Створення безпечних, стійких і масштабованих хмарних застосунків вимагає нового набору найкращих практик, які відрізняються від традиційної розробки. InfoWorld пропонує почати із шести з них.
Поява хмарних архітектур кардинально змінила способи розробки, розгортання та керування застосунками. Хоча хмарні архітектури пропонують значні переваги з точки зору масштабованості, еластичності та гнучкості, вони також створюють унікальні проблеми безпеки.
Ці виклики часто відрізняються від тих, які пов’язані з традиційними, монолітними програмами. Розуміння цих нюансів має вирішальне значення для розробників, адже сучасні хмарні застосунки є сумішшю старих і нових проблем безпеки, які потрібно вирішувати всебічно.
У цій статті описано деякі методи безпечного кодування, важливі для створення безпечних, стійких і масштабованих хмарних застосунків.
Шість найкращих методів безпеки для хмарних технологій:
- Архітектура нульової довіри.
- Перевірка введених даних.
- Контроль впливу в Інтернеті.
- Безпечне зберігання файлів.
- Принцип найменших привілеїв.
- Маскування даних журналу.
Архітектура нульової довіри
У хмарній екосистемі модульний характер мікросервісів створює як перевагу, так і проблему. Розробляючи мікросервіс, не слід робити припущень щодо його споживання в ширшому контексті програми.
Суть мікросервісів полягає у тому, що вони можуть бути багаторазовими модульними компонентами. Це означає, що той самий мікросервіс, спочатку розроблений для певної мети в одній програмі, пізніше може бути інтегрований в іншу програму з абсолютно іншими обмеженнями безпеки.
Враховуючи цю плавність, надзвичайно важливо підходити до кожного мікросервісу з нульовою довірою. Таким чином ви гарантуєте, що жодна служба не сліпо довіряє іншій, тим самим зміцнюючи захист кожного мікросервісу, незалежно від контексту його використання.
Двома ключовими елементами нульової довіри є мікросегментація й автентифікація між послугами.
Мікросегментація передбачає поділ вашого застосунку на менші компоненти, якими легше керувати (мікросервіси), і налаштування незалежного контролю безпеки для кожного. Це гарантує, що навіть якщо один компонент скомпрометовано, площа атаки обмежена. Приклад: у хмарній програмі електронної комерції ви б розділили інвентаризацію, оплату й автентифікацію користувачів на різні мікросервіси, кожен із власними протоколами безпеки.
Автентифікація між послугами гарантує, що служби автентифікують одна одну перед обміном інформацією. Це можна зробити за допомогою таких методів, як взаємний TLS (mTLS). Приклад: коли мікросервіс інвентаризації на платформі електронної комерції запитує відомості про платіж у платіжному мікросервісі, можна використовувати взаємний TLS для перевірки ідентичності обох сервісів.
Перевірка введених даних
Такі атаки, як впровадження SQL і обхід шляху до файлу, часто використовують погану перевірку вхідних даних. У хмарній програмі, де мікросервіси можуть надавати доступ до кількох API, ризик таких атак зростає в рази. Забезпечення суворої перевірки та санітарної обробки кожних вхідних даних має вирішальне значення для безпеки. Це означає, що всі дані, незалежно від того, чи надходять вони від кінцевого користувача, чи від іншої служби чи навіть внутрішньої бази даних, мають розглядатися як потенційно шкідливі.
Суворі заходи безпеки API включають перевірку типу, перевірку кордонів і білий список. Перевірка типу та валідація меж передбачає перевірку типу вхідних даних, забезпечення їх відповідності очікуваному типу і встановлення меж або обмежень для певних типів вхідних даних, щоб запобігти переповненню, недоповненню або іншим зловмисним атакам на основі вхідних даних.
Приклад. Якщо на сайті електронної комерції є поле для кількості товару, який потрібно придбати, переконайтеся, що він приймає лише цілі додатні числа. Відхиліть такі введення як від’ємні числа або букви. Також установіть верхню межу, наприклад 100 елементів, щоб запобігти нереальним або потенційно шкідливим замовленням.
Білий список передбачає ведення списку прийнятих вхідних даних або діапазонів значень. Слід приймати лише вхідні дані, які відповідають цим заздалегідь визначеним критеріям. Приклад: для API, який приймає введення кольорів для функції налаштування, використовуйте білий список, щоб дозволити лише певні коди кольорів, наприклад #FF0000 для червоного.
Контроль впливу в Інтернеті
Чим більше елементів вашої програми відкрито для Інтернету, тим більша поверхня вашої атаки. Особливо це стосується хмарних застосунків, де функції часто розподіляються між декількома слабко пов’язаними службами. Обмеження доступу до Інтернету лише основними компонентами обмежує потенційні точки входу для зловмисників.
Основні засоби керування доступом до Інтернету включають правила брандмауера, віртуальні приватні хмари (VPC) і керування дрейфом.
Використовуйте розширені налаштування брандмауера, щоб заблокувати всі несуттєві порти. Сегментуйте свою мережу, щоб ізолювати різні служби та мінімізувати вплив кожної з них. Приклад: ізолюйте свій платіжний шлюз від основної служби додатків, гарантуючи, що навіть якщо одна служба скомпрометована, інша залишається в безпеці.
Впровадьте VPC, щоб ізолювати різні частини вашої програми. Це має включати окремі підмережі для кожного типу служби та мережеві ACL для обмеження трафіку між ними. Приклад: розділіть свою програму електронної комерції на окремі VPC для автентифікації користувачів, каталогу продуктів та обробки платежів.
Відстежуйте дрейф конфігурації ваших служб. Часто внутрішні служби можуть випадково бути відкритими для громадськості через зміни в інших місцях, наприклад модифікації для задоволення непов’язаного запиту API. Встановіть сповіщення про будь-які ненавмисні зміни конфігурації та негайно вирішуйте будь-які відхилення.
Приклад. Припустімо, що існує внутрішня служба звітності, призначена лише для адміністративного доступу. Якщо непов’язана модифікація API випадково відкриває цю послугу для загального персоналу або громадськості, інструменти керування дрейфом попередять команду розробників про це ненавмисне відкриття, спонукаючи до негайного виправлення.
Безпечне зберігання файлів
Зберігання даних у файлах, особливо конфіденційних, вимагає підвищеного рівня безпеки. У той час як бази даних мають свої власні набори ризиків, зберігання файлів може бути ще більш ненадійним, якщо з ним поводитися необережно. Дані на основі файлів завжди повинні бути зашифровані у стані спокою.
Крім того, має бути встановлено жорсткий контроль, щоб обмежити доступ до цих файлів.
Практики безпечного зберігання файлів включають шифрування в стані спокою та керування доступом на основі ролей. Також уважно стежте за тимчасовими файлами. Тимчасові файли не такі вже й тимчасові.
Завжди використовуйте власні методи шифрування платформи, щоб забезпечити найбезпечніше зберігання даних. Навіть якщо зловмисник отримає доступ до вашого фізичного сховища, він не зможе прочитати дані. Наприклад, використовуйте вбудовані методи шифрування, надані вашим рішенням для хмарного зберігання, щоб зашифрувати дані користувача перед їх збереженням.
Використовуйте механізм керування доступом на основі ролей (RBAC), щоб керувати доступом до збережених файлів. Зареєструйте всі доступи, щоб створити контрольний слід. Приклад: у програмі охорони здоров’я надайте лише певному медичному персоналу доступ до записів пацієнтів.
Будьте обережні, створюючи тимчасові файли, вони можуть ненавмисно містити конфіденційну інформацію. Застосуйте підпрограми для автоматичного очищення цих файлів і переконайтеся, що вони не залишаються довше, ніж потрібно.
Приклад. Якщо розробник створює тимчасові журнали для усунення помилок автентифікації користувача, дуже важливо мати автоматичний процес, який очищає ці журнали після вирішення проблеми, гарантуючи, що конфіденційні дані не залишаться позаду. Пам’ятайте, що помилки можуть статися легко (навіть для Microsoft), тому ретельність у процесах очищення є життєво важливою.
Принцип найменших привілеїв
Застосування принципу найменших привілеїв має першорядне значення для розробки застосунків у хмарі. Служби повинні мати лише дозволи, необхідні для виконання своїх функцій. Це мінімізує ризик використання скомпрометованої служби для атаки на інші частини системи. Кроки для застосування найменших привілеїв у коді включають обмежені дозволи, тимчасові облікові дані та регулярні аудити.
Тонко налаштуйте параметри дозволів, щоб вони відповідали конкретним обов’язкам кожного компонента. Це важливо з багатьох точок зору, і часто перспектива API втрачається. Чи потрібно вашому API читати та писати? Якщо так, зробіть їх двома різними API й надайте їм мінімальний рівень привілеїв, необхідних для кожного.
Приклад. Служба реєстрації користувачів (яка, імовірно, вносить зміни) повинна мати набір дозволів із різною областю дії, ніж служба лише для читання, яка повідомляє дані.
Використовуйте короткочасні облікові дані для будь-якої операції, яка вимагає більше дозволів, ніж зазвичай. Переконайтеся, що вони закінчуються, як тільки завдання буде виконано.
Приклад: для операцій резервного копіювання, які потребують підвищених дозволів, використовуйте тимчасові облікові дані, термін дії яких закінчується, щойно резервне копіювання завершиться.
Проводьте регулярні й часті перевірки, щоб виявити надмірно дозволені ролі та вжити заходів для виправлення. Автоматизовані інструменти можуть позначати такі ролі та пропонувати коригувальні заходи.
Приклад: використовуйте автоматизований інструмент аудиту, щоб періодично переглядати ролі та дозволи вашої системи, виділяючи ті, які мають більше доступу, ніж необхідно. Потім виконайте коригувальну дію, щоб повернути ці дозволи.
Маскування даних журналу
Ведення журналів є важливим для моніторингу та налагодження, але журнали також можуть містити конфіденційну інформацію.
Маскування даних гарантує, що коли конфіденційна інформація з’являється в журналах, вона замінюється прихованими версіями, таким чином зменшуючи ризик витоку даних. Ключові компоненти реалізації маскування даних у журналах включають засоби автоматизованого редагування, централізоване керування журналами та політики збереження журналів.
Використовуйте спеціалізовані програмні засоби для автоматичного сканування та редагування конфіденційної інформації в журналах. Приклад: у фінансовій програмі переконайтеся, що дані кредитної картки автоматично редагуються перед входом у журнал, залишаючи видимими лише останні чотири цифри для довідки.
Розгорніть централізовану систему керування журналами, яка збирає журнали з різних джерел. Це не тільки покращує моніторинг, але й гарантує, що політики маскування та редагування однаково застосовуються до всіх журналів, зменшуючи ймовірність витоку конфіденційних даних.
Приклад: у розподіленій хмарній програмі з кількома мікросервісами об’єднуйте журнали з усіх служб у централізовану систему, забезпечуючи послідовне застосування правил маскування даних до всіх вхідних журналів.
Розробіть сувору політику щодо тривалості зберігання файлів журналів. Узгодьте цю політику з будь-якими вимогами відповідності та автоматизуйте видалення журналів, які перевищують цей період.
Приклад: відповідно до GDPR налаштуйте автоматичне видалення журналів, що містять особисті дані, через 30 днів, якщо це не потрібно для аудиту чи юридичних причин.
Крок до кращих методів безпеки
Створення безпечних, стійких і масштабованих хмарних застосунків вимагає нового набору найкращих практик, які відрізняються від традиційної розробки. Головне – інтегрувати ці практики, від архітектури нульової довіри до маскування даних журналу, у життєвий цикл розробки якомога раніше, зробивши безпеку невід’ємною частиною процесу проєктування та розгортання.
У той же час надзвичайно важливо усвідомлювати практичні проблеми впровадження у реальному світі. У швидкоплинному середовищі розробки одночасна інтеграція всіх цих практик безпеки може здатися важким завданням.
Тим не менш, розробникам важливо усвідомлювати пов’язані з цим ризики. Замість того, щоб прагнути до миттєвої досконалості, віддайте пріоритет розумінню кожної практики, а потім стратегічно вирішуйте, що інтегрувати та коли, враховуючи потреби конкретної програми та контексту.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодну публікацію!
