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

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

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

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

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

Как и почему злоумышленники нацеливаются на трубопроводы

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

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

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

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

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

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

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

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

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

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

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

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

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