Créer et accorder l'accès à des ressources confidentielles

Les collaborateurs de données doivent configurer les ressources suivantes pour que leurs données confidentielles soient accessibles par une charge de travail:

De plus, les collaborateurs sur les données doivent choisir l'emplacement où les résultats de la charge de travail Confidential Space sont stockés, et si les données présentées sont uniques ou partagées. Vous pouvez, par exemple, générer le même résultat dans plusieurs buckets Cloud Storage appartenant à chaque collaborateur sur les données.

Stocker vos données

Vous pouvez utiliser n'importe quel service Google Cloud qui stocke des données pour héberger vos données confidentielles. Vous pouvez, par exemple, utiliser l'un des services suivants:

Vous devez vous assurer que ces données sont chiffrées au repos, que ce soit à l'aide de fonctionnalités intégrées ou d'un service tel que Cloud Key Management Service (Cloud KMS).

Créer un compte de service pour déchiffrer des données confidentielles

Vous mettez vos données confidentielles à la disposition des charges de travail Confidential Space (et réduisez l'exposition humaine à ces données) via des comptes de service.

Par exemple, vous pouvez chiffrer des fichiers confidentiels dans Cloud Storage avec Cloud KMS, puis créer un compte de service autorisé à accéder à ces données et à la clé de déchiffrement.

Vous associez ensuite ce compte de service à un WIP. Une charge de travail Confidential Space autorisée basée dans un autre projet peut ensuite utiliser ce WIP pour usurper l'identité du compte de service qui déchiffre les données, les récupérer et les traiter.

Étant donné que les comptes de service sont utilisés à la fois pour déchiffrer les données confidentielles et les traiter, la visibilité des données confidentielles est limitée à ses propriétaires. Étant donné que la charge de travail s'exécute dans une VM confidentielle, son chiffrement de la mémoire basé sur le matériel garantit la confidentialité de vos données pendant leur utilisation. SSH est également désactivé sur les VM de charge de travail qui utilisent l'image Confidential Space de production, ce qui signifie que personne ne peut accéder à la VM lorsqu'elle est en cours d'exécution.

Pour en savoir plus, consultez Créer votre premier environnement Confidential Space.

Créer un WIP et un fournisseur pour la validation des attestations

Pour protéger les données d'un opérateur de charge de travail non approuvé, Confidential Space met en œuvre un processus d'attestation qui détecte les modifications apportées à une image de charge de travail ou à son TEE. Ce processus est basé sur les mesures des environnements d'exécution étendus et le démarrage mesuré des VM protégées, et 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).

Le service d'attestation Confidential Space génère des jetons OpenID Connect (OIDC) qui incluent ces attestations vTPM sous une forme pouvant être validée par un WIP, qui les compare aux stratégies ajoutées en tant que conditions d'attribut à un fournisseur. Ces jetons sont signés par Google et durent une heure et sont automatiquement actualisés.

Si le WIP autorise la charge de travail, celle-ci peut usurper l'identité des comptes de service du projet pour déchiffrer et récupérer des données confidentielles.

Pour configurer un WIP et un fournisseur, procédez comme suit:

  1. Créez le WIP.

  2. Associez votre compte de service de déchiffrement au WIP avec le rôle iam.workloadIdentityUser.

  3. Créez un fournisseur OIDC avec les informations suivantes:

    • URI d'émetteur https://confidentialcomputing.googleapis.com/.

    • Audience autorisée de https://sts.googleapis.com.

    • Mappage d'attributs du fournisseur google.subject, avec une valeur de assertion.sub.

    • Conditions d'attribut utilisées pour valider les attestations de la charge de travail. Pour connaître les options disponibles, consultez Créer une règle d'attestation.

Créer une règle d'attestation

Lorsque vous créez un travail en cours, vous ajoutez des conditions d'attributs, c'est-à-dire des conditions qu'une charge de travail doit remplir pour pouvoir accéder à vos données. Pour Confidential Space, ces conditions d'attribut constituent votre règle d'attestation.

Les règles sont écrites en Common Expression Language (CEL) et sont constituées d'une série d'assertions pouvant être associées à l'opérateur &&.

Voici un exemple d'ajout d'un fournisseur à un pool d'identités de charge de travail à l'aide de la gcloud CLI, ainsi que l'option attribute-condition qui définit les règles:

gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
    --location=global \
    --workload-identity-pool=user-pool-name \
    --issuer-uri="https://confidentialcomputing.googleapis.com/" \
    --allowed-audiences="https://sts.googleapis.com" \
    --attribute-mapping="google.subject=assertion.sub" \
    --attribute-condition="assertion.submods.container.image_digest =='sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b' \
&& 'service-account@my-project.iam.gserviceaccount.com' in assertion.google_service_accounts \
&& assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes"

Dans cet exemple, une identité externe qui tente d'emprunter l'identité d'un compte de service associé au pool d'identités de charge de travail doit attester des informations suivantes et vérifier que leurs valeurs correspondent:

  • Condensé de l'image du conteneur de charge de travail

  • Adresse du compte de service associé à la VM de charge de travail

  • CONFIDENTIAL_SPACE est le logiciel exécuté sur la VM, avec toutes ses garanties de sécurité intégrées.

  • Attribut de compatibilité de l'image de production Confidential Space

Assertions d'attestation

Les assertions disponibles pour créer une règle d'attestation sont détaillées dans le tableau suivant. Ils peuvent valider les assertions émises par l'image Confidential Space, le conteneur de charge de travail et la VM.

Affirmations sur les images

Assertion Type Description

assertion.dbgstat

Interagit avec:

 Chaîne définie

Vérifie que l'image Confidential Space est la version de débogage ou de production.

Les valeurs valides sont les suivantes:

  • enable: vérifiez que l'image de débogage est utilisée.
  • disabled-since-boot: vérifiez que l'image de production est utilisée.
Examples

Le code suivant vérifie que la version de débogage de l'image Confidential Space est utilisée:

assertion.dbgstat == "enable"

Le code suivant vérifie que la version de production de l'image Confidential Space est utilisée:

assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes Tableau de chaînes.

Vérifie que la version de sécurité du TEE est une image Confidential Space de production. Aucun attribut de compatibilité n'est défini pour les images Confidential Space de débogage.

Il existe trois attributs de compatibilité :

  • LATEST: il s'agit de la dernière version de l'image, compatible. L'image LATEST est également STABLE et USABLE.
  • STABLE: cette version de l'image est compatible et surveillée pour détecter les failles. Une image STABLE est également USABLE.
  • USABLE: une image ne contenant que cet attribut n'est plus compatible et n'est plus surveillée pour détecter les failles. L'utilisation de cette solution relève entièrement de votre responsabilité.
Exemple

Le code suivant vérifie qu'une version stable de l'image Confidential Space est utilisée:

"STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname Chaîne définie

Vérifie le logiciel exécuté sur l'entité de test. La valeur est toujours CONFIDENTIAL_SPACE.

Exemple
assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion Tableau de chaînes.

Vérifie la version logicielle de l'image Confidential Space. Nous vous recommandons d'utiliser assertion.submods.confidential_space.support_attributes pour cibler la dernière version d'une image.

Exemple
int(assertion.swversion[0]) == 230103

Assertions pour les conteneurs

Assertion Type Description

assertion.submods.container.cmd_override

Interagit avec:

 Tableau de chaînes.

Vérifie les commandes et les paramètres CMD utilisés dans l'image de charge de travail.

Examples

Le code suivant vérifie que l'objet CMD de l'image de charge de travail n'a pas été écrasé:

size(assertion.submods.container.cmd_override) == 0

Le code suivant vérifie que program est le seul contenu dans les remplacements CMD:

assertion.submods.container.cmd_override == ['program']

assertion.submods.container.env

Interagit avec:

 Objet JSON

Vérifie que les variables d'environnement et leurs valeurs ont été explicitement transmises au conteneur.

Exemple

Le code suivant vérifie que la variable d'environnement example-env-1 est définie sur value-1 et que example-env-2 est définie sur value-2.

assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}

assertion.submods.container.env_override

Interagit avec:

 Chaîne

Vérifie si l'opérateur de charge de travail a écrasé les variables d'environnement dans le conteneur.

Examples

Le code suivant vérifie que l'opérateur de charge de travail n'a pas remplacé la variable d'environnement example:

!has(assertion.submods.container.env_override.example)

Le code suivant vérifie que l'opérateur de charge de travail n'a pas écrasé de variables d'environnement:

size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest Chaîne

Vérifie le condensé de l'image du conteneur de la charge de travail. Spécifier cette condition permet à plusieurs parties d'accepter une charge de travail autorisée et autorisée à accéder à leurs données.

Exemple
assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id Chaîne

Vérifie l'ID d'image du conteneur de charge de travail.

Exemple
assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"

assertion.submods.container.image_reference

Interagit avec:

 Chaîne

Vérifie l'emplacement du conteneur de charge de travail exécuté au-dessus de l'image Confidential Space.

Exemple
assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"

assertion.submods.container.image_signatures

Interagit avec:

 Objet JSON

Vérifie que l'image comporte une signature spécifique ou qu'elle est signée par une clé publique et un algorithme de signature. Spécifier cette condition permet à plusieurs parties d'accepter une charge de travail autorisée et autorisée à accéder à leurs données.

L'assertion peut inclure les éléments suivants:

  • key_id: empreinte hexadécimale de la clé publique. Pour obtenir l'empreinte, vous pouvez exécuter la commande suivante:

    openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256

    Où public_key.pem correspond à votre clé publique au format PEM.

  • signature: signature sur une charge utile associée au conteneur signé et qui suit le format de signature simple.

  • signature_algorithm: algorithme utilisé pour signer la clé. Choisissez l'une des options suivantes :

    • RSASSA_PSS_SHA256 (RSASSA-PSS avec un condensé SHA-256)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 avec un condensé SHA-256)
    • ECDSA_P256_SHA256 (ECDSA sur la courbe P-256 avec un condensé SHA-256)
Exemple
assertion.swname == 'CONFIDENTIAL_SPACE' && ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id)) && 'serviceaccount.iam.gserviceaccount.com' in assertion.google_service_accounts"

assertion.submods.container.restart_policy

Interagit avec:

 Chaîne définie

Vérifie la stratégie de redémarrage du lanceur de conteneurs lorsque la charge de travail s'arrête.

Les valeurs valides sont les suivantes:

  • Never (par défaut)
  • Always
  • OnFailure
Exemple
assertion.submods.container.restart_policy == "Never"

Assertions de VM

Assertion Type Description

assertion.google_service_accounts

Interagit avec:

 Tableau de chaînes.

Vérifie qu'un compte de service spécifié est connecté à la VM qui exécute la charge de travail ou a été répertorié à l'aide de tee-impersonate-service-accounts dans les métadonnées de la VM.

Exemple
workload-service-account@my-project.iam.gserviceaccount.com in assertion.google_service_accounts
assertion.hwmodel Chaîne

Vérifie la technologie d'informatique confidentielle sous-jacente. Les plates-formes compatibles sont les suivantes:

Exemple
assertion.hwmodel == "GCP_AMD_SEV"

assertion.submods.confidential_space.monitoring_enabled

Interagit avec:

 Booléen

Vérifie l'état de surveillance sur l'entité de test.

Exemple
assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id Chaîne

Vérifie l'ID de l'instance de VM.

Exemple
assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name Chaîne

Vérifie le nom de l'instance de VM.

Exemple
assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id Chaîne

Vérifie que la VM exécute un projet Google Cloud avec l'ID de projet spécifié.

Exemple
assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number Chaîne

Vérifie que la VM s'exécute dans un projet Google Cloud avec le numéro de projet spécifié.

Exemple
assertion.submods.gce.project_number == "00000000000"

assertion.submods.gce.zone

Interagit avec:

  • Opérateur de charge de travail: valeur --zone .
 Chaîne

Vérifie que la VM s'exécute dans la zone spécifiée.

Exemple
assertion.submods.gce.zone == "us-central1-a"