Проверка безопасности Terraform: почему зелёный сканер не доказывает безопасность инфраструктуры

Terraform удобно превращает инфраструктуру в проверяемые изменения, но это не превращает любой успешный pipeline в заключение о безопасности. Сканер видит только тот материал, который ему передали, применяет выбранные правила и возвращает результат в пределах своей модели. Он не знает, соответствует ли роль CI реальной модели доверия, кто читает state, какие ресурсы изменили вручную и подтвердили ли исправление в облаке. Поэтому покупателю нужна не ещё одна галочка в CI, а проверка цепочки от HCL до работающего ресурса.

Хорошая оценка отвечает на практический вопрос: может ли команда объяснить и доказать, что именно было проверено, в каком контексте и что осталось за границей. Ниже — способ сформировать такой заказ без обещания абсолютной безопасности и без подмены экспертной работы автоматическим отчётом.

Зелёный сканер — сигнал, а не вердикт

Проверка начинается с различия между синтаксисом, планом и реальной средой. Команда terraform validate проверяет, что конфигурация внутренне согласована, но не обращается к удалённым сервисам. План добавляет значения конкретного запуска и предполагаемое изменение. Сканирование JSON-плана может дать инструменту больше контекста и зависимостей, однако некоторые сведения HCL в план не попадают, а сам план способен содержать чувствительные значения. Каждый слой полезен, но отвечает на свой вопрос.

Результат сканера также зависит от активного набора политик. Исключение отдельной проверки, фильтр по severity или soft-fail могут сделать pipeline зелёным, не устранив исходное условие. Поэтому предметом ревью должны быть не только нарушения, но и конфигурация инструмента: какие правила включены, где стоят suppressions, кто их одобряет, есть ли срок пересмотра и видны ли пропущенные проверки в артефакте сборки.

Что входит в покупаемую оценку

Минимальный объект проверки шире каталога с файлами .tf. Рецензенту нужны корневые модули, собственные и внешние модули, версии провайдеров, lock-файл, переменные и backend-конфигурация без передачи самих секретов. Нужен сохранённый план для согласованного окружения, потому что он показывает вычисленные значения и реальные действия. Нужны workflow-файлы CI, матрица идентичностей, политика доступа к state и описание ручных изменений в облаке.

Покупатель заранее решает, ограничится ли оценка анализом кода или также будет сверять его с облачной средой. Code-only обзор может выявить опасный HCL и слабые pipeline-настройки, но не подтвердит отсутствие drift, внешних политик или ресурсов, созданных вне Terraform. Для вывода о производственной среде нужен контролируемый read-only доступ к согласованным аккаунтам и журналам либо совместная сессия, где владелец системы сам показывает доказательства.

State и секреты образуют отдельную границу доверия

Метка sensitive скрывает значение в обычном выводе, но сама по себе не исключает его из state или plan. Для части временных значений Terraform поддерживает ephemeral-механизмы, которые не сохраняют данные в этих артефактах, однако их применимость зависит от версии Terraform, провайдера и конкретного аргумента. Ревью должно установить не наличие красивой метки, а полный путь секрета: от хранилища и выдачи CI до логов, plan, state, резервных копий и прав администраторов.

State следует рассматривать как чувствительный актив. В scope фиксируют backend, шифрование, блокировку, разграничение workspace, аварийный доступ, аудит чтения и сценарий восстановления. Отдельно проверяют, кто может менять backend или выполнять state-команды. Передавать state подрядчику по электронной почте не нужно: безопаснее предоставить ограниченный доступ в согласованной среде либо совместно показать необходимые свойства и доказательства.

План, CI и облачная идентичность проверяются вместе

Защищённый pipeline не заканчивается запуском scanner. Ревью связывает событие запуска, проверяемый commit, созданный plan и идентичность, которая может выполнить apply. Для GitHub Actions это означает анализ permissions, источников недоверенного ввода, сторонних actions, reusable workflows, environments и условий выдачи облачного токена. OIDC убирает необходимость хранить долгоживущий облачный ключ, но trust policy всё равно должна с помощью поддерживаемых условий audience и subject ограничивать репозиторий и применимый контекст запуска — например, ветку, environment или reusable workflow.

