BLUF: Wählen Sie die Mandantentrennung eines RAG-Systems nach den Folgen eines Grenzversagens – nicht nach der Kundenzahl. Ein gemeinsam genutzter Vektorindex mit verpflichtendem Tenant-Metadatenfilter ist effizient, seine Grenze ist jedoch nur so belastbar wie der Code, der diesen Filter ableitet und anwendet. Nutzen Sie ein Silo, wenn vertragliche, regulatorische oder Blast-Radius-Anforderungen dedizierte Ressourcen verlangen. Nutzen Sie ein Bridge-Modell, wenn wenige Mandanten mit hohen Schutzanforderungen Silos benötigen und der übrige Bestand einen Pool teilen kann. Eine Vektordatenbank mit nativer Multi-Tenancy bietet eine weitere Variante: eine Collection mit einem eigenen physischen Shard je Tenant, sodass jede Datenbankoperation einen Tenant-Kontext verlangt. Leiten Sie die Tenant-Identität aus authentifizierten Claims ab, verweigern Sie Anfragen bei fehlendem Kontext, erzwingen Sie die Grenze vor dem Retrieval und behandeln Sie mandantenübergreifende Nichtoffenlegung als Release Gate.
Die Sicherheitsgrenze liegt im Retrieval-Aufruf
RAG-Zugriffskontrolle muss wirken, bevor Kandidaten-Chunks in den Prompt gelangen. Eine nachträgliche Schwärzung der Modellantwort kommt zu spät: Nicht autorisierter Text kann bereits Modell, Traces, Caches oder Evaluationslogs erreicht haben. Das grundlegende Muster zur RAG-Zugriffskontrolle vor dem Retrieval bindet deshalb die authentifizierte Identität vor der Vektorsuche an erlaubte Dokumentattribute. Multi-Tenancy verschärft die Frage: Wird diese Bindung durch Anwendungscode, einen Policy Decision Point, einen Tenant-Selektor der Datenbank oder eine Infrastrukturgrenze erzwungen?
AWS beschreibt für mandantenfähige RAG-Systeme die SaaS-Isolationskonzepte Silo, Pool und Bridge. Im Bedrock-Knowledge-Bases-Beispiel wird beim Silo der RAG-Stack je Tenant separat betrieben. Im Pool wird der gesamte Stack geteilt und beim Retrieval per Tenant-Metadaten gefiltert. Bridge nutzt gemeinsame Infrastruktur, ordnet Tenants aber getrennte Datenquellen, Knowledge Bases und Vektorindizes zu. Diese Muster sind keine Compliance-Zertifikate. Quelle: AWS-Referenzarchitektur für Multi-Tenant RAG.
Vier Positionen der Grenze statt drei Produktetiketten
Beim Silo umschließt die Grenze dedizierte Infrastruktur: tenantbezogener Objektspeicher, Knowledge Base und Vektorspeicher oder Index. Beim Pool liegt sie in jeder Abfrage: Eine gemeinsame Collection wird ausschließlich mit authentifiziertem Tenant-Filter durchsucht. Bei Bridge liegt sie in einer Tenant-zu-Ressource-Zuordnung. Native Datenbank-Multi-Tenancy verankert den Selektor in der Datenbank-API und speichert jeden Tenant in einem separaten Shard derselben Collection.
Weaviate dokumentiert für Multi-Tenancy-Collections einen separaten Shard je Tenant; Daten eines Tenants seien für andere Tenants nicht sichtbar. Die Clients verlangen den Tenant-Namen bei CRUD-Operationen. Damit wandert die Durchsetzung von einem frei formulierbaren Metadatenprädikat in einen tenantbewussten Datenbankpfad. Die Anwendung bleibt dennoch verantwortlich: Sie kann den falschen Tenant auswählen, per Tippfehler einen neuen Tenant erzeugen, über Caches leaken oder Backups falsch behandeln. Quelle: Weaviate Multi-Tenancy Operations.
Referenzarchitektur: von Identität zu tenantbezogenem Retrieval
CLIENT → Identity Provider → API Gateway → Authentifizierungs-Middleware → unveränderlicher Tenant-Kontext → Autorisierungsentscheidung → Isolationsrouter → [POOL: gemeinsamer Index + verpflichtender Tenant-Filter] ODER [NATIV: collection.with_tenant(tenant_id)] ODER [BRIDGE/SILO: Tenant-Register → dedizierte Knowledge Base / dedizierter Index] → Retriever → ausschließlich autorisierte Chunks → Prompt Builder → Modell → Antwort → tenantbezogener Cache und Audit Log.
Der unveränderliche Tenant-Kontext ist der Kontrollpunkt. Er entsteht aus einem verifizierten Token-Claim oder einer serverseitigen Zuordnung von Identität zu Tenant; tenant_id aus dem Request Body darf nie maßgeblich sein. Entfernen Sie öffentliche Retrieval-Methoden ohne diesen Kontext. Der Retriever sollte eine typisierte Operation wie retrieve(TenantContext, Query) anbieten – keinen allgemeinen Vector Client, den nachgelagerter Code ohne Grenze aufrufen kann.
An jeder Übergabe geschlossen ausfallen
Der Anfragepfad muss fehlenden, mehrdeutigen, abgelaufenen oder widersprüchlichen Tenant-Kontext vor dem Retrieval ablehnen. Eine Autorisierungsverweigerung darf keine Abfrage auslösen. Insbesondere darf sie nicht in ein leeres Filterobjekt übersetzt werden, das beim Anbieter möglicherweise „alles finden“ bedeutet. Bei Timeout von Policy Service, Tenant-Register oder Filter Builder geben Sie einen Autorisierungsfehler zurück. Retries müssen denselben verifizierten Tenant-Kontext erhalten.
Die aktuelle AWS-Architektur mit Verified Permissions trennt ausdrücklich logische Metadatenfilter-Isolation von Infrastruktur-Isolation. Sie warnt, dass eine ausfalloffene Middleware Dokumente anderer Gruppen offenlegen kann, positioniert das Beispiel für feingranularen Zugriff innerhalb eines Tenants und empfiehlt bei harter tenantübergreifender Grenze eine dedizierte Knowledge Base mit IAM-erzwungenen Ressourcengrenzen. Quelle: AWS Secure RAG mit Verified Permissions.
Entscheidungstabelle: Silo, Pool, Bridge oder nativer Shard
Anforderung | Pool mit Metadatenfilter | Nativer Tenant-Shard | Bridge | Silo Durchsetzung | Anwendung/Policy erzeugt verpflichtendes Prädikat | Datenbank verlangt Tenant-Selektor und separaten Shard | Router ordnet gemeinsame oder dedizierte Ressource zu | IAM-/Ressourcengrenze und dedizierter Stack Geeignet für | Viele ähnliche Tenants mit geringerer Assurance und Kostendruck | Viele Tenants bei validierter nativer Datenbankisolation | Gemischte Schutz- oder Lastklassen | Hohe Assurance, Sonderkonfiguration, enger Blast Radius Hauptvorteil | Niedrigste Infrastrukturkosten, einfaches Onboarding | Stärkere Datenbankgrenze ohne Collection je Tenant | Kosten folgen der Tenant-Klasse | Höchste architektonische Unabhängigkeit und Performance-Isolation Hauptfehler | Fehlender, fehlerhafter oder umgangener Filter liefert fremde Chunks | Falscher Tenant, Tippfehler-Tenant, Cache-Leak | Veraltetes Register routet auf falschen Index | IaC-Drift, Quotenwachstum, teurer Flottenbetrieb Betriebsaufwand | Metadatenintegrität, Filtertests, tenantbezogene Telemetrie | Tenant-Lifecycle, Shard-Status, Backups, Kapazität | Pool- und Silo-Runbooks plus Routingregister | Provisionierung, Upgrade, Monitoring, Löschung und Quoten je Tenant Wählen, wenn | Dokumentierte Risikoentscheidung akzeptiert logische Isolation | Vertragslage erlaubt gemeinsamen Cluster | Anforderungen unterscheiden sich materiell | Fehlerfolge rechtfertigt dedizierte Kosten
Der AWS-Vergleich nennt weitere Trade-offs: Im Pool fehlt Performance-Isolation auf Ebene des Vektorspeichers; das Silo ist am teuersten und beim Onboarding am aufwendigsten. Bridge erlaubt tenantbezogene Konfiguration ohne vollständig unabhängige Infrastruktur. Übernehmen Sie diese Eigenschaften in ein Kosten- und Risikomodell und prüfen Sie aktuelle Quoten und Topologie Ihres Anbieters.
Compliance-Tiering ist Engineering-Input, kein Rechtsurteil
Definieren Sie eine interne Isolationspolicy. Beispiel: Tier A verlangt dedizierte Ressourcen, kundeneigene Schlüssel soweit verfügbar, unabhängige Löschungsnachweise und tenantbezogene Incident-Eindämmung. Tier B erlaubt einen nativen Datenbank-Shard im gemeinsamen Cluster, wenn Penetrationstests, Backup-Verhalten und Vertragsbedingungen akzeptiert sind. Tier C erlaubt einen gemeinsamen Index mit policyabgeleitetem Metadatenfilter, synthetischen Cross-Tenant-Tests und begrenzter Datensensitivität. Diese Stufen sind technische Kategorien, keine Rechtskategorien.
Ob Vertrag, Branchenregel, Datenschutzprüfung oder Aufsichtserwartung physische Trennung verlangt, müssen Rechtsberatung, Security und verantwortlicher Fachbereich beurteilen. Engineering liefert Datenfluss, Threat Model, Providerkontrollen, Restrisiken, Löschverhalten, Testnachweise und Kostenoptionen. Ohne diese Prüfung sollte Engineering weder „separater Shard“ noch „separater Index“ als rechtlich ausreichend bezeichnen.
Die Ingestion muss dieselbe Grenze erzwingen
Query-Isolation scheitert bei falschen Ingestion-Labels. Binden Sie jeden Source Connector serverseitig an einen Tenant. Schreiben Sie tenant_id als unveränderliche Provenienz, lehnen Sie tenantübergreifende Objektverschiebungen ab und protokollieren Sie Tenant, Quellobjekt-ID, Content-Digest, Parser-Version, Embedding-Modell und Indexziel im Manifest. Im Pool ist fehlende Tenant-Metadaten ein Quarantänegrund. Bei Silo oder Bridge prüfen Sie, dass die Zielressource dem Connector-Tenant gehört.
Das AWS-Pool-Beispiel nutzt eine Metadaten-Sidecar-Datei mit tenantId und einen equals-Filter in Retrieve beziehungsweise RetrieveAndGenerate. Es weist darauf hin, dass ein Dokument ohne Sidecar über Metadatenfilter nicht auffindbar ist. In der Produktion sollte daraus eine harte Ingestion-Regel werden: Kein Dokument ohne validierte Tenant-Metadaten gelangt in den durchsuchbaren Bestand. Stimmen Sie Aufbewahrung und Löschung mit der RAG-Daten-Governance für Unternehmenswissensbasen ab.
Tenantbezogene Caches, Sessions und Traces
Der Vektorabruf ist nicht der einzige Leak-Pfad. Präfixieren Sie Schlüssel von Semantic Cache, Response Cache und Embedding Cache mit Tenant-ID, Autorisierungs-Policy-Revision und Dokumentumfang. Binden Sie Konversationssessions bei Erstellung an Identität und Tenant und validieren Sie dies bei jedem Turn. Eine Session-ID darf nicht zum tenantübergreifenden Bearer Credential werden. Partitionieren Sie Traces tenantbezogen oder erzwingen Sie gleichwertige Zeilenrechte; speichern Sie Chunk-Inhalte nur, wenn sie betrieblich erforderlich sind.
Die AWS-Referenz empfiehlt kryptografisch zufällige Session-IDs, die an Identität und Gruppe gebunden, bei Folgeanfragen erneut validiert und nach Berechtigungsänderungen ungültig gemacht werden. Übertragen Sie dieses Prinzip auf Kundentenants. Audit-Evidenz sollte Subjekt, Tenant, Entscheidung, Policy-Revision, Ressourcenroute, Filter-Digest, abgerufene Dokument-IDs und Ablehnungsgrund enthalten – nicht unnötig den Dokumentinhalt.
Sechs Fehlerbilder vor dem Produktionsstart testen
1. Filterauslassung: Ein neuer Pfad ruft den Vector Client direkt ohne tenant_id auf. Verhindern Sie dies strukturell und injizieren Sie den Defekt im Test. 2. Fail-open: Policy-Timeout oder fehlerhafte Claims werden zum leeren Filter. Jeder unbestimmte Zustand muss verweigern. 3. Falsches Ingestion-Label: Ein Connector schreibt Inhalt von Tenant B mit Metadaten von Tenant A. Gleichen Sie Quelle und Manifest vor Indexierung ab. 4. Cache-Kollision: Gleiche Fragen teilen einen Schlüssel über Tenants. Tenant und Policy-Revision gehören in jeden Key. 5. Bridge-Routing-Drift: Ein Tenant wechselt vom Pool ins Silo, Worker nutzen aber alte Zuordnungen. Versionieren Sie das Register und blockieren Sie mehrdeutige Writes. 6. Löschlücke: Entfernte Quelldateien beweisen keine Löschung aus Vektoren, Caches, Backups und Traces. Führen Sie ein Löschledger mit Abschlussnachweis.
Negative Tests sind die primären Abnahmetests
Erstellen Sie mindestens drei synthetische Tenants mit eindeutigen Canary-Phrasen und semantisch ähnlichen Themen. Prüfen Sie für jede API, jeden Tool-Pfad und jeden asynchronen Worker: Tenant A erhält nur A-Canaries, keine B/C-Dokument-IDs und keine B/C-Kennungen in Traces oder Cache. Testen Sie fehlenden Tenant, manipuliertes Token, widersprüchliche URL-/Body-Angabe, Policy-Ausfall, Retry, Pagination, hybride Keyword-/Vektorsuche, Reranking, Streaming, Session-Fortsetzung und Batch-Ingestion.
Ergänzen Sie Property-based Tests für Tenant-/Filterkombinationen, statische Regeln gegen direkte Vector-Client-Imports außerhalb der Retrieval-Grenze und einen Integrationstest gegen die reale Datenbank. Überwachen Sie im Canary Deployment verweigerte Retrievals, Zero-Result-Rate, Dokumente ohne Tenant-Metadaten, Cross-Tenant-Canary-Treffer, Routingregister-Abweichung und Cache-Key-Kardinalität. Dokumentieren Sie dies im RAG-Sicherheits-Betriebsmodell mit Retrieval-Nachweis.
Implementierungscheckliste
Architektur: Tenant-Stufen klassifizieren; Durchsetzungsebene dokumentieren; Stores, Caches, Sessions, Traces und Backups abbilden; Deny-Verhalten definieren. Identität: Tenant aus verifizierten Claims oder Servermapping ableiten; Request Body nicht autoritativ verwenden; Servicejobs an serverseitigen Kontext binden. Ingestion: Quelleigentum prüfen; unveränderliche Provenienz fordern; fehlende Metadaten quarantänisieren; Zielressource abgleichen. Retrieval: ausschließlich Tenant-pflichtige Schnittstelle anbieten; Grenze vor der Suche anwenden; bei Policy-/Registerfehler verweigern; Filter- und Route-Digest protokollieren. Tests: Canary-Dokumente säen; Cross-Tenant-Negativtests auf jedem Pfad; Migration und Löschung testen; Bypass-Imports suchen. Betrieb: Noisy Neighbours und Shard-Kapazität überwachen; Routing versionieren; Pool-zu-Silo-Migration proben; Löschungsnachweise halten. Governance: Security, Einkauf und Rechtsberatung für regulatorische oder vertragliche Aussagen einbinden; Restrisiko und Freigabe dokumentieren.
Trade-offs und Grenzen
Silos reduzieren gemeinsamen Blast Radius und Noisy-Neighbour-Risiko, vervielfachen aber Infrastruktur, Quoten, Upgrades und Löschabläufe. Pools reduzieren Leerkapazität, doch logische Isolation hängt von vollständigen Metadaten und nicht umgehbarer Query-Konstruktion ab. Native Shards verstärken die Datenbankgrenze; falscher Tenant-Selektor, gemeinsamer Cache oder Backup-Verhalten können trotzdem Daten offenlegen. Bridge passt zu gemischten Portfolios, erzeugt aber zwei Betriebsmodelle und eine sicherheitskritische Routingebene.
Auch physische Trennung ist ein Spektrum: separater Shard, Index, Collection, Cluster, Account und Region bieten unterschiedliche Kontrollen. Produktbegriffe beweisen nicht, welche Ressourcen, Schlüssel, Speicherbereiche, Logs oder Backups geteilt werden. Prüfen Sie Implementierung und Vertrag. Performance-Isolation braucht Lasttests, Sicherheitsisolation braucht Negativtests und Löschung braucht einen End-to-End-Nachweis.
Quellen und Interpretationsgrenze
Primäre und autoritative Referenzen: AWS Multi-Tenant RAG mit Bedrock Knowledge Bases; AWS Secure Multi-Tenant RAG mit Verified Permissions; Weaviate Multi-Tenancy Operations und AWS SaaS Tenant Isolation Concepts. Anbieterarchitekturen beschreiben Optionen und Grenzen; sie zertifizieren keine konkrete Implementierung und ersetzen keine rechtliche, vertragliche oder sicherheitstechnische Prüfung.
Machen Sie die Tenant-Grenze ausführbar
Wenn Ihre RAG-Plattform von einer internen Wissensbasis zu einem mandantenfähigen Kundendienst wird, unterstütze ich Sie dabei, die Isolationsentscheidung in ein ausführbares Design zu übersetzen: Tenant-Stufen, Identitätsbindung, Retrieval-Schnittstelle, Pool-/Silo-Routing, Negativtests, Migrations-Runbook und Audit-Evidenz. Das belastbare Ergebnis ist kein Diagramm mit dem Etikett „sicher“. Es ist eine Grenze, die ein gewöhnlicher Codepfad nicht auslassen kann, plus eine Testsuite, die beweist, dass fremde Chunks draußen bleiben.
