Обзор PT Container Security, отечественной системы защиты контейнеров

1. Введение
2. Функциональные возможности PT Container Security
   1. 2.1. Управление уязвимостями
   2. 2.2. Защита кластеров контейнеризации
   3. 2.3. Защита среды запуска контейнеров
   4. 2.4. Расследование инцидентов
3. Архитектура PT Container Security
4. Системные требования PT Container Security
5. Сценарии использования PT Container Security
6. Выводы

Введение

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

Согласно отчёту The state of Kubernetes security report: 2024 edition компании Red Hat, 67 % фирм отложили или замедлили развёртывание контейнеров из-за проблем с безопасностью Kubernetes. 46 % компаний понесли финансовый ущерб в виде потери дохода или клиентов из-за инцидента с безопасностью контейнеров или Kubernetes, а 30 % респондентов назвали уязвимости самой большой проблемой для своих контейнеров и среды Kubernetes.

В продуктовом портфеле Positive Technologies для защиты контейнеров есть отдельное решение — PT Container Security. Рассмотрим, насколько оно поможет компаниям минимизировать риски информационной безопасности для использования технологии контейнеризации.

Функциональные возможности PT Container Security

PT Container Security участвует в работе с контейнерами в течение всего жизненного цикла внедрения продукта, начиная от разработки и заканчивая внедрением контейнера в продуктивную среду.

Рисунок 1. Применение PT Container Security на разных этапах жизненного цикла разработки ПО

Рассматриваемая система используется вендором в том числе для собственной работы, так как многие его продукты, например PT Sandbox, MaxPatrol VM, MaxPatrol SIEM, PT Application Inspector, PT BlackBox, PT Application Firewall, постепенно переходят в контейнеры. В связи с этим производитель своевременно внедряет необходимые функции безопасности в PT Container Security.

Рисунок 2. Функциональные возможности PT Container Security

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

Управление уязвимостями

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

В системе содержится собственная база уязвимостей, собранная с учётом экспертизы вендора, что позволяет выстроить процесс управления уязвимостями в образах контейнеров, в том числе на базе образов отечественных ОС, таких как Astra Linux, RedOS, Alt linux и другие.

Одной из ключевых проблем при управлении уязвимостями образов является сканирование на этапе сборки в CI/CD-пайпланах. PT Container Securtiy позволяет обеспечить поиск уязвимостей не только в собранных образах, но и в их конфигурациях (Dockerfile) ещё до этапа сборки. В числе используемых баз уязвимостей есть отечественные, предоставленные ФСТЭК, компаниями «Астра», «РЕД СОФТ».

В рамках CI/CD продукт позволяет искать дефекты в конфигурациях манифестов Kubernetes для оценки соответствия лучшим практикам и отраслевым стандартам (например, NIST 800-190, PCI DSS, ФСТЭК № 118 и другим). Пока проверки образов и конфигураций поставляются вместе с продуктом, однако вендор заявляет о том, что поддержит возможность кастомизации контента в конце первой половины 2025 года.

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

PT Container Security позволяет провести интеграцию со всеми популярными артифакториями, такими как Jfrog Artifactory, Sonatype Nexus, Gitlab Container Registry, с использованием их собственного API. Отдельно стоит отметить поддержку API и интеграцию продукта с отечественным облачным реестром образов Yandex Container Registry.

Для всех остальных реестров вендор предлагает интеграцию с использованием стандартного v2 API Docker.

PT Container Security позволяет выявлять угрозы в реестрах образов при помощи регулярного сканирования с возможностью задать расписание. Производитель предлагает осуществлять реагирование на все выявленные угрозы через webhook, почту, Syslog по выбору. 

Защита кластеров контейнеризации

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

Для защиты от атак на кластеры контейнеризации в PT Container Security предусмотрено несколько уровней защиты. Защита от несанкционированного изменения конфигурации, включая изменения в ролевой модели, сетевых политиках, запрет на изменение конфигураций приложений, выполнена через собственный admission controller. В настоящее время продукт «из коробки» поддерживает политики защиты кластера Kubernetes. В первой половине 2025 года вендор обещает открыть доступ к SDK и шаблонам по созданию собственных проверок.

Таким образом, система контролирует конфигурацию кластера.

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

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

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

Рисунок 3. Статистика атак на контейнеры

