Wie IT-Administratoren Datenquellen-Konnektoren und Identitätsberechtigungen in Glean konfigurieren

Die Verteilung von Arbeitsdaten über isolierte Unternehmensanwendungen—wie Microsoft 365, Google Workspace, Slack, Jira, Confluence, Salesforce und interne Eigenentwicklungen—stellt IT-Administratoren vor ein grundlegendes Dilemma. Einerseits benötigen Mitarbeiter eine einheitliche Suche und generative KI-Assistenten, um verteilte Projektinformationen effizient wiederzufinden; andererseits darf dies keinesfalls zu Datenschutzverletzungen oder Rechteübertragungen führen. Gehaltstabellen der Geschäftsführung, unangekündigte Produkt-Roadmaps oder vertrauliche HR-Tickets dürfen unter keinen Umständen für unbefugte Mitarbeiter auffindbar sein.

Glean löst diese Herausforderung durch eine rechtebewusste Sicherheitsarchitektur, die auf drei Säulen basiert: Berechtigungsspiegelung (Permission Mirroring), Identitätsverknüpfung (Identity Stitching) und Zugriffsprüfung zur Abfragezeit (Query-Time Access Enforcement). IT-Teams müssen in Glean kein separates Berechtigungsmodell manuell nachbauen; die Plattform übernimmt und erzwingt direkt die nativen Zugriffskontrolllisten (Access Control Lists, ACLs) jedes angebundenen Quellsystems.

Dieser technische Leitfaden führt IT-Administratoren Schritt für Schritt durch die Bereitstellung von Konnektoren, die Konfiguration der Identitätsföderation, die Zuordnung von Benutzer-Aliasen und die Validierung von Sicherheitsgrenzen.

Architektur-Grundlagen: Wie Glean Datensicherheit garantiert

Vor der Konfiguration einzelner Konnektoren müssen Administratoren die drei Kernmechanismen der Glean-Governance verstehen:

1. Berechtigungsspiegelung (Permission Mirroring)

Glean verwendet kein abstraktes, losgelöstes Berechtigungskonzept. Native Konnektoren erfassen bei der Datenaufnahme gleichzeitig das vollständige Rechtemodell des Ursprungssystems. Ob ein SharePoint-Dokument Berechtigungen von einem übergeordneten Ordner erbt, ein Confluence-Bereich auf eine bestimmte Benutzergruppe beschränkt ist oder ein Salesforce-Datensatz individuelle Freigaberegeln besitzt—Glean spiegelt diese ACLs exakt in seinem Enterprise Knowledge Graph wider.

2. Identitätsverknüpfung über Quellsysteme hinweg (Identity Stitching)

Mitarbeiter besitzen selten in allen genutzten Systemen identische Anmeldenamen. Ein Benutzer meldet sich in Okta mit jane.doe@enterprise.com an, wird in Jira als jdoe geführt, committet Code in GitHub unter einem privaten Handle und besitzt nach einer Unternehmensübernahme eventuell noch Postfächer unter einer alten Domain. Glean durchsucht die Verzeichnisattribute des primären Identity Providers (IdP) und verknüpft diese verteilten Konten sicher zu einem einzigen Personendatensatz (Person Record).

3. Zugriffsprüfung zur Abfragezeit und auf Abschnittsebene

Wenn ein Mitarbeiter eine Suchanfrage stellt oder eine Frage an den Glean Assistant richtet, validiert Glean dessen Identität in Echtzeit:

• Filterung der Suchergebnisse: Dokumente, für die der Benutzer im Quellsystem keine Leseberechtigung besitzt, werden vollständig ausgeblendet. Sie erscheinen weder in den Suchergebnissen noch in Vorschauen oder Linkempfehlungen.
• Faktengrundlage für generative KI (RAG): Der Glean Assistant stützt seine Antworten mittels Retrieval-Augmented Generation (RAG) ausschließlich auf Dokumente, die der anfragende Mitarbeiter tatsächlich lesen darf. Fragt ein Mitarbeiter nach Finanzprognosen, werden vertrauliche Vorstandsdokumente bei der Antwortgenerierung keinesfalls herangezogen.
• Granulare Isolation auf Abschnittsebene: Bei Datentypen mit feingliedrigen Rechten kann Glean vertrauliche Abschnitte innerhalb eines ansonsten öffentlich geteilten Dokuments gezielt isolieren.

