Seguridad y autorización

Vista previa

Este producto está sujeto a las "Condiciones de la oferta previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos de la fase previa a la DG están disponibles "sin modificaciones" y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Cada solicitud a la API de Multi-party Compute pasa por dos verificaciones independientes: una de Identity and Access Management en el método de la API y otra del usuario de Multi-party Compute del emisor y sus roles. En esta página, se describen ambas verificaciones, los permisos de IAM y cómo los administradores aprueban los cambios en los roles de usuario.

Cómo se autoriza una solicitud

1. Verificación de IAM. Antes de que una solicitud llegue a tu instancia, IAM verifica que la principal que realiza la llamada tenga el permiso que el método requiere en el recurso de la solicitud. Si no es así, la solicitud falla con 403 PERMISSION_DENIED y nunca llega a la instancia. La solicitud se registra en los Registros de auditoría de Cloud. Para conocer el permiso que requiere cada método, consulta Permisos de IAM.
2. Verificación de usuarios y roles. En el caso de los métodos que actúan en nombre de un usuario, la instancia busca al usuario cuyo principal coincide con la identidad autenticada del emisor y verifica los roles de ese usuario. Por ejemplo, el emisor de CreateTransaction debe ser un usuario con el rol SIGNER. Para conocer las verificaciones que realiza cada método, consulta Roles de usuario.

Se deben aprobar ambas verificaciones. Los roles de IAM y los roles de usuario son complementarios, por ejemplo:

• Una principal que tiene roles/mpc.editor, pero no un usuario con el rol POLICY_AUTHOR, puede llamar a CreateTransactionPolicy, pero la instancia rechaza la solicitud.
• Un usuario con el rol SIGNER cuya principal no tiene mpc.googleapis.com/transactions.create no puede crear transacciones, porque IAM rechaza la solicitud primero.

Las aprobaciones también llevan una firma. Los firmantes, los autores de políticas y los administradores firman cada aprobación con la clave de autorización registrada en su usuario. Esto garantiza que las políticas y las transacciones no se puedan alterar y dejen registros de auditoría duraderos.

Los entornos de ejecución confiables (TEE) de los participantes verifican estas firmas antes de firmar una transacción o aceptar una política de transacciones, por lo que una solicitud que aprueba ambas verificaciones no puede producir una firma sin aprobaciones válidas. Para obtener más información, consulta el modelo de seguridad.

Funciones de usuario

Cada usuario tiene uno de los siguientes roles, que se configuran en User.roles. Este es un rol en tu instancia, no un rol de IAM.

Función del usuario	Qué puede hacer el usuario	Cuándo se verificó
SIGNER	Contiene claves compartidas y aprueba transacciones. Pertenece a exactamente un equipo.	CreateTransaction: El usuario del emisor debe tener el rol SIGNER. RecordSignerDecision: El usuario del emisor debe tener un recurso compartido de claves de la clave de la transacción. ListTransactions: Si el usuario del emisor solo tiene el rol SIGNER, solo se devuelven las transacciones de las claves en las que el usuario tiene un recurso compartido de claves.
POLICY_AUTHOR	Propone, aprueba e inhabilita políticas de transacciones.	CreateTransactionPolicy, ApproveTransactionPolicy, DisableTransactionPolicy: El usuario del emisor debe ser un autor de políticas activo con una clave de autorización registrada.
ADMIN	Administra usuarios, equipos, llaveros de claves, claves y listas de claves. Aprueba los cambios en los roles ADMIN y POLICY_AUTHOR.	EnableUserRole, DisableUserRole, DisableUser, ApproveUser para los cambios de ADMIN y POLICY_AUTHOR: la solicitud debe llevar la firma del administrador que realiza la llamada. Consulta Aprobación de cambios de roles por parte del administrador.

Las siguientes reglas se aplican a los Usuarios:

• Un principal por usuario. User.principal se establece cuando creas el usuario y no se puede cambiar. Es una Cuenta de Google o una principal de la federación de identidades de personal. Para cambiar la principal de un usuario, inhabilítalo y crea uno nuevo.
• Un equipo por firmante. Un usuario con el rol SIGNER debe tener configurado Team. Solo los usuarios con el rol de SIGNER pueden tener fragmentos de claves, por lo que solo los firmantes pertenecen a un equipo. Mover un firmante a otro equipo usa UpdateTeamAssignment, lo que requiere volver a compartir, algo que se planea para una versión posterior.
• Claves de autorización. Los firmantes y los autores de políticas necesitan una clave de autorización para firmar las aprobaciones. Los administradores necesitan una para solicitar o aprobar cambios en los roles de ADMIN y POLICY_AUTHOR. No se requiere una firma de administrador para administrar los firmantes y los equipos.

