Comment les administrateurs informatiques configurent les connecteurs et les permissions d'identité dans Glean

La fragmentation des outils professionnels au sein de l'entreprise—tels que Microsoft 365, Google Workspace, Slack, Jira, Confluence, Salesforce et les applications internes développées sur mesure—place les équipes informatiques face à un arbitrage critique entre sécurité et productivité. Si les collaborateurs ont besoin d'une recherche d'entreprise unifiée et d'un assistant d'IA générative pour retrouver rapidement le contexte opérationnel, les organisations ne peuvent tolérer aucune fuite de données confidentielles. Les grilles de salaires des dirigeants, les feuilles de route de produits confidentiels ou les tickets RH sensibles ne doivent sous aucun prétexte être exposés à des collaborateurs non autorisés.

Glean résout ce problème grâce à une architecture respectueuse des droits d'accès reposant sur trois piliers fondamentaux : la réplication des permissions (Permission Mirroring), la fusion des identités (Identity Stitching) et l'application des contrôles d'accès au moment de la requête (Query-Time Access Enforcement). Plutôt que d'obliger les administrateurs à concevoir un modèle de droits parallèle, Glean ingère et applique directement les listes de contrôle d'accès (ACL) natives de chaque application source.

Ce guide technique détaille pas à pas la démarche que les administrateurs informatiques doivent suivre pour déployer les connecteurs, configurer la fédération d'identité, réconcilier les alias d'utilisateurs et valider l'étanchéité des accès.

Fondements architecturaux : comment Glean garantit la sécurité des données

Avant d'activer le moindre connecteur, les administrateurs doivent maîtriser les trois mécanismes clés de gouvernance assurés par Glean :

1. La réplication des permissions (Permission Mirroring)

Glean n'utilise pas de système de permissions artificiel ou déconnecté. Lorsque les connecteurs natifs indexent des documents, ils extraient simultanément les droits d'accès définis dans l'outil source. Qu'un fichier SharePoint hérite des permissions d'un sous-dossier, qu'un espace Confluence soit restreint à un groupe d'utilisateurs spécifique ou qu'un enregistrement Salesforce fasse l'objet de règles de partage particulières, Glean reproduit ces ACL au sein de son graphe de connaissances d'entreprise (Enterprise Knowledge Graph).

2. La fusion des identités entre applications disparates (Identity Stitching)

Il est rare qu'un collaborateur dispose du même identifiant dans tous ses outils de travail. Un utilisateur peut s'authentifier dans Okta sous jane.doe@enterprise.com, être identifié dans Jira par jdoe, contribuer sur GitHub avec un pseudo personnel et conserver l'adresse e-mail d'un ancien domaine à la suite d'une fusion-acquisition. Glean analyse les attributs de l'annuaire du fournisseur d'identité (IdP) principal pour fusionner ces comptes épars en une fiche de personne unique (Person Record).

3. Contrôle des accès à la requête et au niveau des passages

Lorsqu'un employé lance une recherche ou sollicite Glean Assistant, Glean évalue son identité en temps réel au moment même de l'exécution de la requête :

• Filtrage des résultats de recherche : Les éléments pour lesquels l'utilisateur n'a pas d'autorisation de lecture dans l'outil source sont totalement masqués. Ils n'apparaissent ni dans les listes de résultats, ni dans les aperçus, ni dans les suggestions.
• Ancrage de l'IA générative (RAG) : Glean Assistant élabore ses réponses par génération augmentée de récupération (RAG) exclusivement à partir des documents que l'employé requérant a le droit de lire. Si un collaborateur interroge l'IA sur les projections financières, celle-ci n'utilisera jamais des documents de direction restreints pour formuler sa réponse.
• Isolement au niveau du passage : Pour les formats de données prenant en charge des autorisations granulaires, Glean peut restreindre l'accès à certaines sections spécifiques, évitant ainsi la divulgation d'extraits sensibles au sein d'un document par ailleurs partagé.

Étape 1 : Intégration du fournisseur d'identité (IdP) et délégation des rôles

