Поделиться через

Авторизовать защищенные хосты посредством аттестации на основе TPM

В режиме TPM используется идентификатор TPM (также называемый идентификатором платформы или ключом подтверждения [EKpub]), чтобы определить, является ли данный узел авторизованным как "защищенный". В этом режиме аттестации используются Безопасная загрузка и измерения целостности кода, чтобы гарантировать, что данный узел Hyper-V находится в работоспособном состоянии и выполняет только доверенный код. Чтобы оценка понимала, что является здоровым, а что нет, необходимо зафиксировать следующие артефакты:

  1. Идентификатор TPM (EKpub)

    • Эта информация уникальна для каждого узла Hyper-V

  2. Базовый уровень TPM (показатели загрузки)

    • Это применимо ко всем узлам Hyper-V, работающим в одном классе оборудования.

  3. Политика целостности кода (список разрешенных двоичных файлов)

    • Это применимо ко всем узлам Hyper-V, которые используют общее оборудование и программное обеспечение.

Рекомендуется записать базовую политику и политику CI из "эталонного узла", который является представителем каждого уникального класса конфигурации оборудования Hyper-V в центре обработки данных. Начиная с Windows Server версии 1709 примеры политик CI включены в C:\Windows\schemas\CodeIntegrity\ExamplePolicies.

Политики аттестации с версиями

Windows Server 2019 представляет новый метод аттестации, называемый аттестацией v2, где сертификат доверенного платформенного модуля (TPM) должен присутствовать для добавления EKPub в HGS. Метод аттестации версии 1, используемый в Windows Server 2016, позволял обойти эту проверку безопасности с помощью флага -Force при запуске Add-HgsAttestationTpmHost или других командлетов аттестации доверенного платформенного модуля для захвата артефактов. Начиная с Windows Server 2019, аттестация версии 2 используется по умолчанию и необходимо указать флаг -PolicyVersion версии 1 при запуске Add-HgsAttestationTpmHost, если необходимо зарегистрировать TPM без сертификата. Флаг -Force не работает с аттестацией версии 2.0.

Хост может удостоверить только если все артефакты (EKPub + базовый уровень TPM + политика CI) используют одинаковую версию аттестации. Аттестация версии 2 выполняется сначала, и если это не удается, используется аттестация версии 1. Это означает, что если необходимо зарегистрировать идентификатор доверенного платформенного модуля с помощью аттестации версии 1, необходимо также указать флаг -PolicyVersion версии 1 для использования аттестации версии 1 при записи базового плана доверенного платформенного модуля и создании политики CI. Если базовая конфигурация TPM и политика CI были созданы, используя аттестацию версии 2, а затем вам необходимо добавить защищенный узел без сертификата TPM, необходимо заново создать каждое средство с флагом -PolicyVersion v1.

Получить идентификатор TPM (идентификатор платформы или EKpub) для каждого хоста

  1. В области управления инфраструктурой убедитесь, что TPM на каждом узле готов к использованию, то есть TPM инициализировано, и права собственности получены. Вы можете проверить состояние доверенного платформенного модуля, открыв консоль управления TPM (tpm.msc) или выполнив команду Get-Tpm в окне Windows PowerShell с повышенными привилегиями. Если TPM не находится в состоянии "Готово, необходимо его инициализировать и установить право владения. Это можно сделать в консоли управления TPM или с помощью Initialize-Tpm.

  2. На каждом защищенном узле выполните следующую команду в консоли Windows PowerShell с повышенными привилегиями, чтобы получить свой EKpub. Для <HostName> замените уникальное имя узла на подходящее для идентификации этого узла - это может быть его имя хоста или имя, используемое службой инвентаризации сети (если оно доступно). Для удобства назовите выходной файл с помощью имени узла.

    (Get-PlatformIdentifier -Name '<HostName>').InnerXml | Out-file <Path><HostName>.xml -Encoding UTF8

  3. Повторите предыдущие шаги для каждого узла, который станет защищенным узлом, обязательно присвойте каждому XML-файлу уникальное имя.

  4. Предоставьте результирующий XML-файл администратору HGS.

  5. В домене HGS откройте консоль Windows PowerShell с повышенными привилегиями на сервере HGS и выполните следующую команду. Повторите команду для каждого XML-файла.

    Add-HgsAttestationTpmHost -Path <Path><Filename>.xml -Name <HostName>

    Примечание.

    Если при добавлении идентификатора доверенного платформенного модуля относительно сертификата ключа подтверждения (EKCert) возникает ошибка, убедитесь, что доверенные корневые сертификаты доверенного доверенного платформенного модуля добавлены в узел HGS. Кроме того, некоторые поставщики TPM не используют EKCerts. Вы можете проверить, отсутствует ли EKCert, открыв XML-файл в редакторе, например Блокноте, и проверьте сообщение об ошибке, указывающее, что EKCert не найден. Если это так и вы доверяете, что TPM в вашей машине является аутентичным, вы можете использовать параметр -Force для добавления идентификатора хоста в HGS. В Windows Server 2019 необходимо также использовать -PolicyVersion v1 параметр при использовании -Force. Это создает политику, согласованную с поведением Windows Server 2016, и вам потребуется использовать -PolicyVersion v1 при регистрации политики CI и базовой конфигурации доверенного платформенного модуля.

