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 este documento, se explica el modelo de dominio en el que se basa el Acceso con Google para la autenticación y la administración de identidades. El modelo de dominio te ayuda a comprender cómo funciona el Acceso con Google en un contexto corporativo, cómo se administran las identidades y cómo puedes facilitar la integración con un proveedor de identidad (IdP) externo. En el siguiente diagrama, se muestra cómo interactúan estas entidades.
Como se muestra en este diagrama, en el centro del modelo se encuentra la identidad de Google, que usa el Acceso con Google. La identidad de Google está relacionada con otras entidades relevantes en el contexto de la administración de identidades:
- Google para consumidores contiene las entidades que son relevantes para el uso enfocado en los clientes de los servicios de Google, como Gmail.
- Google para organizaciones contiene entidades administradas por Cloud Identity o Google Workspace. Estas entidades son las más relevantes para administrar las identidades corporativas.
- Google Cloud contiene las entidades específicas deGoogle Cloud.
- Identidades externas contiene entidades relevantes si integras Google a un IdP externo.
Las flechas continuas en el diagrama indican que las entidades se referencian entre sí o se contienen entre sí En cambio, las flechas punteadas indican una relación de federación.
Identidades de Google
Las identidades, los usuarios y las cuentas de usuario desempeñan un papel fundamental en la administración de identidades. Los tres términos tienen una relación estrecha y, a veces, se usan de forma indistinta. Sin embargo, en el contexto de la administración de identidades, vale la pena diferenciar entre los conceptos:
Una identidad es un nombre que identifica de forma exclusiva a la persona que interactúa con un servicio de Google. Google usa direcciones de correo electrónico para este fin. La dirección de correo electrónico de una persona se considera su identidad de Google.
El proceso de verificación de la asociación entre una persona y una identidad se denomina autenticación o acceso, lo que hace que la persona demuestre que esta es en realidad su identidad.
Una persona puede tener varias direcciones de correo electrónico. Debido a que los servicios de Google usan una dirección de correo electrónico como identidad, se considerará que esa persona tiene varias identidades.
Una cuenta de usuario es una estructura de datos que realiza un seguimiento de los atributos, las actividades y las configuraciones que se deben aplicar cuando una identidad determinada interactúa con un servicio de Google. Las cuentas de usuario no se crean sobre la marcha, pero se deben aprovisionar antes del primer acceso.
Las cuentas de usuario se identifican con un ID que no se expone de forma externa. Por lo tanto, las interfaces de usuario o las API requieren que hagas referencia a la cuenta de usuario de forma indirecta según su identidad asociada, como
alice@gmail.com. A pesar de esta indirección, todos los datos y detalles de configuración están asociados con la cuenta de usuario, no con la identidad.
En la mayoría de los casos, existe una relación uno a uno entre las cuentas de usuario y las identidades, lo que facilita la combinación. Sin embargo, este no es siempre el caso, como se ilustra en los siguientes casos extremos:
La relación entre las cuentas de usuario y las identidades no es fija. Puedes cambiar la dirección de correo electrónico principal de una cuenta de usuario, que asocia una identidad diferente con el usuario.
Como administrador de Cloud Identity o Google Workspace, incluso puedes intercambiar las direcciones de correo electrónico principales de dos usuarios. Por ejemplo, si intercambiaste las direcciones de correo electrónico principales de Alice (
alice@example.com) y Bob (bob@example.com), Alice usaría la cuenta de usuario anterior de Bob y Bob usaría la cuenta de usuario anterior de Alice. Debido a que los datos y la configuración están asociados con la cuenta de usuario y no con la identidad, Alice ahora también usaría la configuración y los datos existentes de Bob (y Bob usaría la configuración y los datos de Alice). La siguiente figura muestra esta relación.
En una configuración no federada, también tendrías que restablecer las contraseñas para que Alice y Bob intercambien las cuentas de usuario. En una configuración federada en la que Alice y Bob usan un IdP externo para la autenticación, no sería necesario restablecer las contraseñas.
Es posible que la relación entre la identidad y los usuarios no sea 1:1. Una cuenta personal puede asociarse de forma intencional con varias identidades, como en el siguiente diagrama.
También es posible que una identidad haga referencia a dos cuentas de usuario diferentes. Te recomendamos que evites esta situación, pero puede surgir en el caso de una cuenta de usuario conflictiva. En tal caso, se muestra una pantalla de selección durante la autenticación, en la que se selecciona la cuenta de usuario que se usará.
Google distingue entre dos tipos de cuentas de usuario, las cuentas de usuario personales y las cuentas de usuario administradas. En las siguientes secciones, se explican ambos tipos de cuentas de usuario y las entidades relacionadas con más detalle.
Google para consumidores
Si tienes una dirección de correo electrónico de Gmail como alice@gmail.com, tu cuenta de Gmail es una cuenta personal. Del mismo modo, si usas el vínculo Crear cuenta en la página de Acceso con Google y, durante el registro, proporcionas una dirección de correo electrónico propia personalizada, como alice@example.com, también se genera una cuenta personal.
Cuenta personal
Las cuentas personales se crean por autoservicio y están diseñadas principalmente para fines privados. La persona que creó la cuenta personal tiene el control total de la cuenta y de los datos que se crean con ella. La dirección de correo electrónico que usó esa persona durante el registro se convierte en la dirección de correo electrónico principal de la cuenta personal y funciona como su identidad. Esa persona puede agregar direcciones de correo electrónico a la cuenta personal. Estas direcciones de correo electrónico sirven como identidades adicionales y también se pueden usar para acceder.
Cuando una cuenta personal usa una dirección de correo electrónico principal que corresponde al dominio principal o secundario de una cuenta de Cloud Identity o Google Workspace, la cuenta personal también se conoce como cuenta de usuario no administrada.
Una cuenta personal puede ser miembro de cualquier cantidad de grupos.
Google para organizaciones
Si tu organización usa servicios de Google, es mejor usar cuentas de usuario administradas. Estas cuentas se denominan administradas porque la organización puede controlar por completo el ciclo de vida y la configuración.
Las cuentas de usuario administradas son una función de Cloud Identity y Google Workspace.
Cuenta de Cloud Identity o Google Workspace
Una cuenta de Cloud Identity o Google Workspace es el contenedor de nivel superior para usuarios, grupos, configuración y datos. Una cuenta de Cloud Identity o Google Workspace se crea cuando una empresa se registra en Cloud Identity o Google Workspace y corresponde a la noción de un usuario.
Cloud Identity y Google Workspace comparten una plataforma técnica común. Ambos productos usan el mismo conjunto de API y herramientas administrativas y comparten la noción de una cuenta como contenedor para usuarios y grupos. Ese contenedor se identifica con un nombre de dominio. Con el fin de administrar usuarios, grupos y autenticación, los dos productos pueden considerarse equivalentes en gran medida.
Una cuenta contiene grupos y una o más unidades organizativas.
Unidad organizativa
Una unidad organizacional (UO) es un subcontenedor para cuentas de usuario que te permite segmentar las cuentas de usuario definidas en la cuenta de Cloud Identity o Google Workspace en conjuntos inconexos para facilitar su administración.
Las unidades organizacionales se organizan de forma jerárquica. Cada cuenta de Cloud Identity o Google Workspace tiene una UO raíz, en la que puedes crear más UO según sea necesario. También puedes anidar tus UO.
Cloud Identity y Google Workspace te permiten aplicar ciertas configuraciones por UO, como la asignación de licencias o la verificación en 2 pasos. Esta configuración se aplica de forma automática a todos los usuarios de la UO y también la heredan las UO secundarias. Por lo tanto, las unidades organizativas tienen una función clave en la administración de Cloud Identity y la configuración del Google Workspace.
Una cuenta de usuario no puede pertenecer a más de una UO, lo que diferencia a las UO de los grupos. Aunque las UO son útiles para aplicar la configuración a las cuentas de usuario, no están diseñadas para administrar el acceso. Para administrar el acceso, te recomendamos usar grupos.
Aunque las UO se parecen a las carpetas deGoogle Cloud , las dos entidades tienen propósitos diferentes y no están relacionadas entre sí.
Cuenta de usuario administrada
Las cuentas de usuario administradas funcionan de manera similar a las cuentas de usuario personalizadas, pero los administradores de la cuenta de Cloud Identity o Google Workspace pueden controlarlas por completo.
La identidad de una cuenta de usuario administrada se define por su dirección de correo electrónico principal.
La dirección de correo electrónico principal debe usar un dominio que corresponda a uno de los dominios principales, secundarios o de alias agregados a la cuenta de Cloud Identity o de Google Workspace. Las cuentas de usuario administradas pueden tener direcciones de correo electrónico de alias adicionales y una dirección de correo electrónico de recuperación, pero estas direcciones no se consideran identidades y no se pueden usar para acceder. Por ejemplo, si Alice usa alice@example.com como su dirección de correo electrónico principal y configuró ally@example.com como una dirección de correo electrónico de alias y alice@gmail.com como dirección de correo de recuperación, la única dirección de correo electrónico que Alice puede usar para acceder es alice@example.com.
Las cuentas de usuario administradas están dentro de una unidad organizativa y pueden formar parte de cualquier cantidad de grupos.
Las cuentas de usuario administradas están diseñadas para que las usen usuarios humanos, no usuarios de máquinas. Una cuenta de usuario de máquina es un tipo especial de cuenta que usa una aplicación o una instancia de máquina virtual (VM), no una persona. Para los usuarios de máquinas,Google Cloud proporciona cuentas de servicio. (las cuentas de servicio se analizan con más detalle más adelante en este documento).
Grupo
Los grupos te permiten agrupar a varios usuarios. Puedes usar grupos a fin de administrar una lista de distribución o para aplicar un control de acceso o una configuración comunes a varios usuarios.
Cloud Identity y Google Workspace identifican grupos por dirección de correo electrónico, por ejemplo, billing-admins@example.com. Al igual que la dirección de correo electrónico principal del usuario, la dirección de correo electrónico del grupo debe usar uno de los dominios principales, secundarios o de alias de la cuenta de Cloud Identity o de Google Workspace. No es necesario que la dirección de correo electrónico corresponda a un buzón, a menos que el grupo se use como lista de distribución. La autenticación aún se realiza con el correo electrónico del usuario en lugar del correo electrónico del grupo, por lo que el usuario no puede acceder con una dirección de correo electrónico de grupo.
Un grupo puede tener las siguientes entidades como miembros:
- Usuarios (usuarios administrados o cuentas personales)
- Otros grupos
- Cuentas de servicio
A diferencia de una unidad organizativa, los grupos no actúan como un contenedor:
- Un usuario o grupo puede ser miembro de cualquier cantidad de grupos, no solo de uno.
- Borrar un grupo no borra ninguno de los usuarios o grupos miembros.
Los grupos pueden contener miembros de cualquier cuenta de Cloud Identity o Google Workspace, así como cuentas personales. Puedes usar el parámetro de configuración no permitir miembros externos a tu organización para restringir los miembros a cuentas de usuario de la misma cuenta de Cloud Identity o Google Workspace.
Identidades externas
Mediante la federación de una cuenta de Cloud Identity o de Google Workspace con un IdP externo, puedes permitir a los empleados usar su identidad y credenciales existentes para acceder a los servicios de Google.
En el nivel más básico, la federación implica configurar el inicio de sesión único con SAML, que vincula las identidades en Cloud Identity o Google Workspace con las identidades administradas por tu IdP externo. A fin de vincular una identidad como alice@example.com y habilitarla para el inicio de sesión único en Google, debes cumplir con dos requisitos:
- Tu IdP externo debe reconocer la identidad
alice@example.comy permitir que se use para el inicio de sesión único. - Tu cuenta de Cloud Identity o Google Workspace debe contener una cuenta de usuario que use
alice@example.comcomo su identidad. Esta cuenta de usuario debe existir antes del primer intento de inicio de sesión único.
En lugar de crear y mantener de forma manual cuentas de usuario en Cloud Identity o Google Workspace, puedes automatizar el proceso si combinas el inicio de sesión único basado en SAML con el aprovisionamiento automático de usuarios. La idea del aprovisionamiento automático de usuarios es sincronizar todos o un subconjunto de los usuarios y grupos de una fuente autorizada externa o Google Workspace.
Según tu elección de IdP, el inicio de sesión único basado en SAML y el aprovisionamiento automático de usuarios pueden manejarse con el mismo componente de software o pueden requerir componentes diferentes. Por lo tanto, el modelo de dominio distingue entre un proveedor de identidad SAML y una fuente autorizada externa.
Proveedor de identidad SAML externo
El IdP externo es el único sistema de autenticación y proporciona una experiencia de inicio de sesión único para tus empleados que abarca aplicaciones. Es externo a Google y, por lo tanto, se lo conoce como un proveedor de identidad externo.
Cuando configuras el inicio de sesión único, Cloud Identity o Google Workspace retransmiten las decisiones de autenticación a un IdP de SAML. En términos de SAML, Cloud Identity o Google Workspace actúan como un proveedor de servicios que confía en el IdP de SAML para verificar la identidad del usuario en su nombre.
Los IdP externos que se usan con frecuencia incluyen los Servicios de federación de Active Directory (AD FS), el ID de Entra, Okta o Ping Identity.
Fuente autorizada externa
La fuente autorizada para las identidades es el único sistema que usas a fin de crear, administrar y borrar identidades para tus empleados. Es externo a Google y, por lo tanto, se la conoce como una fuente autorizada externa.
Desde la fuente autorizada externa, las cuentas de usuario y los grupos se pueden aprovisionar de forma automática en Cloud Identity o Google Workspace. El aprovisionamiento puede ser manejado por la fuente autorizada o mediante middleware de aprovisionamiento.
Para que el aprovisionamiento automático de usuarios sea eficaz, los usuarios deben aprovisionarse con una identidad que reconozca tu IdP de SAML. Si asignas identidades entre las identidades (por ejemplo, si asignas la identidad alice@example.com en Cloud Identity o Google Workspace a u12345@corp.example.com en tu IdP de SAML), entonces el IdP de SAML y el middleware de aprovisionamiento debe realizar la misma asignación.
Cuenta de usuario externa
Se supone que los proveedores de identidad externos tienen el concepto de una cuenta de usuario que realiza un seguimiento del nombre, los atributos y la configuración.
Se espera que la fuente autorizada (o el middleware de aprovisionamiento) aprovisione todas las cuentas de usuario externas a Cloud Identity o Google Workspace (o un subconjunto de ellas) para facilitar una experiencia de inicio de sesión. En muchos casos, es suficiente propagar solo un subconjunto de los atributos del usuario (como la dirección de correo electrónico, el nombre y el apellido) a Cloud Identity o Google Workspace para limitar la redundancia de datos.
Grupo externo
Si tu IdP externo admite la noción de un grupo, de manera opcional, puedes mapear estos grupos a grupos en Cloud Identity o G Suite.
La asignación y el aprovisionamiento automático de grupos son opcionales y no se requieren para el inicio de sesión único, pero ambos pasos pueden ser útiles si deseas volver a usar grupos existentes para controlar el acceso en Google Workspace o Google Cloud.
Google Cloud
Al igual que otros servicios de Google, Google Cloud se basa en el Acceso con Google para autenticar a los usuarios. Google Cloud también se integra estrechamente con Google Workspace y Cloud Identity para permitirte administrar los recursos de manera eficiente.
Google Cloud introduce la noción de nodos de organización, carpetas y proyectos. Estas entidades se usan principalmente para administrar el acceso y la configuración, por lo que solo son relevantes en la administración de identidades. Sin embargo, Google Cloud también incluye un tipo adicional de cuenta de usuario: las cuentas de servicio. Las cuentas de servicio pertenecen a proyectos y desempeñan un papel fundamental en la administración de identidades.
Nodo de la organización
Una organización es el nodo raíz en la jerarquía de recursos deGoogle Cloud y un contenedor para proyectos y carpetas. Las organizaciones te permiten estructurar los recursos de forma jerárquica y son clave para administrarlos de manera central y eficiente.
Cada organización pertenece a una sola cuenta de Cloud Identity o Google Workspace. El nombre de la organización deriva del nombre de dominio principal de la cuenta de Cloud Identity o Google Workspace correspondiente.
Carpeta
Las carpetas son nodos en la jerarquía de recursos de Google Cloud y pueden contener proyectos, otras carpetas o una combinación de ambos. Usas carpetas para agrupar recursos que comparten políticas de Identity and Access Management (IAM) o políticas de la organización comunes. Estas políticas se aplican de forma automática a todos los proyectos de la carpeta y también las heredan las carpetas secundarias.
Las carpetas son similares a las unidades organizativas pero no están relacionadas con ellas. Las unidades organizativas te ayudan a administrar usuarios y a aplicarles políticas o parámetros de configuración comunes, mientras que las carpetas te ayudan a administrar proyectos de Google Cloud y a aplicarles políticas o parámetros de configuración comunes.
Proyecto
Un proyecto es un contenedor de recursos. Los proyectos desempeñan un papel fundamental en la administración de las API, la facturación y la administración del acceso a los recursos.
En el contexto de la administración de identidades, los proyectos son relevantes porque son los contenedores para las cuentas de servicio.
Cuenta de servicio
Una cuenta de servicio (o Google Cloud cuenta de servicio) es un tipo especial de cuenta de usuario destinada a aplicaciones y otros tipos de usuarios de máquinas.
Cada cuenta de servicio pertenece a un Google Cloud proyecto. Al igual que con las cuentas de usuario administradas, los administradores pueden controlar por completo el ciclo de vida y la configuración de una cuenta de servicio.
Las cuentas de servicio también usan una dirección de correo electrónico como su identidad, pero, a diferencia de las cuentas de usuario administradas, la dirección de correo electrónico siempre usa un dominio de Google, como developer.gserviceaccount.com.
Las cuentas de servicio no participan en la federación y tampoco tienen una contraseña. En Google Cloud, usas IAM para controlar el permiso que tiene una cuenta de servicio para un recurso de procesamiento, como una máquina virtual (VM) o una función de Cloud Run, lo que quita la necesidad de administrar credenciales. Fuera de Google Cloud, puedes usar claves de cuenta de servicio para permitir que una aplicación se autentique con una cuenta de servicio.
Cuenta de servicio de Kubernetes
Las cuentas de servicio de Kubernetes son un concepto de Kubernetes y son relevantes cuando usas Google Kubernetes Engine (GKE). Al igual que las cuentas de servicio de Google Cloud , las cuentas de servicio de Kubernetes están diseñadas para que las usen las aplicaciones, no las personas.
Las cuentas de servicio de Kubernetes se pueden usar para autenticar cuando una aplicación llama a la API de Kubernetes de un clúster de Kubernetes, pero no se pueden usar fuera del clúster. Ninguna API de Google las reconoce y, por lo tanto, no reemplazan una cuenta de servicio de Google Cloud .
Cuando implementas una aplicación como un Pod de Kubernetes, puedes asociar el Pod con una cuenta de servicio. Esta asociación permite que la aplicación use la API de Kubernetes sin tener que configurar o mantener certificados o credenciales.
Con Workload Identity, puedes vincular una cuenta de servicio de Kubernetes a una cuenta de servicio de Google Cloud . Este vínculo también permite que una aplicación se autentique en las API de Google, sin tener que mantener certificados ni otras credenciales.
¿Qué sigue?
- Revisa nuestras arquitecturas de referencia para la administración de identidades.