Сканирование Terraform: где ломается инфраструктура
Инфраструктура редко ломается в момент применения конфигурации. Обычно она разъезжается медленнее: инженер правит правила доступа в консоли, чтобы разблокировать релиз, добавляет маршрут «на пять минут», чинит прод вручную — и всё это живёт мимо кода. Через несколько итераций состояние в облаке перестаёт совпадать с описанием в репозитории.
Так начинается расхождение окружений. Стенд собран из того же модуля, но отличается от прода настройками, которые вносили руками и не переносили обратно. Проверки проходят, а отказ приходит уже после развёртывания: порт открыт наружу, роль выдана слишком широко, хранилище доступно публично.
Откат в такой ситуации не спасает — проблема не в конкретном релизе, а в том, что описание и реальность никогда не совпадали. Дрейф конфигурации стоит дорого не временем сборки, а временем до обнаружения: чем позже он всплывает, тем больше ручных правок инфраструктуры приходится разбирать и возвращать в код.
Сканирование terraform переносит эти проверки на момент, когда конфигурация ещё не применена. Анализаторы tfsec и Checkov разбирают описания ресурсов и находят небезопасные значения на этапе ревью, а не после инцидента. Разбираем, как это устроено и что даёт в работе.
Что даёт регулярная проверка конфигураций: классы отказов
Статический анализ инфраструктурного кода переносит точку контроля влево: конфигурация разбирается до развёртывания, а не после того, как правка уехала в рабочее окружение. Проверка идёт по описанию ресурсов — открытые порты, шифрование диска и хранилищ, права доступа, публичные адреса — и не требует поднимать саму среду. Отчёт появляется на этапе ревью, пока изменение ещё ничего не затронуло.
Время проверки изменений падает с часов ручного чтения конфигураций до минут: правила формулируются один раз и применяются к каждому изменению автоматически. Инженер разбирает не сотню строк, а короткий список замечаний с указанием ресурса и места. Проверка не зависит от внимательности ревьюера, поэтому одна и та же ошибка не возвращается в следующих релизах.
Вторая часть эффекта — единая картина окружений. Один набор правил прогоняется для всех сред, и расхождение между тестовым и рабочим контуром видно как конкретный пункт отчёта, а не как сюрприз при следующем применении. Дрейф конфигураций, накопившийся из ручных правок, перестаёт быть невидимым.
Устранённый класс отказов — не «стало безопаснее» в общем, а конкретика: публично доступное хранилище с резервными копиями, открытый наружу порт базы, права администратора у сервисной учётной записи, отключённое шифрование. Наши инженеры настраивают Checkov вместе с tfsec так, чтобы такие находки блокировали изменение до применения, а не превращались в задачу на потом.
Сканирование Terraform: режимы запуска и их ограничения
Режим запуска определяет не скорость сканера, а то, какие ошибки вы поймаете до применения. tfsec и Checkov разбирают одни и те же декларации Terraform, но включённые в разных точках, дают разный сигнал: обязательный отказ при слиянии и ночной отчёт по всему репозиторию отвечают на разные вопросы.
| Режим | Когда подходит | Чем ограничен |
|---|---|---|
| Проверка в конвейере сборки | Каждый коммит в рабочей ветке: ошибка видна в момент появления | Удлиняет сборку; на крупном репозитории время ожидания растёт заметно |
| Проверка перед слиянием | Блокирующий шлюз для правил, которые нельзя обойти | Без настроенных исключений тормозит срочные правки |
| Плановое сканирование | Обход всего кода по расписанию: находят новые правила и расхождения | Отчёт приходит после факта — часть изменений уже применена в облаке |
| Проверка изменённых модулей | Инкрементально по различиям коммита: быстрая обратная связь | Пропускает связи между модулями и нарушения, унаследованные из общего кода |
На практике режимы не конкурируют, а собираются в связку: на изменённых модулях держат быстрые проверки в конвейере сборки, полный набор правил включают перед слиянием, а по расписанию прогоняют весь репозиторий. Общие наборы правил и списки исключений при этом переиспользуются между точками запуска — иначе команда получает три разных ответа на один и тот же код.
Отдельное ограничение — устаревшие находки: без зафиксированного набора исключений инкрементальный режим и полный прогон показывают разное число замечаний, и доверие к отчёту падает.
Этапы внедрения: от инвентаризации до передачи регламентов
Порядок работ выстроен так, чтобы сканирование terraform давало предсказуемый результат с первого дня, а не превращалось в поток предупреждений, которые все привыкли игнорировать. Сначала снимаем фактическую картину по репозиториям, затем формулируем правила под реальные риски, и только после этого включаем блокировки в конвейере сборки.
- Аудит репозиториев. Инвентаризация модулей Terraform, файлов состояния, провайдеров и владельцев: где описана инфраструктура, какие части общие, какие давно не сопровождаются. На выходе — перечень периметра, который войдёт в проверки.
- Схема правил проверки. Находки tfsec и Checkov сопоставляем с фактическими рисками: публичный доступ к хранилищам, открытые группы безопасности, отключённое шифрование, избыточные права ролей. Всё, что не несёт риска, в набор не попадает.
- Уровни строгости. Правила делим на блокирующие и информационные. Остановка слияния — только для критичного; остальное идёт отчётом, иначе команда теряет скорость на мелочах.
- Настройка исключений. Каждое отключение оформляется точечно, с указанием ресурса, причины и срока пересмотра. Массовые исключения по целым проверкам запрещены — они обесценивают набор.
- Встраивание в конвейер. Проверка запускается на этапе запроса на слияние, локально — на предварительном коммите, чтобы автор видел замечание до отправки ветки на ревью.
- Отладка порогов на реальных изменениях. Прогоняем набор по истории репозитория и считаем долю срабатываний, требующих ручного разбора. Пороги подкручиваем до состояния, когда находки действительно требуют внимания.
- Передача регламентов. Команда получает документ: что блокирует, как добавить исключение, кто владелец правила, как обновлять набор при изменении инфраструктуры, — плюс разбор на живых примерах.
Что остаётся у заказчика: конфигурации, политики, регламенты
Результат работы — не отчёт о находках, а артефакты, которые живут в репозитории и работают без нас. Правила проверки — тоже код: конфигурация сканеров tfsec и Checkov, обязательные условия и порог, при котором сборка останавливается. После передачи инженер запускает проверку локально и в конвейере и получает тот же вердикт, что и мы.
Ненастроенный сканер выдаёт сотни срабатываний, команда перестаёт на них смотреть, и защита становится формальностью — поэтому каждое исключение фиксируем с причиной и сроком пересмотра.
- Политики допуска — какие ресурсы разрешены, какие атрибуты обязательны (шифрование, закрытые сети, метки владельца), при какой критичности изменение блокируется.
- Схема модулей — карта переиспользуемых модулей: обязательные параметры, где лежат общие правила, как подключить новый сервис без копирования конфигурации.
- Матрица доступа — роли и права по средам: что меняет инженер, что только конвейер, где лежат секреты и кто их читает.
- Описание исключений — каждое отключённое правило с обоснованием, ответственным и условием снятия.
- Инструкция для инженеров — как запустить проверку до коммита, как читать вердикт, что делать при срабатывании и как оформить отступление.
- Порядок разбора находок — маршрут от срабатывания до исправления: кто смотрит, в какой срок, что блокирует выпуск, что идёт в очередь.
Артефакты обновляются вместе с кодом в обычном порядке изменений — новый инженер видит работающие правила, а не устные договорённости.
Кейс: дефекты конфигураций, пойманные до развёртывания
Инфраструктура проекта — несколько десятков окружений в Terraform, правки вносили три команды и уводили в окружения после ревью глазами по диффу. Настройки копировали по образцу, поэтому один неудачный фрагмент расходился по десяткам конфигураций и всплывал уже на работающем контуре.
Что показал замер до внедрения проверок
Мы прошли по истории изменений: дефект конфигурации доходил до окружения примерно в каждом четвёртом случае. Больше половины находок — широкие правила сетевого доступа и открытые порты, остальное — диски без шифрования, публично читаемые хранилища и значения секретов прямо в переменных. Доля откатов при развёртывании держалась около 18%, а разбор каждого занимал часы.
Что изменили
Сканеры tfsec и Checkov подключили в проверку запроса на слияние: критичные находки блокируют его, остальные приходят предупреждением с указанием файла и строки. Завели перечень осознанных исключений с обоснованием и свои правила под требования проекта, чтобы проверки не шумели. Отчёт сканирования прикладывается к ревью — ревьюер видит не только дифф, но и риск.
Что стало
Дефекты конфигураций, доходящие до окружения, — с 25% до 2-3%, откаты — с 18% до менее 4%. Разбор находки занимает минуты вместо часов: в отчёте видны правило, файл и строка. Проверками покрыты все изменения конфигураций, включая правки в одну строку.
Что делать, если инфраструктура уже развёрнута вручную?
Универсального пути нет: выбирать нужно по цене простоя окружения и объёму ручных изменений, которые никто не документировал. Работающая инфраструктура — факт, с которым код должен сойтись, а не наоборот.
| Путь | Когда подходит | Ограничения |
|---|---|---|
| Описать в коде | Критичные окружения, которые нельзя останавливать | Импорт в state — ручная работа; часть настроек описывается заново |
| Оставить как есть, точечный контроль | Контуры под скорый вывод, песочницы | Расхождение копится, инциденты плохо воспроизводятся |
| Пересобрать с нуля | Тестовые контуры с восстановлением из копий | Нужны окно простоя и перенос данных |
Описание в коде начинается с импорта: реальные объекты вносятся в state, и следующий план должен быть пустым. Если план что-то меняет — описание не совпало с фактом, и это видно на ревью, а не в момент отказа. Затем в контур добавляется сканирование terraform: tfsec и Checkov проверяют описания на открытые порты, публичные хранилища и отсутствие шифрования до применения.
Точечный контроль — компромисс: сканирование работает в режиме проверки, запись в консоль закрывается, расхождения ищутся регулярно. Ограничение в том, что состояние остаётся ручным — воспроизвести окружение с нуля по-прежнему нельзя.
Пересборка даёт полную управляемость, но требует окна простоя и переноса данных. Её обкатывают на некритичном контуре, отлаживают описания и только потом переносят на продуктив.
Ложные срабатывания, пороги и наследование правил
Сканеры на живом репозитории выдают сотни замечаний, и часть из них — шум от решений, которые команда приняла осознанно. Если этим не управлять, отчёт читают один раз и перестают открывать: реальный сигнал тонет в объёме. Поэтому мы сразу настраиваем порог срабатывания по уровню критичности — сборка останавливается только на том классе находок, который действительно блокирует выпуск, остальное попадает в отчёт как справочная информация.
Наследование правил строится от общего набора политик: базовый профиль живёт в отдельном модуле и подключается во все репозитории, а проект может переопределить или ослабить конкретное правило — с явной фиксацией в коде. Исключения в правилах мы оформляем не отключением проверки, а точечным пропуском с указанием причины и владельца: Checkov и tfsec позволяют задать такой пропуск рядом с ресурсом, и на ревью видно, кто и зачем его поставил.
Разбор находок идёт по одной схеме: подтверждённые уязвимости — в очередь исправлений с приоритетом, ложные срабатывания — в список исключений с обоснованием, спорные — к владельцу ресурса. Отчёт перестаёт быть свалкой и превращается в список задач, который реально закрывается.
Сканер выдаёт сотни замечаний на существующую инфраструктуру — с чего начинать?
Начинаем с базовой линии: фиксируем текущее состояние, включаем порог только на новые изменения и постепенно разбираем накопленное. По мере снижения шума строгий профиль распространяется на весь репозиторий — без остановки работы команд.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы разговор был предметным, стоит заранее собрать минимальный срез: где лежит инфраструктурный код, кто и как его меняет, какие окружения живут отдельно. По этому срезу мы оценим объём сканирования terraform и вернёмся с оценкой и планом работ — с этапами и сроками, а не общими словами.
К обсуждению задачи полезно подготовить:
- доступы к репозиториям — достаточно на чтение, чтобы увидеть структуру модулей и историю правок;
- перечень окружений и то, как они разделены: разработка, предпродуктивное, продуктивное;
- текущие правила проверок — какие проверки уже включены и что требует донастройки.
На основе этого среза мы вернёмся с планом работ и сроками по этапам.
