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

Содержание

1. Краткое содержание статьи
2. Введение
3. Что такое технологии виртуализации и контейнеризации
4. Почему безопасность виртуализации и контейнеризации стала критичной
5. Архитектура безопасной виртуальной и контейнерной среды
6. Основные угрозы виртуализации
7. Основные угрозы контейнеризации
8. Типичные ошибки компаний
9. Лучшие практики защиты виртуализации
10. Лучшие практики защиты контейнеризации
11. Российский рынок и отечественные решения
12. Сравнение подходов: VM, контейнеры и гибридная модель
13. Практический сценарий: безопасный CI/CD для контейнеров
14. Практический сценарий: защита виртуальной инфраструктуры
15. Таблица преимуществ и недостатков
16. Чек-лист внедрения защиты
17. Часто задаваемые вопросы
18. Рекомендации эксперта
19. Основные выводы
20. Как оценить эффективность защиты
21. Мини-схема зрелости защиты
22. Примеры безопасных настроек
23. План внедрения на 90 дней
24. Что проверять перед публикацией системы в production
25. Источники и нормативная база

Краткое содержание

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

Для российского рынка тема особенно актуальна из-за импортозамещения, роста использования отечественных платформ виртуализации и развития Kubernetes-платформ. В 2025 году, по данным TAdviser, российский рынок систем виртуализации достиг 19,4 млрд рублей, а доля российских поставщиков в серверной виртуализации увеличилась до 80–86% в зависимости от методики оценки. Это означает, что компании переходят от вопроса «чем заменить VMware» к вопросу «как безопасно эксплуатировать новую виртуальную и контейнерную инфраструктуру».

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

Введение

Виртуализация и контейнеризация давно перестали быть технологиями только для крупных дата-центров. Сегодня виртуальные машины используются почти в любой корпоративной инфраструктуре: от бухгалтерского сервера и VDI до частного облака и резервной площадки. Контейнеры стали стандартным способом доставки приложений: разработчики упаковывают сервисы в образы, команды DevOps разворачивают их через CI/CD, а Kubernetes управляет масштабированием, сетями, секретами и отказоустойчивостью.

На первый взгляд это выглядит как идеальная история: быстрее, дешевле, удобнее. Но в информационной безопасности редко бывает «бесплатное удобство». У каждой новой абстракции появляется собственная поверхность атаки. У гипервизора — уязвимости, ошибки изоляции, проблемы управления снапшотами и доступом к консоли. У контейнеров — небезопасные образы, секреты в Dockerfile, привилегированные контейнеры, неправильный RBAC, открытый Kubernetes API, отсутствие сетевых политик и слабый контроль рантайма.

Важно понимать: контейнер — не маленькая виртуальная машина. Это процесс, изолированный средствами ядра Linux: namespaces, cgroups, capabilities, seccomp, AppArmor или SELinux. Если настройки сделаны плохо, контейнер может получить слишком много прав, увидеть лишние ресурсы или стать точкой входа на узел. А если узел скомпрометирован, под угрозой оказываются все workloads, которые на нём работают.

В России ситуация имеет дополнительный слой сложности. Компании массово переходят на отечественные решения виртуализации, меняют платформы, переносят нагрузки, переобучают администраторов и перестраивают процессы эксплуатации. Параллельно растёт интерес к Kubernetes и контейнерным платформам: Deckhouse, Nova Container Platform, платформы на базе Kubernetes у российских облачных провайдеров, решения безопасности контейнеров от Kaspersky и Positive Technologies. В такой ситуации ошибочно воспринимать миграцию как простой «переезд с одного гипервизора на другой». На практике это полноценная перестройка модели эксплуатации и защиты.

Эта статья написана для специалистов ИБ, ИТ-директоров, владельцев бизнеса, заказчиков и начинающих специалистов. Мы разберём, какие угрозы есть у виртуализации и контейнеризации, какие ошибки чаще всего допускают компании, как выстроить защиту и какие российские решения стоит рассматривать в контексте локального рынка.

Что такое технологии виртуализации и контейнеризации

