Безопасность контейнеров: риски и защита

Изображение: recraft

Контейнеры и виртуальные машины давно перестали быть игрушкой DevOps-команды и сегодня обслуживают жизненно важные сервисы — от платёжных платформ до технологических процессов в АСУ ТП. Однако с ростом масштаба инфраструктуры расширяется и «площадь атаки». Так, исследование показало, что свыше 30 % официальных образов в Docker Hub содержат критические CVE, причём речь идёт именно о «заверенных» репозиториях, которые многие считают безопасными по умолчанию. В runtime-среде ситуация не лучше: знаменитая уязвимость CVE-2019-5736 позволяла вырваться из контейнера на хост буквально одной командой. И если раньше подобные происшествия редко переходили за пределы лаборатории, то в 2024 г. утечка данных фиксировалась уже в 52 % успешных атак на организации.

Когда возникает «точка невозврата» и пора ставить СЗИ?

Факторы для виртуализированных серверов:

• ввод в эксплуатацию продуктов (ГИС / ЗО КИИ / АСУ ТП / ИСПДн), подпадающих под 152‑ФЗ и 187‑ФЗ (или на которые распространяется действие приказов ФСТЭК России 17, 21, 31, 239);
• Развёртывание критичных сервисов (AD, PKI, SIEM) в ВМ/контейнерах;
• Рост East‑West‑трафика в L2‑сегменте vSwitch — повышенный риск бокового движения злоумышленника.

Факторы для контейнеров в частности:

• появление регулярного CI/CD‑конвейера → необходимость shift‑left‑сканирования образов;
• пилот Kubernetes/OpenShift, где escape‑атака способна компрометировать весь узел;
• контейнеры обрабатывают ПД или ЗО КИИ — автоматически подпадают под приказ ФСТЭК России № 118.

Cтатистика Red Hat за 2024 г.: почти 90 % компаний пережили хотя бы один Kubernetes‑инцидент за последние 12 месяцев.

Правило 24 часов. Если виртуальная машина или pod живёт дольше суток и обрабатывает чувствительные данные – она должен входить в периметр СЗИ, иначе ретроспективу инцидента собрать не удастся.

Актуальные угрозы

1. Побег из контейнера. Атакующий прорывается из pod’а на host-узел и получает root-доступ ко всему кластеру;
2. Supply-chain-атаки. Вредоносный код внедряют ещё в образ или публичную зависимость — эксплойт попадает в прод автоматически при сборке;
3. Компрометация CI/CD. Захват runner’а или ключей развёртывания позволяет перезаписать артефакты и выкатывать «отравленные» версии приложения;
4. Боковое движение внутри кластера. Через East-West-трафик злоумышленник перескакивает с одного сервиса на другой, пока не дойдёт до «коронных драгоценностей»;
5. Кража секретов. Открытые ServiceAccount-токены, .env-файлы и неправильные RBAC-права дают доступ к базам данных и облачным API;
6. Использование ресурсов для майнинга/DDoS. Захватив pod, атакующий запускает криптомайнер или ботнет-агентов, перегружая прод-узлы.

Что требует регулятор?

Рассмотрим основные документы и ключевые положения для использования СЗИ в контейнерной среде:

Документ Ключевые положения для контейнеров ФЗ-187 ФЗ «О безопасности КИИ» Обязует субъекты КИИ использовать сертифицированные СЗИ и проводить оценку соответствия Приказ ФСТЭК РОССИИ
№ 118 (04.07.2022) Определяет классы защиты для средств контейнеризации: контроль целостности образов, изоляция, аудит, реагирование Приказ ФСТЭК РОССИИ № 239 (25.12.2017) Базовые меры для значимых объектов КИИ; требует журналировать события и обновлять базы угроз не реже одного раза в сутки ФЗ-152 «О персональных данных» Ст. 19 требует «правовых, организационных и технических» мер защиты ПДн. Если контейнер обрабатывает ПДн, к нему применяются уровни К2/К3 (или К1, если нужно) и весь перечень мер приказа № 21 Приказ ФСТЭК РОССИИ № 21 (18.02.2013) Содержит таблицу мер по уровням защищённости ПДн. Раздел XI «Защита среды виртуализации» предъявляет 10 обязательных требований к VM/контейнеру – идентификация, контроль доступа, сегментация, доверенная загрузка, перемещение контейнеров только с проверкой целостности и т. д. Приказ ФСТЭК РОССИИ № 17 (11.02.2013) Определяет 3 класса защищённости для государственных ИС. Контейнеры, развёрнутые в ГИС, должны обеспечивать те же меры (идентификация, ограничение ПО, аудит, защита среды виртуализации) по классу системы Приказ ФСТЭК РОССИИ № 31 (14.03.2014) Требования к АСУ ТП: сегментация сетей, отказоустойчивость, журналирование, модель угроз. Для контейнерных сервисов в АСУ ТП критично гарантировать изоляцию процессов и доверенную загрузку узлов

NB: в выписке из приказа ФСТЭК РОССИИ от 02 июня 2020 г. №76 «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» можно провести соответствие для СЗИ:

6-й уровень доверия можно применять:

• на значимых объектах КИИ 3-й категории;
• в государственных ИС 3-го класса защищённости;
• в АСУ ТП 3-го класса защищённости;
• в ИСПДн при необходимости обеспечения 3-го или 4-го уровня защищённости ПДн.

5-й уровень доверия можно применять:

