У великих або регульованих середовищах помилка в налаштуваннях призводить не тільки до простою, а й до витоку даних, штрафів чи довгих розслідувань.
Policy-as-Code (PaC) вирішує цю проблему простим принципом. Замість того щоб ховати правила в документах, ми записуємо їх у код. Його можна перевірити, протестувати й виконати автоматично, бо він живе в Git біля решти інфраструктури.
У цьому гайді ми розберемо, що таке PaC, як воно працює на практиці та з чого почати, щоб отримати максимальний ефект від найменшої кількості правил.
Що таке Policy-as-Code?
Уяви, що ти пишеш код для продакшну. Є інструменти, які перевіряють стиль коду, щоб він був акуратним, і є unit-тести, які гарантують, що функції працюють так, як треба.
Policy-as-Code — це майже те саме, але для інфраструктури й безпеки. Правила безпеки записуються у вигляді коду, наприклад, за допомогою Rego, Sentinel або як конфігурації для Checkov.
Ці файли зберігаються в Git, проходять перевірку колег і версіонуються, як будь-який інший код. Коли інфраструктура змінюється, ці правила виконуються автоматично: під час створення pull request, на етапі планування Terraform або як частина організаційних обмежень хмари.
Якщо правило не виконано, пайплайн повертає чітке повідомлення з поясненням, що саме пішло не так і чому, щоб ти міг швидко зрозуміти та виправити проблему.
Чому саме код, а не текст у документі?
Тому що код:
- відтворюваний — перевірка завжди однакова;
- тестований — можна додати unit-тести на політику;
- прозорий — хтось у команді може подивитись diff і зрозуміти, що змінилося;
- автоматичний — рутиною не займається людина, а система.
Приклад простого сценарію: ти хочеш, щоб усі S3-бакети були зашифровані. Замість інструкції в Confluence, пишеш правило, яке перевіряє, чи в плані Terraform для кожного бакета вказаний KMS-ключ. Якщо ні — pull request блокується з повідомленням: «S3 must use KMS CMK».
Ось як розібратись простіше → Якщо ти знайомий з code review, уяви, що правила PaC — це рев’юер, який знає про безпеку. Він не замінює рев’ю коду вручну, але ловить базові та критичні помилки ще до застосування змін.
Де живе PaC?
- у репозиторії з інфраструктурним кодом (Git);
- у CI/CD, де запускають перевірки на pull request;
- у план-тайм (наприклад, аналіз
terraform plan); - в організаційних політиках хмарного провайдера (SCP, Azure Policy, GCP constraints) — як останній рівень захисту.
Навіщо це потрібно?
Про простої, штрафи та витоки даних ми вже згадували. Але це не єдині причини, чому PaC є таким потрібним.
- Дотримання стандартів типу NIST, CIS або ISO
Правила завжди зберігаються поруч з інфраструктурою у Git, тож не потрібно шукати потрібну політику в документах. - Мінімізація людських помилок
Без PaC ти можеш легко загубитися між комітами або змінитися без контролю. А з ним кожна зміна проходить перевірку на pull request, на етапі планування Terraform і навіть на рівні організаційних обмежень хмари. - Документальне підтвердження комплаєнсу
Кожне правило має чітке повідомлення про помилку та посилання на стандарт, який воно реалізує. Все автоматично, без додаткових звітів і ручної перевірки. - Прозорість для команд DevOps і DevSecOps
Правила стають частиною пайплайну, і ти завжди бачиш, де виникли проблеми і як їх виправити ще до того, як зміни потраплять у продакшн.
Три рівні перевірок і контролю Policy-as-Code
У Policy-as-Code перевірки інфраструктури організовані у три рівні, і кожен додає свій рівень захисту.
Pull Request Checks
Це перший рівень контролю, який спрацьовує під час створення pull request у Git. Тут інфраструктура проходить легку перевірку, трохи як spell-check для коду. Така перевірка допомагає зловити очевидні помилки ще до того, як вони потраплять у продакшн. Наприклад:
- відкриті адміністраторські порти;
- бакети без шифрування;
- ресурси без обов’язкових тегів.
Terraform Plan-Time Enforcement
Другий рівень перевірок. Тут оцінюється, що насправді збирається змінити Terraform, і можна налаштовувати різні рівні суворості:
- advisory — попередження без блокування;
- soft-mandatory — обмеження помірковане;
- hard-mandatory — зміни блокуються повністю.
За допомогою Open Policy Agent або інших інструментів можна виконувати Rego-політики прямо на плані Terraform. Саме на цьому рівні перевіряються критично важливі правила — шифрування даних, обмеження доступу до адмін-портів, контроль ролей IAM у проді.
Organizational Guardrails
Третій рівень, який працює на рівні хмарного акаунта або організації. Це останній рубіж захисту, який гарантує виконання політик навіть якщо хтось обійде правила пайплайну. Приклади:
- AWS: Service Control Policies обмежують права навіть для root-користувача та застосовуються глобально.
- Azure: політики можна прив’язати до визначень з ефектами audit, deny або deployIfNotExists.
- GCP: обмеження на рівні організації, каталогу або проєктів.
Разом ці три рівні забезпечують багаторівневий контроль. Pull request ловить швидкі помилки, Terraform-план дозволяє заздалегідь оцінити зміни, а організаційні обмеження гарантовано виконують критичні правила незалежно від того, хто і як намагається змінити інфраструктуру.
Малий набір політик, що дає великий результат
Навіть кілька простих правил Policy-as-Code можуть дати значний ефект для безпеки та комплаєнсу.
Ідея в тому, щоб почати з найважливішого, що реально зменшує ризики, а не перевантажувати команду довгими списками правил:
- Шифрування даних у спокої (encryption at rest). Всі S3-бакети, диски та бази даних повинні використовувати ключі, якими керує клієнт (customer-managed keys). Це забезпечує контроль ротації ключів і прозору історію володіння.
- Обмеження доступу до мереж (CIDR). Не можна залишати адміністративні порти відкритими для всіх (
0.0.0.0/0). Доступ слід обмежити до затвердженого списку IP або через bastion host. - Правильне призначення ролей (IAM). Не використовуй wildcard-права у продакшн середовищі. Доступ повинен бути мінімальним і за ролями, щоб обмежити можливі помилки або зловживання.
- Обов’язкові теги на ресурсах. Наприклад,
Owner,CostCenter,Env. Вони допомагають швидко зрозуміти, хто відповідає за ресурс, і зберігати чистоту у звітах по витратах. - Дозволені регіони (Region allow-list). Політики на рівні хмарного провайдера (AWS SCP, Azure Policy, GCP Constraints) контролюють, де можна створювати ресурси. Це важливо для дотримання правил локального законодавства і планів disaster recovery.
Кожне правило живе як коротка політика з чітким повідомленням про помилку. Наприклад, якщо S3-бакет не зашифрований, пайплайн поверне:
S3 must use KMS CMK
Також правила можна протестувати та пов’язати з відповідним контролем стандартів NIST чи CIS.
Як впровадити Policy-as-Code поетапно?
Policy-as-Code найефективніше працює, коли його впроваджують поетапно, а не намагаються увімкнути всі правила одразу.
Основні чотири фази виглядають так:
- Фаза 1: Advisory (попередження)
Pull request перевіряє правила, Terraform-план аналізується, а критичні обмеження поки не блокують зміни. Мета — зібрати дані, зрозуміти, які помилки з’являються найчастіше, і налаштувати правила так, щоб не було фейкових тривог (false positives). - Фаза 2: Targeted Enforcement (цільове блокування)
Після того, як команди розуміють поведінку політик, можна включати суворі правила для критичних речей: шифрування даних, відкриті адміністративні порти, wildcard-права у прод.
Інші менш критичні перевірки залишаються у режимі advisory, щоб не створювати зайвий хаос. - Фаза 3: Organizational Guardrails (організаційні обмеження)
Це рівень політик на рівні акаунтів і регіонів хмарних провайдерів. Тут застосовуються AWS Service Control Policies, Azure Policies, GCP Constraints. Вони гарантують, що навіть якщо хтось обійде пайплайн або зробить зміни поза Terraform, критичні правила все одно виконуються. - Фаза 4: Runtime Posture & Feedback (постійний моніторинг та вдосконалення)
Навіть після повного впровадження Policy-as-Code не варто зупинятися. Додай runtime-моніторинг, наприклад AWS Security Hub або CIS Benchmark checks, щоб виявляти конфігураційний дрейф. За потреби пиши нові правила, додай unit-тести та оновлюй політики на основі досвіду.
Порада: починай з малого, збирай дані, поступово нарощуй суворість правил. Не потрібно одразу вмикати «режим диктатора» — дай команді звикнути.
Підсумуємо
Policy-as-Code допомагає тримати інфраструктуру під контролем, мінімізувати помилки та довести комплаєнс документально. Починай з простих правил у режимі advisory, поступово додавай суворі обмеження й обов’язково відстежуй ефективність на всіх рівнях: pull request, планування Terraform і організаційні guardrails.
Малий набір правил може дати великий ефект: шифрування, обмеження доступу, теги, контроль прав і регіони. Важливо впроваджувати PaC поетапно, уникати фейкових тривог і завжди мати одне джерело істини.
