Schémas d'architecture pour la fédération d'identité

Ce document compare quatre modèles architecturaux pour fédérer Google Cloudavec un fournisseur d'identité (IdP) externe. Il fournit également des conseils pour vous aider à choisir une architecture adaptée à votre cas d'utilisation.

Voici les quatre modèles d'architecture :

Facteurs de décision

Pour choisir un modèle d'architecture adapté à votre organisation, tenez compte de plusieurs facteurs, y compris les suivants :

  • Portefeuille de services : votre portefeuille de services Google et s'il inclut Google Workspace et des services au-delà deGoogle Cloud, tels que Google Ads, Google Maps ou Chrome Enterprise.
  • Résidence des données : vos exigences en matière de résidence et de souveraineté des données.
  • Intégration de Gemini Enterprise à Microsoft 365 : votre utilisation de Gemini Enterprise ou de Gemini Notebook Enterprise, et si vous prévoyez d'intégrer Gemini Enterprise aux services Microsoft 365.

Portefeuille de services

Les services Google gèrent l'authentification et l'autorisation différemment. Cela affecte la façon dont vous configurez la fédération d'identité. Deux facteurs déterminent ces différences : le modèle de service (SaaS, PaaS ou IaaS) et le modèle d'autorisation (IAM ou spécifique au service).

Modèles de service

  • Software as a Service (SaaS) : Google gère entièrement des services tels que Gmail, Google Ads ou l'application Gemini Enterprise. Ces services ne nécessitent aucun effort de développement et sont prêts à l'emploi. Étant donné que les services SaaS ciblent une large audience, la plupart de vos utilisateurs peuvent avoir besoin d'y accéder.
  • Platform as a Service (PaaS) ou Infrastructure as a Service (IaaS) : la plupart des servicesGoogle Cloud sont des services PaaS ou IaaS. Ces services permettent aux utilisateurs techniques de développer, de déployer et d'exploiter des charges de travail personnalisées. Étant donné que ces services s'adressent à une audience technique, seul un sous-ensemble de vos utilisateurs a besoin d'y accéder.

Modèles d'autorisation

Les services Google implémentent l'autorisation de deux manières :

  • IAM : la plupart des services Google Cloud utilisent IAM pour permettre aux administrateurs de gérer un accès précis aux ressources.
  • Autorisation spécifique au service : les services tels que Google Ads, Looker ou Google Workspace n'utilisent pas IAM. À la place, les administrateurs gèrent l'accès à l'aide d'outils spécifiques à chaque service.

Ces facteurs entraînent les groupes de services suivants :

SaaS PaaS ou IaaS
Autorisation basée sur IAM Google Cloud Services SaaS tels que l'application Gemini Enterprise et Gemini Notebook Enterprise Google Cloud Services PaaS et IaaS tels que BigQuery ou Compute Engine
Autorisation spécifique au service Services Google non cloud, tels que Google Ads, Google Workspace et Google Maps Aucun

Pour choisir un modèle d'architecture adapté à votre organisation, identifiez les groupes de services qui s'appliquent à votre organisation.

Résidence des données

Cloud Identity, Google Workspace et la fédération des identités des employés traitent les informations personnelles des utilisateurs pour les authentifier et gérer les sessions. Ces informations utilisateur peuvent inclure les éléments suivants :

  • Noms d'utilisateur ou adresses e-mail
  • Attributs utilisateur tels que les prénoms et les noms
  • Noms et membres des groupes

Cloud Identity, Google Workspace et la fédération des identités des employés traitent ces données conformément aux conditions d'utilisation des données de service et peuvent les stocker en dehors des emplacements de votre organisation ou de vos utilisateurs :

  • Cloud Identity et Google Workspace stockent les données de service dans des centres de données Google et peuvent les répliquer dans tous les centres de données. Les données stockées peuvent inclure des informations non essentielles pour l'authentification, comme des noms de service, des adresses ou des numéros de téléphone.
  • La fédération d'identité du personnel stocke les données de service dans les régionsGoogle Cloud et peut les répliquer dans toutes les régions.