Технологии виртуализации позволяют запускать несколько изолированных виртуальных машин на одном физическом сервере. Каждая виртуальная машина имеет собственную операционную систему, виртуальные диски, сетевые адаптеры и набор ресурсов. За разделение отвечает гипервизор: VMware ESXi, KVM, Hyper-V, zVirt, Basis Dynamix, vStack, РЕД Виртуализация, Astra Linux «Брест» и другие платформы.

Технологии контейнеризации работают иначе. Контейнеры не запускают отдельную полноценную ОС для каждого приложения. Они используют ядро хостовой ОС, но получают изолированное пространство процессов, файловой системы, сети и ресурсов. За запуск отвечает контейнерный рантайм, например containerd, CRI-O или Docker Engine, а за оркестрацию — Kubernetes или другая платформа управления.

Главная разница для ИБ: виртуальная машина отделена гипервизором и собственной ОС, а контейнер ближе к хосту и делит с ним ядро. Поэтому контейнеры легче, быстрее стартуют и удобнее для микросервисов, но требуют более строгой дисциплины в настройках. Нельзя переносить подходы классического сервера в Kubernetes «как есть».

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

Почему безопасность виртуализации и контейнеризации стала критичной

Раньше инфраструктуру часто защищали по принципу «есть периметр, за ним серверы». Сейчас такой подход не работает. Внутри компании может быть частное облако, Kubernetes-кластер, CI/CD, несколько реестров образов, разработчики с доступом к пайплайнам, внешние подрядчики и интеграции с публичными облаками. Граница стала размытой.

NIST в SP 800-190 подчёркивает, что безопасность контейнеров должна охватывать несколько уровней: образы, реестры, оркестратор, контейнеры и хостовую ОС. Это не случайная классификация. Если защищать только Kubernetes, но не проверять образы, в кластер попадут уязвимые библиотеки или секреты. Если проверять образы, но не контролировать runtime, атака может пройти через легитимный, но скомпрометированный контейнер. Если забыть про хосты, любой escape или ошибка конфигурации станет проблемой всего узла.

У виртуализации похожая логика. Гипервизор становится критической точкой. Ошибка в нём может влиять не на одну систему, а на десятки виртуальных машин. Broadcom в 2025 году выпускала критическое уведомление VMSA-2025-0004 по уязвимостям VMware ESXi, Workstation и Fusion, включая CVE-2025-22224, где локальный администратор внутри виртуальной машины мог выполнить код в контексте VMX-процесса на хосте. Это хороший пример того, почему даже зрелые платформы требуют постоянного патчинга и мониторинга.

У контейнеров есть свой исторический пример — CVE-2019-5736 в runc. Уязвимость позволяла атакующему перезаписать бинарный файл runc на хосте и получить root-доступ при определённых условиях. Это не значит, что контейнеры «небезопасны». Это значит, что контейнеры нужно защищать с пониманием их природы: контролировать рантайм, не запускать всё от root, обновлять компоненты и не полагаться только на изоляцию по умолчанию.

Архитектура безопасной виртуальной и контейнерной среды

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

Для виртуализации базовая архитектура включает:

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

Для контейнеризации архитектура сложнее, потому что появляется цепочка поставки ПО. Безопасность начинается ещё в репозитории кода, затем проходит через сборку образа, реестр, CI/CD, admission control, оркестратор и runtime. Ошибка на любом этапе может стать инцидентом.

Базовая архитектура Kubernetes-безопасности включает:

• защищённый Kubernetes API с TLS, RBAC и многофакторным доступом для администраторов;
• разделение namespace по средам, приложениям и критичности;
• Pod Security Standards или политики через Kyverno/Gatekeeper;
• NetworkPolicy по принципу deny by default;
• отдельное управление секретами, желательно через Vault-подобные решения или KMS;
• сканирование образов на уязвимости, секреты и вредоносный код;
• admission-контроль перед запуском workload;
• runtime detection через eBPF, Falco, Kaspersky Container Security, PT Container Security или аналогичные решения;
• сбор логов в SIEM и процесс реагирования.

