RAG über SharePoint, Confluence und Google Drive: Permissions-First-Architektur

Das harte Problem in Enterprise-RAG sind Berechtigungen: Der Assistent darf ein Dokument niemals an Personen ausspielen, die es nicht sehen dürfen. Ein Embedding trägt oder erzwingt die Autorisierung des Quellsystems nicht von selbst. Erzwinge den Zugriff deshalb vor der Generierung: Führe quellnativen Zugriffskontext je Chunk mit oder nutze eine maßgebliche Nachschlagetabelle und prüfe jeden Treffer, bevor er das Modell erreicht. Reduziere direkte Nutzer, Gruppen, Domains, Links, Vererbung und Schutzmechanismen nicht auf ein universelles Gruppen- oder Deny-wins-Modell.

Dies ist der Implementierungs-Begleiter zu unserer RAG-Production-Readiness-Checkliste, die Per-User-Berechtigungen als das harte Sicherheitsproblem benennt. Dieser Beitrag zeigt, wie du es tatsächlich löst. Anbieterspezifische und Preview-Funktionen ändern sich schnell; prüf die verlinkten Docs erneut, bevor du baust.

Warum Berechtigungen der schwierige Teil sind

Das Fehlerszenario in einem Satz: Das Modell formuliert eine flüssige Antwort, die auf einem Dokument basiert, das der anfragende Nutzer nie sehen durfte, weil das Retrieval auf semantische Ähnlichkeit gematcht hat und nicht auf Autorisierung. Sobald ein Dokument gechunkt und in einen gemeinsamen Index embedded ist, wandern die Eigentümer, Zugriffsstufen und Sensitivitätskennzeichnungen des Quellsystems nicht mit dem Vektor mit, sofern du sie nicht bewusst mitführst. Ein Vektorspeicher hat kein Konzept davon, wer fragt.

Microsoft dokumentiert, dass Microsoft 365 Copilot nur Daten nutzt, auf die der angemeldete Nutzer zugreifen darf, und SharePoint-Kontrollen sowie verschlüsselte Sensitivitätskennzeichnungen respektiert. Bereits übermäßig geteilte Inhalte können dadurch trotzdem leichter auffindbar werden. Restricted Content Discovery ist eine temporäre SharePoint-Kontrolle mit dokumentierten Grenzen; Data Access Governance hilft bei der Berechtigungsanalyse. Beides ersetzt keine korrekten Quellberechtigungen. (1, 2)

Dem Modell zu sagen, ein Dokument nicht preiszugeben, ist keine Zugriffskontrolle. OWASP führt Prompt Injection aktuell als LLM01, und NIST beschreibt indirekte Injection über abgerufene Inhalte. Vertrauenswürdige Anwendungs- oder Datenlogik muss autorisieren, bevor Inhalte das Modell erreichen. (3)

Das Prinzip: auf der Retrieval-Ebene durchsetzen

Der Vektorspeicher darf ein unautorisiertes Dokument gar nicht erst zurückgeben, und das Modell darf es nie verarbeiten. Das erreichst du, indem du jeden Chunk zur Index-Zeit mit normalisierten, versionierten ACL-Metadaten taggst und zur Retrieval-Zeit einen Berechtigungsfilter in die Query einbaust. Das Filtern nach dem Retrieval, auf der Anwendungsebene oder im Prompt, scheitert auf zwei Wegen: Es verschwendet das Kontextfenster, indem es Dokumente abruft, nur um sie wieder zu verwerfen, und wenn die App-Logik einen Bug hat oder durch eine Injection umgangen wird, fließen die Dokumente trotzdem durch. Post-Filtering bricht außerdem leise den Recall, denn das Herausstreichen unautorisierter Chunks aus einem Top-k-Set kann dem Modell nichts mehr lassen, wenn die autorisierten Ergebnisse knapp außerhalb von k lagen. Filtere bereits bei der Suche vor, oder ruf ein Vielfaches von k ab und filtere dann.

Berechtigungsmodelle pro Quelle

Jede Quelle hat eigene Principals, Vererbungsregeln, Freigabelinks und Schutzmechanismen. Nutze eine dedizierte Connector-Identität mit den geringsten nötigen Rechten und dem kleinsten genehmigten Repository-Scope. Normalisiere für effizientes Retrieval, erhalte aber genug quellnative Fakten für die effektive Autorisierungsentscheidung.

Programmiere bei Microsoft Graph gegen grantedToV2 und grantedToIdentitiesV2; die älteren Felder sind deprecated. Wähle die geringsten passenden delegierten oder Application-Berechtigungen und bevorzuge, wo möglich, ressourcenbezogene Selected-Site-Rechte gegenüber tenantweitem Lesezugriff. (4)

Implementierungsmuster, die halten

