Prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo

En este documento, se presentan prácticas recomendadas y orientación que te ayudarán a configurar la federación de manera coherente y segura. La orientación se basa en las prácticas recomendadas para usar Cloud Identity o G Suite con Google Cloud.

Todos los servicios de Google, incluidos Google Cloud, Google Marketing Platform y Google Ads, se basan en el Acceso con Google para autenticar a los usuarios. En lugar de crear y mantener de forma manual cuentas de usuario en Cloud Identity o G Suite para cada empleado, puedes federar Cloud Identity o G Suite con un proveedor de identidad externo (IdP), como Active Directory o Azure Active Directory. La configuración de la federación, por lo general, implica lo siguiente:

  • Aprovisionar de forma automática cuentas de usuario relevantes de una fuente autorizada externa a Cloud Identity o G Suite
  • Permitir que los usuarios usen un IdP externo para autenticarse en los servicios de Google

Asigna identidades

La identidad de una cuenta de usuario administrada por Cloud Identity o G Suite se define por su dirección de correo electrónico principal. La dirección de correo electrónico principal aparece como correo electrónico de la Cuenta de Google en la página de la Cuenta de Google. Para que se considere válida, la dirección de correo electrónico principal debe usar uno de los dominios que agregaste a la cuenta de Cloud Identity o G Suite.

La dirección de correo electrónico principal también tiene los siguientes fines:

  • La dirección de correo electrónico principal es el nombre de usuario que el usuario debe proporcionar al acceder. Aunque los usuarios pueden agregar direcciones de correo electrónico o alias alternativos a sus cuentas de usuario de Google, estas direcciones no se consideran identidades y no se pueden usar para acceder.
  • Cuando un administrador necesita enviar notificaciones a los usuarios (por ejemplo, para anunciar un posible riesgo de seguridad), esas notificaciones se envían solo a la dirección de correo electrónico principal.

Para configurar el inicio de sesión único y el aprovisionamiento automático de usuarios entre Google y el IdP externo, debes asignar las identidades en tu IdP externo a las identidades correspondientes en Cloud Identity o G Suite. En las siguientes secciones, se describen las prácticas recomendadas para establecer esta asignación.

Usa la misma identidad en todos los sistemas federados

Todo lo que se requiere para establecer una asignación es verificar que la aserción de SAML que el IdP proporciona a Google contenga un reclamo del NameID con un valor que coincida con la dirección de correo electrónico principal de una Cloud Identity o usuario de G Suite. El IdP es libre de usar cualquier asignación o lógica aplicable a fin de derivar un reclamo del NameID adecuado para sus usuarios existentes.

Muchos IdP se basan en direcciones de correo electrónico (o, en términos más generales, en nombres que cumplen con RFC 822) para identificar usuarios. Algunos ejemplos son los siguientes:

  • El atributo userPrincipalName en Active Directory es un nombre compatible con RFC 822 que identifica de forma exclusiva a un usuario y que se puede usar para acceder a Windows o a los Servicios de federación de Active Directory (AD FS).
  • Azure Active Directory usa el atributo UserPrincipalName para identificar a los usuarios y permitirles que accedan.

Si los usuarios que administran el IdP externo ya dependen de una dirección de correo electrónico como su identidad, puedes usar la misma identidad que la dirección de correo electrónico principal en Cloud Identity o G Suite. Usar la misma identidad de usuario en los sistemas federados tiene varias ventajas:

  • Cuando los usuarios acceden a una herramienta de Google como Cloud Console, se les solicita que proporcionen la dirección de correo electrónico principal de su usuario de Cloud Identity o G Suite antes de que se los redireccione al IdP externo. Según tu IdP, es posible que el usuario vea otra pantalla de acceso en la que se le solicite su nombre de usuario y contraseña.

    Si las direcciones de correo electrónico son diferentes para estos pasos, la secuencia de pantallas de acceso puede confundir a los usuarios finales. Por el contrario, si los usuarios pueden usar una identidad común en todos los pasos, no quedan expuestos a las diferencias técnicas entre los IdP, lo que minimiza la potencial confusión.

  • Si no tienes que realizar asignaciones entre identidades de usuario, es más fácil correlacionar los registros de auditoría de Google Cloud con los registros de los sistemas locales.

  • Del mismo modo, si las aplicaciones que se implementan de forma local y en Google Cloud necesitan intercambiar datos que contengan identidades de usuario, debes evitar la complejidad adicional de tener que asignar identificadores de usuario.

Para obtener más detalles sobre la asignación de usuarios de Active Directory o de Azure AD a Cloud Identity o G Suite, consulta la guía de Active Directory o Azure AD.

Asegúrate de que las identidades usen direcciones de correo electrónico enrutables

Google Cloud usa la dirección de correo electrónico principal de un usuario para enviar correos electrónicos de notificación. Algunos ejemplos de estas notificaciones son los siguientes:

  • Alertas de presupuesto: si configuraste una alerta de presupuesto, Google Cloud envía una notificación a los administradores de facturación y a los usuarios de facturación cuando se supera un límite de presupuesto.

  • Notificaciones de pago: todas las notificaciones o alertas relacionadas con pagos se envían a las direcciones de correo electrónico de los usuarios de pagos que están configuradas para la cuenta de facturación afectada.

  • Invitaciones del proyecto: si asignas la función de administrador del proyecto a un usuario que es parte de una cuenta de Cloud Identity o G Suite diferente a la que está asociada la organización del proyecto, se envía una invitación al usuario. Antes de que la nueva función otorgada pueda entrar en vigor, el usuario debe aceptar la invitación. Para ello, debe hacer clic en un vínculo del mensaje de correo electrónico.

  • Respuestas a casos de ayuda y otras notificaciones de asistencia.

