BLUF: RAG wird nicht dadurch enterprise-tauglich, dass die Antworten in einer Demo gut aussehen. Es wird erst dann belastbar, wenn Retrieval berechtigungsbewusst arbeitet, sensible Felder vor dem Modell redigiert werden und jede Antwort über Dokumente, Rollen, Prompts und Modellantworten nachvollziehbar bleibt.
Der zentrale Fehler ist schlicht: Ein Sprachmodell antwortet aus dem Kontext, den es erhält. Wenn die Retrieval-Schicht Kontext zusammenstellt, den die anfragende Person nicht sehen dürfte, wird Identity and Access Management zu einer Kontrolle zur Abfragezeit — nicht nur zu einem Login-Thema im Portal.
Warum RAG-Sicherheit anders ist als Chatbot-Sicherheit
Eine klassische Chatbot-Prüfung betrachtet Prompt Injection, Output-Validierung und Modellverhalten. RAG ergänzt eine zweite Angriffsfläche: den Suchindex. Enthält der Index HR-Dokumente, juristische Notizen, Kundenverträge und Betriebsanleitungen, werden Ranking und Filterung zu sicherheitsrelevanten Operationen.
OWASP nennt Prompt Injection und die Offenlegung sensibler Informationen als zentrale Risiken für LLM-Anwendungen. In RAG-Systemen treffen beide Risiken aufeinander: Angreifer können versuchen, Retrieval zu beeinflussen oder das Modell dazu zu bringen, Fragmente preiszugeben, die hätten gefiltert, zusammengefasst oder zurückgehalten werden müssen.
Referenzarchitektur: Zugriff vor Generierung erzwingen
Eine praxistaugliche Enterprise-RAG-Pipeline trennt sechs Kontrollen: Identitätsauflösung, Übernahme der Dokumenten-ACLs, Security Trimming im Retrieval, Redaktion, Generierung und Audit-Logging. Verlassen Sie sich nicht darauf, dass das LLM Richtlinien „berücksichtigt“. Richtlinien müssen den Kontext formen, bevor der Prompt gebaut wird.
Implementierungsmuster: 1) Benutzer- und Gruppen-Principals aus dem Identity Provider auflösen; 2) erlaubte Principals pro indiziertem Chunk speichern; 3) zur Abfragezeit filtern, sodass nur autorisierte Chunks Kandidaten sind; 4) regulierte Felder vor der Prompt-Erstellung redigieren, wenn kein Need-to-know besteht; 5) Antwort mit Quellenhinweisen generieren; 6) unveränderbare Audit-Events für Anfrage, Chunk-IDs, Policy-Entscheidungen, Prompt-Hash, Modell-ID und Antwort-ID schreiben.
Microsoft beschreibt dieses Muster für Azure AI Search als Security Trimming: Benutzer- oder Gruppenkennungen werden in einem filterbaren Feld gespeichert und per Abfragefilter, etwa search.in, mit den Principals des Anfragenden abgeglichen. Das Architekturprinzip gilt auch außerhalb von Azure: vor dem Ranking oder spätestens vor der Prompt-Erstellung filtern und testen, dass unautorisierte Chunks nie in den Modellkontext gelangen.
Checkliste: Kontrollen, die Enterprise-RAG sicher genug machen
| Kontrolle | Guter Produktionsstandard | Fehlerbild bei Lücke |
|---|---|---|
| Dokumentenberechtigungen | ACLs aus dem Quellsystem übernehmen und pro Chunk erhalten | Benutzer sehen Auszüge aus Dateien, die sie in SharePoint, Confluence, Google Drive oder DMS nicht öffnen dürfen. |
| Security Trimming | Principal-basierte Filter zur Retrieval-Zeit anwenden | Der Login funktioniert, aber Retrieval umgeht das Autorisierungsmodell der Quelle. |
| Redaktion | Secrets, personenbezogene Daten und Vertragswerte vor der Prompt-Erstellung entfernen oder maskieren, wenn sie nicht erforderlich sind | Das Modell kann sensible Werte zitieren, auch wenn die UI sie später versteckt. |
| Audit-Logs | Benutzer, Principals, Anfrage, Chunk-IDs, Policy-Ergebnis, Modell- und Antwortmetadaten erfassen | Vorfälle lassen sich nicht rekonstruieren; Compliance-Teams können den Ablauf nicht prüfen. |
| Evaluation | Mit unautorisierten Benutzern, veralteten Gruppen, manipulierten Dokumenten und Prompt-Injection-Strings testen | Das System besteht Demos, versagt aber bei realistischem Missbrauch. |
Berechtigungen: Chunks wie Datensätze mit Eigentümer behandeln
Der häufigste RAG-Fehler ist, Dokumente in Chunks zu zerlegen und dabei den Sicherheitskontext zu verlieren. Jeder Chunk benötigt mindestens Quelldokument-ID, Quellversion, erlaubte Principals, Sensitivitätslabel, Aufbewahrungsklasse und Ingestionszeitpunkt. Ändert sich eine Dokumentberechtigung, müssen alle betroffenen Chunks aktualisiert oder bis zur Neuindizierung ausgeschlossen werden.
Für risikoreiche Repositories ist Deny-by-default sinnvoll. Ein Chunk ohne valide ACL sollte nicht suchbar sein. Wenn das Quellsystem keine verlässlichen Berechtigungen exportieren kann, sollten Sie es nicht an einen breiten Mitarbeiterassistenten anschließen, bevor ein kompensierender Freigabeprozess existiert.
Redaktion: reduzieren, was das Modell sieht
Redaktion nach der Generierung ist schwächer als Redaktion vor der Generierung. Sobald sensibler Text im Kontextfenster steht, kann er Zusammenfassungen, Begründungen und Zitate beeinflussen. Nutzen Sie deterministische Redaktion für bekannte Muster wie API-Keys, IBANs, Personalnummern und Vertragssummen; ergänzen Sie fachliche Prüfung dort, wo False Positives oder False Negatives materielles Risiko erzeugen.
Das bedeutet nicht, alles zu redigieren. Übermäßige Redaktion zerstört Nutzwert und erzeugt Schattenprozesse. Das technische Ziel ist Zweckbindung: nur den minimalen Kontext abrufen, der die autorisierte geschäftliche Frage beantwortet.
Audit-Logs: was erfasst werden sollte, ohne neue Geheimnisse zu protokollieren
NIST SP 800-53 enthält Kontrollen für Audit und Accountability; das NIST AI RMF betont Governance, Messung und Risikomanagement über den KI-Lebenszyklus. Für RAG muss Auditierbarkeit sowohl Anwendungssicherheit als auch KI-Verhalten abdecken.
Protokollieren Sie Benutzer-ID, aufgelöste Gruppen, Zeitstempel, abgefragte Quellsysteme, Dokument-IDs, Chunk-IDs, Policy-Entscheidungen, Redaktionsereignisse, Prompt-Template-Version, Modellname, Antwort-ID, Latenz, Token-Verbrauch und Eskalationsentscheidung. Speichern Sie vollständige Prompts nur dann, wenn diese neue Datensammlung durch Retention- und Zugriffskontrollen abgesichert ist.
Operative Trade-offs
Security Trimming erhöht Latenz, wenn Benutzer sehr vielen Gruppen angehören. Redaktion kann nützlichen Kontext entfernen. Detaillierte Logs können selbst zu einem sensiblen Datenbestand werden. Neuindizierung nach Berechtigungsänderungen erhöht Infrastrukturkosten. Das sind keine Gründe, Kontrollen wegzulassen; es sind Gründe, Budgets, Cache-Invalidierung und Aufbewahrung explizit zu entwerfen.
Ein belastbarer Startpunkt für viele deutsche B2B-Umgebungen ist: Quellkonnektoren für zwei oder drei wertvolle Repositories, Deny-by-default-Indizierung, ACL-Filter zur Abfragezeit, deterministische Secret-Redaktion, Quellenhinweise in Antworten und ein 30-Tage-Audit-Log mit Zugriff nur für berechtigte Security-Rollen. Erweitern Sie erst, wenn Evaluation zeigt, dass unautorisiertes Retrieval, veraltete Berechtigungen und Prompt-Injection-Tests geschlossen fehlschlagen.
Wo Ade unterstützen kann
Wenn Ihr Team einen internen RAG-Assistenten plant, lautet die technische Frage nicht zuerst „welche Vektordatenbank sollen wir nutzen?“. Die erste Frage lautet, ob Ihre Retrieval-Schicht dieselben Vertrauensgrenzen erzwingen kann wie Ihre Enterprise-Systeme. Ade Christanto unterstützt B2B-Teams bei KI-Automatisierung mit berechtigungsbewusstem Retrieval, Auditierbarkeit und operativen Kontrollen für den Produktionsbetrieb.
Quellen
OWASP Top 10 for LLM Applications — Prompt Injection und Offenlegung sensibler Informationen: https://owasp.org/www-project-top-10-for-large-language-model-applications/
Microsoft Azure AI Search Security Filters — Filterung zur Abfragezeit mit Principal-Kennungen: https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search
NIST AI Risk Management Framework — Governance- und Messrahmen für KI-Risiken: https://www.nist.gov/itl/ai-risk-management-framework
NIST SP 800-53 Rev. 5 — Kontrollkatalog für Security und Privacy einschließlich Audit und Accountability: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
