Почему обычный сканер пасует в Kubernetes: VM для контейнеров и облаков

📚Это часть 18 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку, оглавление и все части серии тут.

Мир уходит от “железных” серверов в стойке к контейнерам и облакам. Это удобно, быстро и дешево, но управление уязвимостями в этих средах устроено иначе, и классический сканер тут часто бессилен.

Показательна история Tesla. В феврале 2018 года исследователи RedLock обнаружили: административная панель Kubernetes в облаке Tesla была открыта в интернет без пароля. Через один из подов злоумышленники добрались до AWS-кредов и запустили майнинг криптовалюты: трафик прятали за Cloudflare, порт использовали нестандартный, нагрузку на CPU намеренно занижали, чтобы не спалиться. Tesla закрыла дыру за несколько часов после уведомления по bug bounty. Ни одной уязвимости в коде, только рядовая ошибка конфигурации, которая отдала атакующим доступ к инфраструктуре.

Контейнеры: что это и почему сложно

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

Прижились они почти везде. По данным Red Hat State of Kubernetes Security Report (2024), 89% организаций за последний год столкнулись хотя бы с одним инцидентом безопасности, связанным с контейнерами или Kubernetes. При этом часть компаний прямо не спешит переходить в облако именно из-за опасений за безопасность. Контейнеры - это удобно, но это и новая большая поверхность атаки.

Самая распространенная платформа контейнеризации - Docker. Его части: host, узел, на котором установлен Docker; Docker daemon, центральный компонент, управляющий образами и контейнерами; Dockerfile, текстовый файл с инструкциями по сборке образа; Docker image, образ со всеми компонентами для работы приложения; Docker Registry или Docker Hub, хранилище образов; Docker Client, через который пользователь с Docker и работает.

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

Почему обычный сканер не справляется

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

Контейнеры эфемерны. Они создаются и уничтожаются динамически, их количество меняется в зависимости от нагрузки. Что здесь вообще считать активом? Контейнер, который прожил 30 секунд и исчез? Классическая модель “актив = сервер с IP-адресом” здесь ломается.

Внутренняя сеть невидима снаружи. Контейнеры живут в своей внутренней сети, недоступной извне. Просканировать сервис из десятой внутренней подсети кластера, находясь в сети 192.168, - задача со звездочкой.

Для классических систем контейнеры ведут себя странно. Реальный пример с узла кластера Kubernetes: одна команда показывает, что работает процесс из определенного каталога, а другая - что каталог пуст. От такого классическая SIEM-система начинает сходить с ума и сыпать ложными тревогами.

И безопасность нужна на каждом этапе, а не в одном только проде. Уязвимость может попасть в контейнер еще на этапе сборки, из базового образа или зависимости. Ловить ее в проде поздно.

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

Container Security: правильный инструмент

Для контейнеров существует отдельный класс решений - container security. VM-система и сканер уязвимостей работают с контейнерами, которые уже в промышленной эксплуатации, то есть с тем, что уже запущено. Container security автоматизирует управление уязвимостями и дефектами конфигурации на всех этапах жизненного цикла: на сборке можно заблокировать сборку контейнера с уязвимостями или дефектами, и уязвимость не попадет в прод вообще; на развертывании - заблокировать подозрительные изменения конфигурации и доступ к образам из неразрешенных реестров; в рантайме - мониторить и реагировать на инциденты прямо во время работы контейнера.

Плюс container security управляет безопасностью конфигурации всего кластера Kubernetes. Для проверки соответствия конфигурации лучшим практикам можно использовать инструменты вроде Docker Bench for Security или адаптированные стандарты, но в идеале - писать собственные требования под свою инфраструктуру.

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

• Привилегированные поды. Привилегированный контейнер получает доступ ко всем capabilities ядра и устройствам хоста, по сути то же самое, что и сам хост. Прямой путь к побегу из контейнера. CIS Kubernetes Benchmark (пункт 5.2.2) требует блокировать такие поды через admission control, но по умолчанию Kubernetes ничего не ограничивает.

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

• Раздутые права RBAC. Роль cluster-admin выдают сервис-аккаунтам “на всякий случай”, и она остается там годами. Руководство NSA и CISA по харденингу Kubernetes и тот же CIS Benchmark требуют принципа минимальных привилегий: не раздавать wildcard-права и не плодить cluster-admin там, где хватит namespace-scoped роли.

