Policy as Code: чому ручні перевірки не утримують інфраструктуру
Ручні перевірки інфраструктури тримаються на домовленості: рев'ю змін працює, поки в команді є людина, яка пам'ятає, що ресурси не можна відкривати назовні, а сервісним обліковим записам не потрібні права адміністратора.
Щойно потік змін зростає або частина роботи переходить підряднику, домовленість перестає тримати — план застосовується швидше, ніж хтось встигає прочитати різницю.
Точки відмови виглядають передбачувано. На великих змінах рев'ю перетворюється на формальність: чотириста рядків в описі мережі ніхто не розбирає порядково, а саме там і з'являється відкритий доступ.
Оточення розходяться — узгоджене для тестового контуру в промисловому застосовують з іншими правами й параметрами.
Дрейф конфігурації накопичується непомітно: правки через консоль не потрапляють у репозиторій, і наступне застосування повертає інфраструктуру не туди, де її залишили.
Policy as Code переносить ці правила з листування в код, який перевіряє план до застосування. Sentinel і OPA описують заборони декларативно: обов'язкові мітки, дозволені регіони, заборона необмежених мережевих правил, вимоги до прав доступу.
Перевірка вбудована в конвеєр, тому відхилені зміни не доходять до середовища — з конкретною причиною та посиланням на порушене правило, а не з повідомленням «перероби».
Далі розбираємо, як це влаштовано на практиці та що саме утримує інфраструктуру в заданих межах.
Що змінюється після впровадження автоматичних перевірок
Політики на Open Policy Agent або Sentinel описуються декларативно й підключаються до конвеєра між описом інфраструктури та її застосуванням.
Тому заборона спрацьовує на етапі планування змін, а не в момент розгортання: інженер бачить причину відмови у виводі звичайної команди та править конфігурацію до того, як вона торкнеться робочого середовища.
- Час перевірки змін. Ручний розбір, який займав у рев'юера від півгодини до кількох годин, замінюється прогоном політик за планом — вердикт приходить разом із результатом збирання, зазвичай за хвилини.
- Частка відхилених змін. Близько третини запитів не проходить перевірку автоматично: відкриті назовні порти, публічні сховища, відсутні мітки, занадто широкі права. Ці правки просто не доходять до середовища.
- Класи відмов, які зникають. Невідповідність політиці безпеки, розбіжності між середовищами, зміни, зроблені руками в обхід конфігурації, і поступове розростання прав.
- Частка інцидентів. Пригоди, спричинені конфігурацією, перестають бути основною причиною збоїв, а розбір кожного випадку займає менше часу — видно, яка політика й яка зміна його допустили.
- Прискорення випуску та простій. Вікно відновлення під час відкату скорочується з годин до хвилин: конфігурація відтворювана, а попередній стан розгортається тим самим способом, що й поточний.
Перевірки не замінюють рев'ю, а знімають із нього механічну частину: людина дивиться на архітектурні рішення, а не на список відкритих портів. Набір політик при цьому розширюється поступово — починаючи із заборон на критичне й додаючи правила в міру накопичення відмов.
Підходи до контролю інфраструктури: порівняння варіантів
Вибір варіанта визначає, на якому кроці порушення буде спіймано. Відхилений план правиться хвилинами, а відкат уже застосованої зміни зачіпає живі ресурси, тому варіанти порівнюємо за точкою перехоплення та ціною супроводу, а не за «потужністю» мови правил.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудований рушій політик платформи (Sentinel) | Увесь ландшафт в одній платформі, потрібні перевірки між планом і застосуванням | Правила прив'язані до платформи: під час переїзду їх описують заново, виразність мови обмежена завданнями платформи |
| Зовнішній рушій політик (OPA) | Кілька платформ і контурів, одне правило має працювати всюди, включно з кластерами та конвеєрами збирання | Потрібен свій шар доставки й версіонування політик, а стан плану передається в окремому форматі |
| Перевірки в репозиторії | Потрібен відгук до звернення до платформи: домовленості про найменування, обов'язкові теги, структура модулів | Бачать вихідні коди, але не обчислені значення плану — частина порушень спливе пізніше |
| Ручне рев'ю | Рідкісні зміни та рання стадія, коли правила ще не усталилися | Не масштабується: зі зростанням кількості команд зростає строк узгодження та частка пропущених порушень |
Робочий контур зазвичай збирається зі зв'язки: швидкі перевірки в репозиторії відсікають очевидне, вбудований рушій перевіряє план перед застосуванням, зовнішній тримає загальні правила для кількох контурів. Далі розбираємо, як зібрати таку зв'язку й не дублювати правила між шарами.
Етапи впровадження Policy as Code: від аудиту до передачі
Порядок етапів тут не формальність: якщо одразу ввімкнути блокування, конвеєр збирання зупиниться на першому ж злитті, і команда повернеться до правок вручну.
Тому спочатку описуємо поточний стан, потім формулюємо правила в попереджувальному режимі й лише після перевірки на стенді переводимо їх у блокувальні.
- Аудит репозиторіїв і станів. Збираємо перелік кореневих модулів, де зберігається стан, хто і як часто вносить зміни, які ресурси створюються поза загальним шаблоном. На виході — карта зон ризику: відкриті порти, публічні сховища, ресурси без тегів і власника.
- Схема політик. Класифікуємо правила на три групи: обов'язкові (безпека й доступи), організаційні (нейминг, теги, регіони) та гігієнічні (заборона застарілих типів ресурсів). Для кожного правила фіксуємо сферу застосування й рівень — блокувальний або попереджувальний.
- Прив'язка правил до стадій Terraform. Частина перевірок виконується за планом до застосування — вони ловлять помилку до створення ресурсів, частина за фактом застосування, частина під час рев'ю. Так розробник отримує зворотний зв'язок за секунди, а не після розгортання.
- Налаштування режимів. Блокувальний режим вмикаємо лише для правил із нульовою кількістю хибних спрацювань, решта ведуть у журнал. Винятки оформлюємо явно — з обґрунтуванням, відповідальним і строком перегляду, щоб не накопичувалися вічні обходи.
- Перевірка на стенді. Прогоняємо політики на копії реальних конфігурацій: рахуємо частку спрацювань, розбираємо спірні випадки, заміряємо, наскільки зріс час перевірки. Після цього правила переносяться в загальний контур. Передача. Віддаємо репозиторій з політиками, схему їхнього устрою, регламент зміни й додавання правил, інструкції для розробників. Далі команда замовника веде правила сама — правки проходять те саме рев'ю, що й код.
Артефакти впровадження: бібліотека політик, схеми, регламенти
Впровадження Policy as Code перевіряється не в день запуску, а в той момент, коли правило потрібно поправити, а автора вже немає на проєкті. Тому ми передаємо не налаштований інструмент, а робочу систему — набір артефактів, за якими ваша команда змінює правила сама, без нас.
- Бібліотека політик — правила Sentinel і Rego, розкладені за доменами: мережа, шифрування, теги, ліміти ресурсів. У кожного правила опис, приклад спрацювання й власний тест.
- Схема залежностей — карта модулів і outputs: що читає чужі значення, де спільний state, які правки зачіпають сусідні компоненти й потребують одночасної зміни.
- Матриця доступу — хто ініціює зміну, хто підтверджує, для яких ресурсів потрібне ручне узгодження, а що проходить автоматично за результатом перевірок.
- Регламент змін — порядок викатки нового правила: спочатку режим попередження, потім м'яка заборона, потім жорстка, з прогоном на історичних конфігураціях до ввімкнення.
- Інструкція для розробника — як прогнати політики локально до відправлення коду, як читати вивід про відмову й що робити при хибному спрацюванні.
- Каталог винятків — оформлені відступи з власником і строком дії, щоб правило не вимикали правкою коду в поспіху.
- Документація — точка входу: де лежать правила, як додати своє, який поріг покриття тестами вважається нормою й до кого йти з питанням.
Окремо віддаємо журнал перших прогонів: видно, які правила спрацьовували найчастіше й де команда правила конфігурації під них, — це найкращий навчальний матеріал для нових інженерів.
Кейс: від ручних перевірок до автоматичного контролю змін
Контур — кілька сотень репозиторіїв з описом інфраструктури, які вели понад десять команд. Кожна зміна проходила ручне рев'ю: перевіряльник звіряв конфігурацію з внутрішнім регламентом за чек-лістом, який відставав від регламенту на місяці.
Частина порушень — відкриті назовні сховища, відсутність шифрування, правки в захищених контурах — ішла в роботу й спливала вже після застосування.
Правила описали як код на Open Policy Agent і винесли в окремий репозиторій з версіонуванням і тестами: до кожного правила додані конфігурації, які воно зобов'язане пропустити й зобов'язане заблокувати.
Перевірку вбудували в конвеєр на етапі плану — до застосування, тому автор зміни одразу бачить, яке правило й який рядок його зупинили.
Нове правило не пишуть «на майбутнє»: спочатку фіксується інцидент або вимога безпеки, потім правило проганяється по історичних конфігураціях, і лише потім вмикається в блокувальний режим.
Перший час частина правил працювала в режимі попередження — так вичистили хибні спрацювання, не зупиняючи команди.
Блокування до застосування зросли з поодиноких випадків до 95% усіх знайдених порушень. Частка відкатів змін, спричинених помилкою в конфігурації, впала з 12% до 3%.
Час перевірки однієї зміни скоротився з 40 хвилин ручного рев'ю до 3 хвилин машинної, при цьому обсяг правил зріс з 15 до 60, а ручних пунктів у чек-лісті стало втричі менше.
Чим вбудований рушій політик відрізняється від зовнішнього?
Вбудований рушій іде разом з інструментом: правила пишуться його власною мовою й перевіряються прямо на етапі планування змін. Зовнішній рушій — окремий компонент, який отримує опис інфраструктури в машинозчитуваному вигляді та виносить вердикт за загальним набором правил.
Розходяться вони за чотирма осями: мова опису правил, переносимість політик, швидкість перевірки й супровід.
| Критерій | Вбудований рушій | Зовнішній рушій |
|---|---|---|
| Мова опису правил | Власна, знає об'єкти одного інструмента | Декларативна загального призначення, єдина для всіх перевірок |
| Переносимість політик | Працюють лише всередині свого інструмента | Один набір покриває інфраструктуру та прикладні маніфести |
| Швидкість перевірки | Вердикт у тому самому процесі, без мережевих викликів | Окремий сервіс: мережевий виклик в обмін на незалежне масштабування |
| Супровід правил | У темпі оновлень інструмента | Свій графік, але реєстр правил і тести тримаєте самі |
Обидва варіанти — це Policy as Code: правила лежать у репозиторії, проходять рев'ю й перевіряються автотестами. Вбудований рушій закриває швидкі ризики одного контуру — правила про оточення, теги й допустимі типи ресурсів пишуться за години й не потребують окремого сервісу.
Зовнішній виграє, коли перевірки потрібні одразу на кількох інструментах. Ми зазвичай починаємо з вбудованого, а загальні правила переносимо в зовнішній рушій — з реєстром, версіонуванням і тестом на кожне правило. Перевірка залишається швидкою, а політики не доводиться переписувати при зміні інструмента.
Технічні сумніви: обмеження та часті помилки впровадження
Саме впровадження правил рідко буває складним — складність у тому, як політика поводиться, коли команда працює під строком і в кількох контурах одночасно. Нижче — питання, які найчастіше спливають на етапі передачі рішення в експлуатацію.
Як бути, якщо правило блокує нормальну зміну?
Ми ділимо правила на попереджувальні та блокувальні, і другі вмикаємо лише після прогону по історії змін у репозиторії — одразу видно, яка частка спрацювань хибна.
Правило формулюється на інваріант (відкритий порт, вимкнене шифрування), а не на оформлення коду: перевірка стилю ламається на будь-якому рефакторингу й через місяць вимикається самою командою.
Що робити під час аварії, якщо правило заважає терміновому виправленню?
Шлях обходу проєктується заздалегідь, а не винаходиться в момент збою: окрема роль з коротким строком дії, обов'язкова причина, слід у журналі та автоматичне завдання на приведення конфігурації до норми.
Політика без штатного обходу вимикається цілком — це найгірший результат, бо контролю не залишається зовсім.
Чи можна перевикористовувати правила між розробкою та експлуатацією?
Загальна бібліотека покриває те, що однаково всюди: теги ресурсів, шифрування, сегментація мережі. Відмінності виносяться в перевизначення на середовище — у розробці м'який режим і ослаблені ліміти, в експлуатації блокування.
Успадкування в Terraform будується через окремі кореневі модулі на контур: інакше ослаблення, додане для налагодження, непомітно їде в бойовий контур.
Обговоримо завдання: з чого почати впровадження перевірок
Щоб впровадження перевірок політик не залишилося демонстрацією на тестовому репозиторії, починаємо з розбору поточного процесу.
Нам важливо побачити, як сьогодні народжується зміна інфраструктури: хто готує описи ресурсів у Terraform, хто узгоджує, на якому кроці помилка зазвичай спливає — на рев'ю чи вже в хмарі після застосування.
Від вас для старту достатньо:
- посилання на репозиторій з інфраструктурним кодом і приклади типових змін за останні цикли;
- перелік вимог, які зараз перевіряються вручну: найменування, теги, мережеві доступи, шифрування, регіони;
- ролі та правила узгодження: хто ініціює зміну, хто підтверджує, у кого право на виняток;
- опис середовищ і відмінностей у режимах застосування;
- доступи до системи контролю версій і до середовища, де будуть запускатися перевірки;
- контакт інженера, який відповідає за інфраструктуру й підтверджує спірні правила.
У відповідь ви отримуєте оцінку та план робіт: перелік правил з пріоритетами, схему їх підключення до процесу змін, обсяг пілотного контуру та строки.
Пілотний контур беремо вузьким — одне сховище й 5-8 правил у режимі попередження, щоб команда звикла до сигналів без блокування викатки. Блокувальний режим вмикаємо після того, як правила перестають давати хибні спрацювання.
Передача документації — частина роботи, а не фінал: опис кожного правила, причина його появи та порядок розбору спрацювання залишаються у вашої команди. Опишіть завдання — повернемося з оцінкою та планом.
