Berechtigungen im RAG: warum Nachfiltern nicht reicht

TL;DR

Der übliche Aufbau — technisches Konto liest alles, Filter greift nach dem Abruf — ist aus zwei Gründen falsch: Er liefert zu wenige Treffer für restriktiv berechtigte Nutzer, und er fällt bei einer erfolgreichen Manipulation komplett aus. Berechtigungen gehören als Metadaten in den Index und als Filter in die Abfrage.

Der Moment, in dem es auffällt

Ein Unternehmen führt ein RAG-System über SharePoint und die Netzlaufwerke ein. Es funktioniert gut. Drei Monate später fragt jemand aus der Produktion beiläufig nach den Regelungen zur außertariflichen Vergütung — und bekommt eine präzise Antwort mit Zahlen aus einem Dokument, das in einer Personalbibliothek liegt, auf die er keinen Zugriff hat.

Das ist kein Angriff. Das ist die vorhersehbare Folge davon, dass beim Indexieren ein technisches Konto verwendet wurde, das alles lesen darf, und beim Abruf niemand gefragt hat, wer eigentlich fragt.

Wir sehen diesen Aufbau in der Mehrzahl der Installationen, die wir übernehmen. Er entsteht nicht aus Nachlässigkeit, sondern weil das Indexieren mit einem Dienstkonto der einfachste Weg ist und die Berechtigungsfrage sich erst später stellt.

Warum Nachfiltern nicht die Lösung ist

Der naheliegende Reflex: Abruf wie gehabt, danach die Treffer gegen die Rechte des Nutzers prüfen und Unzulässiges wegwerfen.

Zwei Probleme.

Sie bekommen zu wenig. Wenn ein Nutzer nur 5 Prozent der Dokumente sehen darf und Sie die besten 8 Treffer abrufen, bleiben nach dem Filtern statistisch weniger als ein Treffer übrig. Die Antwort lautet dann "dazu finde ich nichts", obwohl es sehr wohl etwas gibt — nur nicht unter den ersten acht. Fachabteilungen halten das System dann für schlecht, nicht für sicher.

Es ist die falsche Schicht. Der Filter läuft in Ihrem Anwendungscode. Alles, was diesen Code umgeht — eine direkte Abfrage an die Datenbank, eine Manipulation der Kette über den Kontext, ein Fehler im Abrufpfad — umgeht die Berechtigungsprüfung. Was das im Angriffsfall bedeutet, steht im Beitrag zu Prompt-Injection.

Der richtige Aufbau: Rechte als Metadaten

Die Berechtigung gehört an den Textabschnitt, und der Filter gehört in die Abfrage, damit er während der Suche greift.

Das Datenmodell, das sich in Projekten bewährt hat, ist bewusst einfach: Jeder Abschnitt trägt eine Liste von Kennungen, die ihn lesen dürfen — Gruppen, keine Personen.

punkt = {
    "id": "QMH-2025#s44",
    "vector": einbettung,
    "payload": {
        "text": "Änderungen an Fertigungszeichnungen gibt die ...",
        "quelle": "sharepoint://qm/Handbuch2025.docx",
        "leseberechtigt": ["GRP-Konstruktion", "GRP-QS", "GRP-Werkleitung"],
        "vertraulichkeit": "intern",
        "stand": "2025-11-03",
    },
}

In der Abfrage wird daraus ein Filter, der die Gruppen des angemeldeten Nutzers gegen dieses Feld hält:

treffer = client.query_points(
    collection_name="dokumente",
    query=frage_vektor,
    query_filter=models.Filter(must=[
        models.FieldCondition(
            key="leseberechtigt",
            match=models.MatchAny(any=nutzer_gruppen),   # aus dem Token
        )
    ]),
    limit=8,
).points

Entscheidend ist, dass nutzer_gruppen aus dem Zugriffstoken des angemeldeten Nutzers stammt — nicht aus einem Parameter, den die Anwendung setzt. Sobald die Anwendung entscheidet, wessen Rechte gelten, haben Sie dieselbe Schwachstelle wie beim Nachfiltern, nur eleganter verpackt.

In pgvector ist es dieselbe Logik in SQL:

SELECT inhalt, quelle
FROM abschnitte
WHERE leseberechtigt && $2::text[]      -- Überschneidung der Arrays
ORDER BY einbettung <=> $1
LIMIT 8;

Der Vergleich der Datenbanken darunter steht im Beitrag zu Azure AI Search, pgvector und Qdrant.

Woher die Berechtigungen kommen

Der aufwendige Teil ist nicht der Filter, sondern das Befüllen. Drei Quellen, drei Schwierigkeitsgrade.

Netzlaufwerke. Die ACLs des Dateisystems auslesen und auf Gruppen abbilden. Bei gewachsenen Freigaben ist das die unangenehmste Variante, weil Sie regelmäßig auf Einzelberechtigungen für Personen stoßen, auf verwaiste Konten und auf Ordner, deren Vererbung irgendwann durchbrochen wurde. Rechnen Sie damit, dass die Bestandsaufnahme länger dauert als die Umsetzung.

SharePoint. Über die Graph-API abfragbar, aber mit einer Falle: Berechtigungen können pro Element vom Ordner abweichen. Wenn Sie nur die Bibliotheksberechtigung übernehmen, indexieren Sie Elemente mit falscher Kennzeichnung. Die Abfrage muss auf Elementebene erfolgen, und das kostet API-Aufrufe — bei 30.000 Dokumenten spürbar.

