RBAC vs. Mandantenisolierung: Zwei unterschiedliche Sicherheitsgrenzen

RBAC und Mandantentrennung lösen zwei unterschiedliche Sicherheitsprobleme in Multi-Tenant-Systemen. Role-Based Access Control (RBAC) bestimmt, was ein authentifizierter Principal tun darf, z. B. Bestellungen lesen, Produkte bearbeiten oder Benutzer verwalten. Mandantentrennung bestimmt, auf die Daten, Ressourcen und den Ausführungskontext welches Mandanten dieser Principal zugreifen darf. Ein Benutzer kann korrekt authentifiziert und korrekt einer RBAC-Rolle zugewiesen sein und dennoch einen Sicherheitsfehler erleben, wenn die Anwendung dieser Rolle erlaubt, auf Ressourcen eines anderen Mandanten zuzugreifen.

Was RBAC wirklich steuert

RBAC ist ein Autorisierungsmodell, bei dem Berechtigungen mit Rollen verknüpft und Benutzer diesen Rollen zugewiesen werden. Die Rolle fungiert als administrative Abstraktion zwischen Identitäten und Berechtigungen.

Die klassische RBAC-Arbeit von NIST formalisiert dies anhand von Benutzern, Rollen, Berechtigungen, Operationen und Objekten. Der praktische Nutzen besteht darin, dass eine Organisation die Autorisierung über relativ stabile Job- oder Verantwortungsrollen verwalten kann, anstatt jede Berechtigung direkt an jeden Benutzer zu knüpfen.

Eine Rolle wie EDITOR kann daher bedeuten: darf Inhalte lesen, Inhalte schreiben und Inhalte veröffentlichen. Eine Rolle wie ACCOUNTANT kann bedeuten: darf Abrechnungsdaten lesen, Rechnungen abstimmen und Abrechnungen genehmigen.

Was Mandantentrennung wirklich steuert

Mandantentrennung ist die Gesamtheit der Mechanismen, die verhindern, dass ein Mandant die Ressourcen eines anderen Mandanten in einem gemeinsam genutzten System liest, verändert, beeinflusst oder versehentlich erhält.

Die geschützte Grenze ist breiter als Datenbankzeilen. Mandantenspezifischer Zustand kann in relationalen Tabellen, Objektspeichern, Vektorindizes, Caches, Suchindizes, Warteschlangennachrichten, Dateien, temporären Artefakten, Hintergrundjobs, Analysen, Ratenbegrenzungen und Infrastrukturressourcen existieren.

Die SaaS-Richtlinie von AWS macht die Unterscheidung explizit: Autorisierung gewährt Zugriff auf Ressourcen, während Mandantentrennung sicherstellt, dass diese Ressourcen die falsche Mandantengrenze nicht überschreiten können, selbst wenn die Infrastruktur gemeinsam genutzt wird.

Das einfachste Beispiel

Angenommen, Alice ist Administratorin für Mandant A und Bob ist Administrator für Mandant B. Beide Benutzer haben legitimerweise dieselbe ADMIN-Rolle.

RBAC kann korrekt zu dem Schluss kommen, dass beide Benutzer eine Operation wie users.read ausführen dürfen. Wenn Alice jedoch Benutzer-ID 847 anfordert, muss die Anwendung dennoch überprüfen, ob Benutzer 847 zu Mandant A gehört.

Wenn die API nur prüft „Alice hat ADMIN“ und dann SELECT * FROM users WHERE id = 847 ausführt, war RBAC erfolgreich, während die Mandantentrennung fehlgeschlagen ist.

Wo das einfache Beispiel an seine Grenzen stößt

Reale Systeme enthalten oft mehrere Identitätsklassen: Mandantenbenutzer, Plattformadministratoren, Hintergrundprozesse, Integrationen, Agenten und mandantenübergreifende Betriebsdienste. Einige davon überschreiten legitim Mandantengrenzen.