La première étape de déploiement consiste à asseoir l'infrastructure d'identité. L'authentification unique (SSO) est obligatoire dans Glean, et les données de l'annuaire sont synchronisées via une exploration automatique des profils (People Data Crawl).

Configuration du SSO et des fournisseurs d'identité

Le SSO est imposé pour tout déploiement de Glean. Les administrateurs le configurent sous Admin Console > Users & permissions > Authentication :

• Protocoles supportés : Prise en charge d'OpenID Connect (OIDC) et de SAML 2.0. Glean recommande vivement OIDC pour sa gestion fine des permissions et sa synchronisation dynamique des attributs d'annuaire.
• IdP compatibles : Intégrations natives disponibles pour Microsoft Entra ID (anciennement Azure AD), Okta et Google Workspace.

Hiérarchie des rôles d'administration et principe du moindre privilège

Glean propose trois rôles d'administration pour respecter le principe du moindre privilège :

Ces rôles peuvent être attribués manuellement ou associés dynamiquement via les permissions basées sur les groupes (Group-based permissions) à des groupes de sécurité de l'IdP (par exemple Entra-IT-Admins), garantissant l'attribution et la révocation automatiques des droits au gré des mouvements dans l'annuaire.

Étape 2 : Gestion des alias d'utilisateurs et fusion des identités

Pour que la recherche unifiée fonctionne de bout en bout, Glean doit être capable d'attribuer un document créé ou partagé par jdoe à l'identité réelle de l'employé dans l'IdP principal.

Exploration de l'annuaire et extraction des alias

Lors des analyses régulières de l'annuaire, Glean se base sur l'adresse e-mail principale pour créer le profil de l'utilisateur, et enregistre les identifiants secondaires en tant qu'alias.

Correspondance des attributs dans Microsoft Entra ID