• Speichere stabile, quellnative Principals. Gruppen senken die Kardinalität, aber direkte Nutzerrechte, Domain- und Anyone-Links, geerbte Restriktionen und Schutzstatus können ebenfalls entscheidend sein.
• Binde jede Query an den angemeldeten Nutzer. Nutze unveränderliche Subject- und Tenant-IDs und löse effektive Rechte auf oder frage die Quelle. Microsofts On-Behalf-Of-Flow transportiert delegierte Nutzerrechte, keine Application Roles; Google und Atlassian brauchen eigene Delegationsmodelle. (8)
• Erzwinge Autorisierung im Retrieval. Nutze Mengenfilter für additive Regeln und explizite Prüfungen für Vorfahren, Limited Access, Links und Verschlüsselung. Eine universelle Deny-wins-Regel gibt es hier nicht.
• Behandle das Entra-Groups-Overage. Microsoft dokumentiert 200 Gruppen für JWT-Claims und 150 für SAML. Darüber wird die Gruppenliste ausgelassen und ein Overage-Hinweis geliefert; die Anwendung muss vor der Autorisierung die vollständige Mitgliedschaft ermitteln. (7)
• Postgres Row-Level Security kann den Filter nahe an pgvector erzwingen, ist aber nicht unumgehbar. Superuser, Rollen mit BYPASSRLS und normalerweise Tabellen-Owner umgehen RLS. Nutze unprivilegierte App-Rollen, bei Bedarf FORCE ROW LEVEL SECURITY und transaktionslokale Request-Identität. (9)

Es gibt eine echte Gabelung in den Empfehlungen, die man benennen sollte. Ein Lager (darunter AWS) argumentiert, dass Metadatenfilterung zur Query-Zeit allein nicht ausreicht und du die Autorisierung beim Retrieval erneut gegen die Quelle prüfen solltest, weil synchronisierte Metadaten veralten. Das andere (darunter Microsofts Referenzmuster) synchronisiert ACLs in den Index und setzt sie zur Query-Zeit mit dem Token des Nutzers durch, des Durchsatzes wegen. Es ist ein echter Trade-off: Aktualität gegen Latenz. Wähl nach der Sensibilität der Daten.

Das Aktualitätsproblem, das niemand einplant

Materialisierte Berechtigungen spiegeln einen quellseitigen Entzug nicht automatisch im Index. Change-Feeds sind Signale, kein Beweis, dass der effektive Zugriff aller Nachfahren neu berechnet wurde. Google dokumentiert ACL-Einträge im Nutzer-Change-Log nur für Owner, Service-Accounts auf der ACL oder direkt betroffene Nutzer; bei Shared Drives ist der passende Shared-Drive-Log zu verwenden. Kombiniere inkrementelle Ereignisse mit periodischer Reconciliation und einer fail-closed Aktualitätsschwelle. (10)

Löschung ist die andere Hälfte. Wenn eine DSGVO-Löschpflicht greift und abgeleitete Chunks, Embeddings, Caches oder Logs weiterhin personenbezogene Daten sind, musst du sie unter Beachtung der gesetzlichen Gründe und Ausnahmen löschen oder anonymisieren. Embeddings sind nicht kategorisch personenbezogen. Ein veröffentlichter Angriff rekonstruierte in einem spezifischen White-Box-Setup mit zwei Modellen 92 Prozent von 32-Token-Eingaben exakt. Das belegt ein reales Risiko, aber keine universelle Rekonstruktionsrate. (11, 12)

DSGVO und Datenresidenz

Datenminimierung und Speicherbegrenzung sprechen für einen begrenzten Korpus und kurze Aufbewahrung abgeleiteter Artefakte. Retrieval-Audit-Logs helfen bei Rechenschaft und Incident-Analyse, können aber selbst personenbezogene Daten enthalten und müssen minimiert, geschützt und gelöscht werden. Handelt der Modellanbieter als Auftragsverarbeiter, verlangt Artikel 28 passende Vertragsbedingungen; Kapitel V regelt Drittlandtransfers. Ein EU-Inferenz-Endpunkt allein belegt keine vollständige EU-Datenresidenz. Prüfe Datenfluss, Supportzugriff, Speicherung und Unterauftragsverarbeiter. Mehr dazu: EU-Datenresidenz für KI-Apps im Jahr 2026. (11)

Die Referenzarchitektur, und die Anti-Pattern

End-to-End: Ingestiere jede Quelle mit einer Identität, die alle Inhalte und ACLs lesen kann; extrahiere die effektive ACL pro Element (unter Beachtung gebrochener Vererbung, Durchlaufen der Confluence-Vorfahren, Lesen der Drive-Vererbung); chunke, embedde und häng die normalisierte versionierte ACL als filterbares Metadatum an jeden Chunk; ruf mit der Endnutzer-Identität und einem verpflichtenden Berechtigungsfilter ab; generiere nur aus autorisierten Chunks; logge jede Entscheidung; und betreibe eine Aktualitäts-Schleife aus den Change-Feeds der Quelle mit explizitem Resync für vererbte Änderungen und kaskadierenden Löschungen bis zu Chunks und Embeddings.

Anti-Pattern sind ein gemeinsamer Index ohne verpflichtende Autorisierung; Prompt-only-Filterung; Retrieval als breit berechtigter Service-Account; Gruppen zu speichern, aber direkte Nutzer und Links zu verwerfen; alle Produkte auf eine Deny- oder Grant-Regel zu reduzieren; direkte Confluence-Restrictions als effektiven Zugriff zu behandeln; bei Drive nur wachsenden Zugriff anzunehmen; SharePoint-Label-Verschlüsselung zu ignorieren; veraltete Autorisierung unbegrenzt zu akzeptieren; und personenbezogene Ableitungen ohne Rechtsgrund zurückzubehalten.

"Das Modell ist nicht deine Zugriffskontrolle, und der Prompt ist nicht deine Sicherheitsgrenze. Wenn ein Nutzer ein Dokument nicht lesen darf, darf der Vektorspeicher es nie zurückgeben. Alles andere, die Labels, die Aktualität, das Audit-Log, steht im Dienst dieser einen Regel."