Обзор Kaspersky Container Security 1.0, системы обеспечения безопасности контейнерных приложений

1. Введение
2. Функциональные возможности Kaspersky Container Security
3. Архитектура Kaspersky Container Security
4. Системные требования и лицензирование Kaspersky Container Security
5. Сценарии использования Kaspersky Container Security
   1. 5.1. Сценарий № 1. Настройка политик защиты и проверка реестра образов
   2. 5.2. Сценарий № 2. Управление агентами KCS
   3. 5.3. Сценарий № 3. Соответствие стандартам
   4. 5.4. Сценарий № 4. Запуск сканера в CI
6. Выводы

Введение

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

Рисунок 1. Основные компоненты контейнерной инфраструктуры

Глобальный рынок контейнерного ПО быстро растёт. Согласно прогнозам Gartner, к 2024 году он вырастет до 944 млн долларов США. Это связано с тем, что такая форма виртуализации помогает оптимизировать корпоративные ИТ-инфраструктуры и процессы разработки. В изменившемся после COVID-19 бизнес-ландшафте глобальный рынок безопасности контейнеров, оцениваемый в 1,8 млрд долларов США в 2022 году, по прогнозам достигнет размера в 8,2 млрд долларов к 2030 году, увеличиваясь в среднем на 20,7 % за период 2022–2030 гг.

Рисунок 2. Тенденции развития рынка контейнеризации

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

Рисунок 3. Риски для безопасности контейнерных сред

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

Рисунок 4. Инциденты в контейнерных средах

Одна из ключевых целей стратегии развития «Лаборатории Касперского» — построить экосистему, которая будет охватывать все сценарии безопасности для всех цифровых активов корпоративных заказчиков. Компания рассчитывает, что система, которую она выводит на рынок, будет востребованной в самых разных отраслях — не только в ИТ и разработке ПО, но и в банках, в ретейле, в промышленности и вообще везде, где есть современная разработка.

Рисунок 5. Основные различия между защитой виртуальных машин и контейнеров

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

В мае 2023 года состоялся вебинар с описанием и представлением возможностей Kaspersky Container Security, а в конце июля компания рассказала подробнее о версии 1.0.

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

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

Рисунок 6. Функциональные возможности KCS

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

KCS помогает решить проблемы ИБ по части защиты контейнеров:

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

Рисунок 7. Работа с рисками для контейнерных сред с помощью KCS

Также система будет полезным инструментом для сотрудников ИТ-подразделений, занимающихся сопровождением инфраструктуры, и разработчиков бизнес-приложений. С её помощью становятся возможными:

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

Рисунок 8. Интеграция в экосистему Kaspersky XDR

В версии 1.0 внедрены крупные обновления, перечисленные на иллюстрации далее.

Рисунок 9. Основные возможности версии KCS 1.0

В версии 1.1 появится контроль сетевого трафика между контейнерами. В дальнейшем «Лаборатория Касперского» планирует ввести API-интеграцию с KCS в магазины приложений (маркетплейсы) облачных провайдеров, в том числе зарубежных, таких как AWS, Azure и иные. Иные основные нововведения представлены на изображении ниже, а полный перечень будет изложен в сопроводительных записках (release notes) к каждой новой версии системы.

Рисунок 10. Планы развития KCS на 2023-2024 годы

«Лаборатория Касперского» сразу предлагает ролевую модель доступа к консоли KCS: «из коробки» будут доступны пять типов ролей, в том числе с возможностью создавать собственные роли для разграничения доступа.

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

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

KCS состоит из трёх основных компонентов.

1. «KCS Управляющий Сервер» — центральный компонент, отвечающий за управление всей системой и параметрами её функционирования, создание политик безопасности, получение информации от других компонентов системы, выстраивание бизнес-логики продукта и отображение результатов работы, в том числе интеграцию с мессенджерами и электронной почтой.
2. «KCS Сканер» — выполняет обнаружение уязвимостей, вредоносных объектов, паролей в открытом виде и ошибок конфигурации в образах и реестрах образов. По итогам сканирования выстраивается рейтинг опасности и предлагаются рекомендации по снижению уровня угрозы и обработке рисков.
3. «KCS Агент» — отдельный сервис на каждой рабочей ноде. Отвечает за контроль запуска контейнеров из доверенных образов и за проверку политик безопасности с возможностью блокировать запуск контейнера или отправить сообщение администратору СЗИ при несоответствии требованиям. В версии 1.1 будет выполнять анализ поведения контейнера и сервисов внутри него, интегрироваться с платформами оркестровки для анализа их самих и их компонентов.

Рисунок 11. Концептуальная архитектура KCS

Как уже было указано, агент KCS размещается не в контейнере бизнес-приложения, а отдельно в своём собственном. 

Логи системы возможно направлять в любой комплекс управления событиями (SIEM) посредством Syslog, в частности — в SIEM KUMA от «Лаборатории Касперского». 

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

Системные требования и лицензирование Kaspersky Container Security

Для функционирования KCS с Kubernetes требуется версия системы контейнеризации не ниже 1.22. От версии ОС хоста система не зависит.

Таблица 1. Системные требования для компонентов KCS

Предусмотрены два вида лицензий: стандартная и расширенная. Основная разница состоит в том, что стандартная версия предполагает проверку контейнеров перед запуском, оценку рисков и интеграцию в процессы CI / CD, а в расширенной версии добавляются проверка на соответствие требованиям (комплаенс) и защита во время исполнения (runtime): превентивные меры по недопущению запуска контейнеров, которые не прошли проверку на соответствие требованиям политик безопасности.

