Pour appliquer le contrôle des accès aux sources de données et sécuriser les données dans Gemini Enterprise, vous devez configurer un fournisseur d'identité. Cela implique de configurer le fournisseur d'identité et de gérer les autorisations pour vos sources de données. Google utilise votre fournisseur d'identité pour identifier l'utilisateur final qui effectue une recherche et déterminer s'il a accès aux documents renvoyés en tant que résultats.
Choisir votre type de fournisseur d'identité
Le type de fournisseur d'identité que vous choisissez dépend des sources de données connectées à votre application Gemini Enterprise. Gemini Enterprise est compatible avec les options suivantes :
Type de fournisseur d'identité | Cas d'utilisation |
---|---|
Identité Google |
Lorsque vous connectez Gemini Enterprise à des sources de données Google Workspace, vous devez utiliser Google Identity.
Avant de configurer l'identité Google, vous devez déterminer l'attribut utilisateur unique utilisé par votre organisation, généralement l'adresse e-mail de l'utilisateur. Si les utilisateurs ont plusieurs adresses e-mail, vous devez ajouter un alias d'adresse e-mail. |
Fournisseur d'identité tiers |
Lorsque vous ne connectez Gemini Enterprise qu'à des sources de données tierces et que vous utilisez déjà un fournisseur d'identité tiers compatible avec OIDC ou SAML 2.0, comme Microsoft Entra ID, Active Directory Federation Services (AD FS), Okta et d'autres, vous devez utiliser la fédération des identités des employés.
Pour en savoir plus, consultez Fédération des identités des employés.
Avant de configurer la fédération d'identité de personnel, vous devez déterminer les attributs utilisateur uniques utilisés par votre organisation. Ces attributs doivent être mappés avec la fédération des identités des employés. |
Fédération des identités des employés pour les fournisseurs d'identité tiers
Cette section explique comment configurer la fédération des identités des employés pour les fournisseurs d'identité tiers. Vous pouvez également vérifier si la configuration de la fédération des identités des employés fonctionne comme prévu.
Configurer la fédération des identités des employés
Pour savoir comment configurer la fédération des identités des employés avec votre connecteur d'identité tiers, consultez les ressources suivantes :
Fournisseur d'identité | Ressources |
---|---|
Entra ID | |
Okta | |
OIDC ou SAML 2.0 |
Configurer le mappage des attributs
Le mappage d'attributs vous aide à associer vos informations d'identité tierces à Google à l'aide de la fédération des identités des employés.
Lorsque vous configurez le mappage d'attributs dans la fédération des identités des employés, tenez compte des points suivants :
L'attribut
google.subject
doit être mappé sur le champ qui identifie de manière unique les utilisateurs finaux dans les sources de données tierces. Par exemple, adresse e-mail, nom principal, ID utilisateur ou ID employé.Si votre organisation possède plusieurs identifiants uniques, mappez ces attributs organisationnels uniques à l'aide de l'attribut
attribute.as_user_identifier_number between 1 and 50
.Par exemple, si votre organisation utilise à la fois l'adresse e-mail et le nom principal comme identifiants utilisateur dans différentes applications, et que le nom principal est défini comme
preferred_username
auprès de votre fournisseur d'identité tiers, vous pouvez le mapper à Gemini Enterprise à l'aide du mappage d'attributs de la fédération des identités des employés (par exemple,attribute.as_user_identifier_1=assertion.preferred_username
).Utilisez des valeurs en minuscules pour les attributs en ajoutant
lowerAscii()
aux configurations de mappage d'attributs. Lorsqu'elle est utilisée avec la fédération des identités des employés, la recherche Gemini Enterprise ne tient pas compte de la casse. Cela signifie que les données ingérées et les requêtes de recherche sont normalisées en minuscules. Par exemple, si l'adresse e-mail de mappage d'attributs d'un utilisateur estCloudySanFrancisco@gmail.com
et que l'accès aux documents est basé sur l'adresse e-mailcloudysanfrancisco@gmail.com
, Gemini Enterprise convertitCloudySanFrancisco@gmail.com
encloudysanfrancisco@gmail.com
.
Vous trouverez ci-dessous des exemples de mappages d'attributs google.subject
et google.groups
pour les fournisseurs d'identité couramment utilisés.
Entra ID avec le protocole OIDC
Cet exemple utilise l'adresse e-mail pour identifier les utilisateurs de manière unique.google.subject=assertion.email.lowerAscii() google.groups=assertion.groups google.display_name=assertion.given_name
Entra ID avec le protocole SAML
Cet exemple utilise l'ID de nom SAML pour identifier de manière unique les utilisateurs.google.subject=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'][0].lowerAscii() google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groups'] google.display_name=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'][0]
Okta avec le protocole OIDC
Cet exemple utilise l'adresse e-mail pour identifier les utilisateurs de manière unique.google.subject=assertion.email.lowerAscii() google.groups=assertion.groups
Okta avec le protocole SAML
Cet exemple utilise l'assertion du sujet du jeton JWT pour identifier de manière unique les utilisateurs.google.subject=assertion.subject.lowerAscii() google.groups=assertion.attributes['groups']
Facultatif : Vérifier la configuration de la fédération des identités des employés
Pour vérifier que les connexions ont réussi et que le mappage des attributs est correct à l'aide de la fonctionnalité de journalisation des audits de la fédération des identités des employés, procédez comme suit :
Activez les journaux d'audit pour l'API Security Token Service de l'activité "Accès aux données".
-
Dans la console Google Cloud , accédez à la page Journaux d'audit :
Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.
- Sélectionnez un projet, un dossier ou une organisation Google Cloud existants.
- Activez les journaux d'audit des accès aux données.
- Consultez la documentation sur la journalisation pour obtenir la procédure détaillée permettant d'activer les journaux d'audit.
- Pour l'API Security Token Service, sélectionnez le type de journal d'audit Lecture administrateur. Pour en savoir plus, consultez Exemples de journaux pour la fédération des identités des employés.
-
Activez la journalisation détaillée dans votre pool d'employés. La fonctionnalité de groupes étendus de la fédération des identités des employés pour Microsoft Entra ID ne génère pas d'informations détaillées de journalisation d'audit.
Accédez à la page Pools d'identités de personnel:
Dans le tableau, sélectionnez le pool.
Cliquez sur le bouton Activer la journalisation d'audit détaillée pour l'activer.
Cliquez sur Enregistrer le pool.
Dans la section Fournisseurs, cliquez sur l'URL de connexion de votre fournisseur, puis connectez-vous à la console Google Cloud en tant qu'utilisateur du pool de personnel.
Consultez les journaux d'audit générés lors de votre connexion.
Accédez à la page Pools d'identités de personnel:
Dans le tableau, sélectionnez le pool auquel vous vous êtes connecté.
Cliquez sur Afficher à côté de Journaux.
Sur la page du journal d'audit, supprimez le filtre
protoPayload.resourceName
de la requête.Cliquez sur Exécuter la requête.
Consultez les journaux d'audit pour trouver une entrée avec la méthode
google.identity.sts.SecurityTokenService.WebSignIn
qui correspond au code temporel de la connexion.Vérifiez que le champ
metadata.mapped_attributes
du journal correspond à l'attribut que vous avez utilisé lors de la configuration de la fédération des identités des employés pour les fournisseurs d'identité tiers.Par exemple :
"metadata": { "mapped_attributes": { "attributes.as_user_identifier_1": "alex@admin.altostrat.com" "google.subject": "alex@altostrat.com" "google.groups": "[123abc-456d, efg-h789-ijk]" } },
Limites
Lorsque vous connectez vos sources de données à l'aide d'un connecteur pour créer des datastores, les limites suivantes s'appliquent :
3 000 lecteurs sont autorisés par document. Chaque compte principal est considéré comme un lecteur. Un compte principal peut être un groupe ou un utilisateur individuel.
Vous pouvez sélectionner un type de fournisseur d'identité par emplacement compatible dans Gemini Enterprise.
Si les paramètres du fournisseur d'identité sont modifiés en changeant le type de fournisseur d'identité ou le pool d'employés, les datastores existants ne sont pas automatiquement mis à jour avec les nouveaux paramètres. Vous devez supprimer et recréer ces datastores pour appliquer les nouveaux paramètres d'identité.
Pour définir une source de données comme étant à accès contrôlé, vous devez sélectionner ce paramètre lors de la création du datastore. Vous ne pouvez pas activer ni désactiver ce paramètre pour un datastore existant.
Pour prévisualiser les résultats de l'UI pour les applications de recherche qui utilisent le contrôle d'accès tiers, vous devez vous connecter à la console fédérée ou utiliser l'application Web. Consultez Prévisualiser votre application.
Se connecter à votre fournisseur d'identité
La section suivante explique comment vous connecter à votre fournisseur d'identité à l'aide de la consoleGoogle Cloud .
Avant de commencer
Avant de connecter le fournisseur d'identité, procédez comme suit :
Si vous connectez un fournisseur d'identité tiers, configurez la fédération des identités des employés.
Associer un fournisseur d'identité
Pour spécifier un fournisseur d'identité pour Gemini Enterprise et activer le contrôle des accès aux sources de données :
Dans la console Google Cloud , accédez à la page Gemini Enterprise.
Cliquez sur Paramètres > Authentification.
Cliquez sur Ajouter un fournisseur d'identité pour l'établissement que vous souhaitez modifier.
Cliquez sur Ajouter un fournisseur d'identité, puis sélectionnez le type de fournisseur d'identité.
Si vous sélectionnez Identité tierce, vous devez également sélectionner le pool de personnel qui s'applique à vos sources de données.Cliquez sur Enregistrer les modifications.
Accorder des autorisations aux utilisateurs
Les utilisateurs ont besoin du rôle Utilisateur Discovery Engine (roles/discoveryengine.user
) pour accéder aux applications, les gérer et les partager.
Type de fournisseur d'identité | Description |
---|---|
Identité Google |
|
Fournisseur d'identité tiers |
|
Étape suivante
Si vous disposez de datastores Cloud Storage ou BigQuery et que vous souhaitez appliquer un contrôle des accès aux données, vous devez configurer des contrôles des accès pour les sources de données personnalisées.
Si vous vous connectez à votre propre source de données personnalisée, découvrez comment configurer des identités externes.
Lorsque vous êtes prêt à partager l'application avec vos utilisateurs, vous pouvez l'activer et partager l'URL avec eux. Les utilisateurs doivent se connecter avant de pouvoir accéder à l'application. Pour en savoir plus, consultez Afficher l'application Web de recherche.