Ce contenu a été mis à jour pour la dernière fois en mai 2024, et correspond à l'état des connaissances à sa date de rédaction. Les règles et les systèmes de sécurité Google peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.
Ce document décrit l'approche de Google en matière d'attestation des machines d'un centre de données. L'architecture décrite dans ce document est conçue pour être intégrée à des normes ouvertes telles que TPM (Trusted Platform Module), SPDM (Security Protocol and Data Model) et Redfish. Pour en savoir plus sur les nouvelles normes ou les implémentations de référence proposées par Google et liées à l'attestation des machines d'un centre de données, consultez notre projet PINT (Platform Integrity) sur GitHub. Ce document est destiné aux cadres, architectes et auditeurs de sécurité.
Présentation
Google conçoit et déploie de plus en plus des machines de centre de données désagrégées. Au lieu d'une racine de confiance unique, de nombreuses machines contiennent des racines de confiance distinctes, y compris des racines de confiance pour la mesure (root of trust for measurement ou RTM), le stockage, la mise à jour et la récupération. Chaque RTM gère une sous-section de l'ensemble de la machine. Par exemple, une machine peut avoir une RTM qui assure la mesure et l'attestation de ce qui a démarré sur le processeur principal, et une autre RTM qui assure la mesure et l'attestation de ce qui a démarré sur une carte SmartNIC connectée à un emplacement PCIe. Le schéma suivant illustre un exemple de machine.
La complexité d'avoir plusieurs RTM dans une machine augmente l'échelle et les attentes considérables vis-à-vis des machines de centre de données, et de nombreuses complications peuvent survenir en raison de pannes humaines, matérielles ou logicielles. En résumé, assurer l'intégrité des micrologiciels de notre parc n'est pas une mince affaire.
Le système décrit dans ce document est conçu pour faciliter la gestion du problème de l'attestation à distance pour les machines désagrégées. Cette infrastructure d'attestation est extensible, ce qui lui permet de s'adapter à des machines de plus en plus complexes à mesure qu'elles apparaissent dans le centre de données.
En partageant ce travail, nous nous efforçons d'offrir notre point de vue sur la manière dont l'attestation de machines désagrégées peut être réalisée à grande échelle. À travers nos collaborations avec les partenaires du secteur et nos contributions aux organismes de normalisation tels que Distributed Management Task Force (DMTF), Trusted Computing Group (TCG) et Open Compute Project (OCP), notre objectif est de continuer à soutenir l'innovation en matière de sécurité dans cet espace.
Propriétés recommandées pour les RTM
Cette section présente certaines propriétés que nous recommandons pour les RTM.
Intégration matérielle des RTM
Lorsqu'un processeur est associé à une RTM, celle-ci doit capturer des mesures sur le premier code modifiable s'exécutant sur ce processeur. Tout code modifiable ultérieur doit voir ses mesures capturées et rapportées à une racine de confiance avant son exécution. Cet agencement produit une chaîne de démarrage mesuré qui permet une attestation fiable de l'état de sécurité critique du processeur.
Attestation d'identité matérielle et d'identité du micrologiciel de la RTM
Chaque RTM doit posséder une paire de clés de signature permettant d'émettre des attestations pour une validation externe. La chaîne de certificats de cette paire de clés doit inclure des preuves cryptographiques de l'identité matérielle unique de la RTM et de l'identité du micrologiciel pour tout code modifiable s'exécutant au sein de la RTM. La chaîne de certificats doit être racine chez le fabricant de la RTM. Cette approche permet aux machines de surmonter les failles critiques du micrologiciel RTM.
La spécification DICE (Device Identifier Composition Engine) est une formalisation du modèle utilisé dans notre solution d'attestation. Le fabricant de la RTM certifie une paire de clés d'appareil unique, qui certifie une paire de clés d'alias spécifique à l'identité matérielle et à l'image de micrologiciel de la RTM. La chaîne de certificats des clés d'alias contient une mesure du micrologiciel de la RTM ainsi que le numéro de série de la RTM. Les outils de vérification peuvent ainsi être certains que toutes les données signées par une clé d'alias donnée ont été émises par une RTM décrite par les mesures cryptographiques d'identité du matériel et du micrologiciel intégrées à la chaîne de certificats de cette clé d'alias.
Opérations d'attestation à distance
Le schéma d'attestation est conçu pour garantir que les jobs et données utilisateur ne sont délivrés qu'à des machines qui exécutent la pile de démarrage prévue, tout en permettant l'automatisation à grande échelle de la maintenance du parc pour résoudre les problèmes. Le service de planification de jobs, qui est hébergé dans notre cloud interne, peut interroger la collection de RTM de la machine et comparer les mesures certifiées résultantes à une stratégie unique, propre à cette machine. Le planificateur n'envoie les jobs et données utilisateur à une machine que si les mesures certifiées sont conformes à la stratégie de la machine.
L'attestation à distance inclut les deux opérations suivantes :
La génération de la stratégie d'attestation, qui a lieu chaque fois que le matériel ou les logiciels destinés à une machine sont modifié.
La validation d'attestation, qui se produit à des points définis dans nos flux de gestion des machines. L'un de ces points intervient immédiatement avant la planification d'une tâche sur une machine. La machine n'obtient l'accès aux jobs et aux données utilisateur qu'après une validation d'attestation réussie.
La stratégie d'attestation
Google utilise un document signé lisible par un ordinateur, appelé stratégie, pour décrire le matériel et les logiciels devant s'exécuter dans une machine. Cette stratégie peut être certifiée par la collection de RTM de la machine. Pour chaque RTM, la stratégie inclut les détails suivants :
- Le certificat racine d'identité de confiance pouvant valider les attestations émises par la RTM.
- L'identité matérielle globalement unique, qui identifie la RTM de manière unique.
- L'identité du micrologiciel, qui décrit la version attendue à exécuter par la RTM.
- Les mesures attendues pour chaque étape de démarrage rapportée par la RTM.
- Un identifiant de la RTM, analogue à un nom de ressource Redfish.
- Un identifiant qui associe la RTM à son emplacement physique au sein d'une machine. Cet identifiant est analogue à un nom de ressource Redfish et est utilisé par les systèmes de réparation automatique des machines.
En outre, la stratégie contient également un numéro de série de révocation globalement unique, qui permet d'éviter le rollback non autorisé des stratégies. Le schéma suivant illustre une stratégie.
Le schéma montre les éléments suivants de la stratégie :
- La signature assure l'authentification de la stratégie.
- Le numéro de série de révocation (revocation serial number) indique la fraîcheur de la stratégie pour éviter le rollback.
- Les valeurs de RTM attendues (RTM expectations) énumèrent les détails pour chaque RTM de la machine.
Les sections suivantes décrivent ces éléments plus en détail.
Assemblage de la stratégie
Lorsque le matériel d'une machine est assemblé ou réparé, un modèle matériel est créé qui définit toutes les valeurs de RTM attendues sur cette machine. Notre plan de contrôle permet de s'assurer que ces informations restent à jour lors d'événements tels que des réparations impliquant des échanges de pièces ou des mises à niveau matérielles.
En outre, le plan de contrôle conserve un ensemble d’attentes concernant les logiciels destinés à être installés sur une machine, ainsi que des attentes définissant quelles RTM doivent mesurer quels logiciels. Le plan de contrôle utilise ces attentes, ainsi que le modèle matériel, pour générer une stratégie d'attestation signée et révocable qui décrit l'état attendu de la machine.
La stratégie signée est ensuite écrite dans l'espace de stockage persistant sur la machine qu'elle décrit. Cette approche permet de réduire le nombre de dépendances réseau et de services nécessaires à l'outil de vérification distant lors de l'attestation d'une machine. Plutôt que d'interroger une base de données pour obtenir la stratégie, l'outil de vérification peut récupérer la stratégie à partir de la machine elle-même. Cette approche est une caractéristique de conception importante, car les planificateurs de jobs ont des exigences strictes en matières de SLO et doivent rester hautement disponibles. La réduction des dépendances réseau de ces machines vis-à-vis d'autres services contribue à réduire le risque d'interruption. Le schéma suivant illustre ce flux d'événements.
Le schéma décrit les étapes suivantes réalisées par le plan de contrôle lors du processus d'assemblage de la stratégie :
- Il dérive la stratégie d'attestation à partir de l'attribution des packages logiciels et du modèle matériel de la machine.
- Il signe la stratégie.
- Il stocke la stratégie sur la machine du centre de données.
Révocation de la stratégie
L'intent matériel et logiciel d'une machine donnée évolue au fil du temps. Lorsque l'intent change, les anciennes stratégies doivent être révoquées. Chaque stratégie d'attestation signée comprend un numéro de série de révocation unique. Les outils de vérification obtiennent la clé publique appropriée pour authentifier une stratégie signée, ainsi que la liste de révocation de certificats appropriée pour s'assurer que la stratégie est toujours valide.
L'interrogation interactive d'un serveur de clés ou d'une base de données de révocation affecte la disponibilité des planificateurs de jobs. À la place, Google utilise un modèle asynchrone. L'ensemble des clés publiques utilisées pour authentifier les stratégies d'attestation signées est intégré à l'image du système d'exploitation de base de chaque machine. La LRC est envoyée de manière asynchrone à l'aide du même système de déploiement de révocations centralisé que celui utilisé par Google pour les autres types d'identifiants. Ce système est déjà conçu pour fonctionner de manière fiable dans des conditions normales, et permet d'effectuer des déploiements d'urgence rapides dans des conditions de gestion des incidents.
En utilisant des clés publiques de validation et des fichiers LRC stockés localement sur l'ordinateur de l'outil de vérification, les vérificateurs peuvent valider les instructions d'attestation de machines distantes sans qu'aucun service externe n'intervienne dans le chemin critique.
Récupérer les stratégies d'attestation et valider les mesures
Le processus d'attestation à distance d'une machine comprend les étapes suivantes :
- Récupérer et valider la stratégie d'attestation
- Obtenir les mesures certifiées à partir des RTM de la machine
- Évaluer les mesures certifiées par rapport à la stratégie
Le diagramme et les sections suivants décrivent plus en détail ces étapes.
Récupérer et valider la stratégie d'attestation
L'outil de vérification distant récupère la stratégie d'attestation signée pour la machine. Comme indiqué dans la section Assemblage de la stratégie, pour des raisons de disponibilité, la stratégie est stockée en tant que document signé sur la machine cible.
Pour vérifier que la stratégie renvoyée est authentique, l'outil de vérification distant consulte sa copie locale de la LRC appropriée. Cette action permet de s'assurer que la stratégie récupérée présente une signature cryptographique réalisée par une entité de confiance et qu'elle n'a pas été révoquée.
Obtenir les mesures certifiées
L'outil de vérification distant interroge la machine en demandant des mesures provenant de chaque RTM. L'outil de vérification garantit la fraîcheur en incluant des nonces cryptographiques dans ces requêtes. Une entité sur machine, telle qu'un contrôleur de gestion de baseboard (BMC), achemine chaque requête vers sa RTM respective, rassemble les réponses signées et les renvoie à l'outil de vérification distant. Cette entité sur machine n'est pas privilégiée du point de vue de l'attestation, car elle sert uniquement à transporter les mesures signées des RTM.
Google utilise des API internes pour attester ces mesures. Nous contribuons également aux améliorations apportées à Redfish pour permettre aux outils de vérification hors machine d'interroger un BMC pour obtenir les mesures d'une RTM à l'aide de SPDM. Le routage interne de la machine est effectué via des protocoles et des canaux spécifiques à la mise en œuvre, y compris les éléments suivants :
- Redfish sur le sous-réseau
- IPMI (Intelligent Platform Management Interface)
- Protocole MCTP (Management Component Transport Protocol) sur i2c/i3c
- PCIe
- Liaison SPI (Serial Peripheral Interface)
- USB
Évaluer les mesures certifiées
L'outil de vérification distant de Google valide les signatures émises par chaque RTM, garantissant qu'elles correspondent bien à l'identité incluse pour la RTM dans la stratégie d'attestation de la machine. Les identités matérielles et de micrologiciel qui figurent dans la chaîne de certificats de la RTM sont validées par rapport à la stratégie, garantissant ainsi que l'instance de chaque RTM est correcte et que le micrologiciel qu'elle exécute est également correct. Pour garantir la fraîcheur, le nonce cryptographique signé est vérifié. Enfin, les mesures certifiées sont évaluées pour s'assurer qu'elles correspondent aux attentes de la stratégie pour cet appareil.
Réagir aux résultats de l'attestation à distance
Une fois l'attestation effectuée, les résultats doivent être utilisés pour déterminer le sort de la machine objet de la procédure. Comme le montre le diagramme, il y a deux résultats possibles : si l'attestation réussit, la machine reçoit des identifiants de tâche et des données utilisateur ; si l'attestation échoue, des alertes sont envoyées à l'infrastructure de réparation.
Les sections suivantes fournissent plus d'informations sur ces processus.
Échec de l'attestation
Si l'attestation d'une machine échoue, Google ne l'utilise pas pour traiter des jobs client. À la place, une alerte est envoyée à l'infrastructure de réparation, qui tente de réimager automatiquement la machine. Bien que les échecs d'attestation puissent découler d'intentions malveillantes, la plupart d'entre eux sont dus à des bugs lors des déploiements logiciels. Par conséquent, les déploiements présentant une hausse des défaillances d'attestation sont arrêtés automatiquement pour éviter que davantage de machines ne fassent l'objet d'un échec d'attestation. En pareil cas, une alerte est envoyée aux ingénieurs SRE. Pour les machines qui ne sont pas corrigées par une reconfiguration automatique, le déploiement est annulé ou un logiciel corrigé est déployé. Une machine n'est pas utilisée pour traiter des jobs client tant qu'elle n'obtient pas d'attestation à distance qui soit réussie.
Attestation réussie
Si l'attestation à distance d'une machine réussit, Google utilise la machine pour traiter des jobs de production tels que des VM pour les clients Google Cloud ou le traitement d'images pour Google Photos. Google exige que les actions de job importantes impliquant des services en réseau soient conditionnées par des identifiants de tâche LOAS éphémères. Ces identifiants sont accordés via une connexion sécurisée après un défi d'attestation ayant réussi et fournissent les privilèges requis par le job. Pour en savoir plus sur ces identifiants, consultez la section consacrée à Application Layer Transport Security.
La qualité de l'attestation logicielle dépend de l'infrastructure qui compile ce logiciel. Pour nous assurer que les artefacts résultants reflètent fidèlement notre intention, nous avons considérablement investi dans l'intégrité de notre pipeline de compilation. Pour en savoir plus sur la norme proposée par Google pour gérer l'intégrité et l'authenticité de la chaîne d'approvisionnement logicielle, consultez la section Intégrité de la chaîne d'approvisionnement logicielle.
Étapes suivantes
Découvrez comment BeyondProd aide les machines des centres de données de Google à établir des connexions sécurisées.