Почему это важно? Потому что Kubernetes без политики сети и RBAC быстро превращается в «плоскую сеть с API», где компрометация одного приложения может дать злоумышленнику путь к другим сервисам. А виртуализация без изолированной сети управления создаёт риск, что обычный пользовательский сегмент станет маршрутом к гипервизору.

Основные угрозы виртуализации

Первая группа угроз — уязвимости гипервизора. Они встречаются не каждый день, но их эффект может быть серьёзным. Гипервизор управляет памятью, CPU, сетями и дисками виртуальных машин. Если злоумышленник выходит из VM на уровень хоста, он получает доступ к самой ценной части инфраструктуры. Поэтому патчинг гипервизора должен быть отдельным процессом, а не пунктом в общем списке «когда-нибудь обновим».

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

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

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

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

Основные угрозы контейнеризации

У контейнеров главный риск — цепочка поставки. Контейнерный образ может содержать уязвимую библиотеку, секрет, вредоносный скрипт или лишний инструмент, который поможет атакующему после компрометации. Исследования Docker Hub показывали наличие вредоносных образов и секретов в публичных репозиториях. Отдельная научная работа по анализу контейнерных образов выявила секреты в 8,5% исследованных образов из Docker Hub и частных реестров. Это не «теоретическая проблема», а реальный класс ошибок.

Вторая угроза — привилегированные контейнеры. Если контейнер запускается с privileged: true, получает доступ к hostPath или работает от root без необходимости, его компрометация намного опаснее. Такой контейнер может взаимодействовать с ресурсами хоста и обходить обычные ограничения.

Третья угроза — слабый RBAC в Kubernetes. Иногда сервисным аккаунтам выдают права cluster-admin «чтобы заработало». На старте проекта это кажется быстрым решением, но потом такой аккаунт превращается в критическую дыру. Если атакующий получает токен этого аккаунта, он получает управление кластером.

Четвёртая угроза — открытый Kubernetes API. Неправильно ограниченный API-сервер может быть доступен излишне широкому кругу пользователей или сетей. Это особенно опасно при слабой аутентификации, неактуальных сертификатах и отсутствии audit logging.

Пятая угроза — отсутствие NetworkPolicy. По умолчанию многие кластеры позволяют pod-to-pod взаимодействие без строгих ограничений. Если приложение скомпрометировано, злоумышленник может сканировать внутренние сервисы, искать базы данных, Redis, Elasticsearch, метаданные облака или сервисы администрирования.

Шестая угроза — секреты. Kubernetes Secrets не являются «магической сейфовой ячейкой». Их нужно шифровать на уровне etcd, ограничивать RBAC, исключать попадание в логи, Helm values и Git. NSA/CISA в рекомендациях по hardening Kubernetes прямо указывает на необходимость хранить чувствительные данные в Secrets и шифровать их сильным механизмом.

Типичные ошибки компаний

Ошибка 1. Считать контейнеры полноценной заменой виртуальным машинам. Контейнеры решают другие задачи. Они не дают такой же границы изоляции, как отдельная VM. Для нагрузок с разными уровнями доверия иногда разумнее сочетать VM и контейнеры: например, запускать отдельные Kubernetes-кластеры или node pools в разных изолированных виртуальных средах.

Ошибка 2. Запускать образы из публичных реестров без проверки. Даже популярный образ может содержать устаревшие зависимости. А похожее название может быть typosquatting-атакой. Зрелая компания использует внутренний registry, проверку подписей, allow-list базовых образов и сканирование на каждом этапе.

Ошибка 3. Отдавать безопасность контейнеров только DevOps-команде. DevOps отвечает за скорость и стабильность, но без участия ИБ команда может принять слишком рискованные компромиссы. Правильный подход — DevSecOps, где проверки встроены в pipeline и не воспринимаются как внешний тормоз.

Ошибка 4. Не включать audit logging. Без журналов Kubernetes API, событий контейнеров и действий администраторов расследование превращается в догадки. Логи должны уходить в централизованное хранилище и SIEM.

