Введение

В современных ИТ-системах шифрование данных стало обязательным элементом защиты информации. Цель шифрования — гарантировать, что данные могут прочитать только системы, обладающие нужными криптографическими ключами. Любой, не имеющий ключей доступа, увидит лишь бессмысленный набор символов, поскольку информация надёжно зашифрована устойчивым алгоритмом AES-256. VMware vSAN поддерживает два уровня шифрования для повышения безопасности кластерного хранения данных: шифрование данных на носителях (Data-at-Rest Encryption) и шифрование данных при передаче (Data-in-Transit Encryption). Эти механизмы позволяют защитить данные как в состоянии покоя (на дисках), так и в движении (между узлами кластера). В результате vSAN помогает организациям соответствовать требованиям регуляторов и предотвращать несанкционированный доступ к данным, например, при краже носителей или перехвате сетевого трафика.

Сегодня мы расскажем о шифровании данных в платформе VMware vSAN, если вы хотите получить больше подробностей, то обратитесь к документу "vSAN Encryption Services: Understanding Encryption Offerings with vSAN using VMware Cloud Foundation 9.0".

Архитектура и компоненты vSAN Encryption Services

Компоненты решения

Архитектура шифрования vSAN включает несколько ключевых элементов: внешний или встроенный сервер управления ключами (KMS), сервер VMware vCenter, гипервизоры ESXi в составе vSAN-кластера и собственно криптографические модули в ядре гипервизора. Внешний KMS-сервер (совместимый с протоколом KMIP), либо встроенный поставщик ключей vSphere NKP, обеспечивает генерацию и хранение мастер-ключей шифрования. vCenter Server отвечает за интеграцию с KMS: именно vCenter устанавливает доверенные отношения (обмен сертификатами) с сервером ключей и координирует выдачу ключей хостам ESXi. Каждый узел ESXi, входящий в шифрованный кластер vSAN, содержит встроенный криптомодуль VMkernel (сертифицированный по требованиям FIPS), который выполняет операции шифрования и дешифрования данных на стороне гипервизора.

Распределение ключей

При включении шифрования vSAN на кластере vCenter запрашивает у KMS два ключа для данного кластера: ключ шифрования ключей (Key Encryption Key, KEK) и ключ хоста (Host Key). KEK играет роль мастер-ключа: с его помощью будут шифроваться все остальные ключи (например, ключи данных). Host Key предназначен для защиты дампов памяти (core dumps) и других служебных данных хоста. После получения этих ключей vCenter передаёт информацию о KMS и идентификаторы ключей (ID) всем хостам кластера. Каждый узел ESXi устанавливает прямое соединение с KMS (по протоколу KMIP) и получает актуальные копии KEK и Host Key, помещая их в защищённый кэш памяти.

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

Ключи данных (DEK)

Помимо вышеупомянутых кластерных ключей, каждый диск или объект данных получает свой собственный ключ шифрования данных (Data Encryption Key, DEK). В оригинальной архитектуре хранения vSAN (OSA) гипервизор генерирует уникальный DEK (алгоритм XTS-AES-256) для каждого физического диска в дисковой группе. Эти ключи оборачиваются (wrap) с помощью кластерного KEK и сохраняются в метаданных, что позволяет безопасно хранить ключи на дисках: получить «сырой» DEK можно только расшифровав его при помощи KEK. В более новой архитектуре vSAN ESA подход несколько отличается: используется единый ключ шифрования кластера, но при этом для различных объектов данных применяются уникальные производные ключи. Благодаря этому данные каждой виртуальной машины шифруются своим ключом, даже если в основе лежит общий кластерный ключ. В обоих случаях vSAN обеспечивает надёжную защиту: компрометация одного ключа не даст злоумышленнику доступа ко всему массиву данных.

Роль гипервизора и производительность

Шифрование в vSAN реализовано на уровне ядра ESXi, то есть прозрачно для виртуальных машин. Гипервизор использует сертифицированный криптографический модуль VMkernel, прошедший все необходимые проверки по стандарту FIPS 140-2 (а в новых версиях — и FIPS 140-3). Все операции шифрования выполняются с использованием аппаратного ускорения AES-NI, что минимизирует влияние на производительность системы. Опыт показывает, что нагрузка на CPU и задержки ввода-вывода при включении шифрования vSAN обычно незначительны и хорошо масштабируются с ростом числа ядер и современных процессоров. В свежей архитектуре ESA эффективность ещё выше: благодаря более оптимальному расположению слоя шифрования в стеке vSAN, для той же нагрузки требуется меньше CPU-циклов и операций, чем в классической архитектуре OSA.

Управление доступом

Стоит упомянуть, что управление шифрованием в vSAN встроено в систему ролей и привилегий vCenter. Только пользователи с особыми правами (Cryptographic administrator) могут настраивать KMS и включать/отключать шифрование на кластере. Это добавляет дополнительный уровень безопасности: случайный администратор без соответствующих привилегий даже не увидит опцию включения шифрования в интерфейсе. Разграничение доступа гарантирует, что ключи шифрования и связанные операции контролируются ограниченным кругом доверенных администраторов.

