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

Last reviewed 2024-07-11 UTC

En este documento se presentan prácticas recomendadas y directrices que le ayudarán a configurar la federación de forma coherente y segura. Estas directrices se basan en las prácticas recomendadas para usar Cloud Identity o Google Workspace con Google Cloud.

Todos los servicios de Google, incluidos Google Cloud, Google Marketing Platform y Google Ads, utilizan Inicio de sesión con Google para autenticar a los usuarios. En lugar de crear y mantener manualmente cuentas de usuario en Cloud Identity o Google Workspace para cada empleado, puedes federar Cloud Identity o Google Workspace con tu proveedor de identidades (IdP) externo, como Active Directory o Microsoft Entra ID (antes Azure Active Directory). Configurar la federación suele implicar lo siguiente:

Asignar identidades

La identidad de una cuenta de usuario gestionada por Cloud Identity o Google Workspace se define mediante su dirección de correo principal. La dirección de correo principal aparece como Correo 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 principal debe usar uno de los dominios que hayas añadido a tu cuenta de Cloud Identity o Google Workspace.

La dirección de correo principal también se usa para lo siguiente:

  • La dirección de correo principal es el nombre de usuario que debe proporcionar un usuario al iniciar sesión. Aunque los usuarios pueden añadir direcciones de correo alternativas o alias a su cuenta de usuario de Google, estas direcciones no se consideran identidades y no se pueden usar para iniciar sesión.
  • 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 principal.

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

Usar la misma identidad en todos los sistemas federados

Para establecer una asignación, solo tienes que verificar que la aserción SAML que el proveedor de identidades proporciona a Google contiene una propiedad NameID con un valor que coincida con la dirección de correo principal de un usuario de Cloud Identity o Google Workspace. El IdP puede usar la asignación o la lógica que considere oportuna para obtener una reclamación NameID adecuada para sus usuarios.

Muchos proveedores de identidades se basan en direcciones de correo electrónico (o, de forma más general, en nombres que cumplen el estándar RFC 822) para identificar a los usuarios. Estos son algunos ejemplos:

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

Si los usuarios que gestiona tu IdP externo ya utilizan una dirección de correo como identidad, puedes usar la misma identidad como dirección de correo principal en Cloud Identity o Google Workspace. Usar la misma identidad de usuario en sistemas federados tiene varias ventajas:

  • Cuando los usuarios inician sesión en una herramienta de Google, como la Google Cloud consola, primero se les pide que proporcionen la dirección de correo principal de su usuario de Cloud Identity o Google Workspace antes de que se les redirija a tu IdP externo. En función de tu proveedor de identidades, es posible que se muestre otra pantalla de inicio de sesión en la que se le pida al usuario su nombre de usuario y su contraseña.

    Si las direcciones de correo son diferentes en estos pasos, la secuencia de pantallas de inicio de sesión puede confundir fácilmente a los usuarios finales. Por el contrario, si los usuarios pueden usar una identidad común en todos los pasos, no se exponen a las diferencias técnicas entre los IdPs, lo que minimiza la posible confusión.

  • Si no tienes que asignar identidades de usuario, te resultará 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 enGoogle Cloud necesitan intercambiar datos que contengan identidades de usuario, no tendrás que complicarte mapeando identificadores de usuario.

Para obtener más información sobre cómo asignar usuarios de Active Directory o Entra ID a Cloud Identity o Google Workspace, consulta la guía de Active Directory o la de Microsoft Entra ID.

Asegurarse de que las identidades usan direcciones de correo enrutable

Google Cloud usa la dirección de correo principal de un usuario para enviar correos de notificación. Estos son algunos ejemplos de estas notificaciones:

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

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

  • Invitaciones a proyectos: si asignas el rol Administrador de proyectos a un usuario que forma parte de una cuenta de Cloud Identity o de Google Workspace distinta de la que tiene asociada la organización del proyecto, se le enviará una invitación. Para que el rol recién concedido surta efecto, el usuario debe aceptar la invitación haciendo clic en un enlace del mensaje de correo.

  • Respuestas a casos de asistencia y otras notificaciones del equipo de Asistencia.

Si usas Google Workspace y has configurado correctamente los registros MX de DNS necesarios, todos los correos de notificación que se envíen a la dirección de correo principal se entregarán en la bandeja de entrada de Gmail del usuario correspondiente.

En el caso de los usuarios de Cloud Identity, Google Cloud también se intenta enviar correos de notificación, pero tu infraestructura de correo debe gestionar el correo. Para asegurarte de que tus usuarios de Cloud Identity no se pierdan las notificaciones, comprueba que tu sistema de correo acepte los mensajes que se envían a las direcciones de correo principales de los usuarios de Cloud Identity y que los dirija a los buzones correctos. Sigue estos pasos:

  • Asegúrate de que todos los dominios añadidos a Cloud Identity tengan registros MX de DNS que apunten a tu sistema de correo.

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

Si estas soluciones no te resultan prácticas, puedes añadir Google Workspace a tu cuenta de Cloud Identity y asignar licencias de Google Workspace a los usuarios clave que se encarguen de la facturación o de interactuar con el equipo de Asistencia y que, por lo tanto, tengan más probabilidades de recibir notificaciones.