• на значимых объектах КИИ 2-й категории;
• в государственных ИС 2-го класса;
• в АСУ ТП 2-го класса;
• в ИСПДн для 2-го уровня защищённости ПДн.

4-й уровень доверия можно применять:

• на значимых объектах КИИ 1-й категории;
• в государственных ИС 1-го класса;
• в АСУ ТП 1-го класса;
• в ИСПДн для 1-го уровня защищённости ПДн;
• в информационных системах общего пользования II класса.

СЗИ, соответствующие 1-му, 2-му, 3-му уровням доверия, применяются в информационных системах, обрабатывающих государственную тайну.

При закупке СЗИ для значимых объектов КИИ проверяйте не только наличие сертификата ≥4УД, но и соответствие функций приказу 118: не каждое «контейнерное» решение автоматически закрывает всё.

Как защищаемся?

В таблице детально разобраны общие рекомендации по защите

Уровень Зачем Что делаем Hardening хоста Уменьшить поверхность атаки узла Используем минимальный дистрибутив (distroless / immutable);Используем модули SELinux / AppArmor + seccomp;Сильно ограничиваем исходящий трафик на prod-нодах. Проверка образов и IaC Поймать уязвимости до запуска Генерируем SBOM и сканируем Dockerfile / Helm / Terraform;Используем политики-as-code (OPA, Kyverno). Runtime-мониторинг Обнаружить и блокировать аномалии Настраиваем eBPF / ptrace-хуки для системных вызовов;Следим за целостностью файлов. Сюда можно интегрировать поведенческую аналитику (UEBA) на основе системных вызовов контейнеров Сетевая сегментация Остановить боковое движение Делаем NetworkPolicy «deny-all» по умолчанию;Используем micro-segmentation (CNI или Service Mesh);Используем mTLS между сервисами. Корреляция и IR Сократить MTTR Централизованно собираем логи (Syslog / OTEL);Используем SIEM / SOAR с автоматическими playbook’ами;Автотикеты в трекер.

На что смотреть при выборе СЗИ?

• Сертификация ФСТЭК РОССИИ или письмо о соответствии;
• Покрытие полного жизненного цикла: от сканирования IaC до runtime;
• Поддержка российских ОС (Astra Linux, РЕД ОС) и K8s ≥ 1.25;
• Нагрузка агента — не более 5 % CPU и 100 МБ RAM на под;
• Интеграции DevSecOps: плагины Jenkins/GitLab/GitHub; REST API;
• Сетевые политики и eBPF-фильтрация East-West;
• Модель лицензирования (node, core, subscription) + TCO на 3–5 лет;
• Русскоязычная поддержка 24/7 и обучающие курсы для DevOps.

Если говорить о решениях, то на рынке СЗИ для защиты контейнеров сейчас популярны PT Container Security, Kaspersky Container Security, Red Check и «Купол.Контейнеры» (актуально на II кв. 2025 г.).

Пятишаговый чек-лист внедрения

1. Опишите инфраструктуру. Запишите, какие кластеры, узлы и реестры нужно защищать, укажите версии Kubernetes и сторонние CRD;
2. Сведите риски с законом. Составьте простую таблицу: «факт» → «какое требование приказа 118/21/239 его закрывает»;
3. Проведите пилот 30–45 дней. Запустите решение на тестовом кластере, замерьте нагрузку и число ложных срабатываний;
4. Посчитайте бюджет «под ключ». Учтите лицензии, железо/облако, работу команды и обучение сотрудников;
5. Закрепите правила. Утвердите SLA (например, 99,9 %), частоту обновления баз ≤ 24 ч. и порядок реагирования на инциденты.

Практические Best practice

• При написании Dockerfile пытаться не использовать права root;
• Использование mtls при межсервисном взаимодействии;
• Проверяем образы ещё до запуска. Каждый pull-request проходит сканер; есть критическая дыра — в прод не пускаем;
• Если используете Terraform / Helm, то проверяйте их линтами в pull-request;
• Сеть закрыта по умолчанию. Ставим deny-all и открываем только необходимые порты и namespace’ы;
• Минимум привилегий. Убираем hostPID, hostNetwork, лишние capabilities; pod хватает того, что нужно для его задачи;
• Автоматический лог. Все события сразу летят в SIEM — потом не придётся вручную собирать логи с узлов;
• Если обнаружена критическая уязвимость, сборка не попадает в prod.

Заключение

Защита контейнеров и виртуальных машин — это не набор «чекбоксов», а процесс, вписанный в DevSecOps. Правильная СЗИ должна не только «ловить» уязвимости, но и помогать командам выпускать код быстрее, оставаясь в рамках законодательства. Лучшие проекты CISO Club показывают: успех гарантирует пилот, в котором Dev, Sec Ops и бизнес сидят за одним столом.

Двигайтесь «слева направо», автоматизируйте контроль, а не боритесь с инцидентами вручную. Тогда и новости про очередной контейнерный CVE будут восприниматься как обычная рутина, а не повод для бессонной ночи.

📷

Автор: Георгий Абраменко, инженер компании «Газинформсервис»

Оригинал публикации на сайте CISOCLUB: "Выбор СЗИ для защиты виртуализированных серверов и контейнеров".

Смотреть публикации по категориям: Новости | Мероприятия | Статьи | Обзоры | Отчеты | Интервью | Видео | Обучение | Вакансии | Утечки | Уязвимости | Сравнения | Дайджесты | Прочее.

Подписывайтесь на нас: VK | Rutube | Telegram | Дзен | YouTube.