Из инструментов в мире open source популярны Trivy (от Aqua Security, сканирует образы, IaC, секреты, Kubernetes), Grype, Clair. В России развиваются коммерческие решения: PT Container Security (Positive Technologies), Kaspersky Container Security (с 2026 года с ИИ-помощником KIRA, который объясняет находки сканирования простым языком), Luntry (платформа безопасности Kubernetes). Импортозамещение и требования к сертификации подталкивают компании к отечественным решениям, и спрос на них только растет.

Отдельная головная боль - цепочка поставок: откуда вы знаете, что образ настоящий? Кто угодно может выложить в реестр образ с чужим именем и подсунуть внутрь бэкдор. Решение - подпись образов. Sigstore, проект Linux Foundation, запущенный в марте 2021 года при поддержке Red Hat и Google, дает бесплатную инфраструктуру для подписи артефактов без своего удостоверяющего центра. Инструмент cosign из этой экосистемы подписывает и проверяет OCI-образы: сборка подписывается автоматически в CI, а при деплое кластер проверяет подпись и блокирует все неподписанное. К 2024 году Sigstore дорос до graduated-проекта OpenSSF и лег в основу provenance-механизмов npm, PyPI и GitHub, по сути стал стандартом де-факто.

Вторая часть головоломки - SBOM (Software Bill of Materials), полный список всего, что зашито в образ: библиотеки, версии, лицензии. В США SBOM требуют от поставщиков федерального правительства с президентского указа 14028 (май 2021 года). В Евросоюзе похожее требование вводит Cyber Resilience Act: отчетность об уязвимостях обязательна с сентября 2026 года, полный SBOM-мандат - с декабря 2027-го. Форматов два: SPDX (Linux Foundation, стандартизирован как ISO/IEC 5962) и CycloneDX (OWASP). Без SBOM узнать, что где-то в третьем слое зависимостей сидит уязвимая библиотека вроде log4j, можно разве что случайно.

Облака: разделенная ответственность

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

Многие наивно полагают: “Мы в облаке, значит, провайдер за все отвечает”. Нет. Провайдер не настроит за вас права доступа, не закроет уязвимость в вашем приложении, не уберет пароль “admin” из вашей базы. Это ваша зона ответственности.

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

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

Сканировать на уязвимости в облаке сложнее: динамическое масштабирование, контейнеры, бессерверные (serverless) архитектуры. Нужны специализированные инструменты, умеющие работать с временными ресурсами и API облачных провайдеров. В своей инфраструктуре ресурсы стабильны, традиционные методы работают хорошо.

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

Для соответствия требованиям в облаке важно изучать соглашения с провайдером и учитывать применимые стандарты. И тут для российских компаний есть критичный нюанс: требования по защите КИИ и президентские указы жестко ограничивают, где и как могут размещаться данные и какие средства защиты применяться. Указ № 166 запрещает иностранное ПО на значимых объектах КИИ, Указ № 250 с 2025 года запрещает использовать зарубежные средства и услуги информационной безопасности. Зарубежные облака для значимых систем во многих случаях просто запрещены, поэтому российский бизнес активно переходит на отечественные облачные платформы.

У облаков есть и свои риски. Доступ к данным из любой точки мира открывает потенциал для атак через интернет, особенно когда подключается множество пользователей с разных устройств. Многие клиенты используют общие физические серверы (multi-tenancy), и уязвимость в гипервизоре или компрометация соседа теоретически может затронуть и вас. И появляется новая категория инсайдеров - сотрудники провайдера, у которых есть доступ к инфраструктуре.

Как подходить к защите облака

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

Используйте инструменты управления уязвимостями для облака. Зарубежные провайдеры предлагают встроенные сервисы (Amazon Inspector, Microsoft Defender for Cloud, бывший Azure Security Center). Появился даже отдельный класс решений - CNAPP (Cloud-Native Application Protection Platform), объединяющий защиту облачной конфигурации, рабочих нагрузок и прав доступа. Мировой лидер - Wiz: сделку по покупке Google объявили в марте 2025-го за рекордные 32 млрд долларов, а закрыли только через год, в марте 2026-го; сумма и срок показывают, насколько горяча эта тема. У российских провайдеров стоит уточнять, какие инструменты они предоставляют.

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

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

А как у вас?

Сканируете образы на этапе сборки или ловите уязвимости уже в проде? И честно: в вашей команде все четко понимают, за какую часть облачной безопасности отвечаете вы, а за какую провайдер?

Навигация по серии: ⬅️ Предыдущая: Гл. 17. CTEM без хайпа · 📑Оглавление серии · Следующая: Гл. 19. AI в управлении уязвимостями➡️

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