VM protégée

Les VM protégées offrent une intégrité vérifiable à vos instances de VM Compute Engine, vous assurant qu'elles n'ont pas été compromises par des logiciels malveillants ou des rootkits au niveau du démarrage ou du noyau. Cette intégrité vérifiable des VM protégées est assurée grâce aux fonctionnalités de démarrage sécurisé, de démarrage mesuré basé sur un module vTPM (Virtual Trusted Platform Module) et de surveillance de l'intégrité.

Les VM protégées constituent la première offre de l'initiative sur la protection du cloud. Cette initiative vise à fournir une base encore plus sécurisée à Google Cloud Platform (GCP), par le biais d'une intégrité vérifiable et de fonctionnalités telles que la protection ou le scellement vTPM, qui empêchent l'exfiltration des données.

Démarrage sécurisé

Le démarrage sécurité vous permet de vous assurer que le système n'exécute que des logiciels authentiques. Il vérifie pour cela la signature numérique de tous les composants de démarrage et interrompt le processus de démarrage si cette vérification échoue.

Les instances de VM protégées exécutent un micrologiciel signé et vérifié par l'autorité de certification de Google, ce qui vous garantit qu'il n'a pas été altéré et permet d'établir la racine de confiance pour le démarrage sécurisé. Le micrologiciel UEFI 2.3.1 (Unified Extensible Firmware Interface) gère en toute sécurité les certificats contenant les clés utilisées par les fabricants de logiciels pour signer le micrologiciel du système, le chargeur de démarrage du système et les fichiers binaires qu'ils chargent. Les instances de machines virtuelles protégées utilisent le micrologiciel UEFI.

À chaque démarrage, le micrologiciel UEFI vérifie la signature numérique de chaque composant de démarrage à l'aide d'un magasin sécurisé de clés approuvées. Tout composant qui n'est pas correctement signé (ou pas signé du tout) n'est pas autorisé à s'exécuter.

Dans ce cas, l'instance de VM affiche un état d'erreur dans la console GCP, et le journal de la console série de cette instance inclut une entrée contenant les chaînes UEFI : Échec du chargement de l'image et État : Violation de sécurité, ainsi qu'une description de l'option de démarrage qui a échoué. Pour remédier à la situation, désactivez le démarrage sécurisé en suivant les instructions décrites dans la section Modifier les options de la VM protégée. Démarrez l'instance de VM, diagnostiquez et résolvez le problème, puis réactivez le démarrage sécurisé.

Module vTPM (Virtual Trusted Platform Module)

Un vTPM, ou module de plate-forme sécurisée virtualisé, est une puce informatique spécialisée qui vous permet de protéger des objets, tels que des clés et des certificats servant à authentifier l'accès à votre système. Le module vTPM des VM protégées est entièrement compatible avec la spécification de bibliothèque TPM 2.0 du Trusted Computing Group et exploite BoringSSL, qui a obtenu la certification FIPS 140-2 L1.

Le module vTPM des VM protégées permet d'obtenir un démarrage mesuré en effectuant les mesures nécessaires à la création d'une référence connue pour un démarrage sain, appelée règle d'intégrité de référence. Cette règle compare les mesures provenant des démarrages de VM suivants afin d'identifier toute éventuelle modification.

Le module vTPM vous permet également de défendre vos codes secrets grâce à la protection ou au scellement. Pour en savoir plus sur cette démarche et consulter des exemples en langage Go, reportez-vous au projet go-tpm sur GitHub.

Démarrage mesuré

Lors du démarrage mesuré, un hachage de chaque composant (par exemple, le micrologiciel, le bootloader ou le noyau) est créé pendant son chargement. Ce hachage est ensuite concaténé, puis ré-haché à l'aide des hachages de composants déjà chargés. Le schéma ci-dessous décrit ce processus :

Processus de démarrage mesuré

Ces informations identifient les composants chargés ainsi que leur ordre de chargement.

