Patrones para autenticar a los usuarios de la plantilla en un entorno híbrido

Este documento es la segunda parte de una serie de artículos que explican cómo ampliar tu solución de gestión de identidades a Google Cloud para que los usuarios de tu empresa puedan autenticarse y consumir servicios en un entorno de computación híbrido.

La serie consta de los siguientes documentos:

• Autenticar usuarios de la plantilla en un entorno híbrido
• Patrones para autenticar a los usuarios de la plantilla en un entorno híbrido (este documento)

Introducción

Cuando amplías tu infraestructura de TI a Google Cloud como parte de una estrategia híbrida, te recomendamos que gestiones las identidades de forma coherente en todos los entornos. A medida que diseñes y adaptes tu arquitectura para cumplir estas restricciones y requisitos, podrás recurrir a algunos patrones comunes. Estos patrones se dividen en dos categorías:

• Patrones para federar un proveedor de identidades externo con Google Cloud. El objetivo de estos patrones es permitir que Google se convierta en un proveedor de identidades para los usuarios de tu empresa, de forma que las identidades de Google se mantengan automáticamente y tu proveedor de identidades siga siendo la fuente de información veraz.
• Patrones para ampliar un proveedor de identidades a Google Cloud. En estos patrones, permites que las aplicaciones implementadas en Google Cloud reutilicen tu proveedor de identidades, ya sea conectándose directamente a él o manteniendo una réplica de tu proveedor de identidades en Google Cloud.

Patrones para federar un proveedor de identidades externo con Google Cloud

Para habilitar el acceso a la consola de Google Cloud, a la CLI de Google Cloud o a cualquier otro recurso que use Google como IdP, un usuario de la fuerza de trabajo debe tener una identidad de Google. Google Cloud Mantener las identidades de Google de cada empleado sería engorroso si todos los empleados ya tuvieran una cuenta en un proveedor de identidades. Al federar las identidades de usuario entre tu IdP y Google Cloud, puedes automatizar el mantenimiento de las cuentas de Google y vincular su ciclo de vida a las cuentas que ya tengas. La federación ayuda a garantizar lo siguiente:

• Tu IdP sigue siendo la única fuente de información veraz para la gestión de identidades.
• Se crea automáticamente una cuenta de Google para todas las cuentas de usuario que gestione tu proveedor de identidades o para un subconjunto seleccionado de esas cuentas.
• Si se inhabilita o se elimina una cuenta en tu proveedor de identidades, se suspenderá o se eliminará la cuenta de Google correspondiente.
• Para evitar que se copien contraseñas u otras credenciales, la autenticación de un usuario se delega en tu proveedor de identidades.

Federar Active Directory con Cloud Identity mediante Google Cloud Directory Sync y AD FS

Si usas Active Directory como IdP, puedes federar Active Directory con Cloud Identity mediante Google Cloud Directory Sync (GCDS) y Active Directory Federation Services (AD FS):

• GCDS es una herramienta gratuita proporcionada por Google que implementa el proceso de sincronización. GCDS se comunica con Identity Platform a través de la capa de conexión segura (SSL) y suele ejecutarse en el entorno de computación actual.
• Microsoft proporciona AD FS como parte de Windows Server. Con AD FS, puedes usar Active Directory para la autenticación federada. AD FS suele ejecutarse en el entorno informático actual.

Para obtener información más detallada sobre este método, consulta Federar Google Cloud con Active Directory.

Para obtener una variante de este patrón, también puedes usar Active Directory Lightweight Directory Services (AD LDS) u otro directorio LDAP con AD FS u otro proveedor de identidades compatible con SAML.

Experiencia de usuario

1. Cuando solicitas el recurso protegido, se te redirige a la pantalla de inicio de sesión de Google, donde se te pide tu dirección de correo.
2. Si se sabe que la dirección de correo está asociada a una cuenta que se ha sincronizado desde Active Directory, se le redirigirá a AD FS.
3. En función de la configuración de AD FS, puede que veas una pantalla de inicio de sesión en la que se te pida tu nombre de usuario y contraseña de Active Directory. O bien, AD FS puede intentar iniciar sesión automáticamente en función de tu inicio de sesión de Windows (IWA).
4. Cuando AD FS te haya autenticado, se te redirigirá al recurso protegido.

Ventajas

• Este enfoque permite disfrutar de una experiencia de inicio de sesión único en las aplicaciones y los recursos locales de Google Cloud.
• Si has configurado AD FS para que requiera la autenticación multifactor, esa configuración se aplicará automáticamente a Google Cloud.
• No es necesario que sincronices contraseñas ni otras credenciales con Google.
• Como se puede acceder públicamente a la API Cloud Identity, no es necesario configurar la conectividad híbrida entre tu red local y Google Cloud.

Prácticas recomendadas

• Active Directory y Cloud Identity usan una estructura lógica diferente. Asegúrate de que entiendes las diferencias y evalúa qué forma de asignar dominios, identidades y grupos se adapta mejor a tu situación. Consulta nuestra guía sobre la federación Google Cloud con Active Directory para obtener información más detallada.
• Sincronizar grupos además de usuarios. Con este enfoque, puedes configurar IAM para usar las pertenencias a grupos de Active Directory y controlar quién tiene acceso a los recursos de Google Cloud.
• Implementa y expón AD FS para que los usuarios de la plantilla puedan acceder a él, pero no lo expongas más de lo necesario. Aunque los usuarios de la plantilla deben poder acceder a AD FS, no es necesario que se pueda acceder a AD FS desde Google ni desde ninguna aplicación implementada en Google Cloud.
• Considera la posibilidad de habilitar la autenticación integrada de Windows (IWA) en AD FS para permitir que los usuarios inicien sesión automáticamente en función de su inicio de sesión de Windows.
• Si AD FS deja de estar disponible, es posible que los usuarios no puedan usar la Google Cloud consola ni ningún otro recurso que utilice Google como IdP. Por lo tanto, asegúrate de que AD FS y los controladores de dominio en los que se basa AD FS estén desplegados y dimensionados para cumplir tus objetivos de disponibilidad.
• Si usas Google Cloud para ayudar a garantizar la continuidad empresarial, depender de un AD FS local podría menoscabar el objetivo de usarGoogle Cloud como copia independiente de tu implementación. En este caso, te recomendamos que implementes réplicas de todos los sistemas pertinentes en Google Cloud:
  • Replica tu Active Directory en Google Cloud y despliega GCDS para que se ejecute en Google Cloud.
  • Ejecuta servidores de AD FS dedicados en Google Cloud. Estos servidores usan los controladores de dominio de Active Directory que se ejecutan en Google Cloud.
  • Configura Cloud Identity para que use los servidores de AD FS implementados en Google Cloud para el inicio de sesión único.

Federar Entra ID con Cloud Identity

Si eres cliente de Microsoft Office 365 o Azure, es posible que hayas conectado tu servicio Active Directory local a Microsoft Entra ID (anteriormente Azure AD). Si todas las cuentas de usuario que puedan necesitar acceso a Google Cloud ya se están sincronizando con Entra ID, puedes reutilizar esta integración federando Cloud Identity con Entra ID, tal como se muestra en el siguiente diagrama.

Para obtener información más detallada sobre este enfoque, consulta el artículo sobre la federación Google Cloud con Microsoft Entra ID.

Experiencia de usuario

1. Cuando solicitas el recurso protegido, se te redirige a la pantalla de inicio de sesión de Google, donde se te pide tu dirección de correo.
2. Si la dirección de correo está asociada a una cuenta que se ha sincronizado desde Entra ID, se le redirigirá a Entra ID.
3. En función de cómo esté conectado tu Active Directory local a Entra ID, es posible que Entra ID te pida un nombre de usuario y una contraseña. También puede que te redirija a un AD FS local.
4. Una vez que te hayas autenticado correctamente con Entra ID, se te redirigirá al recurso protegido.

Ventajas

• No es necesario instalar ningún software adicional en las instalaciones.
• Este enfoque permite disfrutar de una experiencia de inicio de sesión único en Office 365, Azure y los recursos de Google Cloud.
• Si has configurado Entra ID para que requiera la autenticación multifactor (MFA), esta se aplicará automáticamente a Google Cloud.
• Si tu instancia de Active Directory local usa varios dominios o bosques y has configurado una instancia personalizada de Entra ID Connect para asignar esta estructura a un cliente de Entra ID, puedes aprovechar esta integración.
• No es necesario que sincronices contraseñas ni otras credenciales con Google.
• Como se puede acceder públicamente a la API Cloud Identity, no es necesario configurar la conectividad híbrida entre tu red local y Google Cloud o entre Azure yGoogle Cloud.
• Puedes mostrar la Google Cloud consola como una baldosa en el portal de Office 365.

Prácticas recomendadas

• Como Entra ID y Cloud Identity usan una estructura lógica diferente, asegúrate de que conoces las diferencias. Evalúa qué forma de asignar dominios, identidades y grupos se adapta mejor a tu situación. Para obtener más información, consulta el artículo sobre la federación Google Cloud con Entra ID.
• Sincronizar grupos además de usuarios. Con este método, puedes configurar IAM para usar las pertenencias a grupos de Entra ID y controlar quién tiene acceso a los recursos de Google Cloud.
• Si usas Google Cloud para ayudar a garantizar la continuidad de la empresa, depender de Entra ID para la autenticación podría socavar la intención de usarGoogle Cloud como copia independiente de tu implementación.

Patrones para ampliar un proveedor de identidades externo a Google Cloud

Es posible que algunas de las aplicaciones que tienes previsto implementar en Google Cloud requieran el uso de protocolos de autenticación que no ofrece Cloud Identity. Para admitir estas cargas de trabajo, debes permitir que estas aplicaciones usen tu IdP desde Google Cloud.

En las siguientes secciones se describen patrones habituales para permitir que las cargas de trabajo implementadas en Google Cloudusen tu proveedor de identidades.

Exponer un AD FS local a Google Cloud

Si una aplicación requiere el uso de WS-Trust o WS-Federation, o depende de funciones o reclamaciones específicas de AD FS al usar OpenID Connect, puedes permitir que la aplicación use directamente AD FS para la autenticación.

Al usar AD FS, una aplicación puede autenticar a un usuario. Sin embargo, como la autenticación no se basa en una identidad de Google, la aplicación no podrá hacer ninguna llamada a la API autenticada con las credenciales del usuario. En su lugar, las llamadas a las APIs de Google Cloud deben autenticarse con una cuenta de servicio.

Experiencia de usuario

1. Cuando solicitas el recurso protegido, se te redirige a la pantalla de inicio de sesión de ADFS, donde se te pide tu dirección de correo. Si AD FS no está expuesto públicamente en Internet, es posible que tengas que conectarte a la red de tu empresa o a la VPN corporativa para acceder a AD FS.
2. En función de la configuración de AD FS, puede que veas una pantalla de inicio de sesión en la que se te pida tu nombre de usuario y contraseña de Active Directory. O bien, AD FS puede intentar iniciar sesión automáticamente en función de tu inicio de sesión de Windows.
3. Cuando AD FS te haya autenticado, se te redirigirá al recurso protegido.

Ventajas

• Puedes usar protocolos de autenticación que no sean compatibles con Cloud Identity, como WS-Trust y WS-Federation.
• Si la aplicación se ha desarrollado y probado con AD FS, puedes evitar los riesgos que podrían surgir al cambiar la aplicación para que use Cloud Identity.
• No es necesario configurar la conectividad híbrida entre tu red on-premise y Google Cloud.

Prácticas recomendadas

• Implementa y expón AD FS para que los usuarios de la plantilla puedan acceder a él, pero no lo expongas más de lo necesario. Aunque los usuarios de la plantilla deben poder acceder a AD FS, no es necesario que se pueda acceder a AD FS desde Google ni desde ninguna aplicación implementada en Google Cloud.
• Si AD FS deja de estar disponible, es posible que los usuarios no puedan seguir usando la aplicación. Asegúrate de que AD FS y los controladores de dominio de los que depende estén desplegados y dimensionados para cumplir tus objetivos de disponibilidad.
• Te recomendamos que refactorices las aplicaciones que dependen de WS-Trust y WS-Federation para que usen SAML u OpenID Connect.
• Si la aplicación depende de que la información de los grupos se exponga como reclamaciones en IdTokens emitidas por AD FS, considera la posibilidad de obtener la información de los grupos de otra fuente, como la API Directory. Consultar la API Directory es una operación con privilegios que requiere el uso de una cuenta de servicio que tenga habilitada la delegación en todo el dominio de Google Workspace.

Exponer un directorio LDAP local a Google Cloud

Es posible que algunas de tus aplicaciones requieran que los usuarios proporcionen su nombre de usuario y contraseña, y que utilicen estas credenciales para intentar una operación de enlace LDAP. Si no puedes modificar estas aplicaciones para que usen otros medios, como SAML, para realizar la autenticación, puedes concederles acceso a un directorio LDAP local.

Ventajas

• No es necesario que cambies tu aplicación.

Prácticas recomendadas

• Usa Cloud VPN o Cloud Interconnect para establecer una conectividad híbrida entre Google Cloud y tu red on-premise, de forma que no tengas que exponer el directorio LDAP en Internet.
• Verifica que la latencia introducida al consultar un directorio LDAP local no afecte negativamente a la experiencia del usuario.
• Asegúrate de que la comunicación entre la aplicación y el directorio LDAP esté cifrada. Puedes conseguir este cifrado mediante Cloud VPN o Cloud Interconnect con LDAP/S.
• Si el directorio LDAP o la conectividad privada entreGoogle Cloud y tu red local no están disponibles, es posible que los usuarios no puedan seguir usando una aplicación basada en LDAP. Por lo tanto, asegúrate de que los servidores respectivos se implementen y dimensionen para cumplir tus objetivos de disponibilidad, y considera la posibilidad de usar túneles VPN redundantes o interconexiones.
• Si usas Google Cloud para garantizar la continuidad de tu negocio, depender de un directorio LDAP local puede menoscabar el objetivo de usarGoogle Cloud como copia independiente de tu implementación. En este caso, te recomendamos que repliques el directorio LDAP en Google Cloud .
• Si usas Active Directory, te recomendamos que ejecutes una réplica en Google Cloud , sobre todo si tienes previsto unir al dominio equipos Windows que se ejecuten enGoogle Cloud .

Replicar un directorio LDAP local en Google Cloud

La replicación de un directorio LDAP local en Google Cloud es similar al patrón de exposición de un directorio LDAP local a Google Cloud. En el caso de las aplicaciones que usan LDAP para verificar nombres de usuario y contraseñas, el objetivo de este enfoque es poder ejecutar esas aplicaciones en Google Cloud. En lugar de permitir que estas aplicaciones consulten tu directorio LDAP local, puedes mantener una réplica del directorio local en Google Cloud.

Ventajas

• No es necesario que cambies tu aplicación.
• La disponibilidad de las aplicaciones basadas en LDAP que se ejecutan en Google Cloud no depende de la disponibilidad del directorio local ni de la conectividad a la red local. Este patrón es adecuado para situaciones híbridas de continuidad empresarial.

Prácticas recomendadas

• Usa Cloud VPN o Cloud Interconnect para establecer una conectividad híbrida entre Google Cloud y tu red on-premise, de forma que no tengas que exponer el directorio LDAP en Internet.
• Asegúrate de que la replicación entre el directorio LDAP local se realice a través de un canal seguro.
• Despliega varias réplicas del directorio LDAP en varias zonas o regiones para cumplir tus objetivos de disponibilidad. Puedes usar un balanceador de carga interno para distribuir las conexiones LDAP entre varias réplicas implementadas en la misma región.
• Usa un Google Cloud proyecto independiente con una VPC compartida para desplegar réplicas de LDAP y conceder acceso a este proyecto con el principio de privilegio mínimo.

Extender un Active Directory local a Google Cloud

Algunas de las cargas de trabajo que tiene previsto desplegar en Google Cloud pueden depender de los servicios de dominio de Active Directory. Por ejemplo:

• Equipos Windows que deben unirse a un dominio
• Aplicaciones que usan Kerberos o NTLM para la autenticación
• Aplicaciones que usan Active Directory como directorio LDAP para verificar nombres de usuario y contraseñas

Para admitir este tipo de cargas de trabajo, puedes ampliar tu bosque de Active Directory local a Google Cloud. Por ejemplo, puedes desplegar un bosque de recursos enGoogle Cloud y conectarlo a tu bosque de Active Directory local, como se muestra en el siguiente diagrama.

Para obtener más información sobre este enfoque y otras formas de implementar Active Directory en un entorno híbrido, consulta Patrones para usar Active Directory en un entorno híbrido.

Ventajas

• Tus cargas de trabajo pueden aprovechar al máximo Active Directory, incluida la posibilidad de unir máquinas Windows al dominio de Active Directory.
• La disponibilidad de las aplicaciones basadas en Active Directory que se ejecutan enGoogle Cloud no depende de la disponibilidad de los recursos locales ni de la conectividad a la red local. Este patrón es adecuado para situaciones híbridas de continuidad empresarial.

Prácticas recomendadas

• Usa Cloud VPN o Cloud Interconnect para establecer una conectividad híbrida entre Google Cloud y tu red on-premise.
• Para minimizar la comunicación entre Google Cloud y tu red local, crea un sitio de Active Directory independiente para las implementaciones de Google Cloud. Puedes usar un solo sitio por VPC compartida o, para minimizar la comunicación entre regiones, un sitio por VPC compartida y región.
• Crea un dominio de Active Directory independiente dedicado a los recursos implementados enGoogle Cloud y añade el dominio al bosque. Usar un dominio independiente ayuda a reducir la sobrecarga de replicación y los tamaños de las particiones.
• Para aumentar la disponibilidad, despliega al menos dos controladores de dominio distribuidos en varias zonas¹. Si usas varias regiones, te recomendamos que implementes controladores de dominio en cada una de ellas.
• Usa un Google Cloud proyecto independiente con una VPC compartida para implementar controladores de dominio y conceder acceso a este proyecto con el principio de privilegio mínimo. Si generas una contraseña o accedes a la consola en serie de las instancias del controlador de dominio, los miembros no autorizados del proyecto podrían poner en peligro el dominio.
• Plantéate implementar una granja de servidores de AD FS y GCDS en Google Cloud. Con este método, puedes federar Active Directory con Cloud Identity sin depender de la disponibilidad de recursos ni de la conectividad a la red local.

Siguientes pasos

• Más información sobre la federación Google Cloud con Active Directory
• Más información sobre los patrones para usar Active Directory en un entorno híbrido
• Consulta cómo puedes federar Cloud Identity con Entra ID.
• Diseña la jerarquía de recursos de tu Google Cloud zona de aterrizaje.
• Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.