Autentica usuarios del personal en un entorno híbrido

Last reviewed 2024-06-26 UTC

Este documento es la primera parte de una serie en la que se analiza cómo extender tu solución de administración de identidades a Google Cloud para permitir que tu personal se autentique y consuma servicios en un entorno de procesamiento híbrido.

La serie consta de estas partes:

Introducción

La administración de las cuentas de usuario y el control de acceso de los empleados a las aplicaciones y a los recursos informáticos es una responsabilidad clave de los departamentos de TI de la empresa. Para garantizar la coherencia y la eficiencia administrativa, la mayoría de las empresas consideran la administración de las identidades como una función central y utilizan un sistema unificado para administrarlas. Por lo general, las empresas confían en Microsoft Active Directory Domain Services (AD DS) para este propósito.

Cuando extiendes un panorama de TI a Google Cloud como parte de una estrategia híbrida, lo ideal es mantener un único punto en el que se administran las identidades. Contar con un sistema de administración de identidades unificado minimiza el esfuerzo de la administración de las cuentas y el control del acceso. Este sistema también ayuda a garantizar que los usuarios y las aplicaciones puedan autenticarse de manera segura en un entorno híbrido.

En este documento, se analizan las formas de integrar Google Cloud con tu sistema de administración de identidades. El documento te ayuda a elegir el enfoque que mejor se adapta a tus necesidades.

Aunque la mayor parte de la discusión también se aplica a Google Workspace, el documento se centra únicamente en Cloud Identity.

Evalúa los requisitos para un sistema híbrido de administración de identidades

La mejor manera de extender tu sistema de administración de identidades a Google Cloud depende de varios factores:

  • Los grupos de identidades de la organización
  • Los proveedores de identidades usados a fin de proporcionar servicios de autenticación para tus identidades corporativas
  • Las aplicaciones y los recursos a los que deseas que los usuarios puedan acceder en Google Cloud
  • Tus requisitos de continuidad del negocio

En las secciones siguientes, se analizan cada uno de estos factores.

Identidades

El primer factor que debes considerar cuando integras Google Cloud y tu sistema de administración de identidades es cómo administras los tipos de identidades y cómo los distingues. La mayoría de las organizaciones usan los siguientes tipos de identidades:

  1. Las identidades del personal son las identidades que administras para los empleados de tu organización. Estas identidades se usan a fin de acceder a estaciones de trabajo o al correo electrónico, o para usar aplicaciones corporativas.
  2. Las identidades externas son las identidades que administras para los no empleados, como contratistas o socios, a los que se les debe otorgar el acceso a los recursos corporativos.
  3. Las identidades de invitado son identidades administradas por una parte diferente, como un cliente o socio que necesita acceso a los recursos corporativos.
  4. Las identidades de cliente son las identidades que administras para los usuarios, de manera que interactúen con tu sitio web o las aplicaciones orientadas al cliente.
  5. Las identidades del personal son las identidades que administras para permitir que las aplicaciones interactúen con otras aplicaciones o la plataforma subyacente.

A menudo, las identidades del personal forman un único conjunto de identidades, en el que cada empleado tiene una sola identidad y todas las identidades se administran de igual manera, mediante los mismos sistemas. Sin embargo, este no tiene por qué ser el caso. Por ejemplo, como resultado de una fusión o una adquisición, es posible que tengas varios grupos de identidades del personal, cada una administrada de manera distinta con sistemas diferentes. Técnicamente, esto significa que tal vez debas integrar varias fuentes LDAP, bosques de Active Directory o usuarios de Azure AD con Google Cloud.

La integración de varios grupos aumenta la complejidad de la integración con Google Cloud. Por lo tanto, debes evaluar las siguientes cuestiones:

  • ¿Todos los grupos de identidades necesitan acceso a Google Cloud o solo un subconjunto selecto?
  • ¿Todos los grupos de identidades deben tener acceso a la misma organización en Google Cloud o cada uno a una diferente?
  • ¿Existen opciones para reducir la cantidad de grupos, por ejemplo, mediante la creación de varios bosques de Active Directory con relación de confianza entre sí?

Las identidades externas a menudo se tratan de manera similar a las identidades del personal, con las siguientes excepciones:

  • Su cuenta puede ser válida solo por un tiempo limitado.
  • Se les puede otorgar menos derechos de forma predeterminada.
  • Pueden ser administradas por un directorio de LDAP, un bosque de Active Directory o una instancia de Azure AD independientes.

