Две стороны изоляции: безопасность виртуальных машин и контейнеров

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

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

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

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

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

Основы технологий: два взгляда на изоляцию

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

Виртуализация: «компьютер внутри компьютера»

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

В основе технологии лежат два ключевых компонента: гипервизор и виртуальные машины.

Виртуальная машина (ВМ) – это своего рода «компьютер внутри компьютера» со своей операционной системой. Доступ ВМ к процессору, памяти и другим ресурсам физического сервера контролирует гипервизор. При этом гостевая ОС обычно работает так, будто запущена на отдельном компьютере.

Гипервизор – это программа, которая управляет виртуальными машинами и распределяет между ними ресурсы физического сервера. Гипервизоры принято делить на два типа:

• гипервизоры 1-го типа (bare-metal) работают непосредственно на физическом сервере, без промежуточной хостовой ОС. К ним относятся, например, VMware ESXi и Microsoft Hyper-V, Базис.vCore, а также решения на базе KVM. Они управляют ресурсами сервера и доступом виртуальных машин к реальным процессору, памяти и устройствам.

• гипервизоры 2-го типа (hosted) работают как обычное приложение поверх установленной ОС. Например, VirtualBox или VMware Workstation. Доступ виртуальных машин к оборудованию в этом случае происходит через ОС хоста.

Такая архитектура дает несколько важных преимуществ:

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

• Гибкость. На одном физическом сервере могут одновременно работать разные ОС (Windows, Linux, FreeBSD) со своими версиями ядра и окружением.

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

Контейнеризация: «процесс в изолированной песочнице»

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

В контейнерах изоляция строится на нескольких механизмах ядра Linux:

• Пространства имен (Namespaces). Это механизм, который изолирует разные аспекты работы приложения. Каждый контейнер получает свой собственный набор пространств, видит только свои процессы (PID), имеет свой сетевой стек (Network), свою точку монтирования файловых систем (Mount) и т. д.

• Контрольные группы (Cgroups). Ответственны за контроль над ресурсами. Они позволяют ограничивать процессорное время, память или дисковые операции, которые доступны контейнеру.

• Многослойные файловые системы (Layered FS). Контейнерные образы обычно состоят из нескольких слоев, например на базе OverlayFS. Большинство из них доступны только для чтения, а при запуске контейнера поверх создается отдельный записываемый слой. Такой подход позволяет нескольким контейнерам использовать общие базовые слои, экономить дисковое пространство и ускорять развертывание.

Физический или виртуальный сервер, который подключен к кластеру Kubernetes, называется нодой (node). На нем работает ПО, необходимое для запуска контейнеров. Минимальная единица, с которой работает Kubernetes, называется под (pod). Он может содержать один или несколько тесно связанных контейнеров, которые всегда запускаются на одной ноде. Например, основной контейнер и вспомогательный для сбора логов или проксирования трафика.

У всех контейнеров внутри пода общий сетевой namespace и IP-адрес. Они могут общаться друг с другом через localhost и могут использовать общие тома, если эти тома явно подключены к нескольким контейнерам. Kubernetes размещает контейнеры как единую единицу, хотя отдельные контейнеры внутри пода могут перезапускаться независимо.

Для работы контейнеров на сервере используется среда выполнения (runtime), например containerd и CRI‑O. Она взаимодействует с ядром ОС и через низкоуровневые компоненты, такие как runc, задействует механизмы изоляции: namespaces, cgroups, seccomp и другие средства безопасности, включая AppArmor или SELinux. Здесь находится критический рубеж – уязвимость среды выполнения может позволить злоумышленнику выйти из контейнера (container escape) и продолжить атаку уже на хостовую систему.

Поверх среды выполнения работают инструменты управления контейнера, например Docker или Podman. Они предоставляют удобный пользовательский интерфейс для сборки, хранения и запуска контейнеров, то есть фактически выступают посредниками между человеком и средой выполнения. Риски на этом уровне связаны с неправильной конфигурацией, небезопасными образами и доступом к демону (например, компрометация Docker socket может дать полный контроль над хостом).

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

Группа серверов, объединенных в единую систему для запуска и управления контейнеризованных приложений, называется кластером. Система, которая управляет таким кластером и размещением контейнерных нагрузок, называется оркестратором. Наиболее распространенный пример – Kubernetes, который берет на себя развертывание, масштабирование и поддержание работоспособности приложений. На отечественном рынке также представлены Kubernetes-решения Deckhouse Kubernetes Platform, платформа «Штурвал» и Nova Container Platform. Эти продукты включены в реестр отечественного ПО и сертифицированы ФСТЭК России.

Все это требует постоянного сопровождения: нужно своевременно устанавливать обновления, устранять уязвимости, настраивать политики безопасности, следить за доступностью и резервным копированием. Однако брать все эти задачи на себя необязательно. Крупные облачные провайдеры предлагают управляемые Kubernetes-кластеры (Managed Kubernetes). В этом случае провайдер берет на себя обслуживание мастер-узлов и инфраструктуры, а для работы с кластером доступна готовая панель управления. Другой вариант – бессерверные контейнеры (Serverless Containers). Достаточно передать платформе образ контейнера, а запуск и масштабирование она берет на себя. Среди российских решений это Yandex Serverless Containers и Evolution Container от Cloud.ru.

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

