Привет всем! Я Михаил Бессараб, в Positive Technologies руковожу продуктом PT Container Security, предназначенного для защиты контейнеризированной инфраструктуры.

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

• системные контейнеры (api-server, coredns, scheduler, controller-manager, куда же без них);

• контейнеры cni (container network interface — без них сеть в кластере работать не будет);

• контейнеры ingress для обеспечения внешнего доступа к приложениям.

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

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

И если для ИТ-мониторинга решение уже найдено (на базе, например, Grafana stack или других похожих сервисов), то с обеспечением безопасности есть ряд проблем.

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

Опираясь на опыт других проектов, мы сформировали свое видение защиты мультикластерных инфраструктур и реализовали его в недавнем релизе продукта PT Container Security. Как именно — читайте в этой статье. Спасибо за помощь в ее подготовке Алексею Жукову, нашему лидеру продуктовой практики AppSec.

Да кто вообще защищает контейнеры?!

Совместное исследование К2 Кибербезопасность и Positive Technologies показало, что 65% российских компаний активно используют контейнеры для развертывания приложений. Большинство (94%) из них отметили, что не сталкивались с серьезными инцидентами безопасности. Почти четверть (24%) организаций задумываются о защите и используют отечественные средства ИБ. Еще 15% пытаются защищаться с помощью опенсорсных систем, при этом 40% из них уже рассматривают возможность перехода на enterprise-продукты.

В качестве актуальных киберрисков респонденты отметили DDoS-атаки, утечки данных, нарушение NDA, уязвимости нулевого дня, зависимости в коде, человеческий фактор, вирусы и другое.

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

Образы

Внедрение вредоносного кода, эксплуатация уязвимостей и дефектов конфигурации.

Реестры контейнеров

Компрометация публичного реестра и проникновение в компанию через незащищенное соединение; взлом инфраструктурного хранилища и подмена образов.

Оркестратор

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

Операционная система узла

Эксплуатация уязвимостей компонентов ОС для получения доступа к целевым системам (здесь поверхность атак очень широкая).

Контейнер

Компрометация инфраструктуры через уязвимости и ошибки, которые по каким-то причинам попали в рантайм.

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

Что за зверь эта ваша мультикластерность

Есть в мире IT такое понятие, как мультитенантность — способ развертывания систем, включая те, что относятся к кибербезопасности, на все части ИТ-инфраструктуры (тенанты). Управление при этом осуществляется из единой консоли. В нашем случае тенантами являются кластеры Kubernetes, в которых работают приложения. Поэтому вместо термина «мультитенантность» мы используем «мультикластерность».

Давайте разберем еще несколько понятий, связанных с последним релизом. У нас есть два типа кластеров, которые нужно защищать:

• родительский — сюда устанавливается ядро ИБ-системы; через этот кластер осуществляется настройка контейнеров и управление их безопасностью, при этом он защищается так же, как и зависимые от него сущности;

• дочерний — в нем разворачиваются агенты защиты PT Container Security, сюда же приземляются вспомогательные сервисы для обеспечения кибербезопасности; таких кластеров может быть несколько.  

Следующий важный термин — OCI-реестр. Это репозиторий с docker-образами и helm-чартами, в котором можно хранить артефакты для установки PT Container Security. И это еще одна фишка нового релиза, которую так ждали пользователи. Теперь продукт можно развернуть онлайн: для этого достаточно подключиться к нашему центральному репозиторию и получить все необходимое для запуска. Такой подход позволит еще быстрее и гибче разворачивать компоненты защиты внутри инфраструктуры.

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

Что умеет продукт в мультикластере

Если мы представим карту процессов DevSecOps, то обнаружим, что PT Container Security задействуется повсюду. В самом начале нам нужно понять, из каких образов и с помощью каких утилит собирается приложение и нет ли в них чего-нибудь неприятного в виде CVE, нарушений политик безопасности и другого. А затем мы должны проконтролировать процесс развертывания приложения в кластере. Здесь применяются в том числе функции безопасности оркестратора контейнеров. Идем дальше: ПО работает, и злоумышленники могут атаковать его. Теперь наша задача — защищать рантайм, следить за всем, что там происходит, интегрироваться с окружением, которое используется ИТ-службами, и передавать данные средствам мониторинга ИБ.

А теперь по порядку обо всех функциях безопасности PT Container Security.