Phase 1: Identity-Provider-Integration und Rollendelegation

Der erste Meilenstein besteht im Aufbau der Identitätsinfrastruktur. Single Sign-On (SSO) ist in Glean obligatorisch, und Organisationsdaten werden über automatisierte Personendaten-Crawls (People Data Crawl) synchronisiert.

Konfiguration von SSO und IdP

SSO ist für jede Glean-Bereitstellung zwingend vorgeschrieben. Administratoren konfigurieren die Anbindung unter Admin Console > Users & permissions > Authentication:

• Protokolle: Glean unterstützt OpenID Connect (OIDC) und SAML 2.0. OIDC wird von Glean ausdrücklich empfohlen, da es eine präzisere Rechteverwaltung und eine nahtlose Synchronisation von Verzeichnisattributen bietet.
• Unterstützte IdPs: Native Integrationen existieren für Microsoft Entra ID (ehemals Azure AD), Okta und Google Workspace.

Administrator-Rollen und das Prinzip der minimalen Rechtevergabe

Glean definiert drei administrative Rollen, um Berechtigungen bedarfsgerecht zu vergeben:

Diese Rollen können manuell vergeben oder über gruppenbasierte Berechtigungen (Group-based permissions) dynamisch mit IdP-Sicherheitsgruppen (z. B. Entra-IT-Admins) verknüpft werden, sodass Rechte automatisch anhand der Verzeichniszugehörigkeit vergeben und entzogen werden.

Phase 2: Benutzer-Aliase und Identitätsverknüpfung

Damit die systemübergreifende Suche funktioniert, muss Glean Dokumente, die von jdoe erstellt oder freigegeben wurden, dem realen Benutzerprofil im primären IdP zuordnen.

Verzeichniscrawl und Alias-Ableitung

Während der Identitäts-Crawls nutzt Glean die primäre E-Mail-Adresse zur Anlage des Benutzerdatensatzes und hinterlegt sekundäre Kennungen als Aliase.

Attribut-Mapping in Microsoft Entra ID

• userPrincipalName: Standardmäßig als primäre E-Mail erfasst. (Kann auf Wunsch über den Glean-Support via azure.useMailAsPrimaryEmailField=true auf das Attribut mail umgestellt werden).
• mail: Wird standardmäßig als Alias erfasst.
• proxyAddresses: Wird standardmäßig als Alias erfasst. Empfohlene Quelle: Dieses Feld wird in Entra ID zentral von der IT verwaltet und stellt den sichersten Weg dar, alternative E-Mail-Adressen und sekundäre Domänen zu hinterlegen.
• otherMails: Standardmäßig deaktiviert (Aktivierung erfordert azure.crawlOtherMailsForAlias=true).

Attribut-Mapping in Okta

• email: Als primäre E-Mail erfasst.
• login: Standardmäßig als Alias erfasst.
• proxyAddresses: Wird bei Übernahme aus Active Directory oder als administriertes benutzerdefiniertes Attribut standardmäßig als Alias erfasst (empfohlen).
• secondEmail: Standardmäßig deaktiviert.

Dringende Sicherheitswarnung: Vom Benutzer editierbare Attribute

[!WARNING] Attribute wie otherMails in Entra ID oder secondEmail in Okta sind in vielen Unternehmensumgebungen von den Endbenutzern selbst im Profil bearbeitbar. Werden diese Felder unkritisch als vertrauenswürdige Aliase in Glean übernommen, entsteht ein gravierendes Sicherheitsrisiko zur Rechteausweitung: Ein böswilliger Benutzer könnte die E-Mail-Adresse eines Kollegen oder Vorgesetzten eintragen, woraufhin Glean die Identitäten verschmilzt und dem Angreifer Zugriff auf vertrauliche Dokumente des Opfers gewährt.

Aktivieren Sie diese Felder nur dann als Alias-Quelle, wenn Endbenutzer im IdP-Mandanten nachweislich keine Schreibrechte darauf besitzen. Verwenden Sie stattdessen stets IT-verwaltete Attribute wie proxyAddresses.

Best Practices bei Fusionen, Übernahmen und Multi-Domain-Umgebungen

