Présentation de la sécurité de Confidential Space

Ce document décrit les contrôles de sécurité de Confidential Space et explique comment le système est conçu pour limiter une grande variété de menaces. Confidential Space permet aux parties de partager des données confidentielles (par exemple, des données réglementées ou des informations permettant d'identifier personnellement l'utilisateur) avec une charge de travail, tout en préservant la confidentialité et la propriété des données. Confidential Space permet de créer une isolation afin que les données ne soient visibles que par la charge de travail et les propriétaires d'origine des données.

Vous pouvez utiliser Confidential Space dans des situations où vous ne pouvez pas établir une relation de confiance avec l'opérateur de charge de travail ou entre les parties initiales ayant créé les données confidentielles. Les institutions financières peuvent, par exemple, utiliser Confidential Space pour collaborer entre elles afin d'identifier une fraude ou d'analyser les activités de blanchiment d'argent. Confidential Space permet d'analyser tous les ensembles de données client, tout en préservant la confidentialité des identités client.

Composants d'un système Confidential Space

Confidential Space utilise un environnement d'exécution sécurisé (TEE) conçu pour ne publier des secrets qu'à des charges de travail autorisées. Un processus d'attestation et une image de l'OS renforcée permettent de protéger la charge de travail et les données qu'elle traite à partir d'un opérateur non approuvé.

Un système Confidential Space comporte trois composants principaux :

  • Une charge de travail : une image conteneurisée avec un système d'exploitation renforcé qui s'exécute dans un TEE basé sur le cloud. Vous utilisez l'informatique confidentielle en tant que TEE offrant des fonctionnalités d'isolation matérielle et d'attestation à distance.
  • Google Cloud Attestation:fournisseur de jetons OpenID Connect (OIDC). Vous utilisez ce service pour valider les devis d'attestation pour le TEE et publier des jetons d'authentification. Les jetons contiennent des attributs d'identification pour la charge de travail.
  • Une ressource protégée : une ressource cloud gérée telle qu'une clé Cloud Key Management Service ou un bucket Cloud Storage. La ressource est protégée par une stratégie d'autorisation qui accorde l'accès aux jetons d'identité fédérée autorisés. Une étape intermédiaire qui, à l'aide de pools Workload Identity, transforme les jetons OIDC en jetons d'identité fédérés qu'IAM peut utiliser.

Le système permet de s'assurer que l'accès aux ressources protégées n'est accordé qu'aux charges de travail autorisées. De plus, Confidential Space permet de protéger la charge de travail contre l'inspection et la falsification, avant et après l'attestation.

Un système Confidential Space se compose de trois parties :

  • L'auteur de la charge de travail, qui crée une image en conteneur incluant une application qui a accès aux ressources protégées. L'auteur n'a pas accès aux données ni aux résultats. De plus, l'auteur ne contrôle pas l'accès aux données ou aux résultats.
  • L'opérateur de charge de travail, qui exécute la charge de travail dans un projet Google Cloud. L'opérateur dispose généralement de droits d'administration complets sur le projet. L'opérateur peut gérer des Google Cloud ressources telles que les instances, les disques et les règles de mise en réseau Compute Engine, et peut interagir avec n'importe quelle Google Cloud API qui agit sur celles-ci. L'opérateur n'a pas accès aux données ou aux résultats, et ne peut ni influencer, ni modifier le code ou l'environnement d'exécution. De plus, l'opérateur ne contrôle pas l'accès aux données ou aux résultats.
  • Les propriétaires de ressources (ou collaborateurs de données) qui possèdent la ressource protégée. Un propriétaire de ressource peut accéder à ses propres données, définir des autorisations sur ses propres données et accéder aux résultats. Il ne peut pas accéder aux données d'autres propriétaires de ressources ni modifier le code par lui-même.

Confidential Space est compatible avec un modèle de confiance dans lequel l'auteur de la charge de travail, l'opérateur de charge de travail et les propriétaires de ressources sont des parties distinctes, qui ne se font pas confiance.

Le schéma suivant montre les composants et les parties du système. La charge de travail se trouve dans un projet distinct de la ressource protégée.

Système et composants de Confidential Space

