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

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

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

Choisir la bonne architecture

Les sections suivantes décrivent les principaux facteurs à prendre en compte pour choisir une architecture de fédération adaptée à vos besoins.

Considérations sur l'architecture :

Choisissez un modèle d'architecture de fédération.
Partitionnez l'utilisation de la fédération par service, et non par utilisateur.

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

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

Avant de fédérer, examinez les avantages et les limites de chaque modèle, puis choisissez celui qui correspond à vos besoins. Pour en savoir plus, consultez Schémas d'architecture pour la fédération d'identité.

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

En règle générale, nous vous recommandons de partitionner l'utilisation de la fédération par service plutôt que par utilisateur. La répartition 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 d'identité des employés. Toutefois, en fonction de vos besoins, vous devrez peut-être utiliser les 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 différentes manières :

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

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

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

      • La gestion des groupes d'accès peut être complexe, car les règles d'autorisation IAM doivent contenir une combinaison de types de principaux. De plus, vous ne pouvez pas utiliser les mêmes groupes pour les utilisateurs Cloud Identity et ceux de la fédération d'identité du personnel.

      • 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 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 NotebookLM Enterprise des autres services. Gemini Enterprise et la console Google Cloud sont des outils distincts conçus pour différentes tâches. Toute différence dans leurs processus de connexion devrait avoir un impact minimal sur l'expérience utilisateur globale.

Pour appliquer cette partition, utilisez des contraintes de règles d'administration.

