Deep Dive: Security Trimming in RAG-Systemen - Berechtigungen auf Dokumentenebene mit Azure AI Search
Security Trimming in RAG-Systemen entscheidet darüber, ob Ihr KI-Agent sensible Gebotskalkulationen, PPA-Konditionen und Wirtschaftspläne korrekt vertraulich behandelt, oder sie versehentlich an unberechtigte Nutzer ausgibt. Dieser Deep Dive zeigt am Beispiel eines Wind- und Solarparkentwicklers, wie Berechtigungen mit Azure AI Search auf Dokumentenebene funktionieren und warum das zugleich die DSGVO-Anforderungen aus Art. 32 erfüllt.
Vier Wochen vor der nächsten BNetzA-Ausschreibung. Ein Projektentwickler hat die letzten Monate damit verbracht, das Gebot für ein 80-MW-Vorhaben durchzurechnen. Die Stromgestehungskosten sind die wirtschaftlich sensibelste Zahl im gesamten Unternehmen - sie entscheiden über Zuschlag oder Niederlage.
Im internen RAG-Agenten fragt eine Person aus einem externen Planungsbüro, das routinemäßig Standortbewertungen liefert: „Welche LCOE-Werte sind für vergleichbare Binnenlandstandorte aktuell realistisch?“ Die Antwort des Modells enthält Auszüge aus dem laufenden Gebotskalkulationsmodell.
Drei Wochen später bietet ein Wettbewerber im selben Lossegment. Knapp unter dem eigenen Wert. Das Projekt ist verloren. Was als hilfreiche KI-Recherche gedacht war, ist zu einem siebenstelligen Schaden geworden.
In der Wind- und Solarparkentwicklung gehören Gebotskalkulationen, PPA-Konditionen, Wirtschaftspläne und Standortgutachten zu den wirtschaftlich sensibelsten Dokumenten überhaupt. Projektentwickler führen parallel Tausende weiterer Dokumente: BImSchG-Antragsunterlagen, Artenschutzgutachten, Schallprognosen, Netzanschlussverträge, Pachtverträge und interne Korrespondenz. Wer diese Dokumentenflut mit einem RAG-Agenten durchsuchbar machen will, steht plötzlich vor einem Problem, das es in klassischen Dokumentenmanagementsystemen so nicht gab.
Das vergessene RAG-Problem: Der KI-Agent kennt keine Berechtigungen
In klassischen Systemen wie SharePoint ist Zugriffskontrolle ein gelöstes Problem. Sperren Sie eine Datei für einen Nutzer, sieht er sie schlicht nicht. In RAG-Systemen ist das grundlegend anders.
Retrieval-Augmented Generation zerlegt Dokumente in kleine Textabschnitte, sogenannte Chunks. Eine 80-seitige Wirtschaftsplanung wird zu 300 Chunks. Jeder Chunk wird als Vektor eingebettet und in einem Suchindex abgelegt. Stellt ein Nutzer eine Frage, holt das System die relevantesten Chunks. Ein Sprachmodell generiert daraus die Antwort.
Das Sprachmodell hat keinen Zugriffskontext. Es sieht nur Text.
Gelangt ein unberechtigter Chunk in den Prompt, gibt das Modell dessen Inhalt bereitwillig wieder, vollständig formuliert, ohne dass der Nutzer jemals das Originaldokument geöffnet hätte. Die Stromgestehungskosten aus dem internen Gebotsmodell landen in der Antwort an einen externen Dienstleister. Die Verhandlungsposition bei Ihrer nächsten Ausschreibung ist kompromittiert und Sie wissen nicht einmal, dass es passiert ist.
Hinzu kommt die Granularitätsexplosion: Ein Chunk ist kein Dokument. Jeder einzelne der 300 Chunks aus der Wirtschaftsplanung muss korrekt berechtigt sein. Eine naive Implementierung ignoriert das - mit spürbaren Folgen.
Das Muster: Security Trimming
Der Branchenstandard für diese Herausforderung heißt Security Trimming. Die Grundidee ist einfach und schlagkräftig zugleich:
Berechtigungen leben bei den Daten, nicht bei der Anwendung.
Jedes Dokument erhält beim Indexieren Metadaten, welche Gruppen es sehen dürfen. Zur Abfragezeit wird der Suchindex angewiesen, nur solche Dokumente zurückzugeben, für die der aktuelle Nutzer berechtigt ist. Das Sprachmodell sieht niemals einen Chunk, auf den der Nutzer keinen Zugriff hat.
Der entscheidende Vorteil gegenüber einer App-seitigen Filterung: Der Index gibt keine unberechtigten Daten zurück. Auch dann nicht, wenn die Anwendungslogik Fehler enthält oder eine neue Schnittstelle hinzukommt. Sicherheit ist kein Feature der Anwendung, sondern eine Eigenschaft der Datenstruktur.
Die Azure-Architektur im Überblick
Das technische Setup kombiniert fünf zentrale Azure-Komponenten. Jede ist ein Microsoft-Standardbaustein und kein proprietäres Konstrukt. Das macht die Lösung auditierbar und für mittelständische IT-Abteilungen nachvollziehbar.
| Komponente | Rolle |
|---|---|
| Microsoft Entra ID | Authentifizierung des Nutzers über Azure App Service |
| Azure Table Storage | Schlanke Datenbank für die E-Mail-zu-Gruppen-Zuordnung |
| Azure AI Search | Suchindex mit integriertem OData-Filter für Security Trimming |
| Azure Functions | Orchestrierungs- und Business-Logik-Schicht |
| Azure OpenAI | Sprachmodell, das aus den berechtigten Chunks antwortet |
Der Datenfluss: Vom Login bis zur Antwort
Fragt der Projektleiter im internen Tool nach „Pachtkonditionen Flurstück 127“, durchläuft die Anfrage fünf Stufen.
Schritt 1 - Nutzer identifizieren
Azure App Service stellt nach erfolgreicher Entra-ID-Authentifizierung den Header X-MS-CLIENT-PRINCIPAL-NAME bereit. Daraus liest die Lösung die E-Mail-Adresse des anfragenden Nutzers aus. Kein Passwort im RAG-System, keine redundante Benutzerverwaltung.
Schritt 2 - Gruppenzuordnung laden
Die E-Mail-Adresse dient als Schlüssel für einen Lookup in Azure Table Storage. Dort ist pro Nutzer hinterlegt, welchen Rollengruppen er angehört — zum Beispiel projektleitung, justiziariat, gutachter_artenschutz oder externer_planer.
Schritt 3 - OData-Filter an Azure AI Search übergeben
Die geladenen Gruppen-IDs werden in einen OData-Filter übersetzt und direkt an Azure AI Search übergeben. Dokumente im Index tragen ein Feld group_ids als Collection. Der Filter wird mit der Hybrid-Suche aus BM25 und Vektor in einem einzigen Aufruf kombiniert.
Der Sicherheitsfilter ist kein nachgelagerter Schritt. Er ist integraler Bestandteil der Indexabfrage.
Schritt 4 - App-seitige Nachkontrolle als zweite Schicht
Nach der Suche prüft der Anwendungslayer nochmals auf Chunk-Ebene. Das ist das Gürtel-und-Hosenträger-Prinzip: Selbst wenn der Index einen Fehler zurückgäbe, fängt die Applikationsschicht ihn auf. Drei Fälle werden unterschieden — vollständiger Zugriff, Teilzugriff mit Hinweis auf gesperrte Inhalte und kein Zugriff.
Schritt 5 - Sprachmodell erhält nur berechtigte Chunks
Erst wenn die Berechtigungsprüfung abgeschlossen ist, sieht das Sprachmodell Inhalte. Die vollständige Sicherheitslogik ist durchlaufen, bevor der erste Token generiert wird.
Das Indexschema: Wo Sicherheit technisch verankert ist
Der zentrale Kniff liegt im Indexschema. Jeder Chunk im Azure AI Search Index enthält unter anderem folgende Felder:
| Feld | Bedeutung |
|---|---|
chunk | Textinhalt des Chunks |
chunk_vector | Embedding-Vektor, typisch 1.536 Dimensionen |
title | Dokumenttitel |
parent_id | Verweis auf das Originaldokument |
permalink | Link zum Original für die Quellenangabe |
group_ids | Collection von Berechtigungsgruppen |
document_type | Dokumentkategorie — etwa Pachtvertrag, Gutachten oder Genehmigung |
Entscheidend ist das Feld group_ids. Es ist eine Collection: der Chunk kann also zu mehreren Gruppen gleichzeitig gehören. Ein Artenschutzgutachten für Flurstück 127 darf etwa für die Projektleitung und die Fachgutachter sichtbar sein. Der externe Planer oder der Landeigentümer-Self-Service bekommt es nicht zu sehen.
Das Rollenmodell in der Projektentwicklung
Die Stärke des Ansatzes zeigt sich im konkreten Mapping auf Ihre Projekt-Realität. In einem typischen Windpark-Entwicklungsprojekt mit 15 bis 30 Flurstücken lassen sich folgende Rollen unterscheiden:
| Rolle | Zugriff auf |
|---|---|
| Projektleitung | Alle Dokumente des Projekts |
| Justiziariat | Alle vertraglichen Dokumente |
| Fachgutachter (Artenschutz, Schall, Wind) | Eigene Gutachten, Flurstückskarten, öffentliche BImSchG-Unterlagen |
| Externer Planer | Nur öffentlich zugängliche Antragsunterlagen |
| Finanzierungspartner | Wirtschaftsplan, ausgewählte Vertragsköpfe — ohne Detail-Pachthöhen |
| Landeigentümer-Self-Service | Nur der eigene Pachtvertrag |
Besonders interessant: Die Rolle des Landeigentümer-Self-Service. Sie können den RAG-Agenten als Pächter-Portal anbieten. Jeder Eigentümer stellt Fragen zu seinem eigenen Vertrag und erhält eine sofortige Antwort. Technisch ausgeschlossen bleibt, dass er Inhalte aus Verträgen anderer Eigentümer oder aus internen Wirtschaftsunterlagen erhält. Das gleiche Prinzip schützt im Verhältnis zu externen Planern, Gutachtern und Finanzierungspartnern.
DSGVO: Security Trimming als technisch-organisatorische Maßnahme
Für den deutschen Mittelstand hat der Ansatz eine zweite, rechtliche Dimension. Security Trimming erfüllt die Anforderungen aus Art. 32 DSGVO an technisch-organisatorische Maßnahmen zur Datensicherheit:
- Vertraulichkeit durch Architektur: Zugriff ist technisch erzwungen, nicht nur organisatorisch geregelt.
- Nachvollziehbarkeit: Jede Abfrage läuft über Entra ID, Table Storage und den OData-Filter und damit vollständig auditierbar.
- Wirksamkeit: Das Kontrollprinzip liegt an der tiefsten Stelle der Datenstruktur, nicht auf Anwendungsebene.
Bei einem Datenschutz-Audit oder bei behördlichen Rückfragen im Zuge eines BImSchG-Verfahrens ist das ein belastbares Argument.
Warum dieser Ansatz skaliert
Drei konkrete Eigenschaften machen Security Trimming zum Produktionsstandard.
Neue Anwendungen übernehmen die Sicherheit automatisch
Ob ein zweites Frontend hinzukommt, eine Partner-API oder ein Auswertungsskript — die Berechtigungen gelten automatisch, solange der Index abgefragt wird.
Kein „vergessener Filter“
Ein Entwickler kann keinen neuen Endpoint bauen und den Sicherheitsfilter versehentlich weglassen. Der Filter ist Bestandteil der Indexabfrage, nicht ein optionaler Parameter in der Geschäftslogik.
Performance skaliert mit dem Index
Ob 1.000 oder 10 Millionen Chunks, Azure AI Search filtert auf Indexebene, bevor Ergebnisse übertragen werden. Es gibt kein „hole alles, filtere dann“.
Einordnung in unsere Deep-Dive-Serie
Dieser Beitrag schließt einen Aspekt, den wir in unseren bisherigen Beiträgen bewusst offen gelassen haben:
- Die Grundlagen von RAG und Azure AI Search finden Sie im ersten Deep Dive.
- Die Architektur eines RAG-Agenten in Microsoft Teams beschreibt der zweite Deep Dive.
- Ein konkreter Anwendungsfall zur Vertragsanalyse mit Power Platform steht im dritten Deep Dive.
Security Trimming ist der Baustein, ohne den keiner dieser drei Ansätze in die Produktion gehen sollte.
So unterstützt applied technologies Sie
Als Microsoft Solutions Partner begleiten wir Wind- und Solarparkentwickler bei ihrer RAG-Einführung. Unser Fokus: Azure und die Microsoft Power Platform. Unser Anspruch: vom ersten Architekturentscheid bis zur auditierbaren Produktivlösung.
Unsere Branchenlösung apptech Business Essentials RE bildet den kompletten Projektlebenszyklus ab. Von der Flächensicherung über die BImSchG-Genehmigung bis zum Betrieb auf einer einzigen Plattform. Das Rollenmodell und die Berechtigungsstruktur auf Dokumentenebene entwickeln wir gemeinsam mit Ihrem Fachbereich.
Ihre Dokumente. Ihre Berechtigungen. Ihr KI-Agent.
Starten Sie mit einer individuellen Security-Trimming-Demo und erleben Sie, wie Azure AI Search Ihr Projektwissen verfügbar macht, ohne dass Ihre Verhandlungsbasis in falsche Hände gerät.
Häufig gestellte Fragen zu Security Trimming in RAG
Was ist Security Trimming in RAG-Systemen?
Security Trimming ist ein Muster, bei dem Dokumente im Suchindex Berechtigungs-Metadaten tragen. Zur Abfragezeit liefert der Index nur die Dokumente zurück, für die der aktuelle Nutzer berechtigt ist. Das Sprachmodell in einem RAG-System sieht niemals einen Inhalt, auf den der Nutzer keinen Zugriff hat. Der Ansatz verlagert Sicherheit von der Anwendungsebene in die Datenstruktur selbst.
Warum brauchen RAG-Systeme Berechtigungen auf Dokumentenebene?
RAG-Systeme zerlegen Dokumente in kleine Textabschnitte und speichern sie in einem Suchindex. Das Sprachmodell hat keinen Zugriffskontext und verarbeitet jeden Chunk, der in den Prompt gelangt. Ohne Berechtigungen auf Dokumentenebene könnten vertrauliche Inhalte wie Gebotskalkulationen oder Wirtschaftspläne in Antworten an unberechtigte Nutzer landen — vollständig formuliert und ohne dass der Nutzer das Originaldokument jemals geöffnet hätte.
Wie erfüllt Security Trimming die Anforderungen aus Art. 32 DSGVO?
Art. 32 DSGVO verlangt technisch-organisatorische Maßnahmen zur Datensicherheit. Security Trimming erfüllt die drei zentralen Anforderungen: Vertraulichkeit durch Architektur (Zugriff ist technisch erzwungen, nicht nur organisatorisch geregelt), Nachvollziehbarkeit (jede Abfrage läuft über Entra ID und Suchindex-Filter und ist damit auditierbar) und Wirksamkeit (das Kontrollprinzip liegt an der tiefsten Stelle der Datenstruktur, nicht auf Anwendungsebene).
Welche Azure-Komponenten sind für Security Trimming in RAG notwendig?
Die Referenzarchitektur nutzt fünf Microsoft-Standardbausteine: Microsoft Entra ID für die Authentifizierung, Azure Table Storage für die E-Mail-zu-Gruppen-Zuordnung, Azure AI Search mit integriertem OData-Filter als Suchindex, Azure Functions für Orchestrierungs- und Business-Logik und Azure OpenAI als Sprachmodell. Die Kombination ist auditierbar und für mittelständische IT-Abteilungen nachvollziehbar aufgebaut.
Reicht App-seitige Filterung nicht aus, um RAG-Systeme abzusichern?
Nein. App-seitige Filterung schützt nur so lange, wie die Anwendungslogik fehlerfrei ist und kein zweiter Client auf den Index zugreift. Sobald eine neue Schnittstelle hinzukommt — ein zweites Frontend, eine Partner-API oder ein Auswertungsskript — kann sie den Filter umgehen. Security Trimming verlagert die Kontrolle an die Datenstruktur selbst. Der Index gibt keine unberechtigten Daten zurück, unabhängig davon, welche Anwendung ihn abfragt.
Wie lange dauert die Einführung von Security Trimming in einem bestehenden RAG-System?
Die Einführung hängt von der bestehenden Indexstruktur und dem Rollenmodell ab. In Projekten mit einem sauber modellierten Rollenkonzept erreichen wir ein erstes Pilotprojekt typischerweise in 4 bis 6 Wochen. Der größte Aufwand liegt nicht in der technischen Umsetzung, sondern in der gemeinsamen Definition des Rollenmodells mit dem Fachbereich — etwa welche Gruppen welche Dokumentenklassen sehen dürfen.