Lorsque vous lancez une instance de VM pour la première fois, le démarrage mesuré crée la règle d'intégrité de référence à partir du premier ensemble de mesures et stocke ces données de manière sécurisée. À chaque nouveau lancement de l'instance de VM, ces mesures sont ensuite reprises et stockées dans la mémoire sécurisée jusqu'au redémarrage suivant. Ces deux ensembles de mesures vous permettent de surveiller l'intégrité et ainsi de déterminer si des modifications ont été apportées à la séquence de démarrage d'une instance de VM.

Surveillance de l'intégrité

La surveillance de l'intégrité vous aide à comprendre l'état de vos instances de VM et à prendre des décisions les concernant.

Elle s'articule autour des mesures créées par le démarrage sécurisé, qui exploitent des registres de configuration de plate-forme (PCR) pour stocker des informations sur les composants, ainsi que sur l'ordre de chargement des composants de la règle d'intégrité de référence (séquence de démarrage sain connue) et de la séquence de démarrage la plus récente.

La surveillance de l'intégrité compare les mesures de démarrage les plus récentes à la règle d'intégrité de référence et renvoie une paire de résultats de réussite ou d'échec selon leur correspondance. L'un des résultats concerne la séquence de démarrage précoce tandis que l'autre touche la séquence de démarrage tardive. Le démarrage précoce représente la séquence de démarrage entre le lancement du micrologiciel UEFI et la prise de contrôle du bootloader. Le démarrage tardif, quant à lui, représente la séquence de démarrage entre le bootloader et la prise de contrôle du noyau du système d'exploitation. Si l'une des parties de la séquence de démarrage la plus récente ne correspond pas à la règle de référence, vous obtenez un échec de validation de l'intégrité.

