Параметры безопасности виртуальных машин 2-го поколения для Hyper-V
Область применения: Windows Server 2022, Windows Server 2016, Microsoft Hyper-V Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019
С помощью параметров безопасности виртуальной машины в диспетчере Hyper-V можно защитить данные и состояние виртуальной машины. Вы можете защитить виртуальные машины от проверки, кражи и несанкционированных изменений со стороны как вредоносных программ, которые могут выполняться на узле, так и администраторов центра обработки данных. Уровень безопасности, который вы получаете, зависит от используемого оборудования узла, поколения виртуальной машины и от того, настроена ли служба защиты узла, которая разрешает узлам запускать экранированные виртуальные машины.
Служба защиты узла — это новая роль в Windows Server 2016. Она определяет допустимые узлы Hyper-V и позволяет им запускать указанную виртуальную машину. Вы чаще всего настраиваете службу защиты узла для центра обработки данных. Но вы можете создать экранированную виртуальную машину для локального запуска без настройки службы защиты узла. Позже вы сможете распространить экранированную виртуальную машину в структуре защиты узла.
Если вы не настроили службу защиты узла или запускаете ее в локальном режиме на узле Hyper-V, а на узле есть ключ защитника владельца виртуальной машины, можно изменить параметры, описанные в этой статье. Владелец ключа защитника — это организация, которая создает закрытый или открытый ключ и предоставляет к ним общий доступ для всех виртуальных машин, созданных с помощью этого ключа.
Сведения о том, как сделать виртуальные машины более защищенными с помощью службы защиты узла, см. в следующих ресурсах.
Параметр безопасной загрузки в диспетчере Hyper-V
Безопасная загрузка — это функция (доступная для виртуальных машин 2-го поколения), которая помогает предотвратить выполнение посторонних встроенных программ, операционных систем или драйверов единого расширяемого микропрограммного интерфейса (UEFI) (так называемого дополнительного ПЗУ) во время запуска системы. Безопасная загрузка включена по умолчанию. Вы можете использовать безопасную загрузку с виртуальными машинами 2-го поколения, работающими под управлением операционных систем Windows или Linux.
Шаблоны, описанные в следующей таблице, относятся к сертификатам, необходимым для проверки целостности процесса загрузки.
| Название шаблона | Описание |
|---|---|
| Microsoft Windows | Выберите этот шаблон для безопасной загрузки виртуальной машины с операционной системой Windows. |
| Центр сертификации Microsoft UEFI | Выберите этот параметр для безопасной загрузки виртуальной машины для операционной системы с дистрибутивом Linux. |
| Экранированная виртуальная машина с открытым исходным кодом | Этот шаблон используется для безопасной загрузки экранированных виртуальных машин под управлением Linux. |
Дополнительные сведения см. в следующих статьях.
Параметры поддержки шифрования в диспетчере Hyper-V
Чтобы защитить данные и состояние виртуальной машины, выберите следующие параметры поддержки шифрования.
Включение режима изолированного пользователя
Если выбрать Включить доверенный платформенный модуль на узлах Hyper-V, на которых работают более ранние версии Windows, чем юбилейное обновление Windows 10, необходимо включить режим изолированного пользователя. Это не требуется для узлов Hyper-V под управлением Windows Server 2016 или Windows 10 юбилейного обновления или более поздней версии.
Режим изолированного пользователя — это среда выполнения, в которой приложения безопасности размещаются в виртуальном безопасном режиме на узле Hyper-V. Виртуальный безопасный режим используется для защиты состояния микросхемы виртуального доверенного платформенного модуля.
Чтобы включить режим изолированного пользователя на узле Hyper-V, на котором работают более ранние версии Windows 10, сделайте следующее:
Откройте Windows PowerShell от имени администратора.
Выполните следующие команды:
Вы можете перенести виртуальную машину с включенным виртуальным доверенным платформенным модулем на любой узел под управлением Windows Server 2016, Windows 10 сборка 10586 или более поздняя. Но если перенести ее на другой узел, вы не сможете ее запустить. Необходимо обновить предохранитель ключа для этой виртуальной машины, чтобы авторизовать новый узел для запуска виртуальной машины. Дополнительные сведения см. в статье Защищенная структура и экранированные виртуальные машины и System requirements for Hyper-V on Windows Server (Требования к системе для Hyper-V в Windows Server).
Политика безопасности в диспетчере Hyper-V
Для большей безопасности виртуальной машины выберите параметр Включить защиту, чтобы отключить такие функции управления, как подключение к консоли, PowerShell Direct и некоторые компоненты интеграции. Если выбран этот параметр, будут выбраны и применены следующие параметры: Безопасная загрузка, Включить доверенный платформенный модуль и Encrypt State and VM migration traffic (Шифровать трафик миграции данных состояния и виртуальной машины).
Вы можете создать экранированную виртуальную машину для локального запуска без настройки службы защиты узла. Но если перенести ее на другой узел, вы не сможете ее запустить. Необходимо обновить предохранитель ключа для этой виртуальной машины, чтобы авторизовать новый узел для запуска виртуальной машины. Дополнительные сведения см. в статье Защищенная структура и экранированные виртуальные машины.
Дополнительные сведения о безопасности в Windows Server см. в этой статье.
15 принципов безопасности Hyper-V
Безопасность в наши дни – самое главное для IT-компаний. Прежде, чем внедрить новую технологию в производственную среду, IT-администраторы должны проработать вопрос безопасности и свести к минимуму угрозу атаки. В статье мы озвучим 15 ключевых пунктов, соблюдая которые Вы будете уверены, что Ваша виртуальная среда в безопасности и работает, как надо.
Установка роли Hyper-V в варианте установки Server Core
В целях безопасности рекомендуется всегда устанавливать роль Hyper-V в варианте установки Server Core вместо использования полной версии операционной системы Windows. Отсутствие графического интерфейса в Server Core уменьшает возможности для атаки. Клиентские файлы управления Hyper-V не устанавливаются, а это уменьшает возможности для файловых атак. Использование Server Core на физическом компьютере с Hyper-V предоставляет три основных преимущества в безопасности:
Полномочия (данные) для входа служб Hyper-V
Никогда не меняйте настройки безопасности по умолчанию для сервисов Hyper-V. Оповещения могут привести Hyper-V к прекращению работы. Изменение используемого контекста безопасности Hyper-V может дать возможность кому угодно контролировать весь гипервизор.
Блокировка ненужных портов
Нет необходимости настраивать какие-либо еще роли/службы на сервере Hyper-V. Установленные серверные приложения будут слушать статические порты. Всегда просматривайте порты, которые слушаются на сервере, и блокируйте их в случае необходимости.
Настройки Hyper-V по умолчанию
Всегда проверяйте настройки Hyper-V по умолчанию перед тем, как запустите его в рабочую среду. По умолчанию файлы виртуальных серверов будут храниться локально. Рекомендуется всегда менять место хранения на более защищенный диск.
Использование шифрования BitLocker в родительском разделе.
Т.к. BitLocker встроен в ОС Windows, рекомендуется запустить его для тех томов, где хранятся файлы Hyper-V и виртуальных серверов. Физическая защита на базе BitLocker присутствует даже в выключенном сервере.
Данные будут защищены, даже если диск украдут. BitLocker защищает данные и в случае использования атакующим разных ОС, а также при применении хакерского ПО для получения доступа к содержимому диска.
Примечание: Используйте BitLocker только для Hyper-V. Не используйте его на виртуальных серверах, т.к. на них BitLocker не поддерживается.
Не используйте встроенные аккаунты администратора
Не используйте локальный аккаунт администратора по умолчанию для управления виртуальными машинами и системой Hyper-V. Вместо этого создайте новую управляющую группу Active Directory и с помощью Менеджера авторизации делегируйте ей задачи по управлению виртуальными машинами.
Всегда ставьте антивирус на сервер
Установив антивирус, вы всегда будете уверены, что вредоносные действия будут перехвачены на уровне сервера Hyper-V. Также позаботьтесь о своевременном обновлении антивируса.
Всегда устанавливайте самые последние обновления компонентов интеграции
Компоненты для интеграции обеспечивают работу VMBUS и VSP/VSC, которые обеспечивают безопасное взаимодействие виртуальных машин и гипервизора. Компоненты эти обновляются с каждым новым релизом Hyper-V. Вам необходимо своевременно загружать последние версии компонентов с сайта Microsoft и обновлять все виртуальные машины.
Не устанавливайте никаких приложений в родительском разделе Hyper-V
Сервер Hyper-V должен использоваться только под задачи Hyper-V. Ненужные приложения на сервере могут вмешаться в процессы Hyper-V, что может быть небезопасно.
Защищайте файлы Hyper-V и файлы виртуальных машин
Файлы Hyper-V и виртуальных серверов должны быть под защитой. Поскольку эти данные хранятся в VHD файлах, любой, кто имеет доступ к VHD файлам, может их смонтировать и получить доступ и к содержимому.
Отключите машины, которые не используются
Не используйте машины, которые не несут никаких существенных функций. Если вы запустите какие-либо из серверов, убедитесь, что они отсоединены от коммутаторов Hyper-V, к которым подсоединены другие серверы. Любой, у кого есть доступ к неиспользуемым серверам, может вмешаться в производственную среду через сеть или каким-либо другим способом.
Всегда используйте Firewall и блокируйте ненужные функции
Как только Вы запускаете Hyper-V на сервере Windows, управляющий сервер дает брандмауэру права, необходимые для коммуникации Hyper-V. Убедитесь, что никаких лишних прав брандмауэру не дано.
Обеспечение снимков и контрольных точек
Снимок является образом виртуальной машины на определённый момент времени, к которому Вы позже можете вернуть машину. Рекомендуется хранить снимки и контрольные точки, которые Вы создаете, вместе со связанными с ними VHD-файлами в безопасном месте.
Усиливайте ОС виртуальных серверов
Используйте один и тот же шаблон усиленной ОС для всех виртуальных машин для обеспечения одинакового уровня безопасности. Также убедитесь, что работает антивирус и отключены ненужные компоненты.
Параметры безопасности виртуальных машин 1-го поколения
Область применения: Windows Server 2022, Windows Server 2016, Microsoft Hyper-V Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019
С помощью параметров безопасности виртуальной машины 1-го поколения в диспетчере Hyper-V можно защитить данные и состояние виртуальной машины.
Параметры поддержки шифрования в диспетчере Hyper-V
Чтобы защитить данные и состояние виртуальной машины, выберите следующие параметры поддержки шифрования.
Чтобы включить этот параметр, следует добавить для виртуальной машины диск хранилища ключей.
Диск для хранилища ключей в диспетчере Hyper-V
Диск хранилища ключей предоставляет виртуальной машине небольшой диск для хранения ключа BitLocker. Это позволяет виртуальной машине шифровать диск операционной системы, не применяя виртуальной микросхемы доверенного платформенного модуля (TPM). Содержимое диска хранилища ключей шифруется с помощью предохранителя ключа. Предохранитель ключа предоставляет узлу Hyper-V право запуска виртуальной машины. Содержимое диска хранилища ключей и соответствующий предохранитель ключа хранятся как часть состояния среды выполнения для виртуальной машины.
Чтобы расшифровать содержимое диска хранилища ключей и запустить виртуальную машину, узел Hyper-V должен соответствовать любому из следующих условий:
Дополнительные сведения о защищенных структурах см. в разделе вводных данных об экранированных виртуальных машинах этой статьи.
Диск хранилища ключей можно добавить в пустой слот на любом из контроллеров IDE виртуальной машины. Для этого выберите действие Добавить диск хранилища ключей для первого свободного слота контроллера IDE на нужной виртуальной машине.
Защищенные виртуальные машины в Windows Server 2016
Давайте посмотрим, почему стоит обратить на нее внимание, рассмотрев какие сценарии атак на виртуальные машины возможны в современном частном облаке или в облаке сервис-провайдера.
Предположим, я администратор виртуализованной среды и, разумеется, у меня есть доступ ко всем виртуальным машинам, на которых могут быть развернуты контроллеры домена, почтовые сервисы, базы данных и т. д. Я не являюсь администратором всего домена, но у меня есть административный доступ к гипервизорам на уровне хоста.
Я делаю снимок виртуальной машины с контроллером домена, а затем копирую ее в другое место – на общий файловый сервер или сразу на свой личный флеш-накопитель. И самое приятное, что никто этого не почувствует: сервисы внутри ВМ не останавливаются ни на секунду, а я получил копию контроллера домена. После этого я копирую файлы ВМ на свой личный ноутбук, монтирую VHDX, захожу в папку Windows\NTDS внутри виртуального диска и копирую находящийся там файл NTDS.dat (база данных Active Directory). После этого с помощью любой существующей утилиты для извлечения паролей из NTDS.dat я получаю пароли пользователей в домене в виде обычного текста. Для этого в зависимости от длины и сложности пароля могут потребоваться дни, недели или даже месяцы, но я ведь никуда не тороплюсь, лишь бы успеть до даты следующей смены пароля пользователя в домене (по умолчанию это 42 дня).
Предположим, что я узнал пароль администратора SQL Server, где работает HR-система. Я захожу на виртуальную машину с SQL Server и оставляю в секции реестра HKLM\Software\Microsoft\Windows\CurrentVersion\Run ссылку на запуск атакующего скрипта, который запустится в тот момент, когда DBA залогинится на сервер. Что этот скрипт сделает – решать мне.
Возможны и другие сценарии. Например, администратор сервис-провайдера с целью заработка получает доступ к серверу, где работает база данных CRM-системы крупного заказчика, и выгружает данные по всем клиентам в Excel, после чего продает эти данные конкурентам.
Таким образом, если у меня имеются права администратора виртуализованной среды, то я могу получить доступ к содержимому всех виртуальных машин на управляемых хостах. Я могу легко сбросить пароль локального администратора или root, абсолютно незаметно для владельца сервиса внутри этой ВМ, ведь у нас есть консольный доступ.
Другим возможным сценарием получения доступа к содержимому виртуальной машины является также внешне незаметное подключение отладчика к рабочему процессу VMWP запущенной виртуальной машины, после чего я получаю дамп содержимого оперативной памяти и ищу интересные вещи внутри него.
Рассмотрим также очень распространенный способ защиты от атак подобного рода – шифрование виртуальных дисков. Многие заказчики думают, что это хорошая мера защиты от подобных угроз. Но если использовать шифрование на уровне хоста, то тот же администратор виртуализованной среды при желании сможет отключить шифрование на время и расшифровать диск. Если использовать шифрование диска изнутри ВМ, то это может быть неудобно (чаще всего в подобных системах требуется вводить специальный код при запуске ВМ). Плюс это не защищает от того, что администратор гипервизора не скопирует ВМ на свой флеш-накопитель и не будет атаковать копию виртуальной машины по сети, запустив ее на своем личном компьютере. По очень быстрой виртуальной сети, за пределами корпоративных брандмауэров и систем мониторинга ИБ.
Данный способ атак актуален для всех современных гипервизоров – будь то Hyper-V 2012 R2 или система виртуализации последнего поколения от других лидеров рынка. Но в Windows Server 2016 данная проблема была решена на корню.
Windows Server 2016 и обновленный Hyper-V 2016 предоставляют возможности защиты ваших виртуальных машин от просмотра содержимого, кражи, вредоносного вмешательства (в том числе со стороны системного администратора) в процессе работы виртуальной машины или в остановленном состоянии. Данная технология получила название Shielded VM и с ее помощью вы можете защищать виртуальные машины, размещенные как в фабрике, которой вы не в полной мере доверяете (например, у сервис-провайдера), так и внутри вашего ЦОД (когда одни сотрудники управляют частным облаком, а другие отвечают за сервисы, работающие внутри ВМ).Давайте сравним использование защищенной виртуальной машины Shielded VM с обычной виртуальной машиной Hyper-V и физической машиной в ЦОД (красным показан потенциально опасный доступ):
В рамках технологии существует два типа защиты виртуальных машин – режим Shielded и режим Encryption Supported. В обоих режимах в виртуальной машине зашифровано не только содержимое, но и трафик Live Migration, причем миграция такой машины будет происходить только на доверенный хост, а VHDX будет зашифрован при помощи vTPM (virtual Trusted Platform Module) средствами BitLocker в гостевой ОС. Кроме того, в режиме Shielded реализована дополнительная защита в виде отключения некоторых виртуальных устройств внутри самой ВМ, что не позволит подключиться ни к консоли виртуальной машины, ни тем более получить содержимое ее дампа памяти. Режим Encryption Supported подходит для сценариев, когда владелец приложения доверяет администраторам среды виртуализации, а также для сценариев, когда требуется соответствие требованиям некоторых регуляторов. В остальных случаях мы рекомендуем использовать наиболее защищенный режим Shielded.
Технология Shielded VMs не усложняет администрирование облака – защищенные виртуальные машины все так же можно «бэкапить», перемещать на другие хосты с помощью Live Migration или даже мигрировать на другие площадки с помощью Hyper-V Replica (при условии, что хосты входят в доверенную среду и управляются той же службой Host Guardian Service).
Компоненты System Center 2016 поддерживают управление компонентами механизма Shielded VMs, а Windows Azure Pack теперь умеет создавать защищенные виртуальные машины наряду с обычными.
Давайте посмотрим, как технология Shielded VMs защищает от типовых атак со стороны администратора среды виртуализации в современном облаке:
Способ атаки
Технология защиты
Сброс пароля администратора внутри ВМ
Отключение консольного доступа и PowerShell Direct, а также потенциально опасных запросов WMI путем удаления виртуальных устройств внутри ВМ.
Получение доступа к файловой системе ВМ путем монтирования виртуального диска (в том числе инъекция скриптов, выполняемых при загрузке ВМ)
Шифрование виртуальных дисков и файлов Checkpoints с помощью BitLocker. Ключи шифрования надежно защищены в виртуальном TPM чипе
Копирование ВМ за пределы доверенной среды с целью взлома по сети (в том числе использование снэпшотов и восстановление из бэкапа)
Служба Host Guardian Service передаст ВМ ключи для расшифровки загрузчика только после того, как убедится, что ВМ запускается на доверенном хосте.
Изменение загрузчика ВМ
Механизм Secure Boot блокирует дальнейший запуск ВМ при обнаружении изменений в загрузчике
Перехват данных путем анализа дампа ВМ
Блокировка подключения отладчика к VMWP. Шифрование файла Saved State, а также Runtime State.
Перехват сетевого трафика, содержащего данные оперативной памяти ВМ, при живой миграции на другой хост
Шифрование трафика Live Migration.
Перехват данных при миграции ВМ в резервный сайт
Шифрование трафика и хранящихся данных механизма Hyper-V Replica
Инъекция вредоносных скриптов внутрь шаблона ВМ
Сверка подписи диска с Volume Signature Catalog при создании Shielded VM
Перехват пароля администратора, вводимого при создании ВМ из шаблона
Пароль администратора берется из зашифрованного PDK-файла и не вводится при создании ВМ.
Какие сценарии использования данного типа виртуальных машин могут быть?
— Хостинг-провайдеры, предоставляющие виртуальные машины в аренду: вы хотите защитить данные ваших заказчиков от кражи, обеспечив дополнительный барьер от административного персонала
— Компании, планирующие миграцию в облако: вы хотите разместить рабочую нагрузку в облаке и вам необходимо гарантировать сохранность данных внутри ваших ВМ и требования регулирующих органов (финансовые регуляторы, персональные данные и т. п.)
— Собственное частное облако: вы хотите отделить задачи администрирования рабочих нагрузок от задач по администрированию фабрики Hyper-V.
Дополнительно рассмотрим сценарий использования механизма Shielded VMs для защиты информационной системы в связке с технологией Always Encrypted, которая появилась в SQL Server 2016. Напомню, эта технология позволяет хранить конфиденциальные данные (номера кредитных карт, персональные данные и т. д.) в столбцах таблицы базы в зашифрованном виде. Расшифровка таких данных происходит на стороне клиентского приложения, которое обращается к доверенному хранилищу ключей, недоступному администратору базы данных. Таким образом Always Encrypted позволяет разделить пользователей базы на тех, кто владеет данными и имеет право их просматривать, и тех, кто выполняет задачи по администрированию и не должен иметь доступа к таким данным. При этом организация может спокойно хранить свои базы в облаке, использовать аутсорсеров в качестве администраторов базы данных или повысить требования безопасности внутри компании для собственных сотрудников.
Always Encrypted выполняет шифрование прозрачно для приложения: на уровне клиентского приложения устанавливается драйвер, который шифрует данные в базе с помощью ключей, хранящихся в клиентском приложении. Шифрование осуществляется при выполнении операций INSERT или UPDATE перед их передачей в БД. Аналогичным образом выполняется операция SELECT, при которой данные из соответствующих столбцов прозрачно дешифруются драйвером. При этом структура таблицы никак не меняется, что позволяет сохранить семантику приложения, использующего SQL Server. Если приложение отправляет параметризованный запрос, драйвер получает информацию от Database Engine, какие параметры относятся к зашифрованным столбцам и соответственно должны быть зашифрованы или расшифрованы. Для параноиков может быть важно, что при этом можно реализовать и свой собственный поставщик хранилища ключей столбцов.
Сценарии использования технологии Always Encrypted могут быть такими же как при использовании Shielded VM: хостинг-провайдеры; обеспечение требований законодательства по защите данных, размещенных в облаке; разграничение доступа к конфиденциальным данным внутри ИТ-подразделения компании между администратором сервера баз данных и администратором приложения.
Технологии Shielded VMs и Always Encrypted отлично работают в связке. Например, я являюсь владельцем сервиса, который состоит из Front-end части (веб-приложение) и Back-end (база данных SQL Server). Моя база работает в большой ферме SQL Server 2016 Enterprise, которой управляют администраторы СУБД. Я хочу обезопасить данные своего приложения от кражи и использую технологию SQL Server 2016 Always Encrypted для шифрования данных в базе. Но при этом ключи для шифрования находятся внутри виртуальной машины, где работает Front-end, и их тоже нужно обезопасить от кражи. Для этого я перевожу виртуальную машину с Front-end в режим Shielded, и теперь доступ внутрь нее имею только я. Получилась защита приложения с обоих фронтов.
Совместное использование этих двух технологий гарантирует беспрецедентный уровень безопасности, вместе с тем позволяет найти наиболее подходящий сценарий размещения ваших данных, не опасаясь за их сохранность.
Если вы хотите узнать больше про то, как работает технология Shielded VMs в Windows Server 2016, мы рекомендуем вам прочитать официальную документацию и посмотреть презентацию с конференции Microsoft Ignite.
Соответственно, если вы хотите узнать больше про то, как работает технология Always Encrypted в SQL Server 2016, то вы можете прочитать официальную документацию по данной технологии.