Evaluar las opciones de migración de las cuentas de consumidor

Si tus empleados usaban servicios de Google como Google Ad Manager, Google AdSense o Google Analytics antes de que tu organización se registrara en Cloud Identity o Google Workspace, es posible que hayan estado usando cuentas de consumidor para acceder a estos servicios.

Permitir que los empleados usen cuentas de consumidor con fines empresariales puede ser arriesgado. Para obtener más información sobre estos riesgos y sobre cómo puedes mostrar las cuentas de consumidor que ya tienes, consulta el artículo Evaluar las cuentas de Google que ya se usan.

Puedes gestionar las cuentas de consumidor de las siguientes formas:

  • Mantener las cuentas de consumidor tal cual, aceptando los riesgos potenciales.
  • Migra las cuentas a Cloud Identity o Google Workspace iniciando una transferencia.
  • Obliga a los propietarios de las cuentas de usuario no gestionadas a cambiar su dirección de correo para usar otro dominio.

Para obtener más información sobre cómo consolidar cuentas de consumidor, consulta el artículo Evaluar las opciones de consolidación de identidades.

La forma en que decidas gestionar las cuentas de consumidor influye en cómo y en qué orden configuras la federación. Evalúa las cuentas de consumidor que usan tus usuarios antes de crear cuentas de usuario o configurar el inicio de sesión único en Cloud Identity o Google Workspace.

Asignar conjuntos de identidades

Una vez que hayas definido cómo se asignan las identidades individuales entre tu IdP externo y Cloud Identity o Google Workspace, debes determinar el conjunto de identidades para las que quieres habilitar el acceso a los servicios de Google.

El conjunto de identidades que pueden autenticarse 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 Google Workspace.

  2. Identidades externas que tu proveedor de identidades externo permite usar para iniciar sesión única en Cloud Identity o Google Workspace.

    El proceso para controlar quién tiene permiso para usar el inicio de sesión único varía en función del proveedor de identidades que utilices. Por ejemplo, Entra ID se basa en asignaciones, mientras que AD FS usa políticas de control de acceso.

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

En función de cómo tengas previsto usar Google Cloud, Google Workspace y otras herramientas de Google, todos los empleados de tu organización o solo un subconjunto de ellos deben poder autenticarse en los servicios de Google.

Si tienes previsto conceder acceso a los servicios de Google solo a un subconjunto de los empleados de tu organización, lo mejor es restringir la autenticación a este conjunto de usuarios. Al restringir el número de usuarios que pueden autenticarse, se establece una capa de defensa adicional que ayuda en caso de que hayas configurado accidentalmente una regla de control de acceso demasiado permisiva.

Puede limitar el conjunto de usuarios que pueden autenticarse en Google de las siguientes formas:

  • Minimiza el número de cuentas de usuario en Cloud Identity o Google Workspace. Si no hay ninguna cuenta de usuario asignada, cualquier intento de autenticación por parte de un usuario fallará, aunque el proveedor de identidades permita al usuario iniciar sesión en Cloud Identity o Google Workspace mediante el inicio de sesión único.
  • Configura el inicio de sesión único en tu proveedor de identidades para minimizar el número de usuarios que pueden iniciar sesión en Cloud Identity o Google Workspace.

La mejor opción para tu situación depende de si tienes cuentas de consumidor que necesites migrar.

Limita el conjunto de identidades que aprovisionas si aún tienes que migrar cuentas de consumidor

Solo puedes migrar una cuenta de consumidor a Cloud Identity o Google Workspace si no has creado una cuenta de usuario con la misma identidad en Cloud Identity o Google Workspace.

Si tienes cuentas de consumidor que quieres migrar, debes tener cuidado para no crear cuentas de usuario en conflicto por error. Sigue estas directrices:

  • Limita la autenticación creando cuentas de usuario de Cloud Identity o Google Workspace solo para los usuarios que las necesiten y que no tengan una cuenta de consumidor.
  • Para evitar que se bloqueen por error las cuentas migradas, permite el inicio de sesión único no solo a los usuarios para los que crees cuentas de usuario en Cloud Identity o Google Workspace, sino también a todas las cuentas de consumidor que aún no se hayan migrado.

En el siguiente diagrama se muestra cómo se solapan y se relacionan los diferentes tipos de identidades.

Cómo se solapan y se relacionan los distintos tipos de identidades.

En el diagrama, las identidades que tienen una cuenta de usuario en Cloud Identity o Google Workspace se encuentran en la elipse más pequeña (amarilla). Esa elipse está contenida en la segunda elipse (azul), que contiene identidades que pueden autenticarse. La tercera elipse, la más grande (gris), contiene a las demás y está formada por las identidades que tienen una cuenta de usuario en tu IdP. Para obtener información sobre cómo configurar Active Directory, Entra ID u Okta, consulta nuestra guía de prácticas recomendadas.

Evitar que se creen nuevas cuentas de consumidor

Si añades un dominio como example.com a tu cuenta de Cloud Identity o Google Workspace, no impedirás que los empleados se registren en nuevas cuentas de consumidor con el mismo dominio. Estas nuevas cuentas de consumidor se muestran como usuarios no gestionados en tu cuenta de Cloud Identity o Google Workspace, pero no pueden usar el inicio de sesión único ni ninguna otra configuración que hayas aplicado en tu cuenta de Cloud Identity o Google Workspace.

