Вікіпедія

Безпека за задумом

Безпека за задумом (англ. secure by design) підхід в програмній інженерії, який означає, що програмні продукти та можливості мають бути розроблені принципово безпечними.

Альтернативні стратегії безпеки, тактики та шаблони розглядаються на початку розробки програмного забезпечення, і найкращі вибираються й дотримуються у архітектурі, і також вони використовуються як керівні принципи для розробників.[1] Також рекомендується використовувати шаблони стратегічного проектування, які сприятливо впливають на безпеку, навіть якщо ці шаблони проектування спочатку не були розроблені з урахуванням безпеки.[2]

Безпека за задумом все більше стає основним підходом до розробки для забезпечення безпеки та приватності програмних систем. У цьому підході безпека розглядається і вбудовується в систему на кожному рівні і починається з надійного проекту архітектури. Рішення щодо архітектурного проектування безпеки базуються на добре відомих стратегіях, тактиках і моделях безпеки, визначених як багаторазові методики для вирішення конкретних задач якості. Тактики/шаблони безпеки забезпечують рішення для забезпечення необхідних вимог автентифікації, авторизації, конфіденційності, цілісності даних, приватності, підзвітності, доступності, безпеки та невідмовності, навіть коли система піддається атаці.[3] Щоб забезпечити безпеку програмної системи, важливо не тільки розробити надійну заплановану архітектуру безпеки, але також необхідно зіставити оновлені стратегії безпеки, тактики та шаблони для розробки програмного забезпечення, щоб підтримувати стабільність безпеки.

Очікування атаки ред.

Слід припускати, що зловмисні атаки на програмне забезпечення відбуваються, і намагатися мінімізувати їх вплив. Очікуються вразливості безпеки, а також недійсні дані користувачів.[4] Тісно пов’язаною є практика використання «хорошого» проектування програмного забезпечення, такого як предметно-орієнтоване проєктування або хмарно-орієнтованого підходу[en], також є способом підвищити безпеку за рахунок зниження ризику помилок, що створюють уразливість, навіть якщо використані принципи проектування спочатку не були задумані для цілей безпеки.

Уникнення безпеки через неясність ред.

Як правило, проекти, які добре працюють, не покладаються на неясність. Часто конфіденційність зменшує кількість зловмисників, демотивуючи підгрупу загрозливого населення. Логіка полягає в тому, що якщо для зловмисника зростає складність, збільшення зусиль зловмисника скомпрометувати ціль збентежить його. Незважаючи на те, що ця методика передбачає зниження ризиків, фактично нескінченний набір суб’єктів загрози та методів, що застосовуються з часом, призведе до невдачі більшості методів неясності. Хоча це і не є обов’язковим, належна безпека зазвичай означає, що кожному дозволено знати та розуміти дизайн, «тому що він безпечний». Це має ту перевагу, що якщо багато людей дивляться на комп’ютерний код, то підвищується ймовірність того, що якісь недоліки будуть виявлені раніше (див. закон Лінуса). Недоліком є ​​те, що зловмисники також можуть отримати код, що полегшує їм пошук вразливості для використання. Однак прийнято вважати, що переваги відкритого комп’ютерного коду переважують недоліки.

Мінімізація привілеїв ред.

Також важливо, щоб усе працювало з якомога меншою кількістю привілеїв[en] (див. принцип найменших привілеїв[en]). Наприклад, вебсервер, який працює від імені адміністративного користувача ("root" або "admin"), може мати привілей видаляти файли та користувачів. Таким чином, недолік у такій програмі може поставити під загрозу всю систему, тоді як вебсервер, який працює в ізольованому середовищі, і має привілеї, необхідні лише для доступу до мережі і файлової системи, не можуть скомпрометувати систему, в якій він працює, якщо безпека навколо нього сама по собі також не має недоліків.

Методології ред.

Безпечне проектування має враховуватися на всіх етапах життєвого циклу розробки (незалежно від обраної методології розробки).

Існують деякі попередньо створені методики розробки, безпечні за задуом (наприклад, Безпечний життєвий цикл розробки Microsoft[en]). Microsoft випустила методологію та рекомендації на основі класичної спіральної моделі.

Стандарти та законодавство ред.

Докладніше: Безпека_прикладних_програм#Протоколи_та_стандарти_захисту_додатків

Стандарти та законодавство існують для сприяння безпечному проектуванню, контролюючи визначення поняття «Безпечний» та забезпечуючи конкретні кроки для тестування та інтеграції безпечних систем.

Деякі приклади стандартів, які охоплюють або стосуються принципів Secure By Design:

  • ETSI TS 103 645 [5] який частково включений до документу Уряду Великої Британії «Пропозиції щодо регулювання кібербезпеки розумних продуктів споживача» [6]
  • Серія ISO/IEC 27000 охоплює багато аспектів безпечного проектування.

Кліент-серверна Архітектура ред.

У клієнт-серверних архітектурах програма з іншого боку може не бути авторизованим клієнтом, а сервер клієнта може не бути авторизованим сервером. Навіть якщо вони є, атака людини посередині може поставити під загрозу комунікацію.

Часто найпростіший спосіб зламати безпеку клієнт-серверної системи – це не переходити до механізмів безпеки, а обійти їх. Атака людини посередині є простим прикладом цього, тому можливо використовувати їїдля збору деталей, щоб видавати себе за користувача. Ось чому важливо враховувати шифрування, хешування та інші механізми безпеки у проекті, щоб гарантувати, що інформація, отримана від потенційного зловмисника, не дозволить отримати доступ.

Іншою ключовою особливістю безпечної розробки клієнт-серверної системи є гарна практика кодування[en]. Наприклад, дотримання відомої структури розробки програмного забезпечення, наприклад клієнта та брокера, може допомогти у розробці добре побудованої структури з міцним фундаментом. Крім того, якщо програмне забезпечення буде змінено в майбутньому, ще важливіше, щоб воно відповідало логічній основі поділу між клієнтом і сервером. Це тому, що якщо програміст заходить і не може чітко зрозуміти динаміку програми, він може в кінцевому підсумку додати або змінити щось, що може додати недолік безпеки. Навіть з найкращим проектом це завжди можливо, але чим краще стандартизація проекту, тим менше шансів, що це станеться.

Див. також ред.

Примітки ред.

  1. ↑ Santos, Joanna C. S.; Tarrit, Katy; Mirakhorli, Mehdi (2017). A Catalog of Security Architecture Weaknesses. 2017 IEEE International Conference on Software Architecture (ICSA): 220—223. doi:10.1109/ICSAW.2017.25. ISBN 978-1-5090-4793-2. S2CID 19534342.
  2. ↑ Dan Bergh Johnsson; Daniel Deogun; Daniel Sawano (2019). Secure By Design. Manning Publications. ISBN 9781617294358.
  3. ↑ Hafiz, Munawar; Adamczyk, Paul; Johnson, Ralph E. (October 2012). Growing a pattern language (for security). Onward! 2012: Proceedings of the ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software: 139—158. doi:10.1145/2384592.2384607. ISBN 9781450315623. S2CID 17206801.
  4. ↑ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (October 2009). Secure Design Patterns. doi:10.1184/R1/6583640.v1.
  5. ↑ ETSI TS 103 645 (PDF). Архів оригіналу (PDF) за 3 квітня 2022. Процитовано 8 березня 2022.
  6. ↑ Policy paper: Proposals for regulating consumer smart product cyber security - call for views. Архів оригіналу за 8 березня 2022. Процитовано 8 березня 2022.

Посилання ред.

Отримано з https://uk.wikipedia.org/w/index.php?title=Безпека_за_задумом&oldid=38156783