Безпека за задумом (англ. secure by design) підхід в програмній інженерії, який означає, що програмні продукти та можливості мають бути розроблені принципово безпечними.
Альтернативні стратегії безпеки, тактики та шаблони розглядаються на початку розробки програмного забезпечення, і найкращі вибираються й дотримуються у архітектурі, і також вони використовуються як керівні принципи для розробників.[1] Також рекомендується використовувати шаблони стратегічного проектування, які сприятливо впливають на безпеку, навіть якщо ці шаблони проектування спочатку не були розроблені з урахуванням безпеки.[2]
Безпека за задумом все більше стає основним підходом до розробки для забезпечення безпеки та приватності програмних систем. У цьому підході безпека розглядається і вбудовується в систему на кожному рівні і починається з надійного проекту архітектури. Рішення щодо архітектурного проектування безпеки базуються на добре відомих стратегіях, тактиках і моделях безпеки, визначених як багаторазові методики для вирішення конкретних задач якості. Тактики/шаблони безпеки забезпечують рішення для забезпечення необхідних вимог автентифікації, авторизації, конфіденційності, цілісності даних, приватності, підзвітності, доступності, безпеки та невідмовності, навіть коли система піддається атаці.[3] Щоб забезпечити безпеку програмної системи, важливо не тільки розробити надійну заплановану архітектуру безпеки, але також необхідно зіставити оновлені стратегії безпеки, тактики та шаблони для розробки програмного забезпечення, щоб підтримувати стабільність безпеки.
Слід припускати, що зловмисні атаки на програмне забезпечення відбуваються, і намагатися мінімізувати їх вплив. Очікуються вразливості безпеки, а також недійсні дані користувачів.[4] Тісно пов’язаною є практика використання «хорошого» проектування програмного забезпечення, такого як предметно-орієнтоване проєктування або хмарно-орієнтованого підходу[en], також є способом підвищити безпеку за рахунок зниження ризику помилок, що створюють уразливість, навіть якщо використані принципи проектування спочатку не були задумані для цілей безпеки.
Як правило, проекти, які добре працюють, не покладаються на неясність. Часто конфіденційність зменшує кількість зловмисників, демотивуючи підгрупу загрозливого населення. Логіка полягає в тому, що якщо для зловмисника зростає складність, збільшення зусиль зловмисника скомпрометувати ціль збентежить його. Незважаючи на те, що ця методика передбачає зниження ризиків, фактично нескінченний набір суб’єктів загрози та методів, що застосовуються з часом, призведе до невдачі більшості методів неясності. Хоча це і не є обов’язковим, належна безпека зазвичай означає, що кожному дозволено знати та розуміти дизайн, «тому що він безпечний». Це має ту перевагу, що якщо багато людей дивляться на комп’ютерний код, то підвищується ймовірність того, що якісь недоліки будуть виявлені раніше (див. закон Лінуса). Недоліком є те, що зловмисники також можуть отримати код, що полегшує їм пошук вразливості для використання. Однак прийнято вважати, що переваги відкритого комп’ютерного коду переважують недоліки.
Також важливо, щоб усе працювало з якомога меншою кількістю привілеїв[en] (див. принцип найменших привілеїв[en]). Наприклад, вебсервер, який працює від імені адміністративного користувача ("root" або "admin"), може мати привілей видаляти файли та користувачів. Таким чином, недолік у такій програмі може поставити під загрозу всю систему, тоді як вебсервер, який працює в ізольованому середовищі, і має привілеї, необхідні лише для доступу до мережі і файлової системи, не можуть скомпрометувати систему, в якій він працює, якщо безпека навколо нього сама по собі також не має недоліків.
Безпечне проектування має враховуватися на всіх етапах життєвого циклу розробки (незалежно від обраної методології розробки).
Існують деякі попередньо створені методики розробки, безпечні за задуом (наприклад, Безпечний життєвий цикл розробки Microsoft[en]). Microsoft випустила методологію та рекомендації на основі класичної спіральної моделі.
Стандарти та законодавство існують для сприяння безпечному проектуванню, контролюючи визначення поняття «Безпечний» та забезпечуючи конкретні кроки для тестування та інтеграції безпечних систем.
Деякі приклади стандартів, які охоплюють або стосуються принципів Secure By Design:
У клієнт-серверних архітектурах програма з іншого боку може не бути авторизованим клієнтом, а сервер клієнта може не бути авторизованим сервером. Навіть якщо вони є, атака людини посередині може поставити під загрозу комунікацію.
Часто найпростіший спосіб зламати безпеку клієнт-серверної системи – це не переходити до механізмів безпеки, а обійти їх. Атака людини посередині є простим прикладом цього, тому можливо використовувати їїдля збору деталей, щоб видавати себе за користувача. Ось чому важливо враховувати шифрування, хешування та інші механізми безпеки у проекті, щоб гарантувати, що інформація, отримана від потенційного зловмисника, не дозволить отримати доступ.
Іншою ключовою особливістю безпечної розробки клієнт-серверної системи є гарна практика кодування[en]. Наприклад, дотримання відомої структури розробки програмного забезпечення, наприклад клієнта та брокера, може допомогти у розробці добре побудованої структури з міцним фундаментом. Крім того, якщо програмне забезпечення буде змінено в майбутньому, ще важливіше, щоб воно відповідало логічній основі поділу між клієнтом і сервером. Це тому, що якщо програміст заходить і не може чітко зрозуміти динаміку програми, він може в кінцевому підсумку додати або змінити щось, що може додати недолік безпеки. Навіть з найкращим проектом це завжди можливо, але чим краще стандартизація проекту, тим менше шансів, що це станеться.