Сканирование образов на этапе сборки

Вспомним про shift left — подход, при котором тестирование безопасности начинается уже на самых ранних этапах разработки. Раньше под максимальный сдвиг влево по умолчанию попадал только статический анализ кода. Однако масштабная атака на SolarWinds заставила нас изменить свое мнение: тогда киберпреступники внедрили вредонос в свежие версии платформы Orion и это обновление загрузили около 18 тыс. клиентов.

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

В мире CI/CD приложения в основном собираются из готовых шаблонов — docker-образов. PT Container Security гибко встраивается в любой конвейер сборки и автоматически сканирует конфигурационные файлы, манифесты и уже созданные образы на предмет соответствия заранее заданным правил ИБ. Если обнаруживается опасная уязвимость или вредоносная активность, продукт, используя заданный набор правил, блокирует сборку и доступ к небезопасным объектам, а также уведомляет команду.

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

Admission controller во время развертывания

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

PT Container Security проверяет, соответствуют ли обращения к кластеру заданным правилам безопасности, и блокирует подозрительные команды. Для этого продукт используют штатный компонент кластера — Admission Controller. Мы разработали его самостоятельно, в нем есть набор проверок, позволяющий охватить потенциальные атаки и проверить конфигурации на соответствие лучшим практикам.

Мониторинг рантайма

Когда наш продукт только-только начинал зарождаться, уже тогда на кибербитвах Standoff мы убедились в том, что он точно будет полезен. Как оказалось, классические средства ИБ недостаточно хорошо работают со средами оркестрации. Злоумышленники проникают в контейнер, и всё — мы теряем их из виду. А они тем временем могут пытаться атаковать входящий сетевой поток, изменить параметры безопасности и журналирования, чтобы скрыть свое присутствие, вывести данные из кластера или взломать код приложения.

PT Container Security как специальное средство защиты контейнеризированных инфраструктур позволяет отслеживать все события, которые происходят на каждом узле кластера. Для этого продукт использует штатные механизмы ядра Linux: kprobes, uprobe, tracepoint и BPF-LSM. Сбор событий осуществляется отдельно от их анализа и реагирования на выявляемые угрозы, поскольку первое должно выполняться максимально оперативно, чтобы не тормозить ядро, в то время как требования ко второму не столь высоки.

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

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

Альтернативный и бережный вариант — настроить вебхук. Он сообщит об угрозе в мессенджере или свяжется с внешней системой, позволяющей реализовывать гибкое реагирование. Та в свою очередь подключится к потенциально атакованному объекту и корректно нейтрализует подозрительную активность. Здесь можно написать разные скрипты реагирования. Главное — это будет безопасно, без риска поломать что-то.

Как управиться с армией кластеров

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

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

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

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

PT Container Security позволяет не просто проверить команды, но и в целом сделать процесс подключения кластеров к продукту более логичным. Разумеется, командная строка была и остается одним из универсальных вариантов, но кто сказал, что ее нужно формировать обязательно вручную, поминутно рискуя при этом ошибиться? Мы реализовали в продукте пошаговый установщик. С помощью него удобно совершать разные операции: сохранять сертификаты, передавать их через командную строку, включать и отключать TLS, активировать параметры связи с базами данных и так далее.

Плюс ко всему мы понимаем, что работаем в контексте мильтикластерности. Если где-то нужно развернуть сервис, мы используем его имя и механизмы, чтобы «достучаться» до кластера, находясь внутри. Если дочерний кластер развернут индивидуально, независимо от родительского, используем ingress — штатные правила доступа к сервисам внутри этой группы — или альтернативные подходы.

В итоге получается знакомый всем визуальный интерфейс пошагового установщика («визарда») прямо внутри продукта. А на выходе мы видим привычную нам командную строку, как для развертывания helm-чарта. Только параметры запуска корректно сформированы и проверены.

Кто будет доволен

Операторы SOC, специалисты по ИБ, инженеры ИТ-мониторинга

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

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

Айтишники и DevOps-инженеры

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

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

AppSec-инженеры

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

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

Директора по ИТ и ИБ

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

PT Container Security можно быстро через helm-чарты раскатать на все кластеры, (дочерние подключаются к родительским). Это позволит получать полную и достоверную информацию о состоянии безопасности инфраструктуры, видеть всю активность в контейнерах.

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