Una forma de bloquear la creación de una cuenta de consumidor es crear una cuenta de usuario en Cloud Identity o Google Workspace con la misma dirección de correo. Por ejemplo, si has creado un usuario alice@example.com en tu cuenta de Cloud Identity o Google Workspace, cualquier intento de un empleado de registrarse en una nueva cuenta de consumidor con la misma identidad fallará. Sin embargo, si aún no existe ningún usuario correspondiente en Cloud Identity o Google Workspace, se podrá crear una cuenta de consumidor.

Cuando no haya más cuentas de consumidor que migrar a Cloud Identity, evita que se registren nuevas cuentas de consumidor aplicando la siguiente configuración:

  • Limita la autenticación permitiendo que solo los usuarios pertinentes utilicen el inicio de sesión único en Cloud Identity o Google Workspace.

  • Proporciona Cloud Identity o Google Workspace a todos los empleados. Asegúrate de que las cuentas de usuario utilicen la dirección de correo corporativa del empleado como dirección de correo principal o alias para que no se puedan crear nuevas cuentas de consumidor con la misma dirección de correo. Si es posible, mantén las cuentas de usuario que no tengan habilitado el inicio de sesión único en estado suspendido.

En el siguiente diagrama se muestra esta configuración.

Impedir el registro de nuevas cuentas de consumidor.

Si aún estás migrando cuentas de consumidor, puedes monitorizar temporalmente las nuevas suscripciones de cuentas de consumidor capturando los correos de verificación que se envían durante el proceso de registro. Los correos de verificación usan una dirección de remitente de envolvente que coincide con *@idverification.bounces.google.com. Configura un filtro en tu sistema de correo que identifique los correos con esta dirección de remitente y los retenga para revisarlos internamente.

Hacer que las identidades de Cloud Identity o Google Workspace sean un subconjunto de las identidades de tu proveedor de identidades externo

Es posible que tu cuenta de Cloud Identity o Google Workspace contenga cuentas de usuario con identidades que no se correspondan con ningún usuario de tu proveedor de identidades externo. Hay dos situaciones habituales que pueden dar lugar a estas cuentas de usuario:

  • Creas una cuenta de usuario en Cloud Identity o Google Workspace y usas una dirección de correo principal que no se corresponde con ningún usuario de tu IdP externo.
  • Tienes una cuenta de usuario en Cloud Identity o Google Workspace que se corresponde con una identidad de tu proveedor de identidades externo, pero luego eliminas la identidad del proveedor de identidades externo. Por ejemplo, puedes eliminar la identidad si el empleado deja la empresa.

Cuando habilitas el inicio de sesión único en Cloud Identity o Google Workspace, todos los usuarios (excepto los superadministradores) se ven obligados a usarlo. Si una cuenta de usuario de Cloud Identity o Google Workspace no se corresponde con una identidad de tu IdP externo, se producirá un error al intentar usar el inicio de sesión único. Una cuenta de usuario sin una contraparte de este tipo está inactiva, pero puede seguir suponiendo un riesgo, como en las siguientes situaciones:

  • Si en algún momento se inhabilita el inicio de sesión único de forma temporal o permanente, se podrá volver a usar la cuenta de usuario. Esto podría permitir que un antiguo empleado inicie sesión y acceda a los recursos corporativos.

  • Es posible que se reutilice el nombre de la cuenta de usuario eliminada. Por ejemplo, un empleado que se incorpora a la empresa puede tener el mismo nombre que otro empleado que dejó la empresa meses o años antes. Si la cuenta de usuario del antiguo empleado se ha eliminado, es posible que puedas asignar al nuevo empleado el nombre de usuario que utilizaba el anterior.

    La cuenta de usuario del nuevo empleado puede tener un ID interno diferente al del antiguo empleado. Sin embargo, desde el punto de vista de la federación, las dos cuentas de usuario se consideran la misma si ambas se asignan a la misma dirección de correo principal en Cloud Identity o Google Workspace. Por lo tanto, cuando el nuevo empleado inicie sesión en Google, puede que "herede" los datos, los ajustes y los permisos del antiguo empleado.

Los usuarios con rol de superadministrador de Cloud Identity y Google Workspace no tienen que usar el inicio de sesión único, pero pueden hacerlo cuando el IdP lo inicie. La posibilidad de usar el inicio de sesión único iniciado por el IdP hace que los usuarios superadministradores sean vulnerables a la usurpación de nombres si no tienen una contraparte en tu IdP externo.

Veamos el siguiente ejemplo: Alicia tiene una cuenta de usuario con privilegios de superadministradoralice-admin@example.com en Cloud Identity o Google Workspace y no usa la verificación en dos pasos. Mallory, que no conoce la contraseña de Alicia, encuentra una forma de crear un nuevo usuario en el proveedor de identidades externo que se asigna a alice-admin@example.com. Aunque esta cuenta de usuario recién creada no tenga privilegios especiales y no esté relacionada con la cuenta de usuario de Alicia, el hecho de que comparta una identidad común con la cuenta de superadministrador de Alicia permite a Mallory usar el inicio de sesión único iniciado por el proveedor de identidades y autenticarse como alice-admin@example.com.

