В век облачных технологий, когда у каждого пользователя есть собственное облако для хранения фотографий, а компании арендуют сервера для облачных вычислений, встает вопрос о конфиденциальности хранимой информации. И если пользователи для защиты хранимых данных могут обойтись доверием к облаку или использованием крипто контейнеров, то у компаний дела обстоят хуже. Так как в облака переносится не только хранилище данных, но и сами вычисления.
Особенно страдает защита виртуальных машин, так как в случае компрометации хоста, не составит труда получить доступ к ВМ. До недавнего времени ни один из гипервизоров будь то VMware, Xen, Hyper-V не предоставляли каких-либо значимых технологий по защите ВМ.
А если злоумышленник получит физический доступ к серверу, то спасти может только шифрование дисков, и то не во всех случаях. Конечно арендуя сервер, часть защитных мер берет на себя дата центр. Но в таком случае необходимо доверять администраторам дата центра.
С релизом Windows Server 2016, в Microsoft решили уделить больше внимания безопасности хоста и виртуальной инфраструктуры. Появилась возможность изолировать ВМ от администратора хоста Hyper-V. А используя виртуальный TPM стало возможным шифрование данных ВМ с помощью bitlocker.
Таким образом используя новые технологии можно размещать виртуальные машины на неподконтрольных серверах или в корпоративных дата центрах, но с повышенным уровнем безопасности, разграничивая роли физического и виртуального доступа.
Используемые технологии
Shielded VM – технология изолирующая виртуальную машину от хоста. Защищает ВМ от случайных или преднамеренных действий администратора хоста и от вредоносного программного обеспечения.
Для работы Shielded VM необходимо наличие сервера Host Guardian Service(HGS), который выдает ключи доступа к ВМ и проверяет здоровье хоста Hyper-V.
HGS поддерживает два вида аттестации:
- TPM-trusted аттестация – проверка проходит на основе идентификатора TPM, последовательности загрузки ОС и политики целостности кода. Таким образом можно быть уверенным, что на хосте работает только одобренный код.
- Admin-trusted аттестация – проверка происходит на основе принадлежности к группе безопасности Active Directory.
Схема работы HGS
При запуске виртуальной машины защищённый хост проходит аттестацию у HGS сервера, который принимает решение о передачи ключей доступа к виртуальной машине.
Admin-trusted аттестацию целесообразно использовать внутри предприятия, когда нужно изолировать доступ к ВМ от администраторов.
TPM-trusted аттестацию лучше использовать при размещении ВМ на арендованном сервере, чтобы обеспечить изоляцию данных и ВМ от работников Дата Центра.
Связь сервера HGS и защищённого хоста осуществляется по http (https) протоколу. HTTPS не требуется, для обеспечения безопасной связи, но, если вы захотите включить HTTPS, вам потребуется дополнительный сертификат. В случае AD аттестации необходимо дополнительно настроить односторонний доменный траст.
Virtual Secure Mode (VSM) – технология работающая на основе виртуализации, которая позволяет изолировать критические для безопасности операции в мини ОС.
На VSM работают две другие технологии:
- Device Guard – проверка данных UEFI прошивки и драйверов режима ядра (контроль целостности кода).
- Credential Guard – изоляция процесса аутентификации пользователей (LSA).
Принцип работы VSM
Основная ОС запускается в виртуальном окружении. А гипервизор выступает в роли хостовой ОС, тем самым ограничивая доступ к оперативной памяти. В итоге вредоносное ПО запущенное на хосте даже с администраторскими правами не сможет получить доступ к памяти VSM. Также такая структура должна защищать от атаки на DMA порты.
Об организации Shielded VM
Заказывая Shielded VM подразумевается, что хост Hyper-V и сервер HGS находятся на стороне дата центра (так организованно в Microsoft Azure). В таком случае создавать экранированную виртуальную машину можно самостоятельно или используя предоставленный шаблон.
Создавая Shielded VM самостоятельно заказчик у себя на ПК разворачивает и настраивает ВМ, а потом шифрует ключом выданным Дата Центром. После переносит ВМ в Дата Центр.
Во втором случае, заказчик создает только PDK файл, защищающий ВМ созданную из шаблона. PDK файл связывает файл шаблона с HGS сервером. Но необходимо убедиться, что в шаблоне нет вредоносного ПО.
Первый способ выглядит более безопасным, так как файл данных ВМ попадает на хост в уже шифрованном виде. В любом случае ключи доступа к ВМ не попадают к администраторам Дата Центра в открытом виде.
Единственным местом подверженным атакам остался HGS сервер. Так как:
- Администратор HGS может понизить требования к политике безопасности.
- Злоумышленник получивший администраторские права может попробовать получить ключи доступа.
- Для работы HGS требуется AD и нет требования к обязательному наличию TPM, следовательно, ключи вероятней всего будут храниться в открытом виде.
Исходя из этого появилась, идея проверить возможность работы Shielded VM в условиях, когда сервер HGS размещается в своей инфраструктуре. Это еще больше обезопасит виртуальные машины. Также такой способ можно использовать если Дата Центр не предоставляет услугу Shielded VM. Минус этого подхода в том, что придётся самостоятельно администрировать эту структуру.
Может возникнуть вопрос о подмене сервера HGS администратором гипервизора — ведь для этого необходимо просто указать новый адрес. Защита от этого реализована достаточно просто, созданная ВМ зашифрована с использованием открытого ключа HGS сервера, поэтому другой HGS сервер не сможет выдать ключи для ее запуска.
Также стоит понимать, что технология Shielded VM шифрует только конфигурационные файлы виртуальной машины. VHDX файл остаётся незашифрованным. Для его шифрования нужно включить vTPM, и зашифровать диск битлокером.
Сочетание новых технологий предоставляет надежную защиту:
- человеческий фактор устранен;
- ключи передаются в зашифрованном виде;
- серверы защищены новыми технологиями, предусматривающими проверку целостности кода;
- белый список разрешенных приложений;
- изоляция ВМ от хоста.
Это все очень хорошо защищает от вредоносного ПО нацеленного на хост Hyper-V и предоставляет доступ к ВМ только владельцу, защищая от действий администраторов или кого-либо получившего администраторские права.
Требования к серверам Hyper-V и HGS
Требования указаны для использования TPM аттестации. AD аттестация менее требовательна, но при этом обеспечивает гораздо меньшую защиту.
HGS:
- Windows Server 2016
Hyper-V:
- Windows Server 2016 Datacenter Edition
- UEFI Secure Boot
- TPM v2
- IOMMU (VT-d)
Как настроить
Для примера будет рассмотрен вариант: вы арендовали и хотите его обезопасить. Будет использована TPM аттестация. Соединение между хостом и HGS будет проходить по http протоколу. Если HGS сервер не имеет белого IP необходимо будет пробросить 80 порт или использовать реверс прокси.
Добавление и настройка HGS роли на сервере
Установка HGS сервера и создание домена
Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart
HGS для работы необходим домен. Его можно подключить к уже существующему домену, но рекомендуется создание отдельного домена для повышения безопасности. Перед выполнением следующей команды необходимо убедиться, что компьютер не подключен к домену.
$adminPassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
Install-HgsServer -HgsDomainName 'relecloud.com' -SafeModeAdministratorPassword $adminPassword -Restart
Создание самоподписаных сертификатов
Для теста были созданы самоподписанные сертификаты, но для реальной среды лучше использовать PKI.
$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
$signingCert = New-SelfSignedCertificate -DnsName "signing.relecloud.com"
Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:signingCert.pfx'
$encryptionCert = New-SelfSignedCertificate -DnsName "encryption.relecloud.com"
Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:encryptionCert.pfx'
Инициализация HGS сервера
Указываем сертификаты шифрования и подписи. Выбираем метод аттестации.
$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
Initialize-HgsServer -HgsServiceName '<HgsServiceName>' -SigningCertificatePath 'C:signingCert.pfx' -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath 'C:encryptionCert.pfx' -EncryptionCertificatePassword $certificatePassword [-TrustActiveDirectory | -TrustTPM]
Добавление охраняемого хоста Hyper-V
Получаем идентификатор TPM
Данную процедуру необходимо выполнить для каждого защищаемого хоста.
(Get-PlatformIdentifier -Name '<HostName>').InnerXml | Out-file <Path><HostName>.xml -Encoding UTF8
Добавляем полученный файл на сервер HGS
Add-HgsAttestationTpmHost -Path <Path><Filename>.xml -Name <HostName> -Force
Создаем и применяем Code Integrity Policy
При создании политики происходит сканирование всех установленных программ и добавление их в белый список. Перед созданием политики необходимо убедится, что в системе:
- Отсутствуют вирусы и вредоносное ПО
- Установлено необходимое для работы ПО и оно является благонадежным
Рекомендуется сначала проверить работу политики в режиме аудита. В таком случае исполняемый файл, запрещенный политикой будет отображен в логе.
Сканирование займет некоторое время.
New-CIPolicy -Level FilePublisher -Fallback Hash -FilePath 'C:tempHW1CodeIntegrity.xml' -UserPEs
ConvertFrom-CIPolicy -XmlFilePath 'C:tempHW1CodeIntegrity.xml' -BinaryFilePath 'C:tempHW1CodeIntegrity.p7b'
Файл .p7b необходимо переименовать в SIPolicy.p7b и скопировать в папку C:WindowsSystem32CodeIntegritySIPolicy.p7b
Перезагружаем компьютер и проверяем работу системы под планируемой типичной нагрузкой. После успешной проверки работы системы отключаем режим аудита
Set-RuleOption -FilePath 'C:tempHW1CodeIntegrity.xml' -Option 3 -Delete
ConvertFrom-CIPolicy -XmlFilePath 'C:tempHW1CodeIntegrity.xml' -BinaryFilePath 'C:tempHW1CodeIntegrity_enforced.p7b'
Copy-Item -Path '<Path to HW1CodeIntegrity_enforced.p7b>' -Destination 'C:WindowsSystem32CodeIntegritySIPolicy.p7b'
Restart-Computer
Если защищаться будет несколько идентичных хостов, политику можно создать только один раз.
Рекомендуется оставить исходный XML файл, чтобы в случае необходимости изменения политики не проводить повторное сканирование.
При включенной политике необходимо быть осторожным с обновлением или добавление драйверов режима ядра, так как это может предотвратить загрузку системы.
Регистрируем политику на HGS сервере
Add-HgsAttestationCIPolicy -Path <Path> -Name '<PolicyName>'
Создание TPM baseline политики
Эта политика основывается на PCR регистрах (Platform Configuration Registers), находящихся в модуле TPM. В них хранятся целостности метрик системы, начиная с загрузки BIOS до завершения работы системы. Если порядок загрузки будет изменен, например, руткитом, это отобразиться в регистрах PCR.
Политика создается для класса одинаковых аппаратных хостов. Перед ее созданием необходимо иметь установленный Hyper-V.
Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart
Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'
Для данной команды необходимо включить Secure Boot, IOMMU (VT-d), Virtualization Based Security.
Можно использовать флаг -SkipValidation который позволить выполниться команде, но он не исправит ошибки.
Добавляем TCGlog файл на HGS сервере
Add-HgsAttestationTpmPolicy -Path <Filename>.tcglog -Name '<PolicyName>'
Проверяем статус HGS сервера
На этом моменте настройка HGS сервера заканчивается. Для проверки выполненной работы проведем диагностику.
Get-HgsTrace -RunDiagnostics
Подключаем хост Hyper-V к HGS серверу
Для подключения защищаемого хоста к серверу HGS достаточно указать URL адрес сервера.
Set-HgsClientConfiguration -AttestationServerUrl 'http://<FQDN>/Attestation' -KeyProtectionServerUrl 'http://<FQDN>/KeyProtection'
При правильной настройке должно быть:
- IsHostGuarded: true
- AttestationStatus: passed
Если что-то настроено не верно в AttestationStatus будет указана причина.
Создание экранированной виртуальной машины
Получаем файл описания HGS сервера, который понадобиться для привязки ВМ к серверу.
Invoke-WebRequest http://<"HGSServer">FQDN>/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:HGSGuardian.xml
Создавать ВМ нужно на отдельной машине под управлением Windows Server 2016, не настроенной на использование HGS.
Создаем новую ВМ второго поколения, устанавливаем на нее ОС, настраиваем RDP и проверяем его работоспособность, шифруем битлокером.
Экранирование ВМ
Задаем название ВМ
$VMName = 'SVM'
Выключаем ВМ
Stop-VM –VMName $VMName
Создаем сертификат владельца
$Owner = New-HgsGuardian –Name 'Owner' –GenerateCertificates
Импортируем сертификат сервера
$Guardian = Import-HgsGuardian -Path 'C:HGSGuardian.xml' -Name 'TestFabric' –AllowUntrustedRoot
Создаем Key Protector
$KP = New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot
Включаем экранирование
Set-VMKeyProtector –VMName $VMName –KeyProtector $KP.RawData
Set-VMSecurityPolicy -VMName $VMName -Shielded $true
Включаем vTPM в виртуальной машине
Enable-VMTPM -VMName $VMName
После настройки и включения защиты в ВМ ее необходимо переместить на охраняемый хост. Для этого экспортируем машину, переносим полученные файлы на хост, и импортируем ее в консоль Hyper-V.
На этом этапе настройка завершена, ВМ экранирована.
Проверяем работу Shielded VM
При попытке подключится к ВМ через консоль Hyper-V увидим сообщение:
Так же в настройках ВМ увидим предупреждение о невозможности менять настройки защиты:
Раздел виртуальной машины защищен BitLocker-ом:
Таким образом была произведена настройка Shielded VM, которая обеспечивает более высокий уровень защиты виртуальных машин. Если у вас остались вопросы, добро пожаловать в комментарии.
Автор: MazayZaycev
