Коли компанія AlgoSec почала аналізувати, що насправді означає мультихмарне середовище для управління політиками безпеки, вони постійно поверталися до одного фундаментального питання: чи змінює мультихмарне середовище суть проблеми політик підключення додатків, чи лише умови їх застосування?
Команда дійшла останнього висновку. Перенесення додатків у публічні або приватні хмари не змінює суті проблеми. Віртуалізація теж її не вирішує. Змінюється лише масштаб проблеми та швидкість, з якою вона розвивається.
Нижче наведено обґрунтування трьох архітектурних рішень, що випливають із цього висновку, а також причини, з яких їх було прийнято.
Принцип 1: Пов’язуйте політику з додатками, а не з мережевими структурами
Мережеві ідентифікатори, як і раніше, необхідні для забезпечення дотримання політик, однак вони є неефективною абстракцією для управління в міжхмарному середовищі, оскільки кожне середовище інтерпретує та застосовує їх по-своєму. Група безпеки AWS та група мережевої безпеки Azure не «розмовляють однією мовою» на рівні управління, навіть якщо вони захищають один і той самий додаток.
Було два можливі шляхи. На рівні практичної архітектури один варіант полягав у окремому управлінні кожною нативною конструкцією; інший — у стандартизації політики на основі більш стійкої абстракції: додатка. Створити окрему логіку управління для нативних конструкцій кожної хмарної платформи або побудувати рівень політики навколо того, що залишається незмінним у всіх них: самого додатка. Команда обрала другий варіант, оскільки альтернатива означала б, що командам з безпеки довелося б використовувати різні ментальні моделі для кожного середовища, в якому вони працюють. Саме цю фрагментацію і покликана вирішувати мультихмарна безпека, а не відтворювати її.
Одне з них успішно переноситься в хмару, а інше — ні.
На практиці це означає, що рішення щодо політик переглядаються з урахуванням того, яке бізнес-додаток зачеплено, а не на основі простого переліку діапазонів IP-адрес і портів, які потребують ручного перенесення, щоб зрозуміти, «що саме цим захищається».
Принцип 2: Єдиний підхід, а не розрізнені рішення для конкретних середовищ
Було б простіше розглядати хмарну безпеку як окрему сферу, що відрізняється від локальної безпеки, з власним набором інструментів та власною командою. Але ми вирішили вчинити інакше.
Логіка була проста: команда з безпеки, яка керує гібридною інфраструктурою, не розглядає хмарні та локальні середовища як дві окремі проблеми з двома окремими бюджетами та двома окремими панелями моніторингу. Для неї це єдина інфраструктура. Якщо розглядати їх як дійсно окремі сфери з окремими продуктами, які клієнтам доводиться самостійно інтегрувати, це призведе до повторення тієї самої проблеми фрагментації, від якої намагаються позбутися команди з безпеки мультихмарних середовищ.
Більш детально ця концепція викладена в нашому технічному документі щодо політики безпеки в мультихмарному середовищі, у якому розглядаються проблеми, з якими стикаються підприємства у міру розширення своїх мереж у декількох хмарних середовищах.
Принцип 3: Незалежність від постачальника — за задумом, а не як виняток
Мультихмарні середовища за визначенням є гетерогенними. AWS, Azure, GCP та локальні брандмауери мають різні API, різні моделі політик та різні способи вираження одного й того самого базового наміру.
Нормалізація з урахуванням цієї гетерогенності мала стати основоположним проектним рішенням, а не функцією, доданою задним числом. Прискорене розгортання гетерогенних мереж не вимагало іншого підходу. Воно лише підтвердило необхідність автоматизованого, незалежного від постачальників управління політиками як базової вимоги, а не додаткової опції.
Це та частина філософії, яка частіше звучить як гасло, ніж піддається детальному поясненню: перехід організацій до мультихмарної архітектури не змінює суті проблеми. З архітектурної точки зору це означає, що немає необхідності відмовлятися від основного підходу та починати все з нуля щоразу, коли темпи впровадження хмарних технологій прискорюються. Орієнтована на додатки та незалежна від постачальників модель природним чином розширюється, а не вимагає розробки нової філософії для кожного нового середовища.
Як це виглядає з точки зору тих, хто цим керує
Обсяг завдання змінився. А проблема залишилася колишньою.
Ніщо з цього не має значення, якщо це не призводить до чогось практичного для команд з безпеки та мережевих фахівців, які щодня керують мультихмарними середовищами. На практиці такий підхід проявляється наступним чином:
- Єдине джерело інформації як у хмарі, так і в локальній інфраструктурі, замість необхідності перемикатися між консолями хмарних сервісів та окремим локальним інструментом.
- Зміни політик аналізуються з точки зору додатків, а не у вигляді списку мережевих ідентифікаторів, які потребують ручного перетворення назад у бізнес-контекст.
- Єдиний робочий процес для моніторингу відповідності вимогам та ризиків у всіх підтримуваних хмарних, SDN та локальних середовищах замість набору розрізнених інструментів забезпечення відповідності, специфічних для кожного середовища, кожен із яких дає лише часткову картину.
Чесний компроміс
Такий підхід до розробки не є найшвидшим. Створення архітектури, орієнтованої на додатки та незалежної від постачальників, займає більше часу, ніж розробка набору точкових рішень для конкретних середовищ, оскільки кожна нова функція має працювати в усіх середовищах, а не бути оптимізованою лише для одного.
AlgoSec вважає, що цей компроміс є правильним. Швидший шлях дозволяє швидше отримати початковий продукт, але створює для клієнта набагато складнішу проблему в довгостроковій перспективі: зростаючу кількість неінтегрованих інструментів, кожен із яких вирішує завдання лише в окремій частині середовища, при цьому відсутнє єдине уявлення про роботу всього набору політик. Саме про цю проблему говорять фахівці з безпеки мультихмарних середовищ, коли пояснюють, чому управління політиками здається їм непосильним завданням.
Джерело: How We Think About Multi-Cloud Policy Consistency: The Architectural Principles Behind the Platform
