Prácticas recomendadas para usar la federación de identidades del personal

La federación de identidades de personal federa tu organización Google Cloud con un proveedor de identidad (IdP) externo para habilitar el inicio de sesión único (SSO).

Puedes aplicar estas prácticas recomendadas para usar la federación de identidades del personal de manera eficaz y minimizar los riesgos de seguridad.

Cómo elegir la arquitectura adecuada

En las siguientes secciones, se describen los factores clave para elegir una arquitectura de federación que satisfaga tus requisitos.

Consideraciones sobre la arquitectura:

Elige un patrón de arquitectura de federación.
Uso de la federación de particiones por servicio, no por usuario.

Elige un patrón de arquitectura de federación

En los siguientes cuatro patrones, se describen formas comunes de federar una organización de Google Cloudcon un IdP externo:

Antes de federar, considera las ventajas y limitaciones de cada patrón, y elige el que mejor se adapte a tus requisitos. Para obtener más información, consulta los patrones de arquitectura para la federación de identidades.

Uso de la federación de particiones por servicio

En general, te recomendamos que dividas el uso de la federación por servicio, en lugar de por usuario. En general, la división del uso por servicio tiene menos desventajas.

Para reducir la complejidad, te recomendamos que uses Cloud Identity o la federación de identidades del personal. Sin embargo, según tus requisitos, es posible que necesites ambos en paralelo, como se describe en el patrón híbrido.

Si usas la federación de Cloud Identity y la federación de identidades de personal en paralelo, puedes particionar su uso de las siguientes maneras:

  • Partición por usuario: Divide a tus usuarios en dos cohortes: una que use la federación de identidades de personal y otra que use la federación de Cloud Identity.

    • Ventaja: Cada usuario tiene una sola identidad en todos los servicios de Google y un solo método de acceso.

    • Desventajas: La partición por usuarios tiene varias desventajas, incluidas las siguientes:

      • Administrar grupos de acceso puede ser complejo porque las políticas de permiso de IAM deben contener una combinación de tipos de principales y no puedes usar los mismos grupos para los usuarios de Cloud Identity y de la federación de identidades de personal.

      • Los usuarios de diferentes cohortes no pueden compartir vínculos entre sí porque la consola de Google Cloud , Gemini Enterprise y otras herramientas usan URLs diferentes según cómo acceden los usuarios.

      • Es posible que los usuarios de diferentes cohortes tengan acceso a diferentes conjuntos de funciones.

  • Partición por servicio: Configura cada servicio, comoGoogle Cloud o Gemini Enterprise, de modo que otorgue acceso exclusivamente a los usuarios de la federación de identidades de personal o a los usuarios de Cloud Identity, pero nunca a ambos.

    • Ventaja: Simplifica la administración y garantiza un conjunto de funciones coherente para los diferentes usuarios.
    • Desventaja: Es posible que a algunos empleados se les deban asignar dos identidades: una que use la federación de identidades de personal y otra que use Cloud Identity.

Te recomendamos que realices la partición por servicio, y que separes específicamente Gemini Enterprise y NotebookLM Enterprise de otros servicios. Gemini Enterprise y la consola de Google Cloud son herramientas independientes diseñadas para diferentes tareas. Cualquier diferencia en sus procesos de acceso debería tener un impacto mínimo en la experiencia del usuario general.

Para ayudar a aplicar esta partición, usa restricciones de políticas de la organización.

Fortalecer la administración del grupo

Debes administrar el acceso con grupos y establecer procesos claros para controlar esos grupos y usar la federación de identidades de personal de manera eficaz.

Los permisos de un usuario para acceder a los recursos no se determinan durante la autenticación. En cambio, el acceso se evalúa cuando el usuario intenta acceder al recurso según las políticas adjuntas a ese recurso específico. Estas políticas pueden incluir lo siguiente:

Las políticas definen el acceso para principales individuales o conjuntos de principales:

  • Principal: Es un usuario autenticado que se identifica con un identificador principal. Un identificador principal de personal es similar al siguiente: principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

    El identificador principal contiene lo siguiente:

    • POOL_ID: Identifica de forma única un grupo de identidades de personal.
    • SUBJECT: Identifica de forma única a un usuario específico. El valor y el formato dependen de tu IdP y de la asignación de atributos.

  • Conjunto principal: Usuarios que cumplen con criterios específicos. La federación de identidades de personal admite tres conjuntos de principales: basados en grupos (miembros de un grupo), basados en atributos y comodín (todos los usuarios).

Otorgar acceso a principales individuales puede ser útil en situaciones específicas, pero tiende a no escalar bien debido a los siguientes problemas:

  • Agregar principales de a uno hace que las políticas de permisos crezcan y se vuelvan cada vez más difíciles de administrar.
  • La administración de acceso individual requiere cambios frecuentes en las políticas de permiso.
  • Con el tiempo, las políticas pueden volverse cada vez más incoherentes.

Para una administración de acceso eficaz y escalable, el uso de conjuntos de principales basados en grupos proporciona las siguientes ventajas:

  • Puedes administrar el acceso agregando o quitando miembros de los grupos con tus herramientas y procesos de identidad existentes.
  • Reduce el tamaño y la complejidad de las políticas de permiso.
  • Asegúrate de que los usuarios con el mismo rol tengan el mismo acceso a los recursos.

Para usar grupos y administrar el acceso, debes configurar tu IdP externo de ciertas maneras y conocer las limitaciones que impone el IdP en los grupos.

En las siguientes secciones, se describen las prácticas recomendadas para usar grupos de manera eficaz y evitar los límites del IdP.

Recomendaciones:

Distinguir diferentes tipos de grupos
Usa grupos de acceso para otorgar acceso a los recursos.
Usa grupos de aplicación para restringir el acceso a los recursos.
No uses grupos organizativos ni de colaboración para administrar el acceso.
Usa grupos organizativos y grupos de colaboración solo para Gemini Enterprise.

Distinguir diferentes tipos de grupos

En la siguiente lista, se describen cuatro tipos de grupos que se encuentran comúnmente en las organizaciones:

  • Grupos de acceso: Se usan solo para otorgar acceso a los servicios o recursos de Google.Google Cloud Representan las funciones laborales y simplifican la asignación de roles necesarios para realizar estas funciones.
  • Grupos organizacionales: Estos grupos representan subconjuntos de la estructura de una organización y, por lo general, se obtienen de los datos de recursos humanos. Pueden basarse en el departamento, la estructura de informes, la ubicación geográfica o cualquier otra agrupación organizativa.
  • Grupos de colaboración: Estos grupos representan grupos de trabajo, miembros de proyectos o usuarios que desean colaborar en un proyecto o analizar un tema específico, y se pueden usar para la distribución de correos electrónicos. Los grupos de colaboración suelen crearse de forma ad hoc y de autoservicio.
  • Grupos de aplicación: Los grupos de aplicación, también llamados grupos de políticas, se usan para restringir el acceso, a diferencia de los grupos de acceso, que se usan para otorgar acceso. Por ejemplo, límites de acceso de las principales, políticas de denegación o aplicación de la autenticación de varios factores. Los grupos de acceso pueden permitir que los miembros abandonen el grupo de forma voluntaria. Sin embargo, la pertenencia a un grupo de aplicación no es voluntaria.

Los grupos que necesitas federar dependen de los siguientes servicios que usas:

  • Para Google Cloud, solo necesitas grupos de acceso y grupos de aplicación.
  • En el caso de Gemini Enterprise, necesitas grupos de acceso, grupos de aplicación y, si usas conectores basados en la transferencia de datos, ciertos grupos de colaboración y organización.

Cuando configures la federación de identidades de personal, excluye los tipos de grupos irrelevantes para evitar los límites de tokens con tu IdP. Este enfoque te ayuda a reducir el riesgo de superar las limitaciones impuestas por tu IdP y garantiza un uso más coherente de los grupos.

Cómo otorgar acceso a los recursos con grupos de acceso

Para administrar el acceso de manera eficaz, te recomendamos que uses conjuntos de principales que se asignen a grupos de acceso. Los grupos de acceso existen únicamente para brindar acceso. Representan funciones laborales y simplifican la asignación de los roles necesarios para realizar esas funciones.

Para configurar grupos de acceso, haz lo siguiente:

  1. En tu IdP, crea grupos de acceso que representen las funciones laborales.
  2. Asigna los grupos de acceso a conjuntos de principales para usarlos en IAM.
  3. Crea vinculaciones de políticas para otorgar a los conjuntos de principales acceso a los recursos que se necesitan para cada función laboral.
  4. En el IdP externo, agrega o quita usuarios de los grupos según sus funciones laborales.

Usa grupos de acceso para las políticas que otorgan acceso, incluidas las siguientes:

  • Políticas de permisos de IAM
  • Reglas de entrada de los Controles del servicio de VPC

Asegúrate de que los grupos de acceso sean lo suficientemente detallados. Por ejemplo, los siguientes grupos representan grupos de acceso efectivos:

  • widget-sales-dashboard-readers: Otorga acceso de lectura a un conjunto de datos específico de BigQuery y al panel asociado.

  • dev-ssh-users: Otorga acceso de Acceso al SO a las VMs de Compute Engine en el entorno de desarrollo.

    En cambio, los siguientes tipos de grupos no suelen ser adecuados para usarse como grupos de acceso:

    • Los grupos de administradores amplios, como cloud-admins, a menudo carecen de especificidad sobre qué cargas de trabajo o entornos se aplican.

    • Los grupos organizativos, como australia-fte, representan grupos como equipos o ubicaciones, en lugar de funciones laborales.

    • Los grupos de comunicación, como security-discuss, están diseñados para listas de distribución o colaboración por correo electrónico, en lugar de ser grupos de acceso.

    Para mantener la granularidad de los grupos de acceso, crea un nuevo conjunto de grupos de acceso para cada carga de trabajo o proyecto que incorpores a Google Cloud. De esta manera, puedes escalar la cantidad de grupos de acceso a la cantidad de cargas de trabajo que ejecutas en Google Cloud.

Restringe el acceso a los recursos con grupos de aplicación

Los grupos de aplicación son similares a los grupos de acceso, pero suelen diferir en los siguientes aspectos:

  • No permiten que los miembros abandonen el grupo de forma voluntaria.
  • No son específicos de una carga de trabajo.

Usa grupos de aplicación para las políticas que reducen el acceso, incluidas las siguientes:

  • Políticas de denegación de IAM
  • Límites de acceso a las principales
  • Políticas de la organización

Entre los ejemplos de grupos de aplicación, se incluyen users-in-restricted-locations, fedramp-low y mfa-users. La cantidad de grupos de aplicación suele ser pequeña y es poco probable que afecte la cantidad total de membresías a grupos de un usuario.

No uses grupos de colaboración y organización para administrar el acceso

Para administrar el acceso de manera eficaz, puedes usar grupos de acceso y grupos de aplicación en lugar de grupos organizativos o de colaboración.

Los grupos organizativos representan equipos o subconjuntos de la estructura de una organización y, por lo general, se obtienen de los datos de recursos humanos. Estos grupos no son adecuados para administrar el acceso a los recursos de Google Cloud por los siguientes motivos:

  • Las responsabilidades y la composición del equipo pueden cambiar con el tiempo. Por ejemplo, un equipo podría transferir una carga de trabajo a otro equipo, o bien dos equipos podrían fusionarse. Administrar el acceso con grupos organizativos puede requerir una cascada de cambios en las políticas durante estas transiciones.
  • Los miembros de un grupo de la organización rara vez necesitan el mismo acceso a los recursos. Otorgar acceso a un grupo de la organización a menudo les da a algunos miembros más acceso del que necesitan.

