Sécurité et autorisation

Aperçu

Ce produit est soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Chaque requête adressée à l'API Multi-party Compute passe par deux vérifications distinctes : une vérification Identity and Access Management sur la méthode API et une vérification de l'utilisateur Multi-party Compute de l'appelant et de ses rôles. Cette page décrit ces deux vérifications, les autorisations IAM et la manière dont les administrateurs approuvent les modifications apportées aux rôles utilisateur.

Comment une requête est autorisée

1. Vérification IAM Avant qu'une requête n'atteigne votre instance, IAM vérifie que le compte principal appelant dispose de l'autorisation requise par la méthode sur la ressource de la requête. Si ce n'est pas le cas, la requête échoue avec l'erreur 403 PERMISSION_DENIED et n'atteint jamais l'instance. La requête est enregistrée dans Cloud Audit Logs. Pour connaître l'autorisation requise par chaque méthode, consultez Autorisations IAM.
2. Vérification de l'utilisateur et du rôle Pour les méthodes qui agissent au nom d'un utilisateur, l'instance recherche l'utilisateur dont le principal correspond à l'identité authentifiée de l'appelant, puis vérifie les rôles de cet utilisateur. Par exemple, l'appelant de CreateTransaction doit être un utilisateur disposant du rôle SIGNER. Pour connaître les vérifications effectuées par chaque méthode, consultez Rôles utilisateur.

Les deux vérifications doivent réussir. Les rôles IAM et les rôles utilisateur sont complémentaires. Par exemple :

• Un compte principal disposant de roles/mpc.editor, mais pas d'utilisateur avec le rôle POLICY_AUTHOR, peut appeler CreateTransactionPolicy, mais l'instance rejette la requête.
• Un utilisateur disposant du rôle SIGNER dont le compte principal ne dispose pas de l'autorisation mpc.googleapis.com/transactions.create ne peut pas créer de transactions, car IAM rejette d'abord la requête.

Les approbations comportent également une signature. Les signataires, les auteurs de règles et les administrateurs signent chaque approbation avec la clé d'autorisation enregistrée sur leur utilisateur. Cela garantit que les règles et les transactions ne peuvent pas être falsifiées et qu'elles laissent des pistes d'audit durables.

Les environnements d'exécution sécurisés (TEE) des participants vérifient ces signatures avant de signer une transaction ou d'accepter une règle de transaction. Ainsi, une requête qui réussit les deux vérifications ne peut toujours pas produire de signature sans approbations valides. Pour en savoir plus, consultez le modèle de sécurité.

Rôles utilisateur

Chaque utilisateur dispose de l'un des rôles suivants, défini dans User.roles. Ce rôle est un rôle dans votre instance, et non un rôle IAM.

Rôle d'utilisateur	Ce que l'utilisateur peut faire	Vérifié le
SIGNER	Détient des quotes-parts de clés et approuve les transactions. Appartient à une seule équipe.	CreateTransaction : l'utilisateur de l'appelant doit disposer du rôle SIGNER. RecordSignerDecision : l'utilisateur de l'appelant doit détenir une part de la clé de la transaction. ListTransactions : si l'utilisateur de l'appelant ne dispose que du rôle SIGNER, seules les transactions sur les clés pour lesquelles l'utilisateur détient une part de clé sont renvoyées.
POLICY_AUTHOR	Propose, approuve et désactive les règles de transaction.	CreateTransactionPolicy, ApproveTransactionPolicy, DisableTransactionPolicy : l'utilisateur de l'appelant doit être un auteur de règles actif disposant d'une clé d'autorisation enregistrée.
ADMIN	Gère les utilisateurs, les équipes, les trousseaux de clés, les clés et les listes de clés. Approuve les modifications apportées aux rôles ADMIN et POLICY_AUTHOR.	EnableUserRole, DisableUserRole, DisableUser, ApproveUser pour les modifications de ADMIN et POLICY_AUTHOR : la requête doit comporter la signature de l'administrateur appelant. Consultez Approbation par l'administrateur des modifications de rôles.

Les règles suivantes s'appliquent aux utilisateurs :

• Un compte principal par utilisateur. User.principal est défini lorsque vous créez l'utilisateur et ne peut pas être modifié. Il s'agit d'un compte Google ou d'un compte principal de la fédération des identités des employés. Pour modifier le compte principal d'un utilisateur, désactivez l'utilisateur et créez-en un autre.
• Une équipe par signataire. Un utilisateur disposant du rôle SIGNER doit avoir défini Team. Seuls les utilisateurs disposant du rôle SIGNER peuvent détenir des parts de clé. Par conséquent, seuls les signataires appartiennent à une équipe. Le déplacement d'un signataire vers une autre équipe utilise UpdateTeamAssignment, ce qui nécessite un nouveau partage, prévu pour une version ultérieure.
• Clés d'autorisation Les signataires et les auteurs de règles ont besoin d'une clé d'autorisation pour signer les approbations. Les administrateurs en ont besoin pour demander ou approuver des modifications des rôles ADMIN et POLICY_AUTHOR. La gestion des signataires et des équipes ne nécessite pas de signature d'administrateur.

État de chaque rôle

État	Signification	L'utilisateur peut-il utiliser le rôle ?
PENDING_ACTIVE	Le rôle a été accordé et est en attente d'approbation par l'administrateur.	Non
ACTIVE	Le rôle est actif.	Oui
PENDING_DISABLED	Le rôle est en cours de suppression et est en attente d'approbation par l'administrateur.	Oui, jusqu'à ce que la suppression soit approuvée
DISABLED	Le rôle a été supprimé. Il reste listé pour que ses approbations restent visibles.	Non

Approbation par l'administrateur des changements de rôle

Les administrateurs gèrent tous les rôles utilisateur. L'attribution ou la suppression du rôle ADMIN ou POLICY_AUTHOR nécessite l'approbation de plusieurs administrateurs. L'attribution ou la suppression du rôle SIGNER prend effet immédiatement à partir d'un seul administrateur, sans signature d'administrateur. Le rôle SIGNER seul n'accorde pas d'accès aux clés. Un signataire ne reçoit des parts de clé que lorsqu'un administrateur l'inclut, lui ou son équipe, dans la stratégie de clé d'un trousseau de clés et crée une clé.

Méthode	Effet sur les rôles utilisateur
CreateUser	Chaque rôle ADMIN ou POLICY_AUTHOR demandé commence par PENDING_ACTIVE. SIGNER est ACTIVE immédiatement.
EnableUserRole	Attribue un rôle. ADMIN et POLICY_AUTHOR commencent le PENDING_ACTIVE ; SIGNER est ACTIVE immédiatement.
DisableUserRole	Supprime un rôle. Pour ADMIN et POLICY_AUTHOR, un rôle ACTIVE devient PENDING_DISABLED, et un rôle PENDING_ACTIVE est annulé immédiatement, sans approbation. SIGNER devient immédiatement DISABLED.
DisableUser	Supprime tous les rôles de l'utilisateur en une seule requête, avec une seule signature pour toutes les modifications ADMIN et POLICY_AUTHOR.
ApproveUser	Enregistre l'approbation par un administrateur de la modification en attente de l'utilisateur.
EnableUser	Rétablit l'état ACTIVE pour un utilisateur désactivé. Il ne restaure aucun rôle et ne nécessite aucune approbation.

Une approbation fonctionne comme suit :

1. Un administrateur demande la modification et inclut authorizationInfo : sa signature, effectuée avec sa clé d'autorisation, sur le changement de rôle. Cette demande compte comme la première approbation.
2. D'autres administrateurs appellent ApproveUser sur l'utilisateur, chacun avec sa propre signature. Une seule approbation couvre toutes les modifications de rôle en attente pour cet utilisateur.
3. Lorsque le nombre d'approbations atteint le seuil d'approbation de l'administrateur de l'instance, toutes les modifications de rôle en attente de l'utilisateur prennent effet en même temps. Les approbations sont stockées sur l'utilisateur dans role_statuses.approval_info, et les TEE participants les vérifient.

Les règles suivantes s'appliquent à chaque modification de ADMIN et POLICY_AUTHOR :

• Au moins deux administrateurs actifs Une modification qui laisserait l'instance avec moins d'administrateurs actifs que le seuil d'approbation des administrateurs échoue avec FAILED_PRECONDITION. L'instance ne doit jamais avoir moins de deux administrateurs actifs. Les administrateurs dont le rôle est PENDING_DISABLED ne sont pas considérés comme actifs.
• Pas d'auto-approbation. L'utilisateur concerné par la modification ne peut pas demander ni approuver sa propre modification. Une telle requête échoue avec l'erreur PERMISSION_DENIED.
• Une seule approbation par administrateur. Si un administrateur approuve deux fois la même modification, la deuxième demande échoue avec l'erreur ALREADY_EXISTS.
• Une modification en attente par utilisateur. Lorsqu'une modification est en attente, les requêtes d'activation d'un rôle échouent avec l'erreur FAILED_PRECONDITION. Les demandes de désactivation d'un rôle ne sont jamais bloquées : une désactivation annule les activations en attente et est combinée à toutes les désactivations en attente en une seule nouvelle modification dont les approbations recommencent.
• Expiration. Une modification qui n'obtient pas suffisamment d'approbations d'ici le approval_info.expire_time expire, et ses rôles reviennent à leur état précédent.

Dans l'API v1beta, vous ne pouvez pas désactiver le rôle SIGNER ni l'utilisateur tant que celui-ci détient des parts de clé. Le remplacement des parts de clé d'un signataire nécessite un nouveau partage, qui est prévu pour une version ultérieure.

Autorisations IAM

Le tableau suivant liste chaque méthode v1beta, l'autorisation IAM qu'elle requiert et le rôle prédéfini disposant du moins d'autorisations qui l'inclut. Chaque rôle prédéfini inclut également toutes les autorisations des rôles précédents : roles/mpc.editor inclut roles/mpc.viewer, et roles/mpc.admin inclut roles/mpc.editor.

Ressource	Méthode	Autorisation	Rôle prédéfini
Équipe	CreateTeam	mpc.googleapis.com/teams.create	roles/mpc.admin
	DeleteTeam	mpc.googleapis.com/teams.delete	roles/mpc.admin
	GetTeam	mpc.googleapis.com/teams.get	roles/mpc.viewer
	ListTeams	mpc.googleapis.com/teams.list	roles/mpc.viewer
Utilisateur	CreateUser	mpc.googleapis.com/users.create	roles/mpc.admin
	UpdateUser	mpc.googleapis.com/users.update	roles/mpc.admin
	EnableUserRole	mpc.googleapis.com/users.enableRole	roles/mpc.admin
	DisableUserRole	mpc.googleapis.com/users.disableRole	roles/mpc.admin
	ApproveUser	mpc.googleapis.com/users.approve	roles/mpc.admin
	DisableUser	mpc.googleapis.com/users.disable	roles/mpc.admin
	EnableUser	mpc.googleapis.com/users.enable	roles/mpc.admin
	UpdateTeamAssignment	mpc.googleapis.com/users.updateTeamAssignment	roles/mpc.admin
	GetUser	mpc.googleapis.com/users.get	roles/mpc.viewer
	ListUsers	mpc.googleapis.com/users.list	roles/mpc.viewer
KeyRing	CreateKeyRing	mpc.googleapis.com/keyRings.create	roles/mpc.admin
	DeleteKeyRing	mpc.googleapis.com/keyRings.delete	roles/mpc.admin
	GetKeyRing	mpc.googleapis.com/keyRings.get	roles/mpc.viewer
	ListKeyRings	mpc.googleapis.com/keyRings.list	roles/mpc.viewer
Clé	CreateKey	mpc.googleapis.com/keys.create	roles/mpc.admin
	DisableKey	mpc.googleapis.com/keys.update	roles/mpc.editor
	GetKey	mpc.googleapis.com/keys.get	roles/mpc.viewer
	ListKeys	mpc.googleapis.com/keys.list	roles/mpc.viewer
KeyList	CreateKeyList	mpc.googleapis.com/keyLists.create	roles/mpc.admin
	DeleteKeyList	mpc.googleapis.com/keyLists.delete	roles/mpc.admin
	AddKeyListEntries	mpc.googleapis.com/keyLists.addEntries	roles/mpc.admin
	RemoveKeyListEntries	mpc.googleapis.com/keyLists.removeEntries	roles/mpc.admin
	GetKeyList	mpc.googleapis.com/keyLists.get	roles/mpc.viewer
	ListKeyLists	mpc.googleapis.com/keyLists.list	roles/mpc.viewer
TransactionPolicy	CreateTransactionPolicy	mpc.googleapis.com/transactionPolicies.create	roles/mpc.editor
	ApproveTransactionPolicy	mpc.googleapis.com/transactionPolicies.approve	roles/mpc.editor
	DisableTransactionPolicy	mpc.googleapis.com/transactionPolicies.disable	roles/mpc.editor
	GetTransactionPolicy	mpc.googleapis.com/transactionPolicies.get	roles/mpc.viewer
	ListTransactionPolicies	mpc.googleapis.com/transactionPolicies.list	roles/mpc.viewer
Transaction	CreateTransaction	mpc.googleapis.com/transactions.create	roles/mpc.editor
	RecordSignerDecision	mpc.googleapis.com/transactions.recordSignerDecision	roles/mpc.editor
	GetTransaction	mpc.googleapis.com/transactions.get	roles/mpc.viewer
	ListTransactions	mpc.googleapis.com/transactions.list	roles/mpc.viewer

Pour en savoir plus sur les requêtes et les réponses, consultez la documentation de référence de l'API REST Multi-party Compute.

Rôles prédéfinis

Rôle	Inclut	Conçu pour
Lecteur de calcul multipartite roles/mpc.viewer	Les autorisations roles/mpc.viewer du tableau précédent : get et list sur chaque ressource.	Auditeurs et outils de surveillance.
Éditeur de calcul multipartite roles/mpc.editor	Toutes les autorisations roles/mpc.viewer, plus les autorisations roles/mpc.editor du tableau précédent.	Principaux des signataires et des auteurs de règles. Leurs rôles utilisateur déterminent les méthodes que l'instance accepte de leur part.
Administrateur de calcul multipartite roles/mpc.admin	Toutes les autorisations roles/mpc.editor, plus les autorisations roles/mpc.admin du tableau précédent.	Principaux des administrateurs.

Les ressources v1beta n'ont pas leurs propres stratégies IAM. Attribuez des rôles au projet qui contient votre instance et utilisez des conditions IAM pour limiter un rôle à un trousseau de clés.

Rôles recommandés pour chaque persona

Attribuez à chaque personne un compte principal distinct, un utilisateur ne disposant que des rôles dont il a besoin et un rôle IAM correspondant :

Persona	Rôles utilisateur	Rôle IAM
Administrateur	ADMIN	roles/mpc.admin
Auteur de la règle	POLICY_AUTHOR	roles/mpc.editor ou un rôle personnalisé avec les autorisations transactionPolicies.*
Signer	SIGNER	roles/mpc.editor ou un rôle personnalisé avec les autorisations transactions.*
Auditeur	Aucun	roles/mpc.viewer

Les comptes principaux fédérés doivent également disposer du rôle Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer) sur le projet client. Pour en savoir plus, consultez Configurer la fédération des identités des employés (BYOID).

Rôles personnalisés

Pour n'accorder à un compte principal que les autorisations dont il a besoin, créez un rôle IAM personnalisé. Par exemple, le rôle suivant permet à un signataire d'afficher les transactions et de les approuver ou de les refuser, mais pas de les créer :

gcloud iam roles create mpcTransactionApprover \
  --project=PROJECT_ID \
  --title="MPC transaction approver" \
  --description="View MPC transactions and record signer decisions" \
  --permissions="mpc.googleapis.com/transactions.get,mpc.googleapis.com/transactions.list,mpc.googleapis.com/transactions.recordSignerDecision"

Remplacez PROJECT_ID par l'ID du projet contenant votre instance.

L'instance vérifie toujours l'utilisateur de l'appelant : l'utilisateur doit détenir une part de la clé de la transaction pour enregistrer une décision.

Conditions IAM

Vous pouvez limiter une liaison de rôle aux ressources d'un trousseau de clés à l'aide d'une condition IAM sur le nom de la ressource. Par exemple, si deux unités commerciales partagent une instance et que chacune possède son propre trousseau de clés, vous pouvez accorder aux signataires de chaque unité le rôle roles/mpc.editor uniquement sur leur propre trousseau de clés :

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

Remplacez les éléments suivants :

• PROJECT_ID : ID du projet contenant votre instance.
• SA_NAME : nom du compte de service.
• LOCATION : région de votre instance.
• INSTANCE_ID : ID de votre instance.
• KEYRING_ID : ID du trousseau de clés.

Les noms de ressources v1beta ne contiennent pas /mpc/. Une condition copiée à partir de la documentation de la version Preview privée (v1alpha1), telle que .../instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID, ne correspond à aucune ressource v1beta.

Les utilisateurs, les équipes, les KeyLists et les règles de transaction appartiennent à l'instance, et non à un trousseau de clés. Par conséquent, une liaison limitée à un trousseau de clés ne permet pas d'y accéder.