Autoriser des hôtes protégés à l’aide d’une attestation TPM

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Le mode TPM utilise un identificateur TPM (également appelé identificateur de plateforme ou clé d’approbation [EKpub]) pour commencer à déterminer si un hôte particulier est autorisé comme « protégé ». Ce mode d’attestation utilise le démarrage sécurisé et les mesures d’intégrité du code pour garantir qu’un hôte Hyper-V donné est dans un état intègre et exécute uniquement du code approuvé. Pour que l’attestation comprenne ce qui est intègre et non intègre, vous devez capturer les artefacts suivants :

  1. Identificateur TPM (EKpub)

    • Ces informations sont propres à chaque hôte Hyper-V

  2. Base de référence de TPM (mesures de démarrage)

    • Cela s’applique à tous les hôtes Hyper-V qui s’exécutent sur la même classe de matériel

  3. Stratégie d’intégrité du code (liste d’autorisation des fichiers binaires autorisés)

    • Cela s’applique à tous les hôtes Hyper-V qui partagent du matériel et des logiciels communs

Nous vous recommandons de capturer la ligne de base et la stratégie CI à partir d’un « hôte de référence » représentatif de chaque classe unique de configuration matérielle Hyper-V au sein de votre centre de données. À compter de Windows Server version 1709, les exemples de stratégies CI sont inclus dans C:\Windows\schemas\CodeIntegrity\ExamplePolicies.

Stratégies d’attestation avec version

Windows Server 2019 introduit une nouvelle méthode d’attestation, appelée attestation v2, dans laquelle un certificat TPM doit être présent pour ajouter l’EKPub à SGH. La méthode d’attestation v1 utilisée dans Windows Server 2016 vous a permis de remplacer cette vérification de sécurité en spécifiant l’indicateur -Force lorsque vous exécutez Add-HgsAttestationTpmHost ou d’autres applets de commande d’attestation TPM pour capturer les artefacts. À compter de Windows Server 2019, l’attestation v2 est utilisée par défaut et vous devez spécifier l’indicateur -PolicyVersion v1 lorsque vous exécutez Add-HgsAttestationTpmHost si vous devez inscrire un TPM sans certificat. L’indicateur -Force ne fonctionne pas avec l’attestation v2.

Un hôte ne peut attester que si tous les artefacts (EKPub + base de référence TPM + stratégie CI) utilisent la même version de l’attestation. L’attestation V2 est d’abord essayée, et en cas d’échec, l’attestation v1 est utilisée. Cela signifie que si vous devez inscrire un identificateur TPM à l’aide de l’attestation v1, vous devez également spécifier l’indicateur -PolicyVersion v1 pour utiliser l’attestation v1 lorsque vous capturez la base de référence TPM et créez la stratégie CI. Si la base de référence TPM et la stratégie CI ont été créées à l’aide de l’attestation v2, puis que vous devez ajouter un hôte protégé sans certificat TPM, vous devez recréer chaque artefact avec l’indicateur -PolicyVersion v1.

Capturer l’identificateur TPM (identificateur de plateforme ou EKpub) pour chaque hôte

  1. Dans le domaine de la structure, assurez-vous que le TPM sur chaque hôte est prêt à être utilisé, c’est-à-dire que le module de plateforme sécurisée est initialisé et que la propriété est obtenue. Vous pouvez vérifier l’état du TPM en ouvrant la console de gestion de TPM (tpm.msc) ou en exécutant Get-Tpm dans une fenêtre de Windows PowerShell avec élévation de privilèges. Si votre TPM n’est pas à l’état Prêt , vous devez l’initialiser et définir sa propriété. Vous pouvez le faire dans la console de gestion du TPM ou en exécutant Initialize-Tpm.

  2. Sur chaque hôte protégé, exécutez la commande suivante dans une console Windows PowerShell avec élévation de privilèges pour obtenir son EKpub. Pour <HostName>, remplacez le nom d’hôte unique par un élément approprié pour identifier cet hôte, il peut s’agir de son nom d’hôte ou du nom utilisé par un service d’inventaire d’infrastructure (le cas échéant). À titre de commodité, nommez le fichier de sortie en utilisant le nom de l’hôte.

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

  3. Répétez les étapes précédentes pour chaque hôte qui deviendra un hôte protégé, en veillant à donner à chaque fichier XML un nom unique.

  4. Fournissez les fichiers XML obtenus à l’administrateur SGH.

  5. Dans le domaine SGH, ouvrez une console de Windows PowerShell avec élévation de privilèges sur un serveur SGH et exécutez la commande suivante. Répétez la commande pour chacun des fichiers XML.

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

    Notes

    Si vous rencontrez une erreur lors de l’ajout d’un identificateur TPM concernant un certificat de clé d’approbation (EKCert) non approuvé, vérifiez que les certificats racines TPM approuvés ont été ajoutés au nœud SGH. En outre, certains fournisseurs TPM n’utilisent pas de certificats EK. Vous pouvez vérifier si un EKCert est manquant en ouvrant le fichier XML dans un éditeur comme le Bloc-notes et en recherchant un message d’erreur indiquant qu’aucun certificat EKCert n’a été trouvé. Si c’est le cas et que vous êtes sûr que le TPM de votre ordinateur est authentique, vous pouvez utiliser le paramètre -Force pour ajouter l’identificateur de l’hôte à SGH. Dans Windows Server 2019, vous devez également utiliser le paramètre -PolicyVersion v1 lors de l’utilisation de -Force. Cela crée une stratégie cohérente avec le comportement Windows Server 2016 et vous oblige à utiliser -PolicyVersion v1 lors de l’inscription de la stratégie CI et de la base de référence TPM.

