O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Segurança e autorização

Cada solicitação à API de computação multipartidária passa por duas verificações separadas: uma verificação do Identity and Access Management no método da API e uma verificação do usuário da computação multipartidária do autor da chamada e dos papéis dele. Nesta página, descrevemos as duas verificações, as permissões do IAM e como os administradores aprovam mudanças nas funções do usuário.

Como uma solicitação é autorizada

Verificação do IAM. Antes que uma solicitação chegue à instância, o IAM verifica se o principal que faz a chamada tem a permissão exigida pelo método no recurso da solicitação. Se não corresponder, a solicitação vai falhar com 403 PERMISSION_DENIED e nunca vai chegar à instância. A solicitação é registrada nos Registros de Auditoria do Cloud. Para saber qual permissão cada método exige, consulte Permissões do IAM.
Verificação de usuário e papel. Para métodos que agem em nome de um usuário, a instância procura o usuário cujo principal corresponde à identidade autenticada do autor da chamada e verifica os papéis desse usuário. Por exemplo, o autor da chamada de CreateTransaction precisa ser um usuário com o papel SIGNER. Para saber quais verificações cada método faz, consulte Papéis do usuário.

As duas verificações precisam ser aprovadas. Os papéis do IAM e de usuário são complementares, por exemplo:

Um principal que tem roles/mpc.editor, mas não tem um usuário com o papel POLICY_AUTHOR, pode chamar CreateTransactionPolicy, mas a instância rejeita a solicitação.
Um usuário com o papel SIGNER cujo principal não tem mpc.googleapis.com/transactions.create não pode criar transações, porque o IAM rejeita a solicitação primeiro.

As aprovações também têm uma assinatura. Os signatários, autores de políticas e administradores assinam cada aprovação com a chave de autorização registrada no usuário. Isso garante que as políticas e transações sejam invioláveis e deixem trilhas de auditoria duráveis.

Os ambientes de execução confiáveis (TEEs) dos participantes verificam essas assinaturas antes de assinar uma transação ou aceitar uma política de transação. Assim, uma solicitação que passa por ambas as verificações ainda não pode produzir uma assinatura sem aprovações válidas. Para mais informações, consulte o modelo de segurança.

Papéis do usuário

Cada usuário tem um dos seguintes papéis, definidos em User.roles. Esse papel é um papel na sua instância, não um papel do IAM.

Função do usuário	O que o usuário pode fazer	Verificado quando
`SIGNER`	Mantém compartilhamentos de chaves e aprova transações. Pertence a exatamente uma equipe.	`CreateTransaction`: o usuário do autor da chamada precisa ter o papel `SIGNER`. `RecordSignerDecision`: o usuário do autor da chamada precisa ter uma fração da chave da transação. `ListTransactions`: se o usuário do autor da chamada tiver apenas o papel `SIGNER`, somente as transações em chaves em que o usuário tiver uma fração de chave serão retornadas.
`POLICY_AUTHOR`	Propõe, aprova e desativa políticas de transação.	`CreateTransactionPolicy`, `ApproveTransactionPolicy`, `DisableTransactionPolicy`: o usuário do autor da chamada precisa ser um autor de política ativo com uma chave de autorização registrada.
`ADMIN`	Gerencia usuários, equipes, KeyRings, chaves e KeyLists. Aprova mudanças nos papéis `ADMIN` e `POLICY_AUTHOR`.	`EnableUserRole`, `DisableUserRole`, `DisableUser`, `ApproveUser` para mudanças em `ADMIN` e `POLICY_AUTHOR`: a solicitação precisa ter a assinatura do administrador que está fazendo a chamada. Consulte Aprovação do administrador para mudanças de função.

As seguintes regras se aplicam aos Usuários:

Um principal por usuário. User.principal é definido quando você cria o usuário e não pode ser alterado. É uma Conta do Google ou um principal da federação de identidade de colaboradores. Para mudar o principal de um usuário, desative-o e crie um novo.
Uma equipe por signatário. Um usuário com o papel SIGNER precisa ter Team definido. Somente usuários com o papel SIGNER podem ter compartilhamentos de chaves, então apenas os Signatários pertencem a uma Equipe. Mover um Signer para outra equipe usa UpdateTeamAssignment, o que requer um novo compartilhamento, planejado para uma versão posterior.
Chaves de autorização. Os signatários e autores de políticas precisam de uma chave de autorização para assinar as aprovações. Os administradores precisam de uma para solicitar ou aprovar mudanças nas funções ADMIN e POLICY_AUTHOR. O gerenciamento de signatários e equipes não exige uma assinatura de administrador.

