Azure-RAG kann fremde Dokumente liefern – der Filter gehört in jede Abfrage

Ein Azure-RAG kann fremde Dokumente abrufen, sobald auch nur ein Suchpfad ohne Rechteprüfung auf Azure AI Search zugreift. Deshalb muss die Anwendung die Identität des angemeldeten Nutzers bei jeder Suche berücksichtigen und unzulässige Treffer ausschließen, bevor sie den Prompt, Zitate oder einen Download-Endpunkt erreichen.

Dafür kommen vor allem zwei Modelle infrage: ein anwendungsseitiger String-Filter oder die integrierte, tokenbasierte ACL-/RBAC-Prüfung. Der String-Filter verlangt vertrauenswürdig ermittelte Nutzer- oder Gruppenkennungen in jeder Abfrage; die integrierte Variante verlangt synchronisierte Berechtigungsfelder und ein Microsoft-Entra-Token im vorgesehenen Request-Header.

1. Die Sicherheitsgrenze liegt vor dem Prompt

Eine Systemanweisung wie „Zeige nur erlaubte Inhalte“ ist keine Autorisierung. Lädt die Anwendung zunächst einen unbeschränkten Ergebnissatz und sortiert ihn erst danach aus, können fremde Chunks bereits einen Re-Ranker, Cache, Modellkontext oder Telemetrie erreicht haben.

Die Rechteprüfung gehört deshalb unmittelbar in das Retrieval. Diese Vorgabe gilt nicht nur für die zentrale Chat-Funktion, sondern für jeden Codepfad, der den Index abfragt: hybride und reine Vektorsuche, Folgefragen, Quellenansicht, Downloadprüfung und Hintergrundprozesse. Inhalt, Dateiname, Zitat und Ziel-URL müssen aus demselben autorisierten Ergebnissatz stammen.

2. String-Filter und integrierte Prüfung erfüllen unterschiedliche Aufgaben

Ein String-Filter passt zu eigenen Identitätsmodellen, Push-Indizes und Datenquellen, deren Rechte Azure AI Search nicht nativ übernimmt. Dafür erhält jeder Datensatz beispielsweise ein Feld group_ids vom Typ Collection(Edm.String), das als filterbar markiert wird. Das Backend ermittelt die Gruppen des Aufrufers und ergänzt die Suche um einen Ausdruck wie group_ids/any(g:search.in(g, 'id1,id2')).

Die Microsoft-Dokumentation zum Security-Filter-Muster stellt klar, dass die Principal-Kennung dabei nur als Zeichenfolge verglichen und der Filter auf jede Abfrage angewendet wird; retrievable=false verhindert lediglich die Ausgabe des Feldes und schützt das Dokument nicht allein. Das Backend darf Kennungen daher nicht ungeprüft aus einem veränderbaren Client-Feld übernehmen und muss verhindern, dass ein Aufrufer den Filter entfernt.

Die integrierte Prüfung ist enger an Microsoft Entra und unterstützte Berechtigungsquellen gebunden. Sie erkennt die indexierten Felder als Permission Filter und vergleicht sie zur Abfragezeit mit dem Sicherheitsprinzipal des Tokens. Das reduziert eigenen Autorisierungscode, ersetzt aber weder eine korrekte Anmeldung noch die Synchronisation der Rechte in den Index.

3. Identität, Index und Suche als geschlossene Kette bauen

Microsofts Überblick zur dokumentbezogenen Zugriffskontrolle nennt vier Ansätze: String-basierte Sicherheitsfilter, POSIX-ähnliche ACLs beziehungsweise RBAC-Bereiche, Microsoft-Purview-Vertraulichkeitsbezeichnungen und SharePoint-Berechtigungen. Die drei integrierten, tokenbasierten Ansätze sind Funktionen der REST API 2026-08-01-preview; externe Rechteänderungen wirken erst, nachdem ihre Metadaten mit dem Index synchronisiert wurden.

1. Identität übernehmen: Das Frontend authentifiziert den Nutzer über Microsoft Entra ID und sendet das für die eigene API bestimmte Zugriffstoken an das Backend. Für die integrierte Prüfung beschafft das Backend im passenden delegierten Ablauf ein Token für Azure AI Search; eine frei übermittelte Nutzer-ID genügt nicht.
2. Rechte indexieren: Jeder Dokumentdatensatz und jeder daraus erzeugte Chunk erhält die erforderlichen Nutzer-, Gruppen- oder RBAC-Metadaten. Bei Skillsets mit Chunking müssen die Berechtigungsfelder in die Indexprojektionen gelangen, damit keine ungeschützten Chunk-Zeilen entstehen.
3. Suche autorisieren: Die Anwendung authentifiziert ihren Indexzugriff im normalen Authorization-Header und übermittelt die Identität des Endnutzers zusätzlich über x-ms-query-source-authorization. Diese Übergabe ist Bestandteil jeder geschützten Suchanfrage.