Créer et appliquer une stratégie d'intégrité du code

Une stratégie d’intégrité du code permet de s’assurer que seuls les exécutables que vous approuvez pour s’exécuter sur un hôte sont autorisés à s’exécuter. Les programmes malveillants et autres exécutables en dehors des exécutables approuvés ne peuvent pas s’exécuter.

Chaque hôte protégé doit avoir une stratégie d’intégrité du code appliquée pour exécuter des machines virtuelles protégées en mode TPM. Vous spécifiez les stratégies d’intégrité du code exactes que vous approuvez en les ajoutant à SGH. Les stratégies d’intégrité du code peuvent être configurées pour appliquer la stratégie, bloquer les logiciels qui ne sont pas conformes à la stratégie ou simplement auditer (journaliser un événement lorsque le logiciel non défini dans la stratégie est exécuté).

À compter de Windows Server version 1709, les stratégies d’intégrité de code échantillon sont inclus dans C:\Windows\schemas\CodeIntegrity\ExamplePolicies. Deux stratégies sont recommandées pour Windows Server :

  • AllowMicrosoft : autorise tous les fichiers signés par Microsoft. Cette stratégie est recommandée pour les applications serveur telles que SQL ou Exchange, ou si le serveur est surveillé par des agents publiés par Microsoft.
  • DefaultWindows_Enforced : autorise uniquement les fichiers fournis dans Windows et n’autorise pas les autres applications publiées par Microsoft, telles qu’Office. Cette stratégie est recommandée pour les serveurs qui exécutent uniquement des rôles serveur intégrés et des fonctionnalités telles qu’Hyper-V.

Il est recommandé de créer d’abord la stratégie CI en mode audit (journalisation) pour voir s’il manque quelque chose, puis d’appliquer la stratégie pour les charges de travail de production de l’hôte.

Si vous utilisez l’applet de commande New-CIPolicy pour générer votre propre stratégie d’intégrité du code, vous devez décider des niveaux de règle à utiliser. Nous recommandons un niveau principal de Publisher avec secours vers Hash, qui permet de mettre à jour la plupart des logiciels signés numériquement sans modifier la stratégie CI. Les nouveaux logiciels écrits par le même éditeur peuvent également être installés sur le serveur sans modifier la stratégie CI. Les exécutables qui ne sont pas signés numériquement sont hachés. Mettre à jour à ces fichiers vous obligera à créer une stratégie CI. Pour plus d’informations sur les niveaux de règle de stratégie CI disponibles, consultez Déployer des stratégies d’intégrité du code : règles de stratégie et règles de fichier et aide sur les applets de commande.

  1. Sur l’hôte de référence, générez une nouvelle stratégie d’intégrité du code. Les commandes suivantes créent une stratégie au niveau de l’Éditeurs avec secours au hachage. Ensuite le fichier XML est converti au format de fichier binaire. Puis Windows et SGH doivent appliquer et mesurer la stratégie CI, respectivement.

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

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

    Notes

    La commande ci-dessus crée une stratégie CI en mode audit uniquement. Elle n’empêche pas l’exécution des fichiers binaires non autorisés sur l’hôte. Vous devez uniquement utiliser des stratégies appliquées en production.

  2. Conservez votre fichier de stratégie d’intégrité du code (fichier XML) où vous pouvez facilement le trouver. Vous devrez modifier ce fichier ultérieurement pour appliquer la stratégie CI ou fusionner les modifications à partir des futures mises à jour apportées au système.

  3. Appliquez la stratégie CI à votre hôte de référence :

    1. Exécutez la commande suivante pour configurer la machine afin qu’elle utilise votre stratégie CI. Vous pouvez également déployer la stratégie CI avec stratégie de groupe ou System Center Virtual Machine Manager.

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

    2. Redémarrez l’hôte pour appliquer la stratégie.

  4. Testez la stratégie d’intégrité du code en exécutant une charge de travail classique. Cela peut inclure des machines virtuelles en cours d’exécution, des agents de gestion de l’infrastructure, des agents de sauvegarde ou des outils de résolution des problèmes sur l’ordinateur. Vérifiez s’il existe des violations de l’intégrité du code et mettez à jour votre stratégie CI si nécessaire.

  5. Modifiez votre stratégie CI en mode appliqué en exécutant les commandes suivantes sur votre fichier XML de stratégie CI mis à jour.

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

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

  6. Appliquez la stratégie CI à tous vos hôtes (avec une configuration matérielle et logicielle identique) à l’aide des commandes suivantes :

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