Si usas G Suite y configuraste de forma correcta los registros MX de DNS necesarios, todos los correos electrónicos de notificación que se envían a la dirección de correo electrónico principal se entregan a la bandeja de entrada de Gmail del usuario correspondiente.

Para los usuarios de Cloud Identity, Google Cloud también intenta entregar correos electrónicos de notificación, pero la infraestructura de correo electrónico existente debe manejar el correo electrónico. Para asegurarte de que los usuarios de Cloud Identity no se pierdan las notificaciones, asegúrate de que el sistema de correo electrónico existente acepte los mensajes que se envían a las direcciones de correo electrónico principales de los usuarios de Cloud Identity y que enrute este correo electrónico a los buzones correctos. Haz lo siguiente:

  • Asegúrate de que todos los dominios agregados a Cloud Identity tengan registros MX de DNS que apunten a tu sistema de correo electrónico existente.

  • Asegúrate de que la dirección de correo electrónico principal de un usuario de Cloud Identity coincida con un buzón existente en tu sistema de correo electrónico. Si hay una discrepancia entre la dirección de correo electrónico principal que usa Cloud Identity y la dirección de correo electrónico del usuario, configura un alias en tu sistema de correo electrónico existente para que los correos electrónicos que se envíen a cada dirección de correo electrónico principal se enruten al buzón correcto.

Si estas soluciones no son prácticas, considera agregar G Suite a la cuenta de Cloud Identity existente y asignar licencias de G Suite a los usuarios clave que están a cargo de la facturación o que interactúan con el equipo de asistencia, y que, por lo tanto, es más probable que reciban notificaciones.

Evalúa las opciones de migración para las cuentas personales existentes

Si los empleados usaban servicios de Google como Google Ad Manager, Google AdSense o Google Analytics antes de que la organización se registrara en Cloud Identity o G Suite, es posible que hayan estado usando cuentas personales para acceder a estos servicios.

Permitir que los empleados usen cuentas personales para fines comerciales puede ser riesgoso. Para obtener más detalles sobre cuáles son estos riesgos y cómo puedes mostrar las cuentas personales existentes, consulta Evalúa las Cuentas de Google existentes.

Puedes administrar las cuentas personales existentes de las siguientes maneras:

  • Mantén las cuentas personales como están y acepta los posibles riesgos.
  • Inicia una transferencia para migrar las cuentas a Cloud Identity o G Suite.
  • Obliga a los propietarios de las cuentas de usuario no administradas a cambiar su dirección de correo electrónico a fin de usar un dominio diferente.

Para obtener más detalles sobre cómo consolidar las cuentas personales existentes, consulta Evalúa las opciones de consolidación de identidades.

La manera en la que decides manejar las cuentas personales influye en cómo y en qué secuencia configuras la federación. Evalúa cualquier cuenta personal existente que usen los usuarios antes de comenzar a crear cuentas de usuario o configurar el inicio de sesión único en Cloud Identity o G Suite.

Asigna conjuntos de identidades

Cuando hayas definido cómo se asignan las identidades individuales entre el IdP externo y Cloud Identity o G Suite, debes determinar el conjunto de identidades para el que se habilitará el acceso a los servicios de Google.

El conjunto efectivo de identidades que se puede autenticar en los servicios de Google es la intersección de dos conjuntos:

  1. Identidades externas que se asignan a una identidad en Cloud Identity o G Suite.
  2. Identidades externas que tu IdP externo permite para el inicio de sesión único en Cloud Identity o G Suite.

    El proceso para controlar quién puede usar el inicio de sesión único difiere según el IdP que uses. Por ejemplo, Azure AD se basa en asignaciones, mientras que AD FS usa políticas de control de acceso.

Limita el conjunto de identidades que pueden autenticarse en los servicios de Google

Según cómo planees usar Google Cloud, G Suite y otras herramientas de Google, todos los empleados de la organización, o solo un subconjunto de ellos, deben poder autenticarse en los servicios de Google.

Si planeas otorgar acceso a los servicios de Google solo a un subconjunto de empleados de la organización, lo mejor es restringir la autenticación a este conjunto de usuarios. Cuando restringes la cantidad de usuarios que pueden autenticarse, estableces una capa de defensa adicional que ayuda en caso de que hayas configurado por accidente una regla de control de acceso con demasiada flexibilidad.

Puedes limitar el conjunto de usuarios que pueden autenticarse en Google de las siguientes maneras:

  • Minimiza la cantidad de cuentas de usuario en Cloud Identity o G Suite. Si no hay una cuenta de usuario asignada, cualquier intento de autenticación por parte de un usuario fallará, incluso si el IdP permite que el usuario acceda a Cloud Identity o G Suite mediante el inicio de sesión único.
  • Configura el inicio de sesión único en tu IdP para minimizar la cantidad de usuarios que pueden acceder a Cloud Identity o G Suite.

