Kapitel 7 — Zugriffskontrolle umsetzen

Siebter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Berechtigungsmodelle, die für relationale Datenbanken und Dateisysteme entworfen wurden, passen für Retrieval nicht ganz. Die Zugriffseinheit ist nicht mehr eine Zeile oder eine Datei, sondern ein Embedding — und ein Embedding kann das Original über Ähnlichkeit verraten, auch wenn das Dokument selbst gesperrt ist.

Warum dieses Kapitel existiert

Kapitel 6 hat das Bedrohungsmodell produziert. Die wichtigste Kontrolle, die es impliziert — und die, die die meisten frühen Produktionssysteme falsch machen — ist Zugriffskontrolle auf der Retrieval-Schicht, damit das LLM nie Inhalte sieht, die der Nutzer nicht sehen darf. Die naive Alternative, "bei der Generierung filtern", baut einen Confused Deputy: Das Modell hat die gesperrten Dokumente bereits gelesen und wird ihre Substanz per Paraphrase durchsickern lassen.

Dieses Kapitel geht die vier Mechanismen durch, die sich zu einem funktionierenden Zugriffskontroll-Stack zusammensetzen — dokumentbezogene ACLs als Fundament, RBAC, integriert mit den bestehenden Sensitivitäts-Labels des Unternehmens, ReBAC für die beziehungsförmige Realität von Unternehmenswissen und die Pre-Filter-gegen-Post-Filter-Disziplin, die unter allen läuft.

7.1 Dokumentbezogene ACLs und Metadaten-Filterung

Jeder Chunk weiß, wer ihn sehen darf. Die Umsetzung ist in der Beschreibung geradlinig; die Versagensmuster sind subtil genug, dass fast jedes frühe Produktionssystem es mindestens einmal falsch macht. Drei Details zählen am meisten. Granularität: Ein langer Bericht kann eine öffentliche Zusammenfassung und einen vertraulichen Anhang haben, und eine einzige dokumentbezogene ACL, die uniform auf Chunks vererbt wird, gibt entweder den Anhang frei oder hält die Zusammenfassung zurück. Das Muster, das skaliert, ist, abschnittsbezogene Berechtigungen durch layoutbewusstes Parsing zu tragen.

Frische: Berechtigungen ändern sich. Die ACL beim Indizieren in den Chunk zu backen und nie neu zu bewerten, gibt dir ein System, das lügt. Speichere einen stabilen Identifikator in den Chunk-Metadaten und löse die Live-ACL zur Query-Zeit gegen das Quellsystem auf, hinter einem Cache mit kurzer TTL. Negativraum: Liegt die Antwort in einem gesperrten Dokument, sollte das System nicht halluzinieren und nicht selbstbewusst "ich weiß es nicht" sagen — es sollte sagen "es gibt Material zu diesem Thema, das du nicht sehen darfst". Das verlangt entweder einen zweiten, ungefilterten Aufruf oder eine Vektordatenbank, die "kein Treffer" von "Treffer, aber gefiltert" unterscheidet, und die meisten Implementierungen drücken sich davor.

7.2 RBAC und Microsoft Purview Sensitivity Labels

RBAC komprimiert den Berechtigungsraum — statt Millionen Nutzer-zu-Dokument-Kanten reduziert die Policy sich auf ein paar hundert Rolle-zu-Klassifikation-Kanten, was zugleich auditierbar und wartbar ist. Es passt sauber zu RAG, wenn das Unternehmen ohnehin darauf läuft. In Microsoft-Umgebungen heißt das Entra-ID-Gruppen und Purview Sensitivity Labels: Public, General, Confidential, Highly Confidential, mit optionalen Sub-Labels. Das Label wandert mit dem Dokument; der Parser liest es beim Indizieren und schreibt die stabile Label-ID in die Chunk-Metadaten.

Die Integration ist geradlinig, die Drift nicht. Wenn der Indexer als Servicekonto läuft, das alles entschlüsseln darf, aber das Retrieval-System einen rollenbasierten Filter über dem Index erzwingt, dann werden bei einem Dokument, das von General auf Confidential umgelabelt wird, die bereits indizierten Chunks nicht neu gelabelt, sofern der Indexer die Änderung nicht bemerkt. Die Systeme, die das richtig machen, fahren eine kontinuierliche Reconciliation gegen die Quelle. Die Systeme, die es falsch machen, entdecken die Drift bei einem Audit, und der Befund ist schwerwiegend.