Поддерживаемые типы шифрования

Шифрование данных на носителях (vSAN Data-at-Rest Encryption)

Этот тип шифрования обеспечивает защиту всех данных, хранящихся в vSAN-датасторе. Включение функции означает, что вся информация, записываемая на диски кластера, автоматически шифруется на последнем этапе ввода-вывода перед сохранением на устройство. При чтении данные расшифровываются гипервизором прозрачно для виртуальных машин – приложения и ОС внутри ВМ не осведомлены о том, что данные шифруются. Главное назначение Data-at-Rest Encryption – обезопасить данные на случай, если накопитель будет изъят из системы (например, при краже или некорректной утилизации дисков).

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

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

То есть в ESA шифрование также не препятствует сжатию. Однако особенностью ESA является то, что все данные, покидающие узел, уже зашифрованы высокоуровневым ключом кластера (что частично перекрывает и трафик между узлами – см. ниже). Тем не менее для обеспечения максимальной криптостойкости vSAN ESA по-прежнему поддерживает отдельный механизм Data-in-Transit Encryption для уникального шифрования каждого сетевого пакета.

Включение и поддержка: шифрование данных на носителях включается на уровне всего кластера vSAN – достаточно установить флажок «Data-at-Rest Encryption» в настройках служб vSAN для выбранного кластера. Данная возможность доступна только при наличии лицензии vSAN Enterprise или выше.

В традиционной архитектуре OSA шифрование можно включать как при создании нового кластера, так и на уже работающем кластере. В последнем случае vSAN выполнит поочерёдное перевоспроизведение данных с каждого диска (evacuation) и форматирование дисковых групп в зашифрованном виде, что потребует определённых затрат ресурсов и времени. В архитектуре ESA, напротив, решение о шифровании принимается только на этапе создания кластера и не может быть изменено позднее без полной перестройки хранилища. Это связано с тем, что в ESA шифрование глубоко интегрировано в работу кластера, обеспечивая максимальную производительность, но и требуя фиксации режима на старте. В обоих случаях, после включения, сервис шифрования прозрачно работает со всеми остальными функциями vSAN (в том числе со снапшотами, клонированием, vMotion и т.д.) и практически не влияет на операционную деятельность кластера.

Шифрование данных при передаче (vSAN Data-in-Transit Encryption)

Второй компонент системы безопасности vSAN – это шифрование сетевого трафика между узлами хранения. Функция Data-in-Transit Encryption гарантирует, что все данные, пересылаемые по сети между хостами vSAN, будут зашифрованы средствами гипервизора.

Это особенно важно, если сеть хранения не полностью изолирована или если требуется соответствовать строгим стандартам по защите данных в транзите. Механизм шифрования трафика не требует KMS: при включении этой опции хосты vSAN самостоятельно генерируют и обмениваются симметричными ключами для установления защищённых каналов. Процесс полностью автоматизирован и не требует участия администратора – достаточно активировать настройку в параметрах кластера.

Data-in-Transit Encryption впервые появилась в vSAN 7 Update 1 и доступна для кластеров как с OSA, так и с ESA. В случае OSA администратор может независимо включить шифрование трафика (оно не зависит от шифрования на дисках, но для полноты защиты желательно задействовать оба механизма). В случае ESA отдельного переключателя может не потребоваться: при создании кластера с шифрованием данные «на лету» фактически уже будут выходить из узлов зашифрованными единым высокоуровневым ключом. Однако, чтобы каждый сетевой пакет имел уникальный криптографический отпечаток, ESA по-прежнему предусматривает опцию Data-in-Transit (она остаётся активной в интерфейсе и при включении обеспечит дополнительную уникализацию шифрования каждого пакета). Следует учесть, что на момент выпуска vSAN 9.0 в составе VCF 9.0 шифрование трафика поддерживается только для обычных (HCI) кластеров vSAN и недоступно для т. н. disaggregated (выделенных storage-only) кластеров.

С технической точки зрения, Data-in-Transit Encryption использует те же проверенные криптомодули, сертифицированные по FIPS 140-2/3, что и шифрование данных на дисках. При активации этой функции vSAN автоматически выполняет взаимную аутентификацию хостов и устанавливает между ними защищённые сессии с помощью динамически создаваемых ключей. Когда новый узел присоединяется к шифрованному кластеру, для него генерируются необходимые ключи и он аутентифицируется существующими участниками; при исключении узла его ключи отзываются, и трафик больше не шифруется для него. Всё это происходит «под капотом», не требуя ручной настройки. В результате даже при потенциальном перехвате пакетов vSAN-трафика на уровне сети, извлечь из них полезные данные не представляется возможным.

Интеграция с KMS

Требование наличия KMS

