Este artículo es la segunda parte de una serie de varias partes en la que se analiza cómo extender una solución de administración de identidades a Google Cloud para permitir que los usuarios del personal se autentiquen y consuman servicios en un entorno de computación híbrido.
La serie consiste en los siguientes artículos:
- Autentica usuarios del personal en un entorno híbrido
- Patrones para autenticar usuarios del personal en un entorno híbrido (este artículo)
Introducción
Si extiendes tu panorama de TI a Google Cloud como parte de una estrategia híbrida, te recomendamos que adoptes un enfoque coherente para administrar las identidades en todos los entornos. Durante los procesos de diseño y adaptación de tu arquitectura para cumplir con estas restricciones y requisitos, puedes emplear algunos patrones comunes. Estos patrones se dividen en dos categorías:
- Patrones para federar un proveedor de identidad externo (IdP) con GCP. El objetivo de estos patrones es permitir que Google se convierta en un IdP para tus usuarios del personal, de modo que las identidades de Google se mantengan automáticamente y el IdP siga siendo la fuente de verdad.
- Patrones para extender un IdP a Google Cloud. Con estos patrones, permites que las aplicaciones implementadas en Google Cloud reutilicen el IdP, ya sea conectándose a él directamente o manteniendo una réplica de este en Google Cloud.
Patrones para federar un IdP externo con Google Cloud
Para poder acceder a la consola de Google Cloud, Google Cloud CLI o a cualquier otro recurso que use Google como IdP, los usuarios del personal deben tener una identidad de Google. Mantener las identidades de Google para cada empleado sería engorroso cuando todos los empleados ya tienen una cuenta en un IdP. Si se federan las identidades de los usuarios entre el IdP y Google Cloud, puedes automatizar el mantenimiento de las Cuentas de Google y vincular su ciclo de vida con las cuentas existentes. La federación ayuda a garantizar lo siguiente:
- Tu IdP sigue siendo la única fuente de verdad para administrar identidades.
- Se crea automáticamente una Cuenta de Google para todas las cuentas de usuario que se encuentran bajo la administración de tu IdP (o para un subconjunto seleccionado de esas cuentas).
- Si se inhabilita o se borra una cuenta en tu IdP, la Cuenta de Google correspondiente queda suspendida o se borra.
- Para evitar que se copien las contraseñas o las otras credenciales, el acto de autenticar a un usuario se delega a tu IdP.
Federación de Active Directory con Cloud Identity mediante GCDS 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):
- Google Cloud Directory Sync es una herramienta gratuita que proporciona Google para implementar el proceso de sincronización. Cloud Directory Sync se comunica con Google Identity Platform a través de una capa de conexión segura (SSL) y, por lo general, se ejecuta en el entorno de computación existente.
- Microsoft proporciona AD FS como parte de Windows Server. Con AD FS, puedes usar Active Directory para la autenticación federada. En general, AD FS se ejecuta dentro del entorno de computación existente.
Para obtener información más detallada sobre este enfoque, consulta Federa GCP con Active Directory.
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.
Experiencia del usuario
- Cuando solicitas el recurso protegido, se te redirecciona a la pantalla de inicio de sesión de Google, que te solicita la dirección de correo electrónico.
- Si se sabe que la dirección de correo electrónico está asociada con una cuenta que se ha sincronizado desde Active Directory, se te redirecciona a AD FS.
- Según la configuración de AD FS, es posible que veas una pantalla de inicio de sesión que solicite tu nombre de usuario y contraseña de Active Directory. O bien AD FS podría intentar acceder automáticamente en función de tu acceso a Windows (IWA).
- Cuando AD FS te haya autenticado, serás redireccionado al recurso protegido.
Ventajas
- El enfoque permite usar una experiencia de inicio de sesión único en aplicaciones locales y recursos en Google Cloud.
- 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.
- Debido a que la API de Cloud Identity es de acceso público, no es necesario configurar la conectividad híbrida entre la red local y Google Cloud.
Recomendaciones
- Active Directory y Cloud Identity usan una estructura lógica diferente. Asegúrate de comprender las diferencias y evaluar la forma de asignar dominios, identidades y grupos que se adapte mejor a tu situación. Consulta nuestra guía de federación de Google Cloud con Active Directory para obtener información más detallada.
- 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 los recursos en Google Cloud.
- Implementa y expón AD FS para que los usuarios del personal puedan acceder a él, pero no lo expongas más de lo necesario. Aunque los usuarios del personal deben poder acceder a AD FS, no es necesario que AD FS pueda acceder desde Google o 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 automáticamente 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 usar Google Cloud como una copia independiente de la implementación. En este caso, considera implementar réplicas de todos los sistemas relevantes en Google Cloud:
- Replica Active Directory en Google Cloud e implementa 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 a fin de usar los servidores de AD FS implementados en Google Cloud para el inicio de sesión único.
Federa Azure AD con Cloud Identity
Si eres cliente de Microsoft Office 365 o Azure, es posible que hayas conectado la instancia de Active Directory local a Azure AD. Si todas las cuentas de usuario que potencialmente necesitan acceso a Google Cloud ya se están sincronizando con Azure AD, puedes reutilizar esta integración si federas Cloud Identity con Azure AD, como se muestra en el siguiente diagrama.
Para obtener información más detallada sobre este enfoque, consulta Federa GCP con Azure Active Directory.
Experiencia del usuario
- Cuando solicitas el recurso protegido, se te redirecciona a la pantalla de inicio de sesión de Google, que te solicita la dirección de correo electrónico.
- Si la dirección de correo electrónico está asociada con una cuenta que se sincronizó desde Azure AD, se te redirecciona a Azure AD.
- Según cómo se conecte tu Active Directory local a Azure AD, es posible que Azure AD te solicite un nombre de usuario y una contraseña. Como alternativa, es posible que te redireccione a un AD FS local.
- Después de autenticarte con éxito con Azure AD, se te redirecciona al recurso protegido.
Ventajas
- No es necesario instalar ningún software local adicional.
- Mediante este enfoque, se habilita una experiencia de inicio de sesión único en Office 365, Azure y los recursos de Google Cloud.
- Si configuraste Azure AD para que requiera autenticación de varios factores (MFA), la MFA se aplica automáticamente a Google Cloud.
- Si Active Directory local usa varios dominios o bosques y tienes una configuración personalizada de Azure AD Connect para asignar esta estructura a una instancia de Azure AD, puedes aprovechar este trabajo de integración.
- No es necesario que sincronices contraseñas ni otras credenciales con Google.
- Debido a que la API de Cloud Identity es de acceso público, no es necesario configurar la conectividad híbrida entre la red local y Google Cloud, o entre Azure y Google Cloud.
- Puedes mostrar la consola de Google Cloud como un mosaico en el portal de Office 365.
Prácticas recomendadas
- Azure AD y Cloud Identity usan una estructura lógica diferente, por lo que es importante que comprendas las diferencias. Evalúa qué forma de asignar dominios, identidades y grupos se adapta mejor a tu situación. Para obtener información más detallada, consulta Federa 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énes tienen acceso a los recursos en Google Cloud.
- Si usas Google Cloud a fin de garantizar la continuidad del negocio, depender de Azure AD para la autenticación podría socavar la intención de usar Google Cloud como una copia independiente de la implementación.
Patrones para extender un IdP externo a Google Cloud
Algunas de las aplicaciones que planeas implementar en Google Cloud pueden requerir el uso de protocolos de autenticación que no ofrece Cloud Identity. Para admitir estas cargas de trabajo, debes permitir que estas aplicaciones usen el IdP desde Google Cloud.
En las siguientes secciones, se describen patrones comunes para permitir que las cargas de trabajo implementadas en Google Cloud usen el IdP.
Expón una instancia local de AD FS a Google Cloud
Si una aplicación requiere el uso de WS-Trust o WS-Federation, o se basa en características o reclamaciones específicas de AD FS cuando se usa OpenID Connect, puedes permitir que la aplicación use AD FS directamente para la autenticación.
Mediante AD FS, una aplicación puede autenticar a un usuario. Sin embargo, debido a que la autenticación no se basa en una identidad de Google, la aplicación no podrá realizar ninguna llamada a la API autenticada con credenciales de usuario. En cambio, cualquier llamada a las API de Google Cloud debe autenticarse mediante una cuenta de servicio.
Experiencia del usuario
- Cuando solicitas el recurso protegido, se te redirecciona a la pantalla de inicio de sesión de ADFS, que solicita tu dirección de correo electrónico. Si AD FS no se expone públicamente a través de Internet, el acceso a AD FS puede requerir que estés conectado a la red de tu empresa o a una VPN corporativa.
- Según la configuración de AD FS, es posible que veas una pantalla de inicio de sesión que solicite tu nombre de usuario y contraseña de Active Directory. O bien AD FS podría intentar acceder automáticamente en función de tu acceso a Windows.
- Cuando AD FS te haya autenticado, serás redireccionado al recurso protegido.
Ventajas
- Puedes usar protocolos de autenticación que no son compatibles con Cloud Identity, incluidos WS-Trust y WS-Federation.
- Si la aplicación se desarrolló y probó con AD FS, puedes evitar los posibles riesgos de cambiar la aplicación para que use Cloud Identity.
- No es necesario configurar la conectividad híbrida entre la red local y Google Cloud.
Prácticas recomendadas
- Implementa y expón AD FS para que los usuarios del personal puedan acceder a él, pero no lo expongas más de lo necesario. Aunque los usuarios del personal deben poder acceder a AD FS, no es necesario que AD FS pueda acceder desde Google o cualquier aplicación implementada en Google Cloud.
- Si AD FS no está disponible, es posible que los usuarios ya no puedan usar la aplicación. Asegúrate de que AD FS y los controladores de dominio que usa estén implementados y dimensionados para cumplir con sus objetivos de disponibilidad.
- Considera refactorizar las aplicaciones que dependen de WS-Trust y WS-Federation para que usen SAML, o bien OpenID Connect en su lugar.
- Si la aplicación depende de la exposición de la información del grupo como reclamos en
IdTokensemitidos por AD FS, considera recuperar la información del grupo de otra fuente, como la API de directorio. Consultar la API de directorio es una operación con privilegios que requiere el uso de una cuenta de servicio habilitada para la delegación de todo el dominio de Google Workspace.
Expón un directorio LDAP local a Google Cloud
Algunas de las aplicaciones pueden requerir que los usuarios proporcionen su nombre de usuario y contraseña, y usen estas credenciales para intentar una operación de enlace LDAP. Si no puedes modificar estas aplicaciones para que la autenticación se haga por otros medios (como SAML), puedes otorgarles acceso a un directorio LDAP local.
Ventajas
- No es necesario que cambies tu aplicación.
Recomendaciones
- Usa Cloud VPN o Cloud Interconnect para establecer una conectividad híbrida entre Google Cloud y la red local, de modo que no tengas que exponer el directorio LDAP en Internet.
- Verifica que la latencia ingresada cuando se consulta un directorio LDAP local no afecte negativamente la experiencia del usuario.
- Asegúrate de que la comunicación entre la aplicación y el directorio LDAP esté encriptada. Puedes lograr esta encriptación mediante Cloud VPN o Cloud Interconnect con LDAP/S.
- Si el directorio LDAP o la conectividad privada entre Google Cloud y la red local no están disponibles, es posible que los usuarios ya no puedan usar aplicaciones basadas en LDAP. Por lo tanto, asegúrate de que los servidores correspondientes estén implementados y dimensionados para cumplir con los objetivos de disponibilidad, y considera usar interconexiones o túneles VPN redundantes.
- Si usas Google Cloud para garantizar la continuidad del negocio, depender de un directorio LDAP local podría socavar la intención de usar Google Cloud como una copia independiente de la implementación. En este caso, considera replicar el directorio LDAP en Google Cloud.
- Si usas Active Directory, considera ejecutar una réplica en Google Cloud, en especial si planeas unir los dominios de las máquinas con Windows que se ejecutan en Google Cloud con Active Directory.
Replica un directorio LDAP local en Google Cloud
Replicar un directorio LDAP local en Google Cloud es similar al patrón que se presenta en Expón un directorio LDAP local a Google Cloud. En el caso de las aplicaciones que usan LDAP para verificar nombres de usuario y contraseñas, la intención de este enfoque es poder ejecutar esas aplicaciones en Google Cloud. En lugar de permitir que dichas aplicaciones consulten el 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 las situaciones híbridas de continuidad empresarial.
Recomendaciones
- Usa Cloud VPN o Cloud Interconnect para establecer una conectividad híbrida entre Google Cloud y la red local, de modo que no tengas que exponer el directorio LDAP en Internet.
- Asegúrate de que la replicación del directorio LDAP local se realice a través de un canal seguro.
- Implementa varias réplicas de directorio LDAP en diversas zonas o regiones para cumplir con tus objetivos de disponibilidad. Puedes usar un balanceador de cargas interno para distribuir conexiones LDAP entre varias réplicas implementadas en la misma región.
- Usa un proyecto de Google Cloud independiente con una VPC compartida para implementar réplicas de LDAP y otorgar acceso a este proyecto con menos privilegios.
Extiende una instancia local de Active Directory a Google Cloud
Algunas de las cargas de trabajo que planeas implementar en Google Cloud pueden depender de Active Directory Domain Services, por ejemplo:
- Máquinas de Windows que necesitan 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 estas cargas de trabajo, puedes extender tu bosque local de Active Directory a Google Cloud. Por ejemplo, implementa un bosque de recursos en Google Cloud y conéctalo al bosque local de Active Directory, como se muestra en el siguiente diagrama.
Para obtener más detalles 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 Active Directory al máximo, incluida la posibilidad de unir máquinas de Windows al dominio de Active Directory.
- La disponibilidad de las aplicaciones basadas en Active Directory que se ejecutan en Google Cloud no depende de la disponibilidad de los recursos locales o de la conectividad a la red local. El patrón es adecuado para las situaciones híbridas de continuidad empresarial.
Recomendaciones
- Usa Cloud VPN o Cloud Interconnect para establecer una conectividad híbrida entre Google Cloud y la red local.
- A fin de minimizar la comunicación entre Google Cloud y la red local, crea un sitio independiente de Active Directory para las implementaciones de Google Cloud. Puedes usar un solo sitio por VPC compartida o, para minimizar la comunicación interregional, un sitio por VPC compartida y región.
- Crea un dominio independiente de Active Directory dedicado a los recursos implementados en Google Cloud y agrega el dominio al bosque existente. Usar un dominio independiente ayuda a reducir la sobrecarga de replicación y los tamaños de partición.
- Para aumentar la disponibilidad, implementa al menos dos controladores de dominio distribuidos en distintas zonas. Si usas varias regiones, considera implementar controladores de dominio en cada región.
- Usa un proyecto de Google Cloud independiente con una VPC compartida para implementar controladores de dominio y otorgar acceso a este proyecto con menos privilegios. De lo contrario, corres el riesgo de que un miembro del proyecto con malas intenciones genere una contraseña o acceda a la consola en serie de las instancias de controlador de dominio con el propósito de vulnerar el dominio.
- Considera implementar una granja de servidores de AD FS y GCDS en Google Cloud. Este enfoque te permite federar Active Directory con Cloud Identity sin depender de la disponibilidad de recursos ni de la conectividad a la red local.
¿Qué sigue?
- Obtén más información sobre cómo federar Google Cloud con Active Directory.
- Obtén más información sobre los patrones para usar Active Directory en un entorno híbrido.
- Descubre cómo puedes federar Cloud Identity con Azure AD.
- Diseña la jerarquía de recursos para la zona de destino de Google Cloud.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.