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.
  • Un service d'attestation : un fournisseur de jetons OpenID Connect (OIDC). Ce service vous permet de valider les devis d'attestation pour le TEE et de 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 les ressources Google Cloud telles que les instances, les disques et les règles de mise en réseau Compute Engine, et il peut interagir avec n'importe quelle API Google Cloud qui agit sur eux. 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'intégralité de son ensemble de 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 met en œuvre 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 à plusieurs parties 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. À l'instar du modèle de chiffrement fonctionnel, Alice et Bob chiffrent leurs ensembles de données respectifs et protègent les DEK 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 l'utilisation de leurs données et les charges de travail autorisées à les exploiter.

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 charge de travail ou à son TEE. Ce contrôle permet de protéger la pré-attestation d'intégrité de la charge de travail.
  • Une image de base renforcée permet de réduire la surface d'attaque et d'empêcher l'opérateur de 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 la validation. 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, le noyau chargé et l'image de conteneur. De plus, elles incluent des propriétés d'environnement, telles qu'une option indiquant que l'instance est une Confidential VM. Le module vTPM signe (ou estime) ces mesures à l'aide d'une clé d'attestation certifiée approuvée par le service d'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 de Google 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.

  • Le Service d'attestation : 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.
    • Une partition temporaire accessible 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é.
    • Une partition tmp-fs mappée à la mémoire RAM. Dans un TEE de 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'éviter qu'un système d'exploitation mal configuré stocke des données sur le disque.
  • Connexions réseau authentifiées et chiffrées : le lanceur utilise TLS pour authentifier le service d'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.
  • Les 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 étendre 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, ce qui peut entraîner des cas d'erreur mal testés.
  • Client d'attestation malveillante : ce pirate informatique se connecte au service d'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 à la disposition des 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 pages concernant les instantanés de disque et les fonctionnalités d'import.
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 au service d'attestation peuvent être interceptées. Cette attaque est effectuée à l'aide d'un VPC privé avec une instance Cloud Router publique.
Client d'attestation Service d'attestation Journal des événements et messages d'attestation Le service d'attestation dispose d'une logique complexe et lourde en termes de cryptomonnaie, 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.

Infrastructure Google Cloud

Google Cloud inclut l'hyperviseur Compute Engine, le vTPM de Confidential VM, le micrologiciel UEFI invité et un service d'attestation hébergé. Le matériel important 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 protection de 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 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 de 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 invitée. Les modifications précédentes dans la mémoire de l'invité 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 fichiers binaires exécutables et les fichiers de configuration respectifs sont entièrement mesurés avant leur 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'a été manquée au cours du 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 d'amorçage sont écrits en langage C. Ces composants traitent les données utilisateur non approuvées et peuvent être vulnérables aux problèmes de corruption de mémoire. Pour obtenir un exemple récent, consultez la page 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 obtenir l'exécution du code et empêcher 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é en utilisant la protection d'intégrité dm-verity et dm-crypt au niveau du bloc, et en désactivant les installations 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 lors de 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 n'est lu qu'une seule fois à l'aide du 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 noyau, puis mesurée et certifiée par le service d'attestation.

 Dans l'image de Confidential Space

Attaques sur le lanceur de conteneurs

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 chiffrée et authentifié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 d'attestation.

Le dépôt d'images n'est pas contrôlé à l'aide d'une liste d'accès. Par conséquent, l'image est considérée comme visible par tous. Vous devez vous assurer que l'image du conteneur de la 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 accessible en écriture qui est chiffrée et son 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 le service d'attestation

Attaques sur le service d'attestation

Ce tableau décrit les menaces potentielles et les stratégies d'atténuation pour le service d'attestation.

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

Cette menace est atténuée si vous disposez d'une connexion TLS authentifiée et chiffrée. Cette connexion permet de protéger le jeton contre l'écoute passive.

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

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

 Au sein du 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 des mesures est sérialisé et envoyé au service d'attestation, où il est analysé et traité.

Un écart d'analyse se produit lorsque le service et le système d'exploitation 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 lié à la fiabilité est atténué si vous disposez d'un service distribué et élastique pouvant être facilement répliqué et évolutif en fonction des besoins.

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 en utilisant du code d'analyse défensive 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 mettant en œuvre des contrôles de confidentialité différentiels dans la charge de travail. Dans la charge de travail

Tests de sécurité

Confidential Space a été soumis à un processus complet d'examen de 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 négatifs

    Ces tests ont vérifié que l'attestation échoue en cas de mesures incorrectes, 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 conformément aux bonnes pratiques de sécurité et, en cas d'échec, le code 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 des packages et la réduction de la surface d'attaque.

  • Audit manuel du service d'attestation

    Cet examen s'est concentré sur la mise en œuvre du protocole d'attestation approprié et sur la façon d'éviter les 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 ont couvert des composants critiques de sécurité, tels que le module vTPM et le service d'attestation.

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.

Étapes suivantes