Шифрование виртуальных машин в облаке с помощью vSphere Virtual Machine Encryption27.05.2021 13:01

Привет, Хабр! Я Александр Воронцов, технический специалист Cloud4Y. В этой статье расскажу про vSphere Virtual Machine Encryption. Здесь не будет описания опыта внедрения. Это, скорее, обзор технологии и её неочевидных нюансов и особенностей, не описанных в документации. Я постараюсь дать ответы на вопросы, которые могут возникнуть у специалиста в процессе изучения.

Демонстрацию буду проводить на тестовом стенде vSphere 6.7 U3, Cloud Director 10.2

vSphere VM Encryption — механизм шифрования виртуальных машин, который впервые появился в VMware vSphere 6.5. Официальная документация по VM Encryption по ссылке. VM Encryption требует VMware vSphere 6.5 и новее и KMS (кластера KMS) с поддержкой протокола KMIP v1.1. VMware не предоставляет KMS, его требуется приобрести отдельно у другого вендора. В vSphere 7.0 U2 добавили Native Key Provider, который можно использовать вместо внешнего KMS для VM Encryption. В данной статье его не рассматриваю.

Какие задачи решает VM Encryption

VM Encryption позволяет хранить файлы виртуальной машины (файл конфигурации, файлы виртуальных дисков, снапшоты и т. п.) в зашифрованном виде на СХД, не прибегая к средствам шифрования самой СХД.

VM Encryption позволяет облачному провайдеру дополнительно защитить свою инфраструктуру (напр. зашифровать служебные VM), а также предоставлять своим клиентам опциональную возможность шифрования клиентских VM с управлением шифрованием через VMware Cloud Director.

VM Encryption позволяет клиенту облачного провайдера зашифровать свои VM в облаке, а также использовать vTPM (Virtual Trusted Platfom Module) в связке, например c Windows BitLocker.

Как это работает

У VMware есть видео, которое демонстрирует работы механизма vSphere Virtual Machine Encryption.

В механизме VM Encryption используется два ключа симметричного шифрования:

1. Data Encryption Key (дал. DEK). Этот ключ генерирует ESXi хост. Таким ключом зашифрованы файлы конфигурации и файлы виртуальных дисков виртуальной машины. Для файлов конфигурации VM DEK хранится в *.vmx в зашифрованном виде, для файлов виртуальных дисков — в *.vmdk файле в зашифрованном виде.

2. Key Encryption Key (дал. KEK). Этот ключ генерирует KMS. Таким ключом зашифрован DEK. Этот ключ хранится в базе данных KMS и в оперативной памяти ESXi хоста, на котором зарегистрирована VM.

Давайте рассмотрим процессы, который происходят при работе VM Encryption.

Этапы инициализации шифрования:

1. vCenter запрашивает KEK у KMS. KMS генерирует KEK, сохраняет его в своей базе данных, и передает его vCenter. vCenter передаёт KEK всем ESXi в vSphere High Avalibility кластере. ESXi хранят KEK в оперативной памяти и никогда не записывают его на диск.

2. ESXi, получив KEK, генерирует DEK, зашифровывает DEK с помощью KEK и записывает зашифрованный DEK в конфигурационный файл VM.

3. ESXi выполняет процесс шифрования файлов VM с помощью DEK.

Этапы включения зашифрованной VM:

1. ESXi получает команду на запуск зашифрованной VM, проверяет в своей ОЗУ наличие KEK для расшифровки VM. Если KEK нет в ОЗУ ESXi, KEK запрашивается у vCenter, а vCenter запрашивает KEK у KMS.

2. KMS передаёт KEK vCenter, а vCenter передаёт KEK ESXi хосту.

3. ESXi хост запускает VM.

Этапы миграции vMotion зашифрованной VM:

При миграции vMotion KMS сервер не используется. Encrypted vMotion можно использовать и без VM Encryption.

1. ESXi получает команду на миграцию VM на другой ESXi хост. Если миграция выполняется в другой ESXi кластер, то на этом шаге vCenter запросит KEK у KMS и передаст его на ESXi назначения.

2. ESXi источника запрашивает «одноразовый ключ» у vCenter. vCenter генерирует ключ и передаёт его хостам источника и назначения миграции.

3. ESXi источника зашифровывает «одноразовым ключом» ОЗУ виртуальной машины и расшифрованный DEK и передаёт их на хост назначения с помощью vMotion

4. ESXi назначения расшифровывает «одноразовым ключом» полученные данные и VM продолжает работу на ESXi назначения.

Как настроить VM Encryption

Поскольку есть множество KMS серверов с поддержкой KMIP (у VMware даже есть документ, описывающий «сертифицированные KMS»), я не буду рассматривать конкретную реализацию KMS, выбор и настройку также обойду стороной. В моей тестовой среде уже есть кластер KMS из трёх нод, в котором каждая нода реплицирует данные с другими нодами.