Exemples de traitement sécurisé des données

Confidential Space vous permet de protéger la vie privée d'un utilisateur tout en partageant des données. Le tableau suivant décrit trois exemples de cas d'utilisation.

Cas d'utilisation Exemple de scénario
Modèle de chiffrement fonctionnel Dans un modèle de chiffrement fonctionnel, Alice souhaite partager le résultat de ses données confidentielles avec Bob, sans révéler l'ensemble de ses données. Alice chiffre son ensemble de données et protège la clé de chiffrement des données (DEK) dans Cloud KMS dans son projet. Alice écrit un programme qui implémente la charge de travail et partage le binaire avec Bob. Alice configure le service de gestion des clés pour permettre au programme d'accéder à la DEK. La charge de travail s'exécute dans le Confidential Space de Bob, déchiffre et traite l'ensemble de données d'Alice, puis écrit le résultat dans son espace de stockage Cloud Storage.
Calcul multipartite Dans le calcul multipartie, Alice et Bob souhaitent partager le résultat entre eux, tout en préservant la confidentialité des ensembles de données d'entrée. Comme dans le modèle de chiffrement fonctionnel, Alice et Bob chiffrent leurs ensembles de données respectifs et protègent les clés de chiffrement des données dans les instances Cloud KMS de leurs projets. Ils co-créent un programme qui détermine les résultats et l'exécutent dans un Confidential Space. Alice et Bob configurent le service de gestion des clés pour permettre au programme d'accéder aux DEK. Le programme lit et traite les deux ensembles de données, puis écrit le résultat dans un bucket Cloud Storage partagé.
Quotes-parts de clés Un schéma plus complexe utilise le concept de quotes-parts de clés. Une quote-part de clé est une clé privée répartie entre Alice, Bob et d'autres propriétaires, de sorte que la connaissance des quotes-parts individuelles ne permet pas d'accéder à l'ensemble de données chiffré. Dans ce schéma, la confiance est répartie entre plusieurs propriétaires. La clé privée n'est assemblée que dans un TEE restreint, par une charge de travail autorisée.

Dans ces exemples, seule la charge de travail a accès à l'ensemble de données chiffré et peut le traiter. Confidential Space permet de s'assurer que personne ne peut effectuer des opérations non auditées sur des données qui ne leur appartiennent pas. Les propriétaires de données contrôlent la façon dont leurs données sont utilisées et les charges de travail autorisées à les utiliser.

Protéger l'intégrité et la confidentialité d'une charge de travail

Pour protéger la charge de travail d'un opérateur de charge de travail qui n'est pas approuvé, Confidential Space met en œuvre les contrôles de sécurité suivants :

  • Un processus d'attestation détecte les modifications apportées à l'image de la charge de travail ou à son TEE. Ce contrôle permet de protéger l'intégrité de la charge de travail avant l'attestation.
  • Une image de base renforcée permet de réduire la surface d'attaque et d'empêcher l'opérateur de la charge de travail d'accéder à l'instance ou de la compromettre au moment de l'exécution. Ce contrôle permet de protéger l'intégrité et la confidentialité d'une charge de travail après l'attestation. Ensemble, ces contrôles de sécurité contribuent à protéger la charge de travail, ses secrets et les données qu'elle traite.

Processus d'attestation

Le processus d'attestation est basé sur les démarrages mesurés et les mesures des environnements d'exécution étendus de la VM protégée. Ce processus capture les mesures de la séquence de démarrage dans un registre protégé uniquement à extension prolongée dans l'appareil vTPM (Virtual Trusted Platform Module).

Les mesures couvrent les composants d'amorçage précoce, le noyau chargé et l'image du conteneur. De plus, elles incluent des propriétés d'environnement telles qu'un indicateur indiquant que l'instance est une VM confidentielle. Le vTPM signe (ou estime) ces mesures à l'aide d'une clé d'attestation certifiée approuvée par Google Cloud Attestation.

Le schéma suivant montre les composants d'un système Confidential Space et explique comment chaque composant participe au processus d'attestation.

Les composants et les parties du système du processus d'attestation.