Die integrierten Prüfpfade wirken unabhängig voneinander: Eine passende Nutzer-ID, Gruppen-ID oder ein gültiger RBAC-Bereich kann den Zugriff erlauben. Der Wert all steht für globale Zugänglichkeit im jeweiligen Modell und darf nur bewusst gesetzt werden. Ohne Endnutzertoken geben aktuelle Preview-Versionen keine ACL-geschützten Dokumente zurück; öffentlich zugängliche Dokumente können weiterhin erscheinen.

4. Die Migration darf keine offene Zwischenstufe erzeugen

Bei einem bestehenden Index müssen Indexschema, Berechtigungsdaten und Abfragecode zusammen umgestellt werden. Zuerst wird erfasst, welche Felder Nutzer, Gruppen und bislang implizit öffentliche Dokumente darstellen. Danach werden Permission Filter aktiviert und vollständig befüllt; erst wenn alle Suchpfade das neue Verfahren verwenden, können alte Filter entfallen.

Die offizielle Azure-RAG-Referenzanwendung ergänzt für die Migration die delegierte Berechtigung user_impersonation, aktiviert Permission Filtering und setzt bei eingeschaltetem AZURE_ENFORCE_ACCESS_CONTROL den Header x-ms-query-source-authorization bei jeder Suche. Dokumente, die ältere Versionen wegen leerer ACL-Felder als global behandelten, benötigen im integrierten Modell ausdrücklich ["all"]; dafür beschreibt das Projekt eine einmalige Migration.

Die Anwendung sollte während der Umstellung geschlossen fehlschlagen. Ist das erforderliche Token ungültig oder kann der delegierte Tokenfluss nicht abgeschlossen werden, darf das Backend nicht ersatzweise eine unbeschränkte Service-Abfrage ausführen. Auch ein neuer Such- oder Quellen-Endpunkt bleibt bis zur eingebauten Rechteprüfung deaktiviert.

5. Negative Tests entscheiden über die Freigabe

Ein erfolgreicher Abruf mit einem berechtigten Konto belegt nur, dass der Dienst erreichbar ist. Die Abnahme braucht Gegenproben mit mindestens einem privaten Nutzerdokument, einem Gruppendokument, einem bewusst global freigegebenen Dokument und einem Dokument, auf das das Testkonto keinerlei Rechte besitzt.

• Nutzer A findet das eigene Dokument, aber nicht das private Dokument von Nutzer B.
• Ein Gruppenmitglied erhält den Gruppentreffer; ein Nutzer außerhalb der Gruppe erhält ihn bei derselben eindeutigen Suchphrase nicht.
• Eine integrierte Abfrage ohne Endnutzertoken liefert keine ACL-geschützten Inhalte.
• Quellen-, Vorschau- und Download-Endpunkte erzwingen dieselben Rechte wie die Chat-Suche.
• Nach einem Rechteentzug bleibt der Test bis zur erforderlichen Neuindizierung oder Synchronisation als nicht bestanden markiert; die tatsächliche Verzögerung wird im Betrieb überwacht.
• Wird beim String-Modell der Filter absichtlich entfernt, muss der Anwendungstest fehlschlagen. Beim integrierten Modell muss ein fehlender oder ungültiger Identitätsnachweis zu einem Fehler oder einem Ergebnissatz ohne geschützte Dokumente führen.

Dieselbe Matrix ist für hybride Suche, reine Vektorsuche, Folgefragen und weitere Chat-Modi nötig, sofern die Anwendung sie anbietet. Entscheidend ist nicht die sichtbare Anmeldung, sondern die durchgängige Verbindung von bestätigter Identität, indexierten Berechtigungen und jeder einzelnen Suchanfrage.

Lesen Sie auch:

• SAFE oder Wandeldarlehen: Der schnellere Vertrag kann später teurer werden
• EU AI Act 2026: Was jetzt gilt – und was bis 2028 warten kann
• OpenAI-Agenten brachen aus der Sandbox aus – der Bericht zeigt warum