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 contre-mesures de sécurité dans l'infrastructure Google. Le matériel Titanium comprend des microcontrôleurs de sécurité, des adaptateurs matériels et des processeurs de déchargement développés spécifiquement pour traiter des vecteurs d'attaque spécifiques à l'infrastructure Google.
Le matériel en titane est la dernière innovation de la sécurité d'infrastructure complète et en constante évolution de Google. Il permet de protéger l'intégrité, la confidentialité et la disponibilité des données utilisateur. Le matériel Titanium repose sur une infrastructure telle que les cartes de déchargement matériel cryptographique qui fournissent le chiffrement en transit et des microservices internes qui fournissent le chiffrement des données au repos.
Ce document explique 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 pesant sur les données des clients. 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 schéma d'architecture suivant illustre les composants indépendants, mais interconnecté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 identifiant unique aux services cryptographiques racine.
- RoT de la puce Titan : s'interpose entre le flash de démarrage d'une plate-forme et ses principaux appareils 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 résistante à la falsification qui permet d'établir une identité forte. Les puces Titan permettent également d'autoriser et de 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 en transit.
- Carte mère personnalisée : offre une résilience à grande échelle contre les attaques par déni de service 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.
- Enclave de calcul confidentiel : permet d'appliquer l'isolation contre les droits d'administration de Google, d'améliorer l'isolation avec d'autres locataires et d'ajouter une vérifiabilité à l'aide d'une attestation. L'attestation permet de s'assurer que l'environnement n'a pas été modifié.
- Services régionaux tolérants aux pannes pour le backend : permettent d'éviter l'escalade des droits d'accès entre les services, les zones ou l'accès administratif.
Dans le schéma, Autre infrastructure fait référence aux réseaux et à l'espace de stockage répliqué en arrière-plan.
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 :
Aucun 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 s'applique à l'ensemble de notre infrastructure physique, dans toutes les régions, et même au silicium des puces. Cette résilience dans notre infrastructure mondiale permet de garantir la sécurité et la disponibilité des données client.
Par exemple, la migration à chaud avec l'informatique confidentielle permet de conserver 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 réactions à des 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 un point faible lorsqu'elle offre aux adversaires des cibles bien définies à partir desquelles ils peuvent 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.
Risque zéro confiance et cloisonnement : les contrôles multiparties des actions administratives permettent de s'assurer qu'aucun compte personnel (ou compte personnel compromis) ne peut provoquer unilatéralement les menaces décrites dans cet article. L'architecture sépare les services en couches et en zones pour compartimenter et contenir les risques. Même avec des 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 le comportement d'une puce dans 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 cette puce compromise. Cette machine peut ensuite être mise hors service. Même si la machine n'est pas mise hors service, l'attaquant doit contourner des limites de confiance supplémentaires et compromettre plusieurs identifiants pour se déplacer latéralement et étendre son influence sur d'autres systèmes, utilisateurs ou régions.
Les domaines de défaillance et les technologies d'isolation indépendants permettent de limiter la zone affecté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 plusieurs initiatives de transparence, y compris le développement d'une source ouverte, la divulgation responsable de recherches et de résultats, et le partenariat 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 toutes les caractéristiques du système, à l'exception de la clé, sont publiques.
Par exemple, nous contribuons à des projets Open Source et les utilisons dans nos conceptions de matériel et 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 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 utilisateur et de ring0 hôte
Utilisé dans les bibliothèques de chiffrement FIPS 140-3 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 renforce notre défense en profondeur en ajoutant une compartimentation à 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 qui peuvent détecter avec précision les tentatives d'exfiltration de supports de stockage. Cependant, 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 des 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 permettent de rester vigilants face aux menaces internes et de protéger la confidentialité des données de nos utilisateurs.
Avantages de sécurité des composants d'architecture Titanium
Le tableau suivant met en évidence certains avantages de sécurité importants obtenus avec les composants de l'architecture de sécurité Titanium, tant au niveau du matériel que du 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 du matériel |
Caliptra RTM, Titan RoT |
Vérification de l'exécution des binaires attendus |
Caliptra RTM, Titan RoT |
Atténuer les 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 spécialement conçues avec uniquement les connecteurs essentiels, ce qui permet de limiter les tentatives de falsification physique |
Cartes mères personnalisées |
Isolement des charges de travail cryptographiques par rapport au logiciel système 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 et cloison d'impact minimisées pour un pirate informatique disposant d'un accès local |
Services régionaux de backend tolérants aux pannes |
Compartimentation à plusieurs niveaux |
Services régionaux de backend tolérants aux pannes |
Racine de confiance Caliptra pour la mesure
Caliptra RTM permet de renforcer la confiance et la transparence du micrologiciel dans notre écosystème qui s'exécute sur des systèmes sur puce (SoC) tels que les processeurs, les GPU et les TPU.
Caliptra RTM présente les avantages suivants :
- Fournit un service cryptographique racine : Caliptra RTM permet de détecter le code et la configuration critiques corrompus grâce à une vérification d'intégrité cryptographique de bout en bout. Caliptra RTM peut mesurer son code et sa configuration de manière cryptographique, 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. Caliptra RTM fournit une identité d'appareil cryptographique et un ensemble de mesures d'intégrité du micrologiciel et de la configuration pour la carte mère.
- Réduit la sécurité physique de la chaîne d'approvisionnement : Caliptra RTM permet de s'assurer que le matériel est authentique et qu'il exécute le micrologiciel et le logiciel 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 du logiciel, qu'ils soient créés par Google ou par un tiers. Ce processus de validation permet à Caliptra RTM de garantir l'authenticité et l'intégrité des mises à jour autorisées, et de s'assurer que les configurations restent conformes et attestées.
- Protège contre les intrusions physiques qui nécessitent un accès direct au matériel en cours d'exécution : comme Caliptra RTM est intégré aux couches de silicium de la puce, un interpositionneur de 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 peuvent contourner les capacités de détection d'un RoT externe en falsifiant le bus SPI à vitesse relativement faible. Toutefois, un RoT intégré à un SoC ou à un ASIC est plus difficile à compromettre pour un pirate informatique.
Racine de confiance de la puce Titan
Titan est conçu pour assurer la gestion cryptographique de l'identité de l'appareil, se protéger contre les logiciels malveillants et appliquer l'authenticité du code à l'aide de la révocation.
Une identité cryptographique forte de l'appareil permet de s'assurer que la flotte est composée exclusivement 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 du matériel.
Par défaut, les machines de production utilisent le démarrage sécurisé pour s'assurer que seul le logiciel authentifié peut 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 mesure préventive 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 de limiter non seulement les attaques malveillantes (par exemple, les attaques de rollback ou de replay), 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 comportant des bugs).
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 permettent de garantir la sécurité lors du déchargement des E/S. Ces TOP sont protégés par Titan ou Caliptra RTM. Les opérateurs de transports en commun déploient un chiffrement authentifié généralisé des données en transit et un chiffrement authentifié 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 du matériel. Les cartes mères sont compatibles avec l'attestation à plusieurs niveaux. Les cartes mères sont conçues pour protéger les données des clients, même dans le cas très improbable où un pirate informatique associerait 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 trafic de gestion par proxy 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 rétablir après la plupart des plantages ou en cas de corruption du micrologiciel. Nos dernières conceptions permettent de reconstruire l'ensemble de la machine à partir d'un seul et unique Titan RoT fonctionnel. 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, Trusted Execution Environment) ou un enclave pour isoler les charges de travail sensibles des clients de l'accès administratif Google. Lorsque les données sont gérées par le processeur ou le GPU, l'informatique confidentielle fournit un contrôle technique préventif via l'isolation des calculs et le 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 offre une couche d'isolation du secret des données contre la possibilité d'un accès involontaire du personnel Google ou d'actions logicielles automatisées défectueuses à 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 Balance isole l'infrastructure afin que les clés sensibles soient exclusivement traitées dans un TEE basé sur le matériel. Pour en savoir plus sur l'examen des opérations de chiffrement par un tiers, consultez le rapport public – Mode confidentiel pour Hyperdisk – Analyse de la protection par clé DEK.
Services régionaux de backend tolérants aux pannes
Les services backend régionalisés et tolérants aux pannes permettent de réduire la zone touchée par un pirate informatique disposant d'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 provenant de services d'infrastructure distincts pour continuer à se déplacer latéralement.
Si une attaque déclenche un contrôle préventif qui éloigne une machine de production de l'environnement (par exemple, en éteignant le système), notre infrastructure 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 constituent une partie de la surface d'attaque de Google Cloud. L'architecture de sécurité matérielle Titanium est spécialement conçue pour répondre à un ensemble unique de menaces pour l'infrastructure Google et les données utilisateur que nous stockons.
Menaces pour l'infrastructure
L'architecture Titanium est conçue pour se défendre contre les différentes catégories de menaces suivantes :
- Personnel interne malveillant disposant d'un accès physique : notre personnel a besoin d'accéder aux appareils physiques des 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.
Utilisateur interne malveillant disposant d'un accès logique : comme pour l'accès physique au centre de données, le personnel doit développer, gérer, tester, déboguer, ajuster et prendre en charge plusieurs niveaux de la pile logicielle Google. Ces personnes incluent 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 la section Comment Google protège ses services de production.
Attaquant externe avec accès logique : les pirates informatiques externes peuvent s'introduire dans un environnement Google Cloud et tenter de se transférer 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 un compte légitime d'un employé ou d'un sous-traitant.
Le schéma suivant indique quelle partie de l'environnement cloud est la plus vulnérable à ces menaces.
Surface d'attaque des serveurs du centre de données
Le tableau suivant décrit les surfaces d'attaque qui sont des aspects typiques des serveurs de centre 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 |
|---|---|---|---|
Utilisateur interne malveillant disposant d'un accès physique |
Supports de stockage (SSD, HDD ou disques de démarrage) |
Lecteurs et connecteurs physiques |
Cette attaque peut voler un disque et tenter d'y accéder avec les outils de l'attaquant. |
DIMM |
Connecteurs de mémoire physique |
Cette attaque peut geler le DIMM, le retirer 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 de démarrage à froid. |
|
Serveur |
Connecteurs USB ou PCIe |
Cette attaque peut permettre de connecter du matériel malveillant au serveur. En utilisant le matériel malveillant, l'attaquant peut tenter d'exécuter du code ou d'exfiltrer des données résidentes. |
|
Carte mère |
Port de débogage étendu (XDP) du groupe d'accès aux tests conjoints (JTAG) |
Cette attaque peut connecter un outil de débogage matériel pour exécuter du code ou accéder aux données traitées par 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 peut entraîner l'installation d'un micrologiciel malveillant persistant. Ce micrologiciel peut être préinstallé par un fabricant compromis, intercepté en transit ou mis à jour par un initié. Cette menace peut entraîner un matériel pré-piraté avec des rootkits qui fournissent un accès en arrière-plan au serveur. |
|
Initié malveillant avec accès logique |
Charge de travail de calcul (par exemple, VM) |
Points de connexion |
Cette attaque peut utiliser des identifiants internes pour accéder directement aux VM ou aux hôtes, ainsi qu'aux données qu'ils contiennent. |
Routeur Fabric |
Accès physique ou administratif |
Cette attaque pourrait permettre d'obtenir un contrôle racine sur un routeur Fabric pour espionner tout le trafic, et exfiltrer ou altérer les données en texte clair en transit sur Fabric. |
|
Carte mère |
Micrologiciel |
Cette attaque peut envoyer des images de micrologiciels défectueuses sur les cartes mères, les rendant définitivement inutilisables et rendant les données irrécupérables. Un pirate informatique peut pousser un micrologiciel connu comme vulnérable sur des machines pour reprendre le contrôle à l'aide d'exploits qui permettent l'exécution de code à distance. |
|
Pirate informatique externe disposant d'un accès logique |
Serveur |
VM |
Cette attaque peut lancer des schémas d'attaque par canal secondaire public sur des 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 peut utiliser un accès direct aux SSD PCIe pour tenter d'inférer des données de co-locataire. |
|
Mémoire |
VM |
Ce vecteur d'attaque peut utiliser des canaux secondaires pour rechercher des clés de chiffrement importantes 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 leur permettrait de persister dans la machine et d'attaquer les locataires suivants. |
Mappage des composants matériels Titanium avec les menaces
L'architecture de sécurité matérielle Titanium utilise une approche à plusieurs niveaux pour répondre à 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 de sécurité des serveurs, des réseaux et du plan de contrôle. Aucune solution unique ne permet de traiter 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 non autorisées constituent une menace pour la sécurité des données, car elles peuvent entraîner l'exfiltration de données depuis les 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 en couches résistant à un large éventail d'attaques.
Le tableau suivant décrit certaines des menaces matérielles malveillantes et explique comment l'architecture Titanium peut les atténuer.
| Menace | Atténuation de Titanium |
|---|---|
Un pirate informatique exfiltre des disques 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'autochiffrement intégrées aux supports de stockage sont également activées pour une défense en profondeur et utilisent des clés qui ne sont jamais stockées de manière persistante 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 des clés d'un service de gestion des clés vers des instances de services de stockage. Les machines qui sont configurées de manière malveillante avec un micrologiciel inattendu 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 telles que dm-crypt sont utilisées pour les disques à faible performance, où la réduction de la surface d'attaque est primordiale, comme pour certains cas d'utilisation de disques de démarrage. |
Un pirate informatique exploite un câble réseau et lit les octets sur le fil ou la fibre. |
Les TOP chiffrent les données en transit, ce qui empêche les menaces de détecter des données précieuses sur le réseau. Nos NIC utilisent la norme de déchargement matériel PSP. Cette norme offre un chiffrement économique avec une perte de performances minimale. Ces implémentations sont conformes à FIPS. Les données client sont chiffrées lorsqu'elles transitent par des commutateurs Top of Rack (ToR) 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 modifiable 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 fournir d'accès aux identifiants stockés à l'intérieur. Même si un pirate informatique réécrit le contenu des puces flash non volatiles, le TPM 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 comme vulnérable à l'échelle mondiale dans notre flotte à l'aide de puces Titan. |
Un pirate informatique insère des appareils malveillants dans les interfaces physiques des serveurs ou des cartes du centre 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 appareils malveillants. Des configurations de IOMMU (Input-Output Memory Management Unit) 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 la structure PCIe.) À mesure que le secteur évolue, nous compléterons cette protection avec PCI IDE pour atténuer les risques liés aux 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é matérielle et de l'intégrité du code auprès de notre plan de contrôle. Aucun serveur n'est admis en production si l'attestation ne correspond pas à l'intent matériel et logiciel. |
Un pirate informatique utilise une attaque de dé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 de 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 : Utilisation abusive de serveurs ou de réseaux par des utilisateurs malveillants
Les pirates 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. Les adversaires externes, qu'il s'agisse d'individus ou d'États, peuvent également tenter d'obtenir un accès privilégié à distance.
Pour limiter ces actions, l'architecture de sécurité matérielle Titanium utilise des puces Titan et Caliptra RTM pour provisionner des 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 du serveur et du réseau, et explique comment l'architecture Titanium peut les atténuer.
| Menace | Atténuation de 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 l'attaquant d'avoir un accès persistant. Toute tentative d'accès persistant est susceptible d'être détectée, car la configuration de la machine ne correspond pas à la configuration et à la règle de code de ce serveur. Cette correspondance est nécessaire pour 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 public sur des VM. |
Notre système de gestion de flotte, qui utilise des puces Titan, peut révoquer les logiciels connus comme vulnérables. La révocation peut bloquer les attaques ultérieures qui ciblent ces failles connues. Les mesures d'intégrité basées sur Titan permettent également de s'assurer que les mesures d'atténuation, qui peuvent devoir être déployées de toute urgence, ont été déployées sur les machines cibles. Nous renforçons cette approche en restant à la pointe de l'investigation et de la mitigation des canaux secondaires, grâce à des techniques telles que retpoline et la planification des cœurs, ainsi qu'à des recherches avancées sur Meltdown, Spectre, Zenbleed, Downfall et d'autres. |
Un pirate utilise l'accès direct aux SSD qui fournissent de l'espace de stockage à plusieurs locataires pour tenter de déduire des données de colocation. |
Le chiffrement des données au repos permet de se protéger contre les attaques logiques et physiques grâce à différents interposeurs. Pour les ressources qui ne sont pas partageables, les données de chaque locataire sont chiffrées à l'aide de clés différentes, ce qui réduit les risques d'attaques par accès direct contre le SSD. |
Un pirate informatique analyse la mémoire et utilise des canaux secondaires pour rechercher des clés de chiffrement de données ou des identifiants. |
Les puces Titan permettent de provisionner des identifiants scellés par machine. Même si un pirate informatique obtient un accès racine sur une machine, ses identifiants sont uniquement liés à l'identité privée de la puce Titan locale. |
Un pirate informatique achète des instances bare-metal et analyse tous les périphériques pour tenter d'obtenir un accès persistant. |
Les puces Titan rejettent toute mise à niveau logicielle non autorisée, y compris les commandes persistantes malveillantes. Notre workflow de 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 utilisateurs internes malveillants peuvent tenter d'exploiter les systèmes de Google de différentes manières, par exemple en tentant d'obtenir un contrôle racine sur un routeur de réseau, en envoyant des images de micrologiciel défectueuses sur des cartes mères et en écoutant le trafic réseau. L'architecture de sécurité matérielle Titanium protège 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 et tolérants aux pannes du backend.
Le tableau suivant décrit certaines des menaces du plan de contrôle et explique comment l'architecture Titanium peut les atténuer.
| Menace | Atténuation de Titanium |
|---|---|
Un pirate utilise des identifiants internes pour accéder aux VM Compute Engine qui servent de couche de base aux environnements des clients. |
Les TOP permettent de s'assurer que les administrateurs n'ont pas accès aux environnements des clients. 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 aux données client par les initiés de Google est bloqué, car les données ne sont accessibles que via des API définies. |
Un pirate informatique envoie des images de micrologiciels défectueuses à grande échelle sur des cartes mères, les rendant 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 le réseau et le PCI ont été rendus inutilisables par un pirate, le réseau hors bande (OOB) peut restaurer le système. |
Un pirate informatique envoie un micrologiciel de production obsolète et connu pour être vulnérable sur des machines afin de reprendre le contrôle en utilisant des failles publiques. |
Les puces Titan rejettent les mauvais push et aident à appliquer la révocation du code connu comme vulnérable. Ils attestent de la version du micrologiciel déployée sur la machine et la rejettent au niveau du plan de contrôle. Cette solution permet d'empêcher l'exécution de tâches sur une machine en mauvais état et de déclencher 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. |
Caliptra RTM permet de s'assurer que tous les paramètres qui permettent d'activer des interfaces de débogage invasives, qu'elles soient connectées de manière logique ou par insertion physique directe, sont configurés de manière fiable, mesurés par cryptographie et signalés à notre plan de contrôle à l'aide d'un protocole d'attestation. Seules les machines dont l'état est conforme à l'état souhaité 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 de backend tolérants aux pannes sont des infrastructures d'authentification régionalisées qui ne permettent pas un accès humain unilatéral. En plus d'empêcher les opérateurs de se connecter 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 de 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 la sécurité de l'infrastructure.
- Implémentez l'informatique confidentielle.
Auteurs : Andrés Lagar-Cavilla, Erlander Lo, Jon McCune, Chris Perry