Для использования шифрования данных на vSAN необходим сервер управления ключами (Key Management Server, KMS), совместимый со стандартом KMIP 1.1+. Исключение составляет вариант применения встроенного поставщика ключей vSphere (Native Key Provider, NKP), который появился начиная с vSphere 7.0 U2. Внешний KMS может быть программным или аппаратным (множество сторонних решений сертифицировано для работы с vSAN), но в любом случае требуется лицензия не ниже vSAN Enterprise.

Перед включением шифрования администратор должен зарегистрировать KMS в настройках vCenter: добавить информацию о сервере и установить доверие между vCenter и KMS. Обычно настройка доверия реализуется через обмен сертификатами: vCenter либо получает от KMS корневой сертификат (Root CA) для проверки подлинности, либо отправляет на KMS сгенерированный им запрос на сертификат (CSR) для подписи. В результате KMS и vCenter обмениваются удостоверяющими сертификатами и устанавливают защищённый канал. После этого vCenter может выступать клиентом KMS и запрашивать ключи.

В конфигурации с Native Key Provider процесс ещё проще: NKP разворачивается непосредственно в vCenter, генерируя мастер-ключ локально, поэтому внешний сервер не нужен. Однако даже в этом случае рекомендуется экспортировать (зарезервировать) копию ключа NKP во внешнее безопасное место, чтобы избежать потери ключей в случае сбоя vCenter.

Запрос и кэширование ключей

Как только доверие (trust) между vCenter и KMS установлено, можно активировать шифрование vSAN на уровне кластера. При этом vCenter от имени кластера делает запрос в KMS на выдачу необходимых ключей (KEK и Host Key) и распределяет их идентификаторы хостам, как описано выше. Каждый ESXi узел соединяется с KMS напрямую для получения своих ключей. На период нормальной работы vSAN-хосты обмениваются ключами с KMS напрямую, без участия vCenter.

Это означает, что после первоначальной настройки для ежедневной работы кластера шифрования доступность vCenter не критична – даже если vCenter временно выключен, хосты будут продолжать шифровать/расшифровывать данные, используя ранее полученные ключи. Однако vCenter нужен для проведения операций управления ключами (например, генерации новых ключей, смены KMS и пр.). Полученные ключи хранятся на хостах в памяти, а при наличии TPM-модуля – ещё и в его защищённом хранилище, что позволяет пережить перезагрузку хоста без немедленного запроса к KMS.

VMware настоятельно рекомендует оснащать все узлы vSAN доверенными платформенными модулями TPM 2.0, чтобы обеспечить устойчивость к отказу KMS: если KMS временно недоступен, хосты с TPM смогут перезапускаться и монтировать зашифрованное хранилище, используя кешированные в TPM ключи.

Лучшие практики KMS

В контексте vSAN есть важное правило: не размещать сам KMS на том же зашифрованном vSAN-хранилище, которое он обслуживает. Иначе возникает круговая зависимость: при отключении кластера или перезагрузке узлов KMS сам окажется недоступен (ведь он работал как ВМ на этом хранилище), и хосты не смогут получить ключи для расшифровки датасторов.

Лучше всего развернуть кластер KMS вне шифруемого кластера (например, на отдельной инфраструктуре или как облачный сервис) либо воспользоваться внешним NKP от другого vCenter. Также желательно настроить кластер из нескольких узлов KMS (для отказоустойчивости) либо, в случае NKP, надёжно сохранить резервную копию ключа (через функцию экспорта в UI vCenter).

При интеграции с KMS крайне важна корректная сетевая настройка: все хосты vSAN-кластера должны иметь прямой доступ к серверу KMS (обычно по протоколу TLS на порт 5696). В связке с KMS задействуйте DNS-имя для обращения (вместо IP) – это упростит перенастройку в случае смены адресов KMS и снизит риск проблем с подключением.

vSphere Native Key Provider

Этот встроенный механизм управления ключами в vCenter заслуживает отдельного упоминания. NKP позволяет обойтись без развертывания отдельного KMS-сервера, что особенно привлекательно для небольших компаний или филиалов. VMware поддерживает использование NKP для шифрования vSAN начиная с версии 7.0 U2. По сути, NKP хранит мастер-ключ в базе данных vCenter (в зашифрованном виде) и обеспечивает необходимые функции выдачи ключей гипервизорам. При включении шифрования vSAN с NKP процесс выдачи ключей аналогичен: vCenter генерирует KEK и распределяет его на хосты. Разница в том, что здесь нет внешнего сервера – все операции выполняются средствами самого vCenter.

Несмотря на удобство, у NKP есть ограничения (например, отсутствие поддержки внешних интерфейсов KMIP для сторонних приложений), поэтому для крупных сред на долгосрочной основе часто выбирают полноценный внешний KMS. Тем не менее, NKP – это простой способ быстро задействовать шифрование без дополнительных затрат, и он идеально подходит для многих случаев использования.

Процесс шифрования и дешифрования

Запись данных (шифрование)

