Patrones de arquitectura para la federación de identidades

En este documento, se comparan cuatro patrones arquitectónicos para federar Cloud de Confiance by S3NScon un proveedor de identidad (IdP) externo. También proporciona orientación para ayudarte a elegir una arquitectura adecuada para tu caso de uso.

Los cuatro patrones de arquitectura son los siguientes:

Factores de decisión

Para elegir un patrón de arquitectura adecuado para tu organización, considera varios factores, incluidos los siguientes:

Cartera de servicios

Los servicios de Google administran la autenticación y la autorización de manera diferente. Esto afecta la forma en que configuras la federación de identidades. Dos factores determinan estas diferencias: el modelo de servicio SaaS en comparación con PaaS y IaaS, y el modelo de autorización IAM en comparación con el específico del servicio.

Modelos de servicio

  • Software como servicio (SaaS): Google administra por completo servicios como Gmail, Google Ads o la app de Gemini Enterprise. Estos servicios no requieren esfuerzo de desarrollo y están listos para usarse. Dado que los servicios de SaaS se dirigen a un público amplio, es posible que la mayoría de tus usuarios requieran acceso a ellos.
  • Plataforma como servicio (PaaS) o infraestructura como servicio (IaaS): La mayoría de los servicios deCloud de Confiance son PaaS o IaaS. Estos servicios permiten que los usuarios técnicos desarrollen, implementen y operen cargas de trabajo personalizadas. Dado que estos servicios se dirigen a un público técnico, solo un subconjunto de tus usuarios requiere acceso.

Modelos de autorización

Los servicios de Google implementan la autorización de una de las siguientes dos maneras:

  • IAM: La mayoría de los servicios Cloud de Confiance usan IAM para permitir que los administradores gestionen el acceso detallado a los recursos.
  • Autorización específica del servicio: Los servicios como Google Ads, Looker o Google Workspace no usan IAM. En su lugar, los administradores gestionan el acceso con herramientas específicas para cada servicio.

Estos factores dan como resultado los siguientes grupos de servicios:

SaaS PaaS o IaaS
Autorización basada en IAM Cloud de Confiance Servicios de SaaS, como la app de Gemini Enterprise y Gemini Notebook Enterprise Cloud de Confiance Servicios de IaaS y PaaS, como BigQuery o Compute Engine
Autorización específica del servicio Servicios de Google que no son de la nube, como Google Ads, Google Workspace y Google Maps Ninguno

Para elegir un patrón de arquitectura adecuado para tu organización, considera qué grupos de servicios se aplican a ella.

Residencia de los datos

Para autenticar a los usuarios y administrar las sesiones, Cloud Identity, Google Workspace y la federación de identidades de personal procesan información personal del usuario. Esta información del usuario puede incluir lo siguiente:

  • Nombres de usuario o direcciones de correo electrónico
  • Atributos del usuario, como nombres y apellidos
  • Nombres y membresías de grupos

Cloud Identity, Google Workspace y la federación de identidades de personal procesan estos datos según las condiciones de los datos del servicio y es posible que los almacenen fuera de las ubicaciones de tu organización o de los usuarios:

  • Cloud Identity y Google Workspace almacenan datos de servicio en centros de datos de Google y es posible que los repliquen en todos los centros de datos. Los datos almacenados pueden incluir información que no es esencial para la autenticación, como nombres de departamentos, direcciones o números de teléfono.
  • La Federación de identidades para la fuerza laboral almacena datos de servicio en Cloud de Confianceregiones y es posible que los replique en todas las regiones.

Si le otorgas acceso a un recurso a un usuario, IAM almacena su identificador principal en una vinculación de rol. Cloud de Confiance procesa las vinculaciones de rol según las condiciones de los datos de servicio y puede almacenarlas en todas las regiones Cloud de Confiance .

Los patrones de arquitectura que se describen en esta página requieren el almacenamiento de información del usuario, pero difieren en el tiempo que almacenan esa información:

Muchos IdP te permiten automatizar la suspensión o el borrado de cuentas de usuario cuando cambia el estado de la cuenta de usuario correspondiente en el IdP. Según tu IdP y su configuración, es posible que el IdP retrase la eliminación de la cuenta de usuario hasta que transcurra un período de gracia determinado, lo que puede extender el tiempo que Cloud de Confiancealmacena la información del usuario.

Integración de Gemini Enterprise con Microsoft 365

Gemini Enterprise te permite conectarte a los servicios de Microsoft 365 con dos tipos de conectores:

  • Conectores basados en la transferencia de datos: Estos conectores rastrean Microsoft 365 para crear un índice de búsqueda en Cloud de Confiance. Cuando un usuario envía una instrucción, Gemini Enterprise usa este índice para buscar contenido y realiza verificaciones de acceso de forma local evaluando las listas de control de acceso (LCA) obtenidas de Microsoft 365.
  • Conectores federados: Estos conectores consultan Microsoft 365 para cada instrucción. Usan la autorización delegada para permitir que Microsoft 365 realice las verificaciones de acceso directamente.

Los conectores basados en la transferencia de datos introducen requisitos específicos para la federación de usuarios:

  • Conocimiento de la pertenencia a un grupo: Las ACL de Microsoft 365 pueden incluir entradas para grupos y usuarios. Para evaluar si un usuario puede acceder al contenido, los conectores deben tener en cuenta todos los grupos a los que pertenece el usuario. Si el conector solo conoce un subconjunto de los grupos del usuario, es posible que permita o deniegue el acceso de forma incorrecta.
  • Conversión de identificadores: Para evaluar las LCA, el conector debe convertir los identificadores de usuarios y grupos que usa Microsoft 365 en los identificadores que usa Cloud de Confiance.

Cuando usas la federación de identidades de personal, Gemini Enterprise puede convertir identificadores y evaluar ACL de manera confiable si configuras las asignaciones de atributos para que sean compatibles con Gemini Enterprise.

Cuando usas la federación de Cloud Identity o Google Workspace, Microsoft Entra ID controla las asignaciones de atributos para el aprovisionamiento de usuarios y grupos, en lugar de Cloud de Confiance. Entra determina las reglas de conversión para los identificadores de usuarios y grupos, lo que puede implicar transformaciones complejas. Para evaluar una LCA, el conector de Gemini Enterprise debe aplicar las mismas reglas de conversión, pero el conector no tiene visibilidad de la configuración de Entra. Por lo tanto, cuando usas la federación de Cloud Identity o la federación de Google Workspace, Gemini Enterprise no puede convertir de forma confiable los identificadores de usuarios y grupos, ni evaluar las ACL de forma confiable.

Para determinar qué patrón de arquitectura se adapta mejor a tu organización, considera tu uso de Gemini Enterprise y si planeas usar conectores basados en la transferencia de datos.

Patrones de arquitectura

En el siguiente diagrama de flujo, se muestra cómo estos factores determinan qué patrón cumple con los requisitos de tu organización:

Diagrama de flujo que muestra cómo seleccionar el patrón de federación de identidades.

  1. ¿Una parte importante de tu organización usa Google Workspace?

  2. ¿Utilizas servicios más allá de Cloud de Confiance , como Google Ads o Google Maps?

    • Si la respuesta es Sí, continúa con la decisión 3.
    • Si la respuesta es No, continúa con la decisión 4.

  3. ¿Planeas usar Gemini Enterprise y, luego, integrarlo con Microsoft 365?

  4. ¿Planeas usar Gemini Enterprise?

  5. ¿Tienes requisitos de residencia de datos que te obligan a minimizar el almacenamiento de información del usuario?

Federación de Cloud Identity o Google Workspace

Selecciona este patrón cuando tu organización cumpla con uno de los siguientes criterios:

  • Una parte importante de tu organización ya usa Google Workspace.
  • Usas servicios de Google más allá de Cloud de Confiance , como Google Ads o Google Maps, pero no planeas integrar Gemini Enterprise con Microsoft 365 a través de conectores basados en la transferencia de datos.
  • Solo usas Cloud de Confiance servicios, no planeas usar Gemini Enterprise y no tienes requisitos estrictos de residencia de datos para minimizar el almacenamiento de datos del usuario.

En este patrón, no se usa la federación de identidades de personal. En su lugar, federas tu cuenta de Cloud Identity o tu cuenta de Google Workspace con tu IdP, y usas el aprovisionamiento de usuarios y el aprovisionamiento de grupos por adelantado.

Arquitectura de la federación de Cloud Identity y Google Workspace.

En este patrón, debes aprovisionar usuarios y grupos antes de que los usuarios puedan acceder. De lo contrario, su intento de acceso fallará:

  • Aprovisionamiento de usuarios: Ayuda a garantizar la incorporación y la baja oportunas de los usuarios.
  • Aprovisionamiento de grupos: Te permite usar grupos para administrar el acceso a los servicios y recursos de Google Cloud de Confiance .

Si solo un subconjunto de los usuarios de tu organización necesita Google Workspace, agrega una suscripción a Google Workspace y una suscripción a Cloud Identity a tu cuenta, y asigna licencias de Google Workspace solo a los usuarios que las necesiten.

Beneficios

  • Los usuarios pueden autenticarse en los servicios de Google, independientemente de si esos servicios usan IAM o no. En la cuenta de Cloud Identity o en la cuenta de Google Workspace, controla qué servicios de Google pueden usar los usuarios.
  • Puedes limitar el inicio de sesión único (SSO) y el aprovisionamiento anticipado a un subconjunto de usuarios, y seguir administrando usuarios específicos, como los usuarios con acceso de emergencia, directamente en Cloud Identity o en Google Workspace.
  • Puedes aprovisionar grupos desde tu IdP externo, administrarlos de forma local en tu cuenta de Cloud Identity o en tu cuenta de Google Workspace, o bien combinar ambos enfoques.

Limitaciones

  • El aprovisionamiento de cuentas de usuario con anticipación agrega sobrecarga y puede ralentizar el proceso de incorporación.

  • No puedes controlar ni restringir las ubicaciones que Cloud Identity o Google Workspace usan para almacenar datos de usuarios y grupos. Dado que Google procesa y almacena los datos del usuario y los datos del grupo según las condiciones de los datos de servicio, los controles de región de datos no abarcan esos datos, y Google podría replicarlos en las ubicaciones de los centros de datos de Google.

  • Gemini Enterprise proporciona compatibilidad limitada para conectarse a fuentes de datos de Microsoft cuando usas la federación de Cloud Identity o la federación de Google Workspace.

Federación de identidades de personal, sin sincronización

Selecciona este patrón cuando tu organización cumpla con los siguientes criterios:

  • Solo usas los servicios de Cloud de Confiance .
  • Usas Gemini Enterprise, pero esperas permanecer dentro de las limitaciones de grupos que impone tu IdP.
  • Tienes requisitos de residencia de datos que exigen minimizar el almacenamiento de información personal del usuario.

Arquitectura de la federación de identidades del personal, sin sincronización.

En este patrón, usas la federación de identidades de personal para federar tu organización deCloud de Confiance con tu IdP externo.

Este patrón no requiere el aprovisionamiento de usuarios ni de grupos. Cada vez que un usuario accede, el IdP pasa la información requerida sobre el usuario (incluidas las membresías de grupo y los atributos personalizados) a Cloud de Confiance, y Cloud de Confiance conserva esa información solo durante la sesión del usuario.

Beneficios

  • No es necesario que almacenes ni administres cuentas o grupos de usuarios enCloud de Confiance.
  • El patrón te permite usar conectores basados en la transferencia de datos para integrar Gemini Enterprise con Microsoft 365.

Limitaciones

  • La federación de identidades de personal es una función de IAM y solo permite que los usuarios accedan a los servicios que usan IAM. Los usuarios que se autentican con la federación de identidades de personal no pueden acceder a los servicios de Google, como Google Ads, Looker o Google Marketing Platform.
  • Los usuarios que se autentican con la federación de identidades de personal no pueden acceder a algunas Cloud de Confiance funciones. Para obtener más detalles, consulta Federación de identidades: productos y limitaciones.
  • Muchos IdPs limitan la cantidad de membresías de grupos que pueden pasar a la federación de identidades de personal en una aserción de SAML o un token de ID. Para no superar estos límites, es posible que debas reforzar la gobernanza del grupo y restringir los tipos de grupos que se pueden incluir en las aserciones o los tokens.
  • Cuando compartes recursos, como un cuaderno de Gemini Notebook Enterprise, no puedes buscar un grupo por su nombre. En su lugar, los usuarios deben ingresar sus identificadores manualmente.

Si usas Microsoft Entra ID, puedes usar una variación de este patrón configurando atributos adicionales. Cuando configuras atributos adicionales, la federación de identidades de personal ejecuta una devolución de llamada a la API de Microsoft Graph durante la autenticación del usuario para recuperar las membresías de grupo. Esta configuración te permite superar los límites de pertenencia a un grupo de Entra para las aserciones SAML y los tokens de ID, y usar hasta 999 pertenencias a un grupo por usuario.

Federación de identidades de personal con SCIM

Selecciona este patrón cuando tu organización cumpla con los siguientes criterios:

  • Solo usas los servicios de Cloud de Confiance . Es decir, no usas servicios externos de Google, como Google Ads o Google Maps.
  • Planeas usar Gemini Enterprise o Gemini Notebook Enterprise, y necesitas admitir hasta 2,000 membresías de grupo por usuario, o la capacidad de buscar grupos por nombre cuando compartes recursos.

Arquitectura de la federación de identidades de personal con SCIM.

En este patrón, usas la federación de identidades de personal para federar tu organización deCloud de Confiance . Para aumentar la cantidad de grupos que puedes usar en Gemini Enterprise, también debes configurar SCIM para aprovisionar la información de pertenencia a un grupo con anticipación.

Beneficios

  • El patrón te permite usar conectores basados en la transferencia de datos para integrar Gemini Enterprise con Microsoft 365.
  • Puedes usar hasta 2,000 membresías de grupo por usuario para controlar el acceso a Gemini Enterprise y Gemini Notebook Enterprise, y permitir que los conectores basados en la transferencia de datos de Gemini Enterprise realicen verificaciones de acceso.
  • Cuando compartes recursos, como un notebook de Gemini Notebook Enterprise, puedes buscar grupos por nombre para mejorar la experiencia general del usuario.

Limitaciones

  • La compatibilidad con grupos aprovisionados con SCIM se limita a Gemini Enterprise y Gemini Notebook Enterprise. Otros servicios solo pueden consumir las membresías de grupo que tu IdP pasa en la aserción de SAML o el token de ID.
  • La federación de identidades de personal es una función de IAM y solo permite que los usuarios accedan a los servicios que usan IAM. Los usuarios que se autentican con la federación de identidades de personal no pueden acceder a los servicios de Google, como Google Ads, Looker o Google Marketing Platform.
  • Los usuarios que se autentican con la federación de identidades de personal no pueden acceder a algunas de las Cloud de Confiance funciones. Para obtener más detalles, consulta Federación de identidades: productos y limitaciones.

Cloud Identity híbrida y federación de identidades de personal

Selecciona este patrón cuando tu organización cumpla con los siguientes criterios:

  • Usas servicios de Google más allá de Cloud de Confiance (como Google Ads o Google Maps).
  • Planeas usar Gemini Enterprise y lo integrarás con Microsoft 365.

Arquitectura de la federación híbrida de Cloud Identity y la federación de identidades de personal.

Este patrón combina dos de los patrones anteriores:

  • Usas la federación de identidades de personal (sin sincronización o con SCIM) para administrar el acceso a Gemini Enterprise y a Gemini Notebook Enterprise.
  • Usas la federación de Cloud Identity o Google Workspace para administrar el acceso a otros servicios, incluidos Cloud de Confiance y los servicios de Google que no son de la nube.

Beneficios

Este patrón te permite combinar los beneficios de los dos patrones anteriores:

  • Puedes conectar Gemini Enterprise a fuentes de datos de Microsoft sin limitaciones de funciones.
  • Los usuarios pueden autenticarse en los servicios de Google, independientemente de si esos servicios usan IAM o no.
  • Usa el conjunto completo de atributos Cloud de Confiance .

Limitaciones

  • Debes mantener dos configuraciones de entidad de confianza separadas en tu IdP externo: una para Cloud Identity y otra para la federación de identidades de personal.
  • Según si configuras un usuario para que use Cloud Identity o la federación de identidades de personal, su experiencia de acceso puede variar.
  • Cuando administras políticas de permisos de IAM, debes usar diferentes identificadores de principal según cómo se autentique un usuario. Por ejemplo, un usuario conocido como bob@example.com en tu IdP externo podría tener el identificador principal bob@example.com o principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID en IAM, según si se autentica con la federación de identidades de Cloud Identity o con la federación de identidades de personal.
  • No puedes crear grupos que contengan una combinación de usuarios de Cloud Identity y principales de la federación de identidades de personal. Los grupos de Cloud Identity solo pueden contener usuarios de Cloud Identity, y los grupos de identidades de personal solo pueden contener principales de la federación de identidades de personal.
  • Extender el uso de la federación de identidades de personal más allá de Gemini Enterprise puede requerir que los usuarios cambien de identidad o hacer que no sepan cómo autenticarse.

¿Qué sigue?