Как защитить платформы контейнеризации на всех стадиях жизненного цикла28.09.2023 14:02

Контейнерные инфраструктуры становятся все более популярны и востребованы. Если изначально контейнеры стали внедрять технологические компании, то постепенно их область применения расшилась и на данный момент они все больше используется организациями из разных отраслей. Однако сложность и динамичность компонентов контейнерной среды создает дополнительные риски безопасности. Защита контейнеров является непростой задачей, имеющей свою специфику и требующей отдельного подхода к ее решению. В этой статье Андрей Семенюченко, руководитель управления решений для корпоративных заказчиков «Лаборатории Касперского», рассматривает комплексный подход к защите платформы контейнеризации на всех стадиях жизненного цикла.

1. Специфика защиты контейнеров

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

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

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

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

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

А если взглянуть на контейнеры с точки зрения зрелости подходов безопасности, то мы увидим, что, например, требования по безопасности к средствам контейнеризации ФСТЭК были утверждены только 4 июля 2022 года, и даже передовая, известная всем MITRE ATT&CK матрица для контейнеров появилась лишь в 2021 году. Также, как и Enterprise ATT&CK матрица, описывающая фазы и средства, которыми злоумышленники пользуются для атаки на корпоративную инфраструктуру, матрица для контейнеров содержит 9 тактик и 32 техники, которые атакующий может использовать для проникновения в контейнерную среду и причинения ущерба компании.

Тактики матриц весьма схожи, но используемые техники будут отличаться. Например, на стадии Initial access атакующий может пытаться проникнуть в работающий Kubernetes кластер путем компрометации сервера управления (Control Plane) или компонентов рабочих узлов через эксплуатацию уязвимостей, связанных с ошибками в коде, слабыми настройками контейнерной среды или доставкой в кластер зараженного образа. На стадии Execution путем эксплуатации выявленной уязвимости внутри пода исполняется произвольный код. Это может быть простой HTTP-запрос к удаленной системе злоумышленника, который позже трансформируется в интерактивный удаленный шелл. Для закрепления в системе (Persistence) команды злоумышленника записываются в скрипт, который периодически запускается с помощью Kubernetes Cron. При необходимости из скомпрометированного или недоверенного реестра загружаются дополнительные модули вредоносного ПО. Далее происходит доступ к другим подам и узлам (Privilege escalation и Lateral movement) с целью получения конфиденциальной информации или совершения других деструктивных действий (Impact).

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

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

Мы уже говорили, что контейнеры связаны с разработкой и конкретно с концепцией CI/CD. Подобно кровеносной системе, CI/CD охватывает все процессы сборки и доставки приложений. Поэтому она может быть использована как для доставки «полезных» компонентов — образов контейнеров, так и для доставки потенциально зараженных и уязвимых артефактов.

Кроме того, собранные образы нужно где-то хранить. Для этого используются всевозможные репозитории и реестры. Репозитории могут быть публичными и частными. И здесь необходимо убедиться, что используются только проверенные образы из доверенных репозиториев.

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

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

С учетом сказанного матрица MITRE мне представляется менее информативной, чем, например, руководство Application Container Security от NIST). Поскольку, как признают сами авторы матрицы, несмотря на понимание различных уровней и связанных с ними векторов атак, некоторые уровни, например, оркестратора и рантайма для упрощения объединены в единую платформу.

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

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

Давайте посмотрим на основные из них:

• уровень хранения образов контейнеров и конфигурационных файлов, включающий как риски компрометации образов, так и риски, связанные непосредственно с реестрами. Например, компаниями могут использоваться недоверенные или скомпрометированные реестры ввиду их слабой аутентификации или небезопасного соединения. Такие реестры могут содержать старые, не обновляемые и зараженные образы контейнеров.
• уровень инструментов CI/CD, который не относится непосредственно к кластеру работающих контейнеров, но который нужно учитывать, т.к. на различных этапах пайплайна собираются образы, потенциально содержащие проблемы безопасности
• уровень контейнеров и runtime среды их исполнения (например, Docker Engine, CRI-O, containerd)
• уровень оркестратора (наиболее популярные — Kubernetes, OpenShift) и риски, связанные с его некорректной конфигурацией
• уровень хоста и риски, связанные с его окружением.

2. Проблемы решений по защите контейнеров

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