Создание и применение политики целостности кода

Политика целостности кода помогает обеспечить выполнение только исполняемых файлов, которые вы доверяете запуску на узле. Запуск вредоносных программ и других исполняемых файлов, помимо доверенных исполняемых файлов, не допускается.

Каждый защищённый хост должен применять политику целостности кода для запуска защищённых виртуальных машин в режиме TPM. Вы указываете точные политики целостности кода, которые вы доверяете, добавив их в HGS. Политики целостности кода можно настроить для принудительного применения политики, блокировки любого программного обеспечения, которое не соответствует политике, или просто аудита (регистрировать событие, если программное обеспечение не определено в политике).

Начиная с Windows Server версии 1709, примеры политик целостности кода включены в состав Windows в C:\Windows\schemas\CodeIntegrity\ExamplePolicies. Для Windows Server рекомендуется использовать две политики:

  • AllowMicrosoft: разрешает все файлы, подписанные корпорацией Майкрософт. Эта политика рекомендуется для серверных приложений, таких как SQL или Exchange, или если сервер отслеживается агентами, опубликованными корпорацией Майкрософт.
  • DefaultWindows_Enforced. Разрешает только файлы, включенные в Windows, а не разрешает использование других приложений, выпущенных корпорацией Майкрософт, таких как Office. Эта политика рекомендуется для серверов, которые выполняют только встроенные роли сервера и функции, такие как Hyper-V.

Рекомендуется сначала создать политику CI в режиме аудита (ведения журнала), чтобы определить, чего в ней может не хватать, а затем применить эту политику для рабочих нагрузок в рабочей среде.

Если вы используете командлет New-CIPolicy для создания собственной политики целостности кода, необходимо решить, какие уровни правил следует использовать. Рекомендуется использовать основной уровень издателя с резервным доступом к Хэшу, что позволяет обновлять программное обеспечение с цифровой подписью, не изменяя политику CI. Новое программное обеспечение, написанное тем же издателем, также можно установить на сервере без изменения политики CI. Исполняемые файлы, не подписанные цифровой подписью, будут хэшированы. Обновления этих файлов потребуют создания новой политики CI. Дополнительные сведения о доступных уровнях правил политик целостности кода (CI) см. в разделе "Развертывание политик целостности кода": правила политик и правила файлов, а также в справке по командлетам.

  1. На узле ссылки создайте новую политику целостности кода. Следующие команды создают политику на уровне издателя с переходом на хеш. Затем он преобразует XML-файл в двоичный формат Windows и HGS должны применять и измерять политику CI соответственно.

    New-CIPolicy -Level Publisher -Fallback Hash -FilePath 'C:\temp\HW1CodeIntegrity.xml' -UserPEs

ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'

    Примечание.

    Приведенная выше команда создает политику CI только в режиме аудита. Он не блокирует работу несанкционированных двоичных файлов на узле. В производственной среде следует использовать только обязательные политики.

  2. Сохраните файл политики целостности кода (XML-файл), где его можно легко найти. Позже необходимо изменить этот файл, чтобы применить политику CI или объединить изменения из будущих обновлений, внесенных в систему.

  3. Примените политику CI к эталонному хосту.

    1. Выполните следующую команду, чтобы настроить компьютер для использования политики CI. Вы также можете развернуть политику CI с групповой политикой или System Center Virtual Machine Manager.

      Invoke-CimMethod -Namespace root/Microsoft/Windows/CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{ FilePath = "C:\temp\HW1CodeIntegrity.p7b" }

    2. Перезапустите узел, чтобы применить политику.

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

  5. Измените политику CI на принудительный режим, выполнив следующие команды в обновленном XML-файле политики CI.

    Set-RuleOption -FilePath 'C:\temp\HW1CodeIntegrity.xml' -Option 3 -Delete

ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'

  6. Примените политику CI ко всем узлам (с идентичной конфигурацией оборудования и программного обеспечения) с помощью следующих команд:

    Invoke-CimMethod -Namespace root/Microsoft/Windows/CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{ FilePath = "C:\temp\HW1CodeIntegrity.p7b" }