Estado de cada rol

Estado	Significado	¿Puede el usuario usar el rol?
PENDING_ACTIVE	Se otorgó el rol y está esperando la aprobación del administrador.	No
ACTIVE	El rol está vigente.	Sí
PENDING_DISABLED	Se está quitando el rol y se está esperando la aprobación del administrador.	Sí, hasta que se apruebe la eliminación
DISABLED	Se quitó el rol. Permanecerá en la lista para que sus aprobaciones sigan siendo visibles.	No

Aprobación de los cambios de rol por parte del administrador

Los administradores gestionan todos los roles de usuario. Para otorgar o quitar el rol de ADMIN o POLICY_AUTHOR, se necesita la aprobación de varios administradores. El otorgamiento o la eliminación del rol de SIGNER se aplica de inmediato desde un solo administrador, sin su firma. El rol de SIGNER por sí solo no otorga acceso a las claves. Un firmante recibe recursos compartidos de claves solo cuando un administrador incluye al firmante o a su equipo en la política de claves de un llavero y crea una clave.

Método	Efecto en los roles de usuario
CreateUser	Cada rol ADMIN o POLICY_AUTHOR solicitado comienza en PENDING_ACTIVE. SIGNER es ACTIVE de inmediato.
EnableUserRole	Otorga un rol. ADMIN y POLICY_AUTHOR comienzan en PENDING_ACTIVE; SIGNER es ACTIVE de inmediato.
DisableUserRole	Quita un rol. En el caso de ADMIN y POLICY_AUTHOR, un rol de ACTIVE se convierte en PENDING_DISABLED, y un rol de PENDING_ACTIVE se cancela de inmediato, sin aprobación. SIGNER se convierte en DISABLED de inmediato.
DisableUser	Quita todos los roles del usuario en una solicitud, con una firma para todos los cambios de ADMIN y POLICY_AUTHOR.
ApproveUser	Registra la aprobación de un administrador del cambio pendiente del usuario.
EnableUser	Vuelve a establecer un usuario inhabilitado como ACTIVE. No restablece ningún rol ni necesita aprobación.

Una aprobación funciona de la siguiente manera:

1. Un administrador solicita el cambio y, además, incluye authorizationInfo: su firma, realizada con su clave de autorización, sobre el cambio de rol. Esta solicitud se considera la primera aprobación.
2. Otros administradores llaman a ApproveUser en el usuario, cada uno con su propia firma. Una aprobación cubre todos los cambios de rol pendientes de ese usuario.
3. Cuando la cantidad de aprobaciones alcanza el umbral de aprobación de administradores de la instancia, todos los cambios de rol pendientes del usuario se aplican juntos. Las aprobaciones se almacenan en el usuario en role_statuses.approval_info, y los TEE de los participantes las verifican.

Las siguientes reglas se aplican a todos los cambios de ADMIN y POLICY_AUTHOR:

• Al menos dos administradores activos Un cambio que dejaría la instancia con menos administradores activos que el umbral de aprobación de administradores falla con FAILED_PRECONDITION. La instancia nunca tiene menos de dos administradores activos. Los administradores cuyo rol es PENDING_DISABLED no se consideran activos.
• No se permite la autoaprobación. El usuario que se está cambiando no puede solicitar ni aprobar su propio cambio. Esa solicitud falla con PERMISSION_DENIED.
• Una aprobación por administrador. Si un administrador aprueba el mismo cambio dos veces, la segunda solicitud falla con ALREADY_EXISTS.
• Un cambio pendiente por usuario. Mientras haya un cambio pendiente, las solicitudes para habilitar un rol fallarán con FAILED_PRECONDITION. Las solicitudes para inhabilitar un rol nunca se bloquean: una inhabilitación cancela las habilitaciones pendientes y se combina con cualquier inhabilitación pendiente en un cambio nuevo cuyas aprobaciones comienzan de nuevo.
• Vencimiento. Un cambio que no alcanza suficientes aprobaciones antes del approval_info.expire_time vence, y sus roles vuelven a su estado anterior.

En la API de v1beta, no puedes inhabilitar el rol SIGNER ni el usuario mientras este tenga fragmentos de claves. Para reemplazar los fragmentos de clave de un firmante, se requiere volver a compartirlos, lo que se planea para una versión posterior.

Permisos de IAM

En la siguiente tabla, se enumeran cada método v1beta, el permiso de IAM que requiere y el rol predefinido con la menor cantidad de permisos que lo incluye. Cada rol predefinido también incluye todos los permisos de los roles anteriores: roles/mpc.editor incluye roles/mpc.viewer, y roles/mpc.admin incluye roles/mpc.editor.

Recurso	Método	Permiso	Rol predefinido
Equipo	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
Usuario	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
Clave	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
Transacción	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 obtener detalles sobre la solicitud y la respuesta, consulta la referencia de la API de REST de Multi-party Compute.

Roles predefinidos

Rol	Incluye	Destinado a
Visualizador de Multi-party Compute roles/mpc.viewer	Los permisos roles/mpc.viewer de la tabla anterior: get y list en cada recurso.	Auditores y herramientas de supervisión
Editor de Multi-party Compute roles/mpc.editor	Todos los permisos de roles/mpc.viewer, además de los permisos de roles/mpc.editor de la tabla anterior.	Principales de los firmantes y autores de políticas Sus roles de usuario deciden cuáles de estos métodos acepta la instancia de ellos.
Administrador de Multi-party Compute roles/mpc.admin	Todos los permisos de roles/mpc.editor, además de los permisos de roles/mpc.admin de la tabla anterior.	Principales de administradores.

Los recursos de v1beta no tienen sus propias políticas de IAM. Otorga roles en el proyecto que contiene tu instancia y usa las condiciones de IAM para limitar un rol a un llavero de claves.

Roles recomendados para cada perfil

Asigna a cada persona una principal distinta, un usuario con solo los roles que necesita y un rol de IAM que coincida:

Personificación	Funciones de usuario	Rol de IAM
Administrador	ADMIN	roles/mpc.admin
Autor de la política	POLICY_AUTHOR	roles/mpc.editor o un rol personalizado con los permisos transactionPolicies.*
Signer	SIGNER	roles/mpc.editor o un rol personalizado con los permisos transactions.*
Auditor	Ninguno	roles/mpc.viewer

Las principales federadas también necesitan el rol de consumidor de Service Usage (roles/serviceusage.serviceUsageConsumer) en el proyecto de consumidor. Para obtener más información, consulta Configura la federación de identidades de personal (BYOID).

Funciones personalizadas

Para otorgar a una principal solo los permisos que necesita, crea un rol de IAM personalizado. Por ejemplo, el siguiente rol permite que un firmante vea las transacciones y las apruebe o rechace, pero no que las cree:

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"

Reemplaza PROJECT_ID por el ID del proyecto que contiene tu instancia.

La instancia aún verifica el usuario del emisor: el usuario debe tener un recurso compartido de clave de la clave de la transacción para registrar una decisión.

Condiciones de IAM

Puedes restringir una vinculación de rol a los recursos de un llavero de claves con una condición de IAM en el nombre del recurso. Por ejemplo, si dos unidades de negocio comparten una instancia y cada una tiene su propio KeyRing, puedes otorgar a los firmantes de cada unidad roles/mpc.editor solo en su propio 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"

Reemplaza lo siguiente:

• PROJECT_ID: Es el ID del proyecto que contiene tu instancia.
• SA_NAME: Es el nombre de la cuenta de servicio.
• LOCATION: Es la región de tu instancia.
• INSTANCE_ID: Es el ID de tu instancia.
• KEYRING_ID: Es el ID del llavero de claves.

Los nombres de los recursos de v1beta no contienen /mpc/. Una condición copiada de la documentación de la versión preliminar privada (v1alpha1), como .../instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID, no coincide con ningún recurso v1beta.

Los usuarios, los equipos, las KeyLists y las políticas de transacciones pertenecen a la instancia, no a un llavero de claves, por lo que una vinculación con alcance de llavero de claves no otorga acceso a ellos.