Por lo general, los grupos de colaboración se autoadministran, lo que permite que los miembros se unan con la aprobación de otro miembro o sin aprobación. El uso de grupos de colaboración para otorgar acceso puede generar un exceso de permisos y una elevación de privilegios.

Para evitar que los grupos organizativos y de colaboración se usen para la administración de acceso, configura tu IdP de modo que excluya estas membresías de grupo en los tokens o las aserciones que se usan para la federación de identidades de personal.

Usa grupos organizativos y grupos de colaboración solo para Gemini Enterprise

Si bien los grupos de colaboración y de organización no son adecuados para administrar el acceso a los recursos de Google Cloud , es posible que los necesites para Gemini Enterprise:

  • Evaluación de LCA: Cuando usas conectores basados en la transferencia de datos para integrar Gemini Enterprise con Microsoft 365, es posible que encuentres documentos con listas de control de acceso (LCA) que hagan referencia a grupos de colaboración y organizaciones. Si Gemini Enterprise no tiene acceso a las membresías de un usuario en estos grupos, es posible que no evalúe correctamente si el usuario está autorizado para acceder a esos documentos.
  • Compartir cuadernos: NotebookLM permite que los usuarios compartan cuadernos. Permitir que los usuarios compartan notebooks con grupos de colaboración suele ser más conveniente que restringir el uso compartido a usuarios individuales.

Para asegurarte de que los grupos de colaboración y de la organización solo estén disponibles para Gemini Enterprise, puedes configurar tu IdP de la siguiente manera:

  • Usa SCIM para aprovisionar grupos organizacionales y de colaboración, y sus membresías.
  • Excluye las membresías de grupos organizacionales y de colaboración en los tokens o las aserciones que se usan para la federación de identidades de personal.

Administra grupos de identidades del personal

Un grupo de identidades para cargas de trabajo define un espacio de nombres para los identificadores principales y sirve como contenedor para la configuración de la federación. A diferencia de un directorio de usuarios, un grupo no almacena información sobre usuarios o grupos.

Recomendaciones:

Usa un solo grupo por IdP.
Elige un nombre único y significativo para el grupo.
Trata los grupos como recursos con privilegios altos.
Considera los riesgos cuando extiendas la federación a los socios.

Usa un solo grupo por IdP

Los grupos de identidades de trabajo son un recurso a nivel de la organización, no a nivel del proyecto. Este diseño refleja que los grupos de identidades de personal administran la autenticación en una organización Google Cloud , en lugar de un proyecto o una carga de trabajo individuales.

En la mayoría de las organizaciones, la cantidad de grupos de identidades de personal debe coincidir con la cantidad de IdPs:

  • Si tu organización usa un solo IdP para administrar la autenticación, usa un solo grupo de identidades para la fuerza laboral.
  • Si tu organización usa varios IdP (por ejemplo, debido a una adquisición), usa un grupo de identidades para la fuerza laboral por cada IdP.

Limitar la cantidad de grupos de identidades de personal te ayuda a garantizar lo siguiente:

  • No es necesario que crees ni modifiques grupos de Workforce Identity cuando incorpores cargas de trabajo nuevas a Google Cloud.
  • Puedes usar IAM para controlar a qué proyectos y recursos dentro de Google Cloud pueden acceder los usuarios individuales.

Elige un nombre único y significativo para el grupo

Para que los identificadores principales sean únicos a nivel global, la identidad del personal codifica el nombre del grupo de identidades del personal en el identificador principal. Cuando elijas un nombre para un grupo de identidades de personal, ten en cuenta las siguientes restricciones:

  • Unicidad: Elige un nombre que sea único en Google Cloud y que ninguna otra organización haya reclamado.
  • Inmutabilidad: No puedes cambiar el nombre de un grupo de identidades para personal. Elige un nombre que siga siendo significativo con el tiempo y evita los nombres temporales de iniciativas.
  • Experiencia del usuario: Según la configuración de acceso, es posible que los usuarios deban ingresar el nombre del grupo durante el acceso. Elige un nombre corto que sea fácil de recordar.

Trata los grupos como recursos con privilegios elevados

El grupo y el proveedor de identidades de personal determinan cómo acceden los usuarios y controlan cómo se derivan las identidades y las membresías de grupo del IdP externo. Dado que estos componentes controlan la lógica de autenticación, son fundamentales para la seguridad de tu organización Google Cloud . Si se vulneran estos componentes, es posible que las personas que actúan de mala fe puedan realizar ataques de falsificación de identidad.

Para realizar un ataque de falsificación de identidad, los agentes maliciosos pueden intentar las siguientes acciones:

  • Modificación de asignaciones de atributos: Alterar las asignaciones de atributos puede permitir que una persona que actúa de mala fe se autentique como otra persona y obtenga acceso privilegiado no autorizado.
  • Agregar un proveedor malicioso: Agregar un proveedor puede permitir que una persona que actúa de mala fe omita el IdP de tu organización y se autentique con un IdP diferente que controle.

Los grupos y proveedores de Workforce Identity son recursos críticos para la seguridad que requieren la siguiente protección:

  • Restringe el acceso a usuarios no federados: Limita el acceso administrativo a una pequeña cantidad de usuarios de Cloud Identity o Google Workspace, incluido al menos un usuario con acceso de emergencia.
  • Protege a los usuarios administradores: Solicita la verificación en dos pasos para todos los usuarios administradores y con acceso de emergencia.
  • Acceso justo a tiempo: Usa Privileged Access Manager (PAM) para otorgar acceso de administrador justo a tiempo en lugar de otorgar acceso permanente.