El mejor enfoque para la situación depende de si tienes cuentas personales que necesitas migrar.

Limita el conjunto de identidades que aprovisionas si aún necesitas migrar cuentas de consumidores

Solo puedes migrar una cuenta personal a Cloud Identity o G Suite si no creaste una cuenta de usuario con la misma identidad en Cloud Identity o G Suite.

Si tienes cuentas personales que aún deseas migrar, debes tener cuidado de no crear cuentas de usuario en conflicto por accidente. Para ello, sigue estos lineamientos:

  • Limita la autenticación mediante la creación de nuevas cuentas de usuario de Cloud Identity o G Suite solo para los usuarios que las necesitan y que no tienen una cuenta personal.
  • A fin de evitar el bloqueo accidental de cuentas migradas, permite el inicio de sesión único a los usuarios para los que creas cuentas de usuario en Cloud Identity o G Suite y para todas las cuentas personales que aún no se migraron.

En el siguiente diagrama, se muestra cómo se superponen y se interrelacionan los diferentes tipos de identidades.

Cómo se superponen y se interrelacionan los diferentes tipos de identidades.

En el diagrama, las identidades con una cuenta de usuario en Cloud Identity o G Suite se encuentran en la elipse más pequeña (amarilla). Esa elipse se encuentra dentro de la segunda elipse (azul), que contiene identidades que se pueden autenticar. La tercera y más grande elipse (rosa) contiene a las otras y consta de las identidades que tienen una cuenta de usuario en el IdP. Para obtener detalles sobre cómo configurar Active Directory, Okta o Azure AD, consulta nuestra guía de prácticas recomendadas.

Evita nuevos registros de cuentas personales

Cuando no hay más cuentas personales para migrar a Cloud Identity o G Suite, es mejor evitar que se registren cuentas personales nuevas.

Agregar un dominio, como example.com, a la cuenta de Cloud Identity o G Suite no evita que los empleados se registren para obtener cuentas personales nuevas. Estas cuentas personales nuevas aparecen como usuarios no administrados en tu cuenta de Cloud Identity o G Suite, pero no pueden usar el inicio de sesión único ni ninguna otra configuración que hayas aplicado a la cuenta de Cloud Identity o G Suite.

Para bloquear la creación de una cuenta personal nueva, debes crear una cuenta de usuario en Cloud Identity o G Suite con la misma dirección de correo electrónico. Por ejemplo, si creaste un usuario alice@example.com en la cuenta de Cloud Identity o G Suite, cualquier intento de un empleado de registrarse para una cuenta personal nueva con la misma identidad fallará. Sin embargo, si aún no existe un usuario correspondiente en Cloud Identity o G Suite, se registrará una cuenta personal nueva.

Cuando no hay más cuentas personales para migrar a Cloud Identity o G Suite, puedes aplicar la siguiente configuración:

  • Permite que solo los usuarios relevantes usen el inicio de sesión único en Cloud Identity o G Suite a fin de limitar la autenticación.

  • Lo ideal es aprovisionar usuarios de Cloud Identity o G Suite para todos los empleados. Asegúrate de que las cuentas de usuario usen la dirección de correo electrónico corporativa del empleado como la dirección de correo electrónico principal o el alias para que no se puedan crear cuentas personales nuevas con la misma dirección de correo electrónico. Si es posible, mantén las cuentas de usuario que no están habilitadas para el inicio de sesión único en estado suspendido.

En el siguiente diagrama, se muestra esta configuración.

Evitar nuevos registros de cuentas personales

Haz que las identidades de Cloud Identity o G Suite sean un subconjunto de las identidades en el IdP externo

Tu cuenta de Cloud Identity o G Suite puede contener cuentas de usuario con identidades que no se asignan a ningún usuario en el IdP externo. Existen dos situaciones típicas que pueden dar lugar a estas cuentas de usuario:

  • Creas una cuenta de usuario nueva en Cloud Identity o G Suite y usas una dirección de correo electrónico principal que no se asigna a ningún usuario en el IdP externo.
  • Tienes una cuenta de usuario en Cloud Identity o G Suite que se asigna a una identidad en el IdP externo, pero luego la borras en el IdP externo. Por ejemplo, puedes borrar la identidad si el empleado abandona la empresa.

Cuando habilitas el inicio de sesión único en Cloud Identity o G Suite, todos los usuarios (excepto los administradores avanzados) se ven obligados a usar el inicio de sesión único. Para una cuenta de usuario de Cloud Identity o G Suite que no se asigna a una identidad en el IdP externo, cualquier intento de uso del inicio de sesión único fallará. Una cuenta de usuario sin dicha contraparte queda efectivamente en desuso, pero podría representar un riesgo, como en las siguientes situaciones:

  • Si en algún momento el inicio de sesión único se inhabilita de forma temporal o permanente, la cuenta de usuario se puede volver a usar. Esto puede permitir que un exempleado acceda a los recursos corporativos.

  • El nombre de la cuenta de usuario borrada podría reutilizarse. Por ejemplo, un empleado que se une a la empresa podría compartir el mismo nombre con otro empleado que abandonó la empresa meses o años antes. Si la cuenta de usuario del empleado anterior se borró, es posible que asignes al empleado nuevo el nombre de usuario que solía usar el empleado anterior.

    Puede que la cuenta de usuario del empleado nuevo tenga un ID interno diferente al del empleado anterior. Sin embargo, desde la perspectiva de la federación, las dos cuentas de usuario se consideran iguales si ambas se asignan a la misma dirección de correo electrónico principal en Cloud Identity o G Suite. Como resultado, cuando el empleado nuevo acceda a Google, podría “heredar” los datos, la configuración y los permisos existentes del empleado anterior.

