Autenticar usuarios de la plantilla en un entorno híbrido

Last reviewed 2024-06-26 UTC

Este documento es la primera parte de una serie de artículos en la que se explica cómo ampliar tu solución de gestión de identidades a Google Cloud para que tus empleados puedan autenticarse y consumir servicios en un entorno de computación híbrido.

La serie consta de las siguientes partes:

Introducción

Gestionar las cuentas de usuario y controlar el acceso de los empleados a las aplicaciones y los recursos informáticos es una responsabilidad clave de los departamentos de TI de las empresas. Para garantizar la coherencia y la eficiencia administrativa, la mayoría de las empresas consideran que la gestión de identidades es una función central y utilizan un sistema unificado para gestionar las identidades. Lo más habitual es que las empresas utilicen Microsoft Active Directory Domain Services (AD DS) para ello.

Cuando amplías un entorno de TI a Google Cloud como parte de una estrategia híbrida, quieres mantener un único punto donde se gestionen las identidades. Un sistema de gestión de identidades unificado minimiza el esfuerzo administrativo necesario para gestionar las cuentas y el control de acceso. Este sistema también ayuda a garantizar que los usuarios y las aplicaciones puedan autenticarse de forma segura en un entorno híbrido.

En este documento se describen las formas de integrar Google Cloud con tu sistema de gestión de identidades. Este documento te ayudará a elegir el enfoque que mejor se adapte a tus necesidades.

Aunque la mayoría de los temas que se tratan también se aplican a Google Workspace, este documento se centra únicamente en Cloud Identity.

Evaluar los requisitos de la gestión de identidades híbrida

La mejor forma de ampliar tu sistema de gestión de identidades a Google Cloud depende de varios factores:

  • Los grupos de identidades de tu organización
  • Los proveedores de identidades que se usan para proporcionar servicios de autenticación para las identidades de tu personal
  • Los recursos y las aplicaciones a los que quieres que puedan acceder tus usuarios en Google Cloud
  • Tus requisitos de continuidad empresarial

En las siguientes secciones se analiza cada uno de estos factores.

Identidades

El primer factor que debes tener en cuenta al integrar Google Cloud y tu sistema de gestión de identidades es cómo gestionas y distingues los tipos de identidades. La mayoría de las organizaciones usan los siguientes tipos de identidades:

  1. Las identidades de empleados son las que gestionas para los empleados de tu organización. Sirven para iniciar sesión en las estaciones de trabajo, acceder al correo electrónico o utilizar las aplicaciones empresariales.
  2. Las identidades externas son las que gestionas para usuarios que no son empleados, como contratistas o partners, a los que se les debe dar acceso a los recursos empresariales.
  3. Las identidades de invitado son identidades gestionadas por otra parte, como un cliente o un partner, que necesita acceder a recursos corporativos.
  4. Las identidades de clientes son las que gestionas para que los usuarios puedan interactuar con tu sitio web o las aplicaciones dirigidas a los clientes.
  5. Las identidades de cargas de trabajo son las identidades que gestionas para que las aplicaciones puedan interactuar con otras aplicaciones o con la plataforma subyacente.

A menudo, las identidades de los empleados forman un único grupo de identidades, donde cada empleado tiene una sola identidad y todas las identidades se gestionan de la misma forma, con los mismos sistemas. Sin embargo, no tiene por qué ser así. Por ejemplo, como resultado de una fusión o adquisición, puede que tengas varios grupos de identidades de empleados, cada uno de ellos gestionado de forma diferente con sistemas distintos. Técnicamente, esto significa que es posible que tengas que integrar varias fuentes LDAP, bosques de Active Directory o inquilinos de Entra ID con Google Cloud.

Integrar varias piscinas aumenta la complejidad de la integración conGoogle Cloud. Por lo tanto, debes evaluar lo siguiente:

  • ¿Todos los grupos de identidades necesitan acceso a Google Cloudo solo un subconjunto?
  • ¿Todos los grupos de identidades deben tener acceso a la misma organización en Google Cloud o cada uno a una diferente?
  • ¿Hay alguna opción para reducir el número de grupos, por ejemplo, creando relaciones de confianza entre bosques de Active Directory?