Restart-Computer

    Примечание.

    Будьте осторожны при применении политик CI к узлам и при обновлении любого программного обеспечения на этих компьютерах. Любые драйверы режима ядра, которые не соответствуют политике CI, могут предотвратить запуск компьютера.

  7. Предоставьте двоичный файл (в этом примере HW1CodeIntegrity_enforced.p7b) администратору HGS.

  8. В домене HGS скопируйте политику целостности кода на сервер HGS и выполните следующую команду.

    Для <PolicyName> укажите имя политики CI, описывающей тип узла, к которому она применяется. Лучшей практикой является присвоить имя в соответствии с маркой и моделью вашего компьютера, а также любой специальной конфигурацией программного обеспечения, работающей на нем. Для <Path> укажите путь и имя файла этой политики целостности кода.

    Add-HgsAttestationCIPolicy -Path <Path> -Name '<PolicyName>'

    Примечание.

    Если вы используете политику целостности подписанного кода, зарегистрируйте неподписаную копию той же политики в HGS. Подпись политики целостности кода используется для управления обновлениями политики, но не измеряется в доверенном платформенном модуле и поэтому не может быть подтверждена с помощью HGS.

Фиксация базиса TPM для каждого уникального класса оборудования

Базовый план доверенного платформенного модуля необходим для каждого уникального класса оборудования в структуре центра обработки данных. Снова используйте "эталонный узел".

  1. Убедитесь в том, что на эталонном узле установлена роль Hyper-V и функция поддержки Host Guardian Hyper-V.

    Предупреждение

    Функция поддержки Hyper-V защиты узла обеспечивает защиту целостности кода на основе виртуализации, которая может быть несовместима с некоторыми устройствами. Мы настоятельно рекомендуем протестировать эту конфигурацию в лаборатории перед включением этой функции. Сбой этого может привести к непредвиденным сбоям вплоть до потери данных или ошибки синего экрана (также называемой ошибкой остановки).

    Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

  2. Чтобы записать базовую политику, выполните следующую команду в консоли Windows PowerShell с повышенными привилегиями.

    Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'

    Примечание.

    Необходимо использовать флаг -SkipValidation если на эталонном узле не включена безопасная загрузка, отсутствует IOMMU, не включена и не запущена безопасность на основе виртуализации или не применена политика целостности кода. Эти проверки предназначены для того, чтобы вы знали о минимальных требованиях к запуску экранированных виртуальных машин на узле. Использование флага -SkipValidation не изменяет выходные данные командлета; он просто подавляет ошибки.

  3. Предоставьте базовый файл TPM (файл TCGlog) администратору HGS.

  4. В домене HGS скопируйте файл TCGlog на сервер HGS и выполните следующую команду. Как правило, вы назовете политику после класса оборудования, который он представляет (например, "Редакция модели производителя").

    Add-HgsAttestationTpmPolicy -Path <Filename>.tcglog -Name '<PolicyName>'

Следующий шаг

Подтверждение аттестации