Bonnes pratiques pour utiliser la fédération d'identité de personnel

La fédération des identités des employés fédère votre organisation Google Cloud avec un fournisseur d'identité externe (IdP) pour activer l'authentification unique (SSO).

Vous pouvez appliquer ces bonnes pratiques pour utiliser efficacement la fédération d'identité de personnel et minimiser les risques de sécurité.

Choisir la bonne architecture

Les sections suivantes décrivent les facteurs clés pour choisir une architecture de fédération qui répond à vos besoins.

Choisir un modèle d'architecture de fédération

Les quatre modèles suivants décrivent les méthodes courantes de fédération d'une organisation Google Cloudavec un IdP externe :

• Fédération Cloud Identity
• Fédération d'identité de personnel, sans synchronisation
• Fédération d'identité de personnel avec System for Cross-domain Identity Management (SCIM)
• Cloud Identity hybride et fédération des identités des employés

Avant de procéder à la fédération, tenez compte des avantages et des limites de chaque modèle, puis choisissez celui qui correspond à vos besoins. Pour en savoir plus, consultez Modèles d'architecture pour la fédération d'identité.

Utilisation de la fédération de partitions par service

En général, nous vous recommandons de partitionner l'utilisation de la fédération par service plutôt que par utilisateur. Le partitionnement de l'utilisation par service présente globalement moins d'inconvénients.

Pour réduire la complexité, nous vous recommandons d'utiliser Cloud Identity ou la fédération des identités des employés. Toutefois, selon vos besoins, vous pouvez avoir besoin des deux en parallèle, comme décrit dans le modèle hybride.

Si vous utilisez la fédération Cloud Identity et la fédération des identités des employés en parallèle, vous pouvez partitionner leur utilisation de la manière suivante :

• Partitionner par utilisateur : partitionnez vos utilisateurs en deux cohortes : l'une utilisant la fédération des identités des employés et l'autre utilisant la fédération Cloud Identity.

  • Avantage : chaque utilisateur dispose d'une identité unique pour tous les services Google et d'une méthode de connexion unique.

  • Inconvénients : le partitionnement par utilisateurs présente plusieurs inconvénients, dont les suivants :

    • La gestion des groupes d'accès peut être complexe, car les stratégies d'autorisation IAM doivent contenir une combinaison de types de comptes principaux, et vous ne pouvez pas utiliser les mêmes groupes pour les utilisateurs Cloud Identity et Workforce Identity Federation.

    • Les utilisateurs de différentes cohortes ne peuvent pas partager de liens entre eux, car la console Google Cloud , Gemini Enterprise et d'autres outils utilisent des URL différentes selon la façon dont les utilisateurs se connectent.

    • Les utilisateurs de différentes cohortes peuvent avoir accès à différents ensembles de fonctionnalités.

• Partitionner par service : configurez chaque service, tel queGoogle Cloud ou Gemini Enterprise, de sorte qu'il n'accorde l'accès qu'aux utilisateurs de la fédération des identités des employés ou aux utilisateurs Cloud Identity, mais jamais aux deux.

  • Avantage : simplifie l'administration et garantit un ensemble de fonctionnalités cohérent pour les différents utilisateurs.
  • Inconvénient : certains employés peuvent avoir besoin de deux identités : une qui utilise la fédération des identités des employés et une qui utilise Cloud Identity.

Nous vous recommandons de partitionner par service, en séparant spécifiquement Gemini Enterprise et Gemini Notebook Enterprise des autres services. Gemini Enterprise et la console Google Cloud sont des outils distincts conçus pour des tâches différentes. Les différences dans leurs processus de connexion devraient avoir un impact minimal sur l'expérience utilisateur globale.

Pour appliquer ce partitionnement, utilisez des contraintes de règles d'administration.

Renforcer la gouvernance des groupes

Vous devez gérer les accès à l'aide de groupes et établir des processus clairs pour régir ces groupes afin d'utiliser efficacement la fédération des identités des employés.

Les autorisations d'un utilisateur pour accéder aux ressources ne sont pas déterminées lors de l'authentification. Au lieu de cela, l'accès est évalué lorsque l'utilisateur tente d'accéder à la ressource en fonction des stratégies associées à cette ressource spécifique. Ces règles peuvent inclure les éléments suivants :

• Une ou plusieurs stratégies d'autorisation
• Zéro ou plusieurs stratégies de refus
• Zéro ou plusieurs stratégies de limite d'accès des comptes principaux

Les stratégies définissent l'accès pour des comptes principaux individuels ou des ensembles de comptes principaux :

• Compte principal : utilisateur authentifié identifié par un identifiant de compte principal. Un identifiant de compte principal d'employé ressemble à ceci : principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

  L'identifiant du compte principal contient les éléments suivants :

  • POOL_ID : identifie de manière unique un pool d'identités de personnel.
  • SUBJECT : identifie de manière unique un utilisateur spécifique. La valeur et le format dépendent de votre IdP et du mappage d'attributs.