Das beseitigt nicht die Notwendigkeit der Isolation. Es bedeutet, dass mandantenübergreifende Berechtigungen explizit, eng begrenzt und separat prüfbar sein müssen, anstatt versehentlich aus einer globalen Rolle oder einer nicht eingegrenzten Datenbankverbindung zu entstehen.

Die Mandantenisolation kann auch je nach Ebene variieren. Ein Produkt kann Anwendungsserver gemeinsam nutzen und gleichzeitig Datenbanken trennen oder eine gemeinsame Datenbank mit zeilenbasierten Richtlinien verwenden und Premium-Mandanten isolierten Speicher oder Rechenleistung bieten. Es gibt keine einzige universelle Isolations-Topologie.

RBAC vs. Mandantenisolation

Authentifizierung, Autorisierung und Isolation sind drei verschiedene Prüfungen

Diese Prüfungen sind miteinander verbunden, aber nicht gegenseitig ersetzbar. Die Authentifizierung kann perfekt sein, während die Autorisierung fehlschlägt. Die Autorisierung kann korrekt sein, während die Mandantenisolation fehlschlägt. Ein sicherer SaaS-Anfragepfad benötigt alle anwendbaren Grenzen.

Rollen brauchen einen Geltungsbereich

Das Wort ADMIN ist ohne Geltungsbereich unvollständig. Es kann Plattformadministrator, Mandantenadministrator, Projektadministrator, Arbeitsbereichsadministrator oder Administrator eines Subsystems bedeuten.

In Multi-Mandanten-Systemen sollte die Rollenzuweisung normalerweise mit der Mandantenmitgliedschaft oder einem anderen expliziten Ressourcenbereich verknüpft sein. Derselbe Benutzer kann legitim ADMIN in Mandant A und VIEWER in Mandant B sein.

Ein globales Rollenmodell, das diese Unterscheidung ignoriert, kann zu Berechtigungslecks führen, selbst wenn die Berechtigungszuordnung selbst korrekt ist.

Der Mandantenkontext muss aus einem vertrauenswürdigen Pfad stammen

Eine vom Client bereitgestellte Mandanten-ID ist als Selektor nützlich, aber sie ist kein Nachweis der Berechtigung. Der Server muss die Mandantenmitgliedschaft anhand der authentifizierten Identität und der aktuellen Autorisierungsdaten ableiten oder überprüfen.

Die aktuelle Multi-Mandanten-Richtlinie von OWASP empfiehlt, den Mandantenkontext früh im Anfragelebenszyklus festzulegen, und warnt ausdrücklich davor, Client-Header oder Anfrageparameter als Autorisierungsnachweis zu behandeln.

Das ist wichtig, weil eine triviale Änderung der Anfrage von tenant=A zu tenant=B nicht ausreichen darf, um die Isolationsgrenze zu überschreiten.

Der Mandantenbereich gehört in die Ressourcensuche

Ein gängiges Isolationsmuster auf Anwendungsebene besteht darin, den Mandantenbereich in dieselbe Abfrage aufzunehmen, die die Ressource auflöst.

Dieses Muster ist nicht der einzige mögliche Isolationsmechanismus, aber es hält die Mandantenzugehörigkeit nahe an der Datenzugriffsoperation und verhindert, dass eine Objekt-ID zu einer mandantenübergreifenden Fähigkeit wird.

Anwendungsprüfungen sind nützlich, aber die Isolation sollte nicht von perfektem Entwicklerverhalten abhängen

Die Isolationsrichtlinie von AWS warnt ausdrücklich davor, die Durchsetzung der Isolation nur den Serviceentwicklern zu überlassen. In einer großen Codebasis kann irgendwann eine Abfrage, ein Cache-Schlüssel oder ein Worker-Pfad den Mandantenbereich auslassen.

Verteidigung in der Tiefe kann die Isolation daher in gemeinsame Middleware, Repository-/Service-Schichten, Policy-Engines, Datenbank-Row-Level-Security, dedizierte Anmeldeinformationen, separate Schemas oder separate Datenbanken verlagern, je nach Risiko und Architektur.