Los usuarios administradores avanzados de Cloud Identity y G Suite están exentos del requisito de usar el inicio de sesión único, pero aún pueden usar el inicio de sesión único cuando el IdP lo inicia. La capacidad de usar el inicio de sesión único iniciado por IdP hace que los usuarios administradores avanzados sean susceptibles a la usurpación de nombres si carecen de una contraparte en el IdP externo.

Considera el siguiente ejemplo: Alice tiene un usuario administrador avanzado alice-admin@example.com en Cloud Identity o G Suite y no usa la verificación en dos pasos. Mallory, que no conoce la contraseña de Alice, encuentra una manera de crear un usuario nuevo en el IdP externo que se asigna a alice-admin@example.com. Aunque esta cuenta de usuario recién creada podría no tener ningún privilegio especial y no tiene relación con la cuenta de usuario de Alice, el hecho de que comparta una identidad común con la cuenta de administrador avanzado de Alice permite a Mallory usar el inicio de sesión único iniciado por IdP y autenticarse como alice-admin@example.com.

Para mitigar este riesgo de usurpación de nombres, asegúrate de que las identidades de Cloud Identity o G Suite sean un subconjunto de las identidades en el IdP externo. La mejor manera de lograrlo es asignar todo el ciclo de vida de la cuenta de usuario que implementa el IdP externo al ciclo de vida de la cuenta de usuario en Cloud Identity o G Suite.

Usa usuarios administradores avanzados dedicados

Las cuentas de administrador avanzado de G Suite y Cloud Identity tienen un potente conjunto de permisos que se aplican a la cuenta de Cloud Identity o G Suite, y a una organización de Google Cloud asociada. Debido a que solo una pequeña cantidad de actividades requieren privilegios de administrador avanzado, siempre que sea posible, es mejor limitar la cantidad de administradores con acceso de administrador avanzado y usar cuentas de usuario con menos privilegios para la administración diaria de la organización o cuenta de Google Cloud..

Cuando hayas identificado a los administradores que requieren acceso de administrador avanzado, crea cuentas de usuario de administrador avanzado, por ejemplo:

  • Crea una cuenta de usuario con la identidad alice@example.com y asigna permisos comunes. Esta cuenta debe usarse a diario para las actividades de rutina.
  • Crea una segunda cuenta de usuario con la identidad alice-admin@example.com y asígnale privilegios de superusuario. Se recomienda usar esta cuenta solo para ocasiones en las que se requieren privilegios de administrador avanzado.

    A fin de garantizar que se reciben los correos electrónicos de notificación enviados a esta dirección de correo electrónico en el buzón del usuario, configura G Suite o el sistema de correo electrónico existente para que la dirección de correo electrónico alice-admin@example.com sea un alias o se reenvíe a alice@example.com.

Asegúrate de que el IdP externo reconozca ambas identidades para que el conjunto de identidades en Cloud Identity o G Suite continúe siendo un subconjunto de las identidades en el IdP externo.

Recomendamos seguir un esquema de nombres para estas cuentas de administrador avanzado, de modo que en los registros de auditoría puedas realizar un seguimiento de dónde y cómo se usan. Por ejemplo, agrega -admin al nombre de usuario, como en el ejemplo anterior.

Limita la cantidad de usuarios del servicio en G Suite y Cloud Identity

El IdP externo puede contener cuentas de usuario para empleados y cuentas de usuario destinadas a usuarios de máquinas, como aplicaciones, herramientas o trabajos en segundo plano.

En cambio, la forma preferida en Google Cloud de habilitar una aplicación para autenticar y acceder a las API de Google es implementar uno de los siguientes enfoques:

  • Una aplicación o herramienta web que necesita acceder a los servicios o API de Google en nombre de un usuario final debe usar OAuth 2.0, o bien OpenID Connect. Mediante el uso de uno de estos protocolos, la aplicación primero solicita el consentimiento del usuario final para acceder a los datos del usuario y, tras recibirlo, puede realizar el acceso en nombre del usuario final.

  • Si el acceso a las API o los servicios no debe hacerse en nombre de un usuario final, sino en nombre de la aplicación, es mejor usar cuentas de servicio de Google Cloud para la autenticación y, luego, otorgar acceso a la cuenta de servicio a los recursos mediante Cloud IAM.

Si a las cuentas de servicio de Google Cloud se les otorgan las funciones adecuadas en Cloud IAM, se pueden usar para autenticar y usar cualquier API de Cloud. Si necesitas otorgar a una cuenta de servicio acceso a las API que están fuera de Google Cloud, por ejemplo, a la API de Directory o la API de Drive, puedes usar la delegación de todo el dominio de G Suite.