A diferencia de las identidades externas, no administras las identidades de invitados, sino que lo realizan terceros. En aplicaciones de SaaS, como Google Workspace, las identidades de invitado pueden quitar la necesidad de mantener identidades externas para los clientes o socios. Rara vez te encuentras con identidades de invitado en entornos locales.

Este documento se centra en las identidades del personal y las identidades externas.

Si has utilizado servicios como Google Ads, es posible que algunos de tus empleados ya tengan una Cuenta de Google que no esté conectada a su identidad del personal, lo que significa que tienen dos identidades. Si es así, considera consolidar estas identidades.

Proveedores de identidades

Los proveedores de identidades son el segundo factor que se debe considerar. Un proveedor de identidad (IdP) es un sistema que proporciona servicios de autenticación para tus cargas de trabajo y, en última instancia, decide si autenticar a un usuario.

Además de proporcionar servicios de autenticación, los IdP a menudo se encargan de administrar el ciclo de vida de las identidades. Sin embargo, este no tiene que ser el caso, ya que las identidades también se pueden aprovisionar desde un sistema de recursos humanos separado.

Los proveedores de identidades comunes incluyen lo siguiente:

  • Active Directory (AD DS)
  • Azure Active Directory (Azure AD)
  • Proveedores de IDaaS, como ForgeRock, Okta, o Ping Identity
  • Otros directorios de LDAP, incluido Active Directory Lightweight Directory Services (AD LDS)

En lugar de usar solo un sistema, podrías emplear varios sistemas para administrar distintos grupos de usuarios, manejar cuentas externas o proporcionar diferentes servicios de autenticación a los mismos grupos de usuarios. Los siguientes son ejemplos en los que se utilizan múltiples IdP para administrar los mismos grupos:

  • Active Directory federado con Azure AD
  • Active Directory federado con un proveedor de IDaaS como ForgeRock, Okta o Ping Identity
  • Active Directory con réplicas de AD LDS

Para usar tu IdP en Google Cloud, puedes seguir dos enfoques básicos:

  • Federa tu proveedor de identidad con Cloud Identity: La federación con Cloud Identity permite que Google se convierta en un IdP adicional que tus usuarios del personal pueden usar y en el que pueden confiar las aplicaciones implementadas en Google Cloud. En lugar de mantener las identidades de Google para cada uno de tus usuarios, puedes depender de la relación de la federación a fin de mantener las identidades de manera automática. Esta relación también ayuda a garantizar que tu IdP siga siendo la fuente de veracidad.
  • Extiende tu proveedor de identidad a Google Cloud: Puedes permitir que las aplicaciones implementadas en Google Cloud vuelvan a usar a tu IdP; para ello, conéctate a este directamente o mantén una réplica de tu IdP en Google Cloud.

En función de los demás factores de administración de identidades, es posible que debas combinar ambos enfoques para respaldar tus entornos de uso híbrido.

Recursos

El tercer factor que debes analizar es a qué recursos de Google Cloud planeas otorgarles acceso a los usuarios del personal. Este factor incluye a Google Cloud en sí; debes permitir que los equipos responsables administren Google Cloud mediante la consola de Google Cloud, la CLI de gcloud o las API.

Los recursos adicionales podrían incluir los siguientes:

Estos recursos difieren en si deben, pueden o no pueden usar Google como proveedor de identidad. Las siguientes secciones analizan estos tres casos.

Recursos que deben usar Google como IdP

Los recursos que deben usar Google como IdP incluyen la consola de Google Cloud, la CLI de gcloud, las aplicaciones protegidas con IAP y otras herramientas y servicios de Google. Para otorgar a tus usuarios del personal acceso a estos recursos, debes aprovisionar una identidad de Google a cada usuario.

Mantener identidades de Google separadas va en contra de la idea de una administración de identidades unificada. Por lo tanto, otorgar a los usuarios acceso a cualquiera de estos recursos implica que debes federar tu IdP con Google Cloud.

Después de federar tu IdP con Google Cloud, considera usar Google como IdP para contar con más recursos, incluidas las aplicaciones que podrían usar otros medios para autenticar usuarios.

Recursos que pueden usar Google como IdP

Los recursos que pueden usar Google como IdP, pero que por el momento no lo hacen, son los siguientes:

  • Aplicaciones nuevas, dirigidas a usuarios del personal, que planeas implementar en Google Cloud.
  • Aplicaciones existentes, dirigidas a usuarios del personal, que planeas someter a una migración lift-and-shift o mejorar y mover a Google Cloud.