Le processus d'attestation dépend des composants suivants :

  • Micrologiciel invité:composant immuable qui fait partie intégrante deGoogle Cloud.
  • Image Confidential Space certifiée : image renforcée basée sur Container-Optimized OS lue à partir du disque de démarrage associé.
  • Composants d'amorçage : bootloaders et noyaux qui interagissent avec le module vTPM pour mesurer les composants de démarrage dans un registre de configuration de plate-forme (PCR).

  • Lanceur : composant qui télécharge le binaire de la charge de travail à partir du dépôt d'images, et mesure le conteneur et sa configuration dans un PCR. Le lanceur d'applications lit sa configuration à partir du serveur de métadonnées de l'instance.

  • Code de gestion des attestations : code chargé de préparer un devis sur le PCR et de renvoyer le devis, la clé d'attestation et le journal des événements complet du module vTPM.

  • Attestation Google Cloud:service qui vérifie le devis, relance le journal des événements, émet le jeton OIDC et renvoie le jeton avec les attributs pour la stratégie d'accès à la charge de travail.

Image renforcée

L'image Confidential Space est un OS minimal à usage unique. L'image exécute le lanceur de conteneurs, qui à son tour lance un conteneur. L'image Confidential Workspace s'appuie sur les améliorations de sécurité existantes de Container-Optimized OS et offre les avantages supplémentaire suivants :

  • Partitions de disque chiffrées avec protection de l'intégrité : l'image Confidential Space inclut les partitions suivantes :
    • Une partition root-fs et une partition OEM qui inclut le binaire du lanceur. Ces partitions sont immuables et protégées par dm-verity.
    • Partition temporaire en écriture qui stocke le binaire de la charge de travail téléchargée. dm-crypt chiffre cette partition et protège son intégrité.
    • Partition tmp-fs mappée sur la RAM. Dans un TEE Confidential VM, la mémoire de la VM est chiffrée. De plus, le système swap-fs est désactivé, ce qui permet d'empêcher un système d'exploitation mal configuré de stocker des données sur le disque.
  • Connexions réseau authentifiées et chiffrées:le lanceur utilise TLS pour authentifier Google Cloud Attestation et protéger ses liens de communication.
  • Diverses mesures de démarrage : ces mesures incluent des arguments de ligne de commande du noyau, la configuration dm-verity pour root-fs et le binaire de la charge de travail.

  • Désactivation de l'accès à distance et des outils cloud spécifiques : ces outils incluent sshd et OS Login.

  • Transitions d'état réduites : par exemple, le lanceur exécute un seul conteneur, puis s'arrête.

Modèle de menace et mesures d'atténuation

Cette section décrit les types de menace que Confidential Space permet de limiter, ainsi que les nouveaux risques introduits par Confidential Space.

Les attaques suivantes n'entrent pas dans le cadre de ce document :

  • Les attaques de chaîne d'approvisionnement logicielle qui s'appliquent au micrologiciel UEFI (Unified Extensible Firmware Interface) invité, au bootloader et au noyau de l'image Confidential Space, à l'environnement d'exécution du conteneur et aux dépendances tierces pour la charge de travail Les collaborateurs de données supposent que les propriétaires des ressources ont examiné et audité l'image de conteneur avant que les propriétaires de ressources ne partagent leur ressource avec une stratégie d'autorisation.
  • Attaques sur Google Cloud, telles que les échappements de VM.

Attaques possibles

Confidential Space est conçu pour se protéger contre trois attaques possibles :

  • Un opérateur de charge de travail malveillant : un opérateur de charge de travail malveillant peut modifier le contenu du disque, intercepter les connexions réseau et tenter de compromettre le TEE au moment de l'exécution. Un opérateur malveillant peut élargir la surface d'attaque ou restreindre l'environnement d'exécution. Par exemple, un opérateur malveillant peut ajouter une console série pour introduire de nouveaux vecteurs d'attaque. Autre exemple: un opérateur malveillant peut limiter des ressources, par exemple en limitant la taille de la mémoire d'un invité, en modifiant son espace disque ou en modifiant les règles de pare-feu. Ces contraintes peuvent déclencher des erreurs d'E/S qui peuvent entraîner des cas d'erreur mal testés.
  • Client d'attestation malveillant:ce pirate informatique se connecte à Google Cloud Attestation et envoie des messages de journal d'événements mal formés, mais signés.
  • Propriétaire de ressources malveillantes : un propriétaire de ressource malveillante a le contrôle total de l'ensemble de données chiffré utilisé par la charge d travail. Ce pirate informatique peut présenter des entrées non valides ou des données biaisées, et tenter de déclencher des failles d'analyse dans la charge de travail ou de contourner ses paramètres de confidentialité.

