Защита контейнерной инфраструктуры в российских организациях: полный гид

Кратко о терминологии и инструментах

Контейнер – это изолированная среда для запуска одного приложения, создаваемая средствами на уровне ядра ОС.

Образ контейнера – готовый к запуску пакет ПО, содержащий всё необходимое для работы приложения: код, библиотеки, а также нужные настройки. Наиболее распространённым инструментом для хранения образов контейнеров является Docker.

Реестр образов — частный или публичный сервер, хранящий эталонные образы контейнеров. Среди публичных реестров отметим Docker Hub, Harbor, GitHub container registry, JFrog Container Registry, Amazon ECR, Azure ACR.

Среда исполнения контейнера — программа, предназначенная для запуска контейнера. Оркестратор — система управления жизненным циклом выполнения контейнеров, поддерживающая их взаимосвязь, распределение ресурсов, масштабирование и другие процессы. Самые популярные среды оркестрации — Kubernetes, Red Hat OpenShift и Docker Swarm.

Преимущества контейнеризации

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

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

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

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

Роль контейнеризации в современной микросервисной разработке

Крупные приложения, особенно для веба, разрабатываются в микросервисной архитектуре: отдельные функции приложения выделяются в микросервисы, которые коммуницируют между собой по API. Примером может служить сервис аутентификации, оплаты на веб-сайте.

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

Контейнеры прекрасно вписались в современную методологию непрерывной интеграции и развертывания (CI/CD, continuous integration, continuous delivery), помогающую выпускать обновления приложений быстрее и с меньшим числом ошибок. Этот подход предусматривает короткий цикл разработки, параллельную работу команд над одним кодом, автоматизацию рутинных действий. Применение контейнеризации в конвейере CI/CD тоже повышает эффективность этого конвейера: система CI/CD использует образы контейнеров в качестве шаблонов и доставляет сборку в виде готового к разворачиванию образа.

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

Ключевые угрозы для контейнерной инфраструктуры

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

Систематический обзор угроз можно изучить в NIST Special Publication 800-190 (Application Container Security Guide), но для простоты приведём немного сокращённый перевод в таблице ниже. Угрозы в ней разделены по компонентам системы контейнеризации.

Угрозы из этой таблицы, увы, не гипотетические. Например, вредоносное ПО неоднократно встречалось в Docker Hub (в самом массовом случае были заражены более 1600 образов), а рекордный срок нахождения ВПО в реестре достигал года. Известны вредоносные кампании, использующие Docker API для создания дополнительных контейнеров и майнинга на атакованных системах.

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

Также разработчики систематически забывают в контейнерах приватные API-ключи и другие секреты.

Кибербезопасность контейнеров: индивидуальный подход

Требования по защите контейнерной инфраструктуры описаны в приказе ФСТЭК России от 4 июля 2022 г. N 118. Из документа очевидно, что для орекестраторов и реестров образов требуются специфические меры защиты, а традиционные инструменты во многом не подходят для задач контейнерной безопасности.

Например, системы защиты виртуальных машин не могут обеспечить защиту контейнерных сред из-за особенностей архитектуры, в контейнере нет ОС. Защитные решения EDR уровня хоста и сканеры уязвимостей не способны глубоко анализировать происходящее внутри контейнеров, а межсетевые экраны и WAF «не замечают» межконтейнерный трафик, поскольку он проходит в виртуальной сети на уровне оркестратора мимо сетевых интерфейсов хоста.

Для эффективной защиты недостаточно обеспечить «видимость» в контейнерной среде. Защитному решению для контейнерных сред нужно решать множество дополнительных задач – управлять правами и ресурсами, выделенными контейнеру с учётом его функций, предотвращать запуск недоверенных контейнеров, запрещать опасные конфигурации оркестратора, контролировать соответствие образов принятым ИБ-политикам и так далее.

Частично эта задача решается встроенными средствами безопасности того же Kubernetes. В нём можно управлять квотами ресурсов и ролями пользователей, обеспечить детальное логирование в контейнерной среде. Некоторые другие задачи решаются точечными open source решениями, например соответствие контейнеров лучшим практикам можно проверять при помощи Docker Bench, а искать в них уязвимости при помощи Clair.

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

Отдельной задачей будет соблюдение регуляторных требований – практически нет встроенных или open source решений, способных работать с сертифицированными отечественными ОС, а также анализировать уязвимости, ориентируясь на БДУ.

Выходом служит комплексная система защиты контейнеров, обеспечивающая безопасность на всех этапах жизненного цикла контейнеров с учётом политик организации и требований регуляторов. Она должна быть буквально встроена в ИТ-процессы разработки и быть интегрирована с пайплайном CI/CD. На сегодняшний день этим требованиям наиболее полно отвечает решение Kaspersky Container Security.

Рассмотрим более детально задачи, которые предстоит решить ИТ- и ИБ-команде при комплексной защите контейнеров. Их удобно рассматривать в разрезе объектов защиты и ранее очерченных угроз каждому из компонентов контейнерной инфраструктуры.