Провайдеры и actions — исполняемые зависимости. Lock-файл фиксирует выбранные версии провайдеров и checksums для воспроизводимой установки; его изменение должно быть видимым в code review. Ссылки на сторонние actions, права токена и возможность выполнить код из pull request оценивают как часть того же пути. Даже без найденного нарушения ревью должно назвать зависимости, которые не были прочитаны, и допущения о hosted или self-hosted runner.

1. CommitОбозначает проверяемые HCL, ссылки на модули, lock-файл и workflow
2. PlanВычисляет изменение для выбранного workspace
3. ReviewСопоставляет политики, исключения и ожидаемый эффект
4. Apply identityПолучает ровно согласованные полномочия
5. Live verificationПодтверждает результат и оставшийся drift

Drift меняет смысл code-only вывода

Terraform строит решение по конфигурации, state и сведениям, которые возвращает провайдер. Изменение в консоли, аварийная правка или отдельная система автоматизации способны создать расхождение. Refresh-only plan помогает увидеть изменения удалённых объектов и предварительно проверить предлагаемое обновление state; только refresh-only apply записывает это обновление, не изменяя сами удалённые ресурсы. Решение принять или откатить drift остаётся за владельцем. Сам факт чистого HCL не отвечает на вопрос, совпадает ли production с репозиторием.

Поэтому в договорённости указывают момент съёма доказательств и список аккаунтов, регионов и workspace. Для критичных ресурсов полезно сравнить права, сетевые границы, шифрование и журналирование в live cloud с ожидаемой моделью. Обнаруженное расхождение классифицируют отдельно: допустимое исключение, неучтённое изменение, ресурс вне управления или дефект кода. Это делает remediation проверяемой, а не превращает drift в безымянную «ошибку Terraform».

Как выглядит проверка исправлений

Представим гипотетическую команду: HCL создаёт storage и роль, scanner проходит, а CI применяет plan через OIDC. Во время ревью выясняется, что sensitive output всё ещё попадает в state, suppression скрывает правило для публичного доступа, trust policy допускает лишнюю ветку, а параметр bucket изменён вручную. Это не описание реального инцидента; оно показывает, почему четыре локально «зелёных» элемента могут образовать слабую систему.

Исправление в таком сценарии проверяют по исходной причине. Для секрета подтверждают новый путь данных и отсутствие значения в новом plan/state там, где используется подходящий ephemeral или write-only механизм. Для suppression сохраняют обоснование либо возвращают правило. Для OIDC сужают trust policy и демонстрируют отказ неподходящему контексту. Для drift согласуют желаемое состояние, повторяют plan и затем сверяют live-ресурс. Ретест должен включать хеш commit, workspace, время проверки и фактический результат, а не только скриншот зелёного job.

Матрица выбора услуги и ожидаемый результат

Если задача — быстро проверить новый модуль, подойдёт узкий review HCL и plan с явно записанными ограничениями. Перед значимым релизом разумнее включить state, CI identity, evaluated plan и read-only сверку облака. При нескольких аккаунтах, shared modules и разных pipeline нужен выборочный дизайн: критичные trust boundaries проверяются глубже, повторяющиеся конфигурации — по репрезентативной выборке, а исключения перечисляются в отчёте.

Покупатель должен получить матрицу охвата, находки с доказательствами, перечень suppressions и непроверенных компонентов, сценарии влияния, приоритет исправлений и результат ретеста. Полезный формат описан в материале что должно быть в отчёте, а соседний разбор оценки Infrastructure as Code помогает отделить общий IaC-процесс от особенностей Terraform.

Pentest.red может провести аудит безопасности облачной среды с согласованным Terraform-контуром и проверкой исправлений. Перед запросом оценки зафиксируйте репозитории, workspace, облачные аккаунты, допустимый доступ и формат доказательств в планировщике scope. Так коммерческое предложение будет сравнивать одинаковый объём, а итог не сведётся к повторному запуску scanner.