Si vous accordez à un utilisateur l'accès à une ressource, IAM stocke son identifiant principal dans une liaison de rôle. Google Cloud traite les liaisons de rôle conformément aux conditions applicables aux données de service et peut les stocker dans toutes les régions Google Cloud .

Les modèles d'architecture décrits sur cette page nécessitent le stockage des informations utilisateur, mais ils diffèrent dans la durée de stockage de ces informations :

De nombreux IdP vous permettent d'automatiser la suspension ou la suppression des comptes utilisateur lorsque l'état du compte utilisateur correspondant change dans l'IdP. En fonction de votre IdP et de sa configuration, il est possible qu'il retarde la suppression du compte utilisateur jusqu'à l'expiration d'un certain délai de grâce, ce qui peut prolonger la durée pendant laquelle Google Cloudstocke les informations utilisateur.

Intégration de Gemini Enterprise à Microsoft 365

Gemini Enterprise vous permet de vous connecter aux services Microsoft 365 à l'aide de deux types de connecteurs :

  • Connecteurs basés sur l'ingestion de données : ces connecteurs explorent Microsoft 365 pour créer un index de recherche dans Google Cloud. Lorsqu'un utilisateur envoie une requête, Gemini Enterprise utilise cet index pour rechercher du contenu et effectue des vérifications d'accès en local en évaluant les listes de contrôle d'accès (LCA) obtenues à partir de Microsoft 365.
  • Connecteurs fédérés : ces connecteurs interrogent Microsoft 365 pour chaque requête. Ils utilisent l'autorisation déléguée pour permettre à Microsoft 365 d'effectuer directement les vérifications d'accès.

Les connecteurs basés sur l'ingestion de données présentent des exigences spécifiques pour la fédération des utilisateurs :

  • Connaissance de l'appartenance à un groupe : les LCA Microsoft 365 peuvent inclure des entrées pour les groupes ainsi que pour les utilisateurs. Pour évaluer si un utilisateur peut accéder à un contenu, les connecteurs doivent tenir compte de tous les groupes auxquels il appartient. Si le connecteur n'a connaissance que d'un sous-ensemble des groupes de l'utilisateur, il peut autoriser ou refuser l'accès de manière incorrecte.
  • Conversion des identifiants : pour évaluer les LCA, le connecteur doit convertir les identifiants d'utilisateur et de groupe utilisés par Microsoft 365 en identifiants utilisés par Google Cloud.

Lorsque vous utilisez la fédération d'identité de personnel, Gemini Enterprise peut convertir de manière fiable les identifiants et évaluer les LCA si vous configurez des mappages d'attributs compatibles avec Gemini Enterprise.

Lorsque vous utilisez la fédération Cloud Identity ou Google Workspace, Microsoft Entra ID contrôle les mappages d'attributs pour le provisionnement des utilisateurs et des groupes, plutôt que Google Cloud. Entra détermine les règles de conversion pour les identifiants d'utilisateurs et de groupes, qui peuvent impliquer des transformations complexes. Pour évaluer une LCA, le connecteur Gemini Enterprise doit appliquer les mêmes règles de conversion, mais il n'a pas de visibilité sur la configuration Entra. Par conséquent, lorsque vous utilisez la fédération Cloud Identity ou Google Workspace, Gemini Enterprise ne peut pas convertir de manière fiable les identifiants d'utilisateurs et de groupes, ni évaluer de manière fiable les LCA.

Pour déterminer le modèle d'architecture qui convient à votre organisation, réfléchissez à votre utilisation de Gemini Enterprise et à la question de savoir si vous prévoyez d'utiliser des connecteurs basés sur l'ingestion de données.

Schémas d'architecture

L'organigramme suivant montre comment ces facteurs déterminent le modèle qui répond aux exigences de votre organisation :