Surfaces d'attaque

Le tableau suivant décrit les surfaces d'attaque disponibles pour les pirates informatiques.

Pirate informatique Cible Surface d'attaque Risques
Opérateur de charge de travail TEE, charge de travail Lectures de disque

Tout ce qui est lu à partir du disque est sous le contrôle du pirate informatique.

Des services tels que les disques persistants à écriture simultanée et les rattachements de disque dynamiques permettent à un pirate informatique de modifier le contenu du disque de manière dynamique et à son gré.
Opérateur de charge de travail TEE, charge de travail Écritures de disque Tout ce qui est écrit sur le disque est visible par un pirate informatique. Consultez les fonctionnalités d'instantanés de disque et d'importation.
Opérateur de charge de travail TEE, charge de travail Serveur de métadonnées Les attributs d'instance lus à partir du serveur de métadonnées sont sous le contrôle du pirate informatique, y compris le script de démarrage et les variables d'environnement.
Opérateur de charge de travail TEE, charge de travail Réseau Les connexions réseau externes au dépôt d'images ou à Google Cloud Attestation peuvent être interceptées. Cette attaque est effectuée à l'aide d'un VPC privé avec une instance Cloud Router exposée publiquement.
Client d'attestation Attestation Google Cloud Journal des événements et messages d'attestation Google Cloud Attestation dispose d'une logique complexe et axée sur le chiffrement, qui est difficile à écrire de manière défensive.
Propriétaire de la ressource Charge de travail Ensemble de données chiffré

Un pirate informatique peut empoisonner les ensembles de données d'entrée de la charge de travail, ce qui signifie que les données chiffrées ne sont pas nécessairement des données fiables.

Google Cloud infrastructure

Google Cloud inclut l'hyperviseur Compute Engine, le vTPM de la VM Confidential, le micrologiciel UEFI invité et une instance d'attestation Google Cloud hébergée. Le matériel de clé sensible, tel que les clés de signature vTPM et OIDC, est conçu pour être protégé de manière sécurisée.

L'infrastructure de Google est conçue pour isoler logiquement les données de chaque client des données des autres clients et utilisateurs, même lorsqu'elles sont stockées sur le même serveur physique. L'accès administrateur pour le personnel d'assistance et les ingénieurs est limité, audité et transparent pour les clients. De plus, le chiffrement de la mémoire intégrée dans Confidential VMs permet de protéger la confidentialité de la mémoire de l'instance. Le chiffrement de la mémoire intégrée rend inefficace l'inspection directe ou la journalisation accidentelle de la mémoire (journalisation des plantages du noyau). Pour en savoir plus sur la façon dont nous protégeons notre plate-forme, consultez la présentation de la sécurité Google.

Menaces et stratégies d'atténuation

Un système de fichiers chiffrés avec protection de l'intégrité est conçu pour limiter les risques d'attaques de disque. En outre, une fois que le code est lu à partir du disque, il est mesuré et ces données ne sont plus lues à nouveau à partir du disque. Les secrets ne sont jamais divulgués sous forme de texte brut au disque ni à un appareil externe tel qu'une console série.

Les risques liés aux attaques réseau sont atténués si l'on dispose de canaux chiffrés authentifiés de bout en bout. L'accès au réseau externe, tel que SSH, est désactivé dans l'image. Un protocole d'attestation permet de protéger la séquence de démarrage et toute configuration lue à partir du serveur de métadonnées. Enfin, les charges de travail Confidential Space doivent utiliser des contrôles de confidentialité différentiels pour limiter les risques liés aux ensembles de données biaisés.

Les tableaux suivants décrivent les menaces et les mesures d'atténuation :

Attaques sur le processus de démarrage mesuré

Ce tableau décrit les menaces potentielles et les stratégies d'atténuation liées au processus de démarrage mesuré.

Menace Atténuation Mise en œuvre de l'atténuation

Un pirate informatique démarre une VM protégée avec un ancien micrologiciel qui n'est pas compatible avec le démarrage mesuré.

En cas de réussite, un pirate informatique peut relire des mesures arbitraires et vaincre l'attestation à distance.

Cette menace est atténuée par le plan de contrôle Google Cloud .

Confidential Space ajoute un appareil vTPM et un micrologiciel UEFI à jour. De plus, Confidential Space active le démarrage mesuré, et celui-ci ne peut pas être désactivé.

 Dans l'infrastructure Google Cloud

Un pirate informatique écrase le micrologiciel UEFI dans la mémoire physique de l'invité, redémarre l'invité qui réinitialise les enregistrements vTPM et exécute le micrologiciel modifié.

En cas de réussite, un pirate informatique peut relire des mesures arbitraires et vaincre l'attestation à distance.

 Cette menace est atténuée par l'hyperviseur. Lors du redémarrage de l'invité, l'hyperviseur charge une copie propre du micrologiciel UEFI dans la mémoire de l'invité. Les modifications précédentes dans la mémoire invitée sont supprimées. De plus, le redémarrage de l'invité est le seul événement qui réinitialise le module vTPM. Dans Google Cloud et en activant l'informatique confidentielle
Un pirate informatique modifie les fichiers de configuration non mesurés, ce qui affecte négativement l'exécution du programme.

Cette menace est atténuée par le processus d'attestation. Tous les binaires exécutables et les fichiers de configuration respectifs sont entièrement mesurés avant l'exécution.

En particulier, les variables de démarrage sécurisé, la configuration grub et les arguments de ligne de commande du noyau sont mesurés.

L'examen de sécurité a révélé qu'aucune mesure n'avait été manquée dans le processus d'attestation.

 Dans l'image de Confidential Space
Un pirate informatique déclenche des failles de corruption de mémoire dans les composants d'amorçage et parvient à l'exécution du code.

Les composants de démarrage précoce sont écrits en langage C. Ces composants traitent des données utilisateur non fiables et peuvent être vulnérables aux problèmes de corruption de mémoire. Pour obtenir un exemple récent, consultez BootHole.

Ce risque est atténué par le processus d'attestation : les composants d'amorçage doivent mesurer toutes les données contrôlées par l'utilisateur avant de les traiter. Une attaque BootHole utilise un grub.cfg modifié pour exécuter du code et contourner le démarrage sécurisé.

Cependant, dans un système Confidential Space, cette attaque ne réussit pas l'attestation, car les mesures grub.cfg ne correspondent pas à la configuration attendue.

Un risque connexe provient d'une logique complexe de système de fichiers. Des failles antérieures telles que Sequoia montrent que les pilotes de système de fichiers traitent des structures de données complexes et peuvent être vulnérables aux problèmes de corruption de mémoire.

Ce risque est atténué à l'aide de la protection de l'intégrité dm-verity et dm-crypt au niveau du bloc, et en désactivant les montages automatiques.

Dans l'image de Confidential Space
Un pirate informatique modifie les binaires d'amorçage sur le disque après les avoir lus et mesurés, avant de les lire et de les exécuter (disque TOCTOU).

Les composants d'amorçage ont été conçus pour des machines bare metal. Ils pourraient ne pas être prêts pour l'environnement dynamique du cloud. Les composants de démarrage peuvent supposer que le contenu du disque ne peut pas changer pendant l'exécution, ce qui est une hypothèse incorrecte pour les environnements cloud.

Ce risque est atténué en utilisant une programmation défensive: le contenu du disque est en lecture seule après avoir utilisé le modèle de lecture, de mesure et d'exécution.

L'examen de sécurité pour l'image Confidential Space n'identifie pas les problèmes TOCTOU dans les composants d'amorçage tels que UEFI, Shim, ou GNU GRUB.

 Dans l'image de Confidential Space
Un pirate informatique modifie les pilotes d'appareil et les services en mode utilisateur sur le disque après le chargement du noyau.

Cette menace est atténuée par un système de fichiers racine doté d'une protection de l'intégrité.

Root-fs dans l'image Confidential Space est une intégrité protégée par dm-verity. La configuration (root-hash) est transmise dans un argument de commande du kernel, puis mesurée et attestée par Google Cloud Attestation.

 Dans l'image de Confidential Space

Attaques sur le lanceur de conteneur

Ce tableau décrit les menaces potentielles et les stratégies d'atténuation liées au lanceur.

Menace Atténuation Mise en œuvre de l'atténuation
Un pirate informatique intercepte la connexion réseau du lanceur ou du dépôt d'images.

La connexion au dépôt d'images est protégée par une connexion TLS authentifiée et chiffrée.

Un pirate informatique peut modifier l'URL de l'image et contrôler le binaire de la charge de travail. Toutefois, ces actions sont reflétées dans le journal des attestations.

Le dépôt d'images n'est pas contrôlé à l'aide d'une liste d'accès. Par conséquent, on suppose que l'image est visible par tous les utilisateurs. Vous devez vous assurer que l'image du conteneur de charge de travail ne contient aucun secret.

 Dans l'image de Confidential Space
Un pirate informatique modifie l'image de charge de travail sur le disque après son téléchargement et sa mesure.

Cette menace est atténuée par une partition en écriture chiffrée et dont l'intégrité est protégée.

L'image de la charge de travail et ses données temporaires sont protégées par dm-crypt à l'aide de clés éphémères à chaque démarrage.

Le processus de chiffrement de disque dm-crypt permet les attaques de rollback, où un pirate informatique remplace le contenu du disque par des textes chiffrés et des tags précédemment visibles. Ces attaques sont considérées comme très complexes dans les paramètres de Confidential Space.

 Dans l'image de Confidential Space
Un pirate informatique modifie la configuration du lanceur d'applications sur le serveur de métadonnées et contrôle l'URL du dépôt d'images. Le processus d'attestation détecte les configurations non sécurisées qui chargent des images non authentiques. Dans Google Cloud Attestation

Attaques sur Google Cloud Attestation

Ce tableau décrit les menaces potentielles et les stratégies d'atténuation de Google Cloud Attestation.

Menace Atténuation Mise en œuvre de l'atténuation
Un pirate informatique intercepte la connexion réseau du lanceur ou de Google Cloud Attestation et lit le jeton secret du réseau.

Cette menace est atténuée par une connexion TLS authentifiée et chiffrée. Cette connexion permet de protéger le jeton contre l'espionnage passif.

Un pirate informatique ne peut pas usurper l'identité du service, car il ne dispose pas de la clé TLS. Même s'il réussit, le pirate informatique ne peut pas créer de jetons OIDC valides.

Un pirate informatique ne peut pas usurper l'identité d'un client valide, car l'identité du client est garantie par le protocole d'attestation.

 Sur le réseau, entre votre charge de travail et le service d'attestation.
Un pirate informatique exploite les écarts d'analyse, ce qui entraîne des modifications non détectées dans le processus d'attestation.

Cette menace peut se produire, car le journal des événements de mesure est sérialisé et envoyé à Google Cloud Attestation, où il est analysé et traité.

Une divergence d'analyse se produit lorsque le service et l'OS d'exécution ne sont pas d'accord sur la sémantique du journal.

Par exemple, si le champ cmdline contient une liste d'arguments séparés par une virgule, une chaîne telle que a=1, b=2 c='3,d=e' (notez ,d dans la sous-chaîne de valeur) peut être analysée différemment par le noyau et le service.

Ce risque est atténué si vous disposez d'un moteur d'analyse qui reflète correctement le comportement de l'OS. Plus particulièrement, cmdline est traité comme une chaîne entière et n'est pas divisée en paires clé-valeur.

 Dans l'image de Confidential Space
Un pirate informatique utilise toutes les ressources de service, ce qui entraîne l'arrêt du service lors d'une attaque par déni de service (DoS). Le service est interrompu pour les autres utilisateurs de Confidential Space.

Ce risque de fiabilité est atténué par la présence d'un service distribué et élastique qui peut être facilement répliqué et mis à l'échelle si nécessaire.

Le code empêche l'épuisement des ressources par des clients malveillants.

 Dans la charge de travail

Attaques sur les charges de travail

Ce tableau décrit les menaces potentielles et les stratégies d'atténuation liées aux charges de travail.

Menace Atténuation Mise en œuvre de l'atténuation
Un pirate informatique lit les secrets d'environnement d'exécution à partir de la partition accessible en écriture.

Cette menace est atténuée grâce à un système de fichiers chiffrés. Le système de fichiers accessible en écriture est installé à l'aide de dm-crypt. L'échange est désactivé et le contenu de la mémoire n'est pas paginé sur le disque.

En tant que technique de défense en profondeur, les jetons OIDC ont un champ d'application et sont de courte durée.

 Dans l'image de Confidential Space
Un pirate informatique lit les secrets d'environnement d'exécution à partir de la console série. Cette menace est atténuée dans l'image de Confidential Space, car les identifiants et les jetons ne sont jamais affichés sur la console série. De plus, Cloud Logging est désactivé. Dans l'image de Confidential Space
Un pirate informatique met à jour les clés SSH autorisées à l'aide du package OSLogin, puis se connecte à l'instance en cours d'exécution. Cette menace est atténuée dans l'image de Confidential Space, car les services systemd par défaut sont masqués, y compris sshd. Dans l'image de Confidential Space
Un pirate informatique met à jour les scripts de démarrage sur le serveur de métadonnées, qui sont automatiquement chargés par l'agent invité. Cette menace est atténuée dans l'image de Confidential Space car le package d'agent invité est désactivé. Dans l'image de Confidential Space
Un pirate informatique envoie des packages incorrects sur la VM à l'aide de l'agent OS Config. Cette menace est atténuée dans l'image de Confidential Space, car l'agent OS Config est désactivé. Dans l'image de Confidential Space
Un pirate informatique transmet un ensemble de données non valide et chiffré à la charge de travail. Cette menace est atténuée par la présence d'un code d'analyse défensif dans la charge de travail. Dans la charge de travail
Un pirate informatique transmet un ensemble de données biaisé ou empoisonné à la charge de travail et tente d'obtenir des informations sur les ensembles de données d'autres parties. Cette menace est atténuée en implémentant des contrôles de confidentialité différentielle dans la charge de travail. Dans la charge de travail

Tests de sécurité

Confidential Space a fait l'objet d'un examen approfondi de la sécurité chez Google. Ce processus d'examen de sécurité comprend les tests et audits suivants :

  • Tests d'intégration de bout en bout du flux négatif

    Ces tests ont vérifié que l'attestation échoue en cas de mauvaises mesures, par exemple lorsque le code s'exécute dans un environnement TEE inattendu ou lance un conteneur de charge de travail modifié.

  • Audit manuel du processus de démarrage mesuré

    Cet examen s'est concentré sur l'identification des mesures manquantes et des bugs de double lecture. Les tests ont vérifié que le code a été écrit en tenant compte des bonnes pratiques de sécurité et que, en cas d'échec, le code s'est fermé (arrêt).

  • Audit manuel du processus de compilation de l'image Confidential Space et de la logique de lancement:

    Cet examen s'est concentré sur la suppression de packages et la réduction de la surface d'attaque.

  • Audit manuel de Google Cloud Attestation

    Cet examen s'est concentré sur l'implémentation du bon protocole d'attestation et sur l'évitement des problèmes d'analyse.

  • Examen de la cryptographie par des experts en cybersécurité

    Cet examen s'est concentré sur le protocole d'attestation, le chiffrement du système de fichiers et les solutions d'intégrité.

  • Examen de la confidentialité par des experts en confidentialité

    Cet examen s'est concentré sur les paramètres de confidentialité différentiels dans les charges de travail élaborées par Google.

  • Tests flous continus

    Ces tests couvraient des composants essentiels à la sécurité tels que le vTPM et l'attestation Google Cloud.

Le groupe NCC Group, une organisation externe dédiée aux tests d'intrusion, a effectué des tests d'intrusion sur le système. NCC a examiné Confidential Space en tant que plate-forme de calcul sécurisée.

Étape suivante