Журнал "Information Security/ Информационная безопасность" #3, 2025

Немного про термины В центре нашего внимания – безопас- ная разработка и защита инфраструкту- ры, связанной с контейнерной средой и системами оркестрации. Под контей- нерами мы будем понимать стандартные образы формата 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 и пр.). У каждой категории – свой набор рисков: l для приватных реестров основной угрозой остаются слабый или отсут- ствующий RBAC, непроверенные обра- зы, риск подмены и захламление уста- ревшими версиями. l для публичных – тайпсквотинг (имена- двойники популярных образов), вредо- носные или уязвимые образы, а также санкционные риски. Вот некоторые базовые практические рекомендации, которые помогут снизить эти риски: l никакого анонимного доступа – использование аутентификации и авто- ризации для реестров снизит риски под- мены образа, а также несанкциониро- ванного доступа к образам; l правильно выстроить ролевую модель доступа с разделением прав: например, разработчикам можно выдать права только на pull, команде DevOps – push/pull, команде безопасности – sign; l настроить интеграцию реестра с системами управления пользователей по LDAP или OAuth2/OIDC; l проводить регулярное сканирование образов на уязвимости, вредоносы, ошибки и секреты с помощью Trivy или отечественных решений, например Kaspersky Container Security; l хранить все критичные образы во внут- реннем реестре – проксирование удобно, но не спасет при санкционных рисках и недоступности внешних источников; l зафиксировать версии используемых образов: не использовать latest или образы без тега, иначе однажды в lat- est-версии образа может оказаться совсем не то, что ожидалось; l подписывать образы с помощью Open Source-решений, например Notary или Cosign. l настроить политику хранения образов в реестре, удаляющую неиспользуемые образы (например, через Artifactory Clea- nup Policy). Следование этим рекомендациям помо- жет снизить риски на первом этапе жиз- ненного цикла контейнеров. Но применять их стоит только после комплексного аудита, 66 • ТЕХНОЛОГИИ Практический DevSecOps при защите контейнерной инфраструктуры evSecOps, Shift Left, Container Security – модные слова, за которыми должна стоять реальная практика. Давайте рас- смотрим, что делать "в поле", чтобы повысить защищенность, а не просто следовать трендам? D Максим Ксенофонтов, эксперт по защите контейнерных сред и оркестраторов, “Лаборатория Касперского” Рис. 1. Пример опасного образа в реестре в Kaspersky Container Security Фото: Лаборатория Касперского