Arquitecturas de referencia

Last reviewed 2024-07-11 UTC

En este documento, se presentan arquitecturas típicas que puedes usar como referencia para administrar identidades corporativas. Dos principios básicos de la administración de identidades corporativas son los siguientes:

  • Una fuente autorizada para las identidades, el único sistema que usas a fin de crear, administrar y borrar identidades para tus empleados. Las identidades administradas en el sistema fuente autorizado pueden propagarse a otros sistemas

  • Un proveedor de identidad (IdP) central, que es el único sistema de autenticación y que proporciona una experiencia de inicio de sesión único para tus empleados que abarca aplicaciones

Cuando usas Google Cloud y otros servicios de Google, debes decidir qué sistema usar como tu proveedor de identidad y qué sistema usar como fuente autorizada.

Usa Google como IdP

Mediante Cloud Identity Premium o Google Workspace, puedes convertir a Google en tu IdP principal. Google ofrece una gran selección de integraciones listas para usar para aplicaciones populares de terceros, y puedes usar protocolos estándar como SAML, OAuth y OpenID Connect para integrar tus aplicaciones personalizadas.

Google como IdP y fuente autorizada

Puedes usar Cloud Identity Premium o Google Workspace como IdP y fuente autorizada, como se muestra en el siguiente diagrama.

Google como IdP y fuente autorizada.

  • Usa Cloud Identity Premium o Google Workspace para administrar usuarios y grupos.
  • Todos los servicios de Google usan Cloud Identity Premium o Google Workspace como IdP.
  • Configuras aplicaciones corporativas y otros servicios de SaaS para usar Google como IdP.

Experiencia del usuario

En esta configuración, para un empleado, la experiencia de inicio de sesión del usuario se ve de la siguiente manera:

  1. Cuando solicitas un recurso protegido o acceso a una aplicación corporativa, se redirecciona al empleado a la pantalla de Acceso con Google, que te solicita la dirección de correo electrónico y la contraseña.
  2. Si la verificación en dos pasos está habilitada, se le solicita al empleado que proporcione un segundo factor, como una clave USB o un código.
  3. Cuando se autentica al empleado, se lo redirecciona al recurso protegido.

Ventajas

Usar Google como IdP y fuente autorizada tiene las siguientes ventajas:

Cuándo se debe usar esta arquitectura

Considera usar Google como IdP y fuente autorizada en las siguientes situaciones:

  • Ya usas Google Workspace como solución de colaboración y productividad.
  • No hay una infraestructura local o un IdP existente que debas integrar o que desees mantener separado de todos tus recursos en Google (en Google Cloud, en Google Ads, etcétera).
  • No necesitas la integración con un sistema de información de recursos humanos (HRIS) para administrar identidades.

Google como IdP con un HRIS como fuente autorizada

Si usas un sistema de información de recursos humanos (HRIS) para administrar el proceso de integración y desvinculación de tus empleados, puedes usar Google como tu IdP. Cloud Identity y Google Workspace proporcionan APIs que permiten que el HRIS y otros sistemas controlen la administración de usuarios y grupos, como se muestra en el siguiente diagrama.

Google como IdP con un HRIS como fuente autorizada.

  • Puedes usar tus HRIS existentes para administrar usuarios y, de forma opcional, grupos. El HRIS sigue siendo la única fuente de información para la administración de identidades y aprovisiona de forma automática usuarios para Cloud Identity o G Workspace.
  • Todos los servicios de Google usan Cloud Identity Premium o Google Workspace como IdP.
  • Configuras aplicaciones corporativas y otros servicios de SaaS para usar Google como IdP.

Experiencia del usuario

Para un empleado, la experiencia de inicio de sesión del usuario es equivalente a usar Google como IdP y fuente autorizada.

Ventajas

Usar Google como IdP y fuente autorizada tiene las siguientes ventajas:

Cuándo se debe usar esta arquitectura

Considera el uso de Google como tu IdP con un HRIS como fuente autorizada en los siguientes casos:

  • Tienes un sistema de tipo HRIS o de otro tipo que funciona como la fuente autorizada para las identidades.
  • Ya usas Google Workspace como solución de colaboración y productividad.
  • No existe una infraestructura local o un IdP existente que debas integrar o que desees mantener separado de tu estado de Google.

Usa un IdP externo

Si tu organización ya usa un IdP, como Active Directory, Azure AD, ForgeRock, Okta o Ping Identity, puedes integrar Google Cloud con este IdP externo mediante la federación.

Si federas una cuenta de Cloud Identity o Google Workspace con un IdP externo, puedes permitir que los empleados usen sus identidades y credenciales existentes para acceder a los servicios de Google, como Google Cloud, Google Marketing Platform y Google Ads.

IDaaS externo como IdP y fuente autorizada

Si usas una identidad como proveedor de servicios (IDaaS), como ForgeRock, Okta o Ping Identity, puedes configurar la federación como se ilustra en el siguiente diagrama.

IDaaS externo como IdP y fuente autorizada.

  • Cloud Identity o Google Workspace usan tu IDaaS como IdP para el inicio de sesión único.
  • El IDaaS aprovisiona de forma automática usuarios y grupos para Cloud Identity o Google Workspace.
  • Las aplicaciones corporativas existentes y otros servicios de SaaS pueden continuar con tus IDaaS como IdP.

Para obtener más información sobre cómo federar Cloud Identity o Google Workspace con Okta, consulta Aprovisionamiento de usuarios de Okta y el inicio de sesión único.

Experiencia del usuario

Para un empleado, la experiencia de inicio de sesión del usuario se ve de la siguiente manera:

  1. Cuando se solicita un recurso protegido, se redirecciona al empleado a la pantalla de Acceso con Google, que le solicita la dirección de correo electrónico y la contraseña.
  2. El Acceso con Google te redirecciona a la página de acceso de tu IDaaS.
  3. Realiza la autenticación con tu IDaaS. Según tu IDaaS, es posible que debas proporcionar un segundo factor, como un código.
  4. Después de la autenticación, se te redirecciona al recurso protegido.

Ventajas

Usar un IDaaS externo como IdP y fuente autorizada tiene las siguientes ventajas:

  • Habilitas una experiencia de inicio de sesión único para tus empleados que se extiende a través de los servicios de Google y otras aplicaciones integradas a tu IDaaS.
  • Si configuraste tu IDaaS para que requiera autenticación de varios factores, esa configuración se aplica automáticamente a Google Cloud.
  • No necesitas sincronizar contraseñas ni otras credenciales con Google.
  • Puedes usar la versión gratuita de Cloud Identity.

Cuándo se debe usar esta arquitectura

Considera usar un IDaaS externo como IdP y una fuente autorizada en las siguientes situaciones:

  • Ya usas un proveedor de IDaaS como ForgeRock, Okta o Ping Identity como tu IdP.

Prácticas recomendadas

Consulta nuestras prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.

Active Directory como IdP y fuente autorizada

Si usas Active Directory como la fuente de información para la administración de identidades, puedes configurar la federación como se ilustra en el siguiente diagrama.

Active Directory como IdP y fuente autorizada.

  • Usa Google Cloud Directory Sync (GCDS) para aprovisionar usuarios y grupos de forma automática desde Active Directory para Cloud Identity o Google Workspace. Google Cloud Directory Sync es una herramienta gratuita que proporciona Google para implementar el proceso de sincronización y se puede ejecutar en Google Cloud o en tu entorno local. La sincronización es unidireccional para que Active Directory continúe siendo la fuente de información.
  • Cloud Identity o Google Workspace usan los Servicios de federación de Active Directory (AD FS) para el inicio de sesión único.
  • Las aplicaciones corporativas existentes y otros servicios de SaaS pueden seguir usando tu AD FS como IdP.

Para una variación de este patrón, también puedes usar los Servicios de directorio básicos de Active Directory (AD LDS) o un directorio LDAP diferente con AD FS o con otro IdP compatible con SAML.

Para obtener más información sobre este enfoque, consulta Cómo federar Google Cloud con Active Directory.

Experiencia del usuario

  1. Cuando se solicita el recurso protegido, se redirecciona al empleado a la pantalla de Acceso con Google, que le solicita su dirección de correo electrónico.
  2. El Acceso con Google redirecciona al empleado a la página de acceso de AD FS.
  3. Según la configuración de AD FS, el empleado podría ver una pantalla de acceso que solicita su nombre de usuario y contraseña de Active Directory. Como alternativa, AD FS podría intentar que el empleado acceda de forma automática en función de su acceso a Windows.
  4. Una vez que AD FS haya autenticado al empleado, se lo redireccionará al recurso protegido.

Ventajas

Usar Active Directory como IdP y fuente autorizada tiene las siguientes ventajas:

  • Habilitas una experiencia de inicio de sesión único para tus empleados que se extiende a través de los servicios de Google y tu entorno local.
  • Si configuraste AD FS para que requiera autenticación de varios factores, esa configuración se aplica automáticamente a Google Cloud.
  • No es necesario que sincronices contraseñas ni otras credenciales con Google.
  • Puedes usar la versión gratuita de Cloud Identity.
  • Debido a que las APIs que usa GCDS son de acceso público, no es necesario configurar la conectividad híbrida entre tu red local y Google Cloud.

Cuándo se debe usar esta arquitectura

Considera usar Active Directory como IdP y fuente autorizada en las siguientes situaciones:

  • Tienes una infraestructura de Active Directory existente.
  • Deseas proporcionar una experiencia de acceso sin interrupciones para los usuarios de Windows.

Prácticas recomendadas

Considera estas prácticas recomendadas:

  • Active Directory y Cloud Identity usan una estructura lógica diferente. Asegúrate de comprender las diferencias y evaluar qué método de asignación de dominios, identidades y grupos se adapta mejor a tu situación. Para obtener más información, consulta nuestra guía sobre la federación de Google Cloud con Active Directory.
  • Sincroniza grupos además de usuarios. Con este enfoque, puedes configurar IAM para usar las membresías de grupo en Active Directory a fin de controlar quién tiene acceso a qué recursos enGoogle Cloud.
  • Implementa y expón AD FS para que los usuarios corporativos puedan acceder a él, pero no lo expongas más de lo necesario. Aunque los usuarios corporativos deben poder acceder a AD FS, no es necesario que se pueda acceder desde Cloud Identity o Google Workspace, o desde cualquier aplicación implementada en Google Cloud.
  • Considera habilitar la autenticación de Windows integrada (IWA) en AD FS para permitir que los usuarios accedan de forma automática en función de su acceso a Windows.
  • Si AD FS no está disponible, es posible que los usuarios no puedan usar la consola de Google Cloud o cualquier otro recurso que use Google como IdP. Por lo tanto, asegúrate de que AD FS y los controladores de dominio en los que confía estén implementados y tengan el tamaño adecuado para cumplir con los objetivos de disponibilidad.
  • Si usas Google Cloud para garantizar la continuidad del negocio, depender de un AD FS local podría socavar la intención de usarGoogle Cloud como una copia independiente de tu implementación. En este caso, considera implementar las réplicas de todos los sistemas relevantes en Google Cloudde una de las siguientes maneras:

    • Extiende tu dominio de Active Directory existente a Google Cloud y, luego, implementa GCDS para que se ejecute enGoogle Cloud.
    • Ejecuta servidores de AD FS dedicados en Google Cloud. Estos servidores usan los controladores de dominio de Active Directory que se ejecutan enGoogle Cloud.
    • Configura Cloud Identity para usar los servidores de AD FS implementados en Google Cloud para el inicio de sesión único.

Para obtener más información, consulta Prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.

Azure AD como IdP con Active Directory como fuente autorizada

Si eres cliente de Microsoft Office 365 o Azure, es posible que hayas conectado el Active Directory local a Azure AD. Si todas las cuentas de usuario que pueden necesitar acceso a Google Cloud ya se están sincronizando con Azure AD, puedes volver a usar esta integración mediante la federación de Cloud Identity con Azure AD, como se muestra en el siguiente diagrama.

Azure AD como IdP con Active Directory como fuente autorizada.

  • Azure AD permite que se aprovisionen de manera automática usuarios y grupos a Cloud Identity o Google Workspace. Azure AD puede integrarse a un Active Directory local.
  • Cloud Identity o Google Workspace usan Azure AD para el inicio de sesión único.
  • Las aplicaciones corporativas existentes y otros servicios de SaaS pueden seguir usando Azure AD como IdP.

Para obtener información más detallada sobre este enfoque, consulta cómo federar Google Cloud con Azure Active Directory.

Experiencia del usuario

  1. Cuando se solicita el recurso protegido, se redirecciona al empleado a la pantalla de Acceso con Google, que le solicita su dirección de correo electrónico.
  2. El Acceso con Google lo redirecciona a la página de acceso de AD FS.
  3. Según cómo se conecte su Active Directory local a Azure AD, es posible que Azure AD le solicite un nombre de usuario y una contraseña, o que lo redireccione a un AD FS local.
  4. Una vez que el empleado se autentica con Azure AD, se lo redirecciona al recurso protegido.

Ventajas

Usar Azure AD como tu IdP con Active Directory como fuente autorizada tiene varias ventajas:

  • Habilitas una experiencia de inicio de sesión único para tus empleados que se extiende a través de los servicios de Google, Azure y tu entorno local.
  • Si configuraste Azure AD para que requiera autenticación de varios factores, esa configuración se aplica automáticamente a Google Cloud.
  • No es necesario instalar ningún software local adicional.
  • Si Active Directory local usa varios dominios o bosques y tienes una configuración personalizada de Azure AD Connect para mapear esta estructura a un usuario de Azure AD, puedes aprovechar este trabajo de integración.
  • No es necesario que sincronices contraseñas ni otras credenciales con Google.
  • Puedes usar la versión gratuita de Cloud Identity.
  • Puedes mostrar la consola de Google Cloud como un mosaico en el portal de Office 365.
  • Debido a que las APIs que usa Azure AD son de acceso público, no es necesario configurar la conectividad híbrida entre Azure y Google Cloud.

Cuándo se debe usar esta arquitectura

Considera usar Azure AD como IdP con Active Directory como fuente autorizada en las siguientes situaciones:

  • Ya usas Azure AD y lo integraste a una infraestructura de Active Directory existente.
  • Deseas proporcionar una experiencia de acceso sin interrupciones para los usuarios de Azure y Google Cloud.

Prácticas recomendadas

Sigue las prácticas recomendadas a continuación:

  • Azure AD y Cloud Identity usan una estructura lógica diferente, por lo que es importante que comprendas las diferencias. Evalúa qué método de asignación de dominios, identidades y grupos se adapta mejor a tu situación. Para obtener información más detallada, consulta cómo federar Google Cloud con Azure AD.
  • Sincroniza grupos además de usuarios. Con este enfoque, puedes configurar IAM para que puedas usar las membresías de grupo en Azure AD a fin de controlar quién tiene acceso a los recursos enGoogle Cloud.
  • Si usas Google Cloud para garantizar la continuidad del negocio, depender de Azure AD para la autenticación podría socavar la intención de usarGoogle Cloud como una copia independiente de tu implementación.

Para obtener más información, consulta Prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.

¿Qué sigue?