Renforcer la gouvernance des groupes

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

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

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

  • Principal : utilisateur authentifié identifié par un identifiant principal. Un identifiant principal de pool d'identités des employés ressemble à ce qui suit : principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

    L'identifiant 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 des attributs.

  • Ensemble de 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 : ceux basés sur des groupes (membres d'un groupe), ceux basés sur des attributs et ceux basés sur des caractères génériques (tous les utilisateurs).

Accorder l'accès à des comptes individuels peut être utile dans certaines situations, mais cette approche a tendance à mal évoluer en raison des problèmes suivants :

  • L'ajout de comptes principaux un par un entraîne une augmentation du nombre de règles d'autorisation et rend leur gestion de plus en plus difficile.
  • La gestion des accès individuels nécessite des modifications fréquentes des règles 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 comptes principaux basés sur des groupes présente les avantages suivants :

  • Vous pouvez gérer l'accès en ajoutant ou en supprimant des membres de 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 afin de gérer l'accès, vous devez configurer votre fournisseur d'identité externe de certaines manières et être conscient des 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.

Bonnes pratiques

Distinguer les différents types de groupes
Utilisez des groupes d'accès pour accorder l'accès aux ressources.
Utilisez des groupes d'application pour limiter l'accès aux ressources.
N'utilisez pas les groupes organisationnels et de collaboration pour gérer les accès.
Utilisez les groupes de collaboration et les groupes organisationnels pour Gemini Enterprise uniquement.

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 Google ou aux ressourcesGoogle Cloud . Ils représentent des fonctions de travail et simplifient l'attribution des rôles requis pour effectuer ces fonctions.
  • 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 d'un projet ou des utilisateurs qui souhaitent collaborer sur un projet ou discuter d'un thème spécifique. Ils peuvent être utilisés pour la distribution d'e-mails. Les groupes de collaboration sont souvent créés de manière ad hoc et en libre-service.
  • Groupes d'application : les groupes d'application, également appelés groupes de règles, sont utilisés pour restreindre l'accès, contrairement aux groupes d'accès, qui sont utilisés pour accorder l'accès. Par exemple, les limites d'accès des comptes principaux, les stratégies de refus ou l'application de l'authentification multifacteur. Les groupes d'accès peuvent permettre aux membres de quitter volontairement un groupe. Toutefois, l'appartenance à un groupe chargé de l'application des règles n'est pas volontaire.

Les groupes que vous devez fédérer dépendent des services 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 organisationnels 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 de dépasser les limites de jetons avec votre IdP. Cette approche vous aide à réduire le risque de dépasser les limites imposées par votre IdP et à 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 principaux qui correspondent à des groupes d'accès. Les groupes d'accès n'existent que pour fournir un accès. Ils représentent des fonctions professionnelles et simplifient l'attribution des rôles requis pour les exercer.

Pour configurer les groupes d'accès :

  1. Dans votre IdP, créez des groupes d'accès qui représentent les 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 leur fonction.

Utilisez des groupes d'accès pour les règles 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 efficaces :

  • 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 conviennent généralement pas pour servir de groupes d'accès :

    • Les groupes d'administrateurs généraux tels que cloud-admins manquent souvent de spécificité quant aux charges de travail ou aux environnements auxquels ils s'appliquent.

    • Les groupes organisationnels, comme australia-fte, représentent des groupes tels que des équipes ou des groupes par emplacement, plutôt que par fonction.

    • Les groupes de communication, comme security-discuss, sont conçus pour les listes de diffusion ou la collaboration, et non pour les groupes d'accès.

    Pour affiner les groupes d'accès, créez un nouvel 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 présentent généralement les différences suivantes :

  • 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 principales
  • Règles d'administration

users-in-restricted-locations, fedramp-low et mfa-users sont des exemples de groupes d'application. Le nombre de groupes d'application est généralement faible et n'a probablement pas d'incidence sur le nombre total de groupes auxquels un utilisateur est membre.

N'utilisez pas les groupes d'organisation et de collaboration pour gérer l'accès

Pour gérer efficacement l'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 conviennent pas à 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 confier 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 des 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 de l'organisation 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 ou sans l'approbation d'un autre membre. L'utilisation de groupes de collaboration pour accorder l'accès peut entraîner une surautorisation 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 afin d'exclure ces appartenances aux 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 de collaboration et d'organisation 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 est possible que vous rencontriez 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 est possible qu'il n'évalue pas correctement si l'utilisateur est autorisé à accéder à ces documents.
  • Partage de notebooks : NotebookLM permet aux utilisateurs de partager des notebooks. Il est souvent plus pratique d'autoriser les utilisateurs à partager des notebooks avec des groupes de collaboration que de limiter le partage à des utilisateurs individuels.

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

  • Utilisez SCIM pour provisionner des groupes d'organisation et de collaboration, ainsi que leurs membres.
  • Excluez les appartenances aux groupes de collaboration et à l'organisation 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 de personnel définit un espace de noms pour les identifiants principaux et sert de conteneur pour votre configuration de fédération. Contrairement à un répertoire d'utilisateurs, un pool ne stocke pas d'informations sur les utilisateurs ni sur les groupes.

Bonnes pratiques

Utilisez un seul pool par IdP.
Choisissez un nom de pool unique et pertinent.
Considérez les pools comme des ressources à accès privilégié.
Tenez compte des risques lorsque vous étendez la fédération à des partenaires.

Utiliser un seul pool par IdP

Les pools d'identités de personnel sont des ressources 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 dans une organisation Google Cloud , plutôt que dans un projet ou une charge de travail individuels.

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

  • 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 vous assurer des 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 .

 Choisir un nom de pool unique et pertinent

Pour rendre les identifiants principaux uniques au niveau mondial, l'identité de personnel encode le nom du pool d'identités de personnel dans l'identifiant principal. 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 déjà utilisé 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 et évitez les noms d'initiatives temporaires.
  • Expérience utilisateur : en fonction de votre configuration de connexion, les utilisateurs peuvent être amenés à saisir le nom du pool lors de la connexion. Choisissez un nom court et facile à retenir.

Traiter les pools comme des ressources à privilèges élevés

Le pool et le fournisseur d'identité du personnel déterminent la façon 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. Étant donné que ces composants contrôlent la logique d'authentification, ils sont essentiels à la sécurité de votre organisation Google Cloud . Si ces composants sont compromis, des acteurs malintentionnés peuvent lancer des attaques de spoofing.

Pour lancer une attaque de spoofing, les acteurs malintentionnés peuvent tenter les actions suivantes :

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

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

  • Restreignez 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 disposant d'un accès d'urgence.
  • Protégez les utilisateurs administratifs : exigez la validation en deux étapes pour tous les utilisateurs administratifs et ceux ayant accès en cas d'urgence.
  • Accès avec le juste-à-temps : utilisez Privileged Access Manager (PAM) pour accorder un accès administrateur au moment opportun plutôt qu'un accès permanent.

Tenir compte des risques lorsque vous étendez la fédération à des partenaires

La fédération 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é.
  • Faire des assertions précises concernant les identités des utilisateurs et les appartenances aux groupes.
  • Suivez les processus de gouvernance des identités pour vous assurer que les utilisateurs sont désactivés rapidement et que les appartenances aux groupes reflètent fidèlement 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 d'identité de personnel n'est pas compatible avec l'authentification multifacteur post-SSO de la même manière que Cloud Identity.

Avant d'utiliser la fédération d'identité de personnel pour autoriser des partenaires ou des sous-traitants externes à accéder à vos ressources Google Cloud , déterminez si ce niveau de confiance est approprié. N'utilisez pas la fédération d'identité de personnel pour l'accès des partenaires, sauf si vous êtes sûr que le partenaire et son IdP respectent systématiquement vos normes de sécurité.

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

Un fournisseur de pools d'identités des employés 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 le fournisseur d'identité.
  • Facultatif : locataire SCIM à utiliser pour rechercher des informations sur l'appartenance à un groupe.

Bonnes pratiques

Choisissez un nom de fournisseur explicite.
Utilisez le portail d'applications de votre IdP pour exposer des services individuels.
Utilisez un seul fournisseur par pool pour éviter les conflits de sujet.
Utilisez le même pool et le même fournisseur pour la console Google Cloud et Gemini Enterprise.
Utiliser un URI d'émetteur spécifique au locataire.
Évitez d'utiliser le flux implicite OpenID Connect (OIDC).

Choisissez un nom de fournisseur explicite

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 à l'échelle mondiale et n'est pas encodé dans les identifiants 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 à retenir, par exemple entra ou staff.

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

Afficher des services individuels dans le portail d'applications de votre IdP

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

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

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

Application URL
Google Cloud  Console de fédération des identités des employés, également appelée console (fédérée) 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
Applications Web IAP URL de l'application, par exemple https://iap.example.com/

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 NotebookLM Enterprise.

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

Vous pouvez utiliser la fédération d'identité des employés pour ajouter plusieurs fournisseurs à un pool de personnel. 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 de tels conflits, le mappage d'attributs google.subject d'un fournisseur renvoie la même valeur qu'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 exige que les pools d'identités des employés ne comportent qu'un seul fournisseur pour rediriger automatiquement les utilisateurs non authentifiés vers l'IdP. Si vous ajoutez un autre fournisseur, IAP ne peut pas authentifier les utilisateurs.

Si vous devez fédérer avec plusieurs fournisseurs, créez plusieurs pools d'effectifs 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 vous assurer que les utilisateurs peuvent 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 rencontrer 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 n'est pas forcément unique au 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 pouvez autoriser par inadvertance des utilisateurs d'autres organisations à s'authentifier auprès de votre organisation Google Cloud.

Pour éviter tout accès non souhaité entre locataires, utilisez un URI d'émetteur spécifique au locataire. Si votre IdP ne fournit pas d'URI d'émetteur spécifique à un 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, préférez le flux avec code d'autorisation 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 de jetons.

Gérer les utilisateurs

Vous pouvez gérer les utilisateurs à l'aide de la fédération des identités des employés. 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 dans un pool d'identités de personnel, mais n'a pas besoin d'être unique dans Google Cloud.

  2. Dérivez l'identifiant principal en ajoutant l'identifiant du sujet à un préfixe qui identifie le pool d'identités des employés. L'identifiant 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 principal pour évaluer les liaisons de rôle dans les stratégies d'autorisation et l'enregistre dans les Cloud Audit Logs.

Bonnes pratiques

Utilisez un identifiant de sujet immuable.
Ne réutilisez pas les identifiants de sujet.
Microsoft Entra ID : utilisez l'UPN comme identifiant de sujet.

Utiliser un identifiant de sujet immuable

Lorsque l'identifiant de sujet d'un utilisateur change, son identifiant principal change également. Par conséquent, Google Cloud ne les reconnaît plus comme étant 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 principal ne correspond plus aux identifiants principaux listés dans les règles d'autorisation.
  • Les entrées Cloud Audit Logs ne contiennent que le nouvel identifiant principal et ne peuvent plus être corrélées avec les journaux qui utilisaient l'ancien identifiant 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 IdP génèrent automatiquement un identifiant unique au format numérique ou 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 comme google.subject peut entraîner des identifiants de comptes principaux longs et cryptiques, 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 pertinente ou, au moins, facilement recherchable dans le répertoire utilisateur 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 IdP appliquent des contraintes d'unicité à certains identifiants utilisateur, mais autorisent la réutilisation des identifiants. Par exemple, un fournisseur d'identité 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, le fournisseur d'identité peut vous autoriser à créer un nouvel 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 réutilisable, vous risquez de rencontrer des collisions de sujet : la fédération d'identité Workforce ne peut pas faire la différence 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 :

Microsoft Entra ID : utiliser l'UPN comme identifiant du sujet

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 de l'objet (oid)
  • Adresse e-mail (adresse principale dans proxyAddresses)

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

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

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 n'a pas de sens pour les humains.
  • L'adresse e-mail n'est pas un attribut obligatoire et il est possible qu'elle ne soit pas renseignée pour tous les utilisateurs.

Quel que soit l'identifiant que vous choisissez, nous vous recommandons d'éviter d'appliquer des transformations telles que la mise en minuscules forcée des identifiants.

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 :

  • Assertion SAML ou jeton d'identité fournis par le fournisseur d'identité.
  • L'API Microsoft Graph, si vous utilisez Microsoft Entra ID comme IdP.
  • Locataire SCIM associé au fournisseur de pools d'identités de personnel.

Par défaut, la fédération d'identité de personnel n'utilise que l'assertion SAML ou le jeton d'identité :

Source Google Cloud Gemini Enterprise
Jeton SAML ou d'ID
API Microsoft Graph - -
Locataire SCIM - -

Si vous utilisez Microsoft Entra ID comme IdP, vous pouvez activer la fonctionnalité 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 :

Source Google Cloud Gemini Enterprise
Jeton SAML ou d'ID - -
API Microsoft Graph
Locataire SCIM - -

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 aux groupes du locataire SCIM et ignore les informations sur les appartenances aux groupes de l'assertion SAML ou du jeton d'identité.
  • Google Cloud utilise les informations d'appartenance à un groupe de l'assertion SAML ou du jeton d'identité, et ignore les informations d'appartenance à un groupe du locataire SCIM.
Source Google Cloud Gemini Enterprise
Jeton SAML ou d'ID -
API Microsoft Graph - -
Locataire SCIM -

Pour chaque appartenance à un groupe, la fédération d'identité des employés déduit un identifiant 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'identité : appliquez le mappage d'attributs pour google.groups.
    • Locataire SCIM : appliquez le mappage des revendications pour google.group.
    • API Microsoft Graph : suivez extra-attributes-type dans la configuration du fournisseur.

  2. Dérivez l'identifiant principal en ajoutant l'identifiant de groupe à un préfixe qui identifie le pool d'identités de personnel. L'identifiant 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ôle dans les stratégies d'autorisation.

Bonnes pratiques

Utilisez un identifiant de groupe immuable.
Réduisez le nombre d'adhésions à des groupes dans les assertions ou les jetons.
Microsoft Entra ID : utilisez l'ID d'objet comme identifiant de groupe.

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 fournisseur d'identité de sorte que son identifiant change,Google Cloud ne le reconnaît plus comme le même groupe :

  • Les liaisons de rôle IAM existantes continuent de faire référence à l'ancien identifiant 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 le mappage de vos attributs et revendications de manière à utiliser une valeur stable et immuable, comme un ID unique généré par le fournisseur d'identité. Évitez d'utiliser des noms à afficher ou des adresses e-mail comme identifiants de groupe, car ils peuvent changer en cas de modifications organisationnelles.

Réduire le nombre d'appartenances à des groupes dans les assertions ou les jetons

Par défaut, votre fournisseur d'identité peut inclure plus d'appartenances à des groupes dans les assertions SAML ou les jetons d'identité 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 de l'accès : de nombreux IdP imposent des limites au nombre d'appartenances à des groupes qu'ils peuvent inclure dans un jeton ou une assertion. Lorsqu'un utilisateur dépasse cette limite (dépassement de groupe), le fournisseur d'identité peut supprimer certaines appartenances à des groupes, ce qui peut entraîner la perte d'accès à certaines ressources.
  • Échecs de connexion : la fédération des identités des employés limite la taille et le nombre d'adhésions aux groupes que le mappage des 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 mise en 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 aux 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 les groupes d'application nécessaires pour Gemini Enterprise. Selon que vous prévoyez d'utiliser 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 fournisseurs d'identité, y compris Microsoft Entra ID, vous permettent de limiter les appartenances aux 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é Attributs supplémentaires, vous pouvez spécifier un filtre à l'aide de l'indicateur --extra-attributes-filter. La fédération des identités des employés transmet ce filtre à l'API Microsoft Graph lors de la demande d'appartenance à 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 de l'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 possèdent 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 telles que la mise en minuscules des identifiants.

Gérer l'accès

Bonnes pratiques concernant les limites d'accès et la gestion juste à temps

Bonnes pratiques

Utilisez des utilisateurs Cloud Identity pour l'accès d'urgence.
Utilisez Cloud Identity pour les accès à privilèges élevés.
Utiliser des contraintes de règles d'administration pour régir la fédération
N'accordez pas l'accès à tous les membres d'un pool.
Limitez la durée des sessions.
Alignez la durée de la session sur les exigences d'accès JIT.

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

Pour vous assurer d'avoir un accès continu à vos environnements Google Cloud , créez des utilisateurs ayant un accès d'urgence pour chacun d'eux.

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

  • Une erreur dans la configuration du fournisseur de pool d'identités de personnel peut vous empêcher d'accéder à votre compte.
  • Une interruption de service affectant l'IdP externe peut vous empêcher d'utiliser un compte utilisateur à accès d'urgence lorsque vous en avez le plus besoin.
  • Si le fournisseur d'identité externe est piraté, des personnes malintentionnées peuvent s'authentifier en tant qu'utilisateur disposant d'un accès d'urgence et obtenir un accès étendu à vos ressources Google Cloud.

Pour atténuer ces risques, utilisez Cloud Identity ou Google Workspace pour les utilisateurs ayant besoin 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 ayant accès en cas d'urgence dans Cloud Identity.
  • Excluez ces utilisateurs de l'authentification unique et laissez-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 ayant un accès d'urgence, consultez Bonnes pratiques pour un accès continu à Google Cloud.

Utiliser Cloud Identity pour un accès privilégié

Les utilisateurs disposant de droits é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)
  • Les utilisateurs disposant du rôle Administrateur de sécurité (roles/iam.securityAdmin) ou d'un rôle similaire leur permettant de modifier les stratégies d'autorisation dans des parties importantes de votre hiérarchie des ressources Google Cloud