Ошибка 5. Не тестировать восстановление. Виртуальная и контейнерная инфраструктура должна иметь сценарии восстановления: etcd backup, backup registry, резервирование control plane, бэкапы persistent volumes, проверка восстановления VM и Kubernetes namespace.

Ошибка 6. Настраивать всё вручную. Ручные правки в Kubernetes и гипервизоре со временем приводят к конфигурационному хаосу. Зрелые компании используют Infrastructure as Code, GitOps, шаблоны политик и контроль drift.

Лучшие практики защиты виртуализации

Для виртуальной инфраструктуры базовая защита строится вокруг гипервизора, сети управления и жизненного цикла VM. Начните с изоляции management-сегмента. Консоли гипервизоров, vCenter-подобные системы и панели управления должны быть доступны только администраторам через защищённый канал. MFA для административного доступа — не опция, а базовая мера.

Второй слой — ролевой доступ. Разные роли должны иметь разные права: администратор платформы, оператор VM, сетевой инженер, аудитор. Не нужно выдавать полный доступ всем, кто иногда перезапускает виртуальную машину. Все действия должны логироваться.

Третий слой — сегментация виртуальных сетей. Разделяйте production, test, DMZ, базы данных, административные сервисы и резервные площадки. Между зонами должны быть правила межсетевого экранирования, а не «всё ходит ко всему».

Четвёртый слой — обновления. Для гипервизора, управляющих компонентов, guest tools и шаблонов VM нужен регулярный patch management. Критические advisory должны обрабатываться вне общего цикла, особенно если есть признаки эксплуатации в реальном мире.

Пятый слой — резервное копирование. Используйте правило 3-2-1, изолированные копии, immutability или WORM-хранилища. Проверяйте восстановление не реже, чем раз в квартал, а для критичных систем — чаще.

Шестой слой — безопасные шаблоны. Golden image должен проходить hardening, обновления, антивирусную проверку, отключение лишних сервисов, настройку логирования и удаление временных ключей. Новая VM должна быть безопасной с момента создания.

Лучшие практики защиты контейнеризации

Для контейнеризации ключевой принцип — shift left, но не только. Проверки должны начинаться в разработке, но защита должна продолжаться в рантайме.

На этапе кода используйте SAST, dependency scanning и secret scanning. Любой токен в Git — потенциальный инцидент. Даже если репозиторий приватный, секреты не должны попадать в историю коммитов.

На этапе сборки используйте минимальные базовые образы. Не устанавливайте в production-образ компиляторы, отладчики, curl, bash и прочие инструменты, если они не нужны приложению. Чем меньше образ, тем меньше поверхность атаки.

На этапе registry включите сканирование образов, подпись и контроль доступа. Образы должны храниться во внутреннем реестре. Старые образы нужно удалять или переводить в архив с понятным сроком хранения.

На этапе admission control запретите запуск образов без подписи, с критическими уязвимостями, root-пользователем, privileged-режимом, hostNetwork, hostPID, hostIPC и небезопасными hostPath. Эти правила можно реализовать через Kyverno, OPA Gatekeeper или коммерческие решения.

На этапе runtime включите мониторинг системных вызовов и поведения контейнеров. eBPF-подход позволяет видеть, какие процессы запускаются, какие сетевые соединения создаются и какие файлы читаются. Здесь помогают Falco, Cilium Tetragon, Kaspersky Container Security, PT Container Security и аналоги.

На уровне Kubernetes настройте RBAC по принципу минимальных прав, NetworkPolicy, Pod Security Standards, audit logging, шифрование Secrets, регулярный аудит admission webhooks и контроль kubeconfig-файлов.

Российский рынок и отечественные решения

Российский рынок виртуализации после 2022 года прошёл быстрый разворот. По данным TAdviser, в 2025 году затраты на российском рынке систем виртуализации достигли 19,4 млрд рублей, а доля российских поставщиков в серверной виртуализации выросла до 80%. В сегменте серверной виртуализации также отмечается доля российских разработчиков до 86% по отдельным оценкам. Это означает, что компании уже не просто тестируют отечественные платформы, а переводят на них рабочие нагрузки.

