Прежде всего, KMS - это сервисы шифрования не только для виртуальных машин, но и любых других объектов ИТ-инфраструктуры. Поэтому KMS уже может быть в вашей организации, при этом он может не быть прикрученным к VMware vSphere. Вы можете использовать любой KMS-сервер, но VMware сертифицировала лишь следующие системы из списка (см. вот этот документ VMware):
Если же у вас другой KMS-провайдер, не расстраивайтесь - он, скорее всего, будет работать, если поддерживает протокол управления ключами KMIP 1.1.
Начать надо с вопросов доступности KMS-сервера. Как вы понимаете, это самый важный сервер в вашей инфраструктуре, важнее DNS или контроллера домена. Если у вас недоступен DNS, все тоже не работает, как и в случае с KMS, но если оказались недоступными данные хранилища KMS - это катастрофа для организации. И нет абсолютно никакого пути восстановить их. Совершенно никакого. Обо всем этом рассказывает видео ниже:
Таким образом, KMS становится бизнес-критичной точкой не только инфраструктуры, но и бизнеса в целом. И вопросы бэкапа и его доступности - это вопросы номер 1. Давайте посмотрим на несколько базовых понятий KMS:
KMIP (Key Management Interoperability Protocol) - это стандарт, по которому клиент KMIP может общаться с серверами KMS. Каждый год он проходит серьезную проверку на конференции RSA.
DEK (Data Encryption Key). Это ключ, который хост ESXi генерирует, когда требуется зашифровать виртуальную машину. Этот ключ используется также и для расшифровывания данных ВМ, он записан в VMX/VM Advanced settings в зашифрованном виде.
KEK (Key Encryption Key). Это ключ, которым зашифрован DEK. KEK key ID также находится в VMX/VM Advanced settings.
Key Manager Cluster/Alias - это коллекция адресов FQDN/IP всех реплицируемых между собой серверов KMS. Она также хранится вместе с зашифрованной машиной в VMX/VM Advanced settings, чтобы после ее включения можно было обратиться к нужному кластеру KMS, получить KEK для cервера vCenter, который разлочит ВМ.
VM и vSAN encryption - это, на самом деле, с точки зрения реализации механизма шифрования одно и то же. То есть, для обоих типов шифрования используются одни и те же библиотеки, конфигурации и интерфейсы.
Когда мы говорим о кластере KMS - это всего лишь KMS-серверы, реплицирующие между собой хранилища ключей. Они не обеспечивают доступность друг друга, как, например, это делает VMware HA. Например, есть серверы KMS-A, KMS-B и KMS-C, в хранилищах которых при добавлении ключа новой ВМ он появляется мгновенно.
Если KMS-A недоступен как сервер, то сервер vCenter запрашивает ключи у хоста KMS-B. Если же KMS-A недоступен как сервис (то есть сервер работает, а служба KMS не отвечает), то vCenter ждет 60 секунд восстановления работоспособности сервиса и только потом переключается на KMS-B. Это поведение изменить нельзя.
Лучшие практики по использованию KMS таковы:
По возможности нужно делегировать обязанности по поддержке инфраструктуры KMS отдельной команде (Security Team) или человеку.
Не класть KMS-серверы в виртуальной машине в тот же кластер (например, vSAN), который также зашифрован. Иначе коробочка закроется (выключится кластер), а ключ от нее останется внутри нее же. То есть, необходимо держать хотя бы один из KMS-серверов за пределами такого домена отказа.
Предыдущий пункт относится и к серверам vCenter и PSC. Чтобы они могли расшифровать другие сервера, они должны быть доступны в случае сбоя.
Теперь надо сказать о катастрофоустойчивости серверов KMS. Типичный кластер в рамках одной площадки выглядит так:
Но если на этой площадке будет авария, которая затронет все 3 сервера - бизнесу может настать конец. Поэтому в идеале надо использовать конфигурацию с двумя площадками:
Понятное дело, что у малого и среднего бизнеса резервных площадок, как правило, нет. В этом случае помочь может публичное облако Amazon AWS или Microsoft Azure. Чтобы поддерживать там одну резервную машину, много денег не нужно.
Ну и если вы используете конфигурацию с несколькими площадками, то обязательно нужно учитывать в конфигурации порядок обращения к серверам KMS в рамках площадки. Если на первой площадке находятся сервера KMS-A, KMS-B и KMS-C, а на второй - KMS-D, KMS-E и KMS-F, то в первом случае порядок должен быть A,B,C,D,E,F, а во втором - D,E,F,A,B,C.
Если на второй площадке вы будете использовать конфигурацию аналогичную первой, сервер vCenter может ходить по серверам другой площадки, которая может быть недоступна, а только обойдя все ее серверы, начнет использовать локальные KMS.
RSS