• Ensemble de comptes principaux : utilisateurs correspondant à des critères spécifiques. La fédération des identités des employés est compatible avec trois ensembles de comptes principaux : basé sur un groupe (membres d'un groupe), basé sur des attributs et générique (tous les utilisateurs).

Accorder l'accès à des comptes principaux individuels peut être utile dans des situations spécifiques, mais cela a tendance à ne pas s'adapter correctement en raison des problèmes suivants :

• L'ajout de comptes principaux un par un entraîne l'augmentation des stratégies d'autorisation, qui deviennent de plus en plus difficiles à gérer.
• La gestion des accès individuels nécessite des modifications fréquentes des stratégies d'autorisation.
• Les règles peuvent devenir de plus en plus incohérentes au fil du temps.

Pour une gestion des accès évolutive et efficace, l'utilisation d'ensembles de principaux basés sur des groupes offre les avantages suivants :

• Vous pouvez gérer les accès en ajoutant ou en supprimant des membres des groupes, à l'aide de vos outils et processus d'identité existants.
• Réduisez la taille et la complexité des stratégies d'autorisation.
• Assurez-vous que les utilisateurs ayant le même rôle ont le même accès aux ressources.

Pour utiliser des groupes pour gérer l'accès, vous devez configurer votre IdP externe de certaines manières et connaître les limites qu'il impose aux groupes.

Les sections suivantes décrivent les bonnes pratiques pour utiliser efficacement les groupes et éviter les limites de l'IdP.

Distinguer différents types de groupes

La liste suivante décrit quatre types de groupes couramment utilisés dans les organisations :

• Groupes d'accès : utilisés uniquement pour accorder l'accès aux services ou aux ressourcesGoogle Cloud Google. Ils représentent des fonctions professionnelles et simplifient l'attribution des rôles requis pour les exercer.
• Groupes organisationnels : ces groupes représentent des sous-ensembles de la structure d'une organisation et proviennent généralement des données des ressources humaines. Ils peuvent être basés sur le service, la structure hiérarchique, l'emplacement géographique ou d'autres regroupements organisationnels.
• Groupes de collaboration : ces groupes représentent des groupes de travail, des membres de projet ou des utilisateurs qui souhaitent collaborer sur un projet ou discuter d'un sujet spécifique. Ils peuvent être utilisés pour la distribution d'e-mails. Les groupes de collaboration sont souvent créés de manière ponctuelle et en libre-service.
• Groupes d'application : les groupes d'application, également appelés groupes de règles, permettent de restreindre l'accès, contrairement aux groupes d'accès, qui permettent d'accorder l'accès. Par exemple, les limites d'accès des principaux, les stratégies de refus ou l'application de l'authentification multifacteur. Les groupes d'accès peuvent autoriser les membres à quitter volontairement un groupe. Toutefois, l'appartenance à un groupe d'application n'est pas volontaire.

Les groupes que vous devez fédérer dépendent des services suivants que vous utilisez :

• Pour Google Cloud, vous n'avez besoin que de groupes d'accès et de groupes d'application.
• Pour Gemini Enterprise, vous avez besoin de groupes d'accès, de groupes d'application et, si vous utilisez des connecteurs basés sur l'ingestion de données, de certains groupes d'organisation et de collaboration.

Lorsque vous configurez la fédération des identités des employés, excluez les types de groupes non pertinents pour éviter d'atteindre les limites de jetons avec votre IdP. Cette approche vous permet de réduire le risque de dépassement des limites imposées par votre IdP et d'assurer une utilisation plus cohérente des groupes.

 Accorder l'accès aux ressources à l'aide de groupes d'accès

Pour gérer efficacement les accès, nous vous recommandons d'utiliser des ensembles de comptes principaux qui correspondent à des groupes d'accès. Les groupes d'accès existent uniquement pour fournir un accès. Ils représentent des fonctions professionnelles et simplifient l'attribution des rôles requis pour exécuter ces fonctions.

Pour configurer des groupes d'accès, procédez comme suit :

1. Dans votre IdP, créez des groupes d'accès qui représentent des fonctions professionnelles.
2. Mappez les groupes d'accès aux ensembles de comptes principaux pour les utiliser dans IAM.
3. Créez des liaisons de stratégie pour accorder aux ensembles de comptes principaux l'accès aux ressources nécessaires pour chaque fonction.
4. Dans l'IdP externe, ajoutez ou supprimez des utilisateurs des groupes en fonction de leurs fonctions.

Utilisez des groupes d'accès pour les stratégies qui accordent l'accès, y compris les suivantes :

• Stratégies d'autorisation IAM
• Règles d'entrée VPC Service Controls

Assurez-vous que les groupes d'accès sont suffisamment précis. Par exemple, les groupes suivants représentent des groupes d'accès effectifs :

• widget-sales-dashboard-readers : accorde un accès en lecture à un ensemble de données BigQuery spécifique et au tableau de bord associé.

• dev-ssh-users : accorde l'accès OS Login aux VM Compute Engine dans l'environnement de développement.

  En revanche, les types de groupes suivants ne sont généralement pas adaptés à une utilisation en tant que groupes d'accès :

  • Les groupes d'administrateurs généraux tels que cloud-admins ne sont souvent pas assez spécifiques quant aux charges de travail ou aux environnements concernés.

  • Les groupes organisationnels tels que australia-fte représentent des groupes comme des équipes ou des emplacements, plutôt que des fonctions professionnelles.

  • Les groupes de communication tels que security-discuss sont conçus pour les listes de diffusion ou la collaboration, plutôt que pour les groupes d'accès.

  Pour que les groupes d'accès restent précis, créez un ensemble de groupes d'accès pour chaque charge de travail ou projet que vous intégrez à Google Cloud. Vous pouvez ainsi adapter le nombre de groupes d'accès au nombre de charges de travail que vous exécutez sur Google Cloud.

Limiter l'accès aux ressources à l'aide de groupes d'application

Les groupes d'application sont semblables aux groupes d'accès, mais ils diffèrent généralement de la manière suivante :

• Ils n'autorisent pas les membres à quitter volontairement le groupe.
• Elles ne sont pas spécifiques à une charge de travail.

Utilisez des groupes d'application pour les règles qui réduisent l'accès, y compris les suivantes :

• Stratégies de refus IAM
• Limites d'accès des principaux
• Règles d'administration

Voici quelques exemples de groupes d'application : users-in-restricted-locations, fedramp-low et mfa-users. Le nombre de groupes d'application est généralement faible et n'affectera probablement pas le nombre total de groupes auxquels un utilisateur appartient.

Ne pas utiliser de groupes organisationnels et de collaboration pour gérer les accès

Pour gérer efficacement les accès, vous pouvez utiliser des groupes d'accès et des groupes d'application au lieu de groupes organisationnels ou de collaboration.

Les groupes organisationnels représentent des équipes ou des sous-ensembles de la structure d'une organisation. Ils proviennent généralement des données des ressources humaines. Ces groupes ne sont pas adaptés à la gestion de l'accès aux ressources Google Cloud pour les raisons suivantes :

• Les responsabilités et la composition de l'équipe peuvent évoluer au fil du temps. Par exemple, une équipe peut transférer une charge de travail à une autre équipe, ou deux équipes peuvent fusionner. La gestion des accès avec des groupes organisationnels peut nécessiter une cascade de modifications de règles lors de ces transitions.
• Les membres d'un groupe organisationnel ont rarement besoin d'un accès identique aux ressources. Accorder l'accès à un groupe organisationnel donne souvent à certains membres plus d'accès que nécessaire.

Les groupes de collaboration sont généralement autogérés, ce qui permet aux membres de les rejoindre avec l'approbation d'un autre membre ou sans approbation. L'utilisation de groupes de collaboration pour accorder l'accès peut entraîner une attribution excessive d'autorisations et une élévation des privilèges.

Pour empêcher l'utilisation de groupes organisationnels et de collaboration pour la gestion des accès, configurez votre IdP de sorte qu'il exclue ces appartenances à des groupes dans les jetons ou les assertions utilisés pour la fédération des identités des employés.

Utiliser des groupes organisationnels et des groupes de collaboration pour Gemini Enterprise uniquement

Bien que les groupes d'organisation et de collaboration ne soient pas adaptés à la gestion de l'accès aux ressources Google Cloud , vous pouvez en avoir besoin pour Gemini Enterprise :

• Évaluation des LCA : lorsque vous utilisez des connecteurs basés sur l'ingestion de données pour intégrer Gemini Enterprise à Microsoft 365, il peut rencontrer des documents avec des listes de contrôle des accès (LCA) qui font référence à des groupes d'organisation et de collaboration. Si Gemini Enterprise n'a pas accès aux appartenances d'un utilisateur à ces groupes, il risque de ne pas évaluer correctement si l'utilisateur est autorisé à accéder à ces documents.
• Partage de notebooks : Gemini Notebook Enterprise permet aux utilisateurs de partager des notebooks. Autoriser les utilisateurs à partager des notebooks avec des groupes de collaboration est souvent plus pratique que de limiter le partage à des utilisateurs individuels.

Pour vous assurer que les groupes d'organisation et de collaboration ne sont disponibles que pour Gemini Enterprise, vous pouvez configurer votre IdP comme suit :

• Utilisez SCIM pour provisionner des groupes d'organisation et de collaboration, ainsi que leurs membres.
• Excluez les appartenances à des groupes d'organisation et de collaboration dans les jetons ou les assertions utilisés pour la fédération des identités des employés.

Gérer les pools d'identités de personnel

Un pool d'identités d'employés définit un espace de noms pour les identifiants de comptes principaux et sert de conteneur pour votre configuration de fédération. Contrairement à un annuaire d'utilisateurs, un pool ne stocke pas d'informations sur les utilisateurs ou les groupes.

Utiliser un seul pool par IdP

Les pools d'identités des employés sont une ressource au niveau de l'organisation, et non au niveau du projet. Cette conception reflète le fait que les pools d'identités des employés gèrent l'authentification au sein d'une organisation Google Cloud , plutôt que d'un projet ou d'une charge de travail individuels.

Pour la plupart des organisations, le nombre de pools d'identités de personnel doit correspondre au nombre d'IdP :

• Si votre organisation utilise un seul IdP pour gérer l'authentification, utilisez un seul pool d'identités de personnel.
• Si votre organisation utilise plusieurs IdP (par exemple, en raison d'une acquisition), utilisez un pool d'identités de personnel par IdP.

Limiter le nombre de pools d'identités de personnel vous permet de garantir les points suivants :

• Vous n'avez pas besoin de créer ni de modifier des pools d'identités de personnel lorsque vous intégrez de nouvelles charges de travail à Google Cloud.
• Vous pouvez utiliser IAM pour contrôler les projets et les ressources auxquels les utilisateurs individuels peuvent accéder dans Google Cloud .

Choisissez un nom de pool unique et pertinent.

Pour que les identifiants d'entité principale soient uniques au niveau mondial, l'identité de personnel encode le nom du pool d'identités de personnel dans l'identifiant d'entité principale. Lorsque vous choisissez un nom pour un pool d'identités de personnel, tenez compte des contraintes suivantes :

• Unicité : choisissez un nom unique dans Google Cloud et qui n'est pas revendiqué par une autre organisation.
• Immuabilité : vous ne pouvez pas modifier le nom d'un pool d'identités de personnel. Choisissez un nom qui reste pertinent au fil du temps, en évitant les noms d'initiatives temporaires.
• Expérience utilisateur : selon votre configuration de connexion, les utilisateurs devront peut-être saisir le nom du pool lors de la connexion. Choisissez un nom court et facile à mémoriser.

Traiter les pools comme des ressources hautement privilégiées

Le pool d'identités de personnel et le fournisseur déterminent la manière dont les utilisateurs se connectent et contrôlent la façon dont les identités et les appartenances aux groupes sont dérivées de l'IdP externe. Comme ces composants contrôlent la logique d'authentification, ils sont essentiels à la sécurité de votre organisation Google Cloud . Une compromission de ces composants peut permettre à des acteurs malveillants d'effectuer des attaques par usurpation d'identité.

Pour effectuer une attaque par usurpation d'identité, des acteurs malveillants peuvent tenter les actions suivantes :

• Modifier les mappages d'attributs : la modification des mappages d'attributs peut permettre à un utilisateur malveillant de s'authentifier en tant qu'autre personne et d'obtenir un accès privilégié non autorisé.
• Ajout d'un fournisseur malveillant : l'ajout d'un fournisseur peut permettre à un acteur malintentionné de contourner l'IdP de votre organisation et de s'authentifier à l'aide d'un autre IdP qu'il contrôle.

Les pools d'identités de personnel et les fournisseurs sont des ressources critiques pour la sécurité qui nécessitent la protection suivante :

• Limiter l'accès aux utilisateurs non fédérés : limitez l'accès administrateur à un petit nombre d'utilisateurs Cloud Identity ou Google Workspace, y compris au moins un utilisateur d'accès d'urgence.
• Protéger les utilisateurs avec accès administrateur : exigez la validation en deux étapes pour tous les utilisateurs avec accès administrateur et les utilisateurs disposant d'un accès d'urgence.
• Accès juste-à-temps : utilisez Privileged Access Manager (PAM) pour accorder un accès administrateur juste-à-temps plutôt qu'un accès permanent.

Prendre en compte les risques lors de l'extension de la fédération aux partenaires

La fédération de Google Cloud avec un IdP externe à l'aide de la fédération des identités des employés établit une relation de confiance. En utilisant la fédération, vous vous appuyez sur le fournisseur d'identité externe pour effectuer les actions suivantes :

• Effectuez une authentification multifacteur (MFA) qui répond à vos exigences de sécurité.
• Émettre des assertions précises concernant les identités des utilisateurs et les appartenances aux groupes.
• Suivez des processus de gouvernance des identités qui garantissent que les utilisateurs sont supprimés rapidement et que les appartenances aux groupes reflètent précisément les rôles actuels.

La fédération des identités des employés fournit des mécanismes limités pour valider les assertions effectuées par un IdP externe. Plus précisément, la fédération des identités des employés n'est pas compatible avec l'authentification MFA post-SSO de la même manière que Cloud Identity.

Avant d'utiliser la fédération des identités des employés pour permettre à des partenaires ou sous-traitants externes d'accéder à vos ressources Google Cloud , déterminez si ce niveau de confiance est approprié. N'utilisez pas la fédération des identités des employés pour l'accès des partenaires, sauf si vous faites confiance au partenaire et à son IdP pour respecter systématiquement vos normes de sécurité.

Surveiller votre quota d'échange de jetons

L'échange de jetons de la fédération d'identité de personnel est limité par la métrique de quota sts.googleapis.com/workforce_requests, qui est définie par défaut sur 1 000 requêtes par minute et appliquée par organisation. Le quota est partagé entre tous les pools d'employés, fournisseurs, utilisateurs et charges de travail de l'organisation. Les pools distincts ne reçoivent pas de quotas distincts. Pour connaître la valeur actuelle, consultez Quotas et limites.

Étant donné que le quota s'applique à l'ensemble de l'organisation, un seul client à haute fréquence peut l'épuiser et provoquer des erreurs 429 RESOURCE_EXHAUSTED pour tous les autres utilisateurs de votre organisation, y compris les administrateurs.

Nous vous recommandons de suivre les conseils suivants :

• Réservez la fédération d'identité de personnel pour la connexion humaine. Acheminez les charges de travail automatisées, les pipelines de CI/CD et les agents vers la fédération d'identité de charge de travail, conçue pour le trafic de machine à machine.
• Réduisez la fréquence des requêtes en cas de limitation. Réessayez les réponses 429 RESOURCE_EXHAUSTED avec un intervalle exponentiel entre les tentatives et une gigue. Des boucles de nouvelles tentatives serrées aggravent la saturation et prolongent la panne pour tous les membres de votre organisation.
• Demandez une augmentation de quota avant d'en avoir besoin. Si votre organisation a un besoin légitime et durable de dépasser la limite par défaut, demandez une augmentation de quota plutôt que de fonctionner à la limite.
• Alerte avant d'atteindre la limite de quota Créez une alerte Cloud Monitoring qui se déclenche lorsque l'utilisation atteint 80 % de votre limite, en comparant serviceruntime.googleapis.com/quota/rate/net_usage à serviceruntime.googleapis.com/quota/limit, filtré sur metric.label.quota_metric="sts.googleapis.com/workforce_requests".
• Maintenez l'accès d'urgence. Assurez-vous qu'au moins un administrateur peut accéder à votre organisation sans la fédération des identités des employés, afin de pouvoir toujours agir si l'échange de jetons est limité.

Pour afficher votre utilisation et votre limite actuelles, accédez à la page "Quotas" de la console Google Cloud , sélectionnez votre organisation comme ressource, puis filtrez par Workforce Pool token exchange requests.

Gérer les fournisseurs de pools d'identités de personnel

Un fournisseur de pools d'identités de personnel définit une relation de fédération avec un IdP externe et contient la configuration des éléments suivants :

• Fournisseur d'identité à utiliser pour l'authentification unique.
• Mappage d'attributs à utiliser pour dériver les identifiants de principal à partir des jetons ou des assertions fournis par l'IdP.
• Facultatif : locataire SCIM à utiliser pour rechercher des informations sur l'appartenance à un groupe.

Choisissez un nom de fournisseur pertinent

Lorsque vous créez un fournisseur de pool d'identités de personnel, vous devez lui attribuer un nom. Contrairement aux noms de pools d'identités de personnel, ce nom n'a pas besoin d'être unique au monde et n'est pas encodé dans les identifiants de comptes principaux. Toutefois, selon votre configuration de connexion, les utilisateurs devront peut-être saisir le nom du fournisseur lors de la connexion. Pour améliorer l'expérience utilisateur, choisissez un nom explicite et facile à mémoriser, par exemple entra ou staff.

Évitez d'utiliser des noms tels que oidc ou saml, car ces acronymes peuvent ne pas être familiers aux utilisateurs.

Afficher des services individuels dans le portail de votre application IdP

Les fournisseurs d'identité tels que Microsoft Entra ID et Okta fournissent un portail d'applications qui permet aux utilisateurs de découvrir les applications qui leur sont attribuées et d'y accéder. Utilisez le portail pour optimiser l'expérience utilisateur en procédant comme suit :

• Configurez le portail pour qu'il affiche les services Google pertinents individuellement au lieu d'un seul lien Google Cloud .
• Configurez des liens pour connecter l'utilisateur automatiquement.

Le tableau suivant liste les services Google courants compatibles avec la fédération d'identité de personnel et les URL de connexion automatique :

Remplacez les éléments suivants :

• POOL : nom du pool d'identités de personnel.
• PROVIDER : nom du fournisseur du pool.
• WEBAPP_ID : ID de l'application Web Gemini Enterprise.
• PROJECT_NUMBER : numéro du projet Gemini Notebook Enterprise.

Utiliser un seul fournisseur par pool pour éviter les conflits de sujet

Vous pouvez utiliser la fédération des identités des employés pour ajouter plusieurs fournisseurs à un pool d'employés. L'ajout d'un deuxième fournisseur est utile lors des migrations où vous autorisez temporairement les utilisateurs à s'authentifier à l'aide de différents IdP. Au-delà des situations temporaires, évitez d'utiliser plusieurs fournisseurs pour les raisons suivantes :

• Conflits de sujets : l'utilisation de plusieurs fournisseurs présente un risque de conflits de sujets. Dans ce cas, le mappage d'attributs google.subject d'un fournisseur renvoie la même valeur que celui d'un autre fournisseur. Cette collision mappe plusieurs identités externes sur le même compte principal IAM, ce qui les rend impossibles à distinguer dans Cloud Audit Logs.
• Compatibilité avec IAP : IAP nécessite que les pools d'identités des employés disposent d'un seul fournisseur pour rediriger automatiquement les utilisateurs non authentifiés vers l'IdP. Si vous ajoutez un fournisseur supplémentaire, IAP ne peut pas authentifier les utilisateurs.

Si vous devez fédérer avec plusieurs fournisseurs, créez plusieurs pools de personnel et configurez un fournisseur pour chaque pool.

Utiliser le même pool et le même fournisseur pour la console Google Cloud et Gemini Enterprise

Si vous utilisez la fédération d'identité de personnel pour Gemini Enterprise et Google Cloud, utilisez un seul fournisseur pour que les utilisateurs puissent accéder aux deux services simultanément sans avoir à se reconnecter. Si vous utilisez des fournisseurs distincts avec des mappages d'attributs différents, les utilisateurs peuvent se retrouver dans des situations où leur accès aux ressources diffère selon le fournisseur avec lequel ils se connectent.

Utiliser un URI d'émetteur spécifique au locataire

Lorsque vous configurez un fournisseur, vous spécifiez un URI d'émetteur pour identifier de manière unique votre IdP. Toutefois, selon la configuration de votre IdP, l'URI de l'émetteur peut ne pas être unique pour le locataire de votre organisation. Par exemple, si vous utilisez un URI d'émetteur générique ou partagé, tel que le point de terminaison commun Microsoft Entra ID (https://login.microsoftonline.com/common/v2.0), vous risquez d'autoriser par inadvertance des utilisateurs d'autres organisations à s'authentifier auprès de votre organisation Google Cloud.

Pour éviter tout accès non intentionnel entre locataires, utilisez un URI d'émetteur spécifique au locataire. Si votre IdP ne fournit pas d'URI d'émetteur spécifique au locataire, configurez une condition d'attribut pour limiter l'accès à votre locataire spécifique.

Éviter d'utiliser le flux implicite OpenID Connect (OIDC)

Lorsque vous configurez un fournisseur OIDC, privilégiez le flux avec code d'autorisation par rapport au flux implicite. Le flux implicite est obsolète dans la version 2.1 de la spécification OAuth, car il est vulnérable aux fuites et aux injections de jetons. L'utilisation du flux avec code d'autorisation permet de réduire le risque d'interception des jetons.

Gérer les utilisateurs

Vous pouvez gérer les utilisateurs à l'aide de la fédération d'identité de personnel. La fédération d'identité de personnel dérive l'identifiant principal d'un utilisateur à partir de son jeton ou de son assertion en procédant comme suit :

1. Déterminez l'identifiant de sujet en appliquant le mappage d'attributs pour google.subject. L'identifiant du sujet doit identifier de manière unique un utilisateur au sein d'un pool d'identités d'employés, mais il n'est pas nécessaire qu'il soit unique dans Google Cloud.

2. Dérivez l'identifiant du compte principal en ajoutant l'identifiant du sujet à un préfixe qui identifie le pool d'identités des employés. L'identifiant du compte principal obtenu est unique dans Google Cloud et se présente au format suivant :

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

Lorsqu'un utilisateur authentifié à l'aide de la fédération d'identité des employés accède à une ressource, IAM utilise l'identifiant du compte principal pour évaluer les liaisons de rôles dans les stratégies d'autorisation et l'enregistre dans Cloud Audit Logs.

Utiliser un identifiant de sujet immuable

Lorsque l'identifiant de sujet d'un utilisateur change, son identifiant de compte principal change également. Par conséquent, Google Cloud ne les reconnaît plus comme le même utilisateur :

• L'utilisateur ne peut pas accéder aux ressources auxquelles il avait précédemment accès, car son nouvel identifiant de compte principal ne correspond plus aux identifiants de compte principal listés dans les stratégies d'autorisation.
• Les entrées Cloud Audit Logs ne contiennent que le nouvel identifiant du compte principal et ne peuvent plus être corrélées avec les journaux qui utilisaient l'ancien identifiant du compte principal.

Pour que l'identifiant principal d'un utilisateur reste stable, utilisez un mappage d'attributs qui génère une valeur stable pour google.subject.

De nombreux fournisseurs d'identité génèrent automatiquement un identifiant numérique unique ou au format UUID pour les utilisateurs. Ces identifiants sont uniques et stables, ce qui en fait de bons candidats pour google.subject. Toutefois, l'utilisation de ces identifiants en tant que google.subject peut entraîner des identifiants de comptes principaux longs et énigmatiques, qui peuvent être difficiles à utiliser.

Pour vous aider à choisir un identifiant pour google.subject, tenez compte des exigences suivantes par ordre de priorité décroissant :

1. Unicité : la valeur identifie de manière unique un utilisateur dans votre IdP.
2. Facilité d'utilisation : la valeur est significative ou, au moins, facilement consultable dans l'annuaire d'utilisateurs de votre IdP.
3. Immuabilité : la valeur est immuable ou, du moins, ne peut être modifiée que par les administrateurs.

Ne réutilisez pas les identifiants de sujet

De nombreux fournisseurs d'identité appliquent des contraintes d'unicité à certains identifiants utilisateur, mais autorisent leur réutilisation. Par exemple, un IdP peut ne pas vous autoriser à créer deux utilisateurs avec le même nom d'utilisateur bob. Toutefois, une fois que vous avez supprimé le compte utilisateur bob, l'IdP peut vous autoriser à créer un compte utilisateur et à lui attribuer à nouveau le nom d'utilisateur bob.

Si le mappage d'attributs de votre fournisseur pour google.subject fait référence à un identifiant utilisateur qui autorise la réutilisation, vous pouvez rencontrer des collisions de sujets : la fédération d'identité de personnel ne peut pas faire la distinction entre un ancien utilisateur et un nouvel utilisateur si leur google.subject est identique. Par conséquent, le nouvel utilisateur peut accéder à des ressources destinées uniquement à l'ancien utilisateur.

Pour éviter les collisions de sujets, effectuez l'une des opérations suivantes ou les deux :

• Mappez google.subject à un identifiant utilisateur que votre IdP ne permet pas de réutiliser.
• Lorsque vous supprimez un utilisateur dans votre IdP, utilisez l'API locations.workforcePools.subjects.delete pour supprimer les données de l'utilisateur dans Google Cloud et empêcher l'utilisation du même identifiant utilisateur pour les connexions jusqu'à ce que toutes les données aient été purgées.

Microsoft Entra ID : utiliser l'UPN comme identifiant de l'objet

Cette bonne pratique ne s'applique que si vous utilisez Microsoft Entra ID comme IdP.

Si vous utilisez Microsoft Entra ID, les identifiants que vous pouvez utiliser comme identifiant de sujet incluent les suivants :

• Nom principal de l'utilisateur (upn)
• ID d'objet (oid)
• Adresse e-mail (l'adresse principale dans proxyAddresses)

Parmi ces options, nous vous recommandons d'utiliser le nom d'utilisateur principal comme identifiant de l'objet pour les raisons suivantes :

• Tous les utilisateurs ont un nom d'utilisateur principal.
• Les noms d'utilisateur principaux identifient un utilisateur de manière unique.
• Les noms d'utilisateur principaux sont généralement explicites et faciles à utiliser.
• Les noms d'utilisateur principaux intègrent un nom de domaine qui identifie de manière unique le locataire Microsoft Entra ID auquel l'utilisateur est associé.
• Votre organisation peut avoir mis en place une règle qui interdit ou régit la réutilisation des identifiants principaux des utilisateurs.

En revanche, l'ID d'objet et l'adresse e-mail d'un utilisateur sont moins adaptés pour les raisons suivantes :

• Un ID d'objet (oid) est immuable, mais formaté en tant que GUID. Ce format les rend difficiles à utiliser et peu compréhensibles pour les humains.
• L'adresse e-mail n'est pas un attribut obligatoire et peut ne pas être renseignée pour tous les utilisateurs.

Quel que soit l'identifiant que vous choisissez, nous vous recommandons d'éviter d'appliquer des transformations, par exemple en forçant les identifiants à être en minuscules.

Gérer les groupes

La fédération des identités des employés peut déterminer l'appartenance d'un utilisateur à un groupe à partir des sources suivantes :

• L'assertion SAML ou le jeton d'ID fourni par l'IdP.
• L'API Microsoft Graph, si vous utilisez Microsoft Entra ID comme IdP.
• Le locataire SCIM associé au fournisseur de pools d'identités de personnel.

Par défaut, la fédération d'identité des employés n'utilise que l'assertion SAML ou le jeton d'ID :

Si vous utilisez Microsoft Entra ID comme IdP, vous pouvez activer la fonctionnalité d'attributs supplémentaires. La fédération des identités des employés n'utilise alors que l'API Microsoft Graph comme source pour les appartenances aux groupes :

Si vous utilisez Gemini Enterprise, vous pouvez configurer la fédération d'identité de personnel pour utiliser un locataire SCIM, ce qui modifie le comportement comme suit :

• Gemini Enterprise utilise les appartenances à des groupes du locataire SCIM et ignore les informations d'appartenance à un groupe provenant de l'assertion SAML ou du jeton d'ID.
• Google Cloud utilise les informations d'appartenance à un groupe de l'assertion SAML ou du jeton d'ID, et ignore les informations d'appartenance à un groupe du locataire SCIM.

Pour chaque appartenance à un groupe, la fédération des identités des employés dérive un identifiant de compte principal en procédant comme suit :

1. Déterminez l'identifiant du groupe en effectuant l'une des opérations suivantes :
   • Assertion SAML ou jeton d'ID : appliquez le mappage d'attributs pour google.groups.
   • Locataire SCIM : appliquez le mappage de revendication pour google.group.
   • API Microsoft Graph : suivez extra-attributes-type dans la configuration du fournisseur.

2. Dérivez l'identifiant du compte principal en ajoutant l'identifiant du groupe à un préfixe qui identifie le pool d'identités des employés. L'identifiant du compte principal obtenu est unique dans Google Cloud et se présente au format suivant :

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

Lorsqu'un utilisateur authentifié à l'aide de la fédération d'identité des employés accède à une ressource, IAM utilise ces identifiants de compte principal pour évaluer les liaisons de rôles dans les stratégies d'autorisation.

Utiliser un identifiant de groupe immuable

Toutes les stratégies IAM font référence aux groupes par leur identifiant principal. Lorsque vous renommez un groupe dans votre IdP de sorte que son identifiant change,Google Cloud ne le reconnaît plus comme le même groupe :

• Les liaisons de rôles IAM existantes continuent de faire référence à l'ancien identifiant du compte principal et deviennent inefficaces.
• Les membres du groupe renommé perdent l'accès, car le nouvel identifiant principal du groupe ne correspond plus à aucune liaison de rôle IAM.

Pour éviter ces perturbations, configurez votre mappage d'attributs et de revendications de manière à utiliser une valeur stable et immuable, telle qu'un ID unique généré par l'IdP. Évitez d'utiliser des noms à afficher ou des adresses e-mail comme identifiants de groupe, car ils peuvent changer lors de modifications organisationnelles.

Réduire les appartenances à des groupes dans les assertions ou les jetons

Par défaut, votre IdP peut inclure plus d'appartenances à des groupes dans les assertions SAML ou les jetons d'ID que ce dont vous avez besoin pour gérer l'accès à Gemini Enterprise et aux ressources Google Cloud . L'inclusion d'appartenances à des groupes inutiles crée plusieurs risques :

• Perte partielle d'accès : de nombreux IdP imposent des limites au nombre d'appartenances à un groupe qu'ils peuvent inclure dans un jeton ou une assertion. Lorsqu'un utilisateur dépasse cette limite (dépassement de groupe), l'IdP peut supprimer certaines appartenances à des groupes, ce qui entraîne la perte de l'accès à certaines ressources.
• Échecs de connexion : la fédération d'identité de personnel limite la taille et le nombre d'appartenances à des groupes que le mappage d'attributs google.groups peut produire. Les utilisateurs qui dépassent l'une de ces limites ne peuvent pas se connecter.
• Utilisation incohérente des groupes : si vous exposez des groupes à Google Cloud, les propriétaires de projet peuvent décider d'utiliser ces groupes pour gérer l'accès aux ressources, même si vous n'avez jamais prévu que certains groupes soient utilisés dansGoogle Cloud.

Les approches suivantes peuvent vous aider à atténuer ces risques et à réduire le nombre d'appartenances à des groupes dans les assertions ou les jetons :

• Filtrer par type de groupe : certains IdP, y compris Microsoft Entra ID, vous permettent de configurer un filtre qui détermine les groupes à inclure dans les assertions ou les jetons. Vous pouvez configurer un filtre pour exclure les types de groupes qui ne sont pas pertinents en fonction de votre configuration et des services que vous prévoyez d'utiliser.

  Le tableau suivant indique les types de groupes que vous devrez peut-être inclure dans les assertions ou les jetons, en fonction des services que vous prévoyez d'utiliser :

  Type de groupe	Google Cloud	Gemini (sans synchronisation)	Gemini (SCIM)
  Groupes d'accès			-
  Groupes de mesures d'application			-
  Groupes organisationnels	Pas nécessaires	*	-
  Groupes de collaboration	Pas nécessaires	*	-

  * Obligatoire uniquement si vous utilisez des connecteurs basés sur l'ingestion de données.

  • Pour gérer l'accès à Google Cloud, vous devez inclure des groupes d'accès et des groupes d'application.
  • Le filtre requis pour gérer l'accès à Gemini Enterprise dépend de si vous utilisez SCIM. Si vous utilisez SCIM, Gemini Enterprise ignore les appartenances à des groupes incluses dans les assertions ou les jetons. Vous n'avez donc pas besoin d'inclure de groupes spécifiques à Gemini Enterprise. Si vous n'utilisez pas SCIM, vous devez inclure les groupes d'accès et d'application nécessaires pour Gemini Enterprise. Selon que vous prévoyez d'utiliser ou non des connecteurs basés sur l'ingestion de données, vous devrez peut-être également inclure certains groupes d'organisation et de collaboration.

• Attribution : certains IdP, y compris Microsoft Entra ID, vous permettent de limiter les appartenances à des groupes dans les jetons et les assertions aux groupes attribués, qui sont les groupes que vous attribuez explicitement à la configuration de la partie de confiance.

• Filtre d'attributs supplémentaires : si vous utilisez Microsoft Entra ID et que vous avez activé la fonctionnalité d'attributs supplémentaires, vous pouvez spécifier un filtre à l'aide de l'option --extra-attributes-filter. La fédération des identités des employés transmet ce filtre à l'API Microsoft Graph lorsqu'elle demande les appartenances à un groupe.

Pour tester ou résoudre les problèmes liés aux filtres, utilisez l'outil Déboguer le jeton IdP dans la console Google Cloud ou activez la journalisation d'audit détaillée.

Microsoft Entra ID : utiliser l'ID d'objet comme identifiant de groupe

Cette bonne pratique ne s'applique que si vous utilisez Microsoft Entra ID comme IdP.

Si vous utilisez Microsoft Entra ID, les identifiants que vous pouvez utiliser comme identifiant de groupe incluent les suivants :

• ID d'objet (oid)
• Adresse e-mail
• Nom à afficher

Parmi ces options, nous vous recommandons d'utiliser l'ID d'objet (oid) comme identifiant de groupe pour les raisons suivantes :

• Tous les groupes ont un ID d'objet. En revanche, l'adresse e-mail est un champ facultatif qui ne peut être renseigné que pour les groupes Microsoft 365.
• L'ID d'objet est unique et immuable. En revanche, le nom à afficher d'un groupe peut changer et n'est pas forcément unique.

Quel que soit l'identifiant que vous choisissez, nous vous recommandons d'éviter d'appliquer des transformations, comme forcer les identifiants en minuscules.

Gérer l'accès

Bonnes pratiques pour les limites d'accès et la gestion juste-à-temps (JIT).

Utiliser des utilisateurs Cloud Identity pour l'accès d'urgence

Pour garantir un accès continu à vos environnements Google Cloud , créez des utilisateurs d'accès d'urgence pour chaque environnement.

Les utilisateurs disposant d'un accès d'urgence fournissent un accès à votre environnement Google Cloud lorsque les services sont mal configurés, compromis ou ne fonctionnent pas normalement. Les utilisateurs disposant d'un accès d'urgence disposent de privilèges élevés. S'appuyer sur la fédération d'identité de personnel pour authentifier les utilisateurs d'accès d'urgence présente les risques suivants :

• Une erreur dans la configuration du fournisseur de pools d'identités des employés peut vous empêcher d'accéder à votre compte.
• Une interruption de service affectant l'IdP externe peut vous empêcher d'utiliser un utilisateur d'accès d'urgence lorsque vous en avez le plus besoin.
• Une compromission de l'IdP externe peut permettre à des acteurs malintentionnés de s'authentifier en tant qu'utilisateur d'accès d'urgence et d'obtenir un accès étendu à vos ressources Google Cloud.

Pour limiter ces risques, utilisez Cloud Identity ou Google Workspace pour les utilisateurs disposant d'un accès d'urgence, même si vous utilisez la fédération d'identité de personnel pour les autres utilisateurs :

• Créez des utilisateurs d'accès d'urgence dans Cloud Identity.
• Excluez ces utilisateurs de l'authentification unique et autorisez-les à s'authentifier à l'aide d'un nom d'utilisateur et d'un mot de passe.
• Sécurisez ces utilisateurs en les inscrivant à la validation en deux étapes avec une clé de sécurité.

Pour en savoir plus sur les utilisateurs d'accès d'urgence, consultez Bonnes pratiques pour un accès continu à Google Cloud.

Utiliser Cloud Identity pour l'accès hautement privilégié

Les utilisateurs disposant de privilèges élevés ont un accès étendu à votre environnement Google Cloud. Voici quelques exemples de ces utilisateurs :

• Utilisateurs disposant du rôle Administrateur de l'organisation (roles/resourcemanager.organizationAdmin)
• Utilisateurs disposant du rôle Administrateur de sécurité (roles/iam.securityAdmin) ou d'un rôle similaire pouvant modifier les stratégies d'autorisation sur des parties importantes de votre hiérarchie de ressources Google Cloud

Si vous utilisez la fédération des identités des employés pour les utilisateurs disposant de privilèges élevés, toute mauvaise configuration ou compromission de votre IdP externe peut avoir un impact sur la sécurité de vos ressources Google Cloud . En particulier, une compromission de l'IdP externe peut permettre à des acteurs malintentionnés de s'authentifier en tant qu'utilisateur disposant de privilèges élevés et d'obtenir un accès étendu à vos ressources Google Cloud .

Pour atténuer ces risques, utilisez Cloud Identity pour les utilisateurs disposant de privilèges élevés :

• Créez des utilisateurs disposant de privilèges élevés dans Cloud Identity.
• Sécurisez ces utilisateurs en les inscrivant à la validation en deux étapes avec une clé de sécurité.
• Si vous avez fédéré Cloud Identity avec un IdP externe, activez les validations SSO supplémentaires et la validation en deux étapes pour ces utilisateurs.

Ces validations supplémentaires peuvent sembler redondantes si votre IdP applique déjà l'authentification multifacteur, mais ce paramètre peut aider à protéger les utilisateurs en cas de piratage de votre fournisseur d'identité. Les validations SSO supplémentaires sont une fonctionnalité compatible avec Cloud Identity, mais indisponible pour la fédération des identités des employés.

Utiliser des contraintes de règles d'administration pour gérer la fédération

Si vous utilisez Cloud Identity à des fins autres que l'accès d'urgence ou l'accès hautement privilégié, partitionnez votre utilisation de la fédération Cloud Identity et de la fédération d'identité de personnel par service. Pour appliquer cette pratique, utilisez des contraintes de règles d'administration personnalisées afin de limiter les types de comptes principaux autorisés dans des projets spécifiques.

Par exemple, vous pouvez limiter la fédération d'identité de personnel à Gemini Enterprise en procédant comme suit :

• Appliquez une contrainte de règle d'administration personnalisée à votre projet Gemini Enterprise qui utilise la fonction MemberTypeMatches pour limiter les types de comptes principaux autorisés à iam.googleapis.com/WorkforcePoolPrincipal et iam.googleapis.com/WorkforcePoolPrincipalSet. Il s'agit des types de comptes principaux utilisés par la fédération d'identité de personnel.
• Pour tous les autres projets, appliquez une contrainte qui autorise tous les types de comptes principaux, à l'exception de iam.googleapis.com/WorkforcePoolPrincipal et iam.googleapis.com/WorkforcePoolPrincipalSet.

L'utilisation de contraintes de règles d'administration personnalisées vous aide à assurer la cohérence et à éviter l'utilisation accidentelle de types de comptes principaux incorrects.

N'accordez pas l'accès à tous les membres d'un pool

La fédération d'identité de personnel est compatible avec un identifiant de compte principal générique au format suivant :

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

Cet identifiant correspond à tous les utilisateurs que votre IdP autorise à s'authentifier auprès deGoogle Cloud.

N'utilisez pas cet identifiant générique pour accorder des autorisations. À mesure que la base d'utilisateurs de votre IdP s'agrandit, l'octroi d'un accès avec l'identifiant principal générique entraîne une sur-autorisation.

Créez plutôt des groupes d'accès dans votre IdP et utilisez-les pour gérer l'accès aux ressources. Cette approche permet de s'assurer que l'accès est régi par l'appartenance intentionnelle à un groupe plutôt que par une authentification réussie, ce qui réduit le risque d'octroi d'autorisations excessives.

Limiter la durée des sessions

Lorsqu'un utilisateur se connecte, la fédération d'identité des employés lance une session. La session permet à un utilisateur d'effectuer les opérations suivantes :

• Utilisez la console (fédérée), Gemini Enterprise ou d'autres portails compatibles avec la fédération d'identité de personnel, et passez de l'un à l'autre.
• Utiliser des applications Web protégées par IAP
• Obtenez des jetons d'actualisation fédérés et des jetons d'accès fédérés, par exemple en exécutant gcloud auth login.

Une session reste valide jusqu'à ce que l'un des événements suivants se produise :

• La durée de la session atteint la limite définie par le pool d'identités des employés.
• La durée de la session atteint la limite définie dans l'attribut SessionNotOnOrAfter de l'assertion SAML de l'utilisateur, le cas échéant.
• L'utilisateur se déconnecte.
• Un administrateur révoque les sessions de l'utilisateur.

Autoriser les sessions à rester valides pendant de longues périodes augmente le risque de vol de jetons et peut entraîner l'obsolescence des informations d'appartenance au groupe :

• Les utilisateurs peuvent conserver l'accès plus longtemps que prévu si les autorisations sont révoquées dans l'IdP.
• Il est possible que les utilisateurs ne puissent pas exercer l'accès nouvellement accordé tant qu'ils ne se sont pas réauthentifiés et qu'ils n'ont pas établi une nouvelle session.

Pour limiter ces risques, limitez la durée de la session afin que les utilisateurs doivent se reconnecter au moins une fois par jour.

Aligner la durée de la session sur les exigences d'accès JIT

Pour gérer l'accès privilégié, vos IdP peuvent accepter les groupes juste-à-temps (JIT) que les membres peuvent activer temporairement. L'utilisation de groupes juste-à-temps pour gérer l'accès privilégié à Google Cloud ou à Gemini Enterprise peut présenter les risques suivants :

• Activation différée : si un utilisateur dispose d'une session de fédération des identités des employés active lors de l'activation de son appartenance à un groupe juste-à-temps, la modification de l'appartenance ne prend effet que lorsque l'utilisateur se déconnecte et se reconnecte. Si le fournisseur de pool d'identités de personnel utilise SCIM, la modification de l'appartenance ne prend effet que lorsque la modification de l'appartenance au groupe est provisionnée.
• Révocation différée : si l'appartenance à un groupe expire, l'utilisateur ne perd pas l'accès privilégié tant qu'il ne se déconnecte pas et ne se reconnecte pas, ou tant que la modification de l'appartenance au groupe n'est pas provisionnée à l'aide de SCIM. Selon la durée de votre session, ce délai peut aller à l'encontre de l'objectif de la durée de validité de l'inscription.

Pour limiter ces risques, configurez la durée de session de votre pool d'identités de personnel de manière à ce qu'elle soit suffisamment courte.

Surveiller l'activité

Chaque fois que vous remarquez une activité suspecte affectant une ressource dansGoogle Cloud, Cloud Audit Logs fournit des informations essentielles pour déterminer quand l'activité s'est produite et quels utilisateurs ont été impliqués.

Activer les journaux d'accès aux données

La fédération d'identité de personnel peut générer des journaux qui vous permettent de suivre les activités de connexion et d'échange de jetons. L'API Security Token Service écrit ces journaux, qui incluent les méthodes suivantes :

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

Tous les journaux liés aux activités de connexion et d'échange de jetons sont classés comme journaux d'accès aux données et sont désactivés par défaut. Pour capturer ces journaux, activez les journaux d'accès aux données pour l'API Security Token Service dans votre organisationGoogle Cloud . Pour augmenter encore le niveau de détail des journaux de connexion, activez la journalisation d'audit détaillée.

Pour suivre d'autres activités liées à l'authentification, nous vous recommandons d'activer et d'utiliser les journaux suivants :

• Journaux d'audit IAM SCIM
• Journaux d'audit des identifiants du compte de service
• Journaux d'audit de connexion Cloud Identity et Google Workspace

Étapes suivantes

• Consultez la Présentation de la fédération des identités des employés.
• Découvrez comment gérer les pools et les fournisseurs.
• Découvrez comment révoquer les sessions utilisateur de la fédération d'identité de personnel.