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

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

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

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

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

  2. Базовый план доверенного платформенного модуля (измерения загрузки)

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

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

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

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

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

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

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

Запись идентификатора доверенного платформенного модуля (идентификатор платформы или EKpub) для каждого узла

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

      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.

Захват базового плана доверенного платформенного модуля для каждого уникального класса оборудования

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

  1. Убедитесь в том, что на эталонном узле установлена роль Hyper-v и компонент поддержки 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>'

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

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