Row-Level Security ist keine Empfehlung
Warum Multi-Tenant-Isolation in die Datenbank gehoert, nicht in die Anwendung.
Ein Gedankenexperiment. Sie nutzen eine SaaS-Plattform. Ihr Wettbewerber nutzt dieselbe Plattform. Sie speichern beide Inventory, Grading-Ergebnisse, Preise und Kundendaten. Die Frage: Was verhindert, dass Ihr Wettbewerber Ihre Daten sieht?
Wenn die Antwort lautet "der Anwendungscode prüft, welcher Tenant Sie sind, und zeigt nur Ihre Daten" — Glückwunsch, Sie haben application-level security. Das bedeutet, dass ein Bug im Anwendungscode, ein falsch konfigurierter API-Endpunkt, SQL Injection oder ein zu hilfreicher Entwickler mit Datenbankzugriff potenziell Daten von Tenant A an Tenant B ausgeben könnte.
Wenn die Antwort lautet "die Datenbank selbst erzwingt Isolation, und keine Query kann Daten eines anderen Tenants zurückgeben, egal wie sie geschrieben ist" — dann haben Sie Row-Level Security. Das sind sehr unterschiedliche Dinge.
Das Problem der Anwendungsschicht
Application-level Tenant Isolation funktioniert so: Jede Query enthält einen Filter. WHERE tenant_id = 'your-tenant'. Die Anwendung fügt diesen Filter jedem Datenbankaufruf hinzu. Ist der Filter vorhanden, sehen Sie Ihre Daten. Fehlt er — wegen eines Bugs, eines Versehens, eines neuen Endpoints ohne Check oder eines Entwicklers, der schnell eine Query in Produktion ausführt — gibt die Datenbank fröhlich alles zurück.
Die Datenbank weiß nichts über Tenants. Die Datenbank speichert Zeilen. Es ist Aufgabe der Anwendung, nach den richtigen Zeilen zu fragen. Und die Anwendung, Software geschrieben von Menschen, kann Fehler machen.
Das ist nicht theoretisch. Multi-Tenant-Datenlecks gehören zu den häufigsten Sicherheitsvorfällen in SaaS-Plattformen. Ein Entwickler schreibt einen neuen API-Endpunkt und vergisst den Tenant-Filter. Ein Migrationsskript läuft ohne WHERE-Klausel. Eine Debugging-Session verbindet direkt zur Datenbank und führt ein SELECT * aus, das Datensätze aller Tenants zurückgibt. Jede dieser Situationen ist ein einfacher Fehler. Jede könnte Ihr Inventory, Ihre Preise und Ihre Kundendaten offenlegen.
Application-level Security bedeutet, dass das Schloss an der Tür ist. Row-Level Security bedeutet, dass die Wände aus Beton sind. Türen können offen bleiben. Beton nicht.
Row-Level Security: Die Datenbank als Durchsetzer
Postgres Row Level Security (RLS) funktioniert anders. Statt sich darauf zu verlassen, dass die Anwendung Daten filtert, erzwingt die Datenbank selbst die Regeln. Jede Tabelle hat eine Policy, die sagt: "Dieser Tenant darf nur Zeilen sehen, bei denen tenant_id zu seiner Session passt." Die Policy wird auf Datenbankebene durchgesetzt. Kein Anwendungscode kann sie überschreiben. Keine Query kann sie umgehen. Ein SELECT * gibt nur Ihre Zeilen zurück, nicht weil die Anwendung sie gefiltert hat, sondern weil die Datenbank sich weigert, etwas anderes zu zeigen.
Wenn ein Entwickler einen buggy Endpoint schreibt und den Tenant-Filter vergisst, gibt die Datenbank trotzdem nur die Daten des richtigen Tenants zurück. Wenn jemand eine Raw Query ausführt, gilt die Policy. Wenn eine neue Funktion in Eile gebaut wird und Access Control unvollständig ist, ist das der Datenbank egal — die Policy ist da, dauerhaft und unvergesslich.
RLS ersetzt Anwendungssicherheit nicht. Sie brauchen weiterhin Authentifizierung, Autorisierung und gutes API-Design. Aber RLS ist das Sicherheitsnetz — die Garantie, dass Tenant-Daten nicht leaken, selbst wenn die Anwendung einen Fehler macht. Es ist der Unterschied zwischen "wir vertrauen dem Code" und "die Architektur lässt es nicht zu".
Warum das für ITAD wichtig ist
ITAD-Plattformen verarbeiten naturgemäß sensible Daten. Inventory enthält Geräteseriennummern und Asset-Historien. Preise offenbaren kommerzielle Strategie. Kundenlisten sind Wettbewerbsintelligenz. Löschdatensätze enthalten Metadaten darüber, was auf dem Gerät war, bevor es gelöscht wurde — und obwohl die Daten selbst weg sind, sind die Metadaten (welche Kunden welche Geräte mit welchen Datenklassifizierungen hatten) wertvoll und sensibel.
Wenn Sie als ITAD-Unternehmen eine Multi-Tenant-Plattform evaluieren, sollte die Frage "Wie sind meine Daten von anderen Tenants isoliert?" in Ihrer ersten E-Mail stehen. Und die Antwort sollte lauten: "auf Datenbankebene, mit RLS-Policies auf jeder Tabelle." Nicht "unser Anwendungscode erledigt das". Nicht "wir haben Zugriffskontrollen". Nicht "unsere Entwickler sind sehr vorsichtig". Vorsicht ist keine Sicherheitsarchitektur. Vorsicht ist Hoffnung.
Row-Level Security ist kein Feature, das je nach Präferenz ein- oder ausgeschaltet wird. Es ist eine grundlegende Architekturentscheidung, die bestimmt, ob Ihre Multi-Tenant-Plattform echte Isolation oder simulierte Isolation hat. Der Unterschied ist unsichtbar, wenn alles korrekt funktioniert. Der Unterschied ist alles, wenn etwas schiefgeht.
Ihr Wettbewerber nutzt dieselbe Plattform. Kann er Ihre Daten sehen? Wenn die Antwort davon abhängt, dass die Anwendung nie einen Fehler macht, lautet die Antwort: "noch nicht".