Защита образов контейнеров

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

Система защиты должна интегрироваться с публичными и корпоративными реестрами, чтобы регулярно сканировать используемые образы на соответствие установленным политиками. Политики могут быть достаточно разнообразны – от полного соответствия стандартам CIS Kubernetes до простого «в образах нет ВПО и критических уязвимостей из БДУ ФСТЭК». В каждой компании настройки отличаются сообразно её специфике.

Рекомендовано создание контрольных точек (например, момента сборки приложения), за которыми не могут быть использованы образы, не прошедшие одну или несколько проверок. Для минимизации поверхности атаки в качестве базовых образов рекомендуются лаконичные варианты Alpine Linux, Windows Nano Server и подобные. Разумеется, важно выбирать часто обновляемые базовые образы из очень доверенных источников.

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

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

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

Довольно важно проработать сценарии реагирования на найденные несоответствия. Обычно это комбинация из блокирования образа для использования и оповещение ответственных. Но иногда служба ИБ хочет видеть такие события прямо в SIEM. Для уязвимостей с невысоким уровнем опасности можно даже разрешить использование образов и ограничиться оповещениями администраторов. В идеале сканер образов интегрирован с системой CI/CD, чтобы блокировать сборку приложения из образов, не прошедших сканирование успешно.

Защита реестра

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

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

Авторизация и аутентификация. Доступ к реестрам без аутентификации должен быть запрещён. Права доступа должны быть ограничены, например разработчик получает права на запись только тех образов, за создание которых он отвечает.

Защита оркестратора и ОС хоста

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

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

Контейнеры разной степени важности на одном хосте. Рекомендовано распределять контейнеры по нодам, группируя их по важности и чувствительности обрабатываемых данных. Для этого в оркестраторе используется функция «закрепления» (pinning) контейнера на ноде, а в больших организациях может быть осмысленным завести несколько кластеров по числу уровней важности информации.

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

Обновление оркестратора до свежих версий и устранение уязвимостей должно быть приоритетом ИТ и ИБ.

Защита запущенных контейнеров

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

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

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

Уязвимости приложений. Поведенческий анализ контейнеризованных приложений позволяет отследить попытки эксплуатации уязвимостей, запуск ВПО и другие аномалии. Незапланированные контейнеры. Чтобы избежать запуска «левых» контейнеров, необходимы строгое разделение тестовой и рабочей среды, применение ролевой модели доступа (RBAC) и механизмов, запрещающих запуск не соответствующих политикам контейнеров.

Безопасность контейнеризации и DevSecOps

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

Для этого требования ИБ автоматически проверяются на всех фазах подготовки и доставки приложения:

• При выборе базовых образов в начале разработки образы из реестра проверяются на актуальность, ищутся небезопасные настройки и ошибки в файлах IaC (например Dockerfile), сами образы сканируются на уязвимости и ВПО.
• При создании и тестировании приложения на фазе Continuous Integration делаются проверки на соответствие (compliance), отсутствие в образе забытых секретов, уязвимых версий библиотек и ВПО. Система защиты контейнеров интегрирована с CI/CD и прерывает сборку приложения, если часть политик нарушена.
• На фазе доставки, Continuous Delivery, образы проверяются на целостность и соответствие политикам. Если ситуация требует сделать исключение (например, опубликована уязвимость, но еще нет патча), то исключение документируется и на его существование устанавливается временной лимит.
• Когда контейнер выполняется, системы защиты выявляют такие подозрительные индикаторы, как аномально высокая загрузка процессора, неожиданные коммуникации контейнера с другими контейнерами или интернетом. Также система защиты должна минимизировать риски, связанные с опасными настройками оркестратора и уязвимостями среды выполнения, для чего критичны нативная работа с оркестратором Kubernetes или Openshift.

Каким инструментом защищать контейнеры?

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

Решение Kaspersky Container Security создавалось именно с учётом этого комплексного подхода, оно защищает весь жизненный цикл контейнеризованного приложения — от разработки до продолжительной эксплуатации.

На иллюстрации изображена общая архитектура системы. Сканер работает с образами контейнеров и обеспечивает статическую защиту, а агент KCS, работающий как отдельный контейнер под управлением оркестратора, обеспечивает защиту узлов в среде выполнения и безопасность среды оркестрации в целом. Центральный компонент Kaspersky Container Security обеспечивает интеграцию этих частей и позволяет их настраивать.

Производительность платформы позволяет эффективно защищать кластеры K8s с сотнями узлов.

С учетом современных регуляторных требований решение контейнерной безопасности должно входить в Реестр отечественного ПО, отслеживать уязвимости по БДУ ФСТЭК и поддерживать базовые образы, на базе отечественных ОС, в частности Astra Linux и РЕД ОС. Kaspersky Container Security удовлетворяет этим критериям.