Рисунок 12. Лицензирование KCS

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

Рассмотрим некоторые основные сценарии использования KCS в повседневных задачах ИБ и ИТ, в частности — при разработке бизнес-приложений на микросервисной архитектуре, при выстраивании принципов DevSecOps, когда в компании введены проверки качества (quality gates), для соблюдения комплаенса или следования лучшим практикам, а также для визуального отображения состава контейнерной инфраструктуры и процессов в ней.

Рисунок 13. Перечень основных сценариев использования KCS

Сценарий № 1. Настройка политик защиты и проверка реестра образов

На данный момент поддерживается проверка по CIS Benchmarks для Kubernetes.

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

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

Рисунок 14. Настройки сканирующих политик в KCS

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

Рисунок 15. Настройки политики безопасности образов в KCS

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

Рисунок 16. Настройка политики реагирования в KCS

Рисунок 17. Настройки интеграции с Telegram в KCS

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

Рисунок 18. Пример сообщения о завершении проверки на соответствие политикам

Для начала работы по сценарию проверки на соответствие политикам необходимо интегрироваться с реестром образов контейнеров. В настоящее время поддерживаются пять типов реестров: Docker Hub, JFrog, GitLab Registry, Harbour и Nexus.

Рисунок 19. Интеграция с реестром в KCS

Выбираем параметры сканирования образов.

Рисунок 20. Параметры сканирования в KCS

Далее выберем образ, который хотели бы просканировать.

Рисунок 21. Выбор проекта для сканирования в KCS

Сканирование возможно провести не только по базе известных CVE, но и по БДУ ФСТЭК России. Отметим, что поддерживается сканирование образов на базе Astra Linux и РЕД ОС.

Рисунок 22. Результат сканирования реестра образов в KCS

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

Рисунок 23. Варианты устранения обнаруженных рисков

Вкладки в результатах сканирования («Уязвимости», «Слои» и т. д.) можно увидеть на иллюстрациях далее.

Рисунок 24. Вкладка «Уязвимости» в KCS

Рисунок 25. Слои просканированного в KCS

Рисунок 26. Ресурсы (из каких компонентов состоит образ) в KCS

Рисунок 27. Обнаруженная вредоносная программа в KCS

Рисунок 28. Открытые конфиденциальные данные в KCS

Рисунок 29. Ошибки конфигурации в KCS

Рисунок 30. Сводная информация об образе в KCS

Рисунок 31. История сканирований выбранного образа в KCS

По итогам изучения полученного отчёта ИБ-специалист организации или инженер DevSecOps может внести коррективы в настройки политик. Основным шагом для этого этапа является принятие рисков после сканирования. Помимо стандартной процедуры принятия риска (риск несущественен или нет возможности устранить его) есть возможность временного принятия — к примеру, для того, чтобы не останавливать бизнес-процессы, но позволить разработчикам устранить обнаруженные риски и уязвимости. Все принятые риски находятся в соответствующем реестре.

Рисунок 32. Функция принятия риска в KCS

Сценарий № 2. Управление агентами KCS

Поддерживается установка агентов на рабочих нодах кластера Kubernetes / OpenShift. В настоящее время эти платформы являются приоритетными для тестирования и работы агентов KCS.

Для начала необходимо создать группу агентов.

Рисунок 33. Создание группы агентов KCS

Получаем параметры группы и конфигурацию для развёртывания агентов (в виде YAML-файла).

Рисунок 34. Группа агентов KCS готова к установке

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

Рисунок 35. Визуализация содержимого кластера с помощью агентов KCS

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

Сценарий № 3. Соответствие стандартам

Для примера возьмём оценку лучших практик CIS Benchmarks для кластера Kubernetes.

Рисунок 36. Результаты проверки безопасности по стандарту в KCS

Запустим задачу проверки подключённых в KCS кластеров. Пример отчёта, в котором отмечены все несоответствия, проставлены уровни критической значимости и указаны способы устранения замечаний, изображён на рисунке далее.

Рисунок 37. Отчёт по анализу кластера Kubernetes в KCS

Сценарий № 4. Запуск сканера в CI

Имеется проект со скриптом сборки контейнера, в котором также присутствует код запуска сканера KCS.

Рисунок 38. Скрипт сборки контейнера и запуска сканера KCS

Далее напрямую из GitLab возможно запустить работу сканера.

Рисунок 39. Запуск сканера KCS

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

Рисунок 40. Процесс работы сканера KCS

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

Рисунок 41. Результаты сканирования в KCS

Логика сканирования и получаемые результаты в целом аналогичны таковым для сценария № 1, с той разницей, что при отклонении от политик возвращается ошибка, которую возможно обработать в CI. Это позволяет заблокировать развёртывание образа.

Рисунок 42. Пример результата сканирования образа в CI / CD

Выводы

Изучение системы Kaspersky Container Security показало, что уже в версии 1.0 она предоставляет обширные возможности по защите контейнерной инфраструктуры от всевозможных угроз, таких как внедрение вредоносного кода в реестры образов, запуск заражённых контейнеров или эксплуатация уязвимых версий ПО для целенаправленных атак на контейнерную инфраструктуру. Режим проверки соответствия регуляторным требованиям поможет быстро привести в порядок настройки кластера. Ожидаем, что продукт будет развиваться дальше с использованием всех возможностей «Лаборатории Касперского» и с учётом её опыта на рынке ИБ.

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

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

Недостатки:

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