Datenbank-Isolationsstrategien

Das aktuelle Multi-Tenant Security Cheat Sheet von OWASP listet separate Datenbanken, separate Schemas, gemeinsame Tabellen mit Zeilensteuerung und Hybridmodelle auf. Das richtige Modell hängt von Bedrohungsniveau, Compliance, Leistung und Betriebskosten ab.

PostgreSQL Row-Level Security kann Verteidigung in der Tiefe bieten

Bei gemeinsamen Tabellen kann PostgreSQL Row-Level Security ein Mandantenprädikat auf der Datenbankebene durchsetzen, sodass gewöhnliche Abfragen keine Zeilen außerhalb der aktiven Mandantenrichtlinie sehen können.

RLS ist jedoch keine Magie. PostgreSQL-Superuser und Rollen mit BYPASSRLS können Zeilenrichtlinien umgehen. OWASP empfiehlt daher, eine Rolle mit minimalen Berechtigungen für den Anforderungspfad zu verwenden und denselben Verbindungs-/Pooling-Modus zu testen, der in der Produktion verwendet wird.

Die Wiederverwendung von Verbindungen ist ein weiterer wichtiger Randfall: Der Mandantenkontext muss für jede Transaktion/Anforderung sicher gesetzt und zurückgesetzt werden, damit eine gepoolte Verbindung keinen vorherigen Mandantenzustand preisgeben kann.

Mandantenisolierung muss Caches einschließen

Eine Datenbankabfrage kann perfekt abgegrenzt sein und dennoch Daten über einen gemeinsamen Cache-Schlüssel preisgeben.

Wenn user:42 sowohl in Mandant A als auch in Mandant B existiert, kann ein globaler Cache-Schlüssel den Wert des falschen Mandanten zurückgeben. Mandantensensible Cache-Schlüssel sollten jedes Attribut enthalten, das die Sichtbarkeit oder Ergebnis-Semantik ändert, üblicherweise Mandant, Benutzer, Locale, Feature-Set oder Berechtigungsversion.

Cache-Partitionierung ist Verteidigung in der Tiefe, kein Ersatz für Autorisierung. Die Anforderung muss weiterhin autorisiert werden, bevor geschützte zwischengespeicherte Inhalte zurückgegeben werden.

Dateien und Objektspeicher benötigen ihre eigene Mandantengrenze

Objektspeicher sollte globale, mandantenbezogene und benutzerbezogene Objekte unterscheiden. Ein Ordnerpräfix allein ist nur eine Namenskonvention, es sei denn, die Zugriffsrichtlinie schränkt Lese- und Schreibvorgänge tatsächlich ein.

Robustere Designs können mandantenbewusste Objektschlüssel, Bucket-Richtlinien, separate Buckets/Konten oder mandantenspezifische Verschlüsselungsschlüssel verwenden, wenn Risiko oder Compliance eine stärkere Isolierung erfordern.

Signierte URLs müssen vor der Ausstellung autorisiert und auf das genaue Objekt und die genaue Operation beschränkt werden. Der Besitz einer Objektkennung sollte für sich genommen keinen mandantenübergreifenden Zugriff gewähren.

Hintergrundjobs und Warteschlangen können die Isolierung durchbrechen

Asynchrone Jobs verlassen oft den ursprünglichen HTTP-Anfragekontext, was die Weitergabe des Mandanten leicht fehleranfällig macht. Eine Warteschlangennachricht, die tenantId enthält, ist kein ausreichender Beweis dafür, dass der Produzent autorisiert war.

Der Worker sollte eine verifizierte Dienst-/Benutzeridentität oder einen vertrauenswürdigen Job-Umschlag mitführen, den Mandantenkontext wiederherstellen und folgenreiche Operationen an der Konsumentengrenze erneut autorisieren.

