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

  • Article
  • 10 minutes de lecture

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 s’assurer qu’un hôte Hyper-V donné est dans un état sain et exécute uniquement du code approuvé. Pour que l’attestation comprenne ce qui est sain et ce qui ne l’est pas, 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 du module de plateforme sécurisée (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 verte de 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 base de référence et la stratégie CI à partir d’un « hôte de référence » qui est 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, où un certificat TPM doit être présent pour ajouter l’EKPub à HGS. 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 module de plateforme sécurisée sans certificat. L’indicateur -Force ne fonctionne pas avec l’attestation v2.

Un hôte peut uniquement attester si tous les artefacts (EKPub + ligne de base TPM + stratégie CI) utilisent la même version de l’attestation. L’attestation V2 est essayée en premier. 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 et que vous devez ajouter ultérieurement 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 l’infrastructure, assurez-vous que le module TPM sur chaque hôte est prêt à être utilisé, c’est-à-dire que le module de plateforme sécurisée est initialisé et la propriété obtenue. Vous pouvez vérifier l’état du module de plateforme sécurisée en ouvrant la console de gestion du module de plateforme sécurisée (tpm.msc) ou en exécutant Get-Tpm dans une fenêtre de Windows PowerShell avec élévation de privilèges. Si votre module TPM n’est pas à l’état Prêt , vous devez l’initialiser et définir sa propriété. Cela peut être effectué dans la console de gestion du module de plateforme sécurisée 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). Pour plus de commodité, nommez le fichier de sortie à l’aide du 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 un nom unique à chaque fichier XML.

  4. Fournissez les fichiers XML résultants à l’administrateur HGS.

  5. Dans le domaine HGS, ouvrez une console Windows PowerShell avec élévation de privilèges sur un serveur HGS 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é, assurez-vous que les certificats racines TPM approuvés ont été ajoutés au nœud HGS. En outre, certains fournisseurs TPM n’utilisent pas de certificats EK. Vous pouvez vérifier si un certificat EKCert est manquant en ouvrant le fichier XML dans un éditeur tel que 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 convaincu que le module TPM de votre ordinateur est authentique, vous pouvez utiliser le -Force paramètre pour ajouter l’identificateur d’hôte à HGS. Dans Windows Server 2019, vous devez également utiliser le paramètre lors de l’utilisation -PolicyVersion v1 de -Force. Cela crée une stratégie cohérente avec le comportement Windows Server 2016 et vous devrez également l’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 garantir que seuls les exécutables que vous avez confiance 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 à HGS. 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 effectuer un audit (journaliser un événement quand un logiciel non défini dans la stratégie est exécuté).

À compter de Windows Server version 1709, les exemples de stratégies d’intégrité du code sont inclus dans Windows à l’adresse 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 que 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 hôtes.

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 hachage, ce qui permet à la plupart des logiciels signés numériquement d’être mis à jour 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 seront hachés. Mises à jour à ces fichiers vous oblige à 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 l’applet 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 du serveur de publication avec secours au hachage. Il convertit ensuite le fichier XML au format de fichier binaire dont Windows et HGS ont besoin pour 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. Il n’empêche pas l’exécution de fichiers binaires non autorisés sur l’hôte. Vous devez utiliser uniquement des stratégies appliquées en production.

  2. Conservez votre fichier de stratégie d’intégrité du code (fichier XML) où vous pouvez le trouver facilement. Vous devrez modifier ce fichier ultérieurement pour appliquer la stratégie CI ou fusionner les modifications à partir de mises à jour ultérieures 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 l’exécution de machines virtuelles, d’agents de gestion d’infrastructure, d’agents de sauvegarde ou d’outils de résolution des problèmes sur la machine. 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

    Soyez prudent lors de l’application de stratégies CI aux hôtes et de la mise à jour de tout logiciel sur ces ordinateurs. 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 HGS.

  8. Dans le domaine HGS, copiez la stratégie d’intégrité du code sur un serveur HGS 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 fabrique/le modèle de votre machine et toute configuration logicielle spéciale qui s’exécute sur celle-ci. 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é, inscrivez une copie non signée de la même stratégie auprès de HGS. 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 module TPM hôte et ne peut donc pas être attestée par HGS.

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 Host Guardian 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, 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 un 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 de la configuration minimale requise pour 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 fait simplement taire les erreurs.

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

  4. Dans le domaine HGS, copiez le fichier TCGlog sur un serveur HGS 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