Fachanwendungen. Meist die einfachste Quelle, weil dort ein sauberes Rollenmodell existiert. Ein Prüfprotokoll gehört zur Anlage, die Anlage zum Werk, das Werk hat eine Zuständigkeitsgruppe.

Ein Ansatz, der in der Praxis viel Aufwand spart: Bilden Sie nicht die Feinheiten ab, sondern definieren Sie vier bis sechs Vertraulichkeitsstufen und ordnen Sie Dokumentquellen diesen Stufen zu. Das ist gröber als die tatsächliche Berechtigungslage — und für die meisten Häuser ausreichend, weil die relevante Frage lautet "darf die Produktion Personalunterlagen sehen" und nicht "darf Person X Dokument Y sehen".

Sagen Sie das aber offen, statt es zu verschweigen. Wer eine gröbere Abbildung wählt, muss wissen, dass sie gröber ist.

Das Problem, das nach dem Aufbau kommt

Berechtigungen ändern sich. Ein Mitarbeiter wechselt die Abteilung, ein Ordner wird neu freigegeben, ein Projekt wird abgeschlossen.

Der Index weiß davon nichts. Er trägt den Stand vom Zeitpunkt der Indexierung.

Drei Wege damit umzugehen, mit klarer Empfehlung:

Vollständige Neuindexierung nach Zeitplan. Einfach, robust, teuer bei großen Beständen. Für unter 100.000 Abschnitte über Nacht machbar und die Variante, die wir bei kleineren Installationen empfehlen — weil sie keine Fehlerquellen hat.

Inkrementelle Aktualisierung über Änderungsereignisse. SharePoint kann Änderungen melden, Dateisysteme über Überwachungsdienste. Effizient und aufwendig zu bauen, mit der bekannten Schwäche: Ein verpasstes Ereignis fällt niemandem auf, bis jemand etwas sieht, das er nicht sehen sollte.

Rechte zur Abfragezeit auflösen. Im Index steht nur eine Kennung der Berechtigungsgruppe, die tatsächlichen Mitgliedschaften kommen aus dem Verzeichnis. Das ist der sauberste Weg, weil Änderungen sofort wirken — und genau der Weg, den das Token ohnehin geht, wenn Sie die Gruppen aus dem Zugriffstoken lesen. Der Index muss dann nur aktualisiert werden, wenn sich die Berechtigung des Dokuments ändert, nicht die des Nutzers.

Unsere Empfehlung ist die Kombination aus drittem und erstem Weg: Nutzergruppen immer aus dem Token, Dokumentberechtigungen per nächtlichem Abgleich. Damit sind Personalwechsel sofort wirksam, und Freigabeänderungen mit maximal einem Tag Verzug.

Häufig gestellte Fragen

Warum reicht es nicht, Suchergebnisse nach dem Abruf zu filtern?

Aus zwei Gründen. Erstens liefert der Abruf dann zu wenige verwertbare Treffer: Wer nur einen kleinen Teil des Bestands sehen darf, bekommt nach dem Filtern von acht Treffern oft keinen einzigen — das System wirkt schlecht, obwohl die Information existiert. Zweitens liegt der Filter im Anwendungscode und fällt aus, sobald dieser umgangen oder manipuliert wird.

Wie bekomme ich SharePoint-Berechtigungen in den Vektorindex?

Über die Graph-API, und zwar auf Elementebene statt auf Bibliotheksebene — Berechtigungen können pro Datei von der Bibliothek abweichen. Bei größeren Beständen ist die Anzahl der API-Aufrufe der begrenzende Faktor; planen Sie den ersten vollständigen Durchlauf über ein Wochenende und danach einen nächtlichen Abgleich der Änderungen.

Muss ich den Index neu aufbauen, wenn ein Mitarbeiter die Abteilung wechselt?

Nein, wenn Sie die Gruppen des Nutzers zur Abfragezeit aus dem Zugriffstoken lesen. Dann steht im Index nur, welche Gruppen ein Dokument sehen dürfen, und die Mitgliedschaft kommt live aus dem Verzeichnis. Neu indexiert werden muss nur, wenn sich die Berechtigung eines Dokuments ändert.

Reichen grobe Vertraulichkeitsstufen statt echter Berechtigungen?

Für viele Häuser ja, und der Aufwandsunterschied ist erheblich. Vier bis sechs Stufen, denen Dokumentquellen zugeordnet werden, beantworten die praktisch relevante Frage — darf dieser Bereich diese Art von Unterlagen sehen. Wichtig ist, dass die Entscheidung bewusst getroffen und dokumentiert wird, statt als stillschweigende Vereinfachung zu passieren.

Was ist mit Dokumenten, die einzelne Personen freigegeben bekommen haben?

Die sind der Hauptgrund, warum Berechtigungsübernahme aus gewachsenen Freigaben so mühsam ist. Praktikabel ist, solche Elemente entweder ganz aus dem Index zu lassen oder die Einzelberechtigung als eigene Kennung in der Liste zu führen. Beides ist unbefriedigend — der bessere Weg führt über eine Bereinigung der Freigabestruktur, die ohnehin ansteht.

Der nächste Schritt

Prüfen Sie an Ihrem laufenden System eine Frage: Melden Sie sich mit einem Konto aus der Produktion an und fragen Sie nach etwas, das nur die Personalabteilung wissen sollte. Wenn eine Antwort kommt, haben Sie Ihre erste Baustelle gefunden. Bei der Umsetzung unterstützen wir gern.