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 de Google. Le matériel Titanium comprend 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 répondre à des vecteurs d'attaque spécifiques à l'infrastructure Google.
Le matériel Titanium est la dernière avancée de la sécurité de l'infrastructure globale 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 s'appuie sur une infrastructure telle que les cartes de déchargement matériel cryptographique qui fournissent le chiffrement en transit et les microservices internes qui fournissent le 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 aide à protéger la surface d'attaque physique des systèmes Google et à atténuer les menaces pesant 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 d'architecture suivant montre les composants indépendants, mais interdépendants, 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.
- Titan chip RoT : s'interpose entre le 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 de base (BMC), le hub de contrôleur de plate-forme (PCH) et le processeur. Les puces Titan fournissent une racine matérielle de confiance physiquement inviolable qui permet d'établir une identité forte. Les puces Titan permettent également d'autoriser et de révoquer des codes pour les machines, les cartes ou les périphériques.
- Processeur de déchargement Titanium (TOP): fournit des commandes cryptographiques pour aider à protéger la confidentialité et l'intégrité des données au repos et en transit.
- Les 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.
- Enclaves de calcul confidentiel : permettent d'appliquer l'isolation contre les privilèges administratifs de Google, d'améliorer l'isolation avec d'autres locataires et d'ajouter la vérifiabilité à l'aide d'une attestation. Une attestation peut vous assurer que l'environnement n'a pas été modifié.
- Services régionalisés tolérants aux pannes de backend: aident à éviter l'escalade des droits d'accès entre les services, les zones ou l'accès administrateur.
Dans le diagramme, 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 en suivant 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 s'applique à l'ensemble de notre infrastructure physique, dans toutes les régions, et même jusqu'au silicium des puces. Cette résilience dans notre infrastructure mondiale permet de protéger et de garantir la disponibilité des 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 réponse aux failles.
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 adversaires des cibles bien définies à partir desquelles ils peuvent espionner des 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 confiance et compartimentation des risques: les contrôles multiparties sur les actions administratives permettent de s'assurer qu'aucun compte personnel (ou compte personnel piraté) ne peut provoquer unilatéralement les menaces abordées dans cet article. 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 enracinées dans le matériel, l'architecture tient compte de la découverte des failles matérielles et de la nécessité de les corriger pendant que les composants restent en service.
Par exemple, si un pirate informatique compromet de manière malveillante le comportement d'un chip 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 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 contourner 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 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 la publication de code Open Source, 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 tout ce qui concerne le système, à l'exception de la clé, est de notoriété publique.
Par exemple, nous contribuons à des projets Open Source et les utilisons dans nos conceptions de matériel de sécurité et nos 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 ring0 hôte et de VM 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 en capital 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 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 conçue de manière délibérée pour ne pas dépendre de la garde 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 de sécurité des composants architecturaux Titanium
Le tableau suivant met en évidence certains avantages de sécurité importants obtenus avec les composants de l'architecture de sécurité Titanium, à la fois au niveau de la couche matérielle et de la couche logicielle. Ces avantages 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 à chaque démarrage |
Caliptra RTM, Titan RoT |
Protection de la confidentialité des données au repos et en transit |
TOPs pour la cryptographie |
Décharger la protection au niveau du processeur (au-delà d'une carte physique) |
TOPs 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 |
Cartes conçues pour un usage spécifique, ne comportant que les connecteurs essentiels, ce qui permet de limiter les tentatives de falsification physique |
Cartes mères personnalisées |
Isolement de la charge de travail cryptographique du logiciel système à l'échelle de la machine et de l'accès humain administratif |
Enclaves d'informatique confidentielle |
Résistance aux accès non autorisés via le chiffrement de la DRAM (pour activer le chiffrement des données en cours d'utilisation) |
Enclaves d'informatique confidentielle |
Zone affectée et cloison minimisées pour un pirate informatique disposant d'un accès local |
Services backend régionalisés tolérants aux pannes |
Compartimentation à plusieurs niveaux |
Services backend régionalisés tolérants aux pannes |
Racine de confiance Caliptra pour la mesure
La racine de confiance Caliptra pour la mesure (RTM) permet de renforcer la confiance et la transparence du 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 matériel, et générer des rapports sur les mesures qui attestent de l'authenticité et de l'intégrité de l'appareil. La RTM Caliptra 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.
- 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 le logiciel prévus. En plus de 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 soient 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 telles qu'elles étaient prévues et sont attestées.
- Protège contre les intrusions physiques qui nécessitent 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 intercalaire PCBA ou une puce malveillante qui tente de fournir le mauvais micrologiciel à un circuit intégré spécifique à l'application (ASIC) ne peut pas attaquer le RoT. Par exemple, les pirates informatiques peuvent contourner les fonctionnalités de détection d'un RoT externe en falsifiant le bus SPI relativement lent. 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 maintenir l'identité de l'appareil de manière cryptographique, se protéger contre les transferts logiciels incorrects et appliquer l'authenticité du code à l'aide de la révocation.
Une identité d'appareil cryptographique forte permet de s'assurer que le parc est composé 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 enraciné au niveau du 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 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 rejeu), mais aussi les bugs de stabilité ou de résilience non malveillants (par exemple, en empêchant la réinstallation accidentelle d'anciens micrologiciels bugués).
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 à assurer la sécurité lors du déchargement des E/S. Ces clés sont protégées par Titan ou Caliptra RTM. Les TOP déploient un chiffrement authentifié étendu 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, telles que la disponibilité, tout en minimisant le risque de perte de la 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 acceptent l'attestation à plusieurs niveaux. Les conceptions de carte mère protègent les données client, même dans l'éventualité peu probable qu'un pirate informatique connecte 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 proxying 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 après la plupart des plantages ou de la corruption du micrologiciel. Nos dernières conceptions permettent de reconstruire l'ensemble de la machine à partir d'un seul module de sécurité Titan opérationnel. 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 une enclave pour aider à isoler les charges de travail sensibles du client de l'accès administrateur 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 de calcul 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 client, l'informatique confidentielle offre une couche de protection du secret des données contre la possibilité d'un accès involontaire du personnel Google ou d'actions logicielles système 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 équilibrée Hyperdisk. Le mode confidentiel pour Hyperdisk Balance 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 tiers des opérations cryptographiques, consultez le rapport public – Mode confidentiel pour Hyperdisk – Analyse de la protection des clés DEK.
Services backend régionalisés tolérants aux pannes
Les services régionalisés tolérants aux pannes du backend permettent de réduire la zone affecté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 afin qu'un pirate informatique qui obtient un accès local doive compromettre plusieurs identifiants de services d'infrastructure distincts pour continuer à se déplacer latéralement.
Si une attaque déclenche un contrôle préventif qui retire 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 des 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 contre 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 les différentes catégories de menaces suivantes:
- Un employé 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 professionnelle légitime de réparer physiquement certaines des machines de nos centres de données.
Personne interne malveillante 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.
Pirate informatique externe disposant d'un accès logique: les pirates informatiques externes peuvent s'implanter dans un environnement Google Cloud et tenter de transférer latéralement vers d'autres machines pour obtenir l'accès à des données sensibles. Une tactique courante utilisée par les pirates informatiques externes consiste à commencer par compromettre un compte légitime de personnel ou de sous-traitant.
Le diagramme suivant montre la partie de l'environnement cloud 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 fournir une protection efficace contre de telles menaces.
| Pirate informatique | Cible | Surface d'attaque | Risque |
|---|---|---|---|
Initié malveillant avec accès physique |
Supports de stockage (SSD, HDD ou disques de démarrage) |
Disques et connecteurs physiques |
Cette attaque peut voler un disque et tenter d'y accéder avec les outils du pirate informatique. |
DIMM |
Connecteurs de mémoire physique |
Cette attaque peut geler la DIMM, la retirer du centre de données et essayer d'accéder aux données qu'elle contient à l'aide des outils du pirate informatique. Cette menace est parfois appelée attaque de démarrage à froid. |
|
Serveur |
Connecteurs USB ou PCIe |
Cette attaque peut 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 |
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 obtenir l'exécution de 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 peut introduire un micrologiciel malveillant persistant. Ce micrologiciel peut être préinstallé par un fabricant piraté, intercepté en transit ou mis à jour par un initié. Cette menace peut entraîner du 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 administrateur |
Cette attaque peut permettre d'obtenir un contrôle racine sur un routeur de fabric pour espionner tout le trafic, et exfiltrer ou falsifier toutes les données en texte clair en transit sur le fabric. |
|
Carte mère |
Micrologiciel |
Cette attaque peut envoyer des images de micrologiciels défectueux aux cartes mères, les rendant définitivement inutilisables et rendant les données irrécupérables. Un pirate informatique peut envoyer un micrologiciel connu comme étant vulnérable aux machines pour reprendre le contrôle à l'aide d'exploits permettant 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 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 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 auxiliaires pour rechercher des clés de chiffrement précieuses dans la mémoire. |
|
Serveur |
VM sur bare metal |
Ce vecteur d'attaque peut 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 sur les menaces
L'architecture de sécurité matérielle Titanium utilise une approche multicouche pour aider à 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 des serveurs, des réseaux et du plan de contrôle. Il n'existe pas de solution unique permettant de répondre à 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 d'informatique cloud.
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 à partir des centres de données et 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ésistante à un large éventail d'attaques.
Le tableau suivant décrit certaines des menaces matérielles malveillantes et la façon dont 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 des produits et services de stockage ne sont jamais stockées de manière persistante sur les machines auxquelles les supports de stockage sont connectés. Les fonctionnalités d'autochiffrement intégrées des 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 de clés vers des instances de service de stockage. Les machines 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 telles que dm-crypt sont utilisées pour les disques moins performants où la réduction de la surface d'attaque est primordiale, comme dans certains cas d'utilisation de disques de démarrage. |
Un pirate informatique écoute 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 une menace d'intercepter 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 rentable avec une diminution minimale des performances. Ces implémentations sont conformes aux normes FIPS. Les données client sont chiffrées lorsqu'elles transitent par des commutateurs Top of Rack (ToR) ou fabric. Certaines infrastructures de machine learning utilisent des mécanismes de sécurité de transport propriétaires. |
Un pirate informatique remplace les puces flash qui contiennent 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 donnent pas accès aux identifiants stockés à l'intérieur. Même si un pirate informatique réécrit le contenu de puces flash non volatiles, le 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 comme étant vulnérable à l'échelle mondiale dans notre flotte à l'aide de puces Titan. |
Un pirate informatique insère des dispositifs d'attaque dans les interfaces physiques des serveurs ou des cartes de centre de données pour exécuter du code malveillant ou exfiltrer des données. |
Les conceptions de cartes mères personnalisées éliminent les interfaces utilisées pour insérer des appareils malveillants. Des configurations d'unité de gestion de mémoire d'E/S (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 tissu PCIe.) À mesure que le secteur évolue, nous complétons cette protection avec PCI IDE pour limiter davantage les interféreurs 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 approuvés attestent de leur identité matérielle 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 d'attestation ne correspond pas à l'intention matérielle et logicielle. |
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: 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 pour déposer des données dans nos services publics. Des adversaires externes, allant d'individus isolés à des États, peuvent également tenter d'obtenir un accès à distance privilégié.
Pour atténuer 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 la façon dont 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 le pirate informatique 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 stratégie de 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 les VM. |
Notre système de gestion de parc, qui utilise des puces Titan, peut révoquer les logiciels présentant des failles connues. La révocation peut bloquer toute attaque ultérieure ciblant ces failles connues. Les mesures d'intégrité basées sur Titan offrent également un niveau de confiance élevé quant au déploiement des mesures d'atténuation, qui peuvent devoir être déployées de toute 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 de cœurs, ainsi qu'à des recherches avancées sur Meltdown, Spectre, Zenbleed, Downfall, etc. |
Un pirate informatique utilise un accès direct aux SSD qui fournissent un espace de stockage à plusieurs locataires pour tenter d'inférer des données de co-locataire. |
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ée, 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 des 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 ne sont liés qu'à l'identité privée du chip Titan local. |
Un pirate informatique achète des instances bare-metal et analyse tous les périphériques pour essayer 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 de machine confirme positivement les mesures d'intégrité attendues sur l'ensemble du cycle d'alimentation attesté du système entre les clients bare metal. |
Scénario: Exploitation de serveurs ou de réseaux par un comportement de plan de contrôle malveillant
Les membres internes du plan de contrôle non autorisés peuvent tenter d'exploiter les systèmes de Google de différentes manières, y compris en essayant d'obtenir le contrôle racine sur un routeur de tissu, en poussant des images de micrologiciels défectueux sur des cartes mères et en interceptant le trafic réseau. L'architecture de sécurité matérielle Titanium se 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 tolérants aux pannes de backend.
Le tableau suivant décrit certaines des menaces du plan de contrôle et comment l'architecture Titanium peut les atténuer.
| Menace | Atténuation de Titanium |
|---|---|
Un pirate informatique utilise des identifiants internes pour accéder aux VM Compute Engine qui servent de couche de base aux environnements client. |
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 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 micrologiciels défectueux à grande échelle sur les 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é bloqués par un pirate informatique, le réseau hors bande (OOB) peut réparer le système. |
Un pirate informatique envoie un micrologiciel de production obsolète et connu comme étant vulnérable sur les machines pour reprendre le contrôle à l'aide de failles publiques. |
Les puces Titan rejettent les transferts incorrects et aident à appliquer la révocation du code présentant des failles connues. Ils attestent la version du micrologiciel déployée sur la machine et rejettent la machine au niveau du plan de contrôle. Cette atténuation permet d'empêcher l'exécution de tâches sur une machine non saine 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 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 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 ont accès à la gestion des 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 du backend sont une infrastructure d'identifiants régionalisée qui n'autorise pas l'accès humain unilatéral. En plus d'empêcher la connexion des opérateurs sur les nœuds de calcul, les opérateurs 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 aident à 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.