Considera los riesgos cuando extiendas la federación a los socios

La federación Google Cloud con un IdP externo a través de la federación de identidades de personal establece una relación de confianza. Cuando usas la federación, dependes del IdP externo para realizar las siguientes acciones:

  • Realiza la autenticación de varios factores (MFA) que cumpla con tus requisitos de seguridad.
  • Realizar afirmaciones precisas sobre las identidades de los usuarios y las membresías de los grupos
  • Sigue los procesos de administración de identidades que garantizan que los usuarios se desvinculen rápidamente y que las membresías de los grupos reflejen con precisión los roles actuales.

La federación de identidades de personal proporciona mecanismos limitados para validar las aserciones realizadas por un IdP externo. Específicamente, la federación de identidades de personal no admite la MFA posterior al SSO de la misma manera que Cloud Identity.

Antes de usar la federación de identidades de personal para permitir que socios o contratistas externos accedan a tus recursos de Google Cloud , determina si este nivel de confianza es adecuado. No uses la federación de identidades de personal para el acceso de socios, a menos que confíes en el socio y en su IdP para que cumplan con tus estándares de seguridad de forma constante.

Administra proveedores de grupos de Workload Identity

Un proveedor de grupos de identidades de personal define una relación de federación con un IdP externo y contiene la configuración de lo siguiente:

  • Es el IdP que se usará para el inicio de sesión único.
  • Es la asignación de atributos que se usará para derivar identificadores principales de los tokens o las aserciones proporcionados por el IdP.
  • Opcional: Es el arrendatario de SCIM que se usará para buscar información sobre la pertenencia a un grupo.

Recomendaciones:

Elige un nombre de proveedor significativo.
Usa el portal de aplicaciones de tu IdP para exponer servicios individuales.
Usa un solo proveedor por grupo para evitar colisiones de sujetos.
Usa el mismo grupo y proveedor para la consola de Google Cloud y Gemini Enterprise.
Usa un URI de entidad emisora específico del usuario.
Evita usar el flujo implícito de OpenID Connect (OIDC).

Elige un nombre de proveedor significativo

Cuando creas un proveedor de grupo de Workforce Identity, debes asignarle un nombre. A diferencia de los nombres de los grupos de identidades de personal, este nombre no necesita ser único a nivel global y no se codifica en los identificadores principales. Sin embargo, según la configuración de acceso, es posible que los usuarios deban ingresar el nombre del proveedor durante el acceso. Para mejorar la experiencia del usuario, elige un nombre significativo y fácil de recordar, por ejemplo, entra o staff.

Evita usar nombres como oidc o saml, ya que es posible que los usuarios no conozcan estos acrónimos.

Muestra servicios individuales en el portal de la aplicación del IdP

Los proveedores de identidad, como Microsoft Entra ID y Okta, proporcionan un portal de aplicaciones que permite a los usuarios descubrir y acceder a las aplicaciones que se les asignaron. Usa el portal para optimizar la experiencia del usuario de la siguiente manera:

  • Configura el portal para que muestre los servicios de Google pertinentes de forma individual en lugar de mostrar un solo vínculo Google Cloud .
  • Configura vínculos para que el usuario acceda automáticamente.

En la siguiente tabla, se enumeran los servicios de Google comunes que admiten la federación de identidades de personal y las URLs para el acceso automático:

Aplicación URL
Google Cloud Consola de la federación de identidades de personal, también conocida como la consola (federada) https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google
Gemini Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID
NotebookLM Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER
Apps web protegidas con IAP URL de la app, como https://iap.example.com/

Reemplaza lo siguiente:

  • POOL: Es el nombre del grupo de identidades de personal.
  • PROVIDER: Es el nombre del proveedor del grupo.
  • WEBAPP_ID: Es el ID de la app web de Gemini Enterprise.
  • PROJECT_NUMBER: Es el número del proyecto de NotebookLM Enterprise.

Usa un solo proveedor por grupo para evitar colisiones de sujetos

Puedes usar la federación de identidades de personal para agregar varios proveedores a un grupo de personal. Agregar un segundo proveedor es útil durante las migraciones en las que permites temporalmente que los usuarios se autentiquen con diferentes IdPs. Además de las situaciones temporales, evita usar varios proveedores por los siguientes motivos:

  • Colisiones de sujetos: El uso de varios proveedores presenta un riesgo de colisiones de sujetos. En estas colisiones, la asignación del atributo google.subject para un proveedor devuelve el mismo valor que otro proveedor. Esta colisión asigna varias identidades externas al mismo principal de IAM, lo que hace que no se puedan distinguir en los registros de auditoría de Cloud.
  • Compatibilidad con IAP: IAP requiere que los grupos de identidades de personal tengan un solo proveedor para redireccionar automáticamente a los usuarios no autenticados al IdP. Si agregas un proveedor adicional, la IAP no podrá autenticar a los usuarios.

Si necesitas federar con varios proveedores, crea varios grupos de personal y configura un proveedor para cada grupo.

Usar el mismo grupo y proveedor para la consola de Google Cloud y Gemini Enterprise

Si usas la federación de identidades de personal para Gemini Enterprise y Google Cloud, usa un solo proveedor para garantizar que los usuarios puedan acceder a ambos servicios de forma simultánea sin volver a acceder. Si usas proveedores independientes con diferentes asignaciones de atributos, es posible que los usuarios se encuentren con situaciones en las que su acceso a los recursos difiera según el proveedor con el que accedan.

Usa un URI de entidad emisora específico del usuario