1. Hinterlegen Sie alternative Adressen im Attribut proxyAddresses des primären IdP.
2. Wenden Sie die Regelung einheitlich auf alle Mitarbeiter an, nicht nur auf historische Migrationsstapel.
3. Falls das Quell-IdP keine Schema-Erweiterungen erlaubt, bietet die Glean-Admin-Konsole den manuellen CSV-Upload von Aliasen als Übergangslösung.

Phase 3: Konfiguration der Datenquellen-Konnektoren

Gleans Konnektoren-Portfolio gliedert sich in verschiedene Bereitstellungsmodelle:

• Native Connectors (Native Konnektoren): Vorkonfiguriert für über 100 gängige SaaS-Lösungen (Google Drive, SharePoint, Slack, Jira, Confluence, Salesforce, GitHub, ServiceNow usw.). Rufen Inhalte, Metadaten und ACLs automatisiert über offizielle APIs ab.
• Push API Connectors (Push-API-Konnektoren): Basieren auf der Glean Indexing API. Bestimmt für interne Eigenentwicklungen, Datenbanken oder On-Premises-Systeme hinter Unternehmens-Firewalls.
• Partner Connectors (Partner-Konnektoren): Von Drittanbietern auf Basis der Glean-Entwicklerplattform entwickelte und gepflegte Schnittstellen.
• Web History Connectors (Browserverlauf-Konnektoren): Für interne Web-Apps ohne eigene API. Erfassen über die Glean-Browsererweiterung den individuellen Verlauf, der ausschließlich für den jeweiligen Benutzer privat bleibt.

Standard-Ablauf bei der Konnektor-Einrichtung

[1. Anwendung im Hub auswählen] 
         │
         ▼
[2. Voraussetzungen und API-Scopes prüfen]
         │
         ▼
[3. Anmeldedaten hinterlegen und speichern]
         │
         ▼
[4. Filterregeln unter "Manage Data" festlegen]
         │
         ▼
[5. Initialen Crawl und Indexierung starten]
         │
         ▼
[6. Berechtigungen mit Testgruppe validieren]

Schritt 1: Anwendung im Connectors Hub auswählen

Navigieren Sie in der Admin Console > Connectors > Connectors hub zur gewünschten Zielanwendung (z. B. Confluence Cloud oder Microsoft SharePoint).

Schritt 2: Voraussetzungen und Rechte im Quellsystem prüfen

Konsultieren Sie die anwendungsspezifischen Leitfäden:

• Dienstkonten und Quellrechte: Für ServiceNow muss das Dienstkonto vorübergehend die Rolle security_admin erhalten, um Tabellen-ACLs einzurichten; Microsoft 365 erfordert die Zustimmung des Mandantenadministrators.
• Minimal erforderliche API-Berechtigungen: Verwenden Sie rein lesende Scopes (z. B. Sites.Read.All und Files.Read.All in Microsoft Graph). Glean benötigt für die Suchindexierung keinerlei Schreibrechte.

Schritt 3: Authentifizierung konfigurieren und speichern

Klicken Sie auf Add connector, hinterlegen Sie die Instanz-URL, übergeben Sie die OAuth-Anmeldedaten oder API-Schlüssel und speichern Sie die Einstellungen.

Schritt 4: Geltungsbereich unter "Manage Data" eingrenzen

Viele native Konnektoren bieten den Reiter Manage data:

• Ausschlussregeln definieren: Schließen Sie vertrauliche oder irrelevante Quellen explizit aus (z. B. SharePoint-Seiten der Geschäftsleitung, vertrauliche Slack-Kanäle der Rechtsabteilung oder archivierte Jira-Projekte).
• Datenzugriffsmodus festlegen: Wählen Sie zwischen Indexed (Indexiert) für minimale Latenzen durch Vorab-Crawling oder Live / Hybrid (Live/Hybrid) für sich sekündlich ändernde Datenbestände.

Phase 4: Initialer Crawl, Indexierung und Sicherheitsprüfung

Nach dem Speichern wechselt der Konnektor in die Synchronisationsphase.

Die zwei Synchronisationsphasen

1. Crawling-Phase: Glean ruft die APIs des Quellsystems ab und erfasst Textinhalte, Metadaten (Autor, Änderungsdatum) und Zugriffskontrolllisten (Benutzer-ACLs, Gruppen, Freigabelinks).
2. Indexierungs-Phase: Glean generiert semantische Embeddings, löst Entitätsbeziehungen auf, verknüpft Konten mit dem People Graph und baut den durchsuchbaren Wissensgraphen auf.

