Налаштування Environment Protection Rules у CI/CD

Environment protection rules: де ламається викатка в прод

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

Тому випадковий реліз у прод частіше трапляється не там, де правила увімкнені, а там, де їх обходять.

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

Права на розгортання при цьому видані ролі, а не людині з прив'язкою до середовища: той, хто править тестовий стенд, отримує той самий рівень доступу до проду.

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

У GitHub такі шляхи видно в правилах захисту середовища як винятки в умовах доступу — їх варто перевіряти до того, як вони спрацюють у проді.

Третій шар — ручні домовленості: «після обіду не викатуємо», «попередь у чаті». Кроку підтвердження як обов'язкової умови при цьому немає — є усна домовленість, яка не залишає сліду і не блокує викатку, якщо про неї забули. Розбираємо, як це закривається на рівні конфігурації, а не дисципліни.

Що дає керований захист середовищ

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

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

Черговому не потрібно в момент аварії з'ясовувати, хто має право натиснути кнопку, — право вже закріплено в політиці середовища.

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

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

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

Режими захисту середовищ: порівняння підходів

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

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

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

Як ми впроваджуємо захист середовищ: етапи робіт

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

Далі — схема ролей і підтверджувачів, налаштування умов, спроба обійти власний захист і передача регламентів команді.

1. Інвентаризація середовищ і способів викатки. Збираємо стенди й канали, через які в них пишуть: конвеєри збірки, ручні запуски, скрипти адміністраторів, правки конфігурації напряму. Окремо позначаємо середовища без власника — обхідним шляхом зазвичай стають саме вони.

2. Схема ролей і підтверджувачів. Фіксуємо, які зміни потребують підтвердження і хто має право його дати — розробник, провідний інженер, черговий. Ролі прив'язуємо до груп, а не до людей: відпустка не повинна зупиняти викатку.

3. Налаштування правил захисту. Для кожного середовища задаємо умови: підтвердження другим інженером, успішні автотести, дозволені гілки й вікно викатки, заборона підтверджувати власні правки.

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

5. Журнал і відкат. Вмикаємо аудит: хто підтвердив, що викатив, коли і чим відкотив. Саме правило відкату перевіряємо на живому середовищі, а не лише на папері.

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

Конфігурації, схеми ролей і регламенти на виході

Захист середовищ — це не набір галочок у вебпанелі, а артефакти, які лежать поряд із кодом і переживають зміну відповідальних.

Ми передаємо їх у вигляді, придатному для рев'ю та онбордингу: правила описані декларативно, ролі прив'язані до груп, а не до конкретних людей, аварійний доступ винесено в окремий регламент.

• Файли декларативного опису середовищ: середовище розробки, передпродакшн і продакшн з роздільними наборами правил захисту.
• Політики доступу: які групи та сервісні облікові записи запускають розгортання, читають секрети й змінюють правила самого середовища.
• Схема підтверджувачів: скільки затверджень потрібно, чому автор запуску не може затвердити його сам, вікно очікування й поведінка завдання, якщо відповіді немає.
• Обмеження за джерелом: дозволені гілки й теги, обов'язковість пройдених перевірок, заборона обходу захищених гілок.
• Робота із секретами: поділ за середовищами, відсутність довгоживучих ключів у змінних, короткоживучі облікові дані для зовнішніх систем.
• Журналювання: склад подій, термін зберігання, вивантаження в загальне сховище й оповіщення про правку правил захисту.
• Документація із захисту середовищ: карта середовищ, схема ролей, порядок підключення нового підтверджувача, розбір частих відмов.
• Регламент аварійного обходу: хто має право зняти захист, на який термін, що обов'язково зробити після і як фіксується сам факт обходу.

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

Кейс: як викатка перестала обходити перевірки

Замовник — продуктова команда з десятком сервісів і щоденними релізами. Захист стояв лише на головній гілці: рев'ю та перевірки конвеєра були обов'язковими, а саме продуктивне середовище залишалося відкритим.

Права на злиття й на викатку не різнилися, тому будь-хто, хто має доступ до гілки, потрапляв у прод напряму.

До впровадження за зіставний період третина викаток у прод пішла без підтвердження відповідального за напрям — не зі злого умислу, а тому що обхідний шлях був швидшим за штатний.

Погодження жило в листуванні: від запиту до дозволу минали години, реліз або чекав, або їхав без нього. Незаплановані релізи дали чотири інциденти, а відкат займав близько сорока хвилин і вимагав ручних дій на серверах.

Захист перенесли з гілок на середовища: для продуктивного середовища увімкнули environment protection rules засобами платформи, у цьому проєкті — GitHub.

Прописали обов'язкових рев'юерів із власників сервісу, правило повторного підтвердження при новому коміті в тому самому наборі змін, вікно очікування перед стартом, дозволені джерела викатки — головну гілку й теги релізів.

Секрети продуктивного середовища відв'язали від спільних: їх бачить лише завдання, якому дозволено викатку.

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

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

Що робити, якщо protection rules уже налаштовані, але їх обходять?

Обхід environment protection rules майже завжди йде не через платформу, а навколо неї — через доступи й людей.

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

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

Ми розводимо ролі: умови захисту змінює обмежене коло, а кожна зміна залишається в журналі й потребує обґрунтування.

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

Варто перевірити, для яких запусків правило взагалі спрацьовує, і закрити ті, де захисту не залишається.

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

П'яте — тимчасові винятки після аварії: інженер вніс себе до списку обходу, щоб терміново підняти сервіс, і запис залишився. Проходимо журналом змін правил, звіряємо винятки з поточними співробітниками й підрядниками і прибираємо все, що втратило підставу.

Захист тримається не сам по собі, а на вузькому колі доступів і одному контрольованому аварійному шляху — з обов'язковим записом у журналі й розбором після. Тоді правило перестає бути декоративним і знову щось означає.

Часті технічні питання із захисту середовищ

Правила захисту середовищ (environment protection rules) — це набір умов для конкретного середовища: хто підтверджує випуск, скільки підтверджень потрібно, які гілки й ролі допускаються, що відбувається з завданням, яке очікує, у разі відхилення.

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

Чи доведеться вимкнути поточні автоматичні викатки?

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

Як випускати аварійне виправлення вночі?

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

Чи отримають зовнішні підрядники доступ до продуктивного середовища?

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

Чи достатньо одного підтверджувача?

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

Обговорімо вашу схему викатки й точки обходу

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

Тому розбір починаємо не з шаблону налаштувань, а з вашої схеми викатки — де сьогодні ухвалюється рішення «у прод можна», і які шляхи ведуть повз це рішення.

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

Щоб розбір був предметним, надішліть:

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

Обговоримо завдання на дзвінку: покажете схему, ми поставимо питання щодо стиків і назвемо, яких даних бракує для точної оцінки. Далі — план впровадження з етапами й порядком увімкнення перевірок без зупинки поточних релізів.