Organigramme montrant comment sélectionner le modèle de fédération d'identité.

  1. Une part importante de votre organisation utilise-t-elle Google Workspace ?

  2. Utilisez-vous d'autres services que Google Cloud , comme Google Ads ou Google Maps ?

    • Si la réponse est Oui, passez à la décision 3.
    • Si la réponse est Non, passez à la décision 4.

  3. Prévoyez-vous d'utiliser Gemini Enterprise et de l'intégrer à Microsoft 365 ?

  4. Envisagez-vous d'utiliser Gemini Enterprise ?

  5. Avez-vous des exigences de résidence des données qui vous obligent à minimiser le stockage des informations utilisateur ?

Fédération Cloud Identity ou Google Workspace

Sélectionnez ce modèle si votre organisation répond à l'un des critères suivants :

  • Une part importante de votre organisation utilise déjà Google Workspace.
  • Vous utilisez des services Google au-delà de Google Cloud , comme Google Ads ou Google Maps, mais vous ne prévoyez pas d'intégrer Gemini Enterprise à Microsoft 365 à l'aide de connecteurs basés sur l'ingestion de données.
  • Vous n'utilisez que les services Google Cloud , vous ne prévoyez pas d'utiliser Gemini Enterprise et vous n'avez pas d'exigences strictes en matière de résidence des données pour minimiser le stockage des données utilisateur.

Dans ce modèle, vous n'utilisez pas la fédération d'identité de personnel. Au lieu de cela, vous fédérez votre compte Cloud Identity ou Google Workspace avec votre fournisseur d'identité, et vous utilisez le provisionnement anticipé des utilisateurs et des groupes.

Architecture de la fédération Cloud Identity et Google Workspace.

Dans ce modèle, vous devez provisionner les utilisateurs et les groupes avant qu'ils puissent se connecter. Sinon, leur tentative de connexion échouera :

  • Provisionnement des utilisateurs : permet d'intégrer et de désintégrer les utilisateurs rapidement.
  • Provisionnement de groupes : vous permet d'utiliser des groupes pour gérer l'accès aux services Google et aux ressources Google Cloud .

Si seul un sous-ensemble des utilisateurs de votre organisation a besoin de Google Workspace, ajoutez à la fois un abonnement Google Workspace et un abonnement Cloud Identity à votre compte, et n'attribuez des licences Google Workspace qu'aux utilisateurs qui en ont besoin.

Avantages

  • Les utilisateurs peuvent s'authentifier auprès des services Google, qu'ils utilisent IAM ou non. Dans le compte Cloud Identity ou Google Workspace, contrôlez les services Google que les utilisateurs sont autorisés à utiliser.
  • Vous pouvez limiter l'authentification unique (SSO) et le provisionnement anticipé à un sous-ensemble d'utilisateurs, et continuer à gérer des utilisateurs spécifiques, tels que les utilisateurs ayant accès en cas d'urgence, directement dans Cloud Identity ou Google Workspace.
  • Vous pouvez provisionner des groupes à partir de votre fournisseur d'identité externe, les gérer localement dans votre compte Cloud Identity ou Google Workspace, ou combiner les deux approches.

Limites

  • Le provisionnement des comptes utilisateur à l'avance ajoute des frais généraux et peut ralentir le processus d'intégration.

  • Vous ne pouvez pas contrôler ni limiter les lieux où Cloud Identity ou Google Workspace stockent les données utilisateur et de groupe. Étant donné que Google traite et stocke les données utilisateur et de groupe conformément aux conditions applicables aux données de service, les paramètres régionaux des données ne couvrent pas ces données. Google peut les répliquer dans les centres de données Google.

  • Gemini Enterprise offre une compatibilité limitée pour la connexion aux sources de données Microsoft lorsque vous utilisez la fédération Cloud Identity ou Google Workspace.

Fédération d'identité de personnel, sans synchronisation

