다자간 계산 API에 대한 모든 요청은 API 메서드에 대한 Identity and Access Management 검사와 호출자의 다자간 계산 사용자 및 해당 역할에 대한 검사라는 두 가지 개별 검사를 통과합니다. 이 페이지에서는 두 가지 검사, IAM 권한, 관리자가 사용자 역할 변경사항을 승인하는 방법을 설명합니다.
요청 승인 방법
- IAM 확인 요청이 인스턴스에 도달하기 전에 IAM은 호출 주 구성원에게 요청의 리소스에 대해 메서드가 요구하는 권한이 있는지 확인합니다. 그렇지 않으면 요청이
403 PERMISSION_DENIED과 함께 실패하고 인스턴스에 도달하지 않습니다. 요청은 Cloud 감사 로그에 기록됩니다. 각 메서드에 필요한 권한은 IAM 권한을 참조하세요. - 사용자 및 역할 확인. 사용자를 대신하여 작동하는 메서드의 경우 인스턴스는
principal가 호출자의 인증된 ID와 일치하는 사용자를 조회하고 해당 사용자의 역할을 확인합니다. 예를 들어CreateTransaction호출자는SIGNER역할이 있는 사용자여야 합니다. 각 메서드가 수행하는 검사는 사용자 역할을 참조하세요.
두 검사 모두 통과해야 합니다. IAM 역할과 사용자 역할은 상호 보완적입니다. 예를 들면 다음과 같습니다.
roles/mpc.editor가 있지만POLICY_AUTHOR역할이 있는 사용자가 없는 주 구성원은CreateTransactionPolicy를 호출할 수 있지만 인스턴스에서 요청을 거부합니다.- 주 구성원에
mpc.googleapis.com/transactions.create가 없는SIGNER역할이 있는 사용자는 IAM이 먼저 요청을 거부하므로 트랜잭션을 만들 수 없습니다.
승인에는 서명도 포함됩니다. 서명자, 정책 작성자, 관리자는 사용자에 등록된 승인 키로 각 승인에 서명합니다. 이를 통해 정책과 트랜잭션이 변조되지 않고 영구적인 감사 추적이 남습니다.
참여자 신뢰할 수 있는 실행 환경 (TEE)은 트랜잭션에 서명하거나 트랜잭션 정책을 수락하기 전에 이러한 서명을 확인하므로 두 검사를 모두 통과한 요청은 유효한 승인 없이는 서명을 생성할 수 없습니다. 자세한 내용은 보안 모델을 참고하세요.
사용자 역할
각 사용자는 User.roles에 설정된 다음 역할 중 하나를 갖습니다. 이 역할은 인스턴스의 역할이며 IAM 역할이 아닙니다.
| 사용자 역할 | 사용자가 할 수 있는 작업 | 확인 시점 |
|---|---|---|
SIGNER |
키 공유를 보유하고 거래를 승인합니다. 정확히 하나의 팀에 속합니다. | CreateTransaction: 호출자의 사용자에게 SIGNER 역할이 있어야 합니다.RecordSignerDecision: 호출자의 사용자가 트랜잭션 키의 키 공유를 보유해야 합니다.ListTransactions: 호출자의 사용자에게 SIGNER 역할만 있는 경우 사용자가 키 공유를 보유한 키의 트랜잭션만 반환됩니다. |
POLICY_AUTHOR |
트랜잭션 정책을 제안, 승인, 사용 중지합니다. | CreateTransactionPolicy, ApproveTransactionPolicy, DisableTransactionPolicy: 호출자의 사용자는 등록된 승인 키가 있는 활성 정책 작성자여야 합니다. |
ADMIN |
사용자, 팀, 키링, 키, 키 목록을 관리합니다. ADMIN 및 POLICY_AUTHOR 역할에 대한 변경사항을 승인합니다. |
EnableUserRole, DisableUserRole, DisableUser, ApproveUser(ADMIN 및 POLICY_AUTHOR 변경사항): 요청에 호출 관리자의 서명이 포함되어야 합니다. 역할 변경에 대한 관리자 승인을 참고하세요. |
사용자에게는 다음 규칙이 적용됩니다.
- 사용자당 주 구성원 1명
User.principal는 사용자를 만들 때 설정되며 변경할 수 없습니다. Google 계정 또는 직원 ID 제휴 주 구성원입니다. 사용자의 주 구성원을 변경하려면 사용자를 사용 중지하고 새 사용자를 만드세요. - 서명자당 하나의 팀.
SIGNER역할이 있는 사용자는Team를 설정해야 합니다.SIGNER역할이 있는 사용자만 키 공유를 보유할 수 있으므로 서명자만 팀에 속합니다. 서명자를 다른 팀으로 이동하면UpdateTeamAssignment가 사용되며, 이 경우 다시 공유해야 합니다. 이 기능은 이후 버전에 출시될 예정입니다. - 승인 키. 서명자와 정책 작성자는 승인에 서명하기 위해 승인 키가 필요합니다. 관리자는
ADMIN및POLICY_AUTHOR역할에 대한 변경사항을 요청하거나 승인하려면 관리자 서명이 필요합니다. 서명자 및 팀을 관리하는 데는 관리자 서명이 필요하지 않습니다.
각 역할의 상태
| 상태 | 의미 | 사용자가 역할을 사용할 수 있나요? |
|---|---|---|
PENDING_ACTIVE |
역할이 부여되었으며 관리자 승인을 기다리는 중입니다. | 없음 |
ACTIVE |
역할이 적용됩니다. | 예 |
PENDING_DISABLED |
역할이 삭제되고 있으며 관리자 승인을 기다리고 있습니다. | 예, 삭제가 승인될 때까지 |
DISABLED |
역할이 삭제되었습니다. 승인 내역이 계속 표시되도록 목록에 유지됩니다. | 없음 |
역할 변경에 대한 관리자 승인
관리자는 모든 사용자 역할을 관리합니다. ADMIN 또는 POLICY_AUTHOR 역할을 부여하거나 삭제하려면 여러 관리자의 승인이 필요합니다. SIGNER 역할을 부여하거나 삭제하면 관리자 서명 없이 단일 관리자로부터 즉시 적용됩니다. SIGNER 역할만으로는 키에 대한 액세스 권한이 부여되지 않습니다. 서명자는 관리자가 키링의 키 정책에 서명자 또는 해당 팀을 포함하고 키를 만들 때만 키 공유를 받습니다.
| 메서드 | 사용자 역할에 미치는 영향 |
|---|---|
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로 설정합니다. 역할을 복원하지 않으며 승인이 필요하지 않습니다. |
승인은 다음과 같이 작동합니다.
- 관리자가 변경을 요청하고
authorizationInfo를 포함합니다. 이는 역할 변경에 대해 승인 키로 생성된 서명입니다. 이 요청은 첫 번째 승인으로 간주됩니다. - 다른 관리자는 각자의 서명으로 사용자에 대해
ApproveUser를 호출합니다. 한 번의 승인으로 해당 사용자의 대기 중인 모든 역할 변경이 처리됩니다. - 승인 수가 인스턴스의 관리자 승인 기준점에 도달하면 사용자의 대기 중인 역할 변경사항이 모두 함께 적용됩니다. 승인은
role_statuses.approval_info의 사용자에 저장되며 참여 TEE가 이를 확인합니다.
다음 규칙은 모든 ADMIN 및 POLICY_AUTHOR 변경사항에 적용됩니다.
- I can see that you have at least two active Admins. 인스턴스에 활성 관리자가 관리자 승인 기준점보다 적게 남게 되는 변경사항은
FAILED_PRECONDITION로 인해 실패합니다. 인스턴스에는 활성 관리자가 항상 2명 이상 있어야 합니다. 역할이PENDING_DISABLED인 관리자는 활성 상태로 집계되지 않습니다. - 자체 승인 불가. 변경 대상 사용자는 자신의 변경을 요청하거나 승인할 수 없습니다. 이러한 요청은
PERMISSION_DENIED와 함께 실패합니다. - 관리자당 1회 승인 관리자가 동일한 변경사항을 두 번 승인하면 두 번째 요청은
ALREADY_EXISTS로 인해 실패합니다. - 사용자당 대기 중인 변경사항은 1개입니다. 변경이 대기 중인 동안에는 역할을 사용 설정하라는 요청이
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 |
|
| 키링 | 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 조건을 사용하여 역할을 키링으로 제한합니다.
각 캐릭터에 권장되는 역할
각 사용자에게 고유한 주 구성원, 필요한 역할만 있는 사용자, 일치하는 IAM 역할을 부여합니다.
| 페르소나 | 사용자 역할 | IAM 역할 |
|---|---|---|
| 관리자 | ADMIN |
roles/mpc.admin |
| 정책 작성자 | POLICY_AUTHOR |
roles/mpc.editor 또는 transactionPolicies.* 권한이 있는 커스텀 역할 |
| Signer | SIGNER |
roles/mpc.editor 또는 transactions.* 권한이 있는 커스텀 역할 |
| 감사자 | 없음 | roles/mpc.viewer |
제휴 주 구성원에게는 소비자 프로젝트에 대한 서비스 사용량 소비자 역할 (roles/serviceusage.serviceUsageConsumer)도 필요합니다. 자세한 내용은 직원 ID 제휴 (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에 있는 리소스로 좁힐 수 있습니다. 예를 들어 두 비즈니스 단위가 인스턴스를 공유하고 각 단위에 자체 키링이 있는 경우 각 단위의 서명자에게 자체 키링에 대해서만 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: 인스턴스의 IDKEYRING_ID: KeyRing의 ID입니다.
v1beta 리소스 이름에 /mpc/가 포함되지 않습니다. 비공개 프리뷰(v1alpha1) 문서에서 복사한 조건(예: .../instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID)이 v1beta 리소스와 일치하지 않습니다.
사용자, 팀, KeyList, 트랜잭션 정책은 KeyRing이 아닌 인스턴스에 속하므로 KeyRing 범위 바인딩은 이러한 항목에 대한 액세스 권한을 부여하지 않습니다.