Con la delegación de todo el dominio de G Suite, habilitas una cuenta de servicio para que actúe en nombre de un usuario de Cloud Identity o G Suite. Debido a que la delegación es un privilegio valioso, recomendamos que uses la delegación de todo el dominio de G Suite solo en los casos en que el enfoque de OAuth no sea práctico.

Usa un usuario de Cloud Identity o G Suite dedicado para cada cuenta de servicio de Google Cloud que esté habilitada para la delegación de todo el dominio de G Suite. Crea este usuario en el IdP externo y aprovisiónalo en Cloud Identity o G Suite para que el conjunto de usuarios en Cloud Identity o G Suite continúe siendo un subconjunto de usuarios en el IdP externo.

Evita crear usuarios de servicios en Cloud Identity y G Suite que no quieras usar para la delegación de todo el dominio de G Suite.

Asigna ciclos de vida de cuentas de usuario

Las cuentas de usuario en el IdP externo siguen un ciclo de vida determinado. Por lo general, este ciclo de vida refleja la relación laboral entre el empleado y la empresa:

  1. Se crea una cuenta de usuario nueva para un empleado que se une a la organización.
  2. La cuenta de usuario podría suspenderse de forma temporal y reactivarse más tarde, por ejemplo, cuando el empleado se ausente.
  3. Cuando el usuario abandona la empresa, la cuenta de usuario se borra o se mantiene suspendida durante un período de retención determinado antes de borrarse.

En el siguiente diagrama, se ilustra este ciclo de vida.

Asignación de ciclos de vida de cuentas de usuario.

En esta sección, se enumeran las prácticas recomendadas para garantizar que el ciclo de vida de las cuentas de usuario en Cloud Identity o G Suite siga el ciclo de vida de las cuentas de usuario correspondientes en el IdP externo.

Designa el IdP externo como fuente de información

Muchos sistemas de información de RR.HH. (HRIS), IdP y adaptadores solo admiten el aprovisionamiento unidireccional del usuario. Esto significa que los cambios realizados en el HRIS o el IsP se propagan a Cloud Identity o G Suite, pero los cambios realizados en Cloud Identity o G Suite no se propagan.

Para evitar incoherencias causadas por el aprovisionamiento unidireccional, designa el IdP externo como la fuente de información. Usa de forma exclusiva el IdP externo (o HRIS) a fin de crear, modificar o borrar usuarios, y confía en el aprovisionamiento automatizado para que los cambios se propaguen a G Suite y Cloud Identity. Cuando designas tu IdP externo como fuente de información, limitas el riesgo de incoherencias y de que el IdP anule las modificaciones manuales.

Automatiza el aprovisionamiento de usuarios en Cloud Identity o G Suite

A fin de permitir que un empleado se autentique en Google mediante el inicio de sesión único, primero debes crear una cuenta de usuario para el empleado en Cloud Identity o G Suite. Para garantizar la coherencia con el IdP externo, es mejor automatizar el proceso de aprovisionamiento de estas cuentas de usuario en Cloud Identity o G Suite:

  • Si automatizas el aprovisionamiento, puedes asegurarte de que las identidades de Cloud Identity o G Suite siempre sean un subconjunto de las identidades en el IdP externo.
  • Minimizas el riesgo de generar, por accidente, una discrepancia entre una identidad en Cloud Identity o G Suite y la identidad correspondiente en el IdP externo. Las discrepancias, como un error ortográfico accidental en la dirección de correo electrónico, pueden ocasionar que los empleados tengan problemas para acceder.
  • Minimizas el esfuerzo de administración manual.

Si usas el HRIS a fin de administrar el proceso de integración, una forma de automatizar el aprovisionamiento de usuarios es configurar el HRIS para que aprovisione las cuentas de usuario en el IdP externo y en Cloud Identity o G Suite, como en el siguiente diagrama.

Aprovisiona cuentas de usuario en el IdP externo y en Cloud Identity o G Suite.

A fin de que esta configuración funcione bien, debes asegurarte de que tu HRIS aprovisione las cuentas de usuario de modo que se asignen entre sí de forma correcta. Además, el HRIS debe decidir qué cuentas de usuario aprovisionar en Cloud Identity o G Suite.

Otra forma de automatizar el aprovisionamiento de usuarios que funciona de forma independiente de un HRIS es usar el IdP externo como fuente autorizada para aprovisionar usuarios en Cloud Identity o G Suite. En este caso, la configuración para asignar cuentas de usuario y conjuntos de cuentas de usuario se administra en el IdP o por el adaptador, como se muestra en el siguiente diagrama.

Usa el IdP externo como la fuente autorizada para aprovisionar usuarios en Cloud Identity o G Suite

Si usas Active Directory como tu IdP, puedes duplicar esta configuración mediante Google Cloud Directory Sync. Otros IdP, como Okta o Azure AD tienen adaptadores integrados para el aprovisionamiento de usuarios en G Suite. Dado que G Suite y Cloud Identity se basan en la misma plataforma y usan las mismas API, estos adaptadores también se pueden usar para Cloud Identity.

Propaga eventos de suspensión a Cloud Identity o G Suite