Sélectionnez ce modèle lorsque votre organisation répond aux critères suivants :

  • Vous n'utilisez que les services Google Cloud .
  • Vous utilisez Gemini Enterprise, mais vous vous attendez à respecter les limites de groupe imposées par votre IdP.
  • Vous avez des exigences de résidence des données qui nécessitent de minimiser le stockage des informations utilisateur personnelles.

Architecture de la fédération d'identité de personnel, sans synchronisation.

Dans ce modèle, vous utilisez la fédération des identités des employés pour fédérer votre organisationGoogle Cloud avec votre IdP externe.

Ce modèle ne nécessite pas le provisionnement d'utilisateurs ni de groupes. Chaque fois qu'un utilisateur se connecte, le fournisseur d'identité transmet les informations requises sur l'utilisateur (y compris les appartenances à des groupes et les attributs personnalisés) à Google Cloud, et Google Cloud conserve ces informations uniquement pendant la durée de la session utilisateur.

Avantages

  • Vous n'avez pas besoin de stocker ni de gérer les comptes utilisateur ou les groupes dansGoogle Cloud.
  • Le modèle vous permet d'utiliser des connecteurs basés sur l'ingestion de données pour intégrer Gemini Enterprise à Microsoft 365.

Limites

  • La fédération des identités des employés est une fonctionnalité IAM qui permet uniquement aux utilisateurs d'accéder aux services qui utilisent IAM. Les utilisateurs qui s'authentifient à l'aide de la fédération des identités des employés ne peuvent pas accéder aux services Google tels que Google Ads, Looker ou Google Marketing Platform.
  • Les utilisateurs qui s'authentifient à l'aide de la fédération des identités des employés ne peuvent pas accéder à certaines fonctionnalités de Google Cloud . Pour en savoir plus, consultez Fédération des identités : produits et limites.
  • De nombreux fournisseurs d'identité limitent le nombre d'appartenances à des groupes qu'ils peuvent transmettre à la fédération d'identité des employés dans une assertion SAML ou un jeton d'identité. Pour respecter ces limites, vous devrez peut-être renforcer la gouvernance des groupes et limiter les types de groupes à inclure dans les assertions ou les jetons.
  • Lorsque vous partagez des ressources, comme un notebook Gemini Notebook Enterprise, vous ne pouvez pas rechercher un groupe par son nom. Les utilisateurs doivent saisir manuellement leurs identifiants.

Si vous utilisez Microsoft Entra ID, vous pouvez utiliser une variante de ce modèle en configurant des attributs supplémentaires. Lorsque vous configurez des attributs supplémentaires, la fédération des identités des employés exécute un rappel à l'API Microsoft Graph lors de l'authentification de l'utilisateur pour récupérer les appartenances aux groupes. Cette configuration vous permet de surmonter les limites d'appartenance aux groupes d'Entra pour les assertions SAML et les jetons d'identité, et d'utiliser jusqu'à 999 appartenances à des groupes par utilisateur.

Fédération d'identité de personnel avec SCIM

Sélectionnez ce modèle lorsque votre organisation répond aux critères suivants :

  • Vous n'utilisez que les services Google Cloud . Autrement dit, vous n'utilisez pas de services Google externes tels que Google Ads ou Google Maps.
  • Vous prévoyez d'utiliser Gemini Enterprise ou Gemini Notebook Enterprise, et vous devez prendre en charge jusqu'à 2 000 appartenances à des groupes par utilisateur, ou la possibilité de rechercher des groupes par nom lorsque vous partagez des ressources.

Architecture de la fédération des identités des employés avec SCIM.

Dans ce modèle, vous utilisez la fédération d'identité de personnel pour fédérer votre organisationGoogle Cloud . Pour augmenter le nombre de groupes que vous pouvez utiliser pour Gemini Enterprise, vous devez également configurer SCIM pour provisionner les informations sur l'appartenance à un groupe à l'avance.