La posibilidad de que estas aplicaciones usen Google como IdP depende de los protocolos que emplees para la autenticación y la autorización.

Protocolos web de inicio de sesión único

Google admite varios protocolos estándar de la industria para el manejo de la autenticación, la autorización y el inicio de sesión único. Los protocolos admitidos son los siguientes:

  • OAuth 2.0, que se aplica a clientes móviles, clientes pesados y otras aplicaciones que no son de navegador
  • OpenID Connect 1.0 (OIDC), que se aplica a las aplicaciones basadas en navegador
  • SAML 2.0, que se aplica a la integración de aplicaciones de terceros

Para las aplicaciones que planeas desarrollar, OAuth 2.0 o también OIDC deben ser tu opción preferida. Estos protocolos son de amplia adopción y puedes aprovechar muchas bibliotecas y herramientas bien probadas. Además, confiar en estos protocolos implica que, de manera opcional, puedes usar Google como IdP mientras conservas la flexibilidad de cambiar de proveedor de identidad según sea necesario.

Si tienes aplicaciones que utilizan OAuth 2.0, OIDC o SAML, debería ser posible cambiarlas a Google como proveedor de identidad con pocos o ningún cambio de código.

LDAP

Lightweight Directory Access Protocol (LDAP) es uno de los protocolos más versátiles y confiables para la autenticación y autorización. Hay varias formas en que una aplicación puede usar LDAP para la autenticación y autorización. Los dos casos más comunes son los siguientes:

  1. Uso de LDAP para la autenticación y la consulta de información del usuario: En este caso, una aplicación no usa el inicio de sesión único. En su lugar, le muestra al usuario un formulario de acceso en el que se solicita el nombre de usuario y la contraseña. Luego, usa las credenciales proporcionadas para intentar realizar una operación bind de LDAP. Si tiene éxito, las credenciales se considerarán válidas. Y en el directorio se puede consultar información adicional sobre el usuario, como el nombre y la membresía, y utilizarla para autorizar el acceso.

  2. Uso de SAML en la autenticación y LDAP en la consulta de información del usuario: En este caso, la aplicación autentica al usuario con un protocolo de inicio de sesión único; las aplicaciones a menudo usan SAML para este propósito. Una vez autenticado el usuario, la aplicación utiliza el servidor de LDAP para consultar información adicional sobre el usuario, como el nombre y las membresías del grupo.

La diferencia fundamental entre los dos casos es que el primero requiere que tanto la aplicación como el servidor de LDAP tengan acceso a la contraseña del usuario para verificar las credenciales. En el segundo, la aplicación y el servidor no requieren acceso a la contraseña del usuario; la aplicación puede realizar sus consultas de LDAP mediante un usuario de servicio dedicado.

Con LDAP seguro, puedes acceder a la información de usuarios y grupos en Cloud Identity a través del protocolo LDAP. Si Google es tu IdP principal, LDAP seguro te permite admitir ambos casos. Sin embargo, si integras Cloud Identity a un IdP externo, Cloud Identity no conserva una copia de las contraseñas de los usuarios. Como resultado, solo el segundo caso se puede habilitar con LDAP seguro.

Kerberos y NTLM

Si planeas migrar cargas de trabajo basadas en Windows a Google Cloud, algunas de estas aplicaciones podrían depender de la autenticación integrada de Windows (IWA) en lugar de usar protocolos estándar. IWA es una opción común para aplicaciones basadas en ASP.NET que se ejecutan en Microsoft IIS. IWA es popular porque brinda una experiencia de inicio de sesión único sin problemas para los usuarios que accedieron a su estación de trabajo de Windows con credenciales de dominio.

IWA se basa en NTLM o Kerberos. Requiere la estación de trabajo del usuario y el servidor en el que se ejecuta la aplicación a fin de unirse al mismo dominio de Active Directory o a dominios de confianza.

Una consecuencia de depender de NTLM y Kerberos es que una aplicación que use IWA no podrá usar Google como IdP. Sin embargo, es posible que aún puedas refactorizar la aplicación para usar OIDC. OIDC no requiere que la estación de trabajo del usuario o el servidor se unan al dominio. Por lo tanto, la refactorización podría simplificar la implementación y ayudarte a buscar opciones de implementación alternativas.