Cuando un empleado abandona la organización, ya sea de forma temporal o permanente, recomendamos revocar el acceso del empleado a los servicios de Google. Si suspendes la cuenta de usuario del empleado en el IdP externo, revocas su capacidad de usar el inicio de sesión único para autenticarse en Google, pero es posible que no revoques por completo el acceso a todos los servicios de Google. Podría ocurrir lo siguiente:

  • Si el usuario de Cloud Identity o G Suite tiene una sesión de navegador activa, la sesión continuará funcionando. Todos los tokens de OAuth ya obtenidos seguirán siendo válidos.
  • Si el usuario tiene privilegios de administrador avanzado, o si configuraste máscaras de red, es posible que el empleado aún pueda acceder mediante una contraseña.
  • Es posible que la cuenta de usuario siga recibiendo notificaciones de Google Cloud, incluidas las alertas de presupuesto.
  • Si el usuario tiene una licencia de G Suite asignada, seguirá recibiendo correos electrónicos en su buzón, seguirá apareciendo en la libreta de direcciones y podría seguir apareciendo como disponible en Calendario de Google.
  • Si permites que los usuarios usen apps menos seguras, es posible que el usuario aún pueda acceder a Gmail, Calendario y otros datos mediante contraseñas de la aplicación.

Para revocar por completo el acceso a los servicios de Google, propaga los eventos de suspensión a Cloud Identity o G Suite de las siguientes maneras:

  • Asegúrate de que cada vez que se suspenda una cuenta de usuario en el IdP externo, también se suspenda la cuenta de usuario correspondiente en Cloud Identity o G Suite. La suspensión de un usuario en Cloud Identity o G Suite finaliza las sesiones activas del navegador, invalida los tokens y revoca todos los otros accesos.

  • De manera similar, cuando reactives una cuenta de usuario en el IdP externo, asegúrate de reactivar la cuenta de usuario correspondiente en Cloud Identity o G Suite.

La suspensión de una cuenta de usuario en Cloud Identity o G Suite no es una operación destructiva. Mientras la cuenta de usuario se encuentra suspendida, se conservan los datos del usuario, las licencias de G Suite permanecen adjuntas y las funciones asignadas en Google Cloud no se modifican.

Propaga eventos de eliminación a Cloud Identity o G Suite

Cuando un empleado abandona la organización de forma permanente, es posible que decidas suspender la cuenta de usuario del empleado en el IdP externo y borrarla.

Si borras una cuenta de usuario en el IdP externo, pero no borras el usuario de Cloud Identity o G Suite correspondiente, el conjunto de usuarios en Cloud Identity y G Suite ya no es un subconjunto de los usuarios en el IdP. Esto puede convertirse en un problema en el futuro si un empleado nuevo se une a la organización y tiene el mismo nombre que el empleado que dejó la empresa. Si creas una cuenta de usuario en el IdP para el empleado nuevo, puedes volver a usar el nombre de usuario del empleado anterior, lo que hace que la cuenta de usuario nueva se asigne a la cuenta de usuario anterior en Cloud Identity o G Suite. Como resultado, el empleado nuevo podría obtener acceso a los datos y la configuración del empleado anterior.

Para evitar los riesgos asociados con las cuentas de usuario huérfanas de Cloud Identity o G Suite, puedes borrar un usuario de Cloud Identity o G Suite apenas se borre la cuenta de usuario correspondiente en el IdP.

Borrar un usuario de Cloud Identity o G Suite es una operación destructiva que solo se puede deshacer durante un período determinado. Según los servicios de Google que consume el usuario, borrar el usuario puede hacer que los datos asociados se borren de forma permanente y, por lo tanto, que no se satisfagan los requisitos de cumplimiento.

Para conservar la configuración y los datos del usuario durante un período de retención determinado antes de borrarlos de forma permanente, implementa uno de los siguientes enfoques:

  • Para retrasar la eliminación de la cuenta de usuario en tu IdP externo, mantén al usuario en un estado de suspensión durante un período de retención determinado. Borra el usuario en el IdP y en Cloud Identity/G Suite una vez transcurrido el período de retención.

  • Cuando borres una cuenta de usuario en el IdP externo, suspende el usuario de Cloud Identity o G Suite correspondiente y cambia la dirección de correo electrónico principal a un nombre que tenga pocas probabilidades de generar un conflicto. Por ejemplo, cambia el nombre de alice@example.com a obsolete-yyyymmdd-alice@example.com, en el que yyyymmdd refleja la fecha de eliminación en el IdP externo. Mantén la cuenta de usuario a la que le cambiaste el nombre en un estado de suspensión durante un período de retención y bórrala una vez transcurrido dicho período.

A fin de conservar los datos de G Suite para los usuarios suspendidos, mantén la licencia de G Suite asignada al usuario o cámbiala a una licencia de usuario archivado a fin de garantizar que las reglas de retención de G Suite Vault se sigan aplicando y que se conserven los datos del usuario.

Inicio de sesión único

Todos los productos de Google, incluidos los servicios como Google Cloud, Google Ads y YouTube, usan el Acceso con Google para autenticar a los usuarios. Un servicio inicia el proceso de autenticación mediante la redirección de un usuario a accounts.google.com. Allí, el usuario ve la pantalla de Acceso de Google y se le solicita su dirección de correo electrónico. Según el dominio de la dirección de correo electrónico proporcionada, la cuenta de usuario se busca en Gmail, en el directorio de la cuenta del consumidor, o si el dominio coincide con su dominio principal, secundario o de alias, en una cuenta de Cloud Identity o G Suite.