Restart-Computer

    Notes

    Faites attention lorsque vous appliquez des stratégies d’intégration continue aux hôtes et lors de la mise à jour de logiciels sur ces machines. Tous les pilotes en mode noyau qui ne sont pas conformes à la stratégie CI peuvent empêcher le démarrage de l’ordinateur.

  7. Fournissez le fichier binaire (dans cet exemple, HW1CodeIntegrity_enforced.p7b) à l’administrateur SGH.

  8. Dans le domaine SGH, copiez la stratégie d’intégrité du code sur un serveur SGH et exécutez la commande suivante.

    Pour <PolicyName>, spécifiez un nom pour la stratégie CI qui décrit le type d’hôte auquel elle s’applique. Une bonne pratique consiste à le nommer d’après la marque/le modèle de votre machine et toute configuration logicielle spéciale exécutée dessus. Pour <Path>, spécifiez le chemin d’accès et le nom de fichier de la stratégie d’intégrité du code.

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

    Notes

    Si vous utilisez une stratégie d’intégrité du code signée, inscrivez une copie non signée de la même stratégie auprès de SGH. La signature sur les stratégies d’intégrité du code est utilisée pour contrôler les mises à jour de la stratégie, mais n’est pas mesurée dans le TPM hôte et ne peut donc pas être attestée par SGH.

Capturer la base de référence TPM pour chaque classe unique de matériel

Une base de référence TPM est requise pour chaque classe unique de matériel dans votre infrastructure de centre de données. Utilisez à nouveau un « hôte de référence ».

  1. Sur l’hôte de référence, assurez-vous que le rôle Hyper-V et la fonctionnalité Support Hyper-V pour Host Guardian sont installés.

    Avertissement

    La fonctionnalité de prise en charge Hyper-V de Guardian hôte permet une protection basée sur la virtualisation de l’intégrité du code qui peut être incompatible avec certains appareils. Nous vous recommandons vivement de tester cette configuration dans votre laboratoire avant d'activer cette fonctionnalité. Dans le cas contraire, cela risque d’entraîner des échecs inattendus pouvant aller jusqu'à la perte de données ou un écran bleu d’erreur (également appelé erreur d’arrêt).

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

  2. Pour capturer la stratégie de base de référence, exécutez la commande suivante dans une console Windows PowerShell avec élévation de privilèges.

    Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'

    Notes

    Vous devez utiliser l’indicateur -SkipValidation si le démarrage sécurisé de l’hôte de référence n’est pas activé, si l’outil IOMMU est présent, si la sécurité basée sur la virtualisation est activée et en cours d’exécution, ou si une stratégie d’intégrité du code est appliquée. Ces validations sont conçues pour vous informer des exigences minimales de l’exécution d’une machine virtuelle protégée sur l’hôte. L’utilisation de l’indicateur -SkipValidation ne modifie pas la sortie de l’applet de commande ; il réduit simplement au silence les erreurs.

  3. Fournissez la base de référence TPM (fichier TCGlog) à l’administrateur SGH.

  4. Dans le domaine SGH, copiez le fichier TCGlog sur un serveur SGH et exécutez la commande suivante. En règle générale, vous nommez la stratégie d’après la classe de matériel qu’elle représente (par exemple, « Révision du modèle fabricant »).

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

Étape suivante

Confirmer l’attestation