Защита виртуальных машин, размещенных в дата центре


    В век облачных технологий, когда у каждого пользователя есть собственное облако для хранения фотографий, а компании арендуют сервера для облачных вычислений, встает вопрос о конфиденциальности хранимой информации. И если пользователи для защиты хранимых данных могут обойтись доверием к облаку или использованием крипто контейнеров, то у компаний дела обстоят хуже. Так как в облака переносится не только хранилище данных, но и сами вычисления.
    Особенно страдает защита виртуальных машин, так как в случае компрометации хоста, не составит труда получить доступ к ВМ. До недавнего времени ни один из гипервизоров будь то VMware, Xen, Hyper-V не предоставляли каких-либо значимых технологий по защите ВМ.

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

    С релизом Windows Server 2016, в Microsoft решили уделить больше внимания безопасности хоста и виртуальной инфраструктуры. Появилась возможность изолировать ВМ от администратора хоста Hyper-V. А используя виртуальный TPM стало возможным шифрование данных ВМ с помощью bitlocker.

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

    Используемые технологии


    Shielded VM – технология изолирующая виртуальную машину от хоста. Защищает ВМ от случайных или преднамеренных действий администратора хоста и от вредоносного программного обеспечения.
    Для работы Shielded VM необходимо наличие сервера Host Guardian Service(HGS), который выдает ключи доступа к ВМ и проверяет здоровье хоста Hyper-V.

    HGS поддерживает два вида аттестации:

    1. TPM-trusted аттестация – проверка проходит на основе идентификатора TPM, последовательности загрузки ОС и политики целостности кода. Таким образом можно быть уверенным, что на хосте работает только одобренный код.
    2. Admin-trusted аттестация – проверка происходит на основе принадлежности к группе безопасности Active Directory.

    Схема работы HGS

    При запуске виртуальной машины защищённый хост проходит аттестацию у HGS сервера, который принимает решение о передачи ключей доступа к виртуальной машине.

    Admin-trusted аттестацию целесообразно использовать внутри предприятия, когда нужно изолировать доступ к ВМ от администраторов.

    TPM-trusted аттестацию лучше использовать при размещении ВМ на арендованном сервере, чтобы обеспечить изоляцию данных и ВМ от работников Дата Центра.

    Связь сервера HGS и защищённого хоста осуществляется по http (https) протоколу. HTTPS не требуется, для обеспечения безопасной связи, но, если вы захотите включить HTTPS, вам потребуется дополнительный сертификат. В случае AD аттестации необходимо дополнительно настроить односторонний доменный траст.

    Virtual Secure Mode (VSM) – технология работающая на основе виртуализации, которая позволяет изолировать критические для безопасности операции в мини ОС.

    На VSM работают две другие технологии:

    1. Device Guard – проверка данных UEFI прошивки и драйверов режима ядра (контроль целостности кода).
    2. 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:\temp\HW1CodeIntegrity.xml' -UserPEs
    
    ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'



    Файл .p7b необходимо переименовать в SIPolicy.p7b и скопировать в папку C:\Windows\System32\CodeIntegrity\SIPolicy.p7b

    Перезагружаем компьютер и проверяем работу системы под планируемой типичной нагрузкой. После успешной проверки работы системы отключаем режим аудита

    Set-RuleOption -FilePath 'C:\temp\HW1CodeIntegrity.xml' -Option 3 -Delete
    
    ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'
    
    Copy-Item -Path '<Path to HW1CodeIntegrity\_enforced.p7b>' -Destination 'C:\Windows\System32\CodeIntegrity\SIPolicy.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, которая обеспечивает более высокий уровень защиты виртуальных машин. Если у вас остались вопросы, добро пожаловать в комментарии.

    Больше статей на Servilon
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 22

      +1
      Что произойдет, если недоступен HGS сервер?
        0
        Если это происходит при попытке запуска экранированной ВМ, она не запуститься, так как не кому будет выдать ключи.
          0
          А с кластерами работает? будет ли проходить миграция виртуалок между хостами?
            0
            Работает, все хосты кластера должны быть аттестованы HGS сервером. Миграция работать будет, при этом трафик будет шифроваться.
        • UFO just landed and posted this here
            +2
            VSM не позволит это сделать, так как хостовая ОС сама запускается в виртуальном окружении.
              +1
              Что мешает сделать снапшот виртуальной хостовой ОС и ковыряться во всем что под ней запущено?
            +1
            пару дней назад на хабре было большое обсуждение как быстро уничтожить SSD может правильный метод чем шифрование т.к. при физическом доступе к компьютеру шифрованный диск подвержен атаке Cold boot attack https://ru.wikipedia.org/wiki/Cold_boot_attack

              –2
              возможность шифрования виртуалок битлокером нормально работает и в 2012r2,
              • UFO just landed and posted this here
                • UFO just landed and posted this here
                  • UFO just landed and posted this here
                      +2
                      Не получится эксплуатировать этe уязвимость так как потребуется перезагрузка хоста или запуск приложения, чему будет препятствовать политика HGS. В случае ее нарушения ВМ не запуститься, так как не получит сеансовый ключ, который выдает HGS
                      • UFO just landed and posted this here
                        • UFO just landed and posted this here
                          • UFO just landed and posted this here
                              0
                              а если сервер core режиме без установленного .Net и JVM?
                              • UFO just landed and posted this here
                                • UFO just landed and posted this here
                                  0
                                  Все это слишком сложно. Надо:
                                  1. Найти хостинг, где стоят машины.
                                  2. Подкупить сотрудника хостера или внедрить туда своего.
                                  3. Взломать хостовую операционку (не сложно).
                                  4. Попытаться поставить на работающий гипервизор программы для сбора дампов, так что бы клиент этого не заметил.
                                  5. В случае, если эти уязвимости работают и не пропаченны 2 дня назад, скопировать дамп памяти.
                                  6. Расшифровать дамп памяти, получить ключ.
                                  7. Еще раз зайти на хост остановит гипервизор и взять VHD.
                              0
                              на выделенном сервере (например хетцнер) такое можно реализовать?
                                +1
                                ДА, если сервер поддерживает TPM. Проверьте:
                                PS C:\> Get-Tpm
                                TpmPresent : True

                                И разместите HGS на другом хосте, лучше в альтернативном датацентре, например, в небольшая ВМ в Azure

                              Only users with full accounts can post comments. Log in, please.