После того как кластер vSAN сконфигурирован для шифрования и получены необходимые ключи, каждая операция записи данных проходит через этап шифрования в гипервизоре. Рассмотрим упрощённо этот процесс на примере OSA (Original Storage Architecture):

• Получение блока данных. Виртуальная машина записывает данные на диск vSAN, которые через виртуальный контроллер поступают на слой vSAN внутри ESXi. Там данные сначала обрабатываются сервисами оптимизации – например, вычисляются хеши для дедупликации и выполняется сжатие (если эти функции включены на кластере).
• Шифрование блока. Когда очередь дошла до фактической записи блока на устройство, гипервизор обращается к ключу данных (DEK), связанному с целевым диском, и шифрует блок по алгоритму AES-256 (режим XTS) с помощью этого DEK. Как упоминалось, в OSA у каждого диска свой DEK, поэтому даже два диска одного узла шифруют данные разными ключами. Шифрование происходит на уровне VMkernel, используя AES-NI, и добавляет минимальную задержку.
• Запись на устройство. Зашифрованный блок записывается в кеш или напрямую на SSD в составе дисковой группы. На носитель попадают только зашифрованные данные; никакой незашифрованной копии информации на диске не сохраняется. Метаданные vSAN также могут быть зашифрованы или содержать ссылки на ключ (например, KEK_ID), но без владения самим ключом извлечь полезную информацию из зашифрованного блока невозможно.

В архитектуре ESA процесс схож, с тем отличием, что шифрование происходит сразу после сжатия, ещё на высокоуровневом слое ввода-вывода. Это означает, что данные выходят из узла уже шифрованными кластерным ключом. При наличии Data-in-Transit Encryption vSAN накладывает дополнительное пакетное шифрование: каждый сетевой пакет между хостами шифруется с использованием симметрических ключей сеанса, которые регулярно обновляются. Таким образом, данные остаются зашифрованы как при хранении, так и при передаче по сети, что создаёт многослойную защиту (end-to-end encryption).

Чтение данных (дешифрование)

Обратный процесс столь же прозрачен. Когда виртуальная машина запрашивает данные из vSAN, гипервизор на каждом затронутом хосте находит нужные зашифрованные блоки на дисках и считывает их. Прежде чем передать данные наверх VM, гипервизор с помощью соответствующего DEK выполняет расшифровку каждого блока в памяти. Расшифрованная информация проходит через механизмы пост-обработки (восстановление сжатых данных, сборка из дедуплицированных сегментов) и отправляется виртуальной машине. Для ВМ этот процесс невидим – она получает привычный для себя блок данных, не зная, что на физическом носителе он хранится в зашифрованном виде. Если задействовано шифрование трафика, то данные могут передаваться между узлами в зашифрованном виде и расшифровываются только на том хосте, который читает их для виртуальной машины-потребителя.

Устойчивость к сбоям

При нормальной работе все операции шифрования/дешифрования происходят мгновенно для пользователя. Но стоит рассмотреть ситуацию с потенциальным сбоем KMS или перезагрузкой узла. Как отмечалось ранее, хосты кэшируют полученные ключи (KEK, Host Key и необходимые DEK) в памяти или TPM, поэтому кратковременное отключение KMS не влияет на работающий кластер.

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

Управление ключами и ротация

Замена ключей (Rekey)

Безопасность криптосистемы во многом зависит от регулярной смены ключей. VMware vSAN предоставляет администраторам возможность проводить плановую ротацию ключей шифрования без простоя и с минимальным влиянием на работу кластера. Поддерживаются два режима: «мелкая» ротация (Shallow Rekey) и «глубокая» ротация (Deep Rekey). При shallow rekey генерируется новый мастер-ключ KEK, после чего все ключи данных (DEK) перешифровываются этим новым KEK (старый KEK уничтожается). Важно, что сами DEK при этом не меняются, поэтому операция выполняется относительно быстро: vSAN просто обновляет ключи в памяти хостов и в метаданных, не перестраивая все данные на дисках. Shallow rekey обычно используют для регулярной смены ключей в целях комплаенса (например, раз в квартал или при смене ответственного администратора).

Deep rekey, напротив, предполагает полную замену всех ключей: генерируются новые DEK для каждого объекта/диска, и все данные кластера постепенно перераспределяются и шифруются уже под новыми ключами. Такая операция более ресурсоёмка, фактически аналогична повторному шифрованию всего объёма данных, и может занять продолжительное время на крупных массивах. Глубокую ротацию имеет смысл выполнять редко – например, при подозрении на компрометацию старых ключей или после аварийного восстановления системы, когда есть риск утечки ключевой информации. Оба типа рекея можно инициировать через интерфейс vCenter (в настройках кластера vSAN есть опция «Generate new encryption keys») или с помощью PowerCLI-скриптов. При этом для shallow rekey виртуальные машины могут продолжать работать без простоев, а deep rekey обычно тоже выполняется онлайн, хотя и создаёт повышенную нагрузку на подсистему хранения.

