Wie funktioniert die Mandanten-Isolation?
Kurzantwort
Abschnitt betitelt „Kurzantwort“Jede Anfrage an Notory läuft im Kontext genau eines Mandanten, abgeleitet aus dem
Anmelde-Token, nicht aus einer wählbaren Einstellung. Die Trennung wird auf zwei
Ebenen erzwungen: in der Anwendung (jede Abfrage filtert auf tenant_id) und in der
Datenbank per Row-Level-Security (RLS). Selbst ein fehlerhafter Anwendungsfilter würde
dadurch keine fremden Daten preisgeben. Nur Super-Admins umgehen die Sperre bewusst.
Voraussetzungen
Abschnitt betitelt „Voraussetzungen“Die Isolations-Schichten im Detail
Abschnitt betitelt „Die Isolations-Schichten im Detail“1. Der Mandant steckt im Token
Abschnitt betitelt „1. Der Mandant steckt im Token“Beim Login wird die tenant_id deines Kontos fest in das Sitzungs-Token (JWT) geschrieben;
bei einem API-Token ist sie fest am Token gespeichert.
Der Server liest den Mandanten ausschließlich aus diesem Nachweis. Es gibt keinen
Header und keinen Parameter, mit dem sich ein anderer Mandant „anfordern” ließe.
2. Row-Level-Security in der Datenbank
Abschnitt betitelt „2. Row-Level-Security in der Datenbank“Zu Beginn jeder Anfrage setzt Notory den RLS-Kontext der Datenbank-Session auf deinen Mandanten. PostgreSQL blendet daraufhin alle Zeilen anderer Mandanten aus, auf Datenbank-Ebene, unterhalb der Anwendung. Ein Programmierfehler in einer Abfrage kann dadurch keine Fremddaten liefern: Die Datenbank gibt sie schlicht nicht heraus.
3. Eindeutige Konten, getrennte Konfiguration
Abschnitt betitelt „3. Eindeutige Konten, getrennte Konfiguration“- Benutzer gehören zu genau einem Mandanten (E-Mail systemweit eindeutig).
- SSO: Ein Konto darf sich nur über einen Identity-Provider seines eigenen Mandanten anmelden. Der Versuch über einen fremden Provider wird abgelehnt („This account does not belong to the selected provider’s tenant”).
- Rollen: Eine Rolle aus einem fremden Mandanten kann nie zugewiesen werden.
- Webhooks, API-Tokens, Freifelder, Branding, SSO-Provider: alles ist je Mandant gespeichert und sichtbar.
4. Lizenz-Schnittmenge
Abschnitt betitelt „4. Lizenz-Schnittmenge“Die wirksamen Rechte eines Mandanten sind die Schnittmenge aus seinem eigenen Tarif
(license_tier) und der Produktlizenz der Installation, inklusive Asset-Limit. Ein
Mandant kann sich also nie „mehr Lizenz” verschaffen, als die Installation besitzt.
Was passiert dabei?
Abschnitt betitelt „Was passiert dabei?“- Anfrageablauf: Authentifizierung →
tenant_idaus JWT/API-Token → RLS-Kontext setzen → erst dann werden Daten gelesen/geschrieben. Bei API-Tokens wird zusätzlich der Scope (read/write) geprüft. - Super-Admin-Ausnahme: Für Super-Admins wird der RLS-Bypass gesetzt. Sie sehen und verwalten alle Mandanten (z. B. in der Mandanten- und Benutzerverwaltung). Genau deshalb sollte es sehr wenige Super-Admins geben.
- Audit bleibt zentral: Das Protokoll erfasst Aktionen mit
tenant_id, sodass der Instanzbetreiber mandantenübergreifend nachvollziehen kann, was geschah. Einträge überleben sogar das Löschen eines Mandanten. - 2FA-Pflicht je Mandant:
require_2falässt sich pro Mandant erzwingen (nur mit Multi-Tenant-Lizenz); instanzweite und mandantenspezifische Pflicht wirken per ODER. - Papierkorb & Aufbewahrung je Mandant: Mandanten können die Instanz-Vorgaben für Papierkorb und Aufbewahrungsfristen überschreiben.