Инфраструктура как код (IaC), несомненно, меняет подход инженеров к облаку. IaC в сочетании с инструментами разработки и автоматизацией открывает новые возможности для повышения производительности инфраструктуры, масштабируемости, а теперь и безопасности.

Встраивая элементы управления безопасностью и соответствием IaC в свои системы контроля версий и конвейеры CI/CD, вы можете раньше начать выявлять и исправлять ошибки. Но чтобы сделать это, не нарушая работу, жизненно важно разработать стратегию, чтобы определить, где и как применять меры безопасности для достижения ваших целей, не замедляя работу ваших разработчиков, от экспериментов до управления вашей стратегией.

В этом посте будет описан технический процесс разработки и построения внутренней стратегии безопасности IAC.

Каковы ваши цели безопасности инфраструктуры?

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

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

Какие политики вы хотите внедрить и как?

Ваша программа обеспечения безопасности инфраструктуры сильно зависит от приоритетов безопасности и зрелости вашей организации, и вам следует читать это руководство с учетом ваших уникальных потребностей.

Если вы хотите улучшить общее состояние облачной безопасности, вы можете поискать способы применения общих рамок политик безопасности, таких как Центр интернет-безопасности. Некоторые сканеры безопасности с открытым исходным кодом, такие как Checkov или Open Policy Agent (OPA), применяют политику как код на уровне IaC.

Обычно они представляют собой автономные упакованные контейнеры, определенные для приема файла, каталога, репозитория, ветки и т. д., и выводят результаты сканирования в машиночитаемом формате, таком как JSON или JUnit XML. Наиболее существенное преимущество использования сканера с открытым исходным кодом заключается в том, что они предварительно упаковывают ценную логику тестирования безопасности, которую вашим разработчикам не придется изучать.

Альтернативой сканеру является полнофункциональный продукт безопасности, желательно с открытыми API и источниками интеграции веб-перехватчиков. Большинство решений для обеспечения безопасности, разработанных в первую очередь для разработчиков, сделали эту часть тяжелой работы, поэтому вы должны получить некоторые из них «из коробки».

Если вам необходимо внедрить внешние средства контроля, такие как отраслевые эталоны или требования соответствия нормативным требованиям, вам потребуется более структурированный подход, который сопоставляет отдельные проверки с желаемыми результатами. Многие облачные провайдеры включают надежные отчеты о соответствии стандартам для стандартных эталонных тестов, таких как HIPAA, NIST, PCI-DSS и т. д. Убедитесь, что ваш подход к обеспечению соблюдения политик позволяет вам создавать собственные политики, чтобы вы также могли применять эти элементы управления.

Где следует применять политики инфраструктуры?

У каждой из ваших команд, вероятно, есть свои уникальные платформы и процессы, и важно иметь полное представление о местности, прежде чем погрузиться в нее. Начните с простого упражнения по сопоставлению и перечислите все используемые платформы конфигурации — из CloudFormation или Azure Resource Manager. (ARM) в Terraform или Pulumi.

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

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

  • Что запускает сборку CI/CD?
  • Работают ли ваши текущие автоматизированные усилия по обеспечению качества непрерывно при каждом новом запросе на вытягивание и коммите?
  • Выполняются ли более трудоемкие тесты, такие как тесты интеграции, с менее чем непрерывными интервалами, например, каждую ночь, или только в ветвях в соответствии с определенными соглашениями об именах?
  • Проверяют ли разработчики свою работу локально перед фиксацией?
  • Сколько конвейеров CI/CD используется?

Как и где вы реализуете сканирование безопасности, будет зависеть от этих процессов и инструментов, используемых для их выполнения. Основываясь на вашей текущей настройке, вы, как правило, захотите использовать один из двух подходов к безопасности IaC — использование процессов CI/CD или встроенных функций вашей системы контроля версий (VCS).

Подход №1: конвейер CI/CD

Построение элементов управления безопасностью как части конвейеров CI/CD, вероятно, является более простым из двух подходов, потому что современные инструменты CI/CD полностью абстрагируются от сложностей, лежащих в основе оркестровки тестовой логики.

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

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

Подход №2: Система контроля версий

Выбранная вами система контроля версий (VCS) также скрывает некоторые надежные внутренние элементы управления безопасностью. Помимо добавления отдельных возможностей автоматизации, все три платформы, которые в настоящее время доминируют на рынке (GitHub, GitLab и Bitbucket), предлагают встроенные средства проверки кода и авторизации, которые можно использовать для лучшего контроля того, кто может что и где менять.

Благодаря своим собственным версиям и ветвлениям разработчики могут выполнять обширное тестирование без ущерба для какой-либо работающей производственной системы и продолжать совместную работу и общение, прежде чем вносить изменения в связи с тестированием.

Внедрение здесь защиты инфраструктуры дает некоторые преимущества с точки зрения более детального доступа и контроля. Два из наиболее распространенных способов сделать это используют стандартный процесс проверки запросов на вытягивание (PR):

  • PR-аннотации: начните с простого, выбрав путь наименьшего сопротивления. Используя стандартный веб-хук или API-интерфейс, вы можете начать с сканирования каждого PR и аннотирования его результатов конкретными советами по безопасному кодированию. Преимущество аннотации в том, что она не вызывает трения. Разработчики могут принять или проигнорировать его — небольшое разочарование, но, с другой стороны, не так много управления.
  • Проверки. С добавлением встроенной непрерывной интеграции на большинство платформ git вы всегда можете включить в git стандартный конвейер непрерывной интеграции. Основным преимуществом является включение сканирования, подобного CI, как части каждого отдельного PR. Он выдает такой же результат на более ранней стадии и позволяет разработчикам реагировать до того, как на самом деле произойдет сбой сборки в конвейере.

Как вы должны обеспечить безопасность вывода?

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

Определите, насколько пассивными или активными должны быть выходные данные ваших элементов управления безопасностью. Должен ли он активно блокировать сборку или предоставлять пассивную обратную связь для решения некоторых заранее определенных SLA?

Некоторые сканеры могут даже дополнительно интегрироваться в конвейеры и управлять более сложными действиями, такими как блокировка завершения сборки до завершения тестирования. Сканирование в CI обычно должно было быть пассивным; он не был создан для интерактивного тестирования и устранения неполадок. Должен ли конвейер разработки содержать ответы на сложные вопросы, на которые необходимо ответить при устранении ошибки безопасности или нарушения соответствия?

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

В дополнение к ранее упомянутым преимуществам привязки вашей стратегии безопасности IaC к вашей VCS, в git есть более тонкие элементы управления, такие как:

  • Правила утверждения. С помощью системы контроля версий вы можете определить, сколько утверждений и запросов на вытягивание необходимо, прежде чем их можно будет объединить. Некоторые даже позволяют вам выбрать, какими именно пользователями они должны быть.
  • Владельцы кода. Если у вас есть доступ администратора к вашему основному репозиторию, рассмотрите возможность использования параметров CODEOWNERS, чтобы определить более строгий протокол утверждения для более конфиденциальных файлов.

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

Вывод

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