Sicurezza e autorizzazione

Anteprima

Questo prodotto è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Ogni richiesta all'API Multi-party Compute supera due controlli separati: un controllo di Identity and Access Management sul metodo API e un controllo sull'utente Multi-party Compute del chiamante e sui suoi ruoli. In questa pagina vengono descritti entrambi i controlli, le autorizzazioni IAM e il modo in cui gli amministratori approvano le modifiche ai ruoli utente.

Come viene autorizzata una richiesta

1. Controllo IAM. Prima che una richiesta raggiunga la tua istanza, IAM verifica che l'entità chiamante disponga dell'autorizzazione richiesta dal metodo sulla risorsa nella richiesta. In caso contrario, la richiesta non va a buon fine con 403 PERMISSION_DENIED e non raggiunge mai l'istanza. La richiesta viene registrata in Cloud Audit Logs. Per l'autorizzazione richiesta da ogni metodo, consulta Autorizzazioni IAM.
2. Controllo di utenti e ruoli. Per i metodi che agiscono per conto di un utente, l'istanza cerca l'utente il cui principal corrisponde all'identità autenticata del chiamante e controlla i ruoli di quell'utente. Ad esempio, il chiamante di CreateTransaction deve essere un utente con il ruolo SIGNER. Per i controlli eseguiti da ciascun metodo, consulta Ruoli utente.

Entrambi i controlli devono essere superati. I ruoli IAM e i ruoli utente sono complementari, ad esempio:

• Un'entità che dispone di roles/mpc.editor, ma non di Utente con il ruolo POLICY_AUTHOR, può chiamare CreateTransactionPolicy, ma l'istanza rifiuta la richiesta.
• Un utente con il ruolo SIGNER la cui entità non dispone di mpc.googleapis.com/transactions.create non può creare transazioni, perché IAM rifiuta prima la richiesta.

Anche le approvazioni contengono una firma. I firmatari, gli autori delle policy e gli amministratori firmano ogni approvazione con la chiave di autorizzazione registrata nel loro utente. In questo modo, i criteri e le transazioni non sono manomissibili e lasciano tracce di audit permanenti.

I Trusted Execution Environment (TEE) dei partecipanti verificano queste firme prima di firmare una transazione o accettare una policy di transazione, quindi una richiesta che supera entrambi i controlli non può comunque produrre una firma senza approvazioni valide. Per saperne di più, consulta il modello di sicurezza.

Ruoli utente

Ogni utente ha uno dei seguenti ruoli, impostati in User.roles. Questo ruolo è un ruolo nella tua istanza, non un ruolo IAM.

Ruolo utente	Cosa può fare l'utente	Data del controllo
SIGNER	Contiene le condivisioni delle chiavi e approva le transazioni. Appartiene esattamente a un team.	CreateTransaction: l'utente del chiamante deve avere il ruolo SIGNER. RecordSignerDecision: l'utente del chiamante deve possedere una condivisione della chiave della transazione. ListTransactions: se l'utente del chiamante ha solo il ruolo SIGNER, vengono restituite solo le transazioni sulle chiavi per le quali l'utente possiede una condivisione della chiave.
POLICY_AUTHOR	Propone, approva e disattiva le policy di transazione.	CreateTransactionPolicy, ApproveTransactionPolicy, DisableTransactionPolicy: l'utente del chiamante deve essere un autore di policy attivo con una chiave di autorizzazione registrata.
ADMIN	Gestisce utenti, team, keyring, chiavi ed elenchi di chiavi. Approva le modifiche ai ruoli ADMIN e POLICY_AUTHOR.	EnableUserRole, DisableUserRole, DisableUser, ApproveUser per le modifiche di ADMIN e POLICY_AUTHOR: la richiesta deve contenere la firma dell'amministratore chiamante. Consulta Approvazione da parte dell'amministratore delle modifiche ai ruoli.

Agli Utenti si applicano le seguenti regole:

• Un'entità per utente. User.principal viene impostato quando crei l'utente e non può essere modificato. È un Account Google o un'entità della federazione delle identità della forza lavoro. Per modificare l'entità di un utente, disattiva l'utente e creane uno nuovo.
• Un team per firmatario. Un utente con il ruolo SIGNER deve avere Team impostato. Solo gli utenti con il ruolo SIGNER possono detenere condivisioni di chiavi, quindi solo i firmatari appartengono a un team. Lo spostamento di un firmatario in un altro team utilizza UpdateTeamAssignment, che richiede la nuova condivisione, prevista per una versione successiva.
• Chiavi di autorizzazione. I firmatari e gli autori delle policy hanno bisogno di una chiave di autorizzazione per firmare le approvazioni. Gli amministratori ne hanno bisogno per richiedere o approvare modifiche ai ruoli ADMIN e POLICY_AUTHOR; la gestione dei firmatari e dei team non richiede la firma di un amministratore.

Stato di ogni ruolo

Stato	Significato	L'utente può utilizzare il ruolo?
PENDING_ACTIVE	Il ruolo è stato concesso ed è in attesa dell'approvazione dell'amministratore.	No
ACTIVE	Il ruolo è attivo.	Sì
PENDING_DISABLED	Il ruolo è in fase di rimozione ed è in attesa dell'approvazione dell'amministratore.	Sì, fino a quando la rimozione non viene approvata
DISABLED	Il ruolo è stato rimosso. Il gioco rimane in elenco, quindi le relative approvazioni rimangono visibili.	No

Approvazione da parte dell'amministratore delle modifiche ai ruoli

Gli amministratori gestiscono tutti i ruoli utente. La concessione o la rimozione del ruolo ADMIN o POLICY_AUTHOR richiede l'approvazione di diversi amministratori. La concessione o la rimozione del ruolo SIGNER ha effetto immediato da un singolo amministratore, senza la firma di un amministratore. Il ruolo SIGNER da solo non concede l'accesso alle chiavi; un Signer riceve le condivisioni delle chiavi solo quando un Admin include il Signer o il suo Team nella policy delle chiavi di un KeyRing e crea una chiave.

Metodo	Effetto sui ruoli utente
CreateUser	Ogni ruolo ADMIN o POLICY_AUTHOR richiesto inizia in PENDING_ACTIVE. SIGNER è ACTIVE immediatamente.
EnableUserRole	Concede un ruolo. ADMIN e POLICY_AUTHOR iniziano il giorno PENDING_ACTIVE; SIGNER è ACTIVE immediatamente.
DisableUserRole	Rimuove un ruolo. Per ADMIN e POLICY_AUTHOR, un ruolo ACTIVE diventa PENDING_DISABLED e un ruolo PENDING_ACTIVE viene annullato immediatamente, senza approvazione. SIGNER diventa immediatamente DISABLED.
DisableUser	Rimuove tutti i ruoli dell'utente in un'unica richiesta, con una firma per tutte le modifiche di ADMIN e POLICY_AUTHOR.
ApproveUser	Registra l'approvazione di un amministratore della modifica in attesa dell'utente.
EnableUser	Ripristina un utente disattivato su ACTIVE. Non ripristina alcun ruolo e non richiede approvazione.

Un'approvazione funziona nel seguente modo:

1. Un amministratore richiede la modifica e include authorizationInfo: la sua firma, creata con la sua chiave di autorizzazione, sulla modifica del ruolo. Questa richiesta viene conteggiata come prima approvazione.
2. Altri amministratori chiamano ApproveUser sull'utente, ciascuno con la propria firma. Un'approvazione copre ogni modifica del ruolo in attesa di quell'utente.
3. Quando il numero di approvazioni raggiunge la soglia di approvazione dell'amministratore dell'istanza, tutte le modifiche dei ruoli in attesa dell'utente diventano effettive contemporaneamente. Le approvazioni vengono memorizzate nell'utente in role_statuses.approval_info e i TEE dei partecipanti le verificano.

Le seguenti regole si applicano a ogni modifica di ADMIN e POLICY_AUTHOR:

• Almeno due amministratori attivi. Una modifica che lascerebbe l'istanza con un numero di amministratori attivi inferiore alla soglia di approvazione degli amministratori non va a buon fine con FAILED_PRECONDITION. L'istanza non ha mai meno di due amministratori attivi. Gli amministratori con il ruolo PENDING_DISABLED non vengono conteggiati come attivi.
• Nessuna autoapprovazione. L'utente che viene modificato non può richiedere o approvare la propria modifica. Una richiesta di questo tipo non va a buon fine e restituisce PERMISSION_DENIED.
• Un'approvazione per amministratore. Se un amministratore approva la stessa modifica due volte, la seconda richiesta non va a buon fine e viene visualizzato l'errore ALREADY_EXISTS.
• Una modifica in attesa per utente. Mentre una modifica è in attesa, le richieste di abilitazione di un ruolo non vanno a buon fine con FAILED_PRECONDITION. Le richieste di disattivazione di un ruolo non vengono mai bloccate: una disattivazione annulla le attivazioni in attesa e viene combinata con eventuali disattivazioni in attesa in una nuova modifica le cui approvazioni ricominciano da capo.
• Scadenza. Una modifica che non riceve un numero sufficiente di approvazioni entro il giorno approval_info.expire_time scade e i relativi ruoli tornano allo stato precedente.

Nell'API v1beta, non puoi disattivare il ruolo SIGNER o l'utente mentre quest'ultimo detiene condivisioni di chiavi. La sostituzione delle condivisioni di chiavi di un firmatario richiede la ricondivisione, che è prevista per una release successiva.

Autorizzazioni IAM

La tabella seguente elenca ogni metodo v1beta, l'autorizzazione IAM richiesta e il ruolo predefinito con il minor numero di autorizzazioni che lo include. Ogni ruolo predefinito include anche tutte le autorizzazioni dei ruoli precedenti: roles/mpc.editor include roles/mpc.viewer e roles/mpc.admin include roles/mpc.editor.

Risorsa	Metodo	Autorizzazione	Ruolo predefinito
Team	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
Utente	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
Chiave	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
Transazione	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

Per i dettagli sulla richiesta e sulla risposta, consulta il riferimento REST dell'API Multi-party Compute.

Ruoli predefiniti

Ruolo	Include	Destinato a
Multi-party Compute Viewer roles/mpc.viewer	Le autorizzazioni roles/mpc.viewer nella tabella precedente: get e list su ogni risorsa.	Revisori e strumenti di monitoraggio.
Multi-party Compute Editor roles/mpc.editor	Tutte le autorizzazioni roles/mpc.viewer, più le autorizzazioni roles/mpc.editor nella tabella precedente.	Principals of Signers and Policy Authors. I ruoli utente determinano quali di questi metodi l'istanza accetta.
Multi-party Compute Admin roles/mpc.admin	Tutte le autorizzazioni roles/mpc.editor, più le autorizzazioni roles/mpc.admin nella tabella precedente.	Entità degli amministratori.

Le risorse v1beta non hanno policy IAM proprie. Concedi i ruoli nel progetto che contiene l'istanza e utilizza le condizioni IAM per restringere un ruolo a un keyring.

Ruoli consigliati per ogni persona

Assegna a ogni persona un'entità distinta, un utente con solo i ruoli di cui ha bisogno e un ruolo IAM corrispondente:

Utente tipo	Ruoli utente	Ruolo IAM
Amministratore	ADMIN	roles/mpc.admin
Autore delle policy	POLICY_AUTHOR	roles/mpc.editor o un ruolo personalizzato con le autorizzazioni transactionPolicies.*
Firmatario	SIGNER	roles/mpc.editor o un ruolo personalizzato con le autorizzazioni transactions.*
Revisore	Nessuno	roles/mpc.viewer

Le entità federate devono avere anche il ruolo Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) nel progetto consumer. Per ulteriori informazioni, consulta Configura la federazione delle identità per la forza lavoro (BYOID).

Ruoli personalizzati

Per concedere a un'entità solo le autorizzazioni di cui ha bisogno, crea un ruolo IAM personalizzato. Ad esempio, il seguente ruolo consente a un firmatario di visualizzare le transazioni e di approvarle o rifiutarle, ma non di crearle:

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"

Sostituisci PROJECT_ID con l'ID del progetto che contiene l'istanza.

L'istanza controlla comunque l'utente chiamante: l'utente deve possedere una condivisione della chiave della transazione per registrare una decisione.

Condizioni IAM

Puoi restringere un'associazione di ruoli alle risorse in un KeyRing con una condizione IAM sul nome della risorsa. Ad esempio, se due unità aziendali condividono un'istanza e ognuna ha il proprio KeyRing, puoi concedere ai firmatari di ogni unità roles/mpc.editor solo sul proprio KeyRing:

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"

Sostituisci quanto segue:

• PROJECT_ID: l'ID del progetto che contiene l'istanza.
• SA_NAME: il nome del account di servizio.
• LOCATION: la regione dell'istanza.
• INSTANCE_ID: l'ID dell'istanza.
• KEYRING_ID: l'ID del keyring.

I nomi delle risorse v1beta non contengono /mpc/. Una condizione copiata dalla documentazione di Anteprima privata (v1alpha1), ad esempio .../instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID, non corrisponde ad alcuna risorsa v1beta.

Utenti, team, KeyList e policy di transazione appartengono all'istanza, non a un keyring, quindi un'associazione con ambito keyring non concede l'accesso a questi elementi.