Para mitigar este riesgo de usurpación de nombres, asegúrate de que tus identidades de Cloud Identity o Google Workspace sean un subconjunto de las identidades de tu proveedor de identidades externo. La mejor forma de hacerlo es mapear todo el ciclo de vida de la cuenta de usuario tal como lo implementa tu IdP externo con el ciclo de vida de la cuenta de usuario en Cloud Identity o Google Workspace.

Usar usuarios superadministradores específicos

Las cuentas de superadministrador de Google Workspace y Cloud Identity tienen un conjunto de permisos muy potentes que se aplican no solo a la cuenta de Cloud Identity o Google Workspace, sino también a la organización Google Cloud asociada. Como solo un pequeño número de actividades requieren privilegios de superadministrador, siempre que sea posible, es mejor limitar el número de administradores con acceso de superadministrador y usar cuentas de usuario con menos privilegios para la administración diaria de su cuenta u organización Google Cloud .

Cuando hayas identificado a los administradores que necesitan acceso de superadministrador, crea cuentas de usuario de superadministrador específicas. Por ejemplo:

  • Crea una cuenta de usuario con la identidad alice@example.com y asigna permisos normales. Esta cuenta se debe usar a diario para llevar a cabo actividades rutinarias.

  • Crea una segunda cuenta de usuario con la identidad alice-admin@example.com y asígnale privilegios de superusuario. Es una práctica recomendada que Alicia use esta cuenta solo en las ocasiones en las que se requieran privilegios de superadministrador.

    Para asegurarte de que se reciben los correos de notificación enviados a esta dirección de correo en el buzón del usuario, configura Google Workspace o tu sistema de correo para que la dirección alice-admin@example.com sea un alias o se reenvíe a alice@example.com.

Asegúrate de que tu proveedor de identidades externo reconozca ambas identidades para que el conjunto de identidades de Cloud Identity o Google Workspace siga siendo un subconjunto de las identidades de tu proveedor de identidades externo.

Te recomendamos que sigas un esquema de nomenclatura para estas cuentas de superadministrador dedicadas, de forma que puedas hacer un seguimiento de dónde y cómo se usan en los registros de auditoría. Por ejemplo, añade -admin al nombre de usuario, como en el ejemplo anterior.

Limitar el número de usuarios de servicios en Google Workspace y Cloud Identity

Tu proveedor de identidades externo puede contener no solo cuentas de usuario de empleados, sino también cuentas de usuario destinadas a usuarios de máquinas, como aplicaciones, herramientas o trabajos en segundo plano.

Por el contrario, la forma preferida de Google Cloud habilitar una aplicación para que se autentique y acceda a las APIs de Google es implementar uno de los siguientes métodos:

  • Una aplicación o herramienta web que necesite acceder a las APIs o los servicios de Google en nombre de un usuario final debe usar OAuth 2.0 u OpenID Connect. Al usar uno de estos protocolos, la aplicación primero solicita el consentimiento del usuario final para acceder a sus datos y, al recibirlo, puede realizar el acceso en nombre del usuario final.

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

Si Google Cloud se asignan los roles adecuados a las cuentas de servicio en Gestión de identidades y accesos, se pueden usar para autenticar y usar cualquier API de Cloud. Si necesitas conceder acceso a una cuenta de servicio a APIs que están fuera deGoogle Cloud, como la API Directory o la API Drive, puedes usar la delegación a nivel de dominio de Google Workspace.

Con la delegación a nivel de dominio de Google Workspace, puedes permitir que una cuenta de servicio actúe en nombre de un usuario de Cloud Identity o Google Workspace. Dado que la delegación es un privilegio muy importante, te recomendamos que utilices la delegación en todo el dominio de Google Workspace solo en los casos en los que el enfoque de OAuth no sea práctico.

Usa un usuario de Cloud Identity o Google Workspace específico para cada cuenta de servicio que tenga habilitada la delegación a nivel de dominio de Google Workspace.Google Cloud Crea este usuario en tu proveedor de identidades externo y, a continuación, aprovisiona el usuario en Cloud Identity o Google Workspace para que el conjunto de usuarios de Cloud Identity o Google Workspace siga siendo un subconjunto de los usuarios de tu proveedor de identidades externo.

No crees usuarios de servicio en Cloud Identity y Google Workspace que no vayas a usar para la delegación en todo el dominio de Google Workspace.

Asignar ciclos de vida de cuentas de usuario

Las cuentas de usuario de tu 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 nueva cuenta de usuario para un empleado que se incorpora a la organización.
  2. Es posible que la cuenta de usuario se suspenda temporalmente y se reactive más adelante, por ejemplo, cuando el empleado se vaya de vacaciones.
  3. Cuando el usuario deja la empresa, la cuenta de usuario se elimina o se mantiene en estado suspendido durante un periodo de conservación determinado antes de eliminarse definitivamente.

En el siguiente diagrama se ilustra este ciclo de vida.

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

