Row-Level-Security-Richtlinien verringern mandantenübergreifende Datenlecks im Vergleich zu anwendungsseitiger Filterung

Hypothese

Die Dokumentation zu Row Security hält fest, dass, sobald Row Security auf einer Tabelle aktiviert ist, jeder normale Zugriff durch eine Richtlinie erlaubt sein muss, und dass ohne jede Richtlinie eine Default-Deny-Regel gilt, sodass keine Zeilen sichtbar oder änderbar sind; Superuser, Rollen mit BYPASSRLS und normalerweise die Eigentümerin oder der Eigentümer der Tabelle umgehen sie. Eine Richtlinie trägt einen USING-Ausdruck für Zeilen, die gesehen werden dürfen, und einen WITH CHECK-Ausdruck für Zeilen, die geschrieben werden dürfen; die CREATE-POLICY-Seite hält fest, dass permissive Richtlinien mit OR kombiniert werden, restriktive mit AND, und dass mindestens eine permissive Richtlinie nötig ist, bevor restriktive nützlich sind. Ein Dienst, der sich als Rolle verbindet, die nicht Eigentümerin ist, den Mandanten pro Transaktion setzt (SET LOCAL app.tenant_id = ...) und auf jeder Mandantentabelle USING (tenant_id = current_setting('app.tenant_id')::uuid) definiert, verändert die Fehlermodi: Eine Abfrage, der das Mandantenprädikat fehlt, liefert weiterhin nur die Zeilen des aktuellen Mandanten, und eine Anfrage, die app.tenant_id nie setzt, liefert nichts oder scheitert am Cast, statt die Zeilen aller Mandanten zu liefern. Die Hypothese: Über die Lebensdauer einer Codebasis hinweg führt dieses Design zu weniger bestätigten mandantenübergreifenden Offenlegungsfehlern als anwendungsseitige Filterung bei gleicher Testdisziplin.

Vorhersage

In Codebasen mit Richtlinien auf allen Mandantentabellen sind als „Daten eines anderen Mandanten sichtbar“ klassifizierte Fehlerberichte pro Endpunkt seltener als in vergleichbaren Codebasen ohne solche Richtlinien, und die verbleibenden Lecks stammen aus einer kleinen Menge von Ursachen: Verbindungen, die als Eigentümerin, Superuser oder mit einer BYPASSRLS-Rolle laufen; Tabellen, bei denen die Richtlinie vergessen wurde; und Code, der mit den Rechten der definierenden Person läuft. Einzelne Abfragen, denen ein Prädikat fehlt, tauchen unter den Ursachen nicht auf.

Vorgeschlagener Test

1. Dienste ähnlicher Grösse mit und ohne richtlinienbasierte Isolation auswählen; aus ihren Trackern die als mandantenübergreifende Offenlegung markierten Vorfälle über einen festen Zeitraum extrahieren, normalisiert nach Anzahl der Endpunkte.
2. Mutationsartige Prüfung: das Mandantenprädikat aus einer Stichprobe von Abfragen in jeder Codebasis entfernen und zählen, wie viele mutierte Abfragen in einer Testumgebung mit zwei Mandanten fremde Zeilen zurückgeben, und wie viele Tests sie abfangen.
3. Die verbleibenden Fehlerklassen festhalten, um zu sehen, ob Eigentümerverbindungen und vergessene Richtlinien dominieren, was anzeigen würde, wohin Review-Aufwand gehört.

Status

Es wird kein Ergebnis behauptet. Richtlinien verschieben den Fehlermodus, bringen aber ihre eigenen mit sich: Sie müssen pro Tabelle erstellt und getestet werden, privilegierte Rollen umgehen sie, und Richtlinienausdrücke verändern Abfragepläne. Die Hypothese betrifft nur Leck-Zahlen, nicht Performance oder Betriebskosten.