Если у вас нет KMS, можете взять любой из списка «сертифицированных». Бесплатных решений в этом списке нет, если требуется что-то такое, смотрите в сторону PyKMIP. Кластер на PyKMIP построить нельзя, но с vCenter он работает. Проверял.

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

Установка доверительных отношений между vCenter и KMS

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

Создаём новый кластер, указываем адрес нашей первой ноды и порт 5696 (стандартный порт KMIP). В моем случае логин и пароль указывать не требуется, но это может зависеть от реализации KMS.

Говорим vCenter доверять KMS.

На следующем шаге нам нужно, чтобы KMS доверял vCenter. Нажимаем MAKE KMS TRUST VCENTER.

На выбор есть несколько вариантов установки доверия KMS к vCenter. В случае с нашим кластером используется способ загрузки в vCenter ключевой пары KMS.

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

После установки доверия KMS к vCenter, кластер KMS будет доверять этому vCenter. Добавляем в vCenter остальные ноды KMS (загрузка пары ключей этих нод не потребуется) и на этом настройка KMS завершена.

Создание Storage Policy с шифрованием

Следующим шагом будет создание Storage Policy, использующей шифрование.

VM Encryption позволяет хранить VM с шифрованием и без шифрования на одной СХД. У нас уже есть Storage Policy vcd-default-policy. Создадим аналогичную vcd-default-encrypted-policy и включим шифрование в параметрах Host based services.

Как управлять шифрованием из vSphere Client

Когда KMS и Storage Policy настроены, можно применить Storage Policy с шифрованием к VM. Включаем шифрование в настройках VM, выбирая vcd-default-encrypted-policy. На примере Linux машины это выглядит так.

Применяем настройки, и в Tasks виртуальной машины видим прогресс выполнения первичного шифрования.

Шифрование конфигурационных файлов VM без шифрования дисков

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

VM configuration files are encrypted.

No hard disks are encrypted.

Мы можем использовать такой сценарий для подключения vTPM и используя Bitlocker в Windows VM. Про vTPM и Bitlocker расскажу дальше.

Дополнительные возможности для Windows

Virtualization Based Security

Для Windows 10, Windows Server 2016 и новее мы можем использовать Virtualization Based Security. Включение VBS принудительно установит механизм загрузки в UEFI и включит Secure Boot. Если VM использовала BIOS, она, скорее всего, не загрузится после включения.

Про VBS можно прочитать в документации Microsoft или блоге VMware. VBS недостаточно включить в настройках виртуальной машины, его необходимо настроить в гостевой ОС. Процедура настройки описана здесь и в документации Microsoft.

Virtual Trusted Platform Module

Для Windows 10 и Windows Server 2016 и новее, включив шифрование конфигурационных файлов VM и используя для загрузки UEFI (Secure boot можно не включать), в настройках VM становится доступна установка vTPM.

Данные vTPM хранятся в файле *.nvram в зашифрованном виде.

В гостевой ОС vTPM определяется как обычный физический TPM 2.0.

Bitlocker

С vTPM мы можем использовать Windows Bitlocker без ввода пароля при загрузке Windows.

Windows будет загружаться автоматически и разблокировать диски с помощью ключей в vTPM. Если такую VM вынести за пределы площадки облачного провайдера, (или, если vTPM будет изменён, а такое происходит даже при восстановлении бэкапа VM, кроме восстановления поверх) то Bitlocker будет требовать ввести ключ восстановления Bitlocker. Перенести ключи из vTPM невозможно (такой кейс не описан в документации и простых способов извлечения ключей из vTPM я не вижу).

После ввода ключа восстановление Bitlocker диск останется зашифрован и начнёт использовать новый vTPM, т.е., в случае изменения vTPM, ключ восстановления Bitlocker нужно будет ввести только 1 раз.

Кейс использования vTPM + Bitlocker может быть компромиссом между удобством (VM включается автоматически без ввода пароля Bitlocker) и безопасностью данных (данные зашифрованы средствами гостевой ОС).

Как управлять шифрованием VM из VMware Cloud Director. Взгляд со стороны клиента облачного провайдера

Через панель управления VMware Cloud Director 10.1 и новее есть возможность выбрать Storage Policy, использующую шифрование.

Можно изменять как VM default policy, и в этом случае, изменится политика всех дисков VM, у которых Storage policy не задана явно (задана как VM default policy), а также изменится политика хранения конфигурационных файлов VM.

Также можно задавать Storage Policy индивидуально для каждого диска.

Необходимо придерживаться правила, чтоб все диски VM были или зашифрованы, или были без шифрования. При попытке использования дисков с шифрованием и без шифрования на одной виртуальной машине VMware Cloud Director не позволит это сделать.

При зашифрованных конфигурационных файлах виртуальной машины мы увидим напротив VM Storage Policy надпись (Encrypted). При зашифрованных дисках надпись (Encrypted) будет отображаться напротив каждого виртуального диска.

vTPM без шифрования диска средствами VM Encryption