En esta sección se indican las prácticas recomendadas para asegurarse de que el ciclo de vida de las cuentas de usuario de Cloud Identity o Google Workspace siga el ciclo de vida de las cuentas de usuario correspondientes de tu proveedor de identidades externo.

Designar tu proveedor de identidades externo como fuente de referencia

Muchos sistemas de información de recursos humanos (SIRR), IdPs y adaptadores solo admiten el aprovisionamiento de usuarios unidireccional. Esto significa que los cambios realizados en el sistema de información de recursos humanos o en el proveedor de identidades se propagan a Cloud Identity o Google Workspace, pero los cambios realizados en Cloud Identity o Google Workspace no se propagan de vuelta.

Para evitar incoherencias causadas por el aprovisionamiento unidireccional, designe su IdP externo como fuente de información veraz. Usa exclusivamente tu proveedor de identidades externo (o tu sistema de información de recursos humanos) para crear, modificar o eliminar usuarios, y confía en el aprovisionamiento automatizado para que los cambios se propaguen a Google Workspace y Cloud Identity. Al designar tu IdP externo como fuente de información veraz, limitas el riesgo de que haya incoherencias y de que el IdP sobrescriba las modificaciones manuales.

Automatizar el aprovisionamiento de usuarios en Cloud Identity o Google Workspace

Para que un empleado pueda autenticarse en Google mediante el inicio de sesión único, primero debes crear una cuenta de usuario para el empleado en Cloud Identity o Google Workspace. Para que el proceso sea coherente con tu IdP externo, lo mejor es automatizar el aprovisionamiento de estas cuentas de usuario en Cloud Identity o Google Workspace:

  • Al automatizar el aprovisionamiento, puedes asegurarte de que las identidades de Cloud Identity o Google Workspace siempre sean un subconjunto de las identidades de tu proveedor de identidades externo.
  • De esta forma, se reduce el riesgo de que se produzca una discrepancia entre una identidad de Cloud Identity o Google Workspace y la identidad correspondiente de tu IdP externo. Si hay errores, como una falta de ortografía accidental en la dirección de correo, los empleados pueden tener problemas para iniciar sesión.
  • Minimizar el esfuerzo de administración manual.

Si utilizas un sistema de información de recursos humanos para gestionar el proceso de incorporación, una forma de automatizar el aprovisionamiento de usuarios es configurar el sistema para que aprovisione cuentas de usuario tanto en tu proveedor de identidades externo como en Cloud Identity o Google Workspace, tal como se muestra en el siguiente diagrama.

Proporciona cuentas de usuario tanto a tu proveedor de identidades externo como a Cloud Identity o Google Workspace.

Para que esta configuración funcione correctamente, debes asegurarte de que tu sistema de información de recursos humanos aprovisione las cuentas de usuario de forma que se asignen correctamente entre sí. Además, el SIREH debe gestionar la decisión de qué cuentas de usuario se aprovisionan en Cloud Identity o Google Workspace.

Otra forma de automatizar el aprovisionamiento de usuarios que funciona independientemente de un SIAR es usar tu proveedor de identidades externo como fuente autorizada para aprovisionar usuarios en Cloud Identity o Google Workspace. En esta configuración, la asignación de cuentas de usuario y los conjuntos de cuentas de usuario se gestionan en el IdP o en el adaptador, como se muestra en el siguiente diagrama.

Usar tu IdP externo como fuente autorizada para aprovisionar usuarios en Cloud Identity o Google Workspace.

Si usas Active Directory como proveedor de identidades, puedes duplicar esta configuración con Google Cloud Directory Sync. Otros proveedores de identidades, como Entra ID u Okta, tienen adaptadores integrados para aprovisionar usuarios en Google Workspace. Como Google Workspace y Cloud Identity se basan en la misma plataforma y usan las mismas APIs, estos adaptadores también se pueden usar en Cloud Identity.

Propagar eventos de suspensión a Cloud Identity o Google Workspace

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

  • Si el usuario de Cloud Identity o Google Workspace tiene una sesión de navegador activa, la sesión seguirá funcionando. Los tokens de OAuth que ya se hayan obtenido también seguirán siendo válidos.
  • Si el usuario tiene privilegios de superadministrador o si has configurado máscaras de red, es posible que el empleado pueda iniciar sesión con 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 asignada una licencia de Google Workspace, los correos seguirán enviándose a su buzón, seguirá apareciendo en la libreta de direcciones y puede que siga figurando como disponible en Google Calendar.
  • Si permites que los usuarios utilicen aplicaciones poco seguras, es posible que puedan acceder a Gmail, Google Calendar y otros datos mediante contraseñas de aplicación.

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

  • Asegúrate de que, cada vez que se suspenda una cuenta de usuario en tu IdP externo, también se suspenda la cuenta de usuario correspondiente en Cloud Identity o Google Workspace. Si suspendes a un usuario en Cloud Identity o Google Workspace, se cerrarán las sesiones de navegador activas, se invalidarán los tokens y se revocará el resto de los accesos.

  • Del mismo modo, cuando reactives una cuenta de usuario en tu proveedor de identidades externo, asegúrate de reactivar también la cuenta de usuario correspondiente en Cloud Identity o Google Workspace.