Si vous utilisez la fédération des identités des employés pour les utilisateurs disposant de droits d'accès élevés, toute erreur de 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 malveillants de s'authentifier en tant qu'utilisateur disposant de privilèges élevés et d'accéder largement à vos ressources Google Cloud .

Pour atténuer ces risques, utilisez Cloud Identity pour les utilisateurs disposant de droits d'accès élevés :

  • Créez des utilisateurs disposant de droits d'accès é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 d'autres validations SSO 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 permet de protéger les utilisateurs en cas de piratage de l'IdP. Les vérifications SSO supplémentaires sont une fonctionnalité compatible avec Cloud Identity, mais pas avec la fédération des identités des employés.

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

Si vous utilisez Cloud Identity à des fins autres que l'accès d'urgence ou à privilèges élevés, 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. Voici les principaux types 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 principaux incorrects.

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

La fédération des identités des employés est compatible avec un identifiant principal générique au format suivant :

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

Cet identifiant correspond à chaque utilisateur 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 augmente, l'octroi d'accès avec l'identifiant principal générique entraîne un surdimensionnement des autorisations.

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 une appartenance intentionnelle à un groupe plutôt que par une authentification réussie, ce qui réduit le risque de sur-autorisation.

 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 des identités des employés, et naviguez entre eux.
  • Utilisez 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 de personnel.
  • 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.

Si vous autorisez les sessions à rester valides pendant de longues périodes, vous augmentez le risque de vol de jetons et vous pouvez rendre obsolètes les informations sur l'appartenance à un groupe :

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

Pour atténuer ces risques, limitez la durée des sessions 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 les accès privilégiés, vos IdP peuvent prendre en charge 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 entraîner les risques suivants :

  • Activation différée : si un utilisateur a une session de fédération des identités des employés active lorsqu'il active 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 qu'une fois la modification de l'appartenance au groupe provisionnée.
  • Révocation différée : si l'appartenance à un groupe expire, l'utilisateur ne perd pas son 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. En fonction de la durée de votre session, ce délai peut compromettre l'objectif de l'expiration de l'abonnement.

Pour atténuer ces risques, configurez la durée de session de votre pool d'identités de personnel de sorte 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é a eu lieu et quels utilisateurs ont été impliqués.

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

La fédération d'identité du 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 davantage la verbosité 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 :

Étapes suivantes