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 guía se basa 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, se basan en el Acceso con Google para autenticar a los usuarios. En lugar de crear y mantener de forma manual las cuentas de usuario en Cloud Identity o en el Google Workspace para cada empleado, puedes federar Cloud Identity o Google Workspace con tu 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:
- Aprovisiona de forma automática las cuentas de usuario relevantes de una fuente autorizada externa a Cloud Identity o Google Workspace.
- 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 Google Workspace 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 tu cuenta de Cloud Identity o Google Workspace.
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 tu IdP externo, debes mapear identidades en tu IdP externo a las identidades correspondientes en Cloud Identity o Google Workspace. En las siguientes secciones, se describen las prácticas recomendadas para establecer esta asignación.
Usa la misma identidad en todos los sistemas federados
Lo único que se requiere para establecer una asignación es verificar que la aserción de SAML que el IdP proporcione a Google contenga una reclamación NameID con un valor que coincida con la dirección de correo electrónico principal de un usuario existente de Cloud Identity o Google Workspace. 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
userPrincipalNameen 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
UserPrincipalNamepara identificar a los usuarios y permitirles que accedan.
Si los usuarios que administra tu IdP externo ya tienen una dirección de correo electrónico como su identidad, puedes usar la misma identidad como la dirección de correo electrónico principal en Cloud Identity o Google Workspace. Usar la misma identidad de usuario en los sistemas federados tiene varias ventajas:
Cuando los usuarios acceden a una herramienta de Google como la consola de Google Cloud, 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 cómo mapear usuarios de Active Directory o usuarios de Azure AD a Cloud Identity o Google Workspace, consulta 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 de proyecto: Si asignas la función de administrador de proyecto a un usuario que forma parte de una cuenta de Cloud Identity o de Google Workspace diferente a la que está asociada con 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 Google Workspace y configuraste correctamente los registros MX de DNS necesarios, todos los correos electrónicos de notificación que se envíen a la dirección de correo electrónico principal se enviarán a la carpeta Recibidos 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 Google Workspace a tu cuenta de Cloud Identity existente y asigna licencias de Google Workspace a los usuarios clave que están a cargo de la facturación o de interactuar 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 tus empleados usaban servicios de Google como Google Ad Manager, Google AdSense o Google Analytics antes de que tu organización se registre en Cloud Identity o Google Workspace, es posible que tus empleados hayan usado cuentas de consumidor 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.
- Para migrar las cuentas a Cloud Identity o Google Workspace, inicia una transferencia.
- 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 Google Workspace.
Asigna conjuntos de identidades
Cuando hayas definido cómo se asignan las identidades individuales entre tu ID externo y Cloud Identity o el lugar de trabajo de Google, debes determinar el conjunto de identidades para 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:
- Identidades externas que se mapean a una identidad en Cloud Identity o Google Workspace.
Identidades externas para las que el IdP externo permite el inicio de sesión único en Cloud Identity o Google Workspace.
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, 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 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 Google Workspace. Si no hay una cuenta de usuario mapeada, fallará cualquier intento de autenticación por parte de un usuario, incluso si el IdP le permite al usuario acceder a Cloud Identity o a Google Workspace con un 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 Google Workspace.
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
Puedes migrar una cuenta personal a Cloud Identity o a un lugar de trabajo de Google solo si no creaste una cuenta de usuario con la misma identidad en Cloud Identity o a Google Workspace.
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 Google Workspace solo para los usuarios que las necesitan y que no tienen una cuenta personal.
- Evita el bloqueo del acceso de las cuentas migradas de forma accidental, ya que permite el inicio de sesión único no solo para los usuarios para los que creas cuentas de usuario en Cloud Identity o Google Workspace, sino también 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.
En el diagrama, las identidades con una cuenta de usuario en Cloud Identity o Google Workspace 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
Agregar un dominio como example.com a tu cuenta de Cloud Identity o de Google Workspace no impide que los empleados se registren en nuevas cuentas personales con el mismo dominio. Estas cuentas personales nuevas se muestran como usuarios no administrados 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 a tu cuenta de Cloud Identity o de Google Workspace.
Una forma de bloquear la creación de una cuenta personal nueva es crear una cuenta de usuario en Cloud Identity o Google Workspace con la misma dirección de correo electrónico. Por ejemplo, si creaste un usuario alice@example.com en tu cuenta de Cloud Identity o de Google Workspace, fallarán todos los intentos de un empleado para registrarse en una cuenta personal nueva con la misma identidad. Sin embargo, si aún no existe un usuario correspondiente en Cloud Identity o Google Workspace, se registrará una cuenta personal nueva.
Cuando no haya más cuentas personales para migrar a Cloud Identity, aplica la siguiente configuración a fin de evitar registros en cuentas personales nuevas.
Para limitar la autenticación, debes permitir que solo los usuarios relevantes usen el inicio de sesión único en Cloud Identity o Google Workspace.
Aprovisiona usuarios de Cloud Identity o de Google Workspace 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.
Si aún te encuentras en el proceso de migración de cuentas personales, puedes supervisar de forma temporal los registros de nuevas cuentas personales mediante la recopilación de los correos electrónicos de verificación enviados durante el proceso de registro. Los mensajes de verificación usan una dirección de remitente del sobre que coincide con *@idverification.bounces.google.com.
Configura un filtro en tu sistema de correo electrónico que identifique los correos electrónicos con esta dirección de remitente del sobre y los retenga para una revisión interna.
Haz que las identidades de Google Workspace o Cloud Identity sean un subconjunto de identidades de tu IdP externo.
Tu cuenta de Cloud Identity o Google Workspace puede contener cuentas de usuario con identidades que no se mapean a ningún usuario en tu IdP externo. Existen dos situaciones típicas que pueden dar lugar a estas cuentas de usuario:
- Debes crear una cuenta de usuario nueva en Cloud Identity o Google Workspace, y usar una dirección de correo electrónico principal que no se mapee a ningún usuario en tu IdP externo.
- Tienes una cuenta de usuario en Cloud Identity o Google Workspace que se mapea a una identidad en tu IdP externo, pero luego borras la identidad 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 Google Workspace, todos los usuarios (excepto los administradores avanzados) deben usar el inicio de sesión único. Para una cuenta de usuario de Cloud Identity o Google Workspace que no se mapea a una identidad en tu IdP externo, fallará cualquier intento de inicio de sesión único. 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 Google Workspace. 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 Google Workspace 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 Google Workspace, y no usa la verificación de 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 control de nombres, asegúrate de que tus identidades de Cloud Identity o Google Workspace sean un subconjunto de las identidades en tu IdP externo. La mejor manera de lograrlo es mapear el ciclo de vida completo de la cuenta de usuario que implementó tu IdP externo al ciclo de vida de la cuenta de usuario en Cloud Identity o Google Workspace.
Usa usuarios administradores avanzados dedicados
Las cuentas de administrador avanzado de Cloud Identity y Google Workspace tienen un poderoso conjunto de permisos que se aplican no solo a la cuenta de Cloud Identity o Google Workspace, sino también a una organización asociada de Google Cloud. 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.comy 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.comy asígnale privilegios de superusuario. Se recomienda usar esta cuenta solo para ocasiones en las que se requieren privilegios de administrador avanzado.Para garantizar que se reciban correos electrónicos de notificación que se envíen a esta dirección de correo electrónico en el buzón del usuario, configura Google Workspace o tu sistema de correo electrónico existente para que la dirección de correo electrónico
alice-admin@example.comsea un alias o se reenvíe aalice@example.com.
Asegúrate de que tu IdP externo reconozca ambas identidades para que el conjunto de identidades en Cloud Identity o Google Workspace siga siendo un subconjunto de las identidades en tu 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 Google Workspace 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 realizarse 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 a la cuenta de servicio acceso a los recursos mediante IAM.
Si las cuentas de servicio de Google Cloud reciben las funciones adecuadas en IAM, se pueden utilizar 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 a la API de Drive, puedes usar la delegación de todo el dominio de Google Workspace.
Con la delegación de todo el dominio de Google Workspace, habilitas una cuenta de servicio para que actúe en nombre de un usuario de Cloud Identity o de Google Workspace. Debido a que la delegación es un gran privilegio, te recomendamos que uses la delegación de todo el dominio de Google Workspace solo en casos en los que el enfoque de OAuth no sea práctico.
Usa un usuario dedicado de Cloud Identity o Google Workspace para cada cuenta de servicio de Google Cloud habilitada para la delegación de todo el dominio de Google Workspace. Crea este usuario en tu IdP externo y, luego, aprovisionarlo en Cloud Identity o Google Workspace para que el conjunto de usuarios en Cloud Identity o Google Workspace siga siendo un subconjunto de usuarios en tu IdP externo.
Evita crear usuarios de servicio en Cloud Identity y en Google Workspace que no quieras usar para la delegación de todo el dominio de Google Workspace.
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:
- Se crea una cuenta de usuario nueva para un empleado que se une a la organización.
- La cuenta de usuario podría suspenderse de forma temporal y reactivarse más tarde, por ejemplo, cuando el empleado se ausente.
- 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.
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 Google Workspace sigue el ciclo de vida de las cuentas de usuario correspondientes en tu 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 que se realizan en el HRIS o IdP se propagan a Cloud Identity o Google Workspace, pero los cambios realizados en Cloud Identity o Google Workspace no se propagan.
Para evitar incoherencias causadas por el aprovisionamiento unidireccional, designa el IdP externo como la fuente de información. Usa el IdP externo (o HRIS) de forma exclusiva para crear, modificar o borrar usuarios, y confía en el aprovisionamiento automatizado para que los cambios se propaguen a Google Workspace y a 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 Google Workspace.
Para permitir que un empleado se autentique en Google con el inicio de sesión único, primero debes crear una cuenta de usuario para el empleado en Cloud Identity o Google Workspace. Para garantizar la coherencia con tu IdP externo, es mejor automatizar el proceso de aprovisionamiento de estas cuentas de usuario en Cloud Identity o Google Workspace:
- Si automatizas el aprovisionamiento, puedes asegurarte de que las identidades de Cloud Identity o Google Workspace 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 Google Workspace 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 un HRIS a fin de administrar el proceso de integración, una forma de automatizar el aprovisionamiento de usuarios es configurar el HRIS para aprovisionar cuentas de usuario tanto en tu IdP externo como en Cloud Identity o Google Workspace, como en el siguiente diagrama.
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 controlar la decisión de qué cuentas de usuario aprovisionar a Cloud Identity o Google Workspace.
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 Google Workspace. 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.
Si usas Active Directory como tu IdP, puedes duplicar esta configuración mediante Google Cloud Directory Sync. Otros IdP, como Azure AD u Okta, tienen adaptadores integrados para aprovisionar usuarios a Google Workspace. Dado que Google Workspace 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 Google Workspace
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 Google Workspace tiene una sesión de navegador activa, la sesión seguirá 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 lugar de trabajo de Google asignada, los correos electrónicos se seguirán entregando al buzón del usuario, este aparecerá en la libreta de direcciones y es posible que el usuario todavía aparezca como disponible en el Calendario de Google.
- Si permites que los usuarios usen apps menos seguras, es posible que el usuario aún pueda acceder a Gmail, Calendario de Google 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 Google Workspace 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 Google Workspace. La suspensión de un usuario en Cloud Identity o Google Workspace finaliza las sesiones activas del navegador, invalida los tokens y revoca todos los otros accesos.
Del mismo modo, cuando reactives una cuenta de usuario en tu IdP externo, asegúrate de volver a activar la cuenta de usuario correspondiente en Cloud Identity o Google Workspace.
La suspensión de una cuenta de usuario en Cloud Identity o Google Workspace no es una operación destructiva. Mientras la cuenta de usuario está suspendida, los datos del usuario se conservan, las licencias de Google Workspace permanecen conectadas y no se modifican las funciones asignadas en Google Cloud.
Propaga eventos de eliminación a Cloud Identity o Google Workspace
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 tu IdP externo, pero no borras el usuario de Cloud Identity o Google Workspace correspondiente, el conjunto de usuarios en Cloud Identity y Google Workspace no es un subconjunto de los usuarios de tu IdP externo. 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 tu IdP para el empleado nuevo, puedes volver a usar el nombre de usuario del empleado anterior y hacer que la cuenta de usuario nueva se mapee a la cuenta de usuario anterior en Cloud Identity o Google Workspace. Como resultado, el empleado nuevo podría obtener acceso a los datos y la configuración del empleado anterior.
Puedes evitar los riesgos asociados con las cuentas de usuario huérfanas de Cloud Identity o Google Workspace si borras un usuario de Cloud Identity o Google Workspace tan pronto se borre la cuenta de usuario correspondiente en tu IdP.
Borrar un usuario de Cloud Identity o Google Workspace 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 al usuario en el IdP y en Cloud Identity/Google Workspace una vez que haya finalizado el período de retención.
Cuando borres una cuenta de usuario en tu IdP externo, suspende al usuario correspondiente de Cloud Identity o Google Workspace, y cambia su dirección de correo electrónico principal por un nombre que probablemente provoque un conflicto. Por ejemplo, cambia el nombre de
alice@example.comaobsolete-yyyymmdd-alice@example.com, en el queyyyymmddrefleja 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 del lugar de trabajo de Google para los usuarios suspendidos, conserva la licencia de Google Workspace asignada al usuario o cámbiala a una licencia de usuario archivado para asegurarte de que las reglas de retención de Google Workspace Vault continúan aplicándose y que se conservan 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, el directorio de la cuenta de consumidor o si el dominio coincide con su dominio principal, secundario o de alias, en una cuenta de Cloud Identity o de Google Workspace.
En el siguiente diagrama, se ilustra este proceso de autenticación.
Si configuras una cuenta de Cloud Identity o Google Workspace 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 Google Workspace, 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 SAML
Después de que un usuario se autentica en el IdP externo, Cloud Identity o Google Workspace 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 Google Workspace que corresponde al valor 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 de un usuario se ignoran porque la cuenta del usuario en Cloud Identity o Google Workspace se considera la única fuente de información sobre este 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 Google Workspace. Habilita la opción de entidad emisora específica del dominio solo si tienes más de una cuenta de Cloud Identity o de Google Workspace (y, en consecuencia, varios dominios) y tu IdP debe poder distinguir entre los inicios de sesión iniciados por una cuenta de Cloud Identity o de Google Workspace en comparación con otra cuenta. Cuando habilitas la opción, las solicitudes de SAML usan google.com/a/DOMAIN como el emisor y esperan google.com/a/DOMAIN como público, en el que DOMAIN es el dominio principal de la cuenta de Cloud Identity o Google Workspace.
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 Google Workspace 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 la consola de Google Cloud se aplica a la consola de Google Cloud, a la CLI de Google Cloud 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 Google Workspace.
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.
Inhabilita el inicio de sesión único para usuarios administradores avanzados
Para los usuarios administradores avanzados, el SSO es opcional: pueden usar el SSO cuando el IdP lo inicia, pero también pueden acceder mediante el nombre de usuario y la contraseña.
Si no planeas usar el inicio de sesión único iniciado por IdP para los usuarios administradores avanzados, puedes disminuir el riesgo mediante el siguiente procedimiento:
- Agrega una unidad organizacional dedicada a los administradores avanzados.
- Asigna un perfil de SSO a la unidad organizacional que inhabilita el inicio de sesión único.
De lo contrario, si planeas usar el inicio de sesión único iniciado por IdP, asegúrate de aplicar la verificación posterior al SSO para usuarios administradores avanzados.
Autenticación de varios factores
Habilitar el inicio de sesión único entre Cloud Identity o Google Workspace 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 hayas configurado el inicio de sesión único para tu cuenta de Cloud Identity o Google Workspace, los usuarios sin privilegios de administrador avanzado deben usar tu IdP externo para realizar 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 usuarios con acceso de administrador avanzado
No se redirecciona a los usuarios de administradores avanzados a tu IdP externo cuando intentan acceder a la consola de Google Cloud o a otros sitios de Google. En cambio, se solicita a los usuarios avanzados que realicen la autenticación por nombre de usuario y contraseña.
Debido a que los usuarios de administrador avanzado pueden autenticarse mediante el nombre de usuario y la contraseña, no están sujetos a ninguna política de autenticación de varios factores que la IdP pueda aplicar. A fin de proteger a los usuarios de administradores avanzados, aplica la autenticación en dos pasos de Google para todos los usuarios con administradores avanzados.
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 de administradores avanzados de máquinas: Aunque es mejor evitar estas cuentas de usuario, a veces es necesario habilitar herramientas como Cloud Directory Sync o la aplicación de la galería de Azure AD para administrar usuarios y grupos en Cloud Identity o Google Workspace.
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 de administradores avanzados, consulta las prácticas recomendadas de seguridad para las cuentas de administrador.
Aplica la verificación posterior a SSO para los usuarios con acceso de administrador avanzado
Aunque no es necesario que los usuarios avanzados administren el inicio de sesión único, sí se les permite usar el inicio de sesión único cuando lo inicie el IdP. A fin de garantizar que los usuarios de administradores avanzados siempre estén sujetos a la verificación en dos pasos, incluso si los autentican mediante el inicio de sesión iniciado por el IdP, activa las verificaciones de SSO adicionales y la verificación en dos pasos para todos los usuarios avanzados.
Las verificaciones de SSO adicionales pueden parecer redundantes en los casos en que tu IdP ya impone una autenticación de varios factores, pero la configuración puede ayudar a proteger a los usuarios de administrador avanzado si el IdP se ve comprometido.
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 Google Workspace, puedes especificar una máscara de red en forma opcional. 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.
Para restringir el acceso a los recursos según la dirección IP, configura una lista permitida de IP en tu IdP externo o usa el acceso adaptado al contexto para Google Cloud y Google Workspace.
¿Qué sigue?
- Obtén información sobre prácticas recomendadas adicionales:
- Compara los patrones para federar un IdP externo con Google Cloud.