Tech-USP: Mandanten-Scoping ist Default, nicht Opt-in. Jede Entität ist mandanten-getrennt, solange ihr nicht explizit Cross-Tenant markiert. Und auf Plattform-Ebene bekommt jede App eigene Datenbank-Zugangsdaten — Trennung ist nicht nur eine Filter-Klausel, sondern wird auf Datenbank-Ebene erzwungen.
Sicht des Käufers: Eine Installation hostet beliebig viele Kunden (oder Abteilungen oder Geschäftsbereiche). Jeder sieht nur seine eigenen Daten — automatisch, ohne dass eure Entwickler je eine Filter-Klausel von Hand schreiben. Und die Datenbank selbst vertraut dem App-Code nicht: Jede App meldet sich mit eigenen Credentials an, ein Bug in App A kann physisch nicht App Bs Daten lesen.
Zwei Schichten Isolation
Schicht 1 — Mandanten-Scoping innerhalb einer App.
Wenn ihr ein internes Tool baut das mehrere Kunden (oder Abteilungen) bedient, wird jeder Datensatz automatisch dem „aktuellen Mandanten” zugeordnet. Euer Code sagt db.query("ticket") und das Framework hängt den Mandanten-Filter dran — ihr könnt ihn nicht vergessen weil es keinen Weg gibt die Query ohne ihn zu schreiben.
Cross-Tenant-Queries sind möglich — aber sie müssen explizit sein. Ein Entwickler der db.crossTenant("ticket") schreibt trifft eine bewusste Entscheidung; ein Entwickler der die normale Query schreibt bekommt den sicheren Default.
Schicht 2 — Datenbank-Isolation zwischen Apps. Auf der gehosteten Plattform bekommt jede App, die ihr betreibt, eine eigene Datenbank mit eigenen Login-Credentials. App A weiß buchstäblich nicht wie sie sich an App Bs Datenbank anmelden würde — die Credentials werden beim Start aus einem Vault gezogen, pro App separat. Kein „Service-Account-mit-Admin-Rechten-auf-alles”-Setup.
Was das in Failure-Modes heißt:
- Ein SQL-Injection in App A kann App As Daten korrumpieren. App Bs Daten erreicht es nicht.
- Eine fehlerhafte Query in App A liefert eigene Daten, nie die einer anderen App — es gibt schlicht keine Verbindung.
- Eine kompromittierte Dependency in App A ist auf App As Datenbank-Scope beschränkt.
Highlights
- Mandanten-Auflösung über Header, Cookie, Resolver oder Default — passt für Subdomain-, Path- und Header-basierte Setups
- Anonymous-Access für öffentliche Endpoints mit Mandanten-Auflösung über den Host
- Pro Mandant: eigener Suchindex, eigene Feature-Toggles, eigene Konfiguration
- Pro App (auf Hosted): eigene Datenbank, eigene Credentials, eigener Bucket für Dateien
- Cross-Tenant-Zugriff ist explizit, nicht implizit — der sichere Default ist auch der einfache Default
Was ihr nicht machen müsst
WHERE tenant_id = ?in jede Query schreiben — wird für euch ergänzt- Per-App-Datenbank-User von Hand verwalten — die Plattform provisioniert sie
- Eine „Tenant-Context”-Middleware bauen — gibt’s schon, getestet
- Cross-Tenant-Queries auditieren um sicherzustellen dass niemand den Filter vergessen hat — es gibt nichts zu vergessen
Architektur-Tiefendoku
tenant-db-context—ctx.dbScoping, Cross-Tenant-Eskalationpermissions— Roles + Ownership-Filterscaling— Multi-Tenant-Skalierung (DB-shared vs DB-per-tenant)
Wo das im Pitch landet
- DACH-Mittelstand: „Mandantentrennung von Haus aus — eure Abteilungen sehen sich nicht gegenseitig, und die Datenbank selbst erzwingt das”
- Indie-Hacker: „Mandantentrennung ist die häufigste Bug-Quelle in B2B-SaaS. Wir haben die Möglichkeit dieses Bugs entfernt”
- Compliance / Security-Review: Zwei Schichten (App-Filter + Datenbank-Credentials) bedeuten dass ein Ein-Zeilen-Bug nicht zum Datenleck wird