Mandantenisolierung umfasst auch Verfügbarkeit. Ein Mandant sollte nicht in der Lage sein, gemeinsame Worker, Warteschlangen, Verbindungspools oder Rechenleistung so zu monopolisieren, dass andere Mandanten wesentlich beeinträchtigt werden.

Suche und RAG benötigen mandantenbewussten Abruf

Multi-Mandanten-KI führt eine weitere Kopie des Isolierungsproblems ein. Dokumente können nach der Aufnahme in Chunks aufgeteilt, eingebettet und in einem Vektorindex gespeichert werden.

Die aktuelle RAG-Sicherheitsrichtlinie von OWASP besagt, dass Zugriffskontrolle zum Zeitpunkt des Abrufs durchgesetzt werden muss und dass Chunks von Mandant A nicht durch Abfragen von Mandant B abgerufen werden dürfen. Es kann nicht einfach davon ausgegangen werden, dass Berechtigungen auf Dokumentebene das Chunking automatisch überleben.

Der Vektorindex benötigt daher Mandanten-/Zugriffsmetadaten oder physisch/logisch getrennte Sammlungen gemäß dem Isolierungsdesign. Abruffilter sollten angewendet werden, bevor nicht autorisierte Inhalte in den Modellkontext gelangen können.

Abgeleitete Daten erben die Mandantensensibilität

Einbettungen, Suchindizes, Miniaturansichten, generierte Zusammenfassungen, Caches, Analysezeilen und KI-Antworten werden aus Quelldaten abgeleitet. Ihr Mandantenbereich sollte der Quelle folgen, es sei denn, eine explizite Transformation erzeugt ein legitimes gemeinsames/globales Artefakt.

Löschung und Offboarding müssen sich daher über die kanonische Zeile hinaus ausbreiten. Das Entfernen eines Mandantendokuments, während durchsuchbare Chunks oder zwischengespeicherte Zusammenfassungen verbleiben, kann eine mandantenübergreifende oder über die Aufbewahrungsfrist hinausgehende Exposition aufrechterhalten.

Nicht alles gehört zu einem Mandanten

Multi-Mandanten-Plattformen haben oft absichtlich globale Ressourcen: Produkttaxonomien, öffentliche Vorlagen, Systemberechtigungen, Funktionsdefinitionen oder öffentliche Inhalte.

Das sicherste Modell ist die explizite Klassifizierung: global, mandantenbezogen, benutzerbezogen oder explizit mandantenübergreifend. Mehrdeutige Ressourcen sind der Ausgangspunkt für versehentliche Datenlecks.

Ein absichtlich gemeinsam genutztes Objekt sollte einen dokumentierten Grund dafür haben, global zu sein, und nicht einfach keine Mandantenzuordnung besitzen.

Plattformadministratoren erfordern ein anderes Berechtigungsmodell

Ein Plattformbetreiber muss möglicherweise mehrere Mandanten für Support, Compliance oder Infrastrukturbetrieb inspizieren. Dies als gewöhnlichen Mandanten-ADMIN mit versehentlichem globalem Datenbankzugriff zu modellieren, schwächt sowohl Sicherheit als auch Auditierbarkeit.

Ein besseres Design verwendet eine eigenständige Plattformidentität oder eine explizite mandantenübergreifende Berechtigung, stärkere Authentifizierung, Zweckbindung, detaillierte Auditierung und, wo angemessen, Genehmigungs- oder Break-Glass-Kontrollen.

Mandantenübergreifender Zugriff sollte daher eine benannte Fähigkeit sein, nicht das Fehlen eines Mandantenfilters.

RBAC kann mit Attributen kombiniert werden

Einige Entscheidungen hängen von mehr als der Rolle ab. Mandantenzugehörigkeit, Region, Ressourceneigentümer, Abonnementstufe, Zeit, Projektzugehörigkeit oder Datenklassifizierung können alle den Zugriff beeinflussen.