Помимо хорошо известных атак, таких как инъекции (например, SQL) и удалённый запуск кода (RCE), значимыми рисками для контейнеров являются нарушение изоляции и «побег» на хостовую ОС, который позволяет злоумышленнику получить доступ к данным не только конкретного контейнера, но и всех контейнеров на узле, а также неограниченный доступ к ресурсам самого узла.

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

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

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

Зачастую поток событий в контейнерах значительно превышает таковой в классической инфраструктуре. Например, один не сильно нагруженный кластер (до 15 микросервисов) может генерировать десятки тысяч событий в секунду, что соответствует потоку событий инфраструктуры в организации средних размеров. Функциональность PT CS предоставляет широкие возможности по настройке потока событий без обязательной последующей перезагрузки системы. Например, можно отдельно включить наблюдение за критичными системными файлами или отключить отслеживание сетевых пакетов и так далее.

Для того чтобы выявлять аномалии в потоке событий рантайма контейнеров, событий admission controller и сканера, в PT Container Security используется отдельный движок политик безопасности на базе технологии WebAssembly. При помощи движка продукт обрабатывает входящие очереди событий от поддерживаемых сенсоров и выявляет в них угрозы безопасности контейнеров. 

Positive Technologies заявляет о высокой производительности движка, проверенной в рамках нагрузочных тестов и реальных испытаний у клиентов. Также говорится о планах поддержки в SDK движка дополнительных источников, например с собственным потоковым антивирусом PT MultiScanner для сканирования образов на вредоносные программы в CI/CD-пайплайне.

Для реагирования на выявленные угрозы в PT Container Security предусмотрены механизмы уведомления с использованием электронной почты, протокола syslog для отправки событий в SIEM системы, а также механизма webhook для интеграции с такими системами, как трекеры задач, мессенджеры, и инструменты оркестрации. 

В рамках тестирования предлагаются интеграции с telegram, mattermost, Jenkins, Grafana LOKI, Max Patrol SIEM, Defect Dojo. При этом настройка шаблонов уведомлений доступна для всех методов интеграций и выполняется непосредственно в графическом интерфейсе пользователя, таким образом список подключаемых систем может быть легко расширен как с участием вендора, так и без него.

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

Расследование инцидентов

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

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

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

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

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

Архитектура PT Container Security 

Для обеспечения высокой производительности и доступности решение задействует подходы микросервисной архитектуры. Всего в PT Container Security входит 15 микросервисов, каждый из которых отвечает за выполнение своей функции. Конфигурации сервисов и результаты сканирований хранятся в БД на базе PostgreSQL, исторические события — в БД Clickhouse, а взаимодействие микросервисов проходит через производительные сервисы очередей RabbitMQ и кэш на базе Redis. 

Одной из особенностей продукта Positive Technologies является возможность использовать внешние кластеры БД, очереди и кэш для всех инфраструктурных компонентов в сценариях высокой нагрузки (рекомендуемый производителем сценарий). Также отметим поддержку работы с сертифицированными версиями внешних компонентов для сценариев работы в ГИС и КИИ. 

Основа высокой производительности движка политик безопасности обеспечена за счёт технологии WASM (WebAssembly). Она позволяет интегрировать модули, написанные на разных языках. Основным преимуществом WebAssembly является скорость работы кода правил, близкая к нативному коду, в отличие, например, от реализаций на REGO. Также эта технология позволяет изолировать модули друг от друга с целью минимизировать влияние и ограничить доступ к ресурсам хостовой системы. 

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

Рисунок 4. Архитектура PT Container Security

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

1. Задачи сканирования образов и проверки конфигураций попадают от сервиса интеграции с реестрами в кэш обработки, из которого передаются в сканирующий компонент.
2. Поток событий от сенсора рантайма передаётся в очередь событий, где их обрабатывают несколько (в зависимости от нагрузки) экземпляров сервиса движка политик.
3. Запись обработанных событий в БД и отправка уведомлений осуществляются отдельными микросервисами.

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

К главным отличительным чертам PT Container Security относятся возможность настраивать политики сбора событий ядра ОС Linux и фильтрация сбора по необходимым ресурсам контейнеров (namespace, pod, container, label). Таким образом пользователь продукта может сам выбрать баланс между глубиной мониторинга, потребляемыми ресурсами и покрытием инфраструктуры.