7.3 ReBAC mit Zanzibar und SpiceDB

RBAC kann "jeder im Vertrieb, der auch dem Acme-Corp-Deal zugewiesen ist" nicht ausdrücken. Das verlangt, eine Beziehung zwischen Nutzer und Ressource zu berücksichtigen, nicht nur eine Rolle. Relationship-Based Access Control, im Zanzibar-Paper bei Google formalisiert und als SpiceDB und OpenFGA Open Source verfügbar, speichert einen Graphen: "Alice ist Mitglied von Engineering", "Engineering ist Viewer auf Ordner Specs", "Spec-101 liegt in Specs". Berechtigungs-Checks werden zu Graphtraversalen.

Das Integrationsmuster mit RAG ist sauber. SpiceDB bekommt die Frage welche Dokumente kann dieser Nutzer sehen? und liefert eine Liste von Dokument-IDs; das Retrieval-System reicht diese Liste als Metadaten-Filter an die Vektorsuche weiter. Zanzibars Zookies erlauben es dem Retrieval-Aufruf, auf Konsistenz mindestens so frisch wie eine gerade gewährte Berechtigung zu bestehen — ein Nutzer, der um 10:00 einem Projekt hinzugefügt wird und um 10:01 fragt, sieht die neuen Dokumente. Die operativen Kosten sind, dass SpiceDB zu einer kritischen Abhängigkeit im Query-Pfad wird, die HA und aggressives, kurz-TTL-Caching der Pro-Nutzer-Dokumentlisten braucht. Gereifte Systeme nutzen oft beides — RBAC für die breite Sensitivitäts-Policy, ReBAC für die feingranulare Beziehungs-Policy, kombiniert als Schnittmenge der erlaubten Sets.

7.4 Pre-Filter, Post-Filter und die Disziplin darunter

Pre-Filtering wendet das Autorisierungs-Prädikat vor der Vektorsuche an — der Index begrenzt zuerst die Kandidatenmenge, dann läuft die Ähnlichkeit über die Begrenzung. Konzeptionell sauber und die sicherere Voreinstellung, aber die Performance hängt von der Indexstruktur ab. HNSW mit einem hochselektiven Filter kann scharf abfallen, weil die Graphtraversierung viele Nicht-Treffer-Knoten durchläuft; filterbare HNSW-Varianten in Weaviate und Qdrant und Pro-Mandanten-Namespaces in Pinecone und Milvus mildern, eliminieren aber nicht.

Post-Filtering kehrt die Reihenfolge um. Volle HNSW-Geschwindigkeit, schwächere Sicherheit: das Top-K-Leck, das Timing-basierte Informationsleck und das Korrektheitsleck, wenn das ganze Top-K weggefiltert wird. Die pragmatische Produktionsantwort ist, beides zu schichten — Pre-Filter auf das gröbste, schnellste Prädikat (Mandant, breite Rolle), Post-Filter auf die teuren präzisen Prädikate (SpiceDB-Listen, Purview-Labels) — und Over-Fetching der Top-50 statt Top-10, damit der Post-Filter trotzdem ein volles geranktes Set übriglässt. Zwei weitere Stellen lecken: das Prompt-Template, das einen vertraulichen Dokumenttitel zitiert, und der Response-Cache, der allein auf dem Query-String basiert. Beide gehören in die Autorisierungs-Oberfläche.

Was Kapitel 7 vorbereitet

Zugriffskontrolle beantwortet wer kann was sehen. Sie nimmt an, dass es etwas zu sperren gibt. Sie fragt nicht, ob der Chunk in der Form eingebettet werden sollte, in der er war — ob die Kundennamen, Sozialversicherungsnummern, proprietären Code-Pfade überhaupt im Vektor-Store sitzen sollten und auf die richtige Autorisierung warten dürfen, um aufzutauchen. Das ist die Frage der Anonymisierung, und sie ist das Thema des nächsten Kapitels.

Als Nächstes — Kapitel 8: Datenanonymisierung in der RAG-Pipeline. Pre-Generation gegen Post-Generation, Masking gegen synthetischer Ersatz gegen differenzielle Privatsphäre und der Utility-Privacy-Tradeoff, den jede Wahl navigieren muss.