Многослойная архитектура и отсутствие дополнительных ОС, которые надо поддерживать, дают контейнерам несколько важных преимуществ перед виртуальными машинами:

• большая скорость. Контейнер запускается практически мгновенно, так как ему не нужно грузить свою ОС.

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

• портативность. Приложение можно упаковать вместе с необходимыми зависимостями и запускать в разных средах с более предсказуемым результатом.

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

После разбора базовых принципов можно перейти к рассмотрению технологиий с точки зрения безопасности.

Где что применять: сценарии использования технологий

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

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

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

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

Например, телеком-оператор «ЭР-Телеком Холдинг» внедрил отечественную Kubernetes-платформу Deckhouse Kubernetes Platform для централизованного управления микросервисными нагрузками. До перехода развертывание новых приложений занимало несколько недель, а после внедрения время сократилось до нескольких часов. Это позволило компании быстрее тестировать решения и запускать новые сервисы, а также унифицировать подходы к работе с контейнерной инфраструктурой.

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

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

Например, в публичных облаках (AWS, GCP, Azure) виртуальная машина – это базовая единица аренды, и Kubernetes-кластер разворачивается внутри ВМ. В корпоративных дата-центрах также распространен сценарий, когда контейнеры запускаются на VMware. При этом одна команда управляет виртуальным железом, другая – контейнерными платформами поверх. Такой гибридный подход позволяет сохранить привычные процессы безопасности на уровне гипервизора и получить скорость разработки, которую дают контейнеры.

Корпоративные платформы, такие как VMware Tanzu и OpenShift, позволяют централизованно управлять ВМ и контейнерами. В рамках единой платформы можно размещать как классические ВМ с унаследованными приложениями, так и поды с микросервисами, применяя к ним общие подходы к сетевому взаимодействию, доступу и политикам безопасности.

Гибридный подход особенно актуален в следующих случаях:

• при наличии большого парка унаследованных Windows-приложений, но новые сервисы разрабатываются в контейнерах;

• на этапе миграции – когда приложения постепенно оборачиваются в контейнеры, но остаются на привычных ВМ до полной готовности инфраструктуры;

• требования регулятора диктуют аппаратную изоляцию для части нагрузки.

Безопасность виртуализации

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

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

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

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

Еще в 2021 году специалисты Positive Technologies фиксировала целенаправленную адаптацию вредоносного ПО под среды виртуализации и рост количества атак на них. При этом 63% всех атак в тот период составляли программы-вымогатели. К 2025 году, по оценке Cloud Security Alliance, этот вектор стал одним из главных для операторов программ-вымогателей, а отдельные успешные инциденты приводили к ущербу в сотни миллионов долларов.

Особенно показательным стал случай, произошедший в 2025 году, когда компания Broadcom экстренно закрыла сразу три уязвимости нулевого дня в VMware ESXi (например, CVE-2025-22224), которые позволяли выйти из ВМ на уровень гипервизора. Актуальность данных атак подчеркивает и статистика Shadowserver Foundation: в первые сутки после анонса патча в интернете насчитывалось почти 41500 уязвимых экземпляров ESXi, доступных для атак извне. По данным компании Huntress, в том же 2025 году доля программ-вымогателей, нацеленных на гипервизоры (включая ESXi и Hyper-V), выросла с 3% в первой половине года до 25% во второй.

Чтобы снизить риск выхода за пределы ВМ и дальнейшей компрометации инфраструктуры, важно выстроить многоуровневую защиту:

1. Использовать актуальные версии ПО. Критические обновления и исправления безопасности следует устанавливать как можно быстрее, а процесс обновления – по возможности автоматизировать.

2. Использовать TPM (Trusted Platform Module) и Secure Boot. Эти механизмы помогают контролировать целостность платформы и компонентов гипервизора при загрузке. Secure Boot разрешает загрузку только доверенного подписанного кода, а TPM может использоваться для измерения компонентов в процессе загрузки и последующей проверки состояния платформы. Вместе они усложняют подмену компонентов гипервизора и внедрение руткитов на ранних этапах загрузки.

3. Отключать неиспользуемое виртуальное оборудование. Ненужные USB-, COM-порты, флоппи-дисководы и другие виртуальные устройства увеличивают поверхность атаки за счет дополнительного кода и драйверов. Чем меньше таких компонентов, тем меньше потенциальных точек входа.

4. Изолировать сеть управления гипервизором. Для административного доступа стоит использовать выделенный VLAN или отдельный физический интерфейс, а также настроить строгие ACL и межсетевой экран. Доступ к SSH, HTTPS, API и другим интерфейсам управления следует разрешать только из доверенных подсетей.

Атака на цепочку поставок через небезопасные шаблоны

Для массового развертывания виртуальных машин удобно использовать эталонные образы – заранее подготовленные шаблоны ОС и приложений. Они позволяют быстро создавать десятки и сотни ВМ с одинаковыми настройками безопасности, установленным ПО и обновлениями. Такой подход ускоряет развертывание и упрощает управление инфраструктурой.

Однако ошибка или уязвимость в эталонном образе автоматически тиражируется на все созданные из него ВМ. Это может быть устаревшая библиотека, забытый SSH-ключ или слабый пароль администратора. Такой сценарий можно рассматривать как внутреннюю атаку на цепочку поставок (supply chain): компрометация одного доверенного шаблона способна затронуть сразу значительную часть инфраструктуры.

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