Среди российских платформ виртуализации часто рассматривают Basis Dynamix и Basis vCore, zVirt от Orion Soft, vStack, РЕД Виртуализация, Astra Linux «Брест», Rosa Virtualization, «Скала^р МВ» и другие решения. Выбор зависит от масштаба инфраструктуры, требований к VDI, поддерживаемых ОС, API, отказоустойчивости, интеграции с резервным копированием, сертификации и доступности партнёрской поддержки.

В контейнеризации заметны платформы на базе Kubernetes: Deckhouse Kubernetes Platform, Nova Container Platform, решения российских облачных провайдеров и внутренние корпоративные Kubernetes-платформы. Здесь важно оценивать не только удобство развёртывания, но и безопасность: управление сертификатами, обновления Kubernetes, поддержка admission policies, интеграция с registry, журналирование и поддержка отечественных ОС.

В сегменте контейнерной безопасности есть два заметных российских класса решений. Первый — комплексные платформы защиты контейнеров, например Kaspersky Container Security и PT Container Security. Kaspersky Container Security заявляет защиту от этапа разработки до рантайма: сканирование образов и IaC, проверку на уязвимости и секреты, контроль запуска, защиту оркестратора, runtime-контроль, инвентаризацию ресурсов и аудит соответствия. PT Container Security ориентирован на защиту Docker/Kubernetes и DevSecOps-сред, включая проверки образов и конфигураций, управление настройками Kubernetes и runtime security на базе eBPF.

Второй класс — open-source и инфраструктурные инструменты, которые часто используются вместе с коммерческими продуктами: Trivy, Grype, Syft, Cosign, Kyverno, OPA Gatekeeper, Falco, Cilium, Sealed Secrets, External Secrets Operator. Они не заменяют процесс и экспертизу, но позволяют быстро закрыть базовые технические задачи.

Сравнение подходов: VM, контейнеры и гибридная модель

Мой практический вывод: для большинства российских компаний оптимальна гибридная модель. Критичные и legacy-системы остаются на VM, новые микросервисы разворачиваются в Kubernetes, а управление безопасностью строится единообразно: централизованные логи, IAM, сегментация, резервное копирование, сканирование уязвимостей и контроль изменений.

Практический сценарий: безопасный CI/CD для контейнеров

Представим компанию, которая разрабатывает внутренний сервис для клиентов. Разработчик пишет код, отправляет его в Git, pipeline собирает Docker-образ и разворачивает приложение в Kubernetes. Где здесь безопасность?

1. При коммите запускается secret scanning и SAST.
2. При сборке используется минимальный базовый образ из внутреннего registry.
3. Dockerfile проверяется на root-пользователя, лишние capabilities и небезопасные команды.
4. После сборки образ сканируется на CVE, вредоносный код и секреты.
5. SBOM сохраняется вместе с образом.
6. Образ подписывается Cosign или другим механизмом подписи.
7. Admission controller разрешает запуск только подписанных образов из доверенного registry.
8. Pod запускается без root, с readOnlyRootFilesystem, без privilege escalation и с ограничениями CPU/RAM.
9. NetworkPolicy разрешает доступ только к нужным сервисам.
10. Runtime security отслеживает запуск необычных процессов, сетевые соединения и доступ к чувствительным файлам.
11. Все события уходят в SIEM.

Такой pipeline не делает компанию «неуязвимой», но сильно снижает вероятность типовых ошибок. Главное — проверки работают автоматически и не зависят от того, вспомнил ли инженер вручную посмотреть Dockerfile.

Практический сценарий: защита виртуальной инфраструктуры

Другой пример — компания переносит часть сервисов с VMware на отечественную платформу виртуализации. Риск здесь не только технический, но и организационный. Администраторы привыкли к одному интерфейсу, схемы backup были настроены под прежнюю платформу, мониторинг собирал события из старого API. Если просто перенести VM, можно потерять часть контроля.

Правильный сценарий миграции выглядит иначе:

1. Составить реестр VM, владельцев, сетей и критичности.
2. Разделить нагрузки по зонам доверия.
3. Проверить совместимость ОС и приложений.
4. Настроить отдельный management-сегмент.
5. Включить MFA и RBAC для администраторов.
6. Подключить события новой платформы к SIEM.
7. Проверить резервное копирование и восстановление.
8. Обновить регламенты и инструкции для эксплуатации.
9. Провести тест отказа и восстановления.
10. Провести внутренний аудит настроек.

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

Таблица преимуществ и недостатков

Чек-лист внедрения защиты

Для виртуализации

• Сеть управления гипервизорами изолирована.
• Включён MFA для административного доступа.
• Настроена ролевая модель с минимальными правами.
• Все действия администраторов логируются.
• Гипервизор и компоненты управления обновляются по регламенту.
• VM разделены по зонам критичности.
• Шаблоны VM проходят hardening и регулярные обновления.
• Снапшоты имеют срок жизни и владельца.
• Backup изолирован от основной инфраструктуры.
• Восстановление регулярно тестируется.

Для контейнеризации

• Используются только доверенные базовые образы.
• Образы сканируются на CVE, malware и secrets.
• Образы подписываются и проверяются перед запуском.
• Registry закрыт от публичного доступа и защищён RBAC.
• Kubernetes API доступен только из доверенных сетей.
• Настроен RBAC по минимальным правам.
• Включены Pod Security Standards или policy engine.
• По умолчанию запрещены privileged containers.
• Настроены NetworkPolicy.
• Secrets шифруются и не хранятся в Git.
• Включён Kubernetes audit logging.
• Runtime security подключён к SIEM/SOC.
• Есть резервные копии etcd, registry и persistent volumes.

Часто задаваемые вопросы

Что безопаснее: виртуальные машины или контейнеры?

Нет универсального ответа. Виртуальные машины дают более сильную границу изоляции за счёт отдельной ОС и гипервизора. Контейнеры быстрее и удобнее для микросервисов, но требуют строгой настройки Kubernetes и контроля цепочки поставки. В критичных средах часто используют комбинацию: контейнеры внутри изолированных VM или отдельных кластеров.

Можно ли использовать Kubernetes без отдельного решения контейнерной безопасности?

Можно, но риск выше. Минимум нужны сканирование образов, RBAC, NetworkPolicy, Pod Security Standards, secret management и audit logging. Для production-среды желательно добавить runtime security и интеграцию с SIEM.

Нужно ли сканировать образы, если используются официальные базовые образы?

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

Почему нельзя запускать контейнеры от root?

Если приложение работает от root внутри контейнера и возникает escape или небезопасное монтирование, последствия могут быть серьёзнее. Docker rootless mode и Kubernetes securityContext помогают снижать риск, но их нужно правильно внедрять и тестировать.

Как связаны контейнерная безопасность и DevSecOps?

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

Какие российские решения стоит рассмотреть?

Для виртуализации — Basis Dynamix/vCore, zVirt, vStack, РЕД Виртуализация, Astra Linux «Брест», Rosa Virtualization и другие платформы. Для контейнерной безопасности — Kaspersky Container Security, PT Container Security, а также open-source-инструменты вроде Trivy, Kyverno, OPA Gatekeeper, Falco и Cilium в составе архитектуры.

Что важнее: сетевые политики или сканирование образов?

Это разные уровни защиты. Сканирование образов снижает риск запуска уязвимого или вредоносного кода. NetworkPolicy ограничивает распространение атаки внутри кластера. Зрелая архитектура использует оба механизма.

Рекомендации эксперта

Не начинайте с покупки «лучшего продукта». Начните с модели угроз и инвентаризации. Сколько у вас гипервизоров? Какие VM критичны? Где находятся контейнерные образы? Кто может пушить в registry? Кто имеет cluster-admin? Какие секреты есть в Git? Ответы на эти вопросы часто дают больше пользы, чем презентация любого вендора.

Виртуализацию защищайте как критичную инфраструктурную платформу. Контейнеризацию — как непрерывную цепочку поставки ПО. Это разные подходы. У виртуализации важны стабильность, резервирование, доступы и патчи. У контейнеров — скорость изменений, автоматические политики и наблюдаемость.