Например, если говорить про уровень хоста кластера, на котором запускаются контейнеры, то здесь мы имеем дело с классическими рисками, связанными с эксплуатацией уязвимостей в операционной системе и окружении хоста. Поэтому здесь необходимо максимально уменьшать поверхность атаки. Это можно сделать, например, с помощью применения MAC (Mandatory Access Control) контроля доступа средствами ядра Linux и запрета по умолчанию на запуск любых приложений и сервисов, кроме требуемых для работы контейнеров. Либо рекомендуется вообще отказаться от операционных систем общего назначения в пользу специализированных ограниченных систем, предназначенных только для запуска контейнеров, например, Fedora CoreOS, RHCOS, Container-Optimized OS и других.

Конечно же необходима гранулярная настройка политик RBAC. В случае с защитой контейнеров, когда в процессе задействованы множественные роли — разработчики, DevOps специалисты, SDET команда, администраторы, служба безопасности и выделенная DevSecOps команда, — нужно как никогда руководствоваться принципом наименьших привилегий.

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

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

Во-вторых, платформы оркестрации, такие как Kubernetes, вносят свой уровень абстракции. Так, например, если говорить про сетевое взаимодействие контейнеров, то K8s создает свою наложенную overlay сеть поверх классической сети. Каждый pod, запускающий контейнеры в K8S, получает свой IP-адрес. Кроме того, существует межконтейнерное взаимодействие между подами даже в рамках одного хоста, а сетевая политика по умолчанию в K8S разрешает все сетевые соединения. Все это делает невозможным для большинства традиционного сетевого оборудования контролировать передаваемый трафик и выявлять в нем какие-либо аномалии и угрозы.

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

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

3. Комплексное решение безопасности

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

Настройку продукта прежде всего нужно начать с интеграции с реестрами, в которых хранятся образы контейнеров. Такие реестры могут быть публично доступными, как, например, Docker hub. Так же компании могут использовать реестры, развернутые во внутреннем контуре, например JFrog или Nexus OSS. Настройки сканирования реестров должны предусматривать не только ручной выбор образов, но и автоматическую проверку на основе разных критериев, например, даты создания и изменения образов, их названий и тегов.

В случае наличия в компании внутренней разработки и соответствующих процессов необходимо произвести интеграцию с используемыми инструментами CI/CD, такими как GitLab, Jenkings, TeamCity, CircleCI. Это позволит сканировать образы контейнеров на различных этапах сборки и тестирования образов. Для этого выстраиваются так называемые секьюрити гейты, чтобы на каждый следующий этап поступал только уже проверенный образ.

После того, как интеграция с необходимыми реестрами и CI/CD платформами выполнена необходимо настроить политики безопасности. Причем политики сканирования образов будут отличаться от политик, применяемых на уровне запуска контейнеров.

Политика сканирования позволяет настроить фильтры и контроли безопасности, применяемые во время проверки образов, собранных в том числе на базе отечественных ОС: Astra Linux и RedOS. Нужно определить, сканировать ли образы на уязвимости, и если да, то какую базу уязвимостей использовать. Для российских заказчиков актуальным будет использование не только базы NIST, но и БДУ ФСТЭК. Критичным также является проверка на наличие злонамеренного ПО. Кроме этого, образы контейнеров также могут быть небезопасно сконфигурированы и содержать забытые секреты, такие как учетные данные, пароли, ключи, токены и другие конфиденциальные данные.

Далее нам необходимо настроить действия и триггеры, применяемые в политиках реагирования. Например, политика может быть применена только в случае найденных уязвимостей уровня High и Critical. Критически важным будет наличие в политике возможности осуществить такие действия, как остановка этапа CI/CD пайплайна или занесение образа в список не соответствующих политике безопасности для предотвращения его последующего запуска в среде исполнения. Необходимо также информировать членов команды безопасности, DevSecOps и DevOps о таких образах и найденных в них проблемах через различные каналы связи, например, почту и Telegram.

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

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

Заключение

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

• визуализировать активы: все ресурсы кластера, включая неймспейсы, поды, их конфигурацию и взаимосвязи,
• определять общее состояние безопасности системы и давать оценку риска,
• проводить регулярную проверку реестров на предмет нахождения образов, несоответствующих политикам безопасности,
• интегрироваться с инструментами CI/CD для более раннего выявления проблем (с подходом безопасности Shift-left) на всех этапах пайплайна,
• контролировать запуск и активность уже запущенных контейнеров.

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

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

Автор выражает благодарность Вениамину Левцову за полезные замечания и общее руководство при подготовке материала.

Полный текст статьи читайте на CNews