Multi-party Compute API へのすべてのリクエストは、API メソッドに対する Identity and Access Management チェックと、呼び出し元の Multi-party Compute ユーザーとそのロールに対するチェックの 2 つの個別のチェックを通過します。このページでは、両方のチェック、IAM 権限、管理者がユーザーロールの変更を承認する方法について説明します。
リクエストの認可方法
- IAM チェック。リクエストがインスタンスに到達する前に、IAM は、呼び出し元のプリンシパルが、リクエスト内のリソースに対してメソッドが必要とする権限を持っていることを確認します。一致しない場合、リクエストは
403 PERMISSION_DENIEDで失敗し、インスタンスに到達しません。リクエストは Cloud Audit Logs に記録されます。各メソッドに必要な権限については、IAM 権限をご覧ください。 - ユーザーとロールの確認。ユーザーに代わって動作するメソッドの場合、インスタンスは
principalが呼び出し元の認証済み ID と一致するユーザーを検索し、そのユーザーのロールを確認します。たとえば、CreateTransactionの呼び出し元は、SIGNERロールを持つユーザーである必要があります。各メソッドで行われるチェックについては、ユーザーロールをご覧ください。
両方のチェックに合格する必要があります。IAM ロールとユーザーロールは補完的なものです。たとえば、
roles/mpc.editorを持つプリンシパルは、POLICY_AUTHORロールを持つユーザーがいない場合でもCreateTransactionPolicyを呼び出すことができますが、インスタンスはリクエストを拒否します。SIGNERロールを持つユーザーのプリンシパルにmpc.googleapis.com/transactions.createがない場合、IAM が最初にリクエストを拒否するため、トランザクションを作成できません。
承認には署名も含まれます。署名者、ポリシー作成者、管理者は、ユーザーに登録されている認証鍵を使用して各承認に署名します。これにより、ポリシーとトランザクションが改ざんされることなく、耐久性のある監査証跡が残ります。
参加者の高信頼実行環境（TEE）は、トランザクションに署名するか、トランザクション ポリシーを受け入れる前に、これらの署名を検証します。そのため、両方のチェックに合格したリクエストでも、有効な承認がなければ署名を生成できません。詳細については、セキュリティ モデルをご覧ください。
ユーザーロール
各ユーザーには、User.roles で設定された次のいずれかのロールがあります。このロールはインスタンス内のロールであり、IAM ロールではありません。
| ユーザー ロール | お客様ができること | 確認日時 |
|---|---|---|
SIGNER |
鍵の共有を保持し、トランザクションを承認します。1 つのチームにのみ属します。 | CreateTransaction: 呼び出し元のユーザーに SIGNER ロールが付与されている必要があります。RecordSignerDecision: 呼び出し元のユーザーが、トランザクションの鍵の鍵共有を保持している必要があります。ListTransactions: 呼び出し元のユーザーに SIGNER ロールのみが付与されている場合、ユーザーが鍵共有を保持している鍵のトランザクションのみが返されます。 |
POLICY_AUTHOR |
トランザクション ポリシーを提案、承認、無効にします。 | CreateTransactionPolicy、ApproveTransactionPolicy、DisableTransactionPolicy: 呼び出し元のユーザーは、登録済みの認証キーを持つアクティブなポリシー作成者である必要があります。 |
ADMIN |
ユーザー、チーム、KeyRing、鍵、KeyList を管理します。ADMIN ロールと POLICY_AUTHOR ロールの変更を承認します。 |
EnableUserRole、DisableUserRole、DisableUser、ApproveUser（ADMIN と POLICY_AUTHOR の変更の場合）: リクエストには、呼び出し元の管理者の署名が含まれている必要があります。ロール変更の管理者承認をご覧ください。 |
ユーザーには次のルールが適用されます。
- ユーザーごとに 1 つのプリンシパル。
User.principalはユーザーの作成時に設定され、変更できません。Google アカウントまたは Workforce Identity 連携のプリンシパルです。ユーザーのプリンシパルを変更するには、ユーザーを無効にして新しいユーザーを作成します。 - 署名者ごとに 1 つのチーム。
SIGNERロールを持つユーザーにはTeamが設定されている必要があります。SIGNERロールを持つユーザーのみが鍵共有を保持できるため、チームに所属できるのは署名者のみです。署名者を別のチームに移動するにはUpdateTeamAssignmentを使用します。これには再共有が必要ですが、これは今後のリリースで予定されています。 - 認証鍵。署名者とポリシー作成者が承認に署名するには、認証鍵が必要です。管理者は、
ADMINロールとPOLICY_AUTHORロールの変更をリクエストまたは承認するために、1 つの署名が必要です。署名者とチームの管理には、管理者の署名は必要ありません。
各ロールのステータス
| ステータス | 意味 | ユーザーはロールを使用できるか？ |
|---|---|---|
PENDING_ACTIVE |
ロールが付与され、管理者の承認を待機しています。 | いいえ |
ACTIVE |
ロールが有効である。 | はい |
PENDING_DISABLED |
ロールは削除中で、管理者の承認を待っています。 | はい。削除が承認されるまで表示されます。 |
DISABLED |
ロールが削除されました。承認が表示されたままになるように、リストに表示されたままになります。 | いいえ |
ロール変更の管理者による承認
管理者はすべてのユーザーロールを管理します。ADMIN ロールまたは POLICY_AUTHOR ロールを付与または削除するには、複数の管理者の承認が必要です。SIGNER ロールの付与または削除は、管理者の署名なしで、1 人の管理者からすぐに有効になります。SIGNER ロールだけでは鍵へのアクセス権は付与されません。署名者が鍵共有を受け取るのは、管理者が鍵リングの鍵ポリシーに署名者またはそのチームを含めて鍵を作成した場合のみです。
| メソッド | ユーザーロールへの影響 |
|---|---|
CreateUser |
リクエストされた各 ADMIN ロールまたは POLICY_AUTHOR ロールは PENDING_ACTIVE で始まります。SIGNER はすぐに ACTIVE になります。 |
EnableUserRole |
1 つのロールを付与します。ADMIN と POLICY_AUTHOR は PENDING_ACTIVE で開始。SIGNER はすぐに ACTIVE。 |
DisableUserRole |
1 つのロールを削除します。ADMIN と POLICY_AUTHOR の場合、ACTIVE ロールは PENDING_DISABLED になり、PENDING_ACTIVE ロールは承認なしですぐにキャンセルされます。SIGNER はすぐに DISABLED になります。 |
DisableUser |
1 つのリクエストですべての ADMIN と POLICY_AUTHOR の変更に対して 1 つの署名を使用して、ユーザーのすべてのロールを削除します。 |
ApproveUser |
ユーザーの保留中の候補に対する 1 人の管理者の承認を記録します。 |
EnableUser |
無効になっているユーザーを ACTIVE に戻します。ロールは復元されず、承認も必要ありません。 |
承認は次のように機能します。
- 管理者が変更をリクエストし、
authorizationInfo（ロール変更に関する承認キーで作成された署名）を含めます。このリクエストは最初の承認としてカウントされます。 - 他の管理者は、それぞれ独自の署名を使用して、ユーザーに対して
ApproveUserを呼び出します。1 つの承認で、そのユーザーの保留中のロール変更すべてが対象となります。 - 承認数がインスタンスの管理者承認のしきい値に達すると、ユーザーの保留中のロール変更がすべて有効になります。承認は
role_statuses.approval_infoのユーザーに保存され、参加者の TEE が承認を検証します。
ADMIN と POLICY_AUTHOR のすべての変更には、次のルールが適用されます。
- 有効な管理者が 2 人以上いる。変更によってインスタンスのアクティブな管理者が管理者承認のしきい値を下回る場合、
FAILED_PRECONDITIONで失敗します。インスタンスには、常に 2 人以上のアクティブな管理者が存在します。ロールがPENDING_DISABLEDの管理者は、アクティブとしてカウントされません。 - 自己承認は不可。変更対象のユーザーは、自身の変更をリクエストまたは承認することはできません。このようなリクエストは
PERMISSION_DENIEDで失敗します。 - 承認は管理者 1 人につき 1 回です。管理者が同じ変更を 2 回承認すると、2 回目のリクエストは
ALREADY_EXISTSで失敗します。 - ユーザーごとに 1 つの保留中の候補。変更が保留中の間は、ロールを有効にするリクエストは
FAILED_PRECONDITIONで失敗します。ロールを無効にするリクエストがブロックされることはありません。無効にすると、保留中の有効化がキャンセルされ、保留中の無効化と組み合わされて 1 つの新しい変更になり、承認が最初からやり直されます。 - 有効期限。
approval_info.expire_timeまでに十分な承認が得られなかった変更は期限切れとなり、ロールは以前のステータスに戻ります。
v1beta API では、ユーザーが鍵共有を保持している間は、SIGNER ロールを無効にしたり、ユーザーを無効にしたりすることはできません。署名者の鍵共有を置き換えるには、再共有が必要です。これは、今後のリリースで予定されています。
IAM の権限
次の表に、各 v1beta メソッド、必要な IAM 権限、その権限を含む最小限の権限を持つ事前定義ロールを示します。各事前定義ロールには、それより前のロールのすべての権限も含まれています。roles/mpc.editor には roles/mpc.viewer が含まれ、roles/mpc.admin には roles/mpc.editor が含まれます。
| リソース | メソッド | 権限 | 事前定義ロール |
|---|---|---|---|
| チーム | 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 |
|
| ユーザー | 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 |
|
| キー | 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 |
|
| トランザクション | 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 |
リクエストとレスポンスの詳細については、マルチパーティ コンピューティング API REST リファレンスをご覧ください。
事前定義ロール
| ロール | 含める | 対象 |
|---|---|---|
マルチパーティ コンピューティング閲覧者roles/mpc.viewer |
上記の表の roles/mpc.viewer 権限: すべてのリソースに対する get と list。 |
監査者とモニタリング ツール。 |
マルチパーティ コンピューティング編集者roles/mpc.editor |
すべての roles/mpc.viewer 権限と、上の表の roles/mpc.editor 権限。 |
署名者とポリシー作成者のプリンシパル。ユーザーロールによって、インスタンスが受け入れる方法が決まります。 |
マルチパーティ コンピューティング管理者roles/mpc.admin |
すべての roles/mpc.editor 権限と、上の表の roles/mpc.admin 権限。 |
管理者のプリンシパル。 |
v1beta リソースには独自の IAM ポリシーがありません。インスタンスを含むプロジェクトにロールを付与し、IAM 条件 を使用してロールを KeyRing に絞り込みます。
各ペルソナに推奨されるロール
各ユーザーに個別のプリンシパル、必要なロールのみを持つユーザー、一致する IAM ロールを付与します。
| ペルソナ | ユーザーロール | IAM ロール |
|---|---|---|
| 管理者 | ADMIN |
roles/mpc.admin |
| ポリシー作成者 | POLICY_AUTHOR |
roles/mpc.editor、または transactionPolicies.* 権限を持つカスタムロール |
| Signer | SIGNER |
roles/mpc.editor、または transactions.* 権限を持つカスタムロール |
| 監査担当者 | なし | roles/mpc.viewer |
フェデレーション プリンシパルには、コンシューマー プロジェクトに対する Service Usage コンシューマー ロール（roles/serviceusage.serviceUsageConsumer）も必要です。詳細については、Workforce Identity 連携（BYOID）を構成するをご覧ください。
カスタムロール
プリンシパルに必要な権限のみを付与するには、カスタム IAM ロールを作成します。たとえば、次のロールでは、署名者はトランザクションを表示して承認または拒否できますが、作成することはできません。
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"
PROJECT_ID は、インスタンスを含むプロジェクトの ID に置き換えます。
インスタンスは引き続き呼び出し元のユーザーを確認します。ユーザーは、決定を記録するためにトランザクションの鍵の鍵共有を保持する必要があります。
IAM 条件
リソース名の IAM 条件を使用して、ロール バインディングを 1 つの KeyRing 内のリソースに絞り込むことができます。たとえば、2 つのビジネス ユニットが 1 つのインスタンスを共有し、それぞれに独自の KeyRing がある場合、各ユニットの署名者に独自の KeyRing の roles/mpc.editor のみを付与できます。
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"
次のように置き換えます。
PROJECT_ID: インスタンスが含まれているプロジェクトの ID。SA_NAME: サービス アカウントの名前。LOCATION: インスタンスのリージョン。INSTANCE_ID: インスタンスの ID。KEYRING_ID: KeyRing の ID。
v1beta リソース名に /mpc/ は含まれません。非公開プレビュー（v1alpha1）のドキュメントからコピーされた条件（.../instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID など）が、v1beta リソースと一致しません。
ユーザー、チーム、KeyList、トランザクション ポリシーは KeyRing ではなくインスタンスに属しているため、KeyRing スコープのバインディングではアクセス権が付与されません。