En el siguiente diagrama, se ilustra este proceso de autenticación.

Proceso de autenticación de Google.

Si configuras una cuenta de Cloud Identity o G Suite a fin de usar el inicio de sesión único, los usuarios se redireccionan a un IdP externo para la autenticación. Cuando el IdP externo completa la autenticación, el resultado se retransmite al Acceso con Google mediante una aserción de SAML. Esta aserción de SAML sirve como prueba de una autenticación exitosa. La aserción contiene la dirección de correo electrónico del usuario y está firmada por el certificado del IdP externo para que el Acceso con Google pueda verificar la autenticidad.

Este proceso se conoce como inicio de sesión único iniciado por el proveedor de servicios y se aplica a todos los usuarios, excepto a los administradores avanzados. Los administradores avanzados nunca se redireccionan a un IdP externo, en su lugar, se les solicita una contraseña.

Algunos IdP también admiten el inicio de sesión único iniciado por IdP. En este modelo, el usuario se autentica en el IdP externo y, luego, sigue un vínculo que apunta a un servicio de Google como Google Cloud o Google Ads. Si se habilitó el inicio de sesión único para una cuenta de Cloud Identity o G Suite, todos los usuarios de esa cuenta pueden usar el inicio de sesión único iniciado por IdP, incluso los administradores avanzados.

Minimiza el conjunto de atributos pasados en las aserciones de SAML

Después de que un usuario se autentica en el IdP externo, Cloud Identity o G Suite usan la aserción de SAML que pasa el IdP externo para establecer una sesión. Además de validar su autenticidad, este proceso incluye la identificación de la cuenta de usuario de Cloud Identity o G Suite que corresponde al valor del NameID en la aserción de SAML.

Se espera que el valor del NameID contenga la dirección de correo electrónico principal de la cuenta de usuario que se autenticará. En las direcciones de correo electrónico, se distingue entre mayúsculas y minúsculas. No se tienen en cuenta los alias ni las direcciones de correo electrónico alternativas.

Para evitar errores de ortografía o de mayúsculas accidentales, es mejor aprovisionar de forma automática las cuentas de usuario.

Las aserciones de SAML pueden contener atributos adicionales, pero no se tienen en cuenta durante la autenticación. Los atributos que contienen información como el nombre, el apellido o las membresías de grupo del usuario se ignoran porque la cuenta del usuario en Cloud Identity o G Suite se considera la única fuente de esta información del usuario.

A fin de minimizar el tamaño de las aserciones de SAML, configura el IdP de manera que no incluya ningún atributo que no sea obligatorio para el Acceso con Google.

Usa google.com como emisor

Las sesiones de Acceso con Google no están restringidas a una sola herramienta o dominio. En cambio, una vez que se establece una sesión, esta es válida en todos los servicios de Google a los que se le otorgó acceso. Esta lista de servicios puede incluir servicios como Google Cloud, Google Ads, Búsqueda de Google y YouTube.

La naturaleza global de una sesión se refleja en el intercambio de protocolo de SAML. De forma predeterminada, Google usa google.com como el emisor (el elemento Issuer en la solicitud de SAML) y espera que las aserciones de SAML especifiquen google.com como el público (el elemento Audience en la respuesta de SAML).

Para cambiar esta configuración predeterminada, habilita la opción Usar una entidad emisora específica del dominio cuando configures el inicio de sesión único en Cloud Identity o G Suite. Habilita la opción del emisor específico del dominio solo si tienes más de una cuenta de Cloud Identity o G Suite (y, por lo tanto, varios dominios) y el IdP necesita distinguir entre los accesos iniciados por una cuenta de Cloud Identity o G Suite, en lugar de otra cuenta. Cuando habilitas la opción, las solicitudes de SAML usan google.com/a/DOMAIN como el emisor y esperan que google.com/a/DOMAIN sea el público, en el que DOMAIN es el dominio principal de la cuenta de Cloud Identity o G Suite.

En todos los demás casos, mantén la configuración predeterminada a fin de usar google.com como el emisor y configura el IdP externo para especificar google.com como el público en las aserciones de SAML. Según el IdP, esta configuración también puede denominarse emisor, identificador de relación de confianza con la parte autenticada o ID de entidad.

Alinea la duración de las sesiones de Google y las sesiones de IdP

Cuando un usuario completa el proceso de inicio de sesión único y se establece una sesión, la sesión de Acceso con Google permanece activa durante un período determinado. Tras este período, o si el usuario sale, se le solicita al usuario que vuelva a autenticarse mediante el proceso de inicio de sesión único.

De forma predeterminada, la duración de la sesión para los servicios de Google es de 14 días. Para los usuarios con una licencia de Cloud Identity Premium o G Suite Business, puedes cambiar la duración predeterminada de la sesión a un período diferente, como 8 horas.

Puedes controlar la duración de la sesión que usa Google Cloud. La sesión de Google Cloud se aplica a Cloud Console, a la herramienta de línea de comandos de gcloud y a otros clientes de la API. Puedes configurar la duración de la sesión de Google Cloud en todos los tipos de cuentas de Cloud Identity y G Suite.