Смена KMS и экспорт ключей

Если возникает необходимость поменять используемый KMS (например, миграция на другого вендора или переход от внешнего KMS к встроенному NKP), vSAN упрощает эту процедуру. Администратор добавляет новый KMS в vCenter и обозначает его активным для данного кластера. vSAN автоматически выполнит shallow rekey: запросит новый KEK у уже доверенного нового KMS и переведёт кластер на использование этого ключа, перешифровав им все старые DEK. Благодаря этому переключение ключевого сервиса происходит прозрачно, без остановки работы хранилища. Тем не менее, после замены KMS настоятельно рекомендуется удостовериться, что старый KMS более недоступен хостам (во избежание путаницы) и сделать резервную копию конфигурации нового KMS/NKP.

При использовании vSphere Native Key Provider важно регулярно экспортировать зашифрованную копию ключа NKP (через интерфейс vCenter) и хранить её в безопасном месте. Это позволит восстановить доступ к зашифрованному vSAN, если vCenter выйдет из строя и потребуется его переустановка. В случае же аппаратного KMS, как правило, достаточно держать под рукой актуальные резервные копии самого сервера KMS (или использовать кластер KMS из нескольких узлов для отказоустойчивости).

Безопасное удаление данных

Одним из побочных преимуществ внедрения шифрования является упрощение процедуры безопасной утилизации носителей. vSAN предлагает опцию Secure Disk Wipe для случаев, когда необходимо вывести диск из эксплуатации или изъять узел из кластера. При включенной функции шифрования проще всего выполнить «очистку» диска путем сброса ключей: как только DEK данного носителя уничтожен (либо кластерный KEK перегенерирован), все данные на диске навсегда остаются в зашифрованном виде, то есть фактически считаются стёртыми (так называемая криптографическая санация).

Кроме того, начиная с vSAN 8.0, доступна встроенная функция стирания данных в соответствии со стандартами NIST (например, перезапись нулями или генерация случайных шаблонов). Администратор может запустить безопасное стирание при выведении диска из кластера – vSAN приведёт накопитель в состояние, удовлетворяющее требованиям безопасной утилизации, удалив все остаточные данные. Комбинация шифрования и корректного удаления обеспечивает максимальную степень защиты: даже физически завладев снятым накопителем, злоумышленник не сможет извлечь конфиденциальные данные.

Поддержка FIPS и совместимость

Соответствие стандартам (FIPS)

VMware vSAN Encryption Services были разработаны с учётом строгих требований отраслевых стандартов безопасности. Криптографический модуль VMkernel, на котором основано шифрование vSAN, прошёл валидацию FIPS 140-2 (Cryptographic Module Validation Program) ещё в 2017 году. Это означает, что реализация шифрования в гипервизоре проверена независимыми экспертами и отвечает критериям, предъявляемым правительственными организациями США и Канады.

Более того, в 2024 году VMware успешно завершила сертификацию модуля по новому стандарту FIPS 140-3, обеспечив преемственность соответствия более современным требованиям. Для заказчиков из сфер, где необходима сертификация (государственный сектор, финансы, медицина и т.д.), это даёт уверенность, что vSAN может использоваться для хранения чувствительных данных. Отдельно отметим, что vSAN включена в руководства по безопасности DISA STIG для Министерства обороны США, а также поддерживает механизмы двухфакторной аутентификации администраторов (RSA SecurID, CAC) при работе с vCenter — всё это подчёркивает серьёзное внимание VMware к безопасности решения.

Совместимость с функционалом vSAN

Шифрование в vSAN спроектировано так, чтобы быть максимально прозрачным для остальных возможностей хранения. Дедупликация и сжатие полностью совместимы с Data-at-Rest Encryption: благодаря порядку выполнения (сначала дедупликация/сжатие, потом шифрование) эффективность экономии места практически не снижается. Исключение составляет экспериментальная функция глобальной дедупликации в новой архитектуре ESA — на момент запуска vSAN 9.0 одновременное включение глобальной дедупликации и шифрования не поддерживается (ожидается снятие этого ограничения в будущих обновлениях).

Снапшоты и клоны виртуальных машин на зашифрованном vSAN работают штатно: все мгновенные копии хранятся в том же шифрованном виде, и при чтении/записи гипервизор так же прозрачно шифрует их содержимое. vMotion и другие механизмы миграции ВМ также поддерживаются – сама ВМ при миграции может передаваться с шифрованием (функция Encrypted vMotion, независимая от vSAN) или без него, но это не влияет на состояние ее дисков, которые на принимающей стороне всё равно будут записаны на vSAN уже в зашифрованном виде.

Резервное копирование и репликация

vSAN Encryption не накладывает ограничений на работу средств резервного копирования, использующих стандартные API vSphere (такие как VMware VADP) или репликации на уровне ВМ. Данные читаются гипервизором в расшифрованном виде выше уровня хранения, поэтому бэкап-приложения получают их так же, как и с обычного хранилища. При восстановлении или репликации на целевой кластер vSAN, естественно, данные будут записаны с повторным шифрованием под ключи того кластера. Таким образом, процессы защиты и восстановления данных (VDP, SRM, vSphere Replication и пр.) полностью совместимы с зашифрованными датасторами vSAN.

