Максим Ксенофонтов
Практический DevSecOps при защите контейнерной инфраструктуры.
DevSecOps, Shift Left, Container Security – модные слова, за которыми должна стоять реальная практика. Давайте рассмотрим, что делать "в поле", чтобы повысить защищенность, а не просто следовать трендам?
Немного про термины
В центре нашего внимания – безопасная разработка и защита инфраструктуры, связанной с контейнерной средой и системами оркестрации. Под контейнерами мы будем понимать стандартные образы формата OCI или Docker, предназначенные для изолированного выполнения приложений в рамках Container Runtime Interface (CRI).
DevSecOps вырос из DevOps как ответ на необходимость встроенной безопасности в разработку. Со временем вопросы защиты инфраструктуры и эксплуатации оформились в самостоятельное направление – SecOps, где знание программирования уже не критично.
Зато в DevSecOps без этого никуда. Здесь требуются специалисты, которые одинаково хорошо ориентируются в коде, CI/CD-конвейерах, контейнерах, сетях, СУБД и системах контроля версий. Такой набор компетенций редко встречается у классических офицеров ИБ – чаще с задачами справляются профильные DevOps- или DevSecOps-инженеры. Помочь удержать все в фокусе призваны инструменты автоматизации: SAST и DAST решают задачи анализа кода, SCM-решения следят за цепочкой поставок, а платформы контейнерной безопасности берут на себя контроль уже развернутой инфраструктуры.
У контейнеров есть свой жизненный цикл. Он состоит из трех этапов, для каждого из которых есть свои риски и свои способы защиты:
DevSecOps вырос из DevOps как ответ на необходимость встроенной безопасности в разработку. Со временем вопросы защиты инфраструктуры и эксплуатации оформились в самостоятельное направление – SecOps, где знание программирования уже не критично.
Зато в DevSecOps без этого никуда. Здесь требуются специалисты, которые одинаково хорошо ориентируются в коде, CI/CD-конвейерах, контейнерах, сетях, СУБД и системах контроля версий. Такой набор компетенций редко встречается у классических офицеров ИБ – чаще с задачами справляются профильные DevOps- или DevSecOps-инженеры. Помочь удержать все в фокусе призваны инструменты автоматизации: SAST и DAST решают задачи анализа кода, SCM-решения следят за цепочкой поставок, а платформы контейнерной безопасности берут на себя контроль уже развернутой инфраструктуры.
У контейнеров есть свой жизненный цикл. Он состоит из трех этапов, для каждого из которых есть свои риски и свои способы защиты:
- Управление кодом и хранение образов в реестрах.
- Сборки образов и их развертывание (CI/CD).
- Работа запущенных образов в средах контейнеризации и оркестрации.
1
Управление кодом и хранение образов в реестрах
Реестры – это централизованное хранилище образов, и их компрометация может привести к заражению всей инфраструктуры. Они бывают приватные (например, Harbor, Nexus, JFrog и т. д.) и публичные (Docker Hub, GitHub Container Registry и пр.). У каждой категории – свой набор рисков:
Вот некоторые базовые практические рекомендации, которые помогут снизить эти риски:
- для приватных реестров основной угрозой остаются слабый или отсутствующий RBAC, непроверенные образы, риск подмены и захламление устаревшими версиями.
- для публичных – тайпсквотинг (именадвойники популярных образов), вредоносные или уязвимые образы, а также санкционные риски.
Вот некоторые базовые практические рекомендации, которые помогут снизить эти риски:
- никакого анонимного доступа – использование аутентификации и авторизации для реестров снизит риски подмены образа, а также несанкционированного доступа к образам;
- правильно выстроить ролевую модель доступа с разделением прав: например, разработчикам можно выдать права только на pull, команде DevOps – push/pull, команде безопасности – sign;
- настроить интеграцию реестра с системами управления пользователей по LDAP или OAuth2/OIDC;
- проводить регулярное сканирование образов на уязвимости, вредоносы, ошибки и секреты с помощью Trivy или отечественных решений, например Kaspersky Container Security;
- хранить все критичные образы во внутреннем реестре – проксирование удобно, но не спасет при санкционных рисках и недоступности внешних источников;
- зафиксировать версии используемых образов: не использовать latest или образы без тега, иначе однажды в latest-версии образа может оказаться совсем не то, что ожидалось;
- подписывать образы с помощью Open Source-решений, например Notary или Cosign.
- настроить политику хранения образов в реестре, удаляющую неиспользуемые образы (например, через Artifactory Cleanup Policy).
«Следование этим рекомендациям поможет снизить риски на первом этапе жизненного цикла контейнеров. Но применять их стоит только после комплексного аудита, постепенно и осознанно, чтобы не нарушить выстроенные процессы разработки»
Максим Ксенофонтов
Технический директор "Смартехснаб"
2
Безопасность CI/CD-конвейера
CI/CD-конвейер автоматизирует сборку и доставку: здесь компилируется код, формируются образы, запускается развертывание в CRI и выполняются основные проверки безопасности. Однако стоит помнить: полноправный владелец этого процесса – DevOps-инженер. Он может обойти любую неуспешную проверку безопасности просто дописав в строке запуска сканирования "ignore_errors: true" или "|| true".
Это значит, что если безопасность целиком завязана на CI/CD, она становится ненадежной. Оптимальный подход – двухуровневый контроль: первичные проверки безопасности можно проводить в CI/CD, но результаты этих проверок необходимо хранить снаружи или делать дополнительную проверку.
Такой подход реализован, например, в Kaspersky Container Security: сканирование запускается в CI/CD, но результаты сохраняются вне конвейера – в Kaspersky Container Security. Перед развертыванием в оркестраторе KCS повторно проверяет образ на соответствие политикам, что снижает риски обхода.
Для CI/CD-конвейера можно выделить следующие основные риски:
Для закрытия данных рисков можно реализовать следующие меры:
Это значит, что если безопасность целиком завязана на CI/CD, она становится ненадежной. Оптимальный подход – двухуровневый контроль: первичные проверки безопасности можно проводить в CI/CD, но результаты этих проверок необходимо хранить снаружи или делать дополнительную проверку.
Такой подход реализован, например, в Kaspersky Container Security: сканирование запускается в CI/CD, но результаты сохраняются вне конвейера – в Kaspersky Container Security. Перед развертыванием в оркестраторе KCS повторно проверяет образ на соответствие политикам, что снижает риски обхода.
Для CI/CD-конвейера можно выделить следующие основные риски:
- подмена базового образа перед сборкой и подмена собранного (child) образа перед деплоем;
- встраивание вредоносного ПО или ПО с эксплуатируемыми уязвимостями в код или в собираемые компоненты в образе;
- несанкционированный доступ к секретам (пароли, ключи, токены и пр.) в случае хранения их в репозитории в открытом виде.
Для закрытия данных рисков можно реализовать следующие меры:
- подписывать базовый и дочерний образы, например в системах Cosign или Notary;
- анализировать импортируемые библиотеки и их поведения в динамике с использованием решений класса SAST/DAST;
- фиксировать версии базового образа и отказаться от использования latest-версий;
- отслеживать цепочку поставок для добавляемых библиотек с использованием Supply Chain Management-систем;
- проверять собранные дочерние образы на вредоносные файлы, секреты, ошибки конфигурации и уязвимости с использованием систем контейнерной безопасности;
- хранить секреты либо во встроенных хранилищах секретов CI/CD, либо во внешних Vault-системах;
- использовать решения для контроля CI/CD-конвейера на обязательные шаги (например, проверки безопасности) и соответствие лучшим практикам с помощью таких инструментов, как Quality Gate, Open Policy Agent (OPA) / Rego и пр.
3
Контроль безопасности в CRI
и оркестраторах
и оркестраторах
Если на этапах сборки и развертывания мы имеем дело со статичными образами, то в рантайме появляются уже "живые" сущности – контейнеры и поды. Их нужно защищать так же, как и обычные хосты, включая мониторинг в реальном времени. Контейнер, пусть даже минимальный, ведет себя как полноценная виртуальная машина: у него есть сеть, файловая система, память, CPU и консоль. Внутрь можно установить как системное, так и прикладное ПО – и все это нуждается в контроле.
Контейнеры несут два типа рисков:
В связи с этим меры защиты также делятся на два сценария:
Для первого сценария можно предложить следующие конкретные меры:
Для защиты запущенных подов можно реализовать следующие меры защиты:
Защита рантайма и запущенных подов является более сложной задачей в техническом и организационном плане, поэтому и доступных для использования систем автоматизации значительно меньше. Для реализации части мер можно использовать, например, Falco. Защита сети может быть закрыта CNI-системами. Но для реализации всех мер защиты в одном решении лучшей практикой будет использование специализированных систем, например Kaspersky Container Security.
Контейнеры несут два типа рисков:
- при запуске – уязвимые или вредоносные образы, секреты и ошибки в конфигурациях (манифесты, Compose-файлы);
- в рантайме – сетевые атаки, запуск вредоносного ПО, эксплуатация уязвимостей, эскалация прав и нелегитимный доступ к данным.
В связи с этим меры защиты также делятся на два сценария:
- контроль запуска контейнеров и подов, например с помощью Admission Controller в случае использования оркестратора;
- контроль уже работающих контейнеров и подов.
Для первого сценария можно предложить следующие конкретные меры:
- контролировать выполнение различных Best Practice для IoC при запуске подов;
- контролировать контекст безопасности в манифесте до запуска пода: отличный перечень рекомендаций есть в справке для Kubernetes [1];
- контролировать реестр, из которого скачивается образ;
- запускать только безопасные образы, то есть те, которые признаны безопасными согласно вашей политике безопасности образов;
- использовать подписи или контроль хеша при запуске пода, чтобы исключить подмену образа.
Для защиты запущенных подов можно реализовать следующие меры защиты:
- контролировать файловую систему контейнера/пода на вредоносную активность: в контейнер может попасть вредоносный файл (особенно если он создан для работы с файлами, например веб-сервер);
- контролировать доступ к файловой системе и отслеживать возможный доступ к конфиденциальной информации внутри контейнера;
- контролировать сетевые взаимодействий с помощью Network Policy или механизма eBPF;
- контролировать запуск исполняемых файлов внутри контейнера с использованием eBPF или других механизмов.
Защита рантайма и запущенных подов является более сложной задачей в техническом и организационном плане, поэтому и доступных для использования систем автоматизации значительно меньше. Для реализации части мер можно использовать, например, Falco. Защита сети может быть закрыта CNI-системами. Но для реализации всех мер защиты в одном решении лучшей практикой будет использование специализированных систем, например Kaspersky Container Security.
Итоги
Контейнеризация и оркестрация – относительно новые области ИТ, со своими рисками и требованиями к безопасности. На старте экосистему защищали в основном Open Source-инструменты, созданные самими разработчиками. Со временем появились зрелые коммерческие продукты, такие как Aqua Security, Palo Alto Prisma Cloud и Kaspersky Container Security.
Вендорские решения предлагают комплексный подход: встроенные лучшие практики, регулярные обновления, техподдержку и развитие функциональности. Это снижает нагрузку на команду и повышает отдачу от инвестиций в ИБ. С учетом санкционных рисков Open Source-подходы становятся все менее жизнеспособны, а отечественные решения с продуманным интерфейсом позволяют эффективно работать даже без глубокой технической подготовки.
Вендорские решения предлагают комплексный подход: встроенные лучшие практики, регулярные обновления, техподдержку и развитие функциональности. Это снижает нагрузку на команду и повышает отдачу от инвестиций в ИБ. С учетом санкционных рисков Open Source-подходы становятся все менее жизнеспособны, а отечественные решения с продуманным интерфейсом позволяют эффективно работать даже без глубокой технической подготовки.