La mayoría de los IdP externos también mantienen una sesión para los usuarios autenticados. Si la duración de la sesión de IdP es mayor que la de la sesión de Google, puede que se vuelva a realizar la autenticación de forma silenciosa. Es decir, se redirecciona al usuario al IdP, pero es posible que no tenga que volver a ingresar las credenciales. La reautenticación silenciosa podría socavar la intención de acortar la duración de las sesiones de Google.

A fin de asegurarte de que los usuarios tengan que volver a ingresar sus credenciales después de que venza una sesión de Google, configura la duración de la sesión de IdP para que sea más corta que la duración de la sesión de Google.

Autenticación de varios factores

Habilitar el inicio de sesión único entre Cloud Identity o G Suite y el IdP externo mejora la experiencia del usuario para los empleados. Los usuarios deben autenticarse con menos frecuencia y no necesitan memorizar credenciales diferentes para acceder a los servicios de Google.

Sin embargo, permitir que los usuarios se autentiquen sin problemas en todos los servicios y entornos también significa que el impacto potencial de las credenciales de usuario vulneradas aumenta. Si el nombre de usuario y la contraseña de un usuario se pierden o se roban, un atacante podría usar estas credenciales para acceder al entorno existente y a uno o más servicios de Google.

A fin de mitigar el riesgo de robo de credenciales, es mejor usar la autenticación de varios factores para todas las cuentas de usuario.

Aplica la autenticación de varios factores para los usuarios

Cuando configuras el inicio de sesión único para la cuenta de Cloud Identity o G Suite, los usuarios sin privilegios de administrador avanzado deben usar tu IdP externo para la autenticación.

Configura el IdP de modo que exija el uso de un segundo factor (como un código de un solo uso o una clave USB) a fin de aplicar la autenticación de varios factores cada vez que se use el inicio de sesión único en Google.

Si el IdP externo no admite la autenticación de varios factores, considera habilitar la verificación posterior al SSO para que Google realice una verificación adicional después de que el usuario se autentique con el IdP externo.

Evita usar máscaras de red, ya que podrían abusarse de ellas como una forma de evitar la autenticación de varios factores para los usuarios.

Aplica la autenticación en dos pasos de Google para los administradores avanzados

Las cuentas de administrador avanzado de G Suite y Cloud Identity están exentas del inicio de sesión único y tienen un conjunto potente de permisos, lo que las convierte en un objetivo atractivo para los atacantes. De forma predeterminada, la autenticación en dos pasos es opcional para las Cuentas de Google, incluidas las cuentas de administrador avanzado. Los usuarios pueden habilitar la función, pero no están obligados a hacerlo, a menos que apliques la autenticación en dos pasos.

Por lo general, los usuarios administradores avanzados se dividen en dos categorías:

  • Usuarios administradores avanzados personalizados: Estos usuarios están personalizados y diseñados para que los use un solo administrador. Recomendamos aplicar la verificación en dos pasos para todos los usuarios administradores avanzados personalizados.

  • Usuarios administradores avanzados de máquinas: Aunque es mejor evitar estas cuentas de usuario, a veces son necesarias para habilitar herramientas como Cloud Directory Sync o la app de la galería de Azure AD a fin de administrar usuarios y grupos en Cloud Identity o G Suite.

    Limita la cantidad de usuarios administradores avanzados de máquinas e intenta habilitar la verificación en dos pasos siempre que sea posible.

Para los usuarios que no usan el inicio de sesión único, puedes aplicar la autenticación en dos pasos a nivel global, por unidad organizacional o por grupo:

  • Si no tienes usuarios administradores avanzados de máquinas que no puedan usar la verificación en dos pasos, es mejor aplicar la autenticación a todos los usuarios. Si aplicas la verificación en dos pasos a todos los usuarios, evitas el riesgo de pasar por alto usuarios por accidente.

  • Si tienes usuarios administradores avanzados de máquinas que no pueden usar la verificación en dos pasos, usa un grupo dedicado para controlar la verificación en dos pasos. Crea un grupo nuevo, aplica la autenticación al grupo y agrega todos los superusuarios relevantes a él.

Si quieres obtener más detalles sobre el uso de la autenticación en dos pasos a fin de proteger a los usuarios administradores avanzados, consulta las prácticas recomendadas de seguridad para las cuentas de administrador.

No restrinjas el inicio de sesión único por máscara de red

Cuando configuras el inicio de sesión único en Cloud Identity o G Suite, puedes especificar una máscara de red. Si especificas una máscara, solo los usuarios que tengan direcciones IP que coincidan con la máscara estarán sujetos al inicio de sesión único; los demás usuarios deberán proporcionar una contraseña cuando accedan.

Si usas máscaras de red, es posible que estés socavando la autenticación de varios factores que aplica el IdP externo. Por ejemplo, un usuario podría cambiar las ubicaciones o usar una VPN para controlar si la máscara de red se aplica o no. Si aplicas la autenticación de varios factores en el IdP externo, esta táctica podría permitirle a un usuario o atacante eludir las políticas de autenticación de varios factores configuradas en el IdP externo.

Para garantizar que la autenticación de varios factores se aplique de manera coherente, sin importar la ubicación o la dirección IP de un usuario, evita restringir el inicio de sesión único por máscara de red.

A fin de restringir el acceso a los recursos por dirección IP, configura una lista apropiada de IP permitidas en el IdP externo o usa el acceso adaptado al contexto para Google Cloud y G Suite.

Próximos pasos