Общая архитектура работы мониторинга контейнеров в рантайме PT Container Security приведена ниже.

Рисунок 5. Архитектура PT Container Security при работе с runtime

Системные требования PT Container Security

Сервер, с которого выполняется установка PT CS, должен соответствовать минимальным требованиям, приведённым в таблице.

Таблица 1. Системные требования PT Container Security

Сервер с развёрнутым кластером Kubernetes должен удовлетворять требованиям, приведённым в таблице.

Таблица 2. Аппаратные требования к серверу с кластером Kubernetes

Подробные требования к аппаратной части приведены на сайте производителя.

Сценарии использования PT Container Security 

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

Рисунок 6. Стартовая страница PT Container Security

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

Рисунок 7. Раздел управления образами в PT Container Security

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

Рисунок 8. Информация об образе в PT Container Security

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

Рисунок 9. Просмотр образов в PT Container Security

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

Для снижения количества ложноположительных срабатываний администратор системы может добавлять исключения как по идентификатору уязвимости, так и по названию компонента либо его версии. Для проверок безопасности конфигураций (IaC), Admission Controller и проверок в рантайме добавляют в исключения конкретную проверку или проверки.

Рисунок 10. Настройка правил реагирования в PT Container Security 

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

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

Рисунок 11. Настройка уведомлений в PT Container Security

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

Рисунок 12. Работа с событиями раздела «Сканирование» в PT Container Security

Для поиска аномалий и расследования работы контейнеров используется раздел «Рантайм». В нём можно настроить работу сенсора, просмотреть список доступных детекторов (правил выявления аномалий), а также ознакомиться с событиями контейнеров, запущенных в кластере, и выявленными аномалиями. 

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

На момент тестирования в продукте предусмотрены политики для мониторинга:

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

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

Рисунок 13. Настройка параметров отслеживания событий в PT Container Security 

Рисунок 14. Информация о выявляемых событиях

Детали выявленных событий можно просмотреть в отдельной карточке.

Рисунок 15. Карточка события в PT Container Security 

Пользователь может отредактировать настройки фильтров рантайма в части выявления событий: добавить или убрать namespace, pod кластера или настроить мониторинг контейнеров только с определёнными label, в которых производится анализ файлов, расширениями файлов и так далее.

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

Рисунок 16. Информация о событиях в PT Container Security

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

Рисунок 17. Необработанные данные события в PT Container Security

Одной из ключевых возможностей PT Container Security является построение дерева процессов. Например, обнаружив подозрительное срабатывание, можно проанализировать её «родителя» и отследить другие процессы, запущенные в рамках одного «родителя». Таким образом отсматривают, например, все команды, выполненные в рамках reverse-shell. Кроме «родительского», можно перейти и в «дочерние» процессы.

Рисунок 18. Отслеживание процессов, запущенных из-под «родителя» в PT Container Security

Раздел детекторов содержит информацию об индикаторах атак, используемых в системе. Команда вендора поставляет свою экспертизу «из коробки» в части выявления атак на контейнеры. На момент анализа продукта вендор заявляет более 20 правил, которые на 100 % покрывают матрицу MITRE ATT&CK for Containers. 

Администратор системы может удалить какие-либо из них либо добавить новые через графический интерфейс. Детекторы в системе написаны на языке Go (вендор предоставляет SDK и шаблоны), но в случае необходимости допускается адаптировать систему под детекторы, созданные на других языках.

Рисунок 19. Раздел детекторов в PT Container Security

Выводы

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

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

Достоинства:

• Возможность выдерживать высокую нагрузку и независимо масштабировать компоненты системы.
• Построение дерева процессов.
• Настройка мониторинга как по глубине собираемых событий, так и по покрываемой части инфраструктуры.
• Реагирование на выявленные события ИБ нативными средствами.
• Кастомизация контента и шаблонов уведомлений.
• Наличие встроенной («из коробки») и обновляемой экспертизы по безопасности контейнеров от экспертного центра безопасности Positive Technologies.

Недостатки:

• Использование WASM не даёт активизировать графический редактор для поиска событий в системе.
• Отсутствие сертификата ФСТЭК. Его планируется получить в первом квартале 2025 года.
• Требуется значительная степень визуализации ресурсов в кластере.
• Большое количество микросервисов в архитектуре продукта.