Kaspersky Container Security: контроль над безопасностью контейнерной инфраструктуры

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

Авторы:
Алексей Рыбалко, специалист по защите сред разработки, “Лаборатория Касперского”
Антон Русаков-Руденко, старший менеджер по продуктовому маркетингу “Лаборатории Касперского”
Тимофей Минин, старший менеджер по продуктам “Лаборатории Касперского”

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

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

Во-вторых, необходимо интегрировать проверки на безопасность в процессы CI/CD, если таковые в компании выстроены. Согласно исследованиям [1], только у трети всех организаций организован полноценный цикл внутренней разработки. Но если говорить об эталонном решении, то интеграция в CI/CD – обязательна. Входящие в сборку образа объекты (SBOM) должны анализироваться на всех этапах, а затем, уже после перехода к фазе continuous delivery, необходимо контролировать, какие именно образы запускаются.

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

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

Именно такое понимание контейнерной защиты реализовано в Kaspersky Container Security.

ris1_w-Jun-19-2025-02-02-55-3588-PM

Ключевые угрозы и векторы атак

Когда организация приступает к анализу рисков своей контейнерной инфраструктуры, разумнее всего опираться на регуляторные требования – приказ ФСТЭК России № 118 [2] от 4 июля 2022 г., ГОСТ Р 56939–2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования" [3], а также на другие авторитетные материалы, в частности, Application Container Security Guide от NIST [4].

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

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

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

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

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

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

Дополнительная защита на уровне Kubernetes

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

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

Такой трехуровневый контроль – ранний в части хранения образов и проверки реестра, дополнительный в CI/CD и обязательный в Kubernetes – позволяет эффективно предотвратить проникновение непроверенного кода в рабочую среду, даже если ранние этапы проверки были кем-то намеренно пропущены.

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

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

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

От мониторинга к управлению

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

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

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

Стратегии реагирования на аномалии

В Kaspersky Container Security предусмотрены два основных режима работы:

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

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

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

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

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

Другой важный момент связан с тем, как именно осуществляется процесс блокировки. В некоторых архитектурах используется подход, при котором контроль над блокировками передается внешним средствам: встроенным механизмам Kubernetes или расширенным модулям, таким как Kyver№ или OPA Gatekeeper на уровне admission-контроллеров, а на уровне хоста – системам вроде AppArmor.

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

Осознавая эти риски, команда разработки приняла стратегическое решение: Kaspersky Container Security позволяет самостоятельно управлять блокировками без использования сторонних модулей (таких как Kyverno).

Собственный движок системы выступает одновременно и как admission-контроллер, и как активный механизм реагирования. Все решения о разрешении или запрете действий принимаются внутри Kaspersky Container Security, без передачи контроля внешним средствам.

Таким образом, заказчик контролирует весь процесс – от формирования правил до их применения – и, соответственно, его служба эксплуатации может качественно работать с любыми возникающими инцидентами, включая возможные ложные срабатывания. В случае возникновения вопросов или проблем, связанных с защитой, техническая поддержка "Лаборатории Касперского" полностью берет на себя сопровождение процесса, исключая необходимость обращаться к обезличенному сообществу при использовании Open Source-компонентов.

Стоит отметить, что часть политик безопасности поставляется сразу из коробки.

Яркий выход на рынок

Kaspersky Container Security – одна из по-настоящему ярких историй успеха. Старт продукта состоялся в середине 2023 г. С тех пор выпускается по два релиза в год, в которых совершенствуется система и развивается ее функционал.

"Лаборатория Касперского" внимательно следит за международной аналитикой, отслеживает тренды в области ИБ и ИТ по материалам крупнейших аналитических агентств, чтобы оставаться на острие мировых трендов. В сфере контейнеризации и Kubernetes разработчики четко уловили момент, когда технология вышла за пределы круга энтузиастов и стала массово применяться в продакшене. Kaspersky Container Security вышел на рынок в тот самый момент, когда заказчики были готовы не просто обсуждать защиту контейнеров, а активно ее внедрять. Выход совпал с усилением политики импортозамещения, что еще больше подстегнуло интерес рынка.

Несмотря на молодость, решение уже продемонстрировало зрелость и востребованность, быстро заняв свою нишу как на российском, так и на международном рынках. С момента запуска получено более сорока заявок на демонстрацию и пилотные проекты от ведущих Enterprise-заказчиков. К 2025 г. Kaspersky Container Security используется в ряде крупных банков, телеком-компаниях, ретейле и промышленных предприятий. Причем решение востребовано не только в России: сегодня есть реализованные внедрения за рубежом, что подтверждает его универсальность и высокую конкурентоспособность. О реальных историях успешного внедрения Kaspersky Container Security можно узнать на сайте решения [6].