RBAC und ABAC schließen sich nicht gegenseitig aus. Die aktuelle Multi-Tenant-Autorisierungsrichtlinie von AWS behandelt RBAC, ABAC und Hybridmodelle. Eine Rolle kann eine breite Verantwortung definieren, während Attribute einschränken, auf welche konkrete Ressourceninstanz zugegriffen werden kann.

Die zentrale Architekturregel bleibt: Kodieren Sie die Mandantenisolierung nicht nur als beiläufigen Rollennamen, wenn die Mandantenidentität eine erstklassige Ressourcengrenze ist.

Autorisierungsentscheidungen sind mindestens zweidimensional

Ursprüngliche Implementierungsnachweise: Aaasaasa AI CMS

Der RBAC-Dienst definiert typisierte Berechtigungscodes wie cms.content.read, shop.orders.write, billing.reconcile und users.roles. Systemrollen ordnen diese Berechtigungen benannten Verantwortungssätzen zu.

Rollendatensätze werden mit einer tenantId erstellt und aufgelöst. Systemrollen werden mithilfe einer zusammengesetzten Mandanten-/Code-Identität aktualisiert oder eingefügt, und die Rollenauflistung wird nach Mandant gefiltert.

Bei der Rollenaktualisierung und -löschung wird die Rolle zuerst anhand von Rollen-ID und Mandanten-ID aufgelöst. Benutzer-Rollen-Zuweisungen werden ebenfalls im aktuellen Mandantenkontext gespeichert und ersetzt.

Die Berechtigungsauflösung liest explizite Benutzer-Rollen-Zuweisungen, die sowohl nach tenantId als auch nach userId eingeschränkt sind. Dies verhindert, dass die Rollenzuweisung eines Mandanten automatisch zur Rollenzuweisung eines anderen Mandanten wird.

Auf API-Ebene lösen administrative RBAC-Routen einen Mandantenkontext auf, bevor Rollen erstellt oder geändert werden. Dies ist die richtige Richtung: Die Berechtigungsverwaltung selbst muss die Mandantenfähigkeit respektieren.

Warum diese Unterscheidung für KI-Agenten noch wichtiger ist

KI-Agenten können einen Berechtigungsfehler in eine Abfolge von Aktionen verwandeln. Wenn ein Agent ein breites orders.read-Tool ohne mandantenbezogene Durchsetzung erhält, kann ein Fehler beim Schlussfolgern oder eine Prompt-Injection zu mandantenübergreifenden Lesezugriffen mit Maschinengeschwindigkeit führen.

Agenten-Tool-Beschreibungen können Mandantenbeschränkungen erwähnen, aber die Durchsetzung muss weiterhin in der vertrauenswürdigen Laufzeit-/Service-/Datenschicht erfolgen. Natürlichsprachliche Anweisungen sind keine Autorisierungsgrenze.

Dasselbe gilt für RAG: Ein Agent kann die Berechtigung haben, das Suchtool zu verwenden, während das Such-Backend weiterhin verhindern muss, dass die Abfrage von Mandant A Chunks von Mandant B zurückgibt.

RBAC und Mandantentrennung getrennt testen

Die Autorisierungs-Regressionsrichtlinie von OWASP hebt speziell mandantenübergreifende Grenztests hervor, weil Codeänderungen an Caching, Abfragen oder gemeinsamen Diensten die Isolation stillschweigend brechen können, selbst wenn Rollentests weiterhin bestehen.

Häufige Fehlermodi

Häufige Missverständnisse

Eine praktische Entwurfssequenz

RBAC + Mandantentrennungs-Checkliste

Edge Cases und Einschränkungen

Ein Benutzer kann mehreren Mandanten angehören. Der aktuelle Mandant sollte daher ein expliziter Ausführungskontext sein und nicht dauerhaft aus dem Benutzerkonto abgeleitet werden.

Einige Ressourcen werden absichtlich zwischen ausgewählten Mandanten geteilt, wie z. B. Kollaborationsräume oder Konsortialdaten. Dies erfordert ein explizites Freigabemodell; vorzugeben, die Ressource gehöre zu einem Mandanten, und später Ausnahmen hinzuzufügen, führt in der Regel zu mehrdeutiger Autorisierung.