Для защиты жизненного цикла эталонных шаблонов стоит применять несколько базовых мер:

1. Создавать минимальные и безопасные образы. В шаблоне должны оставаться только необходимые службы и пакеты, а стандартные учетные записи – отключаться или дополнительно защищаться. Это снижает поверхность атаки еще до развертывания ВМ.

2. Регулярно сканировать шаблоны на уязвимости. Для этого можно использовать специальные инструменты, например, MaxPatrol VM или OpenSCAP.

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

4. Развертывать ВМ только из проверенных шаблонов. Это снижает риск использования устаревших или скомпрометированных образов и делает конфигурации более предсказуемыми.

5. Контролировать версии и изменения шаблонов. Это позволяет быстро откатываться к стабильной версии при обнаружении проблем и четко понимать, из какого шаблона была развернута конкретная ВМ.

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

Избыточные привилегии виртуальных машин

В среде виртуализации существует несколько уровней доступа: к самому гипервизору (ESXi, гипервизорный агент), системе управления (vCenter, SCVMM) и  операционной системе виртуальной машины.

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

Кроме того, виртуальные машины, созданные временно для тестирования или разовых задач и использующие простые пароли (например, qwerty123), нередко остаются в инфраструктуре на долгий срок. Злоумышленник, получив доступ к одной такой ВМ, может использовать ее для дальнейшего продвижения.

Например, при подключении ESXi-хоста к vCenter автоматически создается учетная запись vpxuser с правами root на гипервизоре. Если злоумышленник получит доступ к памяти vCenter, он сможет извлечь учетные данные vpxuser и получить прямой доступ к ESXi-хосту.

Интересный кейс. В 2025 году группировка Fire Ant провела масштабную кампанию, в ходе которой злоумышленники компрометировали vCenter, извлекали учетные данные vpxuser и с их помощью получали полный контроль над подключенными ESXi-хостами. Атаки затронули множество организаций и наглядно показали, что компрометация одной служебной учетной записи может привести к полному захвату инфраструктуры.

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

1. Соблюдать принцип минимальных привилегий и разделения ролей. Пользователи и сервисы должны иметь только те права, которые необходимы им для работы. Например, специалист SOC не должен управлять виртуальными машинами, а специалист поддержки – создавать новые. В vCenter можно настроить отдельные роли под конкретные задачи, что позволит уменьшить ущерб при компрометации отдельной учетной записи.

2. Использовать многофакторную аутентификацию (MFA). Ее стоит включить для всех учетных записей, имеющих доступ к системам управления виртуализацией.

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

Сетевые слепые зоны

В виртуальной среде трафик между двумя ВМ на одном хосте часто не выходит за пределы физического сервера. При отсутствии дополнительных механизмов фильтрации виртуальные машины на одном хосте могут взаимодействовать друг с другом. Такой трафик проходит через виртуальный коммутатор и может не попадать на традиционный периметровый межсетевой экран, что создает «слепую» зону для систем мониторинга. Если одна из ВМ скомпрометирована, злоумышленник может попытаться получить доступ к другим ВМ во внутреннем сегменте. При недостаточной сегментации и мониторинге такой трафик может оставаться менее заметным для средств контроля.

Недостатки такой архитектуры были подтверждены экспериментально специалистами из Университета штата Иллинойс. Исследователи сравнили две среды с помощью симулятора атак Infection Monkey. В сети без сегментации вредоносное ПО смогло обнаружить и скомпрометировать все виртуальные машины, тогда как в сегментированной среде – ни одной. Причина в том, что сегментация разделяет инфраструктуру на изолированные зоны и тем самым ограничивает горизонтальное перемещение между ВМ.

Таким образом, сегментация является необходимым базовым элементом защиты, который значительно затрудняет горизонтальное перемещение атакующих. Однако важно понимать, что наличие сегментации не сможет полностью остановить злоумышленников. Сегментация должна быть частью комплексной стратегии защиты, дополненной мониторингом, контролем доступа и принципом нулевого доверия (Zero Trust).

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

Чтобы сократить сетевые слепые зоны и затруднить горизонтальное перемещение между ВМ, важно контролировать внутренний трафик:

1. Внедрить микросегментацию. Распределенные межсетевые экраны, например VMware NSX или решения на базе Open vSwitch, позволяют фильтровать трафик между ВМ на уровне виртуальных портов. Политики должны задаваться не IP-адресами, а логическими тегами (например, разрешить соединение между «веб-сервером» и «базой данных» по порту 3306). Это позволит изолировать ВМ даже внутри одного хоста.

2. Ограничить прямой доступ к ESXi-хостам. Административные операции, где это возможно, стоит выполнять через vCenter. Доступ к нему стоит разрешать только с выделенных промежуточных серверов, PAM-систем или административных подсетей.

3. Следовать принципу нулевого доверия (Zero Trust). Не стоит доверять трафику только потому, что он идет от «своей» ВМ. Необходимо проверять каждый запрос и шифровать данные даже внутри доверенной сети.

4. Настроить зеркалирование виртуальных портов. Копии внутреннего трафика можно передавать на IDS/IPS для выявления подозрительной активности, которые могут остаться незамеченными традиционными межсетевыми экранами.

Эффект «забытого сервера» и ресурсный DoS

Виртуальные машины имеют свойство быстро накапливаться в инфраструктуре. Например, разработчикам понадобилось пять ВМ для тестирования. Бухгалтерский сервер уже год не используется. Тестовый стенд, созданный для проверки обновления, остался в инфраструктуре «на всякий случай». Каждая такая виртуальная машина становится потенциальным источником рисков.

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

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

Показательный пример – атака группировки Scattered Spider в 2025 году. Получив доступ к vCenter с помощью социальной инженерии, злоумышленники обнаружили в инфраструктуре «осиротевшую» виртуальную машину без владельца. Затем они отключили контроллер домена, отсоединили его виртуальный диск и подключили его к подконтрольной ВМ. Так им удалось извлечь базу данных Active Directory (NTDS.dit) с хэшами паролей. После они вернули диск обратно и снова запустили контроллер домена.

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

1. Ограничить потребление CPU и памяти. Гипервизоры позволяют задавать резервирование и ограничения (Reservation, Limit, Shares), чтобы одна ВМ не могла занять все ресурсы хоста из-за утечки памяти, аномальной нагрузки или ошибки приложения.

2. Назначать владельца каждой ВМ. У каждой машины должен быть указан ответственный сотрудник или подразделение. Если владелец неизвестен или ВМ долго не используется, стоит проверить, нужна ли она по-прежнему.

3. Регулярно проводить инвентаризацию. Для этого можно использовать средства управления платформы виртуализации для автоматического обнаружения неиспользуемых ВМ и вовремя выводить их из эксплуатации.

Безопасность контейнеризации

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

Критические риски связаны не только с возможным побегом через ядро хоста, но и с компрометацией учетных записей (в особенности служебных), уязвимостями в приложениях и образах, ошибками конфигурации (избыточные права, открытые API, слабые сетевые политики), утечками секретов и атаками на цепочку поставок через вредоносные образы.

Побег из контейнера: атака на ядро хоста

Наиболее критичные уязвимости в области контейнеризации традиционно связаны с низкоуровневой средой выполнения контейнеров runc, используемой Docker, Kubernetes и другими платформами. Например, в 2024 году была обнаружена уязвимость CVE-2024-21626. Из-за утечки файлового дескриптора атакующий мог через специально сформированную рабочую директорию контейнера получить доступ к хостовой файловой системе. В некоторых сценариях это также позволяло перезаписывать исполняемые файлы на хосте и выполнять произвольный код на нем.

В 2025 году исследователь из SUSE обнаружил еще три уязвимости CVE-2025-31133, CVE-2025-52565 и CVE-2025-52881 в runc высокого уровня риска. Эксплуатация любой из них может позволить злоумышленнику выйти за пределы контейнера и получить привилегии root на хосте.

Однако проблема заключается не только в этом: даже при использовании актуальной версии runc сохраняются риски, связанные с эксплуатацией возможностей самого ядра Linux. Например, злоумышленник может получить доступ к интерфейсам ядра через файловые системы /proc и /sysfs, которые предоставляют информацию о процессах, параметрах ядра и оборудовании. При недостаточной изоляции эти механизмы становятся источником утечки данных. Атакующий может извлечь важную информацию о хосте (например, список запущенных процессов, сетевые конфигурации, параметры памяти) или модифицировать параметры ядра, изменяя поведение системы в свою пользу. В сочетании с другими векторами атак это может привести к полной компрометации хоста.

Чтобы минимизировать риски побега из контейнера и компрометации хоста, необходимо выстроить многоуровневую систему защиты:

1. Регулярно обновлять ядро и среду выполнения контейнеров. Использовать дистрибутивы с длительной поддержкой и автоматической доставкой патчей (например, Livepatch или KernelCare).

2. Сокращать поверхность атаки. Ненужные модули ядра стоит отключать, а для контейнерных узлов – по возможности использовать специализированные ОС, например Flatcar Container Linux или Bottlerocket. Чем меньше лишних компонентов, тем меньше потенциальных точек входа.

3. Ограничить возможности процессов. Seccomp помогает контролировать доступные системные вызовы, а AppArmor или SELinux – дополнительно ограничивать действия процессов и доступ к ресурсам.

4. Контролировать поведение контейнеров во время работы. Инструменты вроде Falco, Tetragon или Runtime Radar от PT Container Security отслеживают системные вызовы, сетевые соединения и изменения в файловой системе в реальном времени. Они могут обнаружить подозрительную активность (например, запуск шелла внутри контейнера, обращения к /etc/shadow или попытки загрузки модулей ядра) и автоматически генерировать оповещения или даже блокировать процесс.

Вредоносные образы в публичных реестрах

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

Интересный факт. В 2024 году в Docker Hub было обнаружено около 3 миллионов репозиториев, которые использовались для распространения вредоносного контента.

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

Однако даже официальные или популярные образы не могут гарантировать безопасность, так как в них могут содержаться устаревшие библиотеки с известными уязвимостями. Например, образы, подверженные CVE-2024-3094, продолжали распространяться даже спустя год после публикации уязвимости. Поэтому даже свежесобранный образ может содержать критические уязвимости, известные на протяжении нескольких лет.

Интересные кейсы. В марте 2026 года злоумышленники скомпрометировали CI/CD-конвейер Aqua Security и загрузили вредоносные версии сканера уязвимостей Trivy в официальный репозиторий на Docker Hub. Вредоносный код был нацелен на кражу секретов CI/CD, облачных учетных данных и SSH-ключей.

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

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

1. Использовать только проверенные источники. Внедрить подпись образов с помощью Cosign или Notary, а также использовать привязку к digest (хэшу) при развертывании. Подпись образов позволяет проверять происхождение и целостность артефактов, а использование digest вместо плавающих тегов (например, latest, stable) фиксирует конкретную версию образа и предотвращает незаметную замену содержимого, на которое ссылается развертывание.

2. Встроить сканирование образов на уязвимости в CI/CD-пайплайн. Для автоматического анализа каждого собираемого образа могут использоваться такие инструменты, как Trivy, Clair или Grype, а также комплексные решения PT Container Security или MaxPatrol VM. Собираемые образы не должны попадать в продакшн без прохождения сканирования. Это позволит выявлять известные CVE еще на этапе сборки.

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

4. Периодически сканировать содержимое реестра (continuous scanning). Настроить автоматическое сканирование образов по расписанию, чтобы своевременно выявлять новые CVE в используемых образах.

Избыточные привилегии контейнеров

Запуск контейнеров с флагом --privileged, предоставление всех привилегий через флаг

--cap-add=ALL или запуск процессов от пользователя root увеличивают последствия возможной компрометации. Особенно опасен режим
--privileged, поскольку он значительно ослабляет изоляцию контейнера и предоставляет расширенный доступ к ресурсам хоста. Еще опаснее предоставлять контейнеру доступ к сокету Docker (/var/run/docker.sock). Это равносильно передаче ключей от всего хоста. Через сокет злоумышленник может запустить привилегированный контейнер, смонтировать корневую файловую систему хоста и получить полный контроль.

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

1. Запускать контейнеры от непривилегированного пользователя (non-root). Для этого можно задать USER 1000 в Dockerfile или использовать --user при запуске. Это ограничивает права процесса внутри контейнера и снижает последствия компрометации.

2. Отказаться от использования флага --privileged. Если контейнеру нужен доступ к конкретному устройству, лучше предоставить его точечно с помощью флага --device. Предоставление отдельных возможностей ядра (например, CAP_NET_BIND_SERVICE) стоит выдавать точечно с помощью флага --cap-add.

3. Не монтировать /var/run/docker.sock в контейнер без необходимости. Такой доступ фактически дает контейнеру возможность управлять Docker-демоном на хосте. Для CI/CD лучше использовать альтернативные подходы, такие как BuildKit в rootless-режиме. Docker-in-Docker (DinD) также возможен, но его стандартная конфигурация требует привилегированного контейнера, что снижает уровень изоляции и отключает часть защитных механизмов.

4. Использовать rootless-режим Docker или Podman. Этот режим запускает контейнеры от обычного пользователя, без root-привилегий на хосте. Это не защищает от уязвимостей ядра, но значительно усложняет повышение привилегий на хосте.

Помимо привилегий отдельных контейнеров, важно контролировать доступ ко всему Kubernetes-кластеру:

1. Использовать RBAC (Role-Based Access Control) по принципу минимальных привилегий. Пользователи и сервисные аккаунты должны иметь доступ только к тем ресурсам, которые нужны для их работы.

2. Не хранить пароли, токены и ключи в переменных окружения или в коде. Использовать для этого встроенный ресурс Secret в Kubernetes или внешние системы, например HashiCorp Vault с интеграцией через CSI-драйвер. Включать шифрование секретов на уровне etcd.

3. Использовать политики Admission Controller.  Они позволяют проверять запросы к API Kubernetes до создания объектов и блокировать небезопасные конфигурации. Например, можно запрещать привилегированные контейнеры, монтирование docker.sock или требовать определенных настроек securityContext. Для этого могут использоваться OPA/Gatekeeper, Kyverno или встроенный Pod Security Admission (PSA).

4. Регулярно проверять конфигурацию кластера. Инструменты вроде kube-bench, kube-score и Polaris помогают выявлять небезопасные настройки: отсутствие лимитов, запуск от root, монтирование путей хоста и другие риски. Дополнительно стоит учитывать применимые стандарты и требования, например CIS Kubernetes Benchmark, CRIS от Positive Technologies или PCI DSS.

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

Изоляция контейнеров на сетевом уровне

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

По умолчанию контейнеры в разных bridge-сетях изолированы друг от друга. Эта изоляция обеспечивается автоматически создаваемыми правилами межсетевого экрана (iptables/nftables), которые Docker устанавливает для bridge-сетей. Однако эта изоляция может быть нарушена.

В 2025 году была опубликована уязвимость CVE-2025-54410 в Docker Engine, позволяющая обойти механизмы изоляции bridge-сетей. Уязвимость заключается в том, что при перезагрузке межсетевого экрана firewalld Docker не может восстановить критические правила (iptables), разделяющие сети контейнеров. В результате контейнеры из разных bridge-сетей получают доступ к портам друг друга. Традиционные периметровые средства защиты, расположенные за пределами хоста, не видят такой трафик, поскольку он происходит внутри виртуальной сети.

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

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

1. Использовать явные сетевые политики. В Kubernetes для этого может использоваться Network Policies. В Docker необходимо разделять контейнеры по нескольким bridge-сетям и подключать к каждой сети только те контейнеры, которым требуется взаимодействие друг с другом. В отличие от автоматических правил Docker, такие политики обеспечивают предсказуемую и контролируемую изоляцию.

2. Использовать сервисную сетку (Service Mesh) с шифрованием трафика. Такие инструменты, как Istio или Linkerd, позволяют с помощью mTLS защищать и аутентифицировать трафик между сервисами внутри кластера.

3. Контролировать сетевую активность на уровне контейнеров. Для мониторинга могут использоваться такие инструменты, как Cilium Hubble, а для обнаружения подозрительной активности внутри контейнеров можно использовать Falco.

Жадный сосед: ресурсный DoS

«Жадный сосед» (noisy neighbor) – процесс, который потребляет больше ресурсов, чем ему выделено. Причиной может стать утечка памяти, бесконечный цикл или неконтролируемое создание дочерних процессов. Без явных ограничений такой контейнер способен занять значительную часть памяти или процессорного времени хоста и нарушить работу соседних сервисов. В худшем случае это может привести к отказу в обслуживании (DoS).

Документация Prisma Cloud указывает, что если для пода не заданы лимиты (limits), он может потребить всю доступную память и CPU узла. В реальных кластерах отсутствие лимитов приводит к каскадным сбоям. Когда один контейнер исчерпывает доступные ресурсы, это может привести к отказу сервисов на той же ноде или в худшем случае, к нестабильности самой ноды. Это приводит не только к техническим проблемам, но и к финансовым и репутационным потерям. При этом контейнер может даже не быть создан злоумышленником, достаточно ошибки в коде, вызывающей утечку памяти или бесконечный цикл.

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

1. Задавать лимиты и запросы ресурсов. В Docker для этого можно использовать флаги

   --memory=512m и --cpus=1, в Kubernetes — соответствующие поля в спецификации контейнера. Эти ограничения реализуются через механизм Cgroups, который напрямую контролирует распределение CPU, памяти и операций ввода-вывода между контейнерами. Без явных лимитов контейнер может утилизировать все доступные ресурсы узла.

2. Использовать Cgroups v2. Cgroups v2 предоставляет единую иерархию контроля, что упрощает настройку и исключает конфликты между подсистемами. В частности, параметры memory.min и memory.low позволяют осуществлять защиту от агрессивного освобождения памяти, а memory.high и memory.max – ограничивать ее потребление. Для мониторинга давления на ресурсы и своевременного обнаружения деградации можно использовать PSI.

3. Ограничивать количество процессов (PID). В Docker для этого может использоваться флаг --pids-limit=100, а в Kubernetes – параметр podPidsLimit. Это может снизить риски исчерпания лимита PID в пространстве имен из-за атаки типа «fork-бомба» и других атак, связанных с бесконечным порождением процессов.

4. Настроить автоматическое масштабирование. Например, Horizontal Pod Autoscaler (HPA) и Vertical Pod Autoscaler (VPA) помогают адаптировать выделение ресурсов к изменяющейся нагрузке и снизить вероятность отказов из-за штатных пиков потребления. В облачных средах Cluster Autoscaler добавляет новые узлы при нехватке ресурсов.

Дополнительный рубеж: мониторинг

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

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

Мониторинг виртуальной среды

Побег из виртуальной машины и атаки на гипервизор

Для выявления попыток выхода за пределы ОС виртуальной машины на уровень гипервизора необходимо непрерывно отслеживать следующие события и аномалии:

• Критические события в журналах. К ним относятся стандартные записи событий ОС (/var/log/messages в Linux), сообщения ядра (dmesg), а также записи событий платформы виртуализации (например, VMware vSphere Syslog или Hyper-V Admin Logs).

• Нетипичные процессы и изменения на хосте. Например, появление на хосте процессов или модулей, которые не соответствуют штатной конфигурации гипервизора. Также следует обращать внимание на процессы с именами, имитирующими системные (например, vmmemchictl вместо vmmemctl), или запущенные с нестандартными аргументами.

• Срабатывания IDS/IPS на известные уязвимости гипервизора. Такие события могут указывать на попытки эксплуатации или проверку инфраструктуры на наличие устаревших компонентов.

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

Атака на цепочку поставок через небезопасные шаблоны

Для своевременного обнаружения атак, связанных с эталонным образами, необходимо отслеживать:

• Изменения в репозиториях шаблонов. Отслеживайте обновления эталонных образов, выполненные в нерабочее время или от имени неавторизованных пользователей. Аудит действий в системах управления виртуализацией (например, vCenter или SCVMM) позволяет выявить несанкционированные изменения эталонных образов.

• Отклонения конфигурации новых ВМ от эталона. Изменения настроек установленного ПО должны автоматически передаваться системе мониторинга для дальнейшего анализа.

• Аномалии в сетевой активности и потреблении ресурсов. Резкий рост сетевого трафика или загрузки CPU у недавно созданных ВМ может указывать на вредоносную активность.

• Соединения с недоверенными внешними IP-адресами. Подключение новых ВМ к неизвестным IP-адресам и доменам стоит проверять с помощью Threat Intelligence. Для обогащения таких событий можно использовать, например, PT Fusion.

Избыточные привилегии виртуальных машин

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

• Критические действия в системах управления виртуализацией. К ним относятся вход в систему, изменения ролей, назначение прав, создание и удаление виртуальных машин, а также создание резервных копий состояния (снапшотов).

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

• Нетипичная активность учетной записи vpxuser. Стоит отслеживать действия и команды, не соответствующие обычному взаимодействию vCenter с ESXi.

• Множественные неуспешные попытки аутентификации. Серии неудачных входов в ОС виртуальных машин или попыток прохождения MFA могут указывать на перебор учетных данных. Такие события можно выявлять по журналам аутентификации: auth.log в Linux, Security Event Log в Windows.

Сетевые слепые зоны

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

• Зеркалирование портов виртуальных коммутаторов. Копии внутреннего трафика можно передавать на системы анализа для выявления подозрительных взаимодействий между ВМ.

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

• Контроль изменений MAC- и ARP-таблиц. Атаки с подменой информации в этих таблицах могут проводиться злоумышленниками для перенаправления трафика между ВМ, поэтому стоит отслеживать неожиданные изменения и появление нетипичных записей.

• Мониторинг событий распределенного межсетевого экрана. Если в инфраструктуре внедрена микросегментация с использованием распределенного межсетевого экрана, например NSX Distributed Firewall, необходимо собирать записи о всех разрешенных и заблокированных соединениях и направлять их в SIEM. Это позволит отслеживать попытки соединений между ВМ, которые были предотвращены политиками безопасности.

Эффект «забытого сервера» и ресурсный DoS

Для контроля разрастания инфраструктуры и своевременного выявления нехватки ресурсов необходимо применять следующие меры:

• Регулярная инвентаризация ВМ. Стоит отслеживать виртуальные машины без указания ответственного лица или отдела, а также ВМ, связанные с уволенным сотрудником.

• Контроль неактивных ВМ. Если виртуальная машина не запускалась более трех месяцев, это должно быть поводом проверить ее назначение, владельца и необходимость дальнейшей эксплуатации.

• Мониторинг потребления ресурсов. Следует отслеживать аномальный рост потребления CPU, памяти, дискового пространства и сетевых ресурсов.

Мониторинг в контейнерной среде

Побег из контейнера и атаки на ядро хоста

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

• Потенциально опасные системные вызовы из контейнера. Следует отслеживать выполнение таких вызовов, как mount, chroot, pivot_root, init_module, finit_module. Их использование может быть легитимным в отдельных сценариях, однако в обычных прикладных контейнерах такие события, особенно в сочетании с обращением к ресурсам хоста, могут указывать на попытку нарушения изоляции.

• Обращения к важным путям. Необходимо обращать внимание на попытки доступа из контейнера к критическим файлам и директориям хоста, таким как /etc/shadow и /root/.ssh.

• События ядра и политик безопасности. Для этого можно анализировать сообщения из кольцевого буфера ядра (команда dmesg), файлы постоянного хранения (/var/log/kern.log) или использовать системный журнал (journalctl -k).

• Нетипичные процессы и команды. Стоит отслеживать появление на хосте процессов, запущенных внутри контейнерного пространства имен, но выполняющих команды, не связанные с нормальной работой приложения. Запуск оболочки, например, bash и sh, или сетевых утилит вроде nc и curl внутри контейнера из процесса, который обычно их не запускает, может свидетельствовать о совершении несанкционированных действий в системе.

Использование вредоносных или устаревших образов

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

• Критические уязвимости в образах. Образы стоит сканированить как на этапе сборки (в CI/CD-пайплайне), так и при хранении в реестре. Инструменты типа Trivy, Clair или Grype позволяют выявлять известные CVE и другие небезопасные компоненты или конфигурации соответствующим образом для последующей ручной проверки.

• Попытки развертывания неподписанных образов. Следует фиксировать попытки запуска образов без доверенной подписи или из непроверенных источников как нарушение политики безопасности.

• Аномальное поведение контейнеров. Если контейнер генерирует исходящие соединения на незнакомые внешние IP-адреса или аномально много потребляет ресурсы, это может указывать на запуск вредоносной нагрузки, встроенной в образ.

Избыточные привилегии контейнеров

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

• Создание или обновление привилегированных подов. Необходимо отслеживать запросы к Kubernetes API или события Docker, содержащие флаги privileged: true, hostNetwork: true, hostPID: true или hostIPC: true, а также монтирование /var/run/docker.sock (сокет Docker-демона) или критических томов хоста, таких как /proc, /sys или корневой файловой системы хоста.

• Изменение привилегий внутри контейнера. Вызов setuid, setgid или capset позволяет изменять идентификаторы пользователя и набор Linux capabilities. Если такое поведение не предусмотрено приложением, оно может указывать на попытку повышения привилегий.

• Нарушение политик безопасности. Стоит фиксировать попытки создания или изменения подов, отклоненные встроенными политиками Pod Security Standards (PSS) или пользовательскими политиками Open Policy Agent (OPA). Даже если попытка была заблокирована, ее фиксация важна для выявления атак.

Нарушение сетевой изоляции

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

• Нарушения сетевых политик. Стоит фиксировать попытки соединений между подами, которые не соответствуют заданным политикам и блокируются средствами вроде Cilium или Calico.

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

• События сервисной сетки (Service Mesh). Service Mesh – это инфраструктурный слой, который управляет сетевым трафиком между микросервисами, обеспечивая шифрование (mTLS), аутентификацию и мониторинг соединений. Необходимо отслеживать записи mTLS-соединений в сервисной сетке (например, с помощью инструментов Istio или Linkerd). Ошибки аутентификации или неожиданные запросы между сервисами могут свидетельствовать о попытках несанкционированного доступа.

• Соединения подов с недоверенными внешними IP-адресами. Для проверки таких соединений по данным Threat Intelligence можно использовать внешние сервисы, например PT Fusion.

Ресурсный DoS («жадный сосед»)

Для обнаружения признаков нехватки ресурсов необходимо отслеживать следующие события:

• Рост потребления ресурсов. Следует отслеживать превышение выделенных лимитов по CPU, памяти и дисковому пространству для каждого пода, а также рост их потребления без видимых причин.

• Запуск подов без ограничений ресурсов. Необходимо фиксировать попытки создания или запуска подов, в которых не заданы лимиты (limits) и запросы (requests) ресурсов.

• Рост числа процессов в контейнере. Это может быть признаком проведения атак, направленных на исчерпание ресурсов (например, fork-бомбы).

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

Будущее технологий: новые рубежи защиты

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

Одним из таких инструментов стал eBPF — технология, позволяющая запускать изолированный код в ядре операционной системы. В отличие от виртуальных машин и контейнеров, которые изолируют целые приложения или операционные системы, eBPF работает на уровне ядра, предоставляя возможность безопасно выполнять программы в ответ на системные события. Это позволяет встраивать мониторинг и защиту непосредственно в ядро, не устанавливая отдельные пользовательские агенты для каждой задачи. Программы eBPF выполняются как часть ядра ОС. Инструменты вроде Cilium и Falco уже используют eBPF для фильтрации сетевого трафика и обнаружения аномалий. Однако eBPF не заменяет существующие технологии, а лишь дополняет их, делая мониторинг более эффективным.

Другой вектор развития – WebAssembly (Wasm). В отличие от контейнеров, которым обычно требуется файловая система с приложением и его зависимостями, Wasm позволяет запускать отдельные модули в компактной песочнице без полноценного пользовательского окружения ОС. Это позволяет запускать их практически мгновенно, с минимальным потреблением памяти. Wasm не заменяет контейнеры, а предлагает решение для сценариев, где даже контейнер оказывается избыточным, например, serverless-функции или edge-вычисления. Такие проекты, как Spin и WasmEdge, развивают инструменты для запуска Wasm-модулей в среде Kubernetes, что позволяет использовать их в привычном контейнерном окружении.

Третье направление – конфиденциальные вычисления (Confidential Computing). В отличие от виртуализации, где гипервизор имеет доступ к памяти систем виртуальных машин, конфиденциальные вычисления шифруют память работающих приложений. Технологии вроде AMD SEV-SNP, Intel TDX и Intel SGX создают аппаратно-изолированные окружения (Trusted Execution Environments, TEE), внутри которых данные остаются зашифрованными. При корректной реализации аппаратной защиты содержимое защищенной памяти может оставаться недоступным гипервизору и облачному провайдеру, даже если они полностью контролируют инфраструктуру. Такая защита критически важна для обработки персональных данных, коммерческой тайны и других чувствительных нагрузок в публичных облаках.

Еще одно направление – песочницы на основе microVM, которые также представляют собой попытку объединения скорости контейнеров с изоляцией виртуальных машин. В этой технологии каждый под запускается либо внутри собственной легковесной виртуальной машины с использованием Kata Containers и гипервизора/VMM вроде Firecracker, либо в пользовательской среде ядра, как в gVisor. В отличие от классического контейнера такой под не разделяет ядро хоста напрямую с соседями, что снижает риск побега через уязвимость ядра Linux. Платить за эти преимущества придется дополнительными накладными расходами и небольшой просадкой производительности, то есть технология по сути возвращает нас к архитектурным издержкам виртуализации ради дополнительной изоляции контейнеров.

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

С ростом популярности eBPF вероятно появятся и попытки эксплуатации самих eBPF-программ. При компрометации механизма загрузки eBPF-программ или получении соответствующих привилегий атакующий потенциально может использовать eBPF для наблюдения за системной и сетевой активностью или обхода части традиционных средств обнаружения. Распространение Wasm-модулей может создать новые возможности для атак на цепочку поставок. MicroVM-песочницы, снижая риск классического побега через ядро, переносят фокус атаки на компрометацию агента Kata Containers, API-сокета Firecracker или пользовательского ядра gVisor. Конфиденциальные вычисления, несмотря на аппаратную изоляцию, также могут стать мишенью, например, через атаки на интерфейсы между TEE и незащищенной частью системы или эксплуатацию драйверов управления памятью. Компрометация одного такого компонента потенциально может дать контроль над тысячами приложений без необходимости взламывать их отдельно. Эти возможные сценарии лишь подчеркивают важность упреждающего подхода к безопасности – защита должна встраиваться не только в код, но и в инструменты разработки, сборки и развертывания.

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

Заключение

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

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

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

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

Ульяна Долгунцева

Аналитик @Направление проектов по кибербезопасности (Cyber Analytics), Positive Technologies