Для российского рынка важна ещё одна деталь: при миграции на отечественные решения не копируйте старые настройки вслепую. Перенос платформы — хороший момент пересмотреть архитектуру. Если раньше management-сеть была доступна слишком широко, не нужно переносить эту ошибку в новую систему. Если старые VM создавались из небезопасного шаблона, миграция — повод сделать новый hardened baseline.

С точки зрения продаж и внедрения, заказчику важно объяснять не «у нас есть контейнерная безопасность», а конкретную пользу: сокращение риска простоя, снижение вероятности утечки секретов, контроль соответствия требованиям, сокращение ручной работы ИБ и DevOps, ускорение безопасных релизов. Бизнесу понятен не список технологий, а управляемый риск.

Основные выводы

1. Виртуализация и контейнеризация решают разные задачи и имеют разные модели угроз.
2. Контейнеры не являются «маленькими VM» и требуют защиты цепочки поставки, Kubernetes и рантайма.
3. NIST рекомендует защищать контейнерную среду по уровням: образы, реестры, оркестратор, контейнеры и хостовую ОС.
4. Критические уязвимости гипервизоров и контейнерных рантаймов подтверждают необходимость патчинга и мониторинга.
5. Основные ошибки — привилегированные контейнеры, слабый RBAC, отсутствие NetworkPolicy, секреты в Git и публичные образы без проверки.
6. Российский рынок виртуализации и контейнерных платформ быстро развивается, но миграция требует пересмотра архитектуры безопасности.
7. Зрелый подход сочетает DevSecOps, hardening, policy-as-code, runtime security, SIEM и регулярные проверки восстановления.
8. Лучший результат даёт не один продукт, а система процессов: инвентаризация, модель угроз, автоматические проверки, ответственность команд и мониторинг.

Как оценить эффективность защиты

Защита виртуализации и контейнеризации должна измеряться не количеством купленных продуктов, а понятными показателями. Если после внедрения сканера образов разработчики продолжают запускать контейнеры с критическими CVE, значит процесс не работает. Если SIEM получает события Kubernetes, но никто не разбирает алерты, это тоже не защита, а «склад логов». Поэтому зрелые компании используют метрики.

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

Для контейнеризации метрики другие: доля образов из доверенного registry, доля подписанных образов, количество critical/high уязвимостей в production, число workloads с privileged-режимом, количество service accounts с правами cluster-admin, доля namespace с NetworkPolicy, количество секретов, найденных в Git и образах, время устранения критичной уязвимости в базовом образе.

Почему это важно? Без метрик безопасность превращается в субъективное ощущение. Команда может считать кластер защищённым, потому что «мы поставили сканер», а аудит покажет десятки root-контейнеров и открытый Kubernetes API. Метрики дисциплинируют и ИТ, и ИБ, и разработку.

Какие ошибки встречаются чаще всего? Компании считают только количество найденных уязвимостей и не смотрят на эксплуатационную реальность. Уязвимость в неиспользуемом dev-образе и уязвимость в production-ingress — разные риски. Зрелые команды ранжируют проблемы по критичности сервиса, доступности из сети, наличию exploit и возможности компенсирующих мер.

Мини-схема зрелости защиты

Уровень 0 — хаос. Нет инвентаризации VM и контейнеров, образы скачиваются из публичных источников, доступы выдаются вручную, логи хранятся локально, правила восстановления не проверяются. На этом уровне инциденты обнаруживаются случайно: по жалобам пользователей или недоступности сервиса.

Уровень 1 — базовый порядок. Есть перечень критичных систем, гипервизоры обновляются, появились внутренние registry и минимальные правила Kubernetes. Но процессы всё ещё ручные: кто-то должен не забыть проверить образ, выдать доступ, убрать лишний снапшот. Риск человеческой ошибки остаётся высоким.

Уровень 2 — управляемая безопасность. Появляется автоматизация: сканирование образов в CI/CD, RBAC-шаблоны, NetworkPolicy, централизованный сбор логов, регулярные тесты восстановления. ИБ участвует в проектировании платформы, а не приходит после релиза.