Las identidades externas suelen tratarse de forma similar a las identidades de los empleados, con las siguientes excepciones:

  • Es posible que su cuenta solo sea válida durante un tiempo limitado.
  • Es posible que se les concedan menos derechos de forma predeterminada.
  • Puede que los gestione un directorio LDAP independiente, un bosque de Active Directory o Microsoft Entra ID.

A diferencia de las identidades externas, las identidades de invitado no las gestionas tú, sino otra parte. En aplicaciones SaaS como Google Workspace, las identidades de invitado pueden eliminar la necesidad de mantener identidades externas para clientes o partners. Rara vez te encontrarás identidades de invitado en entornos locales.

Este documento se centra en las identidades de empleados y las identidades externas.

Si has usado servicios como Google Ads, es posible que algunos de tus empleados ya tengan una cuenta de Google que no esté conectada a su identidad de empleado, lo que significa que tienen dos identidades. Si es así, te recomendamos que consolides estas identidades.

Proveedores de identidades

El segundo factor que debes tener en cuenta son tus proveedores de identidades. Un proveedor de identidades (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 proveedores de identidades suelen gestionar el ciclo de vida de las identidades. Sin embargo, no tiene por qué ser así, ya que las identidades también se pueden aprovisionar desde un sistema de recursos humanos independiente.

Entre los proveedores de identidades habituales se incluyen los siguientes:

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

En lugar de usar un solo sistema, puede que uses varios para gestionar diferentes grupos de usuarios, para gestionar cuentas externas o para proporcionar diferentes servicios de autenticación a los mismos grupos de usuarios. Estos son algunos ejemplos de situaciones en las que se usan varios proveedores de identidades para gestionar los mismos grupos:

  • Active Directory federado con Entra ID
  • 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 proveedor de identidades en Google Cloud, puedes seguir dos enfoques básicos:

  • Federa tu proveedor de identidades con Cloud Identity: al federar tu proveedor de identidades con Cloud Identity, permites que Google se convierta en un proveedor de identidades adicional que tus usuarios de Workforce puedan usar y en el que puedan confiar las aplicaciones implementadas en Google Cloud . En lugar de mantener las identidades de Google de cada uno de tus usuarios, puedes depender de la relación de federación para mantener las identidades automáticamente. Esta relación también ayuda a asegurar que tu IdP siga siendo la fuente de información veraz.
  • Amplía tu proveedor de identidades a Google Cloud: puedes permitir que las aplicaciones implementadas en Google Cloud reutilicen tu IdP conectándose directamente a él o manteniendo una réplica de tu IdP enGoogle Cloud.

En función de los demás factores de gestión de identidades, es posible que tengas que combinar ambos enfoques para admitir tus casos de uso híbrido.

Recursos

El tercer factor que debes tener en cuenta es a qué Google Cloud recursos quieres dar acceso a los usuarios de tu plantilla. Este factor incluye la propia Google Cloud gestión de identidades y accesos: debes permitir que los equipos responsables gestionen Google Cloud la gestión de identidades y accesos mediante la Google Cloud consola, la CLI de gcloud> o las APIs.

Entre los recursos adicionales se incluyen los siguientes:

Estos recursos se diferencian en si deben, pueden o no pueden usar Google como proveedor de identidades. En las siguientes secciones se analizan estos tres casos.

Recursos que deben usar Google como IdP

Entre los recursos que deben usar Google como IdP se incluyen la Google Cloud consola, la CLI de gcloud, las aplicaciones protegidas con IAP y otras herramientas y servicios de Google. Para conceder acceso a estos recursos a los usuarios de tu plantilla, debes aprovisionar una identidad de Google para cada usuario.

Mantener identidades de Google independientes va en contra de la idea de gestión de identidades unificada. Por lo tanto, si quieres conceder acceso a los usuarios a cualquiera de estos recursos, debes federar tu proveedor de identidades con Google Cloud.

Después de federar tu IdP con Google Cloud, considera la posibilidad de usar Google como IdP para acceder a más recursos, incluidas aplicaciones que puedan usar otros medios para autenticar a los usuarios.

Recursos que pueden usar Google como proveedor de identidades

Entre los recursos que podrían usar Google como proveedor de identidades, pero que no lo hacen actualmente, se incluyen los siguientes:

  • Nuevas aplicaciones dirigidas a los usuarios de la plantilla que tengas previsto implementar en Google Cloud.
  • Aplicaciones actuales dirigidas a usuarios de la plantilla que quieras migrar tal cual o migrar y mejorar a Google Cloud.

Si estas aplicaciones pueden usar Google como proveedor de identidades depende de los protocolos que uses para la autenticación y la autorización.

Protocolos de inicio de sesión único web

Google admite varios protocolos estándar del sector para gestionar la autenticación, la autorización y el inicio de sesión único. Protocolos admitidos:

  • OAuth 2.0, que se aplica a clientes móviles, clientes pesados y otras aplicaciones que no son navegadores.
  • 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 quieras desarrollar, OAuth 2.0 u OIDC deberían ser tu opción preferida. Estos protocolos se han adoptado ampliamente y puedes aprovechar muchas bibliotecas y herramientas que se han probado a fondo. Además, si utilizas estos protocolos, puedes usar Google como proveedor de identidades de forma opcional y, al mismo tiempo, mantener la flexibilidad de cambiar de proveedor de identidades según sea necesario.

Si tienes aplicaciones que usan SAML, OAuth 2.0 u OIDC, deberías poder cambiarlas para que usen Google como proveedor de identidades con pocos o ningún cambio en el código.

LDAP

Uno de los protocolos más versátiles y fiables para la autenticación y la autorización es el protocolo ligero de acceso a directorios (LDAP). Hay varias formas en las que una aplicación puede usar LDAP para la autenticación y la autorización. Los dos casos más habituales son los siguientes:

  1. Usar LDAP para la autenticación y para consultar información de usuarios: en este caso, una aplicación no usa el inicio de sesión único. En su lugar, se muestra al usuario un formulario de inicio de sesión en el que se le pide su nombre de usuario y contraseña. A continuación, se usan las credenciales proporcionadas para intentar realizar una operación bind de LDAP. Si el intento se realiza correctamente, las credenciales se consideran válidas. Además, se puede consultar más información sobre el usuario, como el nombre y la pertenencia a grupos, en el directorio y usarla para autorizar el acceso.

  2. Usar SAML para la autenticación y LDAP para consultar información de usuarios:en este caso, la aplicación autentica al usuario mediante un protocolo de inicio de sesión único. Las aplicaciones suelen usar SAML para este fin. Una vez que se ha autenticado al usuario, la aplicación usa el servidor LDAP para consultar información adicional sobre el usuario, como el nombre y las pertenencias a grupos.

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

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

Kerberos y NTLM

Si tienes previsto migrar cargas de trabajo basadas en Windows a Google Cloud, es posible que algunas de estas aplicaciones dependan de la autenticación integrada de Windows (IWA) en lugar de usar protocolos estándar. IWA es una opción habitual para las aplicaciones basadas en ASP.NET que se ejecutan en Microsoft IIS. La autenticación integrada de Windows es popular porque permite que los usuarios que han iniciado sesión en su estación de trabajo de Windows con credenciales de dominio disfruten de una experiencia de inicio de sesión único fluida.

IWA se basa en NTLM o Kerberos. Para ello, es necesario que la estación de trabajo del usuario y el servidor en el que se ejecuta la aplicación se unan al mismo dominio de Active Directory o a dominios de confianza.

Una de las consecuencias de usar NTLM y Kerberos es que una aplicación que utilice IWA no puede usar Google como proveedor de identidades. 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 ni el servidor se unan al dominio. Por lo tanto, la refactorización puede simplificar la implementación y ayudarte a buscar otras opciones de implementación.

Teniendo en cuenta la experiencia de inicio de sesión único fluida que ofrece IWA, usar OIDC en lugar de IWA puede parecer un paso atrás en cuanto a la experiencia de usuario. Sin embargo, no tiene por qué ser así si te aseguras de que los usuarios puedan iniciar sesión en AD FS o Azure AD sin problemas:

  • Si federas Google Cloud con Active Directory y AD FS, se aplican todos los métodos de autenticación configurados en AD FS. Si configuras AD FS para permitir la autenticación integrada de Windows, los usuarios que hayan iniciado sesión en su estación de trabajo Windows con credenciales de dominio podrán autenticarse sin problemas en cualquier aplicación que use Google como IdP.
  • Si federas Google Cloud con Entra ID, puedes habilitar el inicio de sesión único (SSO) de Azure AD para conseguir el mismo efecto.

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

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

  1. El navegador solicita una página protegida mediante un navegador web.
  2. La aplicación web inicia un inicio de sesión mediante OIDC (flujo de autenticación OIDC). Este flujo redirige el navegador al endpoint de inicio de sesión de Google.
  3. El endpoint de inicio de sesión de Google devuelve la página de inicio de sesión de Google al usuario, donde se le pide que introduzca su dirección de correo electrónico.
  4. El usuario introduce su dirección de correo.
  5. En función de la dirección de correo, el endpoint de inicio de sesión de Google identifica la cuenta de Cloud Identity y reconoce que está configurada para usar el SSO. A continuación, el endpoint de inicio de sesión inicia un inicio de sesión de SAML con AD FS.
  6. AD FS, configurado para usar IWA, solicita 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. Si no se ha almacenado en caché un ticket adecuado, Windows se pone en contacto con el centro de distribución de claves (KDC) de Active Directory y solicita que se emita un ticket de servicio adecuado en función del ticket de concesión de tickets (TGT) que se obtuvo cuando el usuario inició sesión en Windows.
  8. El navegador presenta el ticket recién obtenido a AD FS.
  9. AD FS valida el ticket comprobando su firma criptográfica, extrae la identidad del usuario del ticket y emite un token SAML al endpoint de inicio de sesión de Google.
  10. El endpoint de inicio de sesión de Google usa la información de autenticación del token SAML para completar el inicio de sesión de OIDC y emite tokens de OpenID Connect a la aplicación web.
  11. Cuando se autentica al usuario, se le puede devolver la página protegida.

Autenticación con clave pública SSH

Si tienes previsto ejecutar máquinas virtuales Linux en Google Cloud, es probable que necesites acceso SSH a estas máquinas. El método de autenticación más habitual para SSH es la autenticación de clave pública.

A diferencia de los protocolos de inicio de sesión único que hemos visto antes, la autenticación con clave pública SSH no depende de un proveedor de identidades centralizado para tomar decisiones de autenticación. En su lugar, las decisiones de autenticación se descentralizan: cada máquina gestiona la autenticación en función de un conjunto local de claves públicas autorizadas.

Puedes salvar la distancia entre la autenticación descentralizada con clave pública SSH y la gestión de identidades centralizada mediante OS Login. OS Login vincula el ciclo de vida de las claves SSH al ciclo de vida de las cuentas de usuario de las siguientes formas:

  • Publicar una clave pública SSH cuando se crea un usuario o cuando intenta usar SSH por primera vez.
  • Proporcionar la clave pública del usuario a las máquinas a las que tiene derecho a acceder.
  • Se anula el aprovisionamiento de la clave pública del usuario cuando se revoca el acceso a la cuenta, se inhabilita o se elimina.

Al usar Inicio de sesión del SO, Cloud Identity se convierte en el proveedor de identidades de tus instancias Linux.

Recursos que no pueden usar Google como IdP

Algunos recursos no pueden usar directamente Google como proveedor de identidades. Sin embargo, puedes incluir estos recursos en Google Cloud combinando dos enfoques:

Si un recurso depende de protocolos que no admite el proveedor de identidades de Google, ese recurso no puede usar Google como proveedor de identidades. Entre estos protocolos se incluyen los siguientes:

  • LDAP para la autenticación: aunque puedes usar LDAP seguro para facilitar la consulta de información de usuarios de Cloud Identity a través de LDAP, Cloud Identity no admite el uso de LDAP para la autenticación cuando se federa 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 extender tu Active Directory Google Cloud.

  • WS-Trust y WS-Federation: sobre todo si usas AD FS, es posible que sigas usando WS-Trust o WS-Federation para gestionar la autenticación basada en tokens. A menos que puedas cambiar las aplicaciones afectadas para que usen SAML u OpenID Connect, lo mejor es exponer tu AD FS local Google Cloud y 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 usado AD FS como proveedor de OpenID Connect, es posible que dependas de determinadas reclamaciones específicas de AD FS que Google no admite. Si es así, plantéate exponer tu AD FS local Google Cloud y hacer que las aplicaciones afectadas usen directamente AD FS.

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

  • Máquinas virtuales Windows: si ejecutas cargas de trabajo de Windows enGoogle Cloud, debes poder iniciar sesión en estas VMs a través del protocolo de escritorio remoto (RDP), de una puerta de enlace de escritorio remoto o de otros medios. Si un usuario tiene acceso de escritura al Google Cloud proyecto en el que se creó la VM, Google Cloud le permite crear un usuario y una contraseña, lo que crea una cuenta en la base de datos local del gestor de cuentas de seguridad (SAM) de la VM. Es importante destacar que la cuenta 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 suspendes o eliminas la cuenta de Google del usuario, la cuenta SAM de Windows no se verá afectada y podría seguir proporcionando acceso a la VM.

    Si tienes un número moderado de máquinas virtuales Windows y usuarios que deben poder iniciar sesión en estas máquinas, permitir que los usuarios generen cuentas y contraseñas de usuario de Windows puede ser una opción viable. Sin embargo, cuando se gestionan flotas más grandes de servidores Windows, puede ser mejor extender un Active Directory local Google Cloud y unir los servidores correspondientes al dominio. Los servidores unidos a un dominio también son un requisito si utilizas la autenticación a nivel de red.

Disponibilidad

El último factor que hay que tener en cuenta es la disponibilidad. La capacidad de autenticar usuarios es fundamental para muchas de tus cargas de trabajo, y una interrupción del IdP puede tener consecuencias de gran alcance. El enfoque adecuado para asegurar la disponibilidad depende de cómo tengas previsto usar Google Cloud y de cómo se ajuste a tu estrategia híbrida.

Cargas de trabajo distribuidas

Para aprovechar las funciones únicas que ofrece cada entorno de computación, puedes usar un enfoque multinube híbrido para distribuir las cargas de trabajo en esos entornos. Estos entornos pueden tener dependencias entre sí que sean críticas para la disponibilidad de tus cargas de trabajo. Las dependencias pueden incluir VPN o interconexiones, aplicaciones que se comunican entre sí o sistemas que acceden a datos en diferentes entornos informáticos.

Cuando federes o amplíes tu proveedor de identidades externo a Google Cloud, asegúrate de que la disponibilidad de tu proveedor de identidades externo y de otros sistemas necesarios para la autenticación sea igual o superior a la disponibilidad de otras dependencias críticas. Este requisito implica que es posible que tengas que implementar de forma redundante el IdP externo y sus dependencias y asegurarte de que haya conectividad de red redundante.

Cargas de trabajo redundantes

Si usas Google Cloud para asegurar la continuidad de tu negocio, tus cargas de trabajo en Google Cloud reflejarán algunas de las cargas de trabajo que tengas en tu entorno informático. El objetivo de esta configuración es permitir que un entorno informático asuma el rol del otro entorno si se produce un fallo. Por lo tanto, debes analizar todas las dependencias entre estos entornos.

Al Google Cloud depender de un IdP externo que se ejecute on-premise, creas una dependencia. Esa dependencia podría menoscabar el objetivo de tener unaGoogle Cloud copia independiente de tu entorno de computación.

Intenta replicar tu IdP en Google Cloud para que todas las cargas de trabajo de Google Cloud no se vean afectadas por una interrupción de tu entorno informático local o de la conectividad entre Google Cloud y tu red local.

Siguientes pasos