• userPrincipalName : Utilisé par défaut comme adresse e-mail principale. (Possibilité de basculer vers mail en demandant l'activation de azure.useMailAsPrimaryEmailField=true au support de Glean).
• mail : Exploré comme alias par défaut.
• proxyAddresses : Exploré comme alias par défaut. Source recommandée : Cet attribut est sous le contrôle exclusif des administrateurs informatiques dans Entra ID, constituant le vecteur le plus sûr pour renseigner les adresses de domaines multiples.
• otherMails : Désactivé par défaut (nécessite l'option azure.crawlOtherMailsForAlias=true).

Correspondance des attributs dans Okta

• email : Utilisé comme adresse e-mail principale.
• login : Exploré comme alias par défaut.
• proxyAddresses : Exploré comme alias par défaut lorsqu'il provient d'Active Directory ou d'un attribut personnalisé géré par l'administrateur (recommandé).
• secondEmail : Désactivé par défaut.

Alerte de sécurité critique : le risque des attributs modifiables par l'utilisateur

[!WARNING] Dans de nombreux environnements d'entreprise, les attributs otherMails d'Entra ID ou secondEmail d'Okta peuvent être modifiés directement par les collaborateurs dans leur profil personnel. Si Glean utilisait ces champs sans réserve comme alias de confiance, un collaborateur mal intentionné pourrait renseigner l'adresse d'un collègue ou d'un dirigeant pour usurper son identité dans Glean et hériter indûment de ses droits d'accès aux documents confidentiels.

N'activez pas ces attributs comme sources d'alias à moins que l'édition par les utilisateurs finaux ne soit strictement verrouillée au niveau du locataire IdP. Privilégiez systématiquement proxyAddresses.

Bonnes pratiques lors de fusions-acquisitions et d'environnements multi-domaines

1. Renseignez l'ensemble des adresses e-mail secondaires dans l'attribut proxyAddresses de l'IdP principal.
2. Assurez-vous que cette règle s'applique à tous les comptes actifs, et pas uniquement aux utilisateurs historiques déjà migrés.
3. Si l'IdP source ne permet pas d'étendre son schéma, la console d'administration de Glean propose un outil de téléversement manuel d'alias par fichier CSV en guise de solution de repli.

Étape 3 : Configuration des connecteurs de sources de données

Le catalogue d'intégration de Glean s'articule autour de plusieurs modes de raccordement :

• Native Connectors (Connecteurs natifs) : Conçus pour plus de 100 applications SaaS courantes (Google Drive, SharePoint, Slack, Jira, Confluence, Salesforce, GitHub, ServiceNow, etc.), ils extraient automatiquement contenus, métadonnées et ACL via les API éditeurs.
• Push API Connectors (Connecteurs d'API Push) : Basés sur la Glean Indexing API pour les applications internes développées en interne ou les bases de données hébergées derrière les pare-feu de l'entreprise.
• Partner Connectors (Connecteurs partenaires) : Développés et maintenus par des éditeurs tiers sur la plateforme développeur de Glean.
• Web History Connectors (Connecteurs d'historique web) : Utilisés pour les outils web dépourvus d'API ouverte, en s'appuyant sur l'extension de navigateur pour indexer les pages visitées de façon strictement privée pour l'employé.

Déroulement standard de configuration d'un connecteur

[1. Sélectionner l'application dans le hub] 
         │
         ▼
[2. Vérifier les prérequis et les portées d'API]
         │
         ▼
[3. Renseigner les identifiants et enregistrer]
         │
         ▼
[4. Définir les exclusions sous "Manage Data"]
         │
         ▼
[5. Lancer l'exploration initiale et l'indexation]
         │
         ▼
[6. Valider les permissions avec un groupe de test]

Étape 1 : Choisir l'application dans le Connectors Hub

Dans la console d'administration, allez dans Admin Console > Connectors > Connectors hub et repérez l'outil cible (par exemple Confluence Cloud ou SharePoint).

Étape 2 : Vérifier les prérequis et les droits côté source

Consultez le guide spécifique du connecteur :

• Comptes de service et droits d'accès : L'intégration de ServiceNow requiert d'élever temporairement le compte d'administration au rôle security_admin pour configurer les ACL de lecture sur les tables ; Microsoft 365 requiert le consentement de l'administrateur du locataire.
• Portées d'API restreintes au strict nécessaire : Utilisez des autorisations en lecture seule (comme Sites.Read.All et Files.Read.All sur Microsoft Graph). Glean n'a besoin d'aucun droit d'écriture pour indexer le contenu destiné à la recherche.

Étape 3 : Renseigner les identifiants et enregistrer le connecteur

Cliquez sur Add connector, saisissez l'URL de votre instance, fournissez les identifiants OAuth ou jetons de service, puis enregistrez la configuration.

Étape 4 : Définir le périmètre sous l'onglet "Manage Data"

La majorité des connecteurs natifs intègrent un onglet Manage data :

• Règles d'exclusion : Excluez explicitement les espaces sensibles ou obsolètes (sites SharePoint de la direction générale, canaux Slack traitant d'affaires juridiques confidentielles, projets Jira archivés).
• Modes d'accès aux données : Choisissez entre le mode Indexed (Indexé) pour garantir des temps de réponse instantanés par pré-exploration ou le mode Live / Hybrid (En direct ou hybride) pour les données fluctuant à la seconde.

Étape 4 : Exploration initiale, indexation et validation des accès

Une fois le connecteur enregistré, il entame son cycle de synchronisation initiale.

Les deux temps de la synchronisation

1. Phase d'exploration (Crawling) : Les collecteurs interrogent les API sources pour récupérer les textes, les métadonnées (auteur, horodatage) et les structures de sécurité (ACL d'utilisateurs, groupes associés, liens de partage).
2. Phase d'indexation (Indexing) : Glean segmente les textes, génère les représentations vectorielles, relie les entités, aligne les identifiants avec le People Graph et consolide le graphe de connaissances d'entreprise.

La durée de l'opération varie selon le volume de données et les limites de fréquence (rate limits) des API sources. L'avancement peut être suivi en direct sous Admin Console > Connectors > Manage connectors.

Validation des contrôles d'accès en groupe pilote (Point de passage obligatoire)

Avant d'ouvrir la recherche à l'ensemble des collaborateurs, une phase de validation stricte s'impose :

1. Restreindre la visibilité au groupe de test : Dans les paramètres du connecteur, limitez la visibilité de la recherche à un groupe de test informatique ou à un département pilote.
2. Tests de recherche positifs : Connectez-vous avec des comptes de test autorisés et assurez-vous que les collaborateurs retrouvent sans difficulté leurs fichiers légitimes dans Google Drive, SharePoint ou Confluence.
3. Tests d'accès négatifs (Étape la plus cruciale) : Effectuez des recherches sur des documents confidentiels (fiches de paie de dirigeants, notes sur des restructurations) à partir de comptes non autorisés. Vérifiez qu'aucun résultat n'apparaît et que Glean Assistant ne mentionne ni ne cite ces documents dans ses réponses.
4. Vérification des actions d'IA : Si des outils interactifs ont été activés pour l'assistant (création de tickets, serveurs MCP), vérifiez que les actions sont exécutées sous l'identité déléguée de l'utilisateur demandeur et que les outils bloqués restent inaccessibles.

Étape 5 : Gouvernance continue, surveillance et contrôle des agents d'IA

Garantir l'efficacité et la conformité du dispositif sur la durée exige une vigilance régulière :

Mises à jour incrémentielles et Webhooks

Après l'exploration initiale complète, Glean capture les ajouts, modifications et suppressions au moyen de webhooks ou d'explorations incrémentielles régulières. Sur la plupart des connecteurs SaaS natifs, les ajustements de droits réalisés dans l'outil source sont répercutés dans Glean en quelques minutes.

Alertes opérationnelles et journaux d'audit

Les équipes informatiques doivent surveiller le Notifications dashboard et les Admin Alerts afin de réagir rapidement en cas d'expiration de jeton OAuth ou de dépassement de quota d'API. Toutes les interventions des administrateurs sont conservées dans des Audit Logs infalsifiables.

Encadrement du Model Context Protocol (MCP) et des agents autonomes

Avec le déploiement d'agents autonomes et de serveurs MCP :

• Glean veille à ce que les agents ne dépassent jamais les privilèges de l'utilisateur qui a déclenché l'opération.
• Les administrateurs peuvent centraliser l'activation ou le blocage d'outils sous Admin Console > Tools, en imposant une approbation explicite (Needs approval) pour les écritures critiques.

Liste de contrôle des bonnes pratiques pour l'administrateur informatique

1. Sécuriser les attributs d'identité : Vérifiez dans Entra ID ou Okta que les alias proviennent exclusivement d'attributs administrés tels que proxyAddresses, et désactivez les champs modifiables par les utilisateurs finaux.
2. Déployer un RBAC fondé sur les groupes : Associez les rôles d'administration Glean aux groupes de sécurité de votre IdP plutôt que d'attribuer des rôles nominatifs.
3. Définir les exclusions en amont : Utilisez l'onglet Manage data pour exclure les répertoires hautement confidentiels ou archivés avant même de déclencher la première synchronisation complète.
4. Mener des tests négatifs rigoureux : Ne vous contentez pas de vérifier ce que l'on trouve ; assurez-vous activement que les documents restreints demeurent totalement invisibles aux yeux des personnes non habilitées.
5. Surveiller la santé des connecteurs : Contrôlez régulièrement l'état de synchronisation des connecteurs et les journaux d'exploration pour éviter toute rupture d'indexation due à des identifiants expirés.

En articulant rigoureusement la synchronisation d'identité, la délégation des rôles d'administration et la réplication native des autorisations de Glean, les directions informatiques suppriment efficacement les silos d'information tout en garantissant un niveau de sécurité et de conformité irréprochable.

Références

• About connectors
• Get started with connectors
• Administrator Roles
• User aliases and identity stitching
• AI Security: Protecting Enterprise Data with Glean