Avantages

  • Le modèle vous permet d'utiliser des connecteurs basés sur l'ingestion de données pour intégrer Gemini Enterprise à Microsoft 365.
  • Vous pouvez utiliser jusqu'à 2 000 appartenances à des groupes par utilisateur pour contrôler l'accès à Gemini Enterprise et Gemini Notebook Enterprise, et permettre aux connecteurs Gemini Enterprise basés sur l'ingestion de données d'effectuer des vérifications d'accès.
  • Lorsque vous partagez des ressources, comme un notebook Gemini Notebook Enterprise, vous pouvez rechercher des groupes par nom pour améliorer l'expérience utilisateur globale.

Limites

  • La compatibilité avec les groupes provisionnés par SCIM est limitée à Gemini Enterprise et Gemini Notebook Enterprise. Les autres services ne peuvent consommer que les appartenances aux groupes que votre IdP transmet dans l'assertion SAML ou le jeton d'identité.
  • La fédération des identités des employés est une fonctionnalité IAM qui permet uniquement aux utilisateurs d'accéder aux services qui utilisent IAM. Les utilisateurs qui s'authentifient à l'aide de la fédération des identités des employés ne peuvent pas accéder aux services Google tels que Google Ads, Looker ou Google Marketing Platform.
  • Les utilisateurs qui s'authentifient à l'aide de la fédération des identités des employés ne peuvent pas accéder à certaines fonctionnalités de Google Cloud . Pour en savoir plus, consultez Fédération d'identité : produits et limites.

Cloud Identity hybride et fédération d'identité de personnel

Sélectionnez ce modèle lorsque votre organisation répond aux critères suivants :

  • Vous utilisez des services Google autres que Google Cloud (comme Google Ads ou Google Maps).
  • Vous prévoyez d'utiliser Gemini Enterprise et de l'intégrer à Microsoft 365.

Architecture de la fédération hybride Cloud Identity et Workforce Identity Federation.

Ce modèle combine deux des modèles précédents :

  • Vous utilisez la fédération d'identité des employés (sans synchronisation ou avec SCIM) pour gérer l'accès à Gemini Enterprise et Gemini Notebook Enterprise.
  • Vous utilisez la fédération Cloud Identity ou Google Workspace pour gérer l'accès à d'autres services, y compris Google Cloud et les services Google non cloud.

Avantages

Ce modèle vous permet de combiner les avantages des deux modèles précédents :

  • Vous pouvez connecter Gemini Enterprise à des sources de données Microsoft sans aucune limitation de fonctionnalité.
  • Les utilisateurs peuvent s'authentifier auprès des services Google, qu'ils utilisent IAM ou non.
  • Utilisez l'ensemble complet des fonctionnalités Google Cloud .

Limites

  • Vous devez conserver deux configurations de partie de confiance distinctes dans votre IdP externe : une pour Cloud Identity et une pour la fédération des identités des employés.
  • L'expérience de connexion d'un utilisateur peut varier selon que vous le configurez pour utiliser Cloud Identity ou la fédération d'identité de personnel.
  • Lorsque vous gérez des stratégies d'autorisation IAM, vous devez utiliser différents identifiants de compte principal en fonction de la façon dont un utilisateur s'authentifie. Par exemple, un utilisateur connu sous le nom bob@example.com dans votre fournisseur d'identité externe peut avoir l'identifiant principal bob@example.com ou principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID dans IAM, selon qu'il s'authentifie à l'aide de la fédération Cloud Identity ou de la fédération des identités des employés.
  • Vous ne pouvez pas créer de groupes contenant à la fois des utilisateurs Cloud Identity et des principaux de la fédération des identités des employés. Les groupes Cloud Identity ne peuvent contenir que des utilisateurs Cloud Identity, et les groupes d'identité de personnel ne peuvent contenir que des principaux de la fédération d'identité de personnel.
  • Si vous étendez l'utilisation de la fédération des identités des employés au-delà de Gemini Enterprise, les utilisateurs peuvent être amenés à passer d'une identité à une autre ou ne pas savoir comment s'authentifier.

Étapes suivantes