Ограничения и особенности

Поскольку vSAN реализует программное шифрование, аппаратные самошифрующиеся диски (SED) не требуются и официально не поддерживаются в роли средства шифрования на уровне vSAN. Если в серверы установлены SED-накопители, они могут использоваться, но без включения режимов аппаратного шифрования – vSAN в любом случае выполнит шифрование средствами гипервизора. Ещё один момент: при включении vSAN Encryption отключается возможность рентген-просмотра (в веб-клиенте vSAN) содержимого дисков, так как данные на них хранятся в зашифрованном виде. Однако на функциональность управления размещением объектов (Storage Policy) это не влияет. Наконец, стоит учитывать, что шифрование данных несколько повышает требования к процессорным ресурсам на хостах. Практика показывает, что современные CPU справляются с этим отлично, но при проектировании больших нагрузок (вроде VDI или баз данных на all-flash) закладывать небольшой запас по CPU будет не лишним.

Заключение

VMware vSAN Encryption Services предоставляют мощные средства защиты данных для гиперконвергентной инфраструктуры. Реализовав сквозное шифрование (от диска до сети) на уровне хранения, vSAN позволяет организациям выполнить требования по безопасности без сложных доработок приложений. Среди ключевых преимуществ решения можно отметить:

• Всесторонняя защита данных. Даже если злоумышленник получит физический доступ к носителям или перехватит трафик, конфиденциальная информация останется недоступной благодаря сильному шифрованию (AES-256) и раздельным ключам для разных объектов. Это особенно важно для соблюдения стандартов GDPR, PCI-DSS, HIPAA и других.
• Прозрачность и совместимость. Шифрование vSAN работает под управлением гипервизора и не требует изменений в виртуальных машинах. Все основные функции vSphere (кластеризация, миграция, бэкап) полностью поддерживаются. Решение не привязано к специфическому оборудованию, а опирается на открытые стандарты (KMIP, TLS), что облегчает интеграцию.
• Удобство централизованного управления. Администратор может включить шифрование для всего кластера несколькими кликами – без необходимости настраивать каждую ВМ по отдельности (в отличие от VMcrypt). vCenter предоставляет единый интерфейс для управления ключами, а встроенный NKP ещё больше упрощает старт. При этом разграничение прав доступа гарантирует, что только уполномоченные лица смогут внести изменения в политику шифрования.
• Минимальное влияние на производительность. Благодаря оптимизациям (использование AES-NI, эффективные алгоритмы) накладные расходы на шифрование невелики. Особенно в архитектуре ESA шифрование реализовано с учётом высокопроизводительных сценариев и практически не сказывается на IOPS и задержках. Отсутствуют и накладные расходы по ёмкости: включение шифрования не уменьшает полезный объём хранилища и не создаёт дублирования данных.
• Гибкость в выборе подхода. vSAN поддерживает как внешние KMS от разных поставщиков (для предприятий с уже выстроенными процессами управления ключами), так и встроенный vSphere Native Key Provider (для простоты и экономии). Администраторы могут ротировать ключи по своему графику, комбинировать или отключать сервисы при необходимости (например, включить только шифрование трафика для удалённого филиала с общим хранилищем).

При внедрении шифрования в vSAN следует учесть несколько моментов: обеспечить высокую доступность сервера KMS (или надёжно сохранить ключ NKP), активировать TPM на хостах для хранения ключей, а также не сочетать шифрование vSAN с шифрованием на уровне ВМ (VM Encryption) без крайней необходимости. Двойное шифрование не повышает безопасность, зато усложняет управление и снижает эффективность дедупликации и сжатия.

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

Дункан Эппинг рассказал о том, как можно убедиться, что ваши диски VMware vSAN зашифрованы.

Если у вас включена техника шифрования "vSAN Encryption – Data At Rest", то вы можете проверить, что действительно данные на этих дисках зашифрованы в разделе настроек vSAN в клиенте vSphere Client. Однако вы можете сделать это и на уровне хоста ESXi, выполнив команду:

esxcli vsan storage list

Как вы можете увидеть из вывода команды, для шифрования указан параметр Encryption: true.

Второй момент - вам надо убедиться, что служба управления ключами шифрования Key Management System доступна и работает как положено. Это вы можете увидеть в разделе vSAN Skyline Health клиента vSphere:

Дункан также обращает внимание, что если вы используете Native Key Server и получаете ошибку "not available on host", проверьте, опцию "Use key provider only with TPM". Если она включена, то вы должны иметь модуль TPM для корректной работы механизмов шифрования. Если у вас модуля такого нет - просто снимите эту галочку.

В блоге VirtualPad появилась интересная статья о технологии VMware vSAN Encryption. Шифрование vSAN поддерживает и гибридные, и All-Flash кластеры vSAN. Это относится к архитектуре OSA, поскольку ESA поддерживает только All-Flash для всего пула хранения.

Сейчас поддерживаются следующие методы шифрования vSAN: шифрование данных в состоянии покоя (Data-at-Rest Encryption) и шифрование данных в процессе передачи (Data-in-Transit Encryption). Оба конфигурируются независимо друг от друга и на уровне кластера. vSAN OSA выполняет шифрование на уровне всего кластера. Архитектура HCI Mesh не поддерживает шифрование данных в состоянии покоя.

Шифрование данных в процессе передачи (Data-in-Transit)

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

Процесс шифрования трафика между узлами в кластере vSAN можно свести к трем основным шагам:

• Создается TLS-соединение между узлами vSAN для обмена трафиком
• Узлы vSAN создают общий пароль (secret) и прикрепляют его к текущей сессии
• Общий секрет используется для установления сессии шифрования с аутентификацией между узлами

Шифрование данных в состоянии покоя (Data-at-Rest)

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

• Шифруются данные, находящиеся на устройствах кэша и дисковой емкости
• Поддерживаются конфигурации All-Flash и Hybrid
• Исключается необходимость в самошифрующихся дисках
• Проверено на соответствие FIPS 140-2

Разумеется, выбор шифрования данных в состоянии покоя требует либо сервис управления ключами (Key Manager Service, KMS), либо собственного провайдера ключей vSphere (Native Key Provider, NKP) и конфигурируется на уровне кластера.

Шифрование данных vSAN в состоянии покоя (D@RE) помогает защищаться от ситуаций потери или кражи устройства. Шифрование D@RE в vSAN работает отдельно от шифрования виртуальных машин vSphere (VM Encryption).

Шифрование D@RE в vSAN является процессом реального времени, который шифрует данные до того, как они попадают на диск. Данные никогда не хранятся на диске в незашифрованном состоянии. Если в среде используется дедупликация и сжатие или только сжатие, шифрование происходит после операций дедупликации и сжатия или только сжатия, что позволяет клиенту использовать преимущества экономии места перед шифрованием. Когда данные читаются, они расшифровываются в процессе передачи и возвращаются в гостевую операционную систему. Ну а данные на диске остаются в зашифрованном состоянии.

Многие пользователи кластера отказоустойчивости хранилищ VMware vSAN замечали, что в настройках служб кластера есть такая опция "Erase disks before use", которая доступна при шифровании хранилища (vSAN Encryption).

Эта настройка позволяет очистить диск перед использованием шифрования на нем, чтобы соблюсти требования к безопасности хранения и обслуживания данных, например, NIST 800-88 Revision 1, определение "Clear":

Clear applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported).

В приложении A приведенного выше документа есть такая таблица (приведены только 2 строки из нее):

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

Ставя галку "Erase disks before use" надо понимать, что процесс заполнения блоков случайными значениями занимает значительное время, которое зависит от типа используемого хранилища и инфраструктуры хранения в целом.

Также важно помнить, что включение vSAN Encryption влечет за собой шифрование только новых создаваемых дисковых объектов и не применяется к существующим на хранилище блокам (то есть их потенциально можно считать с диска, расшифровка их не потребуется). Таким образом, использование vSAN Encryption с настройкой "Erase disks before use" имеет смысл только при добавлении устройств, где ранее существовали данные.

Поэтому:

• Включайте опцию "Erase disks before use", когда:
  • Включаете vSAN Encryption для существующуего vSAN кластера, в котором требуется вычистить свободные блоки.
  • Добавляете хост, который имел ранее данные на локальных дисках, в кластер vSAN.
  • Выполняете операцию rekey для инициации процедуры deep rekey (запрос нового KEK и новых уникальных DEKs для каждого устройства vSAN).
• Не обязательно включать "Erase disks before use", когда:
  • Включаете vSAN Encryption для полностью нового кластера vSAN, в котором ранее не было данных на добавляемых дисках.
  • Добавляете в кластер vSAN хост, у которого на локальных дисках не было чувствительных данных.
  • Выполняете операцию rekey для инициации процедуры shallow rekey (только запрос нового KEK).

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

• Новая версия платформы виртуализации VMware vSphere 6.7 доступна для скачивания
• Сравнение максимумов конфигурации VMware vSphere 6.5 и 6.7
• Новые возможности VMware vCenter 6.7 - развертывание vCSA стало опцией по умолчанию
• Как отреагировали вендоры решений резервного копирования виртуальных машин на релиз VMware vSphere 6.7
• Новые возможности VMware vSAN 6.7 в составе vSphere 6.7
• Обновленный VMware Update Manager в vSphere Client 6.7
• Рекомендации по обновлению на VMware vSphere 6.7

Ну а сегодня мы расскажем еще об одной возможности vSphere в плане безопасности - поддержке технологии Virtualization Based Security (VBS) операционных систем Microsoft. Механизм VBS позволяет превратить сервер или рабочую станцию на базе ОС Windows Server 2016 или Windows 10 в защищенные системы, исполняющиеся в рамках гипервизора Windows, при этом некоторые компоненты выносятся за пределы гостевой системы. Например, за рамки ОС выносится система управления хэшированными парами логин/пароль (креденшены), называющаяся Credential Guard.

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

Также аппаратное обеспечение компьютера должно иметь в своем составе модуль TPM 2.0 (Trusted Platform Module), который обеспечивает механику безопасной загрузки (Secure Boot). Ведь если не использовать механизм безопасной загрузки, то атаку можно провести на сам гипервизор, подменив его компоненты, а дальше уже иметь доступ к основной виртуальной машине и остальным компонентам гипервизора, в том числе хранилищу паролей. Таким образом, для полной защиты нужно использовать связку VBS+TPM 2.0 (вторая версия TPM поставляется уже со всем современным оборудованием).

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

• UEFI firmware (не BIOS).
• Опция безопасной загрузки Secure Boot с поддержкой TPM.
• Поддержка технологии Hardware virtualization (опция процессоров Intel VT/AMD-V) и функций IOMMU.

И самое главное - ОС Windows должна быть установлена со всеми этими включенными опциями, иначе потом настраивать VBS будет проблематично.

В случае с гипервизором ESXi для незащищенной виртуальной машины Windows все выглядит вот таким образом:

Чтобы защитить машину с помощью VBS, потребуется использовать вложенную (nested) виртуализацию - ведь гипервизор Windows Hypervisor надо запустить на платформе VMware ESXi. Для этого в настройках виртуальной машины надо выставить опцию Enable для пункта Virtualization Based Security:

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

Выглядеть это будет следующим образом:

Чтобы эта схема работала, нужно выполнить 2 условия:

• Виртуальная машина должна иметь виртуальное железо Virtual Hardware версии 14, которое появилось в vSphere 6.7.
• Гостевую ОС виртуальной машины надо развертывать на базе UEFI и с уже включенной опцией Secure Boot (обратите внимание на эту опцию на панели Boot Options в разделе VM Options (см. скриншот настроек выше).

Ну и последняя деталь - это модуль TPM. Для физических систем этот модуль делается с расчетом на одну систему, имеет небольшой объем памяти защищенного хранилища (измеряется в килобайтах) и работает весьма медленно, так как это serial device.

Поэтому VMware сделала виртуальное устройство - vTPM 2.0, которое в качестве хранилища использует обычный файл .nvram. Физический TPM не рассчитан на то, чтобы поддерживать сотни виртуальных машин на одном сервере (просто не хватит объема хранилища и быстродействия), а виртуальный vTPM отлично справляется с этой задачей. К тому же, виртуальную машину с виртуальным vTPM можно переносить между серверами с помощью vMotion и делать ее резервные копии.

Но, само собой, файл nvram надо хорошо зашифровать, поэтому для виртуальной машины нужно включить VM Encryption. Это обеспечит работоспособность машины в защищенной среде совместно с опцией VBS. При этом диски ВМ шифрованными не будут, что позволит получить доступ к данным на уровне VMDK дисков в случае утери ключей.

Самое интересное, что vTPM 2.0 не требуется как-то отдельно устанавливать и настраивать - он автоматически обнаруживается средствами Windows со стандартными драйверами:

Утилита Device Guard and Credential Guard hardware readiness tool от компании Microsoft определяет этот vTPM, как совместимый, поэтому можете использовать его для виртуальных машин, к которым предъявляются повышенные требования к безопасности.

Как вы знаете, в новой версии решения организации отказоустойчивых кластеров VMware vSAN 6.6 появилась возможность шифрования хранилищ. В целях увеличения эффективности и скорости работы в этой технологии используется концепция "encryption at rest". Сначала данные в незашифрованном виде идут по сети (в целях ускорения и работы сжатия), затем они в зашифрованном виде падают в кэш. После чего, перед тем, как отправиться на постоянное хранение (destaging), они будут расшифрованы, дедуплицированы/сжаты и снова зашифрованы уже на целевом устройстве.

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

Для работы шифрования vSAN нужно, чтобы в кластере была версия on-disk format 5 или выше, при этом пятая версия появилась только в vSAN 6.6. Здесь возможны 3 сценария использования шифрования vSAN:

• Развертывание кластера с нуля на vSAN 6.6.
• Апгрейд кластера с vSAN 5.x./6.x на 6.6 со сменой on-disk format на версию 5.
• Апгрейд кластера с vSAN 5.x./6.x на 6.6 без изменения версии on-disk format.

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

Во втором случае мастер миграции может выполнить процедуру DFC (disk format change), что поменяет on-disk format на версию 5. Далее также можно будет включить шифрование в любой момент, и с этого момента новые данные тома будут шифроваться. При этом не потребуется убирать виртуальные машины с хранилища

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