IaC security scanning: що знаходять у маніфестах до викочування
Секрети в маніфестах — найчастіший і найдорожчий дефект. Ключ доступу до реєстру образів, токен зовнішнього сервісу або пароль бази, вписані прямо в опис пода чи в змінні середовища збірки, потрапляють в історію репозиторію, де живуть довше, ніж самі маніфести.
Видалити рядок у наступному коміті недостатньо: значення залишається у старих ревізіях і в кеші збирача, тому доводиться змінювати сам секрет, відкликати видані доступи й з’ясовувати, хто ще ним користувався.
Надлишкові права доступу закладають ще на етапі опису, і далі вони тиражуються за кожного викочування.
Сервісний акаунт із правами адміністратора кластера там, де потрібні лише читання й запис однієї гілки; контейнер, запущений від суперкористувача; роль, якій дозволено звертатися до зовнішніх адрес, хоча їй достатньо внутрішньої мережі.
Окрема лінія — сервіси, відкриті назовні за замовчуванням: точка входу без обмеження джерел, публічно доступне сховище, налагоджувальний порт, який забули закрити перед релізом.
Третій клас дефектів — розходження опису інфраструктури та її фактичного стану. Чергова правка руками під час збою закриває інцидент, але залишається непоміченою: план наступного застосування показує «змін немає», а середовище вже живе за іншими правилами.
На наступному викочуванні таке середовище або затирає ручні доопрацювання, або ламається на них — і відновлення йде з пам’яті, а не за описом.
Ціна будь-якого з цих дефектів множиться на швидкість викочування: чим частіші випуски, тим вищий шанс протягнути секрет або зайвий дозвіл у продакшн.
Перевірки всередині конвеєра ловлять це до застосування — розбираємо, як влаштовано IaC security scanning і що саме воно зупиняє на шляху до середовища.
Що дає контроль конфігурацій: швидкість, відмови, простій
Сенс вбудованих перевірок — не в самому факті сканування, а в тому, які числа змінюються після їх увімкнення. Ми дивимося на чотири метрики: час збірки, частку викочувань, які довелося відкочувати, час відновлення після невдалого застосування та сумарний простій.
Контроль конфігурацій впливає на всі чотири, якщо він вбудований у конвеєр, а не винесений в окремий ручний етап.
Швидкість збірки майже не страждає: перевіряються лише змінені модулі, результат кешується між запусками, важкі правила йдуть паралельно з іншими кроками.
Приріст часу збірки вкладається в одиниці відсотків — це помітно менше, ніж час ручного розбору однієї помилки в конфігурації.
Головний ефект — клас відмов, який просто перестає доходити до стенда. Відкриті назовні порти, публічно доступні сховища, ролі з надлишковими правами, ключі у відкритому вигляді всередині шаблонів — такі дефекти ловляться на етапі перевірки змін, а не на етапі експлуатації.
Час відновлення скорочується з тієї ж причини: конфігурація живе як версіонований набір файлів, тому невдале застосування відкочується до попереднього стану, а не правиться вручну на живому середовищі.
Простій через помилку конфігурації переходить із діапазону годин у діапазон хвилин — середовище повертається в робочий стан тим самим автоматичним проходом.
Передбачуваність викочування — наслідок єдиного набору перевірок для тестового й робочого середовища. Дрейф конфігурації видно до застосування, тому розходження між середовищами перестає бути сюрпризом у момент релізу, а зниження відмов стає вимірюваним, а не декларативним.
Режими перевірок: порівняння підходів та їхніх обмежень
Один режим не закриває контур: підходи різняться моментом спрацювання й тим, який стан вони взагалі бачать.
Перевірка під час збірки читає описи до застосування, контроль розходжень звіряє факт із заявленим у середовищі, аудит дивиться вже розгорнутий контур за розкладом, а ручне рев’ю спирається на контекст, який не виражається правилом.
| Режим | Що виявляє | Де обмежений |
|---|---|---|
| Перевірка під час збірки | Відкриті порти, заборонені параметри, помилки зв’язків в описах до застосування | Не бачить правок, внесених у контур руками |
| Контроль розходжень | Відхилення фактичного стану від заявленого | Не відрізняє навмисну зміну від випадкової |
| Періодичний аудит конфігурацій | Накопичені відхилення налаштувань і застарілі ресурси | Між запусками відхилення живе непоміченим |
| Ручне рев’ю описів | Смислові помилки, які не можна описати правилом | Не масштабується й залежить від уваги перевіряльного |
Висновок із порівняння простий: закривати контур одним режимом не можна. Збірка відсікає основну частину помилок до викочування, контроль розходжень ловить те, що пройшло повз неї, аудит добирає повільні відхилення, рев’ю залишається для змін, де потрібен людський контекст.
Правила при цьому тримаємо декларативно — один набір політик відпрацьовує і під час збірки, і на живому середовищі, наприклад через Checkov у зв’язці із завданнями за розкладом.
Етапи впровадження: від інвентаризації до передачі в роботу
Впровадження перевірок безпеки в описи інфраструктури не починається з увімкнення сканера в збірку. Спочатку фіксуємо, що саме перевіряємо: репозиторії з робочими маніфестами, перевикористовувані модулі, шаблони середовищ.
Інакше вже перший прогін видає сотні спрацювань на архівних гілках, правило дратує команду, і його вимикають через тиждень.
- Інвентаризація конфігурацій. Збираємо перелік репозиторіїв, гілок і модулів, які реально застосовуються до живих середовищ. Архівне й експериментальне позначаємо окремо — воно не потрапляє ні в правила, ні у звітність.
- Схема правил і рівнів строгості. Для кожного класу ресурсів вирішуємо, що блокує збірку, що дає попередження, що йде лише у звіт. Схему узгоджуємо з командами заздалегідь, щоб правило не змінювалося в день релізу.
- Налаштування правил і винятків. Вмикаємо набір перевірок, налаштовуємо винятки за шляхами й мітками ресурсів, а конфігурацію сканера тримаємо в репозиторії — тоді правки проходять рев’ю як звичайний код.
- Перевірка на тестовому контурі. Прогоняємо на копії реальних маніфестів, заміряємо кількість спрацювань, час перевірки й частку хибних. Окремо дивимося, наскільки перевірка подовжує збірку — якщо помітно, виносимо важкі правила в окремий крок.
- Придушення шуму. Легітимні відхилення закриваємо точковими винятками з коментарем і строком перегляду, а не вимкненням правила цілком. Так список спрацювань залишається коротким, і його справді читають.
- Передача в експлуатацію. Підключаємо перевірку до основного конвеєра, призначаємо відповідальних за розбір звітів, передаємо документацію й розбираємо з командами типові знахідки.
Після передачі етапи 3 і 5 повторюються в міру появи нових типів ресурсів — схема правил живе разом з інфраструктурою, а не завмирає на дату впровадження.
Артефакти на передачі: модулі IaC, політики й регламенти
Сканування описів інфраструктури закінчується не звітом, а набором артефактів, які ваша команда веде далі сама. Усе залишається у вашому репозиторії поруч з описом середовищ — без прив’язки до наших інженерів або закритих сервісів.
- Перевикористовувані модулі IaC: блоки опису мереж, сховищ, ролей і баз з єдиними вхідними параметрами — новий сервіс розгортається із заготовки, а не копіюванням чужого файлу.
- Бібліотека правил, відкалібрована під ваш контур: які перевірки блокують збірку, які працюють попередженням і чим обґрунтований кожен виняток.
- Політики доступу до середовищ, секретів і сховищ образів: ролі, зони відповідальності та порядок видачі прав — новий інженер входить у контур за інструкцією, а не за листуванням.
- Регламенти реагування: хто розбирає спрацювання, у якому випадку збірка зупиняється, а в якому фіксується відступ зі строком усунення й відповідальним.
- Документація щодо конфігурації: карта середовищ, зв’язки між сервісами й точки, де результат перевірки вбудовано в конвеєр збірки та доставки.
- Схеми інфраструктури, зібрані з опису, і журнал базових значень — видно, скільки знахідок було на старті й які класи зникли.
Артефакти передаються з історією змін і правом правки у вашої команди. Наші інженери залишаються на зв’язку для розбору спірних знахідок і розширення бібліотеки правил.
Кейс: як прибрали витік секретів із конфігурацій
Замовник — продуктова команда з кількома десятками репозиторіїв, де інфраструктура описана декларативно. Секрети потрапляли в конфігурації за інерцією: пароль до бази прописували прямо в змінні середовища маніфесту, ключі до зовнішніх сервісів — у параметри модуля. Перевірка була ручною: перед релізом інженер очима переглядав відмінності в конфігураціях.
На це йшло 3-4 години на реліз, і дефекти все одно проскакували. За квартал фіксували 5-6 витоків секретів, що доходили до робочого контуру.
Розбір одного інциденту займав 6-10 годин: спочатку з’ясувати, який ключ утік і де він використовувався, потім відкликати й замінити його, потім перевірити, чи не було звернень.
Близько 40% знайдених дефектів були повторними — той самий тип помилки спливав у новому репозиторії через кілька тижнів.
Перевірки вбудували в конвеєр збірки та доставки. Gitleaks запускається на кожен запит на злиття й блокує зміну, якщо рядок схожий на ключ або токен; розробник одразу отримує файл і номер рядка.
Паралельно статичний аналіз конфігурацій ловить відкриті порти, надлишкові права й незашифровані томи до потрапляння в основну гілку. Окремим правилом закрили історію комітів — старі секрети більше не тягнуться в нові релізи.
Через два місяці розбір інциденту займав 20-30 хвилин замість 6-10 годин: спрацювання приходить із готовим контекстом, а не як питання «де це лежить». Повторні дефекти впали приблизно до 5% — правило, один раз додане до загальних політик, працює в усіх репозиторіях одразу. Ручний аудит перед релізом прибрали повністю, ці години пішли на завдання розвитку.
Чим відрізняються перевірки під час збірки та в середовищі виконання?
Перевірка під час збірки працює з описом інфраструктури як коду: маніфестами, шаблонами й модулями. Вона відповідає на питання, що саме ми збираємося розгорнути — відкриті правила доступу, надлишкові права ролей, незашифровані томи, посилання на неперевірені образи.
Такий контроль дешевий: він виконується до застосування й зупиняє небезпечну зміну на етапі перевірки, не потребуючи доступу до робочого контуру.
Межі охоплення у статичного контролю жорсткі: він бачить лише те, що описано кодом.
Ресурс, створений вручну через панель керування, обліковий запис, доданий поза описом, або правило, виправлене прямо в контурі, в аналіз не потрапляють — розходження опису й факту залишається невидимим до наступної звірки.
Перевірка в середовищі виконання читає фактичний стан: які ролі існують, які правила відкриті, які томи змонтовані, що реально запущено. Вона ловить дрейф конфігурації та обхідні шляхи, але запобігти нічому не може — зміну вже застосовано, і ми реагуємо постфактум.
Тому вибір режиму контролю — не «або», а «і», і завдання в режимів різні. Збірка відповідає за запобігання, середовище — за виявлення розходжень і підтвердження, що розгорнуте збігається з перевіреним описом.
Третій шар — регулярна звірка опису з фактом: вона показує, де контур відійшов від коду, і повертає такі місця під контроль.
Технічні сумніви: хибні спрацювання та охоплення правил
«Сканер буде шуміти, ми потонемо в спрацюваннях» і «у нас інфраструктура вже розгорнута руками» — заперечення, які чуємо найчастіше. І те, і те закривається тонким налаштуванням правил, а не відмовою від перевірок.
Починаємо з базового набору: публічні порти, відсутність шифрування, відкритий доступ до сховищ. Решту вмикаємо в міру розбору — так шум не перебиває те, що справді веде до відмови.
Правила сиплють хибними спрацюваннями — що з цим робити?
Кожне спрацювання розбираємо й відносимо до трьох груп: реальна помилка, виняток за контекстом, неточне формулювання правила. Для другої прописуємо винятки за шляхом і тегом ресурсу, для третьої — правимо поріг або вимикаємо з позначкою в реєстрі. Шум падає до поодиноких випадків.
Можна впроваджувати поступово, не блокуючи релізи?
Так. Спочатку перевірки йдуть у режимі попередження й не зупиняють конвеєр. Потім блокування вмикається для тестових середовищ, і лише після того як набір правил устоявся — для продуктивних.
Інфраструктура вже розгорнута — описувати все заново?
Ні. Наявні ресурси імпортуємо в стан: вони продовжують працювати, але переходять під управління описами. Далі перевірки йдуть на змінах і поступово покривають те, що вже розгорнуто.
Як бути із секретами в репозиторії?
Окреме правило шукає ключі й токени в описах і змінних. Знайдене не просто позначаємо: ключ відкликаємо, переносимо у сховище секретів, а в код ставимо посилання. Історію комітів чистимо — видалений файл залишається в ній.
Обговоримо завдання: з чого почати впровадження перевірок
Щоб розмова була предметною, корисно заздалегідь зібрати кілька артефактів — тоді на першій зустрічі ми намітимо обсяг аудиту поточного стану й порядок робіт, а не будемо з’ясовувати базові речі. Нижче — те, що найчастіше прискорює старт впровадження IaC security scanning у конвеєр збірки.
- Перелік середовищ: розробка, тест, передпродакшн, продакшн, скільки акаунтів і кластерів, де конфігурації ведуться вручну, а де вже описані кодом.
- Схема поточного конвеєра збірки: на якому кроці запускаються перевірки, що блокує збірку, а що проходить попередженням.
- Відомі проблемні місця: інциденти через розходження конфігурацій, дрейф між стендами, правила, які обходять вручну.
- Список інструментів опису інфраструктури: модулі, шаблони, спосіб зберігання стану — щоб розуміти, що підключати першим.
- Вимоги до доступів і реакції: хто розбирає знахідки, що вважається блокуючим, куди йдуть звіти й як оформлюються винятки.
- Обмеження щодо релізів: вікна, коли можна змінювати конвеєр, і допустима затримка збірки.
- Відповідальні: хто володіє інфраструктурним кодом і ухвалює рішення щодо спірних правил.
Цього достатньо, щоб повернутися з планом впровадження: етапами, пріоритетом середовищ, розподілом ролей і точками контролю. Опишіть завдання у зручній формі — повернемося з оцінкою та планом робіт.
