Sécuriser le service MPC à l'aide de rôles IAM

Modèle de sécurité : défense en profondeur

L'API Multi-party Compute (MPC) implémente une architecture de sécurité de défense en profondeur qui repose sur des contrôles stricts de Identity and Access Management (IAM). Ce modèle garantit qu'aucune identité ou compte Google compromis ne peut compromettre unilatéralement la plate-forme ou extraire des éléments.

  • Couche 1 : Identity and Access Management (IAM) : toutes les requêtes sont vérifiées à la périphérie pour confirmer que l'appelant dispose des autorisations explicites requises pour appeler des méthodes d'API Google Cloud spécifiques (voir Présentation d'IAM). Les comptes ne disposant pas de droits suffisants sont immédiatement rejetés avec une erreur 403 Forbidden, ce qui empêche le trafic non autorisé d'atteindre la couche d'application.
  • Couche 2 : Séparation des tâches : la plate-forme MPC applique une séparation stricte des rôles pour s'assurer que les actions de gouvernance et d'exécution distinctes ne peuvent pas être effectuées par la même personne. En définissant des rôles distincts (par exemple, en limitant les auteurs de règles à la modification des règles et les signataires à la signature des charges utiles de transaction), le système garantit qu'un seul agent malveillant ou compte piraté ne peut pas exécuter de manière indépendante des transactions sensibles.
  • Couche 3 : principe du moindre privilège : l'accès est accordé strictement en fonction de la fonction, ce qui garantit que les utilisateurs ne disposent que des autorisations minimales requises pour effectuer leurs tâches. Par exemple, l'équipe chargée de la conformité ou de l'audit fonctionne selon le principe du moindre privilège, en conservant un accès strictement en lecture seule pour surveiller l'activité. Ils peuvent consulter les règles et inspecter les journaux de transactions à des fins de surveillance, mais ne peuvent pas modifier les règles, lancer des transactions ni interagir avec les éléments.

Personas et séparation des tâches

La sécurité est assurée en dissociant l'administration (configuration du tableau) de la gouvernance (définition des règles) et de l'exécution (déplacement des éléments).

Persona Domaine Rôle IAM attribué Principales responsabilités
Administrateur Administration mpc.admin Provisionne des ressources. Impossible de signer des transactions ou de créer des règles.
Auteur de la règle Gouvernance mpc.editor Définit et modifie les règles opérationnelles (par exemple, les limites de dépense).
Signataire Exécution mpc.editor Signe les charges utiles de transaction. Impossible de créer des règles.
Conformité Supervision mpc.viewer Accès en lecture seule pour surveiller l'activité et inspecter les règles. Impossible de modifier les règles ou de lancer des transactions.

Rôles IAM prédéfinis

Le tableau suivant détaille les autorisations IAM spécifiques pour l'API Multi-party Compute (MPC) et les rôles qui les accordent. Pour en savoir plus sur les opérations de l'API, consultez la documentation de référence de l'API MPC.

Rôle Autorisations
Lecteur Multi-party Compute
(roles/mpc.viewer)

Fournit un accès en lecture seule à l'API (opérations Get/List sur toutes les ressources). Idéal pour les auditeurs ou les outils de surveillance.

Ressources de niveau le plus bas auxquelles vous pouvez attribuer ce rôle :
  • KeyRing
 mpc.googleapis.com/keyRings.get
mpc.googleapis.com/keyRings.list
mpc.googleapis.com/keys.get
mpc.googleapis.com/keys.list
mpc.googleapis.com/policies.get
mpc.googleapis.com/policies.list
mpc.googleapis.com/policyAuthorTrustBundles.get
mpc.googleapis.com/proposals.get
mpc.googleapis.com/proposals.list
mpc.googleapis.com/signers.get
mpc.googleapis.com/signers.list
Éditeur de calcul multipartite
(roles/mpc.editor)

Conçu pour les auteurs de règles et les participants (signataires). Permet de gérer les règles, de créer des propositions et d'enregistrer les décisions des participants.

Ressources de niveau le plus bas auxquelles vous pouvez attribuer ce rôle :
  • KeyRing
 Inclut toutes les autorisations roles/mpc.viewer, plus :

mpc.googleapis.com/keyRings.update
mpc.googleapis.com/keys.update
mpc.googleapis.com/policies.addQuorumSignature
mpc.googleapis.com/policies.create
mpc.googleapis.com/policies.revoke
mpc.googleapis.com/proposals.create
mpc.googleapis.com/proposals.fetchProposalSignature
mpc.googleapis.com/proposals.recordParticipantDecision
Administrateur de calcul multipartite
(roles/mpc.admin)

Conçu pour les administrateurs. Accorde un accès complet pour provisionner l'infrastructure, générer des clés et enregistrer les clés publiques des participants.

Ressources de niveau inférieur auxquelles vous pouvez attribuer ce rôle :
  • Instance
 Inclut toutes les autorisations roles/mpc.editor, plus :

mpc.googleapis.com/keyRings.create
mpc.googleapis.com/keyRings.delete
mpc.googleapis.com/keys.create
mpc.googleapis.com/policyAuthorTrustBundles.update
mpc.googleapis.com/signers.create

Rôles personnalisés

Pour accorder à un participant un accès strict au moindre privilège au lieu d'utiliser les rôles prédéfinis plus larges comme roles/mpc.editor, vous pouvez créer un rôle IAM personnalisé contenant uniquement les autorisations exactes dont il a besoin pour participer aux opérations.

Exemple de commande de rôle personnalisé

gcloud iam roles create customMpcSigner \
  --project="PROJECT_ID" \
  --title="Custom MPC Signer" \
  --description="Restricted role for transaction participants" \
  --permissions="mpc.googleapis.com/proposals.get,mpc.googleapis.com/proposals.list,mpc.googleapis.com/proposals.recordParticipantDecision"

IAM au niveau des ressources et conditionné

En respectant le principe du moindre privilège, vous pouvez limiter les rôles IAM à un périmètre limité à l'aide des conditions IAM.

Si plusieurs unités commerciales opèrent dans le même projet Google Cloud à l'aide d'une instance partagée, vous pouvez appliquer une séparation en plaçant les ressources dans des trousseaux de clés distincts (par exemple, KeyRing A et KeyRing B). Vous pouvez accorder roles/mpc.editor à un compte de service à l'aide d'une condition IAM qui le limite exclusivement aux opérations se produisant dans un trousseau de clés désigné (KeyRing A), tout en limitant l'accès aux autres trousseaux de clés de la même instance.

Exemple de commande

Exemple de création d'une liaison de rôle limitée à un trousseau de clés :

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:sa-name@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/mpc.editor" \
  --condition="expression=resource.name.startsWith('projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID'),title=KeyRing_Scoped_Editor"

Identités fédérées (Bring Your Own Identity)

Vous pouvez authentifier et autoriser les requêtes de calcul multipartite à l'aide de fournisseurs d'identité d'entreprise externes (tels qu'Okta, Microsoft Entra ID ou Ping Identity) ou d'environnements d'exécution de charges de travail externes sans créer de comptes Google ni gérer de clés de compte de service :

  • Fédération des identités des employés : mappe les pools d'employés au niveau de l'organisation (locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>) à des personas humains (par exemple, administrateurs, auteurs de règles, signataires et conformité) en associant des rôles IAM à des groupes d'IdP externes.
  • Fédération d'identité de charge de travail : mappe les pools d'identités de charge de travail au niveau du projet (projects/<var>PROJECT_NUMBER</var>/locations/global/workloadIdentityPools/<var>WORKLOAD_POOL_ID</var>) aux nœuds de cosignataire automatisés exécutés dans AWS, Azure ou Kubernetes.

Les comptes principaux fédérés doivent également disposer du rôle Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer) sur le projet consommateur afin que les requêtes API puissent attribuer des quotas et une facturation au projet.

Exemples de liaisons de rôles fédérés

# Allow members of the workforce pool to consume APIs through the consumer project
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/*" \
  --role="roles/serviceusage.serviceUsageConsumer"

# Grant MPC Admin to an external IdP administrators group
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/group/mpc-admins" \
  --role="roles/mpc.admin"

# Grant MPC Editor to an external IdP signers group
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/group/mpc-signers" \
  --role="roles/mpc.editor"

Remplacez les éléments suivants :

  • <var>PROJECT_ID</var> : ID du projet client pour votre instance de calcul multipartite.
  • <var>WORKFORCE_POOL_ID</var> : ID du pool d'identités de personnel au niveau de l'organisation.

Pour obtenir un tutoriel complet, consultez Configurer la fédération des identités des employés (BYOID).