Erfahre, wie Mehrmandanten-Datenbanken Sicherheit und Performance beeinflussen, welche Risiken (Isolation, Noisy Neighbors) bestehen und welche praktischen Maßnahmen Mandanten sicher und performant halten.
Eine Mehrmandanten-Datenbank ist eine Architektur, bei der viele Kunden (Mandanten) dasselbe Datenbanksystem teilen — denselben Datenbankserver, denselben zugrundeliegenden Speicher und oft dasselbe Schema — während die Anwendung dafür sorgt, dass jeder Mandant nur seine eigenen Daten sehen kann.
Stell es dir wie ein Wohnhaus vor: alle teilen die Struktur und Versorgungsleitungen, aber jeder Mandant hat seine eigene verschlossene Einheit.
In einem Single-Tenant-Ansatz bekommt jeder Kunde dedizierte Datenbankressourcen — zum Beispiel eine eigene Datenbankinstanz oder einen eigenen Server. Die Isolation ist einfacher nachzuvollziehen, aber meist teurer und betrieblich aufwendiger, wenn die Kundenzahl wächst.
Bei Mehrmandantigkeit teilen sich Mandanten die Infrastruktur, was effizient sein kann — es bedeutet aber auch, dass dein Design Grenzen bewusst durchsetzen muss.
SaaS-Firmen entscheiden sich aus praktischen Gründen oft für Mehrmandanten:
Mehrmandantigkeit ist nicht automatisch „sicher“ oder „schnell“. Das Ergebnis hängt von Entscheidungen ab, z. B. wie Mandanten getrennt werden (Schema, Zeilen, oder Datenbanken), wie Zugriffskontrolle durchgesetzt wird, wie Verschlüsselungsschlüssel gehandhabt werden und wie verhindert wird, dass die Last eines Mandanten andere verlangsamt.
Der Rest dieses Leitfadens konzentriert sich auf diese Design-Entscheidungen — denn in Mehrmandantensystemen sind Sicherheit und Performance Funktionen, die du baust, keine Annahmen, die du übernimmst.
Mehrmandantigkeit ist keine einzelne Designwahl — es ist ein Spektrum, wie eng du Infrastruktur teilst. Das gewählte Modell definiert deine Isolationsgrenze (was niemals geteilt werden darf) und beeinflusst direkt Datenbanksicherheit, Performance-Isolation und den täglichen Betrieb.
Jeder Mandant bekommt seine eigene Datenbank (oft auf demselben Server oder Cluster).
Isolationsgrenze: die Datenbank selbst. Das ist in der Regel die sauberste Isolation, weil cross-mandant Zugriff normalerweise das Überschreiten der Datenbankgrenze erfordert.
Operative Trade-offs: aufwändiger im Betrieb bei großer Anzahl von Mandanten. Upgrades und Schema-Migrationen müssen vielleicht tausendfach ausgeführt werden, und Connection-Pooling kann komplizierter werden. Backups/Restores sind pro Mandant einfach, aber Speicher- und Verwaltungsaufwand kann schnell wachsen.
Sicherheit & Tuning: im Allgemeinen am leichtesten pro Kunde zu sichern und zu optimieren; gut geeignet, wenn Mandanten unterschiedliche Compliance-Anforderungen haben.
Mandanten teilen eine Datenbank, aber jeder Mandant hat sein eigenes Schema.
Isolationsgrenze: das Schema. Es ist eine sinnvolle Trennung, hängt aber von korrekten Rechten und Tooling ab.
Operative Trade-offs: Upgrades und Migrationen sind weiterhin repetitiv, aber weniger aufwendig als bei Datenbank-pro-Mandant. Backups sind kniffliger: viele Tools behandeln die Datenbank als Backup-Einheit, sodass mandantenspezifische Operationen Schema-Exporte erfordern können.
Sicherheit & Tuning: leichter zu isolieren als geteilte Tabellen, aber diszipliniert mit Rechten und Query-Paths umgehen.
Alle Mandanten teilen eine Datenbank und ein Schema, aber jeder Mandant hat eigene Tabellen (z. B. orders_tenant123).
Isolationsgrenze: die Tabellensammlung. Kurzfristig praktikabel, aber schlecht skalierbar: Metadaten-Aufblähung, unhandliche Migrationsskripte und schlechtere Queryplanung können auftreten.
Sicherheit & Tuning: Berechtigungen können präzise sein, doch die operative Komplexität ist hoch und Fehler beim Hinzufügen neuer Tabellen oder Features passieren leicht.
Alle Mandanten teilen dieselben Tabellen, unterschieden durch eine tenant_id-Spalte.
Isolationsgrenze: deine Query- und Zugriffskontrollschicht (häufig Row-Level Security). Dieses Modell ist operativ effizient — ein Schema zu migrieren, eine Indexstrategie zu verwalten — es ist aber am anspruchsvollsten für Datenbanksicherheit und Performance-Isolation.
Sicherheit & Tuning: am schwersten korrekt umzusetzen, weil jede Abfrage mandantenbewusst sein muss. Das Noisy-Neighbor-Problem ist wahrscheinlicher, es sei denn, du ergänzt Resource-Throttling und sorgfältiges Index-Design.
Eine nützliche Regel: je mehr du teilst, desto einfacher werden Upgrades — aber desto mehr Strenge brauchst du bei Mandanten-Isolation und Performance-Schutzmaßnahmen.
Mehrmandantigkeit heißt nicht nur „mehrere Kunden in einer Datenbank“. Sie verändert dein Bedrohungsmodell: das größte Risiko verschiebt sich von Außenangriffen hin zu autorisierter Nutzung, die versehentlich (oder absichtlich) Daten eines anderen Mandanten sichtbar macht.
Authentifizierung beantwortet „Wer bist du?“. Autorisierung beantwortet „Was darfst du zugreifen?“. In einer Mehrmandanten-Datenbank muss der Mandantenkontext (tenant_id, account_id, org_id) bei der Autorisierung durchgesetzt werden — und darf nicht als optionaler Filter behandelt werden.
Ein häufiger Fehler ist das Annehmen, dass wenn ein Benutzer authentifiziert ist und „sein Mandant bekannt ist“, die Anwendung automatisch Abfragen trennt. In der Praxis muss Trennung explizit und an einer konsistenten Kontrollstelle erzwungen werden (z. B. Datenbank-Policies oder eine obligatorische Abfrage-Schicht).
Die einfachste Regel ist zugleich die wichtigste: Jeder SELECT und jede Änderung muss genau auf einen Mandanten eingeschränkt sein.
Das gilt für:
Wenn Mandanten-Scoping optional ist, wird es irgendwann übersprungen.
Cross-Mandanten-Leaks entstehen oft durch kleine, alltägliche Fehler:
tenant_id bindenTests laufen typischerweise mit kleinen Datensätzen und sauberen Annahmen. Die Produktion bringt Konkurrenz, Retries, Caches, gemischte Mandantendaten und echte Edge-Cases.
Eine Funktion kann Tests bestehen, weil in der Testdatenbank nur ein Mandant existiert oder Fixtures keine überlappenden IDs enthalten. Sicherere Designs machen es schwer, eine ungetaggte Abfrage überhaupt zu schreiben, anstatt sich darauf zu verlassen, dass Reviewer jeden Fehler finden.
Das Kernrisiko in einer Mehrmandanten-Datenbank ist simpel: eine Abfrage, die vergisst nach Mandant zu filtern, kann fremde Daten preisgeben. Starke Isolation geht davon aus, dass Fehler passieren werden, und macht diese Fehler harmlos.
Jeder mandantenbesitzte Datensatz sollte ein Mandantenkennzeichen tragen (z. B. tenant_id) und deine Zugriffsschicht sollte immer Lese- und Schreibvorgänge danach einschränken.
Ein praktisches Muster ist „Mandantenkontext zuerst“: die Anwendung ermittelt den Mandanten (aus Subdomain, Org-ID oder Token-Claims), speichert ihn im Request-Kontext, und dein Datenzugriffs-Code verweigert die Ausführung ohne diesen Kontext.
Hilfreiche Guardrails:
tenant_id in Primär-/Unique-Keys, wo angemessen (um Kollisionen zwischen Mandanten zu verhindern).\n- Füge Foreign Keys hinzu, die tenant_id enthalten, damit mandantenübergreifende Beziehungen nicht versehentlich entstehen.Wo unterstützt (insbesondere PostgreSQL), kann Row-Level Security Mandantenprüfungen in die Datenbank verlegen. Policies können SELECT/UPDATE/DELETE so einschränken, dass nur Zeilen sichtbar sind, die zum aktuellen Mandanten passen.
Das reduziert die Abhängigkeit davon, dass jeder Entwickler die WHERE-Klausel korrekt setzt, und schützt gegen bestimmte Injection- oder ORM-Fehlgebrauch-Szenarien. Betrachte RLS als zweite Sperre, nicht als alleinige Schutzmaßnahme.
Wenn Mandanten sensibler sind oder strengere Compliance-Anforderungen haben, kann die Trennung nach Schema (oder sogar nach Datenbank) die Blast-Radius reduzieren. Der Nachteil ist erhöhter Betriebsaufwand.
Gestalte Berechtigungen so, dass die Voreinstellung „kein Zugriff“ ist:
Diese Kontrollen funktionieren am besten gemeinsam: starkes Mandanten-Scoping, datenbankseitig erzwungene Policies wo möglich, und konservative Rechte, die Schaden begrenzen, wenn doch etwas schiefgeht.
Verschlüsselung ist eine der wenigen Kontrollen, die auch dann helfen, wenn andere Isolationsschichten versagen. In einem geteilten Datenspeicher geht es darum, Daten zu schützen, während sie sich bewegen, während sie ruhen, und während deine Anwendung nachweist, für welchen Mandanten sie handelt.
Für Daten in Transit erfordere TLS für jede Verbindungsstrecke: Client → API, API → Datenbank und alle internen Service-Aufrufe. Erzwinge TLS möglichst auf Datenbankebene (z. B. Ablehnung von Nicht-TLS-Verbindungen), damit „temporäre Ausnahmen“ nicht stillschweigend permanent werden.
Für Daten At-Rest nutze Datenbank- oder Storage-Verschlüsselung (managed disk encryption, TDE, verschlüsselte Backups). Das schützt vor verlorenen Medien, Snapshot-Exposure und bestimmten Infrastrukturkompromittierungen — aber es stoppt keine fehlerhafte Abfrage, die fremde Zeilen zurückliefert.
Ein einzelner geteilter Verschlüsselungsschlüssel ist einfacher zu betreiben (weniger Schlüssel zu rotieren, weniger Fehlerquellen). Der Nachteil ist der Blast-Radius: wenn dieser Schlüssel offengelegt wird, sind alle Mandanten betroffen.
Mandantenspezifische Schlüssel reduzieren den Blast-Radius und helfen bei Kundenanforderungen (einige Unternehmen wollen mandantenspezifische Schlüsselkontrolle). Der Kompromiss ist Komplexität: Lifecycle-Management, Rotationspläne und Support-Workflows (z. B. was passiert, wenn ein Mandant seinen Schlüssel deaktiviert).
Ein praktischer Mittelweg ist Envelope-Verschlüsselung: ein Master-Key verschlüsselt mandantenspezifische Datenkeys und hält Rotation handhabbar.
Speichere Datenbank-Zugangsdaten in einem Secrets-Manager, nicht in Umgebungsvariablen in Langzeitkonfigurationen. Bevorzuge kurzlebige Anmeldeinformationen oder automatische Rotation, und scope Zugriff nach Service-Rolle, sodass eine Kompromittierung eines Komponenten nicht automatisch jede Datenbank erreicht.
Behandle Mandantenidentität als sicherheitskritisch. Akzeptiere niemals eine rohe Mandanten-ID vom Client als „Wahrheit“. Binde Mandantenkontext an signierte Token und serverseitige Autorisierungsprüfungen und validiere ihn bei jeder Anfrage, bevor du Datenbankaufrufe machst.
Mehrmandantigkeit verändert, wie „normal“ aussieht. Du beobachtest nicht nur eine Datenbank — du beobachtest viele Mandanten in einem gemeinsamen System, in dem ein Fehler zu Cross-Mandanten-Exposition führen kann. Gute Auditierbarkeit und Monitoring reduzieren sowohl die Wahrscheinlichkeit als auch die Ausbreitung von Vorfällen.
Mindestens solltest du jede Aktion loggen, die Mandantendaten lesen, ändern oder Zugriffsrechte vergeben kann. Die nützlichsten Audit-Events beantworten:
Logge auch administrative Aktionen: Anlegen von Mandanten, Ändern von Isolationspolicies, Modifizieren von RLS-Regeln, Rotieren von Schlüsseln und Ändern von Verbindungs-Strings.
Monitoring sollte Muster erkennen, die in gesundem SaaS-Verhalten unwahrscheinlich sind:
tenant_ids zurückgeben, oder plötzliche Anstiege bei "tenant mismatch"-Rejections\n- Zugriff eines Service-Accounts auf Mandanten, die er normalerweise nicht berührt\n- Rasche Rollen-/Berechtigungsänderungen, neue Admins, deaktivierte Security-Policies oder RLS-Bypass-VersucheVerknüpfe Alerts mit ausführbaren Runbooks: was zu prüfen ist, wie einzudämmen ist und wen zu alarmieren.
Behandle privilegierten Zugriff wie eine Produktionsänderung. Nutze Least-Privilege-Rollen, kurzlebige Anmeldeinformationen und Genehmigungen für sensible Operationen (Schema-Änderungen, Datenexporte, Policy-Edits). Für Notfälle behalte ein Break-Glass-Konto, das streng kontrolliert wird: separate Zugangsdaten, verpflichtendes Ticket/Approval, zeitlich begrenzter Zugriff und zusätzliche Protokollierung.
Setze Retention basierend auf Compliance- und Untersuchungsbedürfnissen, scopiere aber Log-Zugriffe so, dass Support-Mitarbeitende eines Mandanten nur Logs dieses Mandanten sehen. Wenn Kunden Audit-Exporte anfordern, liefere mandantengefilterte Berichte statt roher geteilter Logs.
Mehrmandantigkeit erhöht Effizienz, weil viele Kunden dieselbe Datenbank-Infrastruktur teilen. Der Kompromiss ist, dass Performance ebenfalls eine geteilte Erfahrung wird: was ein Mandant tut, kann andere beeinflussen, selbst wenn ihre Daten sauber isoliert sind.
Ein "noisy neighbor" ist ein Mandant, dessen Aktivität so hoch (oder so spitz) ist, dass er mehr als seinen fairen Anteil gemeinsamer Ressourcen verbraucht. Die Datenbank ist nicht "kaputt" — sie ist nur damit beschäftigt, diese Last zu verarbeiten, sodass andere Mandanten länger warten.
Stell es dir vor wie den Wasserdruck in einem Wohnhaus: eine Einheit betreibt mehrere Duschen und die Waschmaschine gleichzeitig, und alle anderen merken den geringeren Druck.
Selbst wenn Mandanten separate Zeilen oder Schemata haben, sind viele performancekritische Komponenten geteilt:
Wenn diese geteilten Pools gesättigt sind, steigt die Latenz für alle.
Viele SaaS-Workloads kommen in Bursts: ein Import, Monatsberichte, eine Marketingkampagne, ein Cron-Job zur vollen Stunde.
Bursts können "Staus" in der Datenbank erzeugen:
Auch wenn der Burst nur Minuten dauert, kann es zu Nachwirkungen kommen, während die Queues sich leeren.
Aus Kundensicht wirken Noisy-Neighbor-Probleme zufällig und unfair. Typische Symptome:
Diese Symptome sind frühe Warnzeichen, dass Performance-Isolationstechniken (weiter unten) nötig sind, nicht nur "mehr Hardware".
Mehrmandantigkeit funktioniert am besten, wenn ein Kunde nicht mehr als seinen fairen Anteil an DB-Kapazität "ausleihen" kann. Ressourcenisolation sind Guardrails, die verhindern, dass ein schwerer Mandant alle anderen verlangsamt.
Ein häufiger Fehler ist unbeschränkte Verbindungen: ein Mandanten-Traffic-Spike öffnet hunderte Sessions und verdirbt der DB die Ressourcen.
Setze harte Limits an zwei Stellen:
Auch wenn die Datenbank kein direktes "Connections per tenant" erzwingen kann, kannst du es approximieren, indem du jeden Mandanten durch einen dedizierten Pool oder Pool-Partition leitest.
Rate-Limiting sorgt für Fairness über die Zeit. Setze es nah an der Peripherie (API-Gateway/App) und, wo unterstützt, in der Datenbank (Resource-Groups/Workload-Management).
Beispiele:
Schütze die Datenbank vor "ausgeuferten" Abfragen:
Diese Controls sollten sauber fehlschlagen: eine klare Fehlermeldung zurückgeben und Retry/Backoff vorschlagen.
Verlagere read-lastigen Traffic weg vom Primary:
Das Ziel ist nicht nur Geschwindigkeit — sondern auch weniger Lock-Pressure und CPU-Contention, damit Noisy-Mandanten weniger Einfluss haben.
Performance-Probleme in Mehrmandanten-Setups sehen oft aus wie "die DB ist langsam", die Ursache ist aber meist das Datenmodell: wie Mandantendaten indiziert, gefiltert, indiziert und physisch angeordnet sind. Gutes Modeling macht mandantengebundene Abfragen natürlich schnell; schlechtes Modeling zwingt die DB zu viel Arbeit.
Die meisten SaaS-Abfragen sollten eine Mandantenkennung enthalten. Modelle das explizit (z. B. tenant_id) und entwirf Indizes, die damit beginnen. In der Praxis ist ein zusammengesetzter Index wie (tenant_id, created_at) oder (tenant_id, status) viel nützlicher als nur created_at oder status zu indexieren.
Das gilt auch für Einzigartigkeiten: wenn E-Mails nur pro Mandant einzigartig sind, erzwinge das mit (tenant_id, email) statt eines globalen email-Constraints.
Ein häufiges Muster für langsame Queries ist ein versehentlicher Cross-Mandanten-Scan: eine Abfrage vergisst den Mandantenfilter und liest einen großen Tabellenbereich.
Mache den sicheren Pfad einfach:
Partitionierung kann die Datenmenge reduzieren, die jede Abfrage betrachten muss. Partitioniere nach Mandant, wenn Mandanten groß und ungleich verteilt sind. Partitioniere nach Zeit, wenn der Zugriff überwiegend aktuell ist (Events, Logs, Rechnungen), oft mit tenant_id als führendem Index innerhalb jeder Partition.
Sharding ist eine Option, wenn eine einzelne Datenbank den Peak-Durchsatz nicht schafft oder wenn ein Mandant die Ressourcen aller anderen bedroht.
"Hot-Mandanten" zeigen sich durch disproportionalen Lese-/Schreib-Volumen, Lock-Contention oder übergroße Indizes.
Erkenne sie durch Tracking von mandantenspezifischer Query-Zeit, gelesenen Zeilen und Schreibraten. Bei Dominanz isoliere sie: Umzug in ein eigenes Shard/DB, Aufsplitten großer Tabellen pro Mandant oder dedizierte Caches und Rate-Limits einführen, sodass andere Mandanten ihre Performance behalten.
Mehrmandantigkeit scheitert selten, weil die Datenbank „es nicht kann“. Sie scheitert, wenn tägliche Abläufe kleine Inkonsistenzen zulassen, die sich zu Sicherheitslücken oder Performance-Regressionen auswachsen. Ziel ist, dass der sichere Weg die Default-Option für jede Änderung, jeden Job und jedes Deploy ist.
Wähle einen einzigen, kanonischen Mandanten-Identifier (z. B. tenant_id) und verwende ihn konsistent in Tabellen, Indizes, Logs und APIs. Konsistenz reduziert Sicherheitsfehler (falschen Mandanten abfragen) und Performance-Überraschungen (fehlende passende Composite-Indizes).
Praktische Safeguards:
tenant_id in allen primären Zugriffspfaden (Queries, Repositories, ORM-Scopes)\n- Füge Composite-Indizes hinzu, die mit tenant_id beginnen für gängige Lookups\n- Bevorzuge Datenbank-Constraints (Foreign Keys, Check-Constraints), um fehlerhafte Writes früh zu erkennenAsync-Worker sind eine häufige Fehlerquelle, weil sie "out of band" vom Request laufen, der den Mandantenkontext gesetzt hat.
Operative Muster, die helfen:
tenant_id explizit in jedem Job-Payload; verlasse dich nicht auf ambienten Kontext\n- Füge den Mandantenschlüssel in Idempotency-Keys und Cache-Keys ein\n- Logge tenant_id bei Job-Start/Ende und bei jedem Retry, damit Untersuchungen schnell scoped werden könnenSchema- und Datenmigrationen sollten ohne perfekte, synchrone Rollouts einsetzbar sein.
Nutze Rolling-Änderungen:
Füge automatisierte Negative-Tests hinzu, die absichtlich versuchen, auf fremde Mandantendaten zuzugreifen (lesen und schreiben). Behandle diese Tests als Release-Blocker.
Beispiele:
tenant_id aus und verifiziere harte Fehler\n- Regressions-Tests für jeden Query-Helper, um sicherzustellen, dass Mandanten-Scoping immer angewendet wirdBackups sind leicht zu beschreiben ("kopiere die Datenbank") und überraschend schwer sicher auszuführen in einem Mehrmandanten-Setup. Sobald viele Kunden Tabellen teilen, brauchst du einen Plan, wie du einen Mandanten wiederherstellst, ohne andere zu exponieren oder zu überschreiben.
Ein Full-Database-Backup bleibt die Grundlage für Disaster Recovery, aber es reicht nicht für alltägliche Supportfälle. Gängige Ansätze:
tenant_id) um die Daten eines einzelnen Mandanten wiederherzustellen\n- Separater Speicher pro Mandant (sofern machbar), damit Restores natürlich mandantenbegrenzt sindWenn du auf logische Exporte setzt, behandle den Exportjob wie Produktionscode: er muss Mandantenisolation erzwingen (z. B. über RLS) statt sich auf eine einmal geschriebene WHERE-Klausel zu verlassen.
Datenschutzanfragen (Export, Löschung) sind mandantenbezogene Operationen, die Sicherheit und Performance berühren. Baue wiederholbare, geprüfte Workflows für:
Das größte Risiko ist nicht ein Hacker — es ist ein gehetzter Operator. Reduziere menschliche Fehler mit Guardrails:
tenant_id-Distribution vor dem Import\n- Restore zuerst in einer Quarantäneumgebung, dann promoteNach einem Disaster-Recovery-Drill hör nicht beim "die App ist wieder da" auf. Führe automatisierte Prüfungen durch, die Mandantenisolation bestätigen: Stichproben-Abfragen über Mandanten, Audit-Log-Review und stichprobenartige Verifikation, dass Verschlüsselungsschlüssel und Zugriffsrollen weiterhin korrekt gefiltert sind.
Mehrmandantigkeit ist oft die beste Default-Option für SaaS, aber sie ist keine permanente Entscheidung. Wenn Produkt und Kundenmix sich entwickeln, kann das "eine geteilte Datenspeicher"-Modell Geschäftsrisiken erzeugen oder die Auslieferung verlangsamen.
Erhöhe die Isolation, wenn immer wieder eines oder mehrere dieser Zeichen auftreten:
Du musst nicht zwischen "alles geteilt" und "alles dediziert" wählen. Gängige Hybride:
Mehr Isolation bedeutet meist höhere Infrastrukturkosten, mehr operativen Aufwand (Migrationen, Monitoring, On-Call) und mehr Release-Koordination (Schema-Änderungen über mehrere Umgebungen). Der Vorteil sind klarere Performance-Garantien und einfachere Compliance-Gespräche.
Wenn du Isolationsoptionen evaluierst, sieh dir verwandte Guides in /blog an oder vergleiche Pläne und Bereitstellungsoptionen auf /pricing.
Wenn du ein SaaS schnell prototypen und Mehrmandanten-Annahmen früh testen willst (Mandanten-Scoping, RLS-freundliche Schemata, Throttling und operative Workflows), kann eine Vibe-Coding-Plattform wie Koder.ai helfen: damit lässt sich eine funktionierende React + Go + PostgreSQL App aus Chat hochziehen, im Planungsmodus iterieren und mit Snapshots und Rollback deployen — und später den Quellcode exportieren, wenn du die Architektur für Produktion härten willst.
Eine Mehrmandanten-Datenbank ist eine Architektur, bei der mehrere Kunden dieselbe Datenbank-Infrastruktur (oft auch dasselbe Schema) teilen, während Anwendung und/oder Datenbank sicherstellen, dass jeder Mandant nur auf seine eigenen Daten zugreifen kann. Die Kernanforderung ist eine strikte Mandantenausgrenzung bei jedem Lese- und Schreibvorgang.
Mehrmandanten-Architekturen werden oft gewählt wegen:
Der Kompromiss ist, dass Sie bewusst Isolation und Performance-Schutzmaßnahmen bauen müssen.
Gängige Modelle (von stärkerer Isolation zu stärkerem Teilen) sind:
Ihre Wahl bestimmt die Isolationsgrenze und den operativen Aufwand.
Das größte Risiko verschiebt sich hin zu Cross-Mandanten-Zugriffen, die durch Routinefehler passieren, nicht nur durch externe Angreifer. Mandantenkontext (z. B. tenant_id) muss als Autorisationserfordernis behandelt werden, nicht als optionaler Filter. Sie müssen außerdem Produktionsrealitäten wie Konkurrenz, Caches, Retries und Hintergrundjobs berücksichtigen.
Die häufigsten Ursachen sind:
tenant_id bindenBauen Sie Guardrails, damit ungetaggte Abfragen schwer (oder unmöglich) ausführbar sind.
Row-Level Security (RLS) verschiebt Mandantenprüfungen in die Datenbank und verwendet Policies, die SELECT/UPDATE/DELETE auf Zeilen beschränken, die zum aktuellen Mandanten passen. RLS reduziert die Abhängigkeit davon, dass Entwickler immer die WHERE-Klausel richtig setzen, sollte aber mit App-seitiger Scoping-Logik, Least-Privilege-Prinzipien und starker Testabdeckung kombiniert werden. Betrachte RLS als zusätzliche Sperre, nicht als einzige.
Eine praktische Basis umfasst:
tenant_id in mandantenbesitzten Tabellentenant_id einbeziehenVerschlüsselung hilft, deckt aber andere Risiken ab:
Behandle Mandantenidentität als sicherheitskritisch: vertraue nicht einer rohen Mandanten-ID vom Client; binde sie an signierte Tokens und serverseitige Prüfungen.
Noisy-Neighbor-Probleme entstehen, wenn ein Mandant so viele gemeinsame Ressourcen (CPU, Speicher, I/O, Verbindungen) verbraucht, dass die Latenz für alle steigt. Praktische Gegenmaßnahmen sind:
Ziel ist Fairness, nicht nur maximale Durchsatzwerte.
Erhöhe Isolation, wenn Sie regelmäßig sehen:
Gängige Hybrid-Optionen: Auslagerung einiger Top-Tenants in eigene DB/Cluster, gestufte Pläne (shared vs. dedicated) oder Trennung von Analytics/Reporting für schwere Mandanten.
Ziel ist, dass Fehler sicher fehlschlagen.