Das Sicherheits-Dilemma der Mandantenfähigkeit
Bei der Entwicklung von B2B SaaS-Plattformen ist die saubere Trennung der Kundendaten (Tenants) die wichtigste architektonische Pflichtaufgabe. Gelangt ein Kunde durch einen Softwarefehler (z.B. eine fehlerhafte WHERE-Klausel im Backend-Code) an die Daten eines anderen Mandanten, bedeutet das meist den sofortigen Ruin des SaaS-Startups und irreparable Imageschäden. Klassische Lösungsansätze wie separate Datenbanken pro Kunde sind im Betrieb extrem teuer und schwer zu migrieren. Die Lösung: **PostgreSQL Row Level Security (RLS)**.
Was ist Row Level Security?
Row Level Security verschiebt die Zugriffsprüfung von der Anwendungsschicht (Ihrem Node.js/Go-Service) direkt in das Datenbanksystem. Statt darauf zu hoffen, dass Entwickler in jedem SQL-Query ein korrektes WHERE tenant_id = X einfügen, sorgt die Datenbank selbst dafür, dass ein Benutzer nur Zeilen lesen und schreiben kann, für die er explizit autorisiert ist.
Das RLS-Prinzip in der Postgres-Datenbank
Die folgende Visualisierung verdeutlicht, wie PostgreSQL als unüberwindbarer Wächter direkt auf Tabellenebene fungiert:
[Datenbank-Abfrage von Mandant A]
│
▼ (Führt SELECT * FROM orders aus)
┌───────────────────────────────────┐
│ PostgreSQL Engine │
│ │
│ [RLS Policy: tenant_id = 'A'] │ <── Wächter-Schicht
│ │
│ ┌───────────────────────────┐ │
│ │ Tabelle: orders │ │
│ │ ────────────────── │ │
│ │ Row 1 (Tenant A) ──[OK] │ │
│ │ Row 2 (Tenant B) ──[BLOCKED] │
│ └───────────────────────────┘ │
└───────────────────────────────────┘
Code-Blueprint: RLS im SQL-Einsatz
Hier sehen Sie ein konkretes, produktionsreifes SQL-Beispiel, wie wir Tabellen erstellen, RLS aktivieren und eine sichere Policy definieren, die auf einer Session-Variable basiert:
-- 1. Tabelle mit Tenant-ID erstellen
CREATE TABLE tenant_data (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES tenants(id),
document_name VARCHAR(255) NOT NULL,
sensitive_payload TEXT
);
-- 2. Row Level Security für die Tabelle aktivieren
ALTER TABLE tenant_data ENABLE ROW LEVEL SECURITY;
-- 3. Policy erstellen: Vergleiche Tabelleneintrag mit Session-Variable
CREATE POLICY tenant_isolation_policy ON tenant_data
USING (tenant_id = NULLIF(current_setting('app.current_tenant_id', true), '')::uuid);
Vorteile von Postgres RLS
Die datenbankseitige Absicherung bietet immense Vorteile für agile B2B-Projekte:
Die Kernvorteile auf einen Blick:
- check_circle Absolute Sicherheit: Ein fehlerhafter API-Route im Backend kann niemals Datenlecks verursachen, da PostgreSQL den Zugriff sperrt.
- check_circle Geringe Kosten: Hunderte Kunden laufen auf einer einzigen, effizient genutzten DB-Instanz. Das spart enorme Serverressourcen.
- check_circle Einfache Wartung: Schema-Updates und Migrationen müssen nur ein einziges Mal ausgeführt werden statt mühsam für jeden Kunden einzeln.
Fazit
Die Multi-Tenant-Architektur mit Postgres RLS bietet das Optimum aus absoluter Datensicherheit und minimalen Betriebskosten. Sie ist die ideale technologische Basis für B2B-Startups und etablierte Mittelständler, die ihre analogen Produkte zu skalierbaren SaaS-Plattformen transformieren möchten.