Noisy-Neighbor-Isolation ist verwandt, aber anders als Vertraulichkeitsisolation. Ein Mandant darf niemals die Daten eines anderen Mandanten sehen und kann dennoch gemeinsame CPU, Warteschlangenkapazität oder Datenbankverbindungen erschöpfen. Rate Limits und Ressourcenkontingente können daher als Verfügbarkeitsgrenze mandantenbewusst sein.

Physische Isolation ist nicht automatisch sicher, wenn Control-Plane-Anmeldeinformationen oder administrative Pfade Grenzen überschreiten können. Logische Isolation ist nicht automatisch schwach, wenn Richtlinien zentral durchgesetzt, mit minimalen Rechten versehen und gründlich getestet werden.

Die Anforderungen an die Mandantenisolation können je nach Datenklasse unterschiedlich sein. Öffentliche Katalogdaten, Abrechnungsdatensätze und private KI-Dokumente können unterschiedliche Speicher- und Verschlüsselungsgrenzen innerhalb desselben SaaS-Produkts rechtfertigen.

Was würde diese Antwort ändern?

Die genaue Implementierung ändert sich mit der Architektur: Serverless-APIs, Kubernetes, PostgreSQL, Objektspeicher, Vektordatenbanken und Policy Engines bieten unterschiedliche Isolationsprimitive.

Die erforderliche Stärke ändert sich auch mit Regulierung, Kundenverträgen, Datensensibilität, Bedrohungsmodell und operativer Skalierung. Einige Mandanten können isolierte Datenbanken oder Infrastruktur rechtfertigen, während andere gemeinsam genutzte Ressourcen teilen.

Die konzeptionelle Unterscheidung ändert sich nicht: Die Berechtigung zur Durchführung einer Operation ist nicht dasselbe wie die Berechtigung, eine Mandantengrenze zu überschreiten.

Verwandtes kanonisches Wissen

S01 ist eine Voraussetzung für Sicherheitsgrenzen in Enterprise AI Architecture und AI Governance. Sobald KI-Tools, RAG oder Agenten über mandantenfähige Daten arbeiten, muss die Mandantenidentität durch Retrieval, Tool-Ausführung, Speicher, Caches und Audit-Traces wandern.

Es verbindet sich auch direkt mit Agentic AI: Tool-Fähigkeiten und Rollenberechtigungen müssen weiterhin durch den Mandantenbesitz eingeschränkt werden, bevor ein Agent Geschäftsressourcen lesen oder verändern kann.

Für RAG muss die Mandantenisolation durchgesetzt werden, bevor geschützte Chunks den Modellkontext erreichen.

Häufig gestellte Fragen

Glossar

Fazit

RBAC und Mandantenisolierung sind komplementäre, nicht konkurrierende Sicherheitsmechanismen. RBAC strukturiert operative Berechtigungen; Mandantenisolierung beschränkt die Ressourcengrenze, innerhalb derer diese Berechtigung gelten kann.

Eine robuste mandantenfähige Anfrage benötigt daher mehr als „Benutzer hat Rolle ADMIN“. Sie benötigt einen verifizierten Prinzipal, einen verifizierten Mandantenkontext, eine erlaubte Operation, ein mandantenbezogenes Ziel und Durchsetzung auf jeder Ressourcenschicht, die mandanteneigene Daten tragen kann.

Die kürzeste zuverlässige Regel lautet: Autorisieren Sie die Aktion, dann isolieren Sie den Bereich — und nehmen Sie niemals an, dass eines das andere beweist.

Primärquellen und aktuelle Leitlinien

Die folgenden Quellen stützen die RBAC-Definition und die aktuellen Leitlinien zur Mandantenisolierung. Der Abschnitt zum Aaasaasa AI CMS ist ursprüngliche Implementierungsnachweis und ist absichtlich auf die verifizierten Codemuster beschränkt.