Suspender una cuenta de usuario en Cloud Identity o Google Workspace es una operación no destructiva. Mientras la cuenta de usuario esté suspendida, se conservarán los datos del usuario, las licencias de Google Workspace seguirán asociadas y los roles asignados en Google Cloud no cambiarán.

Propagar eventos de eliminación a Cloud Identity o Google Workspace

Cuando un empleado deja la organización de forma permanente, puedes decidir no solo suspender su cuenta de usuario en tu proveedor de identidades externo, sino también eliminarla.

Si eliminas una cuenta de usuario en tu IdP externo, pero no eliminas el usuario correspondiente de Cloud Identity o Google Workspace, el conjunto de usuarios de Cloud Identity y Google Workspace ya no será un subconjunto de los usuarios de tu IdP externo. Esto puede convertirse en un problema en el futuro si se incorpora a tu organización un nuevo empleado que tenga el mismo nombre que el empleado que se fue de la empresa. Si creas una cuenta de usuario en tu proveedor de identidades para el nuevo empleado, es posible que reutilices el nombre de usuario del antiguo empleado, lo que hará que la nueva cuenta de usuario se asigne a la antigua en Cloud Identity o Google Workspace. Por lo tanto, el nuevo empleado podría acceder a los datos y a la configuración del antiguo.

Puedes evitar los riesgos asociados a las cuentas de usuario huérfanas de Cloud Identity o Google Workspace eliminando un usuario de Cloud Identity o Google Workspace en cuanto se elimine la cuenta de usuario correspondiente en tu proveedor de identidades.

Eliminar un usuario de Cloud Identity o Google Workspace es una operación irreversible que solo se puede deshacer en un periodo determinado. En función de los servicios de Google que haya usado el usuario, al eliminarlo, es posible que los datos asociados se eliminen de forma permanente y, por lo tanto, no se cumplan tus requisitos de cumplimiento.

Para conservar la configuración y los datos de los usuarios durante un periodo de conservación determinado antes de eliminarlos definitivamente, implementa uno de los siguientes métodos:

  • Retrasa la eliminación de la cuenta de usuario en tu proveedor de identidades externo manteniendo al usuario en estado suspendido durante un periodo de conservación determinado. Elimina al usuario tanto en tu proveedor de identidades como en Cloud Identity o Google Workspace una vez que haya transcurrido el periodo de retención.

  • Cuando elimines una cuenta de usuario en tu proveedor de identidades externo, suspende el usuario correspondiente de Cloud Identity o Google Workspace y cambia su dirección de correo principal por un nombre que sea poco probable que cause un conflicto. Por ejemplo, cambia el nombre de alice@example.com a obsolete-yyyymmdd-alice@example.com, donde yyyymmdd refleja la fecha de eliminación en tu proveedor de identidades externo. Mantener la cuenta de usuario cuyo nombre se ha cambiado en estado suspendido durante un periodo de conservación y eliminarla una vez transcurrido ese periodo.

Para conservar los datos de Google Workspace de los usuarios suspendidos, mantén la licencia de Google Workspace asignada al usuario o cámbiala a una licencia de Usuario archivado para asegurarte de que se sigan aplicando las reglas de conservación de Google Workspace Vault y de que se conserven los datos del usuario.

Inicio de sesión único

Todos los productos de Google, incluidos servicios como Google Cloud, Google Ads y YouTube, usan Inicio de sesión con Google para autenticar a los usuarios. Un servicio inicia el proceso de autenticación redirigiendo a un usuario a accounts.google.com, donde el usuario ve la pantalla de inicio de sesión de Google y se le pide su dirección de correo electrónico. En función del dominio de la dirección de correo proporcionada, la cuenta de usuario se buscará en Gmail, en el directorio de cuentas de consumidor o, si el dominio coincide con su dominio principal, secundario o de alias, en una cuenta de Cloud Identity o Google Workspace.

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 Google Workspace para usar el inicio de sesión único, los usuarios se redirigirán a un IdP externo para autenticarse. Cuando el proveedor de identidades externo haya completado la autenticación, el resultado se enviará de vuelta a Inicio de sesión con Google mediante una aserción SAML. Esta aserción SAML sirve como prueba de una autenticación correcta. La aserción contiene la dirección de correo del usuario y está firmada por el certificado del proveedor de identidades externo para que el inicio de sesión de Google pueda verificar su autenticidad.

Este proceso se denomina inicio de sesión único iniciado por el proveedor de servicios y se aplica a todos los usuarios, excepto a los superadministradores. A los superadministradores nunca se les redirige a un proveedor de identidades externo, sino que se les pide una contraseña.

Algunos IdPs también admiten el inicio de sesión único iniciado por el IdP. En este modelo, el usuario se autentica en el IdP externo y, a continuación, sigue un enlace que apunta a un servicio de Google, como Google Cloud o Google Ads. Si el inicio de sesión único se ha habilitado en una cuenta de Cloud Identity o Google Workspace, todos los usuarios de esa cuenta podrán usar el inicio de sesión único iniciado por el proveedor de identidades, incluidos los superadministradores.

Minimizar el conjunto de atributos transmitidos en las aserciones SAML

