Практический DevSecOps при защите контейнерной инфраструктуры

DevSecOps, Shift Left, Container Security – модные слова, за которыми должна стоять реальная практика. Давайте рассмотрим, что делать "в поле", чтобы повысить защищенность, а не просто следовать трендам?

Автор: Максим Ксенофонтов, эксперт по защите контейнерных сред и оркестраторов, “Лаборатория Касперского”

Немного про термины

В центре нашего внимания – безопасная разработка и защита инфраструктуры, связанной с контейнерной средой и системами оркестрации. Под контейнерами мы будем понимать стандартные образы формата OCI или Docker, предназначенные для изолированного выполнения приложений в рамках Container Runtime Interface (CRI).

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

Зато в DevSecOps без этого никуда. Здесь требуются специалисты, которые одинаково хорошо ориентируются в коде, CI/CD-конвейерах, контейнерах, сетях, СУБД и системах контроля версий. Такой набор компетенций редко встречается у классических офицеров ИБ – чаще с задачами справляются профильные DevOps- или DevSecOps-инженеры. Помочь удержать все в фокусе призваны инструменты автоматизации: SAST и DAST решают задачи анализа кода, SCM-решения следят за цепочкой поставок, а платформы контейнерной безопасности берут на себя контроль уже развернутой инфраструктуры.

У контейнеров есть свой жизненный цикл. Он состоит из трех этапов, для каждого из которых есть свои риски и свои способы защиты:

1. Управление кодом и хранение образов в реестрах.
2. Сборки образов и их развертывание (CI/CD).
3. Работа запущенных образов в средах контейнеризации и оркестрации.

Управление кодом и хранение образов в реестрах

Реестры – это централизованное хранилище образов, и их компрометация может привести к заражению всей инфраструктуры. Они бывают приватные (например, 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).

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

Рис. 1. Пример опасного образа в реестре в Kaspersky Container Security

Безопасность 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-конвейера можно выделить следующие основные риски:

• подмена базового образа перед сборкой и подмена собранного (child) образа перед деплоем;
• встраивание вредоносного ПО или ПО с эксплуатируемыми уязвимостями в код или в собираемые компоненты в образе;
• несанкционированный доступ к секретам (пароли, ключи, токены и пр.) в случае хранения их в репозитории в открытом виде.

Для закрытия данных рисков можно реализовать следующие меры:

• подписывать базовый и дочерний образы, например в системах Cosign или Notary;
• анализировать импортируемые библиотеки и их поведения в динамике с использованием решений класса SAST/DAST;
• фиксировать версии базового образа и отказаться от использования latest-версий;
• отслеживать цепочку поставок для добавляемых библиотек с использованием Supply Chain Management-систем;
• проверять собранные дочерние образы на вредоносные файлы, секреты, ошибки конфигурации и уязвимости с использованием систем контейнерной безопасности;
• хранить секреты либо во встроенных хранилищах секретов CI/CD, либо во внешних Vault-системах;
• использовать решения для контроля CI/CD-конвейера на обязательные шаги (например, проверки безопасности) и соответствие лучшим практикам с помощью таких инструментов, как Quality Gate, Open Policy Agent (OPA) / Rego и пр.

Рис. 2. Пример сканирования образа в CI/CD-конвейере. Источник: Kaspersky Container Security

Контроль безопасности в CRI и оркестраторах

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

Контейнеры несут два типа рисков:

• при запуске – уязвимые или вредоносные образы, секреты и ошибки в конфигурациях (манифесты, Compose-файлы);
• в рантайме – сетевые атаки, запуск вредоносного ПО, эксплуатация уязвимостей, эскалация прав и нелегитимный доступ к данным.

В связи с этим меры защиты также делятся на два сценария:

• контроль запуска контейнеров и подов, например с помощью Admission Controller в случае использования оркестратора;
• контроль уже работающих контейнеров и подов.

Для первого сценария можно предложить следующие конкретные меры:

• контролировать выполнение различных Best Practice для IoC при запуске подов;
• контролировать контекст безопасности в манифесте до запуска пода: отличный перечень рекомендаций есть в справке для Kubernetes [1];
• контролировать реестр, из которого скачивается образ;
• l запускать только безопасные образы, то есть те, которые признаны безопасными согласно вашей политике безопасности образов;
• использовать подписи или контроль хеша при запуске пода, чтобы исключить подмену образа.

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

Для защиты запущенных подов можно реализовать следующие меры защиты:

• контролировать файловую систему контейнера/пода на вредоносную активность: в контейнер может попасть вредоносный файл (особенно если он создан для работы с файлами, например веб-сервер);
• контролировать доступ к файловой системе и отслеживать возможный доступ к конфиденциальной информации внутри контейнера;
• контролировать сетевые взаимодействий с помощью Network Policy или механизма eBPF;
• контролировать запуск исполняемых файлов внутри контейнера с использованием eBPF или других механизмов.

Защита рантайма и запущенных подов является более сложной задачей в техническом и организационном плане, поэтому и доступных для использования систем автоматизации значительно меньше. Для реализации части мер можно использовать, например, Falco. Защита сети может быть закрыта CNI-системами. Но для реализации всех мер защиты в одном решении лучшей практикой будет использование специализированных систем, например Kaspersky Container Security.

Итоги

Контейнеризация и оркестрация – относительно новые области ИТ, со своими рисками и требованиями к безопасности. На старте экосистему защищали в основном Open Source-инструменты, созданные самими разработчиками. Со временем появились зрелые коммерческие продукты, такие как Aqua Security, Palo Alto Prisma Cloud и Kaspersky Container Security.

Вендорские решения предлагают комплексный подход: встроенные лучшие практики, регулярные обновления, техподдержку и развитие функциональности. Это снижает нагрузку на команду и повышает отдачу от инвестиций в ИБ. С учетом санкционных рисков Open Source-подходы становятся все менее жизнеспособны, а отечественные решения с продуманным интерфейсом позволяют эффективно работать даже без глубокой технической подготовки.

1. https://kubernetes.io/docs/tasks/configure-pod-container/security-context/