Захист хмарної інфрастурктури

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

Але природа самої хмари пропонує інший підхід до вирішення проблем безпеки хмар – без звичайних компромісів. У цій публікації ми розглянемо, чому автоматизація хмарної безпеки на основі агента відкритої політики (OPA) – стандарту відкритого коду для політик як коду – може робити те, чого не можуть традиційні підходи безпеки. І ми розглянемо деякі приклади того, як рішення на основі OPA, такі як Fugue, можна цілісно захистити весь життєвий цикл розвитку хмарних інфраструктур.

Чому так важко захистити хмару?

Хмарна інфраструктура сильно відрізняється від інфраструктури центру обробки даних. Інші способи налаштування та управління хмарною інфраструктурою. Мета інша. І спосіб роботи хакерів різний.

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

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

Які зміни в хмарі також відрізняються. Стек інфраструктури центру обробки даних набагато простіший і складається насамперед із мережі, серверів та сховища. Стек хмарної інфраструктури містить віртуалізовані версії цих речей та багато іншого. Існують служби управління ідентифікацією та доступом (наприклад, AWS IAM), безсерверні платформи (наприклад, функції Azure), контейнери (Docker) та системи оркестрування контейнерів (Kubernetes). Тільки Amazon Web Services впровадило сотні нових типів хмарних ресурсів за останнє десятиліття, кожен з яких має свої атрибути конфігурації та міркування безпеки.

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

Відповідність завжди відігравала роль у дотриманні політики безпеки, але хмара порушила традиційну модель відповідності. Більшість компаній, що використовують хмару, повинні дотримуватися галузевих стандартів контролю відповідності, таких як HIPAA для даних про здоров’я, PCI для даних фінансових послуг та SOC 2 для обробки даних клієнтів у хмарі. Однак ці елементи керування написані людською – і часто нечіткою – мовою, яку важко застосувати до випадків використання хмар. І надто багато правил, щоб кожне з них запам’яталося.

Уся ця складність, динамічність та масштабованість призводять до помилок неправильної конфігурації хмар, які виникають протягом дня. У звіті «Стан хмарної безпеки 2021», в якому було опитано 300 інженерів -хмаринок, було виявлено, що половина команд, що працюють у великих, регульованих хмарних середовищах, мають більше 50 неправильних конфігурацій на день. Традиційним інструментом для виявлення цих уразливостей під час роботи у хмарі є Керування поставою Cloud Security (CSPM). Це, по суті, гра «б’є кріт».

І ця гра серйозна. Зловмисники -хакери змінили спосіб атаки хмарних середовищ, щоб викрасти дані та завдати шкоди іншим. Шаблон атаки вибору цілі та пошуку вразливостей для використання перевернувся. Сьогодні хакери використовують засоби автоматизації для пошуку у всьому Інтернеті помилкових конфігурацій хмар, які вони можуть використати. Розгортання такої вразливості може ефективно поставити ціль у тил вашого бізнесу.

Традиційна стратегія атаки	Стратегія хмарної атаки
Крок перший: оберіть свою мету	Крок 1: Пошук вразливостей
Крок 2: Пошук вразливостей	Крок 2: виберіть пункт призначення

Як інфраструктура як код та політика як код змінюють безпеку хмар

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

Завдяки впровадженню автоматизованих конвеєрів розгортання CI / CD та інфраструктури як коду (IaC), які інженери використовують для визначення конфігурацій та взаємозв’язків хмарних ресурсів, тепер ми можемо автоматично запобігати неправильним налаштуванням до їх досягнення під час виконання. На додаток до очевидних переваг безпеки, захист IaC під час розробки та захист від неправильних конфігурацій приносить значні витрати та швидкість.

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

З будь-яким підходом до безпеки «зсув ліворуч» ви говорите про інструменти, зручні для розробників, які допомагають командам розробників виправляти помилки на початку життєвого циклу розробки програмного забезпечення (SDLC). Розробники програмного забезпечення віддають перевагу відкритим вихідним кодам перед власними, які зазвичай обмежені та складніші у використанні. І ви хочете, щоб у SDLC завжди можна було використовувати ті самі вказівки – від інфраструктури, як перевірка коду до захисних рейок CI / CD до моніторингу під час виконання, – щоб розробники, розробники та групи безпеки та комплаєнс працювали відповідно до однакових правил набір правил.

Агент відкритої політики – це популярний механізм політики з відкритим кодом, який є надзвичайно потужним та гнучким. Такі організації, як Goldman Sachs, Netflix і Pinterest, є великими користувачами OPA, і Fugue широко використовує OPA для підтримки автоматизації безпеки на основі політики для хмарних середовищ та IaC. OPA підтримується Фондом Cloud Native Computing Foundation (CNCF) і має надійну екосистему інструментів та активну спільноту. І легше знайти та утримати інженерів, які знають OPA. Якщо ви розглядаєте рамки політики як коду, непогано почати з OPA.

Огляди політики як коду для різних етапів SDLC

Фуга брала активну участь у проекті OPA та розробила інструмент з відкритим кодом Regula, що полегшує використання OPA для перегляду Terraform та AWS CloudFormation IaC. А Fuga IaC дозволяє командам використовувати однакові правила як для перевірок IaC перед розгортанням, так і для моніторингу під час виконання.

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