Una vez que un usuario se ha autenticado en el proveedor de identidades externo, Cloud Identity o Google Workspace usan la aserción SAML que ha enviado el proveedor de identidades 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 Google Workspace que corresponde al valor NameID de la aserción SAML.

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

Para evitar errores ortográficos o de uso de mayúsculas y minúsculas, lo mejor es aprovisionar automáticamente las cuentas de usuario.

Las aserciones SAML pueden contener atributos adicionales, pero no se tienen en cuenta durante la autenticación. Los atributos que contienen información como el nombre, los apellidos o las pertenencias a grupos de un usuario se ignoran porque la cuenta del usuario en Cloud Identity o Google Workspace se considera la única fuente de esta información.

Para minimizar el tamaño de las aserciones SAML, configura tu proveedor de identidades para que no incluya ningún atributo que no sea obligatorio para el inicio de sesión con Google.

Usar google.com como emisor

Las sesiones de inicio de sesión con Google no están restringidas a una sola herramienta o dominio. En su lugar, una vez que se ha establecido una sesión, esta es válida en todos los servicios de Google a los que el usuario haya obtenido acceso. Esta lista de servicios puede incluir servicios como Google Cloud y Google Ads, así como servicios como la Búsqueda de Google y YouTube.

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

Para cambiar este valor predeterminado, habilita la opción Usar un emisor específico de un dominio cuando configures el inicio de sesión único en Cloud Identity o Google Workspace. Habilita la opción de emisor específico del dominio solo si tienes más de una cuenta de Cloud Identity o Google Workspace (y, por lo tanto, varios dominios) y tu proveedor de identidades necesita distinguir entre los inicios de sesión iniciados por una cuenta de Cloud Identity o Google Workspace y los iniciados por otra cuenta. Cuando habilitas la opción, las solicitudes SAML usan google.com/a/DOMAIN como emisor y google.com/a/DOMAIN como audiencia, donde DOMAIN es el dominio principal de la cuenta de Cloud Identity o Google Workspace.

En el resto de los casos, mantén el ajuste predeterminado para usar google.com como emisor y configura tu proveedor de identidades externo para que especifique google.com como audiencia en las aserciones SAML. En función de tu proveedor de identidades, este ajuste también puede denominarse emisor, identificador de confianza de la parte verificadora o ID de entidad.

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

Cuando un usuario ha completado el proceso de inicio de sesión único y se ha establecido una sesión, la sesión de inicio de sesión de Google permanece activa durante un periodo determinado. Cuando transcurre este periodo o si el usuario cierra sesión, se le pide que se vuelva a autenticar repitiendo el proceso de inicio de sesión único.

La duración predeterminada de las sesiones de los servicios de Google es de 14 días. En el caso de los usuarios con una licencia de Cloud Identity Premium o Google Workspace Business, puedes cambiar la duración predeterminada de la sesión a otro periodo, como 8 horas.

Puedes controlar la duración de la sesión que usa Google Cloud. La sesión se aplica a la consola, así como a la CLI de Google Cloud y a otros clientes de la API. Google Cloud Google Cloud Puedes definir la duración de la sesión en todos los tipos de cuenta de Cloud Identity y Google Workspace.Google Cloud

La mayoría de los proveedores de identidades externos también mantienen una sesión para los usuarios autenticados. Si la duración de la sesión del IdP es mayor que la de la sesión de Google, es posible que la reautenticación se produzca de forma silenciosa. Es decir, se redirige al usuario al IdP, pero es posible que no tenga que volver a introducir las credenciales. La reautenticación silenciosa podría menoscabar el objetivo de acortar la duración de las sesiones de Google.

Para asegurarte de que los usuarios tengan que volver a introducir sus credenciales cuando caduque una sesión de Google, configura la duración de la sesión de Google y la duración de la sesión del IdP de forma que la duración de la sesión del IdP sea inferior a la de la sesión de Google.

Inhabilitar el inicio de sesión único para usuarios superadministradores

Para los usuarios superadministradores, el SSO es opcional: pueden usar el SSO cuando el IdP inicia la sesión, pero también pueden iniciar sesión con su nombre de usuario y contraseña.

Si no tienes previsto usar el inicio de sesión único iniciado por el IdP para los usuarios superadministradores, puedes reducir el riesgo siguiendo este procedimiento:

  1. Añade una unidad organizativa específica para los superadministradores.
  2. Asigna un perfil de SSO a la unidad organizativa que inhabilite el inicio de sesión único.

De lo contrario, si tienes previsto usar el inicio de sesión único iniciado por el proveedor de identidades, asegúrate de aplicar la verificación posterior al SSO a los usuarios superadministradores.

Autenticación multifactor

Si habilitas el inicio de sesión único entre Cloud Identity o Google Workspace y tu proveedor de identidades externo, mejorarás la experiencia de los empleados. Los usuarios tienen que autenticarse con menos frecuencia y no necesitan memorizar credenciales independientes para acceder a los servicios de Google.

Sin embargo, permitir que los usuarios se autentiquen fácilmente en diferentes servicios y entornos también significa que aumenta el impacto potencial de las credenciales de usuario vulneradas. Si se pierden o roban el nombre de usuario y la contraseña de un usuario, un atacante podría usar estas credenciales para acceder a recursos no solo en tu entorno, sino también en uno o varios servicios de Google.