Si vous vous attendez à recevoir un échec (lorsque vous avez appliqué une mise à jour système sur l'instance de VM, par exemple), mettez à jour la règle d'intégrité de référence. Cette opération remplace la règle d'intégrité de référence par les mesures enregistrées lors de la dernière séquence de démarrage. Si vous ne vous attendiez pas à un échec, arrêtez l'instance de VM et recherchez la cause du problème.

Vous pouvez afficher les rapports d'intégrité dans Stackdriver Monitoring et configurer des alertes pour les échecs d'intégrité. Vous pouvez également examiner les détails des résultats de la surveillance de l'intégrité dans Stackdriver Logging. Pour en savoir plus, consultez la section Surveiller l'intégrité sur des instances de VM protégées.

Événements de surveillance de l'intégrité

Les VM protégées génèrent des entrées de journal pour les types d'événements suivants :

  • clearTPMEvent : indique si le module vTPM a été effacé (ce qui entraîne la suppression des codes secrets y étant stockés). Cet événement n'affectant aucun aspect des VM protégées, il n'est utile que si vous protégez vos données sensibles à l'aide du module vTPM, comme décrit dans la section Module vTPM (Virtual Trusted Platform Module).
  • earlyBootReportEvent : indique si le contrôle d'intégrité de la séquence de démarrage précoce a réussi. Fournit également des détails sur les valeurs des registres de configuration de plate-forme à partir de la règle de référence et de la séquence de démarrage la plus récente qui ont permis d'obtenir ce résultat.
  • lateBootReportEvent : indique si le contrôle d'intégrité de la séquence de démarrage tardive a réussi. Fournit également des détails sur les valeurs des registres de configuration de plate-forme à partir de la règle de référence et de la séquence de démarrage la plus récente qui ont permis d'obtenir ce résultat.
  • setShieldedInstanceIntegrityPolicy : consigne chaque mise à jour de la règle d'intégrité de référence.
  • shutdownEvent : consigne chaque arrêt de l'instance de VM.
  • startupEvent : consigne chaque démarrage de l'instance de VM. C'est la valeur bootCounter qui nous intéresse dans cet événement, car elle identifie le nombre de redémarrages de l'instance.
  • updateShieldedInstanceConfig : consigne chaque activation ou désactivation de l'une des options de la machine virtuelle protégée.

Les journaux affichent généralement les événements dans l'ordre suivant : startupEvent, earlyBootReportEvent, lateBootReportEvent, puis shutdownEvent. Ils comportent tous la même valeur bootCounter, qui les identifie comme appartenant à la même séquence de démarrage d'instance de VM.

Si vous mettez à jour la règle d'intégrité de référence en réponse à un échec d'intégrité attendu sur une instance de VM, vous verrez également les événements earlyBootReportEvent et lateBootReportEvent, qui décrivent les nouvelles mesures de la règle d'intégrité de référence. L'exemple suivant vous montre la séquence attendue :

  • startupEvent
  • earlyBootReportEvent, qui compare la règle de référence d'origine à la séquence de démarrage la plus récente (réussite)
  • lateBootReportEvent, qui compare la règle de référence d'origine à la séquence de démarrage la plus récente (échec)
  • setShieldedInstanceIntegrityPolicy, qui, lors de la mise à jour de la règle d'intégrité de référence, la définit sur les mesures enregistrées lors de la dernière séquence de démarrage
  • earlyBootReportEvent, qui compare la nouvelle règle de référence à la séquence de démarrage la plus récente (réussite)
  • lateBootReportEvent, qui compare la nouvelle règle de référence à la séquence de démarrage la plus récente (réussite)

Windows

earlyBootReportEvent

Les informations importantes de l'événement earlyBootReportEvent se trouvent dans la section earlyBootReportEvent, qui contient les sections et éléments suivants :

  • actualMeasurements : contient les valeurs des registres de configuration de plate-forme (PCR) pour la séquence de démarrage la plus récente. Ces valeurs PCR identifient les composants de démarrage et l'ordre de chargement des composants utilisés par la séquence de démarrage la plus récente. Elles sont ensuite comparées à la règle d'intégrité de référence (dont les valeurs sont enregistrées dans la section policyMeasurements) afin de repérer toute éventuelle modification dans la séquence de démarrage de l'instance de VM. La section actualMeasurements comporte les éléments suivants :

    • 0 : contient la valeur de PCR0, qui comprend des informations sur les composants du micrologiciel. Ce registre de configuration de plate-forme n'est pas mis en œuvre et contient à la place une valeur statique. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 1 : contient la valeur de PCR4, qui comprend des informations sur le code du gestionnaire de démarrage UEFI et sur les tentatives de démarrage.
    • 2 : contient la valeur de PCR5, qui comprend des informations sur la table de partition GUID du disque. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 3 : contient la valeur de PCR7, qui comprend des informations sur la règle de démarrage sécurisé de l'instance.
  • policyEvaluationPassed : indique si la vérification d'une section spécifique de la séquence de démarrage par rapport à la règle d'intégrité de référence a réussi ou non.

  • policyMeasurements : contient les valeurs des registres de configuration de plate-forme pour la règle d'intégrité de référence. La section policyMeasurements comporte les éléments suivants :

    • 0 : contient la valeur de PCR0, qui comprend des informations sur les composants du micrologiciel. Ce registre de configuration de plate-forme n'est pas mis en œuvre et contient à la place une valeur statique. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 1 : contient la valeur de PCR4, qui comprend des informations sur le code du gestionnaire de démarrage UEFI et sur les tentatives de démarrage.
    • 2 : contient la valeur de PCR7, qui comprend des informations sur la règle de démarrage sécurisé de l'instance.

Pour apprendre à exploiter les valeurs PCR de l'événement earlyBootReportEvent afin de diagnostiquer un échec de validation d'intégrité du démarrage, consultez la section Déterminer la cause de l'échec de la validation d'intégrité du démarrage.

lateBootReportEvent

Les informations importantes de l'événement lateBootReportEvent se trouvent dans la section lateBootReportEvent, qui contient les sections et éléments suivants :

  • actualMeasurements : contient les valeurs des registres de configuration de plate-forme (PCR) pour la séquence de démarrage la plus récente. Ces valeurs PCR identifient les composants de démarrage et l'ordre de chargement des composants utilisés par la séquence de démarrage la plus récente. Elles sont ensuite comparées à la règle d'intégrité de référence (dont les valeurs sont enregistrées dans la section policyMeasurements) afin de repérer toute éventuelle modification dans la séquence de démarrage de l'instance de VM. La section actualMeasurements comporte les éléments suivants :

    • 0 : contient la valeur de PCR0, qui comprend des informations sur les composants du micrologiciel. Ce registre de configuration de plate-forme n'est pas mis en œuvre et contient à la place une valeur statique. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 1 : contient la valeur de PCR4, qui comprend des informations sur le code du gestionnaire de démarrage UEFI et sur les tentatives de démarrage.
    • 2 : contient la valeur de PCR5, qui comprend des informations sur la table de partition GUID du disque. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 3 : contient la valeur de PCR7, qui comprend des informations sur la règle de démarrage sécurisé de l'instance.
    • 4 : contient la valeur de PCR11, qui comprend des informations sur le contrôle des accès de BitLocker Drive Encryption.
    • 5 : contient la valeur de PCR12, qui comprend des informations sur les événements de données. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 6 : contient la valeur de PCR13, qui comprend des informations sur le noyau Windows et sur les pilotes de démarrage.
    • 7 : contient la valeur de PCR14, qui comprend des informations sur les autorités de démarrage de Windows.
  • policyEvaluationPassed : indique si la vérification d'une section spécifique de la séquence de démarrage par rapport à la règle d'intégrité de référence a réussi ou non.

  • policyMeasurements : contient les valeurs des registres de configuration de plate-forme pour la règle d'intégrité de référence. La section policyMeasurements comporte les éléments suivants :

    • 0 : contient la valeur de PCR0, qui comprend des informations sur les composants du micrologiciel. Ce registre de configuration de plate-forme n'est pas mis en œuvre et contient à la place une valeur statique. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 1 : contient la valeur de PCR4, qui comprend des informations sur le code du gestionnaire de démarrage UEFI et sur les tentatives de démarrage.
    • 2 : contient la valeur de PCR7, qui comprend des informations sur la règle de démarrage sécurisé de l'instance.
    • 3 : contient la valeur de PCR11, qui comprend des informations sur le contrôle des accès de BitLocker Drive Encryption.
    • 4 : contient la valeur de PCR13, qui comprend des informations sur le noyau Windows et sur les pilotes de démarrage.
    • 5 : contient la valeur de PCR14, qui comprend des informations sur les autorités de démarrage de Windows.

Pour apprendre à exploiter les valeurs PCR de l'événement lateBootReportEvent afin de diagnostiquer un échec de validation d'intégrité du démarrage, consultez la section Déterminer la cause de l'échec de la validation d'intégrité du démarrage.

Linux

earlyBootReportEvent

Les informations importantes de l'événement earlyBootReportEvent se trouvent dans la section earlyBootReportEvent, qui contient les sections et éléments suivants :

  • actualMeasurements : contient les valeurs des registres de configuration de plate-forme (PCR) pour la séquence de démarrage la plus récente. Ces valeurs PCR identifient les composants de démarrage et l'ordre de chargement des composants utilisés par la séquence de démarrage la plus récente. Elles sont ensuite comparées à la règle d'intégrité de référence (dont les valeurs sont enregistrées dans la section policyMeasurements) afin de repérer toute éventuelle modification dans la séquence de démarrage de l'instance de VM. La section actualMeasurements comporte les éléments suivants :

    • 0 : contient la valeur de PCR0, qui comprend des informations sur les composants du micrologiciel. Ce registre de configuration de plate-forme n'est pas mis en œuvre et contient à la place une valeur statique. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 1 : contient la valeur de PCR4, qui comprend des informations sur le shim du système d'exploitation.
    • 2 : contient la valeur de PCR5, qui comprend des informations sur la table de partition GUID du disque. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 3 : contient la valeur de PCR7, qui comprend des informations sur la règle de démarrage sécurisé de l'instance.
  • policyEvaluationPassed : indique si la vérification d'une section spécifique de la séquence de démarrage par rapport à la règle d'intégrité de référence a réussi ou non.

  • policyMeasurements : contient les valeurs des registres de configuration de plate-forme pour la règle d'intégrité de référence. La section policyMeasurements comporte les éléments suivants :

    • 0 : contient la valeur de PCR0, qui comprend des informations sur les composants du micrologiciel. Ce registre de configuration de plate-forme n'est pas mis en œuvre et contient à la place une valeur statique. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 1 : contient la valeur de PCR4, qui comprend des informations sur le shim du système d'exploitation.
    • 2 : contient la valeur de PCR7, qui comprend des informations sur la règle de démarrage sécurisé de l'instance.

Pour apprendre à exploiter les valeurs PCR de l'événement earlyBootReportEvent afin de diagnostiquer un échec de validation d'intégrité du démarrage, consultez la section Déterminer la cause de l'échec de la validation d'intégrité du démarrage.

lateBootReportEvent

Les informations importantes de l'événement lateBootReportEvent se trouvent dans la section lateBootReportEvent, qui contient les sections et éléments suivants :

  • actualMeasurements : contient les valeurs des registres de configuration de plate-forme (PCR) pour la séquence de démarrage la plus récente. Ces valeurs PCR identifient les composants de démarrage et l'ordre de chargement des composants utilisés par la séquence de démarrage la plus récente. Elles sont ensuite comparées à la règle d'intégrité de référence (dont les valeurs sont enregistrées dans la section policyMeasurements) afin de repérer toute éventuelle modification dans la séquence de démarrage de l'instance de VM. La section actualMeasurements comporte les éléments suivants :

    • 0 : contient la valeur de PCR0, qui comprend des informations sur les composants du micrologiciel. Ce registre de configuration de plate-forme n'est pas mis en œuvre et contient à la place une valeur statique. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 1 : contient la valeur de PCR4, qui comprend des informations sur le bootloader de la deuxième phase et sur le noyau.
    • 2 : contient la valeur de PCR5, qui comprend des informations sur la table de partition GUID du disque. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 3 : contient la valeur de PCR7, qui comprend des informations sur la règle de démarrage sécurisé de l'instance.
  • policyEvaluationPassed : indique si la vérification d'une section spécifique de la séquence de démarrage par rapport à la règle d'intégrité de référence a réussi ou non.

  • policyMeasurements : contient les valeurs des registres de configuration de plate-forme pour la règle d'intégrité de référence. La section policyMeasurements comporte les éléments suivants :

    • 0 : contient la valeur de PCR0, qui comprend des informations sur les composants du micrologiciel. Ce registre de configuration de plate-forme n'est pas mis en œuvre et contient à la place une valeur statique. Cet élément n'est pas utilisé lors de la validation de la séquence de démarrage la plus récente par rapport à la règle d'intégrité de référence.
    • 1 : contient la valeur de PCR4, qui comprend des informations sur le bootloader de la deuxième phase et sur le noyau.
    • 2 : contient la valeur de PCR7, qui comprend des informations sur la règle de démarrage sécurisé de l'instance.

Pour apprendre à exploiter les valeurs PCR de l'événement lateBootReportEvent afin de diagnostiquer un échec de validation d'intégrité du démarrage, consultez la section Déterminer la cause de l'échec de la validation d'intégrité du démarrage.

Autorisation Cloud IAM

Les VM protégées utilisent les autorisations Cloud IAM.

Les autorisations Compute Engine suivantes sont nécessaires pour effectuer des opérations liées aux VM protégées :

  • compute.instances.updateShieldedInstanceConfig : permet à l'utilisateur de modifier les options de VM protégée sur une instance de VM.
  • compute.instances.setShieldedInstanceIntegrityPolicy : permet à l'utilisateur de mettre à jour la règle d'intégrité de référence sur une instance de VM.
  • compute.instances.getShieldedInstanceIdentity : permet à l'utilisateur de récupérer des informations relatives aux clés d'endossement à partir du vTPM.

Les autorisations associées aux VM protégées sont accordées aux rôles Compute Engine suivants :

  • roles/compute.instanceAdmin.v1
  • roles/compute.securityAdmin

Vous pouvez également accorder des autorisations relatives aux VM protégées aux rôles personnalisés.

Contraintes en matière de règles d'administration pour les VM protégées

Vous pouvez définir la contrainte en matière de règles d'administration constraints/compute.requireShieldedVm sur True pour exiger que les instances de VM Compute Engine créées dans votre organisation soient des instances de VM protégées.

Consultez la section Utiliser des contraintes booléennes dans la règle d'administration pour apprendre à définir la contrainte constraints/compute.requireShieldedVm. Vous devez être un administrateur de règle d'administration pour définir une contrainte.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…