Ce contenu a été mis à jour pour la dernière fois en septembre 2024, et correspond à l'état des connaissances à sa date de rédaction. Il est possible que les règles et les systèmes de sécurité de Google changent par la suite, car nous améliorons continuellement la protection de nos clients.
L'architecture de sécurité matérielle Titanium sert de base aux services de Google et sous-tend de nombreuses mesures de sécurité dans l'infrastructure Google. Le matériel Titanium inclut des microcontrôleurs de sécurité, des adaptateurs matériels et des processeurs de déchargement qui ont été développés spécifiquement pour faire face à des vecteurs d'attaque spécifiques pour l'infrastructure Google.
Le matériel Titanium est la dernière avancée en matière de sécurité de l'infrastructure complète et en constante évolution de Google. Il contribue à protéger l'intégrité, la confidentialité et la disponibilité des données utilisateur. Le matériel Titanium s'appuie sur des infrastructures telles que les cartes de déchargement matériel cryptographique qui fournissent un chiffrement en transit et des microservices internes qui fournissent un chiffrement des données au repos.
Ce document décrit comment les composants matériels Titanium fonctionnent ensemble pour créer une architecture de sécurité qui permet de protéger la surface d'attaque physique des systèmes Google et d'atténuer les menaces qui pèsent sur les données client. Ce document décrit également comment le matériel Titanium permet des contrôles de sécurité spécifiques au niveau logiciel, l'évolution de l'architecture au-delà des déchargements matériels cryptographiques initiaux et les menaces réelles que l'architecture de sécurité matérielle Titanium a pour objectif d'atténuer dans la base de déploiement et de clients de Google.
Architecture de sécurité matérielle Titanium
L'architecture de sécurité matérielle Titanium est conçue pour se défendre contre un large éventail de scénarios et d'acteurs malveillants. Le diagramme de l'architecture suivant montre les composants indépendants, mais imbriqués, de Titanium.
L'architecture de sécurité matérielle Titanium comprend les composants suivants :
- Racine de confiance Caliptra pour la mesure (RTM) : permet d'appliquer un périmètre de sécurité pour chaque package de puce. Caliptra RTM fournit une attestation et un ID unique aux services cryptographiques racine.
- Racine de confiance de la puce Titan : s'interpose entre la mémoire flash de démarrage d'une plate-forme et ses principaux périphériques de démarrage tels que le contrôleur de gestion de la carte mère (BMC), le hub de contrôleur de plate-forme (PCH) et le processeur. Les puces Titan fournissent une racine de confiance matérielle physiquement inviolable qui permet d'établir une identité forte. Les puces Titan aident également à autoriser et à révoquer le code pour les machines, les cartes ou les périphériques.
- Processeur de déchargement Titanium (TOPS) : fournit des contrôles cryptographiques pour protéger la confidentialité et l'intégrité des données au repos et des données en transit.
- Cartes mères personnalisées : elles offrent une résilience à grande échelle contre les attaques DoS provenant de logiciels défectueux ou malveillants, ainsi qu'une protection contre les attaques physiques. Dans le schéma, par exemple, le package de puces et le Titan RoT se trouvent sur une carte mère personnalisée distincte de celles de Titanium TOP personnalisées ou d'autres infrastructures.
- Les enclaves d'informatique confidentielle permettent d'appliquer l'isolation par rapport aux droits d'administrateur de Google, d'améliorer l'isolation par rapport aux autres locataires et d'ajouter la vérifiabilité à l'aide de l'attestation. L'attestation peut garantir que l'environnement n'a pas été modifié.
- Services régionaux tolérants aux pannes de backend : ils permettent d'éviter l'escalade des privilèges entre les services, les zones ou à partir d'un accès administratif.
Dans le schéma, Autre infrastructure fait référence aux fabrics réseau et au stockage backend répliqué.
Principes de conception de l'architecture de sécurité matérielle Titanium
Nos composants matériels Titanium et leurs interactions sont développés selon les principes fondamentaux suivants :
Pas de point de défaillance unique : l'architecture Google est conçue pour éviter les points de défaillance uniques, tels que les composants porteurs uniques avec plusieurs responsabilités. La section Créer des systèmes fiables et sécurisés explique pourquoi il est important d'éviter les points de défaillance uniques. Ce principe est appliqué à l'ensemble de notre infrastructure physique, dans toutes les régions et même au niveau du silicium des puces. Cette résilience de notre infrastructure mondiale permet de protéger et de rendre disponibles les données client.
Par exemple, la migration à chaud avec l'informatique confidentielle permet de préserver la mémoire chiffrée sur les machines hôtes compatibles. La migration à chaud permet de s'assurer qu'une VM de longue durée n'est pas un point de défaillance unique en raison d'événements de maintenance ou de la réponse aux failles de sécurité.
Le périmètre est le package de puce : comme un système de serveur contient plusieurs systèmes sur puce interconnectés et distincts, notre architecture ne fait pas confiance à tous les connecteurs, tissus, assemblages de circuits imprimés (PCBA), traces de PCBA et câbles. Bien que la séparation des composants soit utile pour la modularité, elle peut également devenir une faiblesse lorsqu'elle offre aux pirates informatiques des cibles bien définies à partir desquelles espionner les données en texte brut. Les données contenues dans le package de puce sont chiffrées et authentifiées par des éléments cryptographiques privés dans le package.
Déplacer le périmètre dans la puce elle-même permet de minimiser la confiance implicite. Ce principe vise à contrer les menaces contre la confidentialité des données qui se produisent à mesure que les conditions de livraison des centres de données deviennent de plus en plus diverses. Par exemple, la définition du périmètre dans le package de puce permet de lutter contre les menaces provenant d'opérations matérielles malveillantes.
Zéro trust et compartimentation des risques : les contrôles multipartites sur les actions administratives permettent de s'assurer qu'aucun compte de personnel (ou compte de personnel piraté) ne peut, à lui seul, provoquer les menaces abordées dans ce document. L'architecture sépare les services en couches et en zones pour compartimenter et contenir les risques. Même avec les enclaves, qui sont généralement ancrées dans le matériel, l'architecture tient compte de la découverte de failles matérielles et de la nécessité de les corriger pendant que les composants restent en fonctionnement.
Par exemple, si un pirate informatique compromet malicieusement le comportement d'un chip à l'intérieur d'un système actif qui exécute des charges de travail client dans nos centres de données, l'architecture est conçue pour identifier et isoler ce chip compromis. Cette machine peut ensuite être mise hors service. Même si la machine n'est pas mise hors service, le pirate informatique doit franchir des limites de confiance supplémentaires et compromettre plusieurs identifiants pour se déplacer latéralement et gagner de l'influence sur d'autres systèmes, utilisateurs ou régions.
Les domaines de défaillance indépendants et les technologies d'isolation permettent de limiter la zone touchée par un piratage. Ces domaines et technologies ajoutent des points de contrôle naturels pour la détection et limitent la complexité supplémentaire à introduire.
Pour en savoir plus sur notre implémentation zéro confiance, consultez la section BeyondProd.
Sécurité transparente : Google investit dans de nombreuses initiatives de transparence, y compris l'Open Source, la divulgation responsable des recherches et des résultats, et les partenariats avec l'écosystème des fabricants de matériel. L'infrastructure mondiale de Google applique le principe de Kerckhoffs, qui stipule qu'un cryptosystème doit être sécurisé, même si tout ce qui concerne le système, à l'exception de la clé, est public.
Par exemple, nous contribuons à des projets Open Source et les utilisons dans nos conceptions de matériel et de logiciels de sécurité. Le tableau suivant décrit certains des projets Open Source auxquels nous contribuons et que nous utilisons.
Projet Open Source Description Composant Titanium Utilisé dans les bibliothèques de chiffrement FIPS 140-3 de niveau 1
BoringSSL
Utilisé dans les racines de confiance (RoT) au niveau de la puce
Caliptra RTM
Utilisé dans le système d'exploitation temps réel pour une puce dans une architecture système
Puces Titan
Utilisé pour le fuzzing du noyau guidé par la couverture
Distributions de VM hôte ring0 et utilisateur
Utilisé dans les bibliothèques de chiffrement FIPS 140-3 de niveau 1
Processeur de déchargement Titanium
Défense physique et logique en profondeur : Google s'appuie sur la sécurité physique des centres de données pour protéger ses investissements et ses systèmes. Ces contrôles de sécurité constituent une première couche de défense. Nous investissons donc délibérément dans des contrôles logiques supplémentaires pour renforcer nos systèmes contre les menaces physiques. Titanium s'ajoute à notre défense en profondeur en ajoutant une compartimentation dans notre matériel qui offre des défenses supplémentaires contre les menaces spécifiques à l'infrastructure.
Par exemple, nos centres de données sont équipés de détecteurs de métaux capables de détecter avec précision les tentatives d'exfiltration de supports de stockage. Toutefois, notre stratégie de chiffrement des données au repos est délibérément conçue pour ne pas dépendre de la conservation de supports physiques. Ces contrôles logiques et physiques sont des couches indépendantes et complémentaires.
Nos contrôles de sécurité physiques et logiques combinés nous aident à rester vigilants contre les menaces internes et à protéger la confidentialité des données de nos utilisateurs.
Avantages en termes de sécurité des composants architecturaux de Titanium
Le tableau suivant met en évidence certains avantages importants en termes de sécurité obtenus grâce aux composants de l'architecture de sécurité Titanium, à la fois au niveau matériel et logiciel. Ces avantages en termes de sécurité sont décrits plus en détail dans les sections suivantes.
| Avantages de sécurité | Composant d'architecture |
|---|---|
Périmètre de confiance au niveau de la puce sur des systèmes sur puce (SoC), tels que des processeurs ou des GPU |
Caliptra RTM |
Vérification au niveau de la puce |
Caliptra RTM |
Identité cryptographique au niveau matériel |
Caliptra RTM, Titan RoT |
Vérification que les binaires attendus sont en cours d'exécution |
Caliptra RTM, Titan RoT |
Atténuation des menaces persistantes lors des démarrages |
Caliptra RTM, Titan RoT |
Protection de la confidentialité des données au repos et en transit |
TOP pour la cryptographie |
Décharger la protection au niveau du processeur (au-delà d'une carte physique) |
TOP pour la cryptographie |
Conception sécurisée, résistance aux attaques physiques et capacités de résilience permettant la récupération complète du micrologiciel du système à partir d'un seul module de sécurité Titan |
Cartes mères personnalisées |
Des cartes conçues sur mesure avec uniquement les connecteurs essentiels, ce qui permet d'éviter les tentatives de falsification physique |
Cartes mères personnalisées |
Isolement des charges de travail cryptographiques par rapport au logiciel système à l'échelle de la machine et à l'accès administratif humain |
Enclaves d'informatique confidentielle |
Résistance à la falsification grâce au chiffrement DRAM (pour activer le chiffrement des données en cours d'utilisation) |
Enclaves d'informatique confidentielle |
Zone affectée et cloisonnement minimisés pour un pirate informatique disposant d'un accès local |
Services régionalisés de backend tolérants aux pannes |
Compartimentation à plusieurs niveaux |
Services régionalisés de backend tolérants aux pannes |
Racine de confiance Caliptra pour la mesure
La RTM Caliptra contribue à renforcer la confiance et la transparence pour le micrologiciel de notre écosystème qui s'exécute sur des systèmes sur puce (SoC), tels que des processeurs, des GPU et des TPU.
Caliptra RTM présente les avantages suivants :
- Fournit un service cryptographique racine : la RTM Caliptra permet de détecter le code et la configuration critiques corrompus grâce à une vérification de l'intégrité cryptographique de bout en bout. La RTM Caliptra peut mesurer de manière cryptographique son code et sa configuration, signer ces mesures avec une clé d'attestation unique et protégée par le matériel, et signaler les mesures qui attestent de l'authenticité et de l'intégrité de l'appareil. La RTM Caliptra fournit une identité cryptographique de l'appareil et un ensemble de mesures d'intégrité du micrologiciel et de la configuration pour la carte mère.
- Atténue la sécurité de la chaîne d'approvisionnement physique : la RTM Caliptra permet de s'assurer que le matériel est authentique et qu'il exécute le micrologiciel et les logiciels prévus. En combinaison avec la sécurité de la chaîne d'approvisionnement logicielle, Caliptra RTM permet au système de vérifier l'authenticité et l'intégrité du micrologiciel et des logiciels, qu'ils aient été créés par Google ou par un tiers. Ce processus de validation permet à Caliptra RTM de maintenir l'authenticité et l'intégrité des mises à jour autorisées, et de s'assurer que les configurations restent conformes à ce qui est prévu et sont attestées.
- Protection contre les intrusions physiques nécessitant un accès direct au matériel en cours d'exécution : comme la RTM Caliptra est intégrée aux couches de silicium de la puce, un interposeur PCBA ou une puce malveillante qui tente de fournir le mauvais micrologiciel à un circuit intégré spécifique à une application (ASIC) ne peut pas attaquer le RoT. Par exemple, les pirates informatiques peuvent contourner les capacités de détection d'une RoT externe en altérant le bus SPI à vitesse relativement faible. Toutefois, une RoT intégrée à un SoC ou un ASIC devient plus difficile à compromettre pour un pirate informatique.
Racine de confiance de la puce Titan
Titan est conçu pour maintenir l'identité de l'appareil de manière cryptographique, se défendre contre les mises à jour logicielles malveillantes et appliquer l'authenticité du code à l'aide de la révocation.
Une identité cryptographique forte pour les appareils permet de s'assurer que le parc est exclusivement composé de machines validées qui exécutent les binaires attendus et peuvent identifier et authentifier les accès légitimes. L'accès légitime est ancré au niveau matériel.
Par défaut, les machines de production utilisent le démarrage sécurisé pour s'assurer que seuls les logiciels authentifiés peuvent s'exécuter. Le démarrage sécurisé vérifie la signature numérique de tous les composants de démarrage et n'autorise pas une machine à participer à l'environnement de production si l'authentification échoue.
En tant que contrôle préventif supplémentaire, la révocation du code machine empêche l'application de modifications logicielles qui ne sont plus autorisées. La fonctionnalité de révocation des puces Titan permet d'atténuer non seulement les attaques malveillantes (par exemple, les attaques par rollback ou par relecture), mais aussi les bugs de stabilité ou de résilience non malveillants (par exemple, en empêchant la réinstallation accidentelle d'un ancien micrologiciel bogué).
Pour en savoir plus, consultez la page Comment Google applique l'intégrité du démarrage sur les machines de production.
Processeurs de déchargement Titanium pour la cryptographie
Les processeurs de déchargement Titanium (TOP) pour la cryptographie contribuent à la sécurité lors du déchargement des E/S. Ces TOP sont protégés par Titan ou Caliptra RTM. Les TOP déploient un chiffrement authentifié généralisé des données en transit et des données au repos à faible coût. Le chiffrement authentifié signifie que les données client bénéficient d'une assurance cryptographique de confidentialité et d'intégrité. Comme les bibliothèques de chiffrement gèrent la cryptographie, elles suppriment les droits d'accès de nombreux composants système. Les TOP permettent d'améliorer les propriétés architecturales, comme la disponibilité, tout en minimisant le risque de perte de confidentialité des données.
Cartes mères personnalisées
Les cartes mères personnalisées de l'infrastructure Google sont conçues pour fournir une provenance matérielle. Les cartes mères sont compatibles avec l'attestation à plusieurs niveaux. La conception de la carte mère protège les données client, même dans le cas très improbable où un pirate informatique attacherait physiquement un appareil malveillant à une machine. Les conceptions de cartes mères Titanium permettent de déployer de manière fiable des mécanismes de renforcement supplémentaires, tels que des ports de débogage non utilisés, des consoles série en lecture seule, des intrusions de connecteurs de bus et des signaux d'extrusion.
TLS et ALTS sont les seuls protocoles acceptés exposés par notre pile réseau BMC lorsqu'une machine est allumée. Pour les machines qui utilisent une conception COTS tierce, comme nos instances X4, les TOPs utilisent un proxy pour tout trafic de gestion propre à cette conception tierce. Le transit par proxy du trafic de gestion signifie que notre infrastructure ne dépend pas de conceptions tierces pour l'authentification, l'autorisation, la sécurité du transport ou la sécurité du réseau.
Les cartes mères personnalisées Titanium sont conçues pour disposer de mécanismes de récupération et de sauvegarde intégrés afin de garantir la disponibilité et la récupérabilité. Ils peuvent se restaurer eux-mêmes en cas de plantage ou de corruption du micrologiciel. Nos dernières conceptions permettent de reconstruire l'intégralité de la machine à partir d'une seule RoT Titan fonctionnelle. Ces cartes mères utilisent des composants d'alimentation et de réinitialisation dédiés aux fonctionnalités pour garantir l'indépendance électrique des RoT Titan par rapport au reste de la plate-forme, et pour protéger leur contrôle sur les charges utiles du micrologiciel de la plate-forme à des fins d'authentification et de récupération.
Enclaves d'informatique confidentielle
L'informatique confidentielle crée un environnement d'exécution sécurisé (TEE) ou une enclave pour isoler les charges de travail sensibles des clients de l'accès administratif de Google. Lorsque les données sont traitées par le CPU ou le GPU, l'informatique confidentielle fournit un contrôle préventif technique grâce à l'isolation du calcul et au chiffrement en mémoire. L'informatique confidentielle permet de s'assurer que même un hyperviseur malveillant ne peut pas accéder à une VM. Pour les charges de travail des clients, l'informatique confidentielle fournit une couche d'isolation de la confidentialité des données contre la possibilité d'un accès involontaire du personnel Google ou d'actions défectueuses du logiciel système automatisé à grande échelle.
Le mode confidentiel pour Hyperdisk Balanced est un exemple de sécurité avancée activée par l'architecture Titanium. Le mode confidentiel pour Hyperdisk Balanced combine le déchargement du stockage de blocs basé sur Titanium, l'informatique confidentielle et le HSM cloud pour créer un TEE basé sur le matériel. En d'autres termes, le mode confidentiel pour Hyperdisk Balanced est une offre Hyperdisk Balanced. Le mode confidentiel pour Hyperdisk Balanced isole l'infrastructure afin que les clés sensibles soient traitées exclusivement dans un TEE basé sur le matériel. Pour en savoir plus sur l'examen par un tiers des opérations de chiffrement, consultez le rapport public sur le mode confidentiel pour Hyperdisk : analyse de la protection des clés de chiffrement des données.
Services régionalisés de backend tolérants aux pannes
Les services régionaux tolérants aux pannes du backend permettent de minimiser la zone affectée par un pirate informatique ayant un accès local. L'infrastructure Google est conçue pour compartimenter les services, les systèmes et les zones contre les mouvements latéraux d'utilisateurs internes disposant de privilèges ou de services corrompus.
Nous nous efforçons d'inclure des informations régionales dans un ensemble de plus en plus large de nos systèmes internes de gestion de l'authentification et des accès. Les informations régionales renforcent l'isolation cryptographique. Ainsi, un pirate informatique qui obtient un accès local doit compromettre plusieurs identifiants de différents services d'infrastructure pour continuer à se déplacer latéralement.
Si une attaque déclenche un contrôle préventif qui retirerait une machine de production de l'environnement (par exemple, en provoquant l'arrêt du système), notre infrastructure de backend tolérante aux pannes permet de garantir la disponibilité continue des données et des services client sur les machines à proximité. Pour en savoir plus sur nos contrôles d'infrastructure, consultez les sections BeyondProd et Comment Google protège ses services de production.
Vecteurs d'attaque pour l'infrastructure Google Cloud
Cette section décrit les menaces physiques et logiques spécifiques qui composent une partie de la surface d'attaque de Google Cloud. L'architecture de sécurité matérielle Titanium est spécifiquement conçue pour faire face à un ensemble unique de menaces qui pèsent sur l'infrastructure Google et les données utilisateur que nous stockons.
Menaces liées à l'infrastructure
L'architecture Titanium est conçue pour se défendre contre plusieurs catégories de menaces :
- Employé malveillant ayant un accès physique : notre personnel a besoin d'accéder aux appareils physiques dans les centres de données pour déployer, entretenir et réparer le matériel. Cet accès représente un vecteur d'attaque potentiel, car le personnel ou les sous-traitants malveillants ont une raison commerciale légitime de réparer physiquement certaines machines de nos centres de données.
Employé malveillant disposant d'un accès logique : comme pour l'accès physique au centre de données, le personnel est tenu de développer, de gérer, de tester, de déboguer, d'optimiser et d'assurer l'assistance pour plusieurs niveaux de la pile logicielle Google. Ce personnel inclut les développeurs, les ingénieurs SRE et les ingénieurs cloud en contact avec les clients.
Pour en savoir plus sur nos défenses contre cette menace, consultez Comment Google protège ses services de production.
Attaquant externe disposant d'un accès logique : les attaquants externes peuvent s'introduire dans un environnement Google Cloud et tenter de se déplacer latéralement vers d'autres machines pour accéder à des données sensibles. Une tactique courante utilisée par les pirates informatiques externes consiste à commencer par compromettre le compte d'un employé ou d'un sous-traitant légitime.
Le diagramme suivant montre quelle partie de l'environnement cloud est la plus vulnérable à ces menaces.
Surface d'attaque des serveurs de centres de données
Le tableau suivant décrit les surfaces d'attaque qui sont des aspects typiques des serveurs de centres de données. L'architecture de sécurité matérielle Titanium est conçue pour offrir une protection efficace contre ces menaces.
| Pirate informatique | Cible | Surface d'attaque | Risque |
|---|---|---|---|
Initié malveillant avec accès physique |
Supports de stockage (SSD, HDD ou lecteurs de démarrage) |
Disques physiques et connecteurs |
Cette attaque pourrait permettre de voler un disque et de tenter d'y accéder avec les outils de l'attaquant. |
DIMM |
Connecteurs de mémoire physique |
Cette attaque pourrait geler le DIMM, le sortir du centre de données et tenter d'accéder aux données qu'il contient à l'aide des propres outils de l'attaquant. Cette menace est parfois appelée attaque par démarrage à froid. |
|
Serveur |
Connecteurs USB ou PCIe |
Cette attaque pourrait connecter du matériel malveillant au serveur. À l'aide du matériel malveillant, le pirate informatique peut tenter d'exécuter du code ou d'exfiltrer des données résidentes. |
|
Carte mère |
Joint Test Access Group (JTAG) eXtended Debug Port (XDP) |
Cette attaque pourrait connecter un outil de débogage matériel pour exécuter du code ou accéder aux données traitées sur le processeur. |
|
Réseau |
Câbles Ethernet |
Cette attaque peut exploiter un câble Ethernet pour accéder à toutes les données transférées entre les appareils. Tout trafic en texte clair peut alors être observé. |
|
Carte mère |
Micrologiciel |
Cette attaque pourrait introduire un micrologiciel malveillant persistant. Ce micrologiciel peut être préinstallé par un fabricant compromis, intercepté en transit ou mis à jour par une personne interne. Cette menace peut entraîner la pré-piratage du matériel avec des rootkits qui fournissent un accès backdoor au serveur. |
|
Initié malveillant avec accès logique |
Charge de travail de calcul (par exemple, les VM) |
Points de connexion |
Cette attaque peut utiliser les identifiants d'un employé pour accéder directement aux VM ou aux hôtes, ainsi qu'aux données qu'ils contiennent. |
Routeur de tissu |
Accès physique ou administratif |
Cette attaque pourrait permettre d'obtenir le contrôle racine d'un routeur de structure pour écouter tout le trafic et exfiltrer ou altérer toutes les données en texte clair en transit sur la structure. |
|
Carte mère |
Micrologiciel |
Cette attaque pourrait envoyer des images de micrologiciel défectueuses aux cartes mères, les rendant définitivement inutilisables et les données irrécupérables. Un pirate informatique pourrait envoyer un micrologiciel vulnérable connu aux machines pour reprendre le contrôle à l'aide d'exploits permettant l'exécution de code à distance. |
|
Pirate informatique externe avec accès logique |
Serveur |
VM |
Cette attaque pourrait lancer des schémas d'attaque par canal secondaire publics sur les VM. Ces attaques peuvent entraîner une fuite de données provenant d'instances exécutées sur le même matériel ou depuis le logiciel système hôte. |
Disques SSD |
VM |
Cette attaque pourrait utiliser un accès direct aux SSD PCIe pour tenter d'inférer des données de colocataires. |
|
Mémoire |
VM |
Ce vecteur d'attaque pourrait utiliser des canaux auxiliaires pour rechercher des clés de chiffrement intéressantes dans la mémoire. |
|
Serveur |
VM sur bare metal |
Ce vecteur d'attaque pourrait utiliser des instances Bare Metal pour analyser tous les périphériques afin de trouver un composant vulnérable qui lui permettrait de persister dans la machine et d'attaquer les locataires suivants. |
Mappage des composants matériels Titanium aux menaces
L'architecture de sécurité matérielle Titanium utilise une approche multicouche pour aider à faire face à des menaces d'infrastructure spécifiques et à éviter les points de défaillance uniques. Ces menaces peuvent provenir d'erreurs ou d'acteurs malveillants. Les menaces couvrent les opérations matérielles et peuvent exploiter les failles des serveurs, des réseaux et du plan de contrôle. Il n'existe aucune solution unique permettant de contrer tous ces vecteurs d'attaque, mais les fonctionnalités combinées de Titanium aident à protéger les données de nos utilisateurs et nos instances de cloud computing.
Scénario : opérations matérielles non autorisées
Les opérations matérielles malveillantes constituent une menace pour la sécurité des données, car elles peuvent entraîner l'exfiltration de données à partir de centres de données, ainsi que la modification du matériel et du micrologiciel. L'architecture de sécurité matérielle Titanium de Google permet de se protéger contre ces menaces en utilisant diverses mesures de sécurité, y compris des RoT cryptographiques, des cartes mères personnalisées et des processeurs d'E/S. Ces composants fonctionnent ensemble pour fournir une défense multicouche résistante à un large éventail d'attaques.
Le tableau suivant décrit certaines menaces liées au matériel malveillant et la façon dont l'architecture Titanium peut les atténuer.
| Menace | Atténuation Titanium |
|---|---|
Un pirate informatique exfiltre des lecteurs de données individuels des centres de données pour accéder aux données qu'ils contiennent. |
Les clés de chiffrement des données au repos pour les produits et services de stockage ne sont jamais stockées de manière persistante sur les machines auxquelles les supports de stockage sont associés. Les fonctionnalités d'auto-chiffrement intégrées aux supports de stockage sont également activées pour la défense en profondeur et utilisent des clés qui ne sont jamais stockées de manière permanente sur le support lui-même. Les RTM Caliptra permettent à Google d'inclure l'identité matérielle de la racine de confiance et l'intégrité du micrologiciel parmi les conditions d'autorisation requises pour libérer les clés d'un service de gestion de clés vers des instances de service de stockage. Les machines qui sont configurées de manière malveillante avec un micrologiciel non prévu ne peuvent pas accéder aux clés nécessaires pour déchiffrer les données stockées. Les racines d'attestation (RoT) intégrées aux packages de puce ancrent les identités cryptographiques pertinentes dans le package de puce. Les interposeurs à fonction unique constituent la partie principale de la sécurité de notre plan de données et chiffrent les données à chaque étape de traitement. Les TOP offrent les avantages suivants :
Des solutions logicielles éprouvées comme dm-crypt sont utilisées pour les lecteurs moins performants où la réduction de la surface d'attaque est primordiale, comme dans certains cas d'utilisation de lecteurs de démarrage. |
Un pirate informatique intercepte un câble réseau et lit les octets sur le câble ou la fibre. |
Les TOP chiffrent les données en transit, ce qui empêche les menaces d'espionner les données sensibles sur le réseau. Nos cartes d'interface réseau utilisent la norme de déchargement matériel PSP. Cette norme offre un chiffrement économique avec une diminution minimale des performances. Ces implémentations sont conformes à la norme FIPS. Les données client sont chiffrées lorsqu'elles transitent par des commutateurs ToR (Top of Rack) ou de réseau. Certaines infrastructures de machine learning utilisent des mécanismes de sécurité de transport propriétaires. |
Un pirate informatique remplace les puces flash contenant du code mutable dans le centre de données ou la chaîne d'approvisionnement pour exécuter du code malveillant sur les serveurs. |
Les puces Titan sont conçues pour rejeter l'attaque et ne pas donner accès aux identifiants stockés à l'intérieur. Même si un pirate informatique réécrit le contenu des puces flash non volatiles, la RoT Titan signale de manière sécurisée une mesure du code au plan de contrôle de Google, qui est conçu pour bloquer l'appareil. Google révoque régulièrement le code obsolète ou connu pour être vulnérable à l'échelle mondiale dans son parc informatique à l'aide des puces Titan. |
Un pirate informatique insère des dispositifs adverses dans les interfaces physiques des serveurs ou des cartes de centres de données pour exécuter du code malveillant ou exfiltrer des données. |
Les conceptions de cartes mères personnalisées suppriment les interfaces utilisées pour insérer des dispositifs adverses. Des configurations Input-Output Memory Management Unit (IOMMU) sont en place pour empêcher les screamers PCIe dans tous nos micrologiciels. (Les screamers PCIe sont conçus pour lire et écrire des paquets arbitraires sur le fabric PCIe.) À mesure que le secteur arrive à maturité, nous complétons cette protection avec PCI IDE pour atténuer davantage les interposeurs PCI plus sophistiqués. ALTS et TLS sont les seules connexions réseau d'authentification et d'autorisation acceptées pour les fonctions de contrôle et de gestion sur les TOP et les BMC. Les RTM Caliptra bloquent tout micrologiciel non approuvé. Nos périphériques de confiance attestent de l'identité de leur matériel et de l'intégrité de leur code auprès de notre plan de contrôle. Aucun serveur n'est admis en production si l'enregistrement de l'attestation ne correspond pas à l'intention du matériel et du logiciel. |
Un pirate informatique utilise une attaque par redémarrage à froid dans le centre de données pour accéder aux données de la RAM. |
Le chiffrement en mémoire de l'informatique confidentielle protège toutes les données sensibles ou clés de chiffrement dans la RAM. Le chiffrement DRAM est également activé sur les machines déployées sans informatique confidentielle dans les centres de données périphériques à faible niveau d'assurance. |
Scénario : Exploitation de serveurs ou de réseaux par des utilisateurs malveillants
Les pirates informatiques peuvent utiliser le cloud public pour héberger leurs charges de travail malveillantes sur notre infrastructure partagée et déposer des données dans nos services publics. Des pirates externes, qu'il s'agisse de personnes isolées ou d'États-nations, peuvent également tenter d'obtenir un accès privilégié à distance.
Pour atténuer ces actions, l'architecture de sécurité matérielle Titanium utilise des puces Titan et Caliptra RTM pour provisionner les identifiants d'exécution de manière sécurisée et limiter les privilèges sur le matériel et les systèmes d'exploitation. L'informatique confidentielle permet de protéger la mémoire système contre toute manipulation, qu'elle soit physique ou par le biais d'attaques par hyperviseur. Les puces Titan rejettent ou détectent les mises à niveau logicielles non autorisées.
Le tableau suivant décrit certaines des menaces d'exploitation des serveurs et du réseau, et explique comment l'architecture Titanium peut les atténuer.
| Menace | Atténuation Titanium |
|---|---|
Un pirate informatique exploite une faille pour sortir de sa VM et accéder aux données et aux autres VM exécutées sur la même machine. |
Les enclaves d'informatique confidentielle limitent l'exfiltration des données de charge de travail, qu'elles soient en cours de traitement ou au repos. Cette méthode d'atténuation empêche un pirate informatique ayant quitté la VM d'accéder aux données en cours d'utilisation. Les puces Titan et les RTM Caliptra empêchent le pirate informatique d'avoir un accès permanent. Toute tentative d'accès persistant sera probablement détectée, car la configuration de la machine ne correspondra pas à la configuration et au code de ce serveur. Cette correspondance est requise avant que la machine puisse héberger des charges de travail de production après un redémarrage. |
Un pirate informatique lance des modèles d'attaque par canal auxiliaire publics sur des VM. |
Notre système de gestion de parc, qui utilise des puces Titan, peut révoquer les logiciels connus pour être vulnérables. La révocation peut bloquer toute attaque ultérieure ciblant ces failles connues. Les mesures d'intégrité basées sur Titan offrent également une grande confiance dans le déploiement des mesures d'atténuation, qui peuvent devoir être déployées en urgence, sur les machines cibles. Nous renforçons cette approche en restant à la pointe de l'investigation et de la mitigation des canaux auxiliaires, grâce à des techniques telles que retpoline et la planification du cœur, ainsi qu'à des recherches avancées sur Meltdown, Spectre, Zenbleed, Downfall et d'autres. |
Un pirate informatique utilise un accès direct aux SSD qui fournissent du stockage à plusieurs locataires pour tenter d'inférer les données des colocataires. |
Le chiffrement des données au repos permet de se protéger contre les attaques logiques et physiques à l'aide de divers interposeurs. Pour les ressources qui ne sont pas partagées, les données de chaque locataire sont chiffrées à l'aide de clés différentes, ce qui réduit le risque d'attaques par accès direct contre le SSD. |
Un pirate informatique analyse la mémoire et utilise des canaux auxiliaires pour rechercher des clés de chiffrement de données ou des identifiants. |
Les puces Titan permettent le provisionnement d'identifiants scellés par machine. Même si un pirate informatique obtient un accès root sur une machine, ses identifiants sont liés uniquement à l'identité privée de la puce Titan M locale. |
Un pirate informatique achète des instances bare metal et analyse tous les périphériques pour tenter d'obtenir un accès permanent. |
Les puces Titan rejettent toute mise à niveau logicielle non autorisée, y compris les demandes d'accès persistantes malveillantes. Notre workflow machine confirme positivement les mesures d'intégrité attendues sur un cycle d'alimentation attesté complet du système entre les clients bare metal. |
Scénario : Exploitation de serveurs ou de réseaux par un comportement malveillant du plan de contrôle
Les employés malveillants du plan de contrôle peuvent tenter d'exploiter les systèmes de Google de différentes manières, par exemple en essayant d'obtenir le contrôle racine d'un routeur de structure, en envoyant des images de micrologiciel défectueuses aux cartes mères et en écoutant le trafic réseau. L'architecture de sécurité matérielle Titanium permet de se protéger contre ces menaces en utilisant divers mécanismes, y compris des puces Titan, des RTM Caliptra, des cartes mères personnalisées et des services isolés tolérants aux pannes de backend.
Le tableau suivant décrit certaines menaces liées au plan de contrôle et la façon dont l'architecture Titanium peut les atténuer.
| Menace | Atténuation Titanium |
|---|---|
Un pirate informatique utilise des identifiants internes pour accéder aux VM Compute Engine qui servent de couche de base pour les environnements client. |
Les TOP permettent de s'assurer que les administrateurs n'ont pas accès aux environnements client. Sans accès, le personnel Google ne peut pas utiliser ses identifiants pour accéder à la couche matérielle et logicielle privilégiée qui se trouve sous les VM de nos clients. L'accès des initiés Google aux données client est bloqué, car les données ne sont accessibles que via des API définies. |
Un pirate informatique envoie des images de micrologiciel défectueuses à grande échelle aux cartes mères, ce qui les rend inutilisables de manière permanente. |
Les RoT des puces Titan rejettent toute mise à niveau logicielle non autorisée, y compris les demandes d'accès persistantes malveillantes. Les conceptions de cartes mères personnalisées utilisent un autre réseau de signaux qui interconnecte tous nos RoT aux RoT de la plate-forme. Le RoT de la plate-forme contient le micrologiciel de sauvegarde des appareils critiques. Même si un pirate informatique a rendu le réseau et le PCI inutilisables, le réseau hors bande (OOB) peut réparer le système. |
Un pirate informatique envoie un micrologiciel de production obsolète et vulnérable à des machines pour reprendre le contrôle à l'aide de failles publiques. |
Les puces Titan rejettent les notifications push malveillantes et contribuent à appliquer la révocation du code connu pour être vulnérable. Ils attestent de la version du micrologiciel déployée sur la machine et la refusent au niveau du plan de contrôle. Cette atténuation permet d'empêcher l'exécution de tâches sur une machine défectueuse et déclenche une enquête ou une réparation si nécessaire. |
Un pirate informatique abuse des fonctionnalités de débogage des puces nécessaires à la continuité des activités, qui offrent le niveau d'accès aux données le plus élevé possible dans les systèmes de serveurs. |
La racine de confiance Caliptra pour la mesure (RTM) permet de s'assurer que tous les paramètres qui activent les interfaces de débogage invasives, qu'ils soient connectés logiquement ou par insertion physique directe, sont configurés de manière fiable, mesurés de manière cryptographique et signalés à notre plan de contrôle à l'aide d'un protocole d'attestation. Seules les machines dans l'état prévu peuvent accéder aux charges de travail de production. |
Un pirate informatique prend le contrôle d'un service de backend pour accéder aux environnements client. |
Les services régionalisés tolérants aux pannes de backend sont des infrastructures d'identifiants régionalisées qui n'autorisent pas l'accès humain unilatéral. En plus d'empêcher la connexion des opérateurs aux nœuds de calcul, ils ne peuvent pas non plus se connecter au plan de contrôle pour récupérer le matériel clé. Les enclaves d'informatique confidentielle de l'architecture Titanium isolent nos services d'autorisation et de provisionnement de clés du backend des droits d'administrateur de la machine. Les hiérarchies de clés permettent de protéger les clés de signature et d'autorisation de la plupart des services. Avec les hiérarchies de clés, les clés racines sont des clés sous air gap stockées dans des HSM et des coffres-forts, ou des clés stockées en production par un quorum Paxos de datastores en mémoire. |
Étape suivante
- Consultez la présentation de la conception de sécurité d'infrastructure.
- Implémentez l'informatique confidentielle.