Cuando configuras un proveedor, especificas un URI del emisor para identificar de forma única tu IdP. Sin embargo, según la configuración de tu IdP, el URI del emisor podría no ser único para el arrendatario de tu organización. Por ejemplo, si usas un URI de entidad emisora genérico o compartido, como el extremo común de Microsoft Entra ID (https://login.microsoftonline.com/common/v2.0), es posible que, sin querer, permitas que los usuarios de otras organizaciones se autentiquen en tu organización de Google Cloud.

Para evitar el acceso no deseado entre usuarios, usa un URI de entidad emisora específico del usuario. Si tu IdP no proporciona un URI de emisor específico del usuario, configura una condición de atributo para limitar el acceso a tu usuario específico.

Evita usar el flujo implícito de OpenID Connect (OIDC)

Cuando configures un proveedor de OIDC, prefiere el flujo de código de autorización al flujo implícito. El flujo implícito dejó de estar disponible en la versión 2.1 de la especificación de OAuth porque es vulnerable a la filtración y la inyección de tokens. El uso del flujo de código de autorización ayuda a reducir el riesgo de interceptación de tokens.

Administra usuarios

Puedes administrar usuarios con la federación de identidades del personal. La federación de identidades de personal deriva el identificador principal de un usuario a partir de su token o aserción siguiendo estos pasos:

  1. Determina el identificador del sujeto aplicando la asignación de atributos para google.subject. El identificador del sujeto debe identificar de forma única a un usuario dentro de un grupo de identidades para cargas de trabajo, pero no es necesario que sea único en Google Cloud.

  2. Deriva el identificador principal agregando el identificador de sujeto a un prefijo que identifica el grupo de identidades del personal. El identificador principal resultante es único en Google Cloud y tiene el siguiente formato:

    principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\
subject/SUBJECT

Cuando un usuario que se autenticó con la federación de identidades de personal accede a un recurso, IAM usa el identificador principal para evaluar las vinculaciones de roles en las políticas de permiso y las registra en los registros de auditoría de Cloud.

Recomendaciones:

Usa un identificador de asunto inmutable.
No reutilices identificadores de asunto.
Microsoft Entra ID: Usa el UPN como identificador de sujeto.

Usa un identificador de asunto inmutable

Cuando cambia el identificador de asunto de un usuario, también cambia su identificador principal. Como resultado, Google Cloud ya no los reconoce como el mismo usuario:

  • El usuario no puede acceder a los recursos a los que se le había otorgado acceso anteriormente porque su nuevo identificador principal ya no coincide con los identificadores principales que se indican en las políticas de permisos.
  • Las entradas de los registros de auditoría de Cloud solo contienen el nuevo identificador principal y ya no se pueden correlacionar con los registros que usaban el identificador principal anterior.

Para mantener estable el identificador principal de un usuario, usa una asignación de atributos que genere un valor estable para google.subject.

Muchos IdP generan automáticamente un identificador único numérico o con formato UUID para los usuarios. Estos identificadores son únicos y estables, lo que los convierte en buenos candidatos para google.subject. Sin embargo, usar estos identificadores como google.subject puede generar identificadores principales largos y crípticos con los que podría ser difícil trabajar.

Para ayudarte a elegir un identificador para google.subject, ten en cuenta los siguientes requisitos en orden de prioridad descendente:

  1. Unicidad: El valor identifica de forma única a un usuario en tu IdP.
  2. Usabilidad: El valor es significativo o, al menos, se puede buscar fácilmente en el directorio de usuarios de tu IdP.
  3. Inmutabilidad: El valor es inmutable o, al menos, solo los administradores pueden modificarlo.

No reutilices identificadores de sujetos

Muchos IdP aplican restricciones de unicidad en ciertos identificadores de usuario, pero permiten que se reutilicen. Por ejemplo, es posible que un IdP no te permita crear dos usuarios con el mismo nombre de usuario bob. Sin embargo, una vez que borres la cuenta de usuario bob, es posible que el IdP te permita crear una cuenta de usuario nueva y asignarle el nombre de usuario bob nuevamente.

Si la asignación de atributos de tu proveedor para google.subject hace referencia a un identificador de usuario que permite la reutilización, es posible que se produzcan colisiones de asunto: La federación de identidades de la fuerza laboral no puede distinguir entre un usuario anterior y un usuario nuevo si su google.subject es el mismo. Como resultado, el usuario nuevo podría obtener acceso a recursos destinados solo al usuario anterior.

Para evitar colisiones de temas, haz una o ambas de las siguientes acciones:

Microsoft Entra ID: Usa el UPN como identificador de asunto

Esta práctica recomendada solo se aplica si usas el ID de Microsoft Entra como tu IdP.

Si usas el ID de Microsoft Entra, los identificadores que puedes usar como identificador de sujeto incluyen los siguientes:

  • Nombre principal del usuario (upn)
  • ID del objeto (oid)
  • Dirección de correo electrónico (la dirección principal en proxyAddresses)

Entre estas opciones, recomendamos usar el nombre principal del usuario como identificador del sujeto por los siguientes motivos:

  • Todos los usuarios tienen un nombre principal de usuario.
  • Los nombres principales del usuario identifican de forma única a un usuario.
  • Los nombres principales de usuario suelen ser significativos y fáciles de usar.
  • Los nombres principales del usuario incorporan un nombre de dominio, que identifica de forma única el inquilino de Microsoft Entra ID con el que se asocia el usuario.
  • Es posible que tu organización tenga una política que prohíba o regule la reutilización de identificadores principales de usuarios.

En cambio, el ID de objeto y la dirección de correo electrónico de un usuario son menos adecuados por los siguientes motivos:

  • Un ID de objeto (oid) es inmutable, pero tiene el formato de un GUID. Este formato dificulta su uso y no es significativo para los humanos.
  • La dirección de correo electrónico no es un atributo obligatorio y es posible que no se complete para todos los usuarios.

Independientemente del identificador que elijas, te recomendamos que evites aplicar transformaciones, como forzar los identificadores a minúsculas.

Administrar grupos

La federación de identidades de personal puede determinar la membresía de un usuario en un grupo a partir de las siguientes fuentes:

  • Es la aserción de SAML o el token de ID proporcionado por el IdP.
  • La API de Microsoft Graph, si usas Microsoft Entra ID como tu IdP
  • Es el inquilino de SCIM asociado al proveedor de grupos de identidades de personal.

De forma predeterminada, la federación de identidades de personal solo usa la aserción de SAML o el token de ID:

Fuente Google Cloud Gemini Enterprise
Token de ID o SAML
API de Microsoft Graph - -
Tenant de SCIM - -

Si usas Microsoft Entra ID como tu IdP, puedes habilitar la función de atributos adicionales. Luego, la federación de identidades de personal solo usa la API de Microsoft Graph como fuente para las membresías de grupos:

Fuente Google Cloud Gemini Enterprise
Token de ID o SAML - -
API de Microsoft Graph
Tenant de SCIM - -

Si usas Gemini Enterprise, puedes configurar la federación de identidades de personal para usar un arrendatario de SCIM, lo que cambia el comportamiento de la siguiente manera:

  • Gemini Enterprise usa las membresías de grupos del arrendatario de SCIM y omite la información de membresías de grupos de la aserción de SAML o el token de ID.
  • Google Cloud usa la información de pertenencia a un grupo de la aserción de SAML o el token de ID, y omite la información de pertenencia a un grupo del arrendatario de SCIM.
Fuente Google Cloud Gemini Enterprise
Token de ID o SAML -
API de Microsoft Graph - -
Tenant de SCIM -

Para cada pertenencia a un grupo, la federación de identidades de personal deriva un identificador de entidad principal siguiendo estos pasos:

  1. Para determinar el identificador del grupo, haz una de las siguientes acciones:
    • Aserción de SAML o token de ID: Aplica la asignación de atributos para google.groups.
    • Tenant de SCIM: Aplica la asignación de reclamos para google.group.
    • API de Microsoft Graph: Sigue extra-attributes-type en la configuración del proveedor.

  2. Deriva el identificador principal agregando el identificador del grupo a un prefijo que identifica el grupo de identidades de personal. El identificador principal resultante es único en Google Cloud y tiene el siguiente formato:

    principalSet://iam.googleapis.com/locations/global/workforcePools/\
POOL_ID/group/GROUP_ID

Cuando un usuario que se autenticó con la federación de identidades de personal accede a un recurso, IAM usa estos identificadores principales para evaluar las vinculaciones de roles en las políticas de permiso.

Recomendaciones:

Usa un identificador de grupo inmutable.
Reduce group memberships in assertions or tokens.
Microsoft Entra ID: Usa el ID de objeto como identificador de grupo.

Usa un identificador de grupo inmutable

Todas las políticas de IAM hacen referencia a los grupos por su identificador principal. Cuando cambias el nombre de un grupo en tu IdP para que cambie su identificador,Google Cloud ya no lo reconoce como el mismo grupo:

  • Las vinculaciones de roles de IAM existentes seguirán haciendo referencia al identificador principal anterior y dejarán de ser efectivas.
  • Los miembros del grupo renombrado pierden el acceso porque el nuevo identificador principal del grupo ya no coincide con ninguna vinculación de roles de IAM.

Para evitar estas interrupciones, configura la asignación de atributos y de reclamaciones para usar un valor estable e inmutable, como un ID único generado por el IdP. Evita usar nombres visibles o direcciones de correo electrónico como identificadores de grupo, ya que pueden cambiar durante los cambios organizacionales.

Reduce group memberships in assertions or tokens

De forma predeterminada, es posible que tu IdP incluya más membresías de grupos en las aserciones de SAML o los tokens de ID de los que necesitas para administrar el acceso a los recursos de Gemini Enterprise y Google Cloud . Incluir membresías de grupos innecesarias genera varios riesgos:

  • Pérdida parcial del acceso: Muchos IdP imponen límites en la cantidad de membresías de grupos que pueden incluir en un token o una aserción. Cuando un usuario supera este límite (exceso de grupos), es posible que el IdP quite algunas membresías de grupos, lo que hará que el usuario pierda el acceso a ciertos recursos.
  • Fallas de acceso: La federación de identidades de personal limita el tamaño y la cantidad de membresías de grupos que puede producir la asignación de atributos de google.groups. Los usuarios que superen uno de estos límites no podrán acceder.
  • Uso incoherente de grupos: Si expones grupos a Google Cloud, es posible que los propietarios del proyecto decidan usar esos grupos para administrar el acceso a los recursos, incluso si nunca tuviste la intención de que ciertos grupos se usaran enGoogle Cloud.

Los siguientes enfoques pueden ayudarte a mitigar estos riesgos y reducir la cantidad de membresías de grupos en las aserciones o los tokens:

  • Filtrar por tipo de grupo: Algunos IdP, incluido Microsoft Entra ID, te permiten configurar un filtro que determina qué grupos se incluirán en las aserciones o los tokens. Puedes configurar un filtro para excluir los tipos de grupos que no son relevantes según tu configuración y los servicios que planeas usar.

    En la siguiente tabla, se indican los tipos de grupos que tal vez debas incluir en las aserciones o los tokens, según los servicios que planees usar:

    Tipo de grupo Google Cloud Gemini (sin sincronización) Gemini (SCIM)
    Grupos de acceso -
    Grupos de aplicación -
    Grupos organizativos No son necesarios * -
    Grupos de colaboración No son necesarios * -

    * Solo se requiere si se usan conectores basados en la transferencia de datos.

    • Para administrar el acceso a Google Cloud, debes incluir grupos de acceso y grupos de aplicación.
    • El filtro necesario para administrar el acceso a Gemini Enterprise depende de si usas SCIM. Si usas SCIM, Gemini Enterprise ignora las membresías de grupos incluidas en las aserciones o los tokens, por lo que no es necesario que incluyas grupos específicos de Gemini Enterprise. Si no usas SCIM, debes incluir los grupos de acceso y los grupos de aplicación necesarios para Gemini Enterprise. Según si planeas usar conectores basados en la transferencia de datos, es posible que también debas incluir ciertos grupos de colaboración y organización.

  • Asignación: Algunos IdP, incluido Microsoft Entra ID, te permiten restringir las membresías de grupos en tokens y aserciones a los grupos asignados, que son los grupos que asignas explícitamente a la configuración de la entidad de confianza.

  • Filtro de atributos adicionales: Si usas Microsoft Entra ID y habilitaste la función de atributos adicionales, puedes especificar un filtro con la marca --extra-attributes-filter. La federación de identidades de personal pasa este filtro a la API de Microsoft Graph cuando solicita membresías de grupos.

Para probar o solucionar problemas relacionados con los filtros, usa la herramienta Debug IdP token en la consola de Google Cloud o habilita el registro de auditoría detallado.

Microsoft Entra ID: Usa el ID de objeto como identificador de grupo

Esta práctica recomendada solo se aplica si usas el ID de Microsoft Entra como tu IdP.

Si usas Microsoft Entra ID, los identificadores que puedes usar como identificador de grupo incluyen los siguientes:

  • ID del objeto (oid)
  • Dirección de correo electrónico
  • Nombre visible

Entre estas opciones, te recomendamos que uses el ID de objeto (oid) como identificador de grupo por los siguientes motivos:

  • Todos los grupos tienen un ID de objeto. En cambio, la dirección de correo electrónico es un campo opcional que solo se puede completar para los grupos de Microsoft 365.
  • El ID del objeto es único e inmutable. En cambio, el nombre visible de un grupo puede cambiar y no ser único.

Independientemente del identificador que elijas, te recomendamos que evites aplicar transformaciones, como forzar los identificadores a minúsculas.

Administrar acceso

Prácticas recomendadas para los límites de acceso y la administración justo a tiempo (JIT)

Recomendaciones:

Usa usuarios de Cloud Identity para el acceso de emergencia.
Usa Cloud Identity para el acceso con privilegios elevados.
Usa restricciones de las políticas de la organización para controlar la federación.
No otorgues acceso a todos los miembros de un grupo.
Limita la duración de la sesión.
Alinea la duración de la sesión con los requisitos de acceso JIT.

Usa usuarios de Cloud Identity para el acceso de emergencia

Para garantizar el acceso continuo a tus Google Cloud entornos, crea usuarios con acceso de emergencia para cada uno de ellos.

Los usuarios con acceso de emergencia brindan acceso a tu entorno de Google Cloud cuando los servicios están mal configurados, en riesgo o no funcionan con normalidad. Los usuarios con acceso de emergencia tienen muchos privilegios. Confiar en la federación de identidades de personal para autenticar a los usuarios con acceso de emergencia presenta los siguientes riesgos:

  • Un error en la configuración del proveedor de grupo de identidades de personal puede hacer que te quedes sin acceso.
  • Una interrupción del servicio que afecte al IdP externo puede impedir que uses un usuario de acceso de emergencia cuando más lo necesites.
  • Si se vulnera el IdP externo, los agentes maliciosos pueden autenticarse como usuarios con acceso de emergencia y obtener acceso amplio a tus recursos de Google Cloud.

Para mitigar estos riesgos, usa Cloud Identity o Google Workspace para los usuarios con acceso de emergencia, incluso si usas la federación de identidades de personal para otros usuarios:

  • Crea usuarios con acceso de emergencia en Cloud Identity.
  • Excluye a estos usuarios del inicio de sesión único y permíteles autenticarse con un nombre de usuario y una contraseña.
  • Protege a estos usuarios inscribiéndolos en la verificación en dos pasos con una llave de seguridad.

Para obtener más información sobre los usuarios con acceso de emergencia, consulta Prácticas recomendadas para el acceso continuo a Google Cloud.

Usa Cloud Identity para el acceso con privilegios elevados

Los usuarios con muchos privilegios tienen acceso amplio a tu entorno de Google Cloud. Estos son algunos ejemplos de estos usuarios:

  • Usuarios con el rol de Administrador de la organización (roles/resourcemanager.organizationAdmin)
  • Usuarios con el rol de administrador de seguridad (roles/iam.securityAdmin) o un rol similar que pueda modificar las políticas de permisos en partes importantes de la jerarquía de recursos de Google Cloud

Si usas la federación de identidades de personal para usuarios con privilegios elevados, cualquier error de configuración o vulneración en tu IdP externo puede afectar la seguridad de tus recursos de Google Cloud . En particular, una vulneración del IdP externo puede permitir que los agentes maliciosos se autentiquen como usuarios con privilegios elevados y obtengan acceso amplio a tus recursos de Google Cloud .

Para mitigar estos riesgos, usa Cloud Identity para los usuarios con privilegios elevados:

Las verificaciones de SSO adicionales pueden parecer redundantes si tu IdP ya aplica la autenticación de varios factores, pero este parámetro de configuración ayuda a proteger a los usuarios si el IdP se ve comprometido. Las verificaciones adicionales de SSO son una función compatible con Cloud Identity, pero no están disponibles para la federación de identidades de personal.

Usa restricciones de políticas de la organización para regir la federación

Si usas Cloud Identity para fines que no sean de emergencia o de acceso con privilegios altos, divide el uso de la federación de Cloud Identity y de la federación de identidades de personal por servicio. Para aplicar esta práctica, usa restricciones de políticas de la organización personalizadas para restringir los tipos de principales que se permiten en proyectos específicos.

Por ejemplo, puedes limitar la federación de identidades de personal a Gemini Enterprise de la siguiente manera:

  • Aplica una restricción de política de la organización personalizada a tu proyecto de Gemini Enterprise que use la función MemberTypeMatches para limitar los tipos de principales permitidos a iam.googleapis.com/WorkforcePoolPrincipal y iam.googleapis.com/WorkforcePoolPrincipalSet. Estos son los principales tipos que usa la federación de identidades de personal.
  • Para todos los demás proyectos, aplica una restricción que permita todos los tipos de principales, excepto iam.googleapis.com/WorkforcePoolPrincipal y iam.googleapis.com/WorkforcePoolPrincipalSet.

El uso de restricciones de políticas de la organización personalizadas te ayuda a garantizar la coherencia y a evitar el uso accidental de tipos de principales incorrectos.

No otorgues acceso a todos los miembros de un grupo

La federación de identidades de personal admite un identificador principal comodín que usa el siguiente formato:

principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*

Este identificador coincide con cada usuario al que tu IdP permite autenticarse enGoogle Cloud.

No uses este identificador comodín para otorgar permisos. A medida que crece la base de usuarios de tu IdP, otorgar acceso con el identificador de entidad comodín genera un exceso de permisos.

En cambio, crea grupos de acceso en tu IdP y úsalos para administrar el acceso a los recursos. Este enfoque ayuda a garantizar que el acceso se rija por la membresía intencional del grupo en lugar de la autenticación exitosa, lo que reduce el riesgo de otorgar permisos en exceso.

Limita la duración de la sesión

Cuando un usuario accede, la federación de identidades de personal inicia una sesión. La sesión permite que el usuario haga lo siguiente:

  • Usar la consola (federada), Gemini Enterprise o cualquier otro portal que admita la federación de identidades de personal, y navegar entre ellos
  • Usar aplicaciones web protegidas por IAP
  • Obtén tokens de actualización federados y tokens de acceso federados, por ejemplo, ejecutando gcloud auth login.

Una sesión sigue siendo válida hasta que ocurre una de las siguientes situaciones:

  • La duración de la sesión alcanza el límite definido por el grupo de identidades para trabajadores.
  • La duración de la sesión alcanza el límite definido en el atributo SessionNotOnOrAfter de la aserción de SAML del usuario, si está presente.
  • El usuario sale de la cuenta.

Permitir que las sesiones sigan siendo válidas durante períodos prolongados aumenta el riesgo de robo de tokens y puede hacer que la información de pertenencia a un grupo quede obsoleta:

  • Es posible que los usuarios conserven el acceso durante más tiempo del previsto si se revocan los permisos en el IdP.
  • Es posible que los usuarios no puedan ejercer el acceso recién otorgado hasta que se vuelvan a autenticar y establezcan una nueva sesión.

Para mitigar estos riesgos, limita la duración de la sesión de modo que los usuarios deban volver a acceder al menos una vez al día.

Alinear la duración de la sesión con los requisitos de acceso JIT

Para administrar el acceso con privilegios, es posible que tus IdP admitan grupos justo a tiempo (JIT) que los miembros pueden activar de forma temporal. Usar grupos just-in-time para administrar el acceso privilegiado a Google Cloud o Gemini Enterprise puede generar los siguientes riesgos:

  • Activación retrasada: Si un usuario tiene una sesión activa de federación de identidades de personal mientras activa su pertenencia a un grupo justo a tiempo, el cambio de pertenencia no se aplica hasta que el usuario salga de su cuenta y vuelva a acceder. Como alternativa, si el proveedor del grupo de identidades para cargas de trabajo usa SCIM, el cambio de pertenencia a un grupo no entrará en vigencia hasta que se aprovisione el cambio de pertenencia a un grupo.
  • Revocación retrasada: Si vence la pertenencia a un grupo, el usuario no pierde el acceso privilegiado hasta que salga de su cuenta y vuelva a acceder, o bien hasta que se aprovisione el cambio de pertenencia al grupo con SCIM. Según la duración de tu sesión, este retraso puede socavar el propósito del vencimiento de la membresía.

Para mitigar estos riesgos, configura la duración de la sesión de tu grupo de identidades de personal para que sea lo suficientemente corta.

Supervisar la actividad

Cada vez que observes una actividad sospechosa que afecte a un recurso enGoogle Cloud, los Registros de auditoría de Cloud proporcionan información fundamental para determinar cuándo ocurrió la actividad y qué usuarios participaron.

Habilita los registros de acceso a los datos

La federación de identidades de personal puede generar registros que te permiten hacer un seguimiento de las actividades de acceso y de intercambio de tokens. La API del Servicio de tokens de seguridad escribe estos registros, que incluyen los siguientes métodos:

  • google.identity.sts.SecurityTokenService.WebSignIn
  • google.identity.sts.SecurityTokenService.WebSignOut
  • google.identity.sts.v1.SecurityTokenService.ExchangeToken
  • google.identity.sts.v1beta.SecurityTokenService.ExchangeToken

Todos los registros relacionados con las actividades de acceso y de intercambio de tokens se clasifican como registros de acceso a los datos y están inhabilitados de forma predeterminada. Para capturar estos registros, habilita los registros de acceso a los datos para la API de Security Token Service en toda tu organización deGoogle Cloud . Para aumentar aún más la verbosidad de los registros de acceso, habilita el registro de auditoría detallado.

Para hacer un seguimiento de otra actividad relacionada con la autenticación, te recomendamos que habilites y uses los siguientes registros:

¿Qué sigue?