Sicherheit und Autorisierung

Vorschau

Dieses Produkt unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Jede Anfrage an die Multi-Party Compute API durchläuft zwei separate Prüfungen: eine Identity and Access Management-Prüfung der API-Methode und eine Prüfung des Multi-Party Compute-Nutzers des Aufrufers und seiner Rollen. Auf dieser Seite werden beide Prüfungen, die IAM-Berechtigungen und die Genehmigung von Änderungen an den Nutzerrollen durch Administratoren beschrieben.

So wird eine Anfrage autorisiert

1. IAM-Prüfung. Bevor eine Anfrage Ihre Instanz erreicht, prüft IAM, ob das aufrufende Hauptkonto die Berechtigung hat, die die Methode für die Ressource in der Anfrage erfordert. Andernfalls schlägt die Anfrage mit 403 PERMISSION_DENIED fehl und erreicht die Instanz nicht. Die Anfrage wird in Cloud-Audit-Logs aufgezeichnet. Informationen zu den für die einzelnen Methoden erforderlichen Berechtigungen finden Sie unter IAM-Berechtigungen.
2. Nutzer- und Rollenprüfung Bei Methoden, die im Namen eines Nutzers ausgeführt werden, sucht die Instanz nach dem Nutzer, dessen principal mit der authentifizierten Identität des Aufrufers übereinstimmt, und prüft die Rollen dieses Nutzers. Der Aufrufer von CreateTransaction muss beispielsweise ein Nutzer mit der Rolle SIGNER sein. Informationen zu den Prüfungen, die bei jeder Methode durchgeführt werden, finden Sie unter Nutzerrollen.

Beide Prüfungen müssen bestanden werden. IAM-Rollen und Nutzerrollen ergänzen sich, zum Beispiel:

• Ein Hauptkonto mit roles/mpc.editor, aber ohne Nutzer mit der Rolle POLICY_AUTHOR, kann CreateTransactionPolicy aufrufen, die Instanz lehnt die Anfrage jedoch ab.
• Ein Nutzer mit der Rolle SIGNER, dessen Hauptkonto nicht über mpc.googleapis.com/transactions.create verfügt, kann keine Transaktionen erstellen, da IAM die Anfrage zuerst ablehnt.

Genehmigungen enthalten auch eine Signatur. Unterzeichner, Richtlinienautoren und Administratoren signieren jede Genehmigung mit dem Autorisierungsschlüssel, der für ihren Nutzer registriert ist. So wird sichergestellt, dass Richtlinien und Transaktionen nicht manipuliert werden können und dauerhafte Audit-Trails hinterlassen.

Die vertrauenswürdigen Ausführungsumgebungen (TEEs) der Teilnehmer prüfen diese Signaturen, bevor sie eine Transaktion signieren oder eine Transaktionsrichtlinie akzeptieren. Eine Anfrage, die beide Prüfungen besteht, kann also ohne gültige Genehmigungen keine Signatur erzeugen. Weitere Informationen finden Sie im Sicherheitsmodell.

Nutzerrollen

Jeder Nutzer hat eine der folgenden Rollen, die in User.roles festgelegt sind. Diese Rolle ist eine Rolle in Ihrer Instanz, keine IAM-Rolle.

Nutzerrolle	Was der Nutzer tun kann	Geprüft am
SIGNER	Enthält Schlüsselfreigaben und genehmigt Transaktionen. Gehört zu genau einem Team.	CreateTransaction: Der Nutzer des Aufrufers muss die Rolle SIGNER haben. RecordSignerDecision: Der Nutzer des Aufrufers muss einen Schlüsselfreigabe des Transaktionsschlüssels haben. ListTransactions: Wenn der Nutzer des Aufrufers nur die Rolle SIGNER hat, werden nur Transaktionen für Schlüssel zurückgegeben, für die der Nutzer eine Schlüsselfreigabe hat.
POLICY_AUTHOR	Schlägt Transaktionsrichtlinien vor, genehmigt sie und deaktiviert sie.	CreateTransactionPolicy, ApproveTransactionPolicy, DisableTransactionPolicy: Der Nutzer des Aufrufers muss ein aktiver Richtlinienautor mit einem registrierten Autorisierungsschlüssel sein.
ADMIN	Verwaltet Nutzer, Teams, Schlüsselbunde, Schlüssel und Schlüssellisten. Genehmigt Änderungen an den Rollen ADMIN und POLICY_AUTHOR.	EnableUserRole, DisableUserRole, DisableUser, ApproveUser für ADMIN und POLICY_AUTHOR: Die Anfrage muss die Signatur des aufrufenden Administrators enthalten. Weitere Informationen finden Sie unter Genehmigung von Rollenänderungen durch Administratoren.

Für Nutzer gelten die folgenden Regeln:

• Ein Hauptkonto pro Nutzer. User.principal wird beim Erstellen des Nutzers festgelegt und kann nicht geändert werden. Es ist ein Google-Konto oder ein Hauptkonto der Mitarbeiteridentitätsföderation. Wenn Sie das Hauptkonto eines Nutzers ändern möchten, deaktivieren Sie den Nutzer und erstellen Sie einen neuen.
• Ein Team pro Unterzeichner. Für einen Nutzer mit der Rolle SIGNER muss Team festgelegt sein. Nur Nutzer mit der Rolle SIGNER können Schlüsselanteile haben. Daher gehören nur Signierer zu einem Team. Wenn ein Signer in ein anderes Team verschoben wird, wird UpdateTeamAssignment verwendet. Dazu ist eine erneute Freigabe erforderlich, die für eine spätere Version geplant ist.
• Autorisierungsschlüssel: Unterzeichner und Richtlinienautoren benötigen einen Autorisierungsschlüssel, um Genehmigungen zu signieren. Administratoren benötigen eine, um Änderungen an den Rollen ADMIN und POLICY_AUTHOR anzufordern oder zu genehmigen. Für die Verwaltung von Unterzeichnern und Teams ist keine Administratorsignatur erforderlich.

Status der einzelnen Rollen

Status	Bedeutung	Kann der Nutzer die Rolle verwenden?
PENDING_ACTIVE	Die Rolle wurde gewährt und wartet auf die Genehmigung durch den Administrator.	Nein
ACTIVE	Die Rolle ist wirksam.	Ja
PENDING_DISABLED	Die Rolle wird entfernt und wartet auf die Genehmigung durch den Administrator.	Ja, bis die Entfernung genehmigt wurde
DISABLED	Die Rolle wurde entfernt. Es bleibt gelistet, damit die Genehmigungen sichtbar bleiben.	Nein

Administratorgenehmigung von Rollenänderungen

Administratoren verwalten alle Nutzerrollen. Für das Zuweisen oder Entfernen der Rolle ADMIN oder POLICY_AUTHOR ist die Genehmigung mehrerer Administratoren erforderlich. Das Zuweisen oder Entfernen der Rolle SIGNER wird sofort von einem einzelnen Administrator ohne Administratorsignatur wirksam. Die Rolle SIGNER allein gewährt keinen Zugriff auf Schlüssel. Ein Signer erhält nur dann Schlüsselanteile, wenn ein Administrator den Signer oder sein Team in die Schlüsselrichtlinie eines KeyRings aufnimmt und einen Schlüssel erstellt.

Methode	Auswirkungen auf Nutzerrollen
CreateUser	Jede angeforderte ADMIN- oder POLICY_AUTHOR-Rolle beginnt in PENDING_ACTIVE. SIGNER ist sofort ACTIVE.
EnableUserRole	Weist eine Rolle zu. ADMIN und POLICY_AUTHOR beginnen in PENDING_ACTIVE; SIGNER ist sofort ACTIVE.
DisableUserRole	Entfernt eine Rolle. Bei ADMIN und POLICY_AUTHOR wird eine ACTIVE-Rolle zu PENDING_DISABLED und eine PENDING_ACTIVE-Rolle wird sofort ohne Genehmigung gekündigt. SIGNER wird sofort zu DISABLED.
DisableUser	Entfernt alle Rollen des Nutzers in einer Anfrage mit einer Signatur für alle ADMIN- und POLICY_AUTHOR-Änderungen.
ApproveUser	Zeichnet die Genehmigung der ausstehenden Änderung des Nutzers durch einen Administrator auf.
EnableUser	Setzt einen deaktivierten Nutzer auf ACTIVE zurück. Es werden keine Rollen wiederhergestellt und es ist keine Genehmigung erforderlich.

Eine Genehmigung funktioniert so:

1. Ein Administrator fordert die Änderung an und fügt authorizationInfo hinzu: seine Signatur, die mit seinem Autorisierungsschlüssel erstellt wurde, über die Rollenänderung. Diese Anfrage gilt als erste Genehmigung.
2. Andere Administratoren rufen ApproveUser für den Nutzer auf, jeweils mit ihrer eigenen Signatur. Eine Genehmigung deckt alle ausstehenden Rollenänderungen dieses Nutzers ab.
3. Wenn die Anzahl der Genehmigungen den Schwellenwert für die Administratorgenehmigung der Instanz erreicht, werden alle ausstehenden Rollenänderungen des Nutzers zusammen wirksam. Die Genehmigungen werden beim Nutzer in role_statuses.approval_info gespeichert und von den TEEs der Teilnehmer überprüft.

Für jede Änderung von ADMIN und POLICY_AUTHOR gelten die folgenden Regeln:

• Mindestens zwei aktive Administratoren Eine Änderung, die dazu führen würde, dass die Instanz weniger aktive Administratoren als den Schwellenwert für die Administratorgenehmigung hat, schlägt mit FAILED_PRECONDITION fehl. Die Instanz hat immer mindestens zwei aktive Administratoren. Administratoren mit der Rolle PENDING_DISABLED gelten nicht als aktiv.
• Keine Selbstgenehmigung: Der Nutzer, dessen Rolle geändert wird, kann die Änderung nicht selbst beantragen oder genehmigen. Eine solche Anfrage schlägt mit PERMISSION_DENIED fehl.
• Eine Genehmigung pro Administrator. Wenn ein Administrator dieselbe Änderung zweimal genehmigt, schlägt die zweite Anfrage mit ALREADY_EXISTS fehl.
• Pro Nutzer ist nur eine ausstehende Änderung zulässig. Solange eine Änderung aussteht, schlagen Anfragen zum Aktivieren einer Rolle mit FAILED_PRECONDITION fehl. Anfragen zum Deaktivieren einer Rolle werden nie blockiert: Durch das Deaktivieren werden ausstehende Aktivierungen abgebrochen und mit allen ausstehenden Deaktivierungen zu einer neuen Änderung kombiniert, deren Genehmigungen von vorn beginnen.
• Ablaufdatum: Eine Änderung, die bis zum approval_info.expire_time nicht genügend Genehmigungen erhält, läuft ab und die Rollen werden in ihren vorherigen Status zurückgesetzt.

In der v1beta API können Sie die Rolle SIGNER oder den Nutzer nicht deaktivieren, solange der Nutzer Schlüsselfreigaben hat. Das Ersetzen der Schlüsselfreigaben eines Signierers erfordert eine erneute Freigabe, die für eine spätere Version geplant ist.

IAM-Berechtigungen

In der folgenden Tabelle sind die einzelnen v1beta-Methoden, die jeweils erforderliche IAM-Berechtigung und die vordefinierte Rolle mit den wenigsten Berechtigungen aufgeführt, die diese Berechtigung enthält. Jede vordefinierte Rolle enthält auch alle Berechtigungen der Rollen davor: roles/mpc.editor enthält roles/mpc.viewer und roles/mpc.admin enthält roles/mpc.editor.

Ressource	Methode	Berechtigung	Vordefinierte Rolle
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
Nutzer	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
Schlüssel	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
Transaktion	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

Details zu Anfragen und Antworten finden Sie in der REST-Referenz zur Multi-Party Computation API.

Vordefinierte Rollen

Rolle	Enthält	Gedacht für
Multi-Party Compute Viewer roles/mpc.viewer	Die roles/mpc.viewer-Berechtigungen in der vorherigen Tabelle: get und list für jede Ressource.	Auditoren und Monitoring-Tools.
Multi-Party Compute Editor roles/mpc.editor	Alle roles/mpc.viewer-Berechtigungen sowie die roles/mpc.editor-Berechtigungen in der vorherigen Tabelle.	Hauptkonten von Signierern und Richtlinienautoren. Die Nutzerrollen bestimmen, welche dieser Methoden die Instanz von ihnen akzeptiert.
Multi-Party Compute Admin roles/mpc.admin	Alle roles/mpc.editor-Berechtigungen sowie die roles/mpc.admin-Berechtigungen in der vorherigen Tabelle.	Hauptkonten von Administratoren.

v1beta-Ressourcen haben keine eigenen IAM-Richtlinien. Weisen Sie Rollen für das Projekt zu, das Ihre Instanz enthält, und verwenden Sie IAM-Bedingungen, um eine Rolle auf einen Schlüsselbund zu beschränken.

Empfohlene Rollen für jede Persona

Weisen Sie jeder Person ein eigenes Hauptkonto, einen Nutzer mit nur den erforderlichen Rollen und eine entsprechende IAM-Rolle zu:

Persona	Nutzerrollen	IAM-Rolle
Admin	ADMIN	roles/mpc.admin
Richtlinienautor	POLICY_AUTHOR	roles/mpc.editor oder eine benutzerdefinierte Rolle mit den Berechtigungen transactionPolicies.*
Signer	SIGNER	roles/mpc.editor oder eine benutzerdefinierte Rolle mit den Berechtigungen transactions.*
Auditor	Keine	roles/mpc.viewer

Föderierte Hauptkonten benötigen außerdem die Rolle „Service Usage Consumer“ (roles/serviceusage.serviceUsageConsumer) für das Nutzerprojekt. Weitere Informationen finden Sie unter Workforce Identity Federation (BYOID) konfigurieren.

Benutzerdefinierte Rollen

Wenn Sie einem Hauptkonto nur die erforderlichen Berechtigungen gewähren möchten, erstellen Sie eine benutzerdefinierte IAM-Rolle. Mit der folgenden Rolle kann ein Unterzeichner beispielsweise Transaktionen ansehen und genehmigen oder ablehnen, aber nicht erstellen:

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"

Ersetzen Sie PROJECT_ID durch die ID des Projekts, das Ihre Instanz enthält.

Die Instanz prüft weiterhin den Nutzer des Aufrufers: Der Nutzer muss einen Schlüsselfreigabe des Transaktionsschlüssels haben, um eine Entscheidung aufzuzeichnen.

IAM-Bedingungen

Sie können eine Rollenbindung auf die Ressourcen in einem Schlüsselbund mit einer IAM-Bedingung für den Ressourcennamen beschränken. Wenn beispielsweise zwei Geschäftseinheiten eine Instanz gemeinsam nutzen und jede einen eigenen Schlüsselbund hat, können Sie den Signierern der einzelnen Einheiten roles/mpc.editor nur für ihren eigenen Schlüsselbund gewähren:

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/keyRings/KEYRING_ID'),title=keyring-scoped-editor"

Ersetzen Sie Folgendes:

• PROJECT_ID: die ID des Projekts, das die Instanz enthält.
• SA_NAME ist der Name des Dienstkontos.
• LOCATION: die Region Ihrer Instanz.
• INSTANCE_ID: die ID Ihrer Instanz.
• KEYRING_ID: die ID des Schlüsselbunds.

v1beta-Ressourcennamen enthalten nicht /mpc/. Eine Bedingung, die aus der Dokumentation zur privaten Vorabversion (v1alpha1) kopiert wurde, z. B. .../instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID, stimmt mit keiner v1beta-Ressource überein.

Nutzer, Teams, KeyLists und Transaktionsrichtlinien gehören zur Instanz, nicht zu einem KeyRing. Daher gewährt eine Bindung auf KeyRing-Ebene keinen Zugriff auf sie.