Como proteger o serviço de MPC usando papéis do IAM

Visualizar

Este produto está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os produtos pré-GA estão disponíveis no estado em que se encontram e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Observação: esta página aborda a API v1alpha1 descontinuada e será removida em dezembro de 2026. Para a API v1beta, consulte Segurança e autorização.

Modelo de segurança: defesa em profundidade

A API Multi-party Compute (MPC) implementa uma arquitetura de segurança de defesa em profundidade que depende de controles rígidos do Identity and Access Management (IAM). Esse modelo garante que nenhuma identidade ou Conta do Google comprometida possa comprometer unilateralmente a plataforma ou extrair recursos.

• Camada 1: Identity and Gerenciamento de acesso (IAM): todas as solicitações são verificadas na borda para confirmar que o autor da chamada tem as permissões explícitas necessárias para invocar métodos específicos da API do Google Cloud (consulte Visão geral do IAM). As contas que não têm privilégios suficientes são rejeitadas imediatamente com um erro 403 Forbidden, impedindo que o tráfego não autorizado chegue à camada do aplicativo.
• Camada 2: segregação de funções (SoD, na sigla em inglês): a plataforma de MPC aplica uma separação estrita de funções para garantir que ações distintas de governança e execução não sejam realizadas pela mesma pessoa. Ao definir papéis distintos, como restringir os autores de políticas apenas à edição de políticas e os signatários apenas à assinatura de payloads de transações, o sistema garante que um único agente invasor ou uma conta violada não possa executar transações confidenciais de forma independente.
• Camada 3: princípio de privilégio mínimo: o acesso é concedido estritamente com base na função, garantindo que os usuários tenham apenas as permissões mínimas necessárias para realizar as tarefas. Por exemplo, a equipe de compliance ou auditoria opera com o privilégio mínimo, mantendo acesso estritamente somente leitura para monitorar as atividades. Eles podem visualizar políticas e inspecionar registros de transações para fins de supervisão, mas não têm a capacidade de modificar políticas, iniciar transações ou interagir com ativos.

---

Perfis e segregação de funções

A segurança é aplicada ao separar a Administração (configuração do quadro) da Governança (definição de regras) e da Execução (movimentação de recursos).

Persona	Domínio	Papel do IAM atribuído	Principais responsabilidades
Administrador	Administração	mpc.admin	Provisiona recursos. Não é possível assinar transações ou criar políticas.
Autor da política	Governança	mpc.editor	Define e edita políticas operacionais (por exemplo, limites de gastos).
Signatário	Execução	mpc.editor	Assina payloads de transação. Não é possível criar políticas.
Compliance	Supervisão	mpc.viewer	Acesso somente leitura para monitorar atividades e inspecionar políticas. Não é possível modificar políticas nem iniciar transações.

Observação: Modo de avaliação: ao seguir o guia do usuário de forma independente, uma única identidade do IAM do Google Cloud pode ser usada para simular ações em várias personas (por exemplo, assinar como Alice e Bob em uma estação de trabalho). Em um cenário real, uma segregação de funções rigorosa precisa ser aplicada usando identidades do IAM distintas e chaves criptográficas exclusivas para cada persona.

Papéis de IAM predefinidos

A tabela a seguir detalha as permissões específicas do IAM para a API Multi-party Compute (MPC) e os papéis que as concedem. Para mais informações sobre as operações da API, consulte a referência da API MPC.

Papel	Permissões
Leitor de computação multipartidária (roles/mpc.viewer) Fornece acesso somente leitura em toda a API (operações Get/List em todos os recursos). Mais adequado para auditores ou ferramentas de monitoramento. Recursos de nível mais baixo em que você pode conceder esse papel: KeyRing	mpc.googleapis.com/keyRings.get mpc.googleapis.com/keyRings.list mpc.googleapis.com/keys.get mpc.googleapis.com/keys.list mpc.googleapis.com/policies.get mpc.googleapis.com/policies.list mpc.googleapis.com/policyAuthorTrustBundles.get mpc.googleapis.com/proposals.get mpc.googleapis.com/proposals.list mpc.googleapis.com/signers.get mpc.googleapis.com/signers.list
Editor de computação multipartidária (roles/mpc.editor) Projetado para autores de políticas e participantes (signatários). Concede a capacidade de gerenciar políticas, criar propostas e registrar decisões dos participantes. Recursos de nível mais baixo em que é possível conceder esse papel: KeyRing	Inclui todas as permissões de roles/mpc.viewer, além de: mpc.googleapis.com/keyRings.update mpc.googleapis.com/keys.update mpc.googleapis.com/policies.addQuorumSignature mpc.googleapis.com/policies.create mpc.googleapis.com/policies.revoke mpc.googleapis.com/proposals.create mpc.googleapis.com/proposals.fetchProposalSignature mpc.googleapis.com/proposals.recordParticipantDecision
Administrador de computação multipartidária (roles/mpc.admin) Projetado para administradores. Concede acesso total para provisionar infraestrutura, gerar chaves e registrar chaves públicas de participantes. Recursos de nível mais baixo em que você pode conceder esse papel: Instância	Inclui todas as permissões de roles/mpc.editor, além de: mpc.googleapis.com/keyRings.create mpc.googleapis.com/keyRings.delete mpc.googleapis.com/keys.create mpc.googleapis.com/policyAuthorTrustBundles.update mpc.googleapis.com/signers.create

Papéis personalizados

Para conceder a um participante acesso estrito de privilégio mínimo em vez de usar os papéis predefinidos mais amplos, como roles/mpc.editor, crie um papel personalizado do IAM que contenha apenas as permissões exatas necessárias para participar das operações.

Exemplo de comando de papel personalizado

gcloud iam roles create customMpcSigner \
  --project="PROJECT_ID" \
  --title="Custom MPC Signer" \
  --description="Restricted role for transaction participants" \
  --permissions="mpc.googleapis.com/proposals.get,mpc.googleapis.com/proposals.list,mpc.googleapis.com/proposals.recordParticipantDecision"

IAM condicionado e no nível do recurso

Ao aderir ao princípio de privilégio mínimo, é possível definir o escopo dos papéis do IAM para um limite limitado usando as condições do IAM.

Se várias unidades de negócios operarem no mesmo projeto do Google Cloud usando uma instância compartilhada, será possível aplicar a separação colocando os recursos em KeyRings separados (por exemplo, KeyRing A e KeyRing B). É possível conceder roles/mpc.editor a uma conta de serviço usando uma condição do IAM que a restringe exclusivamente a operações que ocorrem em um KeyRing designado (KeyRing A), enquanto restringe o acesso a outros KeyRings na mesma instância.

Exemplo de comando

Exemplo de criação de uma vinculação de papel com escopo de KeyRing:

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/mpc/keyRings/KEYRING_ID'),title=KeyRing_Scoped_Editor"

Identidades federadas (identidade fornecida pelo usuário)

É possível autenticar e autorizar solicitações de computação multipartidária usando provedores de identidade corporativos externos (como Okta, Microsoft Entra ID ou Ping Identity) ou ambientes de execução de carga de trabalho externos sem criar Contas do Google ou gerenciar chaves de conta de serviço gerenciado:

• Federação de identidade de colaboradores: mapeia pools de colaboradores no nível da organização (locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>) para personas humanas, como administradores, autores de políticas, signatários e compliance, vinculando papéis do IAM a grupos de IdP externos.
• Federação de identidade da carga de trabalho: mapeia pools de identidade da carga de trabalho no nível do projeto (projects/<var>PROJECT_NUMBER</var>/locations/global/workloadIdentityPools/<var>WORKLOAD_POOL_ID</var>) para nós de coassinatura automatizados em execução na AWS, no Azure ou no Kubernetes.

Os principais federados também precisam receber o papel de Consumidor do Service Usage (roles/serviceusage.serviceUsageConsumer) no projeto do consumidor para que as solicitações de API possam atribuir cota e faturamento ao projeto.

Exemplos de vinculações de papéis federados

# Allow members of the workforce pool to consume APIs through the consumer project
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/*" \
  --role="roles/serviceusage.serviceUsageConsumer"

# Grant MPC Admin to an external IdP administrators group
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/group/mpc-admins" \
  --role="roles/mpc.admin"

# Grant MPC Editor to an external IdP signers group
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/group/mpc-signers" \
  --role="roles/mpc.editor"

Substitua:

• <var>PROJECT_ID</var>: o ID do projeto do consumidor para sua instância de computação multipartidária.
• <var>WORKFORCE_POOL_ID</var>: o ID do pool de identidade de colaboradores no nível da organização.

Para um tutorial completo, consulte Configurar a federação de identidade de colaboradores (BYOID).