Защита среды платформы DevOps для нулевого доверия

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

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

На приведенной ниже схеме обратите внимание, что среда платформы DevOps подключается к среде приложения и к расширениям конвейера непрерывной доставки и непрерывной доставки (CI/CD).

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

Как и почему злоумышленники нацеливает конвейеры

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

В то время как злоумышленники находят новые способы компрометации систем, наиболее распространенные векторы атак для конвейеров включают:

• Извлечение переменных среды выполнения и внедрения аргументов.
• Скрипты, которые извлекают принципы службы или учетные данные из конвейеров.
• Неправильно настроены личные маркеры доступа, позволяющие любому пользователю с ключом получить доступ к среде платформы DevOps.
• Уязвимости и неправильные настройки в сторонних интегрированных инструментах, требующих доступа к коду (часто доступны только для чтения, но иногда и для записи). Интегрированные средства могут включать платформы тестирования, статическое тестирование безопасности приложений (SAST) и динамическое тестирование безопасности приложений (DAST).

Рекомендации по управлению секретами и сертификатами

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

Как показано на приведенной выше схеме, разработчик запускает сборку для запроса клиента. Затем GitHub запускает бегун с идентификатором роли приложения Хранилища и идентификатором секрета. Доверенный объект периодически запрашивает новый идентификатор секрета из хранилища и получает идентификатор секрета GitHub из GitHub. Хранилище использует идентификатор роли GitHub Secret и секретный идентификатор для входа и получения ресурсов подписывания кода. Runner настраивает и подписывает мобильное приложение.

Следующие рекомендации помогут вам создать безопасную настройку, которая сводит к минимуму воздействие секретов и параметров.

• Обеспечение безопасного хранилища для секретов и сертификатов на каждом этапе жизненного цикла приложения. Всегда разрабатывать, как если бы это проект с открытым исходным кодом. Убедитесь, что команды хранят секреты в хранилищах ключей, а не в коде или в средах команд. Используйте облачную службу Azure Key Vault для безопасного хранения и доступа к секретам.
• Настройте Azure для доверия OIDC OIDC GitHub в качестве федеративного удостоверения. OpenID Подключение (OIDC) позволяет рабочим процессам GitHub Actions получать доступ к ресурсам в Azure без необходимости хранить учетные данные Azure в виде секретов GitHub.

Дополнительные рекомендации по обеспечению безопасности среды DevOps

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

• Обустраивайте каждую среду платформы DevOps с помощью следов аудита.Просмотрите журналы аудита, чтобы отслеживать , кто получил доступ, какие изменения произошли, и дату и время для любой активной системы. В частности, включают платформы DevOps с конвейерами CI/CD, которые будут поступать в рабочую среду. Тропы аудита для средств DevOps предоставляют надежные способы устранения угроз быстрее, найти и предупредить о подозрительных действиях, чтобы устранить возможные нарушения или уязвимости, а также найти потенциальные данные или неправильное использование привилегий. Убедитесь, что в каждой среде доступны детализированные результаты управления и аудита.
• Защитите цепочку поставок программного обеспечения. При каждом вводе библиотеки в базу кода вы расширяете цепочку поставок программного обеспечения и наследуете зависимости от каждого проекта или средства с открытым исходным кодом. С осторожностью удалите ненужные библиотеки и компоненты с открытым исходным кодом, чтобы уменьшить область атак в цепочке поставок программного обеспечения.
• Автоматизация сканирования шаблонов infrastructure-as-Code (IaC). В средах IaC можно легко проверять неправильно настроенные конфигурации, аудит соответствия требованиям и проблемы политик. Реализация проверка соответствия требованиям и средств управления доступом повышает уровень безопасности всей инфраструктуры. Проверьте безопасность сторонних средств интеграции, которые соответствуют требованиям системы автоматизации.
• Автоматизация рабочих процессов утверждения. Для любого рабочего процесса утверждения для отправки кода в рабочую среду некоторые автоматические или вручную проверка должны подтвердить безопасность, бизнес-ценность, состояние и качество каждого запроса. Эти проверка работают в качестве шлюза между разработкой и рабочей средой, чтобы предотвратить атаки типа "отказ в обслуживании" и хакеры внедряют код в рабочие среды без добавления тегов или активации оповещения.
• Разрешить только проверенные интеграции средств DevOps. Как и в средах разработчиков, средства DevOps поставляются с расширениями и интеграцией, чтобы сделать команду DevOps эффективной и безопасной. Убедитесь, что проверенные интеграции требуют минимальных привилегий для выполнения своей работы. Реализуйте минимальные привилегии, когда это возможно, и убедитесь, что правильный уровень разрешений на чтение и запись. Узнайте, как отключить или ограничить действия GitHub для вашей организации.

Следующие шаги

• Защита среды разработчика помогает реализовать принципы нулевого доверия в средах разработки с рекомендациями по наименьшей привилегии, безопасности ветви и доверия средствам, расширениям и интеграции.
• Внедрение безопасности нулевого доверия в рабочий процесс разработчика помогает быстро и безопасно внедрять инновации.
• Защита сред DevOps для Нулевого доверия описывает рекомендации по защите сред DevOps с помощью подхода "Нулевое доверие" для предотвращения взлома хакеров в полях разработчиков, заражая конвейеры выпуска вредоносными сценариями и получая доступ к рабочим данным через тестовые среды.
• Реализуйте принципы нулевого доверия, как описано в меморандуме 22-09 (в поддержку исполнительного указа США 14028 года, улучшения кибербезопасности страны) с помощью Идентификатора Microsoft Entra в качестве централизованной системы управления удостоверениями.
• Ускорьте и защитите код с помощью Azure DevOps с помощью средств, которые предоставляют разработчикам самый быстрый и безопасный код для облачного интерфейса.