Die Dauer hängt von der Datenmenge und den API-Ratenbegrenzungen (Rate Limits) des Quellsystems ab. Der Fortschritt lässt sich unter Admin Console > Connectors > Manage connectors in Echtzeit überwachen.

Validierung in einer Testgruppe (Unerlässliche Freigabestufe)

Vor dem unternehmensweiten Rollout muss die Zugriffskontrolle verifiziert werden:

1. Sichtbarkeit auf Testgruppe einschränken: Begrenzen Sie den Zugriff in den Konnektor-Einstellungen zunächst auf ein IT-Testteam oder eine Pilotabteilung.
2. Positivtests durchführen: Melden Sie sich mit regulären Testkonten an und verifizieren Sie, dass berechtigte Dokumente in SharePoint, Drive oder Confluence problemlos gefunden werden.
3. Negativtests durchführen (Entscheidender Sicherheitsschritt): Suchen Sie mit einem unberechtigten Benutzerkonto gezielt nach vertraulichen Dokumenten (z. B. Gehaltstabellen oder vertrauliche Restrukturierungspläne). Bestätigen Sie, dass keinerlei Ergebnisse geliefert werden und der Glean Assistant diese Inhalte in Antworten weder zitiert noch erwähnt.
4. Prüfung von KI-Werkzeugen (Tools): Falls interaktive Werkzeuge (wie Ticket-Erstellung oder MCP-Server) angebunden sind, stellen Sie sicher, dass Aktionen ausschließlich unter der delegierten Benutzeridentität ausgeführt werden und blockierte Werkzeuge gesperrt bleiben.

Phase 5: Kontinuierliche Governance, Überwachung und KI-Agenten-Kontrolle

Ein stabiler und rechtskonformer Betrieb erfordert laufende administrative Betreuung:

Inkrementelle Crawls und Webhook-Aktualisierungen

Nach dem initialen Voll-Crawl registriert Glean Änderungen über Webhooks oder häufige inkrementelle Crawls. Bei modernen SaaS-Konnektoren werden Berechtigungsänderungen im Quellsystem in der Regel innerhalb weniger Minuten in Glean reflektiert.

Warnmeldungen und unveränderliche Audit-Logs

Administratoren sollten das Notifications dashboard sowie die Admin Alerts überwachen, um abgelaufene OAuth-Tokens oder API-Drosselungen frühzeitig zu beheben. Sämtliche administrativen Eingriffe werden manipulationssicher in den Audit Logs protokolliert.

Governance für Model Context Protocol (MCP) und KI-Agenten

Beim Einsatz von MCP-Servern und autonomen Agenten gilt:

• Glean stellt sicher, dass Agenten niemals die Berechtigungen des ausführenden Benutzers überschreiten.
• Über Admin Console > Tools können Administratoren Werkzeuge zentral freigeben oder sperren und für schreibende Operationen eine Benutzerbestätigung (Needs approval) erzwingen.

Best-Practice-Checkliste für IT-Administratoren

1. Identitätsattribute absichern: Vergewissern Sie sich, dass Aliase nur aus IT-verwalteten Feldern wie proxyAddresses bezogen werden und benutzerdefinierbare Attribute deaktiviert bleiben.
2. Gruppenbasiertes RBAC nutzen: Verknüpfen Sie Glean-Rollen mit bestehenden IdP-Sicherheitsgruppen, anstatt Lizenzen und Rollen manuell zuzuweisen.
3. Vorab-Ausschlüsse konfigurieren: Schließen Sie sensible oder veraltete Datenbereiche in Manage data bereits vor dem ersten Crawl-Lauf aus.
4. Strenge Negativtests durchführen: Testen Sie intensiv, ob gesperrte Dokumente für unbefugte Benutzer und im KI-Chat vollständig unsichtbar bleiben.
5. Konnektor-Gesundheit überwachen: Kontrollieren Sie regelmäßig Statusmeldungen und Synchronisationsberichte, um Ausfälle durch abgelaufene Zertifikate oder Tokens zu verhindern.

Durch eine saubere Verzeichnisstruktur, restriktive Rollenzuweisungen und Gleans automatische Berechtigungsspiegelung schaffen IT-Abteilungen eine sichere, unternehmensweite Wissenssuche, die Informationssilos überwindet und höchsten Sicherheitsstandards entspricht.

Referenzen

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