Kernaussage: Ein Enterprise-RAG-System ist nicht sicher, weil es einen ACL-Filter und eine Vektordatenbank besitzt. Es ist sicher, wenn ein benannter Owner für jede Antwort nachweisen kann, welche Identität geprüft wurde, welche Policy-Version galt, welche Quell-Chunks zulässig waren, was geschwärzt wurde und wie Ausnahmen oder Incidents behandelt werden. Das ist ein Betriebsmodell, keine Feature-Checkliste.
Warum die Kontrollen zusammenwirken müssen
Die Pipeline überschreitet mehrere Sicherheitsgrenzen: Quellen-Onboarding, Klassifizierung, Chunking, Embedding, Retrieval, Prompt-Konstruktion, Modellausgabe und Betriebsnachweise. Eine Policy, die nur im Frontend durchgesetzt wird, versagt, sobald eine andere Integration das Retrieval direkt aufruft. Ein Filter nach der Top-k-Suche kann unberechtigten Text bereits in den Modellkontext bringen. Ein Log, das nur die finale Antwort aufzeichnet, kann keine korrekte Zugriffsentscheidung erklären.
Die OWASP-Leitlinie LLM08:2025 nennt unbefugten Zugriff, Cross-Context-Leaks und Data Poisoning als RAG-Risiken und empfiehlt feingranulare, berechtigungsbewusste Vektor- und Embedding-Stores mit logischer Trennung. Praktisch folgt daraus: Die Autorisierung muss vor der Auswahl von Kontext für den Prompt bewertet werden, nicht nachträglich aus der Antwort abgeleitet werden.
Der minimale Kontrollpfad für die Produktion
1. Binden Sie eine stabile anfragende Identität und die relevanten Attribute an jede Anfrage. Erfassen Sie menschlichen Nutzer, Service-Identität, Mandant oder Geschäftseinheit, Rolle, gegebenenfalls Zweckbindung und Authentisierungsstärke. Eine Konversationskennung ersetzt keine Identität.
2. Erhalten Sie Quellmetadaten beim Ingestion-Prozess. Jeder Chunk benötigt eine unveränderliche Quell-ID, Quellversion, Klassifizierung, Owner, zulässige Zielgruppe, Aufbewahrungsstatus und policyrelevante Attribute. Beim Re-Indexing müssen diese Metadaten mitgeführt werden, sonst entsteht unbemerkt ein breiterer Zugriffspfad.
3. Machen Sie den Retrieval-Service zum Policy Enforcement Point. Er sollte Identität und Attribute vor dem Modellkontext in eine Allowlist oder einen serverseitigen Filter überführen. Die Anwendung darf sich nicht darauf verlassen, dass das LLM ein Dokumentenlabel respektiert. An kritischen Grenzen senken getrennte Indizes oder Mandanten den Blast Radius, erhöhen jedoch Betriebskosten und Update-Komplexität.
4. Konstruieren Sie den Prompt aus dem autorisierten, minimal erforderlichen Auszug. Wenden Sie vor dem Kontextaufbau deterministische Schwärzung für Geheimnisse, personenbezogene Daten oder eingeschränkte Felder an. Schwärzung ersetzt keine Autorisierung: Ist eine Quelle verboten, darf sie nicht allein deshalb abgerufen werden, weil ein Pattern-Scanner möglicherweise Teile entfernt.
5. Erzeugen Sie Evidenz an jedem Entscheidungspunkt. Protokollieren Sie Korrelations-ID, Nutzer- und Service-Identität, Policy-Version, Filter- oder Entscheidungsreferenz, Kandidaten- und zurückgelieferte Quell-IDs, Schwärzungsaktion, Modell- und Prompt-Template-Version, Antwortdisposition, Latenz und Fehlerklasse. Speichern Sie sensible Rohpassagen nicht standardmäßig; auch der Evidenzspeicher benötigt Zugriffskontrolle und Aufbewahrungsregeln.
Betriebsmodell: Ownership, Änderungen und Entzug
Der Owner der Wissensbasis verantwortet Quellenqualität und Klassifizierung. IAM- oder Plattform-Owner verantworten die Policy-Auswertung. Produkt-Owner verantworten vorgesehene Nutzergruppen und Eskalationswege. Security sollte das Kontrolldesign freigeben und regelmäßig testen; sie sollte nicht zur Warteschlange für die manuelle Freigabe jedes Dokuments werden.
Der wertvollste Test ist der Berechtigungsentzug. Entfernen Sie einen Nutzer aus einer Gruppe, ändern Sie eine Dokumentklassifizierung, löschen Sie eine Quelle oder lassen Sie eine Aufbewahrungsregel ablaufen; weisen Sie dann nach, dass alte Chunks in jedem Index, Cache, Reranker und Konversationsspeicher nicht mehr verfügbar sind. Definieren Sie ein messbares Revocation-Ziel. Ein nächtliches Update kann für ein risikoarmes Handbuch genügen, nicht aber für Incident-Daten oder Personaldaten, bei denen Zugriff zeitnah verschwinden muss.
Incident Response bei RAG-Datenabfluss
Bereiten Sie vor dem Deployment ein Runbook vor. Bei Verdacht auf Datenabfluss stoppen Sie zuerst den betroffenen Retrieval-Pfad oder Mandantenbereich, sichern Korrelations-IDs sowie Policy- und Index-Versionen und klären, ob Autorisierung, veraltete Metadaten, Cache, Connector oder Prompt Injection die Ursache waren. Dämmen Sie anschließend ein: betroffene Berechtigungen entziehen, abgeleitete Artefakte invalidieren, exponierte Secrets rotieren und den internen Incident-Prozess informieren. Rechtliche Meldepflichten hängen von Sachverhalt und Jurisdiktion ab; lassen Sie diese rechtlich prüfen.
Eine belastbare Untersuchung beantwortet schnell fünf Fragen: Wer hat die Antwort angefragt? Welche Policy hat sie erlaubt? Welche Chunks erreichten das Modell? Enthielt die Ausgabe diese Daten? Welche weiteren Anfragen nutzten denselben veralteten Index oder Cache? Müssen diese Antworten aus mehreren unverbundenen Logs rekonstruiert werden, ist das Design nicht auditfähig.
Praktischer Abnahmetest
Testen Sie vor Go-live mit synthetischen eingeschränkten Dokumenten und Identitäten, die zugelassen, abgewiesen und gerade entzogen wurden. Decken Sie mandantenübergreifende Anfragen, veraltete ACL-Änderungen, Connector-Ausfälle, vergiftete Dokumente mit Instruktionen, leeres Retrieval und einen Fail-Closed-Ausfall des Policy-Service ab. Messen Sie Sicherheit und Serviceverhalten: Korrektheit der Ablehnung, Rate unbefugter Chunks, Dauer bis zum Berechtigungsentzug, Vollständigkeit der Audit-Events, Retrieval-Latenz und False-Positive-Rate der Schwärzung.
Lassen Sie bei Ausfall von Identität, Policy-Service oder Metadaten nicht unbemerkt Fail Open zu. Ein Fail-Closed-Retrieval kann die Verfügbarkeit senken; definieren Sie daher einen fachlich freigegebenen Fallback, etwa Antworten nur aus kuratiertem öffentlichen Material oder die klare Meldung, dass eine Quelle aktuell nicht erreichbar ist. Dieser Trade-off ist belastbarer als plausibler, aber unberechtigter Kontext.
Entscheidungscheckliste
Sie können über den Prototyp hinausgehen, wenn Sie alle Fragen mit Ja beantworten: Ist jeder Chunk auf Owner und Quellversion zurückführbar? Wird Autorisierung vor der Prompt-Konstruktion durchgesetzt? Können Sie den Entzug über Indizes und Caches nachweisen? Sind Schwärzungsregeln deterministisch und getestet? Kann eine Untersuchung eine Antwort ohne unnötige sensible Rohdaten rekonstruieren? Gibt es Ownership für Policy Drift und Connector-Ausfälle?
Quellen
OWASP GenAI Project, LLM08:2025 Vector and Embedding Weaknesses: https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
NIST SP 800-92, Guide to Computer Security Log Management: https://csrc.nist.gov/pubs/sp/800/92/final
Dies ist technische Umsetzungshilfe und keine Rechtsberatung. Für regulierte Verarbeitung sollten Sie Aufbewahrung, Zugriffsprüfung und Incident-Pflichten mit Ihrer Rechtsberatung und den einschlägigen Anforderungen abgleichen.