Уровень 3 — policy-as-code и DevSecOps. Политики описаны как код, инфраструктура разворачивается через Terraform/Ansible/GitOps, admission controller блокирует небезопасные workload автоматически, а разработчик получает понятную ошибку в pipeline. Runtime-события уходят в SIEM/SOC, есть playbooks реагирования.

Уровень 4 — непрерывная устойчивость. Компания регулярно проводит tabletop exercises, chaos engineering для отказоустойчивости, purple team для проверки детекта, автоматическое обновление базовых образов и контроль drift. Безопасность становится частью платформы, а не отдельной проверкой перед аудитом.

Примеры безопасных настроек

Ниже не готовые универсальные конфигурации, а ориентиры. Их нужно адаптировать под конкретную инфраструктуру.

Пример securityContext для Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          image: registry.example.local/example/app:1.0.0
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

Что здесь важно? Контейнер не запускается от root, не получает escalation, файловая система доступна только для чтения, capabilities сброшены, service account token не монтируется автоматически. Это снижает ущерб даже в случае компрометации приложения.

Пример базовой NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-by-default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Такую политику нельзя просто включить в production без подготовки: можно остановить сервисы. Но сама идея правильная — сначала deny by default, затем явные разрешения между нужными сервисами. Зрелые компании тестируют такие политики в staging и постепенно переносят в production.

План внедрения на 90 дней

Первые 30 дней: провести инвентаризацию VM, контейнерных кластеров, registry, CI/CD и владельцев сервисов. Найти административные доступы, публичные API, критичные namespace, образы без владельца и устаревшие шаблоны VM. На этом этапе не нужно пытаться всё исправить сразу; задача — увидеть реальную картину.

31–60 день: закрыть быстрые риски. Ограничить доступ к management-сетям, включить MFA, убрать лишние cluster-admin, запретить privileged-контейнеры там, где они не нужны, включить сканирование образов и secret scanning, настроить базовый сбор логов. Параллельно согласовать целевую архитектуру.

61–90 день: перейти к управляемому процессу. Внедрить admission policies, настроить NetworkPolicy для критичных namespace, подключить runtime security, описать регламенты патчинга и восстановления, провести тест восстановления VM и Kubernetes-компонентов, зафиксировать метрики и владельцев процесса.

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

Что проверять перед публикацией системы в production

Перед запуском виртуальной или контейнерной платформы задайте команде десять вопросов:

1. Кто владелец каждой критичной VM, namespace и registry?
2. Какие данные обрабатываются внутри системы?
3. Какой минимальный набор сетевых взаимодействий нужен приложению?
4. Кто имеет административный доступ и как он подтверждается?
5. Как быстро мы узнаем о подозрительном действии?
6. Где хранятся логи и сколько времени они доступны?
7. Как восстанавливаются VM, etcd, registry и persistent volumes?
8. Что произойдёт, если один контейнер будет скомпрометирован?
9. Какие политики автоматически блокируют небезопасный запуск?
10. Кто принимает решение об исключениях и как долго они действуют?

Если на эти вопросы нет ответов, production ещё не готов. Это звучит жёстко, но именно такие вопросы предотвращают инциденты.

Источники и нормативная база

1. NIST SP 800-190, Application Container Security Guide — https://csrc.nist.gov/pubs/sp/800/190/final
2. Kubernetes Security Concepts — https://kubernetes.io/docs/concepts/security/
3. Kubernetes Pod Security Standards — https://kubernetes.io/docs/concepts/security/pod-security-standards/
4. Docker Rootless Mode — https://docs.docker.com/engine/security/rootless/
5. NVD CVE-2019-5736 — https://nvd.nist.gov/vuln/detail/CVE-2019-5736
6. Broadcom VMSA-2025-0004 — https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisor...
7. TAdviser: Виртуализация, рынок России — https://www.tadviser.ru/index.php/Статья:Виртуализация_(рынок_России)
8. Kaspersky Container Security — https://www.kaspersky.ru/enterprise-security/container-security
9. PT Container Security — https://ptsecurity.com/products/cs/