Чтобы подключить vTPM, конфигурационные файлы VM нужно зашифровать (также, должен быть включен Secure Boot и использовать Windows в качестве гостевой ОС). Если использовать Bitlocker, то шифрование дисков VM средствами VM Encryption приведёт к двойному шифрованию и может негативно сказаться на производительности. Чтобы зашифровать конфигурационные файлы и не шифровать диски VM, необходимо назначить VM Storage Policy c шифрованием, а для дисков использовать Storage Policy без шифрования.

Подключить vTPM из интерфейса VMware Cloud Director нельзя, но это возможно сделать через vSphere Client силами инженеров облачного провайдера.

Недокументированная фича

vTPM для *nix систем

Существует недокументированный способ подключить vTPM для *nix, или для Windows, использующей BIOS. Этим способом можно подключить vTPM к любой виртуальной машине.

Для этого нужно подключить vTPM, используя PowerCLI. Установим PowerCLI и выполним скрипт через PowerShell.

Import-Module VMware.PowerCLI # Для PowerShell Core используйте Import-Module VMware.VimAutomation.Core
Connect-VIServer -Server  -User  -Password  # Учетные данные от vCenter 
$VMName = "Ubuntu1804_UEFI" # Имя VM, в которую нужно добавить vTPM
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.DeviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
$spec.DeviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
$spec.DeviceChange[0].Device = New-Object VMware.Vim.VirtualTPM
$spec.DeviceChange[0].Device.DeviceInfo = New-Object VMware.Vim.Description
$spec.DeviceChange[0].Device.DeviceInfo.Summary = 'Trusted Platform Module'
$spec.DeviceChange[0].Device.DeviceInfo.Label = 'Trusted Platform Module'
$spec.DeviceChange[0].Device.Key = -1
$spec.DeviceChange[0].Operation = 'add'
$_this = Get-VM $VMname | Get-View
$_this.ReconfigVM_Task($spec)

После выполнения скрипта мы увидим, что конфигурационные файлы VM зашифрованы, но диск использует Storage Policy без шифрования.

Также отобразится подключенный vTPM.

Проверим работу vTPM в Ubuntu 1804.

На Ubuntu установим пакеты:

apt install clevis clevis-tpm2

Проверим наличие TPM

test -c /dev/tpm0 && echo OK || echo FAIL

Проверим работу TPM

echo 'Test vTPM' | clevis encrypt tpm2 '{}' > test.jwe

cat test.jwe | clevis decrypt tpm2

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

Как делать резервные копии зашифрованных VM

Я провёл тестирования резервного копирования и восстановления с помощью Veeam Backup & Replication 10. Использовал один сервер бэкапа и две виртуальные машины Veeam Proxy в режиме Virtual Appliance. Тестировал бэкап из vDC VMware Cloud Director.

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

Провёл 35 тестов. Во всех тестах использовал Windows Server 2019 EN c 1 диском на 40ГБ.

Рассматривал 6 вариаций конфигурации VM:

1. VM с BIOS;

2. VM с UEFI;

3. VM с UEFI и включенным Secure Boot;

4. VM с UEFI, включенным Secure Boot и включенным Virtualization Based Security;

5. VM с UEFI, включенным Secure Boot, включенным Virtualization Based Security, установленным vTPM и настроенным BitLocker в гостевой ОС;

6. VM с BIOS, бэкап которой выполнялся на Storage Policy без шифрования, затем было включено шифрования и бэкап выполнялся уже зашифрованной VM (Кейс, где шифрование будет включено на VM, бэкап которой уже выполнялся до включения шифрования).

   Для каждой VM протестировал 2 варианта бэкапа и 3 варианта восстановления.

 В таблице ниже привожу результаты тестирования.

VEEAM «забирает» с ESXi уже расшифрованную VM. Если используется шифрование диска только VM Encryption, бэкап будет расшифрованным. Если диск зашифрован средствами гостевой ОС, то Veeam, ожидаемо, не может его расшифровать.

Отказоустойчивость

Что будет, если упадёт кластер KMS

Очевидно, что ничего хорошего. В окне конфигурации Key Management Servers в vCenter будет такая картина.

Падение KMS не повлияет на уже запущенные VM, которые продолжать работать (и их можно будет выключать, включать, мигрировать на другие хосты) до тех пор, пока в ОЗУ ESXi хранятся KEK, ранее полученные у KMS. KEK будут храниться в памяти до перезагрузки ESXi хоста.

При попытке включить VM Encryption при неработающем KMS пойдут ошибки генерации ключа.

Что произойдёт при перезагрузке ESXi хоста

Хост будет требовать включить шифрование вручную

VM, будучи зарегистрированной на хосте, который не хранит в ОЗУ KEK для этой VM (например, если ESXi хост был перезагружен или был добавлен в кластер после первичной инициализации шифрования), будет требовать разблокировать её, передав KEK на ESXi хост.

Выводы

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

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