安全性與授權

對 Multi-party Compute API 發出的每項要求,都必須通過兩項獨立檢查:API 方法的 Identity and Access Management 檢查,以及呼叫端的多方運算使用者和角色檢查。本頁面說明這兩項檢查、IAM 權限,以及管理員如何核准使用者角色變更。

如何授權要求

  1. IAM 檢查。在要求到達執行個體之前,IAM 會檢查呼叫主體是否具備該方法在要求資源上所需的權限。如果沒有,要求就會失敗並傳回 403 PERMISSION_DENIED,且不會傳送至執行個體。這項要求會記錄在 Cloud 稽核記錄中。如要瞭解各方法所需的權限,請參閱「IAM 權限」。
  2. 使用者和角色檢查。如果方法代表使用者執行,執行個體會查詢 principal 與呼叫端已驗證身分相符的使用者,並檢查該使用者的角色。舉例來說,CreateTransaction 的呼叫者必須是具備 SIGNER 角色的使用者。如要瞭解各方法執行的檢查,請參閱「使用者角色」。

兩項檢查都必須通過。IAM 角色和使用者角色相輔相成,例如:

  • 如果主體具有 roles/mpc.editor,但沒有具備 POLICY_AUTHOR 角色的使用者,則可以呼叫 CreateTransactionPolicy,但執行個體會拒絕要求。
  • 如果使用者具備 SIGNER 角色,但主體沒有 mpc.googleapis.com/transactions.create,則無法建立交易,因為 IAM 會先拒絕要求。

核准也包含簽名。簽署者、政策作者和管理員會使用註冊在使用者帳戶的授權金鑰,簽署每項核准。這可確保政策和交易無法竄改,並留下永久的稽核追蹤記錄。

參與者的受信任執行環境 (TEE) 會先驗證這些簽章,再簽署交易或接受交易政策,因此即使要求通過這兩項檢查,仍無法在沒有有效核准的情況下產生簽章。詳情請參閱安全性模型。

使用者角色

每位使用者都具備下列其中一個角色 (在 User.roles 中設定)。這個角色是執行個體中的角色,而非 IAM 角色。

使用者角色 使用者可執行的動作 上次檢查時間
SIGNER 持有金鑰共用並核准交易。只屬於一個團隊。 CreateTransaction:呼叫者的使用者必須具備 SIGNER 角色。
RecordSignerDecision:呼叫者的使用者必須持有交易金鑰的金鑰共用。
ListTransactions:如果呼叫者的使用者僅具備 SIGNER 角色,則只會傳回使用者持有金鑰共用的金鑰交易。
POLICY_AUTHOR 提議、核准及停用交易政策。 CreateTransactionPolicy、ApproveTransactionPolicy、DisableTransactionPolicy:呼叫端的使用者必須是具備已註冊授權金鑰的有效政策作者。
ADMIN 管理使用者、團隊、KeyRing、金鑰和 KeyList。核准 ADMIN 和 POLICY_AUTHOR 角色的變更。 EnableUserRole、DisableUserRole、DisableUser、ApproveUser ADMIN 和 POLICY_AUTHOR 變更:要求必須包含呼叫管理員的簽名。請參閱「管理員核准角色變更」。

使用者必須遵守下列規則:

  • 每位使用者一個主體。User.principal 是在建立使用者時設定,無法變更。這是 Google 帳戶或員工身分聯盟主體。如要變更使用者的主體,請停用該使用者並建立新使用者。
  • 每位簽署者一個團隊。具備 SIGNER 角色的使用者必須設定 Team。只有具備 SIGNER 角色的使用者可以持有金鑰共用,因此只有簽署者屬於團隊。將簽署者移至其他團隊會使用 UpdateTeamAssignment,這需要重新共用,我們預計在日後版本中推出這項功能。
  • 授權金鑰。簽署者和政策作者需要授權金鑰,才能簽署核准。管理員必須具備這項權限,才能要求或核准ADMIN和POLICY_AUTHOR角色的變更;管理簽署人和團隊則不需要管理員簽名。

各角色的狀態

狀態 意義 使用者可以使用該角色嗎?
PENDING_ACTIVE 角色已授予,正在等待管理員核准。 否
ACTIVE 角色已生效。 是
PENDING_DISABLED 角色正在移除,等待管理員核准。 是,直到移除要求獲准為止
DISABLED 角色已移除。因此維持公開,核准狀態仍會顯示。 否

管理員核准角色變更

管理員可管理所有使用者角色。授予或移除ADMIN或POLICY_AUTHOR角色,需要多位管理員核准。單一管理員授予或移除SIGNER角色後,不需管理員簽名,就會立即生效。SIGNER 角色本身不會授予金鑰存取權。只有在管理員將簽署者或其團隊加入 KeyRing 的金鑰政策,並建立金鑰時,簽署者才會收到金鑰共用。

方法 對使用者角色的影響
CreateUser 每個要求的 ADMIN 或 POLICY_AUTHOR 角色都會在 PENDING_ACTIVE 中啟動。SIGNER會立即ACTIVE。
EnableUserRole 授予一個角色。ADMIN和POLICY_AUTHOR將於 PENDING_ACTIVE開始;SIGNER會立即ACTIVE。
DisableUserRole 移除一個角色。對於ADMIN和POLICY_AUTHOR,ACTIVE角色會變成PENDING_DISABLED,PENDING_ACTIVE角色則會立即取消,不需經過核准。SIGNER 會立即變成 DISABLED。
DisableUser 在單一要求中移除使用者的所有角色,並為所有 ADMIN 和 POLICY_AUTHOR 變更提供一個簽章。
ApproveUser 記錄一位管理員核准使用者的待變更項目。
EnableUser 將停用的使用者重設為 ACTIVE。不會還原任何角色,也不需要核准。

核准作業的運作方式如下:

  1. 管理員要求變更,並附上 authorizationInfo:使用授權金鑰建立的角色變更簽名。這項要求視為第一次核准。
  2. 其他管理員會對使用者呼叫 ApproveUser,每個管理員都有自己的簽章。只要核准一次,該使用者所有待處理的角色變更就會生效。
  3. 當核准數量達到執行個體的管理員核准門檻時,使用者所有待處理的角色變更就會一併生效。核准資訊會儲存在 role_statuses.approval_info 的使用者中,並由參與者 TEE 驗證。

以下規則適用於所有 ADMIN 和 POLICY_AUTHOR 變更:

  • 至少有兩位有效管理員。如果變更會導致執行個體中的有效管理員人數低於管理員核准門檻,則會失敗並顯示 FAILED_PRECONDITION。執行個體至少有兩位有效管理員。角色為PENDING_DISABLED的管理員不計入有效管理員。
  • 不得自行核准。要變更的使用者無法要求或核准自己的變更。這類要求會失敗,並傳回 PERMISSION_DENIED。
  • 每位管理員只能核准一次。如果管理員核准同一項變更兩次,第二次要求會失敗,並顯示 ALREADY_EXISTS。
  • 每位使用者只能有一個待變更項目。變更待處理期間,啟用角色的要求會失敗,並顯示 FAILED_PRECONDITION。停用角色的要求一律不會遭到封鎖:停用會取消待處理的啟用,並與任何待處理的停用合併為一項新的變更,其核准程序會重新開始。
  • 到期。如果變更在 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 參考資料。

預先定義的角色

角色 收錄 適合用途
Multi-party Compute 檢視者
roles/mpc.viewer
上表中的 roles/mpc.viewer 權限:每項資源的 get 和 list。 稽核人員和監控工具。
Multi-party Compute 編輯者
roles/mpc.editor
所有 roles/mpc.viewer 權限,以及上表中的 roles/mpc.editor 權限。 簽署者和政策作者的主體。執行個體會根據使用者角色,決定接受哪些方法。
Multi-party Compute 管理員
roles/mpc.admin
所有 roles/mpc.editor 權限,以及上表中的 roles/mpc.admin 權限。 管理員的主體。

v1beta 資源沒有專屬的 IAM 政策,在包含執行個體的專案中授予角色,並使用 IAM 條件將角色範圍縮小至金鑰環。

各角色的建議

為每個人指派不同的主體、僅具備所需角色的使用者,以及相符的 IAM 角色:

角色 使用者角色 IAM 角色
管理員 ADMIN roles/mpc.admin
政策作者 POLICY_AUTHOR roles/mpc.editor,或具有 transactionPolicies.* 權限的自訂角色
Signer SIGNER roles/mpc.editor,或具有 transactions.* 權限的自訂角色
稽核者 無 roles/mpc.viewer

聯合主體也需要用戶專案的服務使用情形消費者角色 (roles/serviceusage.serviceUsageConsumer)。詳情請參閱「設定員工身分聯盟 (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 條件,將角色繫結範圍縮小至一個 KeyRing 中的資源。舉例來說,如果兩個業務單位共用一個執行個體,且各自擁有 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 範圍的繫結不會授予這些項目的存取權。