Para reducir el riesgo de robo de credenciales, lo mejor es usar la autenticación multifactor en todas las cuentas de usuario.

Implementar la autenticación multifactor de manera obligatoria para los usuarios

Cuando hayas configurado el inicio de sesión único para tu cuenta de Cloud Identity o Google Workspace, los usuarios que no tengan privilegios de superadministrador deberán usar tu proveedor de identidades externo para autenticarse.

Configura tu IdP para que requiera el uso de un segundo factor (como un código de un solo uso o una llave USB) para aplicar la autenticación multifactor siempre que se utilice el inicio de sesión único en Google.

Si tu IdP externo no admite la autenticación multifactor, te recomendamos que habilites la verificación posterior al SSO para que Google realice una verificación adicional después de que el usuario vuelva de autenticarse con tu IdP externo.

No utilices máscaras de red, ya que se podrían usar de forma inadecuada para eludir la autenticación multifactor de los usuarios.

Aplicar la autenticación en dos pasos de Google a los usuarios superadministradores

Los usuarios superadministradores no se redirigen a tu IdP externo cuando intentan iniciar sesión en la consola de administración Google Cloud u otros sitios de Google. En su lugar, se pide a los usuarios superadministradores que se autentiquen con un nombre de usuario y una contraseña.

Como los usuarios con permisos de superadministrador pueden autenticarse con un nombre de usuario y una contraseña, no están sujetos a ninguna política de autenticación de varios factores que pueda aplicar tu proveedor de identidades. Para proteger a los superadministradores, aplica la verificación en dos pasos de Google a todos los superadministradores.

Los usuarios superadministradores suelen pertenecer a una de estas dos categorías:

  • Usuarios superadministradores personalizados: estos usuarios están personalizados y están pensados para que los use un solo administrador. Te recomendamos que apliques la verificación en dos pasos obligatoria a todos los usuarios superadministradores personalizados.

  • Usuarios superadministradores de máquinas: aunque es mejor evitar estas cuentas de usuario, a veces son necesarias para habilitar herramientas como Cloud Directory Sync o la aplicación de galería de Entra ID para gestionar usuarios y grupos en Cloud Identity o Google Workspace.

    Limita el número de usuarios superadministradores de la máquina e intenta habilitar la verificación en dos pasos siempre que sea posible.

En el caso de los usuarios que no utilizan el inicio de sesión único, puedes implementar obligatoriamente la autenticación en dos pasos en ambas cuentas de forma global, por unidad organizativa o por grupo:

  • Si no tienes ningún usuario superadministrador de máquina que no pueda usar la verificación en dos pasos, lo mejor es activar la implementación obligatoria para todos los usuarios. Si exiges la verificación en dos pasos a todos los usuarios, evitarás el riesgo de que se te pasen por alto algunos por error.

  • Si tienes algunos usuarios superadministradores de máquinas que no pueden usar la verificación en dos pasos, utiliza un grupo específico para controlarla. Crea un grupo, activa la aplicación en ese grupo y añade a todos los superusuarios pertinentes.

Para obtener más información sobre cómo usar la autenticación en dos pasos para proteger las cuentas de superadministrador, consulta nuestras prácticas recomendadas de seguridad para proteger cuentas de administrador.

Aplicar la verificación posterior al SSO a los usuarios superadministradores

Aunque los usuarios con rol de superadministrador no tienen que usar el inicio de sesión único, pueden hacerlo si lo inicia el IdP. Para asegurarte de que los usuarios superadministradores siempre estén sujetos a la verificación en dos pasos, aunque se autentiquen mediante el inicio de sesión iniciado por el proveedor de identidades, activa verificaciones adicionales de SSO y la verificación en dos pasos para todos los usuarios superadministradores.

Las verificaciones adicionales del SSO pueden parecer redundantes en los casos en los que tu IdP ya aplique la autenticación multifactor, pero este ajuste puede ayudar a proteger a los usuarios superadministradores si tu IdP se ve comprometido.

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

Cuando configuras el inicio de sesión único en Cloud Identity o Google Workspace, puedes especificar opcionalmente una máscara de red. Si especificas una máscara, solo los usuarios que tengan direcciones IP que coincidan con la máscara podrán usar el inicio de sesión único. A los demás usuarios se les pedirá una contraseña cuando inicien sesión.

Si usas máscaras de red, es posible que estés debilitando la autenticación multifactor que aplica tu proveedor de identidades externo. Por ejemplo, si un usuario cambia de ubicación o usa una VPN, puede controlar si se aplica o no la máscara de red. Si implementas la autenticación multifactor en el IdP externo, esta táctica podría permitir que un usuario o un atacante eluda las políticas de autenticación multifactor configuradas en tu IdP externo.

Para asegurarte de que la autenticación multifactor se aplica de forma coherente independientemente de la ubicación o la dirección IP de un usuario, no restrinjas el inicio de sesión único por máscara de red.

Para restringir el acceso a los recursos por dirección IP, configura una lista de permitidos de IPs adecuada en tu proveedor de identidades externo o usa acceso contextual Google Cloud y Google Workspace.

Siguientes pasos