В блоге 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), понадобится переместить все виртуальные машины с нужного тома, чтобы включить на нем шифрование. Это может вызвать некоторые неудобства, поэтому лучше всего воспользоваться вариантом один или два.