Защита виртуальных машин: изоляция, шифрование и границы гипервизора

Модель угроз: что защищает гипервизор, а что остаётся вне его границы

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

Почему взлом одной Guest OS не равен взлому всех VM

Guest OS — операционная система внутри VM. Если атакующий получил права администратора в одной гостевой ОС, это обычно даёт контроль над данными, приложениями и сетевыми учётными данными именно этой VM. Сам по себе такой доступ не должен открывать память, виртуальные диски или консоль соседней VM: эти ресурсы разделяет гипервизор.

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

• Уязвимость гипервизора или виртуального устройства. Ошибка в обработке эмулируемого оборудования, драйвере или самом гипервизоре может стать путём выхода из VM.
• Избыточные права в управлении. Учётная запись, которой разрешено менять конфигурацию VM, подключать носители, читать консоль, создавать клоны либо экспортировать диски, может обойти обычные границы гостевой ОС.
• Небезопасные подключения. Общие сетевые сегменты, слишком широкие правила виртуального firewall, открытые сервисы и ошибочные маршруты создают путь между VM без всякого VM Escape.
• Компрометация хоста или firmware. В этой ситуации разделение VM уже не является самостоятельным барьером: атакующий находится ниже уровня гостевых ОС.
• Подключённые к VM данные и секреты. Например, доступные сетевые папки, токены, пароли в сценариях автоматизации и учётные данные, введённые администратором в скомпрометированной консоли.

Доверенная вычислительная база и защищаемый периметр

Для конкретной VM доверенная вычислительная база включает не только гипервизор. В неё входят физический сервер, его BIOS/UEFI и другое firmware, процессоры и память, хостовая платформа, драйверы, сеть и система управления. Для VMware это может включать VMware ESXi и vCenter Server; для Microsoft — Hyper-V и связанные компоненты управления; для KVM — ядро Linux, QEMU и средства управления, такие как libvirt.

Datastore, внешнее хранилище и резервные копии относятся к более широкому периметру данных VM. На них могут находиться виртуальные диски, конфигурация, файлы снимков, экспортированные образы и копии. Даже если злоумышленник не может войти в работающую Guest OS, доступ к незашифрованному файлу её диска может позволить читать или копировать данные офлайн. Подробнее о размещении файлов VM — в статье «Datastore и VMware vSAN: как организовать хранение виртуальных машин».

Защита хоста и плоскости управления

Плоскость управления — это интерфейсы, API, службы и учётные записи, через которые администраторы управляют хостами, VM, сетью и хранилищем. Её компрометация часто опаснее заражения одной Guest OS: управление может дать доступ сразу к нескольким VM и их файлам. Поэтому безопасность VMware, Hyper-V, Proxmox VE и других платформ начинается с защиты хоста и управления, а не с установки защитного ПО в отдельных гостях.

• Используйте поддерживаемый релиз гипервизора и применяйте обновления безопасности в рамках согласованного процесса. Патчинг снижает риск известных уязвимостей, но не исключает эксплуатацию новых или неверно настроенных компонентов.
• Разделяйте роли: повседневенное администрирование VM, управление хостами, управление сетью, хранилищем и ключами не обязательно должны выполняться одной учётной записью.
• Защищайте административный доступ: индивидуальные учётные записи, многофакторная аутентификация там, где её поддерживает выбранная архитектура, защищённые рабочие места и журналирование привилегированных операций.
• Выносите management-трафик в отдельный сегмент, ограничивайте к нему маршрутизацию и доступ только с административных узлов.
• Ограничивайте прямой доступ к хостам. Например, Lockdown Mode в ESXi предназначен для ограничения прямого управления хостом и переноса обычных операций в vCenter Server.
• Регулярно проверяйте события входа, изменения сетей, прав, конфигурации VM, политик шифрования и операций с ключами.

Сетевая изоляция VM: VLAN и firewall нужно настроить отдельно

Сам факт запуска VM на одном гипервизоре не определяет, кто с кем может обмениваться трафиком. Связность задают виртуальные коммутаторы, Port Group, VLAN, маршрутизация, правила виртуального и физического firewall. В VMware эту роль может выполнять vSwitch, в Hyper-V — виртуальный коммутатор Hyper-V, в Proxmox VE и KVM — bridge, Open vSwitch или другие поддерживаемые сетевые механизмы.

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

В Proxmox VE Proxmox VE Firewall применяет правила на уровнях Datacenter, Node и VM/CT. Правила Datacenter задают общую политику, Node относятся к конкретному узлу, а VM/CT — к сетевым интерфейсам отдельной виртуальной машины или контейнера. Это механизм фильтрации трафика, а не шифрование VM и не замена защиты Guest OS. Порядок и действие правил нужно проверять в документации именно используемого релиза.

Шифрование виртуальных машин, дисков и данных внутри Guest OS

VM Encryption — не одно универсальное решение. Можно шифровать файлы VM средствами платформы, виртуальные диски или datastore средствами хранения, а также данные внутри Guest OS. Эти уровни дополняют друг друга, но имеют разные границы доверия.

VMware Encryption: роль vCenter и ключей

В документации vSphere функция VMware VM Encryption связана с централизованным управлением через vCenter Server и инфраструктурой ключей. Для поддерживаемых сценариев vSphere использует внешний совместимый сервер управления ключами KMS по KMIP либо поддерживаемый механизм Native Key Provider, доступный не во всех поколениях vSphere. vCenter управляет назначением ключей и политиками шифрования, а ключевой сервис должен быть доступен и корректно защищён.

Доступность VMware Encryption зависит от конкретного поддерживаемого релиза vSphere, состава приобретённых прав, лицензирования и совместимости компонентов. Нельзя считать эту функцию включённой по умолчанию только потому, что установлен ESXi или vCenter. Для новой либо изменяемой среды нужно сверить официальную документацию Broadcom для используемого релиза, поддерживаемость KMS или Native Key Provider и условия лицензирования; общая схема не заменяет эту проверку.

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

Shielded VM в Hyper-V: защита от недоверенной фабрики

Shielded VM — механизм Windows Server Hyper-V для сценариев, где требуется сильнее ограничить доступ fabric administrators, то есть администраторов виртуализационной инфраструктуры, к содержимому защищённой VM. Он не является названием функции Azure и не должен смешиваться с облачными сервисами со сходными терминами.

В архитектуре Shielded VM vTPM предоставляет гостю виртуальный TPM для защищённого использования секретов и фиксации измерений загрузки. Secure Boot проверяет подписи и допустимость компонентов загрузки. Host Guardian Service выполняет аттестацию guarded host и предоставляет материал, необходимый для запуска защищённой VM, только хостам, соответствующим заданной политике. Таким образом, vTPM и Secure Boot являются частями защитной модели VM, а Host Guardian Service — отдельным критичным компонентом доверия и управления ключами.

Поддержка Shielded VM, варианты аттестации, требования к guarded host, поколениям VM и поддерживаемым гостевым ОС зависят от выпуска Windows Server и редакции компонентов. Перед развёртыванием нужно сверить официальную документацию Microsoft именно для используемого Windows Server. Нельзя переносить ограничения и порядок настройки между Windows Server 2016, более поздними выпусками и Azure без отдельной проверки.

Операции клонирования, восстановления, экспорта и миграции Shielded VM должны планироваться с учётом доступности Host Guardian Service, key protector и доверенности целевого guarded host. Это не означает, что любой сценарий Hyper-V Replica, Live Migration или перенос файлов совместим с Shielded VM: допустимые операции определяет документация соответствующей версии Windows Server.

Когда шифрование VM оправдано и какие создаёт ограничения

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

• Управление ключами. Ключи должны быть доступны авторизованным компонентам, резервированы и защищены от несанкционированного выпуска либо удаления.
• Восстановление. План восстановления VM без проверки доступа к ключам неполон; восстановленный диск может оказаться недоступным.
• Миграция и клонирование. Операции могут требовать дополнительной совместимости, обмена ключами, доверенного целевого хоста либо предварительной расшифровки.
• Экспорт и межплатформенный перенос. Шифрование VMware, Shielded VM, функции Proxmox VE и механизмы KVM/libvirt не являются взаимозаменяемыми форматами.
• Административная сложность. Ротация ключей, аудит операций и аварийный доступ требуют процессов и разделения обязанностей, а не только включения флажка.

Proxmox VE Firewall не следует считать аналогом VM Encryption: он фильтрует сетевой трафик. В KVM/libvirt шифрование обычно строят из отдельных возможностей ОС, хранилища, QEMU и систем управления ключами. Механизмы защиты VMware, Shielded VM и решения на базе Proxmox VE или KVM/libvirt имеют разные модели доверия, способы управления ключами и требования к переносу; считать их взаимозаменяемыми нельзя. Базовый стек KVM и libvirt описан в материале «KVM, QEMU и libvirt в Linux: установка, VM, virsh и Guest Agent».

Антивирус для виртуальных машин и hardening остаются внутри Guest OS

Антивирус для виртуальных машин, EDR, обновления ОС, контроль локальных учётных записей, настройка firewall гостя и защита приложений обычно работают внутри Guest OS либо предоставляются отдельным специализированным решением. Гипервизор не анализирует автоматически каждый файл и процесс во всех VM и не заменяет hardening гостевой ОС.

Поэтому защита от вирусов в виртуальной машине строится как защита обычного сервера: владелец гостя отвечает за обновления, антивирус или EDR, конфигурацию сервисов и реагирование на инциденты. Изоляция VM уменьшает вероятность прямого перехода из одной гостевой ОС в другую через память или виртуальный диск, но не препятствует вредоносному трафику по разрешённой сети и не устраняет последствия компрометации самой Guest OS.