Teniendo en cuenta la experiencia de inicio de sesión único que proporciona IWA, el uso de OIDC en lugar de IWA puede parecer un retroceso en términos de experiencia del usuario. Sin embargo, esto no tiene por qué ser el caso si te aseguras de que los usuarios puedan iniciar sesión sin problemas en AD FS o Azure AD de la siguiente manera:

  • Si federas Google Cloud con Active Directory y AD FS, se aplicarán los métodos de autenticación configurados en AD FS. Si configuras AD FS para admitir IWA, los usuarios que han accedido a su estación de trabajo de Windows con credenciales de dominio pueden autenticarse sin problemas en cualquier aplicación que use Google como IdP.
  • Si federas Google Cloud con Azure AD, puedes habilitar Azure AD Seamless SSO para el mismo fin.

En el siguiente diagrama, se muestra un ejemplo simplificado de cómo puedes usar Cloud Identity, IWA y AD FS para implementar el inicio de sesión único sin problemas en una aplicación web:

Cómo usar Cloud Identity, IWA y AD FS para implementar el inicio de sesión único sin problemas en una aplicación web

  1. El navegador solicita una página protegida mediante un navegador web.
  2. La aplicación web inicia un acceso a través de OIDC (flujo de autenticación de OIDC). Este flujo redirecciona el navegador al extremo de acceso de Google.
  3. Este extremo muestra la página de acceso de Google al usuario y le solicita la dirección de correo electrónico.
  4. El usuario ingresa su dirección de correo electrónico.
  5. Según la dirección de correo electrónico, el extremo de acceso con Google identifica la cuenta de Cloud Identity y reconoce que está configurada para usar SSO. Luego, el extremo de acceso inicia un acceso de SAML con AD FS.
  6. AD FS, que se configuró para usar IWA, pide al navegador que presente un ticket de Kerberos, lo que hace que el navegador solicite al sistema operativo Windows subyacente que obtenga un ticket adecuado.
  7. A menos que se haya almacenado uno en caché, Windows se comunica con el centro de distribución de claves de Active Directory (KDC) y requiere que se emita un vale de servicio adecuado en función del vale de concesión de vales (TGT) que se obtuvo cuando el usuario accedió a Windows.
  8. El navegador presenta el ticket recién obtenido a AD FS.
  9. AD FS valida el ticket mediante la comprobación de la firma criptográfica, extrae la identidad del usuario del ticket y emite un token de SAML al extremo de acceso de Google.
  10. Con la información de autenticación del token de SAML, el extremo de acceso de Google completa el acceso a través de OIDC y emite tokens de OpenID Connect a la aplicación web.
  11. Una vez autenticado el usuario, la página protegida se puede mostrar al usuario.

Autenticación de clave pública SSH

Cuando planeas ejecutar máquinas virtuales (VM) de Linux en Google Cloud, es probable que necesites acceso SSH a estas máquinas. El método de autenticación más común para SSH es la autenticación de clave pública.

A diferencia de los protocolos de inicio de sesión único mencionados anteriormente, la autenticación de clave pública SSH no se basa en un IdP centralizado para tomar decisiones de autenticación. En cambio, las decisiones de autenticación se descentralizan; cada máquina maneja la autenticación en función de un conjunto local de claves públicas autorizadas.

Puedes cerrar la brecha entre la autenticación de clave pública SSH descentralizada y la administración de identidad centralizada mediante el acceso a SO. El Acceso al SO vincula el ciclo de vida de las claves SSH con el ciclo de vida de las cuentas de usuario de la siguiente manera:

  • Publicar una clave pública SSH cuando se crea un usuario o cuando se intenta usar SSH por primera vez.
  • Aprovisionamiento de la clave pública del usuario a las máquinas a las que un usuario tiene acceso
  • Anulación del aprovisionamiento de la clave pública del usuario cuando la cuenta se revoca, inhabilita o quita

El uso del Acceso al SO hace que Cloud Identity sea el IdP para tus instancias de Linux.

Recursos que no pueden usar Google como IdP

Algunos recursos no pueden usar Google directamente como IdP. Sin embargo, puedes adaptar estos recursos en Google Cloud si combinas dos enfoques:

Si un recurso se basa en protocolos que el IdP de Google no admite, ese recurso no puede usar Google como IdP. Estos protocolos son los siguientes:

  • LDAP para autenticación: Aunque puedes usar LDAP seguro a fin de facilitar la consulta de información de usuario desde Cloud Identity a través de LDAP, Cloud Identity no admite el uso de LDAP para la autenticación cuando se federó con un IdP externo.

    Para permitir que las aplicaciones usen LDAP para la autenticación, puedes exponer o replicar un directorio LDAP local, o bien puedes extender tu Active Directory a Google Cloud.

  • WS-Trust y WS-Federation: Especialmente si usas AD FS, todavía puedes confiar en WS-Trust o WS-Federation para manejar la autenticación basada en token. A menos que puedas cambiar las aplicaciones afectadas para usar OpenID Connect o SAML, es mejor exponer tu AD FS local a Google Cloud y hacer que las aplicaciones usen AD FS directamente.

  • OpenID Connect con reclamaciones específicas de AD FS: AD FS y Google admiten OpenID Connect. Si has estado usando AD FS como proveedor de OpenID Connect, puedes confiar en ciertas reclamaciones específicas de AD FS que Google no admite. Si este es el caso, considera exponer tu AD FS local a Google Cloud y hacer que las aplicaciones afectadas usen directamente AD FS.

  • Kerberos y NTLM: Si algunas de tus aplicaciones usan Kerberos o NTLM para la autenticación, es posible que puedas modificarlas a fin de usar OpenID Connect o SAML en su lugar. Si esto no es posible, puedes implementar estas aplicaciones en servidores de Windows unidos al dominio y exponer o replicar tu Active Directory local a Google Cloud.

  • Máquinas virtuales de Windows: Si ejecutas cargas de trabajo de Windows en Google Cloud, debes poder acceder a estas VM mediante el protocolo de escritorio remoto (RDP), a través de una puerta de enlace de escritorio remoto o por otros medios. Si un usuario tiene acceso de escritura al proyecto de Google Cloud en el que se creó la VM, Google Cloud le permite crear un usuario y una contraseña. De esta forma, se crea una cuenta en la base de datos del administrador de cuentas de seguridad (SAM) local de la VM. De manera crucial, la cuenta del SAM de Windows resultante no está conectada a la Cuenta de Google del usuario y no está sujeta al mismo ciclo de vida de la cuenta. Si suspende o borra la Cuenta de Google del usuario, la cuenta del SAM de Windows no se ve afectada y puede continuar brindando acceso a la VM.

    Si tienes un número moderado de VM de Windows y usuarios que deben poder acceder a estas máquinas, entonces permitir que los usuarios generen cuentas de usuario y contraseñas de Windows puede ser un enfoque viable. Sin embargo, cuando se administran grandes flotas de servidores de Windows, puede ser mejor extender un Active Directory local a Google Cloud y unir los servidores correspondientes a los dominios. Los servidores unidos al dominio también son un requisito si confías en la autenticación de nivel de red.

Disponibilidad

La disponibilidad es el último factor para considerar. La capacidad de autenticar a los usuarios probablemente sea crítica para muchas de tus cargas de trabajo, y una interrupción de IdP puede tener consecuencias de gran alcance. El enfoque correcto para garantizar la disponibilidad adecuada depende de cómo pretendes usar Google Cloud y de cómo se adapta a tu estrategia híbrida.

Cargas de trabajo distribuidas

Para capitalizar las capacidades únicas de cada entorno informático, puedes usar un enfoque híbrido a fin de distribuir las cargas de trabajo en esos entornos. Estos entornos pueden tener dependencias entre sí que son fundamentales para la disponibilidad de tus cargas de trabajo. Las dependencias pueden incluir interconexiones o túneles de VPN, aplicaciones que se comunican entre sí, o sistemas que acceden a datos a través de entornos de procesamiento.

Cuando federes o extiendas tu IdP externo a Google Cloud, asegúrate de que la disponibilidad de tu IdP externo y de otros sistemas necesarios para la autenticación alcance o supere la disponibilidad de otras dependencias críticas. Este requisito implica que podrías necesitar implementar de manera redundante el IdP externo y sus dependencias además de garantizar una conectividad de red redundante.

Cargas de trabajo redundantes

Si usas Google Cloud para garantizar la continuidad empresarial, tus cargas de trabajo en Google Cloud reflejarán algunas de las cargas de trabajo que tienes en tu entorno de procesamiento. El propósito de esta configuración es permitir que un entorno de procesamiento asuma la función del otro entorno si se produce una falla. Por lo tanto, debes considerar cada dependencia entre estos entornos.

Creas una dependencia cuando haces que Google Cloud se base en un IdP externo que se ejecuta de forma local. Esa dependencia podría comprometer la intención de que Google Cloud sea una copia independiente de tu entorno de procesamiento.

Intenta replicar tu IdP en Google Cloud de modo que todas las cargas de trabajo que se encuentren allí no se vean afectadas por una interrupción del entorno de procesamiento local o una interrupción de conectividad entre Google Cloud y tu red local.

¿Qué sigue?