Status de cada função

Status	Significado	O usuário pode usar o papel?
`PENDING_ACTIVE`	A função foi concedida e está aguardando a aprovação do administrador.	Não
`ACTIVE`	O papel está em vigor.	Sim
`PENDING_DISABLED`	A função está sendo removida e aguarda a aprovação do administrador.	Sim, até que a remoção seja aprovada
`DISABLED`	O papel foi removido. Ele vai continuar listado para que as aprovações permaneçam visíveis.	Não

Aprovação de mudanças de função pelo administrador

Os administradores gerenciam todas as funções de usuário. A concessão ou remoção da função ADMIN ou POLICY_AUTHOR precisa da aprovação de vários administradores. A concessão ou remoção da função SIGNER entra em vigor imediatamente para um único administrador, sem uma assinatura de administrador. O papel SIGNER por si só não concede acesso às chaves. Um Signatário só recebe compartilhamentos de chaves quando um Administrador inclui o Signatário ou a equipe dele na política de chaves de um KeyRing e cria uma chave.

Método	Efeito nas funções do usuário
`CreateUser`	Cada papel `ADMIN` ou `POLICY_AUTHOR` solicitado começa em `PENDING_ACTIVE`. `SIGNER` é `ACTIVE` imediatamente.
`EnableUserRole`	Concede um papel. `ADMIN` e `POLICY_AUTHOR` começam em `PENDING_ACTIVE`; `SIGNER` é `ACTIVE` imediatamente.
`DisableUserRole`	Remove um papel. Para `ADMIN` e `POLICY_AUTHOR`, uma função `ACTIVE` se torna `PENDING_DISABLED`, e uma função `PENDING_ACTIVE` é cancelada imediatamente, sem aprovação. `SIGNER` se torna `DISABLED` imediatamente.
`DisableUser`	Remove todas as funções do usuário em uma solicitação, com uma assinatura para todas as mudanças de `ADMIN` e `POLICY_AUTHOR`.
`ApproveUser`	Registra a aprovação de um administrador para a alteração pendente do usuário.
`EnableUser`	Define um usuário desativado de volta como `ACTIVE`. Ele não restaura papéis e não precisa de aprovação.

Uma aprovação funciona da seguinte maneira:

Um administrador solicita a mudança e inclui authorizationInfo: a assinatura dele, feita com a chave de autorização, sobre a mudança de função. Essa solicitação conta como a primeira aprovação.
Outros administradores chamam ApproveUser no usuário, cada um com a própria assinatura. Uma aprovação abrange todas as mudanças de função pendentes desse usuário.
Quando o número de aprovações atinge o limite de aprovação do administrador da instância, todas as mudanças de função pendentes do usuário entram em vigor juntas. As aprovações são armazenadas no usuário em role_statuses.approval_info, e os TEEs participantes as verificam.

As regras a seguir se aplicam a todas as mudanças de ADMIN e POLICY_AUTHOR:

Pelo menos dois administradores ativos. Uma mudança que deixaria a instância com menos administradores ativos do que o limite de aprovação de administradores falha com FAILED_PRECONDITION. A instância nunca tem menos de dois administradores ativos. Os administradores com a função PENDING_DISABLED não são considerados ativos.
Sem autoaprovação. O usuário que está sendo alterado não pode solicitar ou aprovar a própria alteração. Uma solicitação como essa falha com PERMISSION_DENIED.
Uma aprovação por administrador. Se um administrador aprovar a mesma mudança duas vezes, a segunda solicitação vai falhar com ALREADY_EXISTS.
Uma alteração pendente por usuário. Enquanto uma mudança estiver pendente, as solicitações para ativar um papel vão falhar com FAILED_PRECONDITION. As solicitações para desativar uma função nunca são bloqueadas: uma desativação cancela as ativações pendentes e é combinada com todas as desativações pendentes em uma nova alteração, cujas aprovações começam de novo.
Validade. Uma mudança que não recebe aprovações suficientes até approval_info.expire_time expira, e as funções voltam ao status anterior.

Na API v1beta, não é possível desativar o papel SIGNER ou o usuário enquanto ele tiver compartilhamentos de chaves. Para substituir as frações de chave de um Signatário, é necessário fazer um novo compartilhamento, o que está planejado para uma versão futura.

Permissões do IAM

A tabela a seguir lista cada método v1beta, a permissão do IAM necessária e o papel predefinido com o menor número de permissões que o inclui. Cada papel predefinido também inclui todas as permissões dos papéis anteriores: roles/mpc.editor inclui roles/mpc.viewer, e roles/mpc.admin inclui roles/mpc.editor.

Recurso	Método	Permissão	Papel predefinido
Equipe	`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`
Usuário	`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`
Chave	`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`
Transação	`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`

Para detalhes sobre solicitações e respostas, consulte a referência da API REST de computação multipartidária.

Papéis predefinidos

Papel	Inclui	Destinado a
Leitor de computação multipartidária `roles/mpc.viewer`	As permissões `roles/mpc.viewer` na tabela anterior: `get` e `list` em todos os recursos.	Auditores e ferramentas de monitoramento.
Editor de computação multipartidária `roles/mpc.editor`	Todas as permissões de `roles/mpc.viewer`, além das permissões de `roles/mpc.editor` na tabela anterior.	Principais de signatários e autores de políticas. As funções de usuário decidem quais desses métodos a instância aceita.
Administrador de computação multipartidária `roles/mpc.admin`	Todas as permissões de `roles/mpc.editor`, além das permissões de `roles/mpc.admin` na tabela anterior.	Principais de administradores.

Os recursos v1beta não têm as próprias políticas do IAM. Conceda papéis no projeto que contém sua instância e use as condições do IAM para restringir um papel a um KeyRing.

Papéis recomendados para cada persona

Dê a cada pessoa um principal distinto, um usuário com apenas os papéis necessários e um papel do IAM correspondente:

Persona	Papéis do usuário	Papel do IAM
Administrador	`ADMIN`	`roles/mpc.admin`
Autor da política	`POLICY_AUTHOR`	`roles/mpc.editor` ou um papel personalizado com as permissões `transactionPolicies.*`
Signer	`SIGNER`	`roles/mpc.editor` ou um papel personalizado com as permissões `transactions.*`
Auditor	Nenhum	`roles/mpc.viewer`

Os principais federados também precisam do papel de consumidor do Service Usage (roles/serviceusage.serviceUsageConsumer) no projeto do consumidor. Para mais informações, consulte Configurar a federação de identidade de colaboradores (BYOID).

Papéis personalizados

Para conceder a um principal apenas as permissões necessárias, crie um papel personalizado do IAM. Por exemplo, o papel a seguir permite que um Signer visualize transações e as aprove ou negue, mas não as crie:

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"

Substitua PROJECT_ID pelo ID do projeto que contém sua instância.

A instância ainda verifica o usuário do autor da chamada: o usuário precisa ter uma parcela da chave da transação para registrar uma decisão.

Condições do IAM

É possível restringir uma vinculação de papel aos recursos em um KeyRing com uma condição do IAM no nome do recurso. Por exemplo, se duas unidades de negócios compartilharem uma instância e cada uma tiver o próprio KeyRing, será possível conceder aos Signatários de cada unidade roles/mpc.editor apenas no próprio 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"

Substitua:

PROJECT_ID: o ID do projeto que contém a instância.
SA_NAME: o nome da conta de serviço.
LOCATION: a região da instância.
INSTANCE_ID: o ID da instância.
KEYRING_ID: o ID do KeyRing.

Os nomes de recursos v1beta não contêm /mpc/. Uma condição copiada da documentação do pré-lançamento privado (v1alpha1), como .../instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID, não corresponde a nenhum recurso v1beta.

Usuários, equipes, KeyLists e políticas de transação pertencem à instância, não a um KeyRing. Portanto, uma vinculação com escopo de KeyRing não concede acesso a eles.