Оценка безопасности инфраструктуры как кода: что проверять в шаблонах, модулях и CI/CD

Сценарий вымышленный, но собран из узнаваемых деталей. Платформенная команда поддерживает внутренний модуль объектного хранилища, на который опираются три десятка сервисов. Чтобы упростить жизнь одной команде, которой нужен публичный доступ к статике, в модуль добавляют переменную public_read. Значение по умолчанию забывают выставить в false, а ревьюер смотрит только на изменённые строки и не замечает, что умолчание стало разрешающим. Сканер в конвейере срабатывает, но это правило давно переведено в рекомендательный режим, потому что «слишком шумело». Через неделю модуль обновляется у всех потребителей, и часть хранилищ с выгрузками и резервными копиями становится читаемой извне. Периметр никто не взламывал: инфраструктура сделала ровно то, что было описано в коде.

В этой истории нет одной «уязвимости», которую нашёл бы сканер портов. Есть цепочка решений: как устроен общий модуль, какие у него умолчания, кто и как согласует изменения, что конвейер делает с предупреждениями политики, как быстро исправление в модуле расходится по средам. Именно это и должна проверять оценка безопасности инфраструктуры как кода. Ниже — что входит в такой аудит, как адаптировать к нему общие методики, где автоматика перестаёт помогать и как заказать работу с воспроизводимым и сопоставимым результатом.

Чем оценка IaC отличается от проверки работающих серверов

Традиционная техническая проверка идёт по живым системам: узел за узлом, сервис за сервисом. Оценка инфраструктуры как кода смотрит на источник, из которого эти узлы появляются. Это шаблоны Terraform или OpenTofu, CloudFormation, манифесты и Helm-чарты, переиспользуемые модули, файлы переменных, описания конвейеров CI/CD и правила policy-as-code. И это процесс поставки, который превращает код в сети, учётные записи, хранилища и балансировщики.

Отсюда двойной вопрос, на который отвечает аудит. Первый: обеспечивает ли описанная инфраструктура те свойства безопасности, которые организация считает обязательными, — закрытые по умолчанию хранилища, узкие роли, включённое журналирование, шифрование? Второй: останавливает ли конвейер небезопасное изменение до того, как оно попадёт в продуктивную среду, или только сообщает о нём в журнал, который никто не читает?

У IaC есть свойство, которое меняет экономику проверки. Решения в ней централизованы: одна ошибка в популярном модуле повторяется во всех средах, которые его подключают. Но то же свойство масштабирует и исправления. Поправленное умолчание в модуле помогает устранить общую причину. У каждого потребителя нужно проверить, что обновление применено, опасные переопределения убраны, а фактические ресурсы приведены к нужному состоянию. Это наблюдение о природе IaC, а не статистика, но оно определяет, где копать глубже и как группировать находки.

При этом важно не переоценивать то, что доказывает анализ кода. Статическая проверка репозитория показывает, что описано. Она не доказывает, что живое окружение совпадает с описанием: ресурсы могли изменить вручную через консоль, часть мер наследуется от политик уровня организации или аккаунта, а некоторые значения появляются только в момент применения. Поэтому зрелая оценка всегда указывает, на каком уровне получено каждое доказательство: код, план изменений, тестовый стенд или — по отдельному разрешению — развёрнутая среда.

Границы аудита: что входит в проверку и что требует отдельного разрешения

Объём оценки IaC шире, чем «папка с шаблонами». В него входят декларативные шаблоны и переиспользуемые модули, включая внутренние каталоги модулей; файлы переменных, наложения для разных сред и источники параметров; описания конвейеров, которые планируют, согласуют и применяют изменения; правила policy-as-code вместе с реестром одобренных исключений; обращение с файлами состояния, секретами и журналами конвейеров. Отдельно стоит конфигурация периметра, которую задают шаблоны: HTTP-заголовки ответов на шлюзах, балансировщиках и ingress-контроллерах, такие как Content-Security-Policy, правила CORS и Permissions-Policy. Если эти заголовки описаны в коде, они становятся проверяемым объектом наравне с правилами сетевого доступа.

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

Отдельный момент — данные, которые увидит проверяющий. Файлы состояния и вывод плана нередко содержат адреса внутренних ресурсов, идентификаторы, а иногда пароли и ключи. Где эти данные хранятся во время проекта и как удаляются после него — часть границ, а не формальность.

Если ваш IaC описывает в основном кластерную инфраструктуру, часть вопросов пересекается с аудитом безопасности Kubernetes: манифесты, RBAC и сетевые политики там проверяются как объекты работающего кластера, а здесь — как код, из которого кластер собирается.

Методика: как применить NIST SP 800-115 к шаблонам и конвейерам

Ни один из используемых здесь источников сам по себе не задаёт полного метода оценки IaC. Удобная отправная точка — NIST SP 800-115, «Техническое руководство по тестированию и оценке информационной безопасности», выпущенное в сентябре 2008 года вместо SP 800-42. Документ описывает, как планировать и проводить технические проверки, анализировать результаты и вырабатывать меры по снижению рисков, и называет две цели таких проверок: поиск уязвимостей и подтверждение соответствия политике или другим требованиям. Для IaC актуальны обе, и, как будет видно ниже, их полезно не смешивать.

Это обзор методов, а не исчерпывающая программа, и об IaC в нём не говорится, поэтому логику документа приходится переводить, а не копировать.

Планирование, выполнение, пост-выполнение

Формально SP 800-115 делит оценку на три фазы. Планирование — это границы, письменное разрешение, цели и правила работ. Выполнение — сами проверки: для IaC это разбор шаблонов, модулей и описаний конвейеров, анализ планов изменений и неразрушающие проверки на согласованных стендах. Пост-выполнение — анализ результатов, отчёт и рекомендации по снижению риска.

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

Рабочий цикл устранения

Поверх формальных фаз удобно держать практический цикл — это авторская рекомендация, а не часть стандарта. Каждая находка превращается в формулировку риска с первопричиной и владельцем. Затем следует исправление на уровне кода, лучше всего в модуле, а не у одного потребителя. Затем — защитный механизм, который снижает риск повторения и обнаруживает охваченные им сценарии: правило политики, тест модуля, обязательная проверка в конвейере. И наконец — повторная проверка и документированный остаточный риск, включая исключения со сроком действия.

Находки IaC хорошо ложатся на семейства мер защиты, с которыми NIST связывает SP 800-115, — аудит и подотчётность, целостность систем, защита коммуникаций, оценка рисков, приобретение систем и услуг: журналирование, сетевые границы, целостность конвейера, происхождение модулей.

Модель угроз: где концентрируется риск инфраструктурного кода

Модель угроз для IaC не обязана быть длинной: достаточно нескольких областей, привязанных к целевым результатам организации и классам первопричин, чтобы приоритеты расставлялись последовательно, а не по ощущению.

Идентификация, права и сетевая доступность

Дорогие ошибки могут выглядеть в диффе совершенно безобидно: роль с подстановочными правами «временно», долгоживущий ключ сервисной учётной записи вместо федерации, входящее правило с широким диапазоном адресов, балансировщик, который по умолчанию создаётся публичным. Каждая такая строка в модуле умножается на число его потребителей. Сюда же относится защита данных по умолчанию: выключенное шифрование, отсутствующее хранение журналов, отключённый аудит доступа к хранилищам.

Журналирование заслуживает отдельного внимания. Руководство CISA Secure by Design относит журналирование к возможностям, которые производитель должен предоставлять по умолчанию и без доплаты. Общий модуль IaC — по сути продукт для внутренних команд, и применять к нему тот же принцип разумно: журналы аудита должен включать модуль, а не каждый потребитель по отдельности. Это наш вывод по аналогии, а не специальное требование CISA к IaC.

Секреты, файлы состояния и журналы конвейера

Секреты в IaC утекают не только через закоммиченные файлы переменных: значение может оказаться в файле состояния в открытом виде, в журнале сборки из вывода плана или в отладочном логе провайдера. Поэтому вопроса «есть ли секреты в репозитории» недостаточно. Нужно проследить путь секрета: откуда он берётся, где хранится состояние, кто может читать бэкенд состояния и артефакты сборки, как долго живут журналы.

Конвейер как поверхность атаки

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

Классический механизм — шаги, которые подставляют недоверенные данные в команды оболочки: название ветки, заголовок pull request, имя файла. Это класс внедрения команд ОС, которому CISA посвятило отдельное предупреждение Secure by Design. Его же предупреждение об обходе каталогов актуально там, где конвейер распаковывает или копирует артефакты по путям, зависящим от входных данных. Отдельная тема — сторонние модули и провайдеры: незафиксированная версия или ссылка на изменяемую ветку означает, что содержимое модуля может поменяться без ревью. Как встроить защиту цепочки поставок в конвейеры CI/CD, разбирает NIST SP 800-204D; подробнее о проверке этой части — в материале об оценке безопасности цепочки поставок ПО.

1. Внешний pull requestАтакующий открывает PR из форка и помещает в название ветки или заголовок фрагмент команды оболочки.
2. Подстановка в шаг CIШаг планирования вставляет это значение в команду оболочки без экранирования, и фрагмент исполняется на раннере.
3. Учётные данные раннераРаннеру доступен токен с правами чтения состояния или применения изменений, потому что секреты не отделены от недоверенных событий.
4. Утечка или подменаАтакующий читает файл состояния с секретами или меняет модуль, и изменение расходится по всем средам-потребителям.

Специалист смотрит, какие события запускают какие задания, какие секреты доступны заданиям из форков, разделены ли планирование и применение и кто даёт ручное согласование для продуктивной среды. Это вопросы технической границы доверия. Процессные вопросы — кто владеет политиками, как фиксируются согласования — проверяет аудит процессов, и это другая работа с другими доказательствами. О ней подробно рассказано в статье об аудите процессов DevSecOps.

Дрейф между кодом и реальностью

Последняя область — расхождение описанного и развёрнутого. Ручная правка в консоли во время инцидента, ресурс, созданный в обход IaC, настройка уровня организации, перекрывающая шаблон, — всё это делает код неполным источником истины. Анализ дрейфа отвечает не на вопрос «хорош ли код», а на вопрос «можно ли по коду судить о среде». В мультиоблачных окружениях к нему добавляются различия моделей прав и умолчаний у провайдеров, поэтому эту часть удобно разбирать вместе с оценкой безопасности мультиоблачной инфраструктуры.

Методы оценки и что каждый из них не видит

Ни один метод не закрывает всю картину, и SP 800-115 прямо подчёркивает, что у каждого есть свои преимущества и ограничения. Хорошая оценка сочетает методы и честно пишет, какой из них дал какое доказательство.

Два практических замечания к таблице ниже. Анализ плана требует аккуратно ограниченных учётных данных непродуктивной среды, а сам вывод плана нужно хранить как конфиденциальные данные. Проверка стенда включает и периметр: если шаблон задаёт заголовки безопасности на ingress, на стенде проверяется, что они действительно возвращаются.

Одна оговорка про стенд: результат проверки тестовой среды не переносится на продуктивную без изменений. Стенд подтверждает, что модуль способен развернуть безопасную конфигурацию с заданными параметрами. Что именно развёрнуто в продуктивной среде, показывают только её собственные данные — анализ дрейфа, выгрузка конфигурации или проверка по отдельному разрешению.

Стандарты как опора, а не как декорация

Ссылки на стандарты полезны ровно настолько, насколько помогают воспроизвести вывод или сравнить подрядчиков; перечень аббревиатур на титульном листе ничего не доказывает. Для IaC работают несколько источников, каждый на своём уровне.

NIST Cybersecurity Framework 2.0 полезен управленчески: целевой профиль описывает результаты, к которым стремится организация, и код проверяется на соответствие им, а не набору правил, случайно оказавшемуся в сканере. Тогда и отчётность для руководства говорит о результатах, а не о выводе инструментов.

OWASP Application Security Verification Standard задаёт проверяемые требования к техническим мерам защиты приложений, включая меры в окружении, на которые приложение опирается. Именно это окружение и описывает IaC. Для ASVS 5.0.0 проект рекомендует ссылаться на требования идентификаторами с версией, например v5.0.0-1.2.5, поскольку нумерация может меняться между выпусками. Это позволяет связать требование, зависящее от окружения, с конкретным модулем, который его реализует.

CWE даёт словарь первопричин. Группировка находок по классам — внедрение команд, обход каталогов, неверное назначение прав, раскрытие чувствительной информации — показывает, какие ошибки повторяются по всем репозиториям, и помогает исправлять класс, а не отдельный случай. Если в отчёте используется рейтинг вроде CWE Top 25, у него должен быть указан год выпуска.

Принципы CISA Secure by Design дают ориентир владельцам общих модулей: безопасность как свойство по умолчанию, а не опция, которую потребитель должен не забыть включить. А NIST SP 800-204D задаёт рамку для встраивания безопасности цепочки поставок в конвейеры CI/CD — она полезна, когда оценка выходит за пределы шаблонов к тому, как собираются и доставляются артефакты.

Отдельно о дисциплине версий. SP 800-115 датирован 2008 годом, а ASVS и рейтинги CWE обновляются. Ссылки без версий делают воспроизведение и сравнение через год неоднозначными, поэтому каждую ссылку стоит фиксировать с версией или годом — и не выдавать методический документ за требование закона.

Приоритеты: первопричины вместо счётчика находок

Количество находок — плохая мера качества оценки IaC. Если одно правило сработало у ста потребителей общего модуля, это одна общая первопричина и сто затронутых экземпляров: отчёт должен сгруппировать корень, но сохранить перечень потребителей, их экспозицию и состояние исправления. И наоборот, одна строка в описании конвейера, открывающая секреты заданиям из форков, может весить больше, чем весь остальной отчёт.

Поэтому находки группируют по первопричинам, а приоритет определяют по масштабу затронутых ресурсов, эксплуатируемости, последствиям и компенсирующим мерам. Дефекты в общих модулях и конвейерах, внешняя доступность и расширение прав — отдельные факторы такого решения. Отклонения от внутренней политики, которые не создают эксплуатируемого состояния, стоит показывать отдельной группой. SP 800-115 называет поиск уязвимостей и проверку соответствия разными целями, и в отчёте их стоит разделять: смешанный список размывает приоритеты, и команды начинают чинить то, что проще, а не то, что опаснее.

Самым ценным результатом оценки IaC может оказаться не длинный перечень, а укреплённый модуль или правило политики, после которых безопасная конфигурация становится вариантом по умолчанию. В этом и состоит практическое прочтение Secure by Design: решение о безопасности принимается один раз в модуле, а не повторяется в каждой команде. Если безопасное умолчание невозможно — например, потому что потребителям действительно нужны разные режимы, — небезопасный вариант должен требовать явного осознанного выбора, а не включаться молча, как в истории с public_read.

Компромиссы: блокировать, предупреждать или измерять

Автоматические проверки политик масштабируются на сотни репозиториев, но шумят. Без реестра исключений с владельцем, обоснованием и сроком временное исключение становится постоянным, а правило — фактически отключённым. Так в истории из начала статьи предупреждение сканера и прошло мимо всех.

Блокирующие проверки останавливают рискованные изменения, но могут тормозить поставку и провоцировать обходы. Рекомендательные сохраняют скорость, но зависят от того, прочитает ли кто-то предупреждение. Руководство CISA Safe Software Deployment делает акцент на процессе развёртывания с надёжными этапами тестирования и измерения. На практике это аргумент в пользу постепенности: сначала измерить, как ведёт себя правило и сколько ложных срабатываний оно даёт, затем перевести в блокирующий режим правила с высоким риском и низким шумом, а остальные оставить рекомендательными под контролем реестра исключений.

Ширина и глубина тоже конкурируют. Поверхностный проход по всем репозиториям находит типовые ошибки конфигурации, а глубокий анализ нескольких модулей идентификации, сети и хранения данных — ошибки проектирования, которые автоматизация пропускает. Разумный план направляет глубину туда, где выше переиспользование и чувствительность данных.

Наконец, разовая оценка и непрерывные защитные механизмы решают разные задачи. Первая даёт обоснованную исходную точку, вторые её удерживают. При закупке разовой оценки стоит заранее спросить, как исходные находки превратятся в устойчивые проверки, а не останутся PDF-файлом в почте.

Если вы сейчас решаете, что именно отдать на внешнюю проверку — несколько критичных модулей, конвейер применения изменений или весь каталог, — эти границы удобно обсудить заранее. На странице определения объёма пентеста можно описать репозитории, среды и ограничения, а Pentest.red поможет разобраться, какие методы и какие доказательства имеет смысл включить в работу.

Как принимать исправления и проводить повторную проверку

Находки в IaC должны превращаться в изменения кода с конкретным владельцем, а не в снимки экрана консоли. Если исправление внесено в общий модуль, работа не заканчивается слиянием: нужно отследить, какие потребители остались на старой версии, иначе исправление существует только в репозитории модуля.

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

Операционные метрики стоит выбрать заранее: доля модулей, проходящих согласованные политики, время устранения по уровням критичности, число просроченных исключений. Это рекомендуемые практики, а не эталонные значения; определять их стоит относительно собственного целевого профиля. Машиночитаемые списки требований ASVS позволяют помечать правила политики идентификаторами требований, а идентификаторы CWE — группировать находки по первопричинам.

Если в анализе участвуют инструменты на основе ИИ, их вывод должен проверить квалифицированный специалист до того, как он повлияет на устранение или отчётность: правдоподобное, но неверное объяснение, почему правило «безопасно», тиражируется так же легко, как ошибка в модуле.

Как выбрать подрядчика для оценки безопасности IaC

Сравнивать предложения бесполезно, если непонятно, что именно будет проверено. Помогают два документа для заказчиков: руководство CISA Secure by Demand, рассчитанное на переговоры с поставщиками ПО и услуг, и совместное руководство австралийского ASD's ACSC и CISA о выборе безопасных и проверяемых технологий. Оба удобны как каркас запроса предложений.

ASVS полезен и здесь: проект заявляет своей целью нормализовать охват и строгость услуг по верификации безопасности. Если попросить каждого подрядчика указать, какие требования и уровни он покрывает, — с идентификаторами и версией, — предложения становятся сопоставимыми.

Практические вопросы стоит задать до подписания. На какие версии стандартов подрядчик опирается и для чего каждый используется в методике? Как оформляются разрешение, правила работ и перечень разрешённых сред? Как защищаются и удаляются после проекта файлы состояния, секреты и вывод планов? Будут ли результаты в машиночитаемом виде, с привязкой к CWE и к идентификаторам требований с версией? Группируются ли находки по первопричинам, с исправлениями на уровне модулей? Входят ли в работу повторная проверка и помощь с защитными механизмами в конвейере?

Тревожные признаки тоже узнаваемы: отчёт, состоящий только из вывода сканера; ссылки на стандарты без версий; заявления о сертификатах, клиентах или результатах, которые нельзя проверить; готовность тестировать продуктивную среду без письменного согласия. Последнее — достаточное основание для отказа. И помните, что пентест или оценка безопасности — не сертификация и не аттестация: это техническое заключение о рисках, найденных на момент проверки в согласованных границах, а не гарантия их отсутствия.

Выбор между своими силами и внешним подрядчиком зависит от зрелости и требований к независимости. Команда с налаженным policy-as-code может сама вести непрерывные проверки, а внешняя оценка полезна для первой исходной точки, перед рискованными изменениями архитектуры и там, где независимости требует политика или договор. Один из вариантов — гибридная модель: внешняя исходная оценка и глубокий разбор критичных модулей, затем внутренние защитные механизмы и периодические внешние повторные проверки. Если такой формат вам ближе, его можно обсудить с Pentest.red в рамках услуг по тестированию на проникновение: какие модули и конвейеры войдут в исходную оценку, какие доказательства вы получите и как будет устроена повторная проверка.

Заключение: чтобы оценка IaC оставалась полезной после отчёта

Оценка безопасности инфраструктуры как кода — не запуск сканера по репозиторию, а техническая проверка по логике NIST SP 800-115, применённая к шаблонам, модулям и конвейерам. Она измеряет код относительно целевых результатов организации, группирует находки по первопричинам и определяет приоритет по риску и добивается безопасных умолчаний вместо бесконечного поиска одних и тех же ошибок.

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