Sichere SQL-Ansichten: Generieren Sie Statistiken, ohne das RLS zu beschädigen

Beim Entwurf moderner mandantenfähiger SaaS-Anwendungen (z. B. eines SOC-Orchestrators, der mehrere Clients verwaltet) ist die Datenbankarchitektur der Knackpunkt. Um sicherzustellen, dass kein Kunde auf die Vorfälle eines anderen Kunden zugreifen kann, hat die Branche einen absoluten Standard eingeführt:Sicherheit auf Zeilenebene (RLS)von PostgreSQL.

Das RLS sperrt jede Zeile in der Datenbank basierend auf der Identität des Analysten. Aber was passiert, wenn Sie aggregierte Statistiken (z. B. die Berechnung der MTTR oder der Gesamtzahl der Tickets) über SQL-Ansichten generieren müssen (VIEWS) oder Aggregationsfunktionen?

Wenn die SQL-Ansicht schlecht gestaltet ist, kann sie RLS-Regeln umgehen und statistische Daten zwischen Clients preisgeben. Erfahren Sie, wie die Akuity SOC-Architektur dieses Rätsel mit dem Modifikator löstSECURITY INVOKER.

Das Problem: Die Datenaggregation umgeht RLS oft

Stellen Sie sich vor, Sie müssten das KPI-Dashboard Ihres SOC erstellen. Sie müssen die Tabelle abfragenTickets(das Tausende von Microsoft Defender-Protokollen enthält), um eine zu erstellenCOUNT()oder berechnen Sie einen Durchschnitt (AVG()) Auflösungszeit.

Die klassische Lösung für einen DBA (Datenbankadministrator) besteht darin, eine SQL-Ansicht zu erstellen (CREATE VIEW viewworkspacekpis AS SELECT ...).

Standardmäßig werden in vielen historischen Datenbanken oder Frameworks Ansichten oder Funktionen mit den Rechten der Person ausgeführt, die dies tuterstelltdie Ansicht (der Eigentümer der Datenbank). Dies wird als Modus bezeichnetSECURITY DEFINER.

Die Gefahr ist kritisch: Wenn eine Ansicht als Superadministrator der Datenbank ausgeführt wird,es umgeht die RLS-Regeln vollständig. Der SOC-Analyst von Kunde A fragt die Ansicht nach ihrer MTTR ab, aber die Ansicht, die ohne RLS-Filter ausgeführt wird, aggregiert die gesamte System-MTTR und gibt sie zurück, einschließlich der Daten von Kunde B. Selbst wenn die Weboberfläche versucht, den Fehler zu verbergen, ist das Metadatenleck bewiesen und Sie verlieren Ihre SOC 2-Konformität.

Die PostgreSQL-Lösung: DieSECURITY INVOKER

Damit ein SaaS-KPIs-Dashboard sowohl effizient als auch perfekt unterteilt ist, muss die SQL-Engine gezwungen werden, die Ansicht oder Funktion mit den genauen Berechtigungen des Endbenutzers (des verbundenen Analysten) und nicht mit denen des Datenbankerstellers auszuwerten.

Hier kommt der Modifikator ins Spiel.SECURITY INVOKER.

In der Architektur der Akuity SOC-Plattform (unterstützt von Supabase/PostgreSQL) sind unsere statistischen Dashboards (wie das Flächendiagramm für die letzten 30 Tage oder die Berechnung der Auflösungsrate) niemals auf umfangreiche Anwendungsabfragen angewiesen. Sie fragen vorkompilierte SQL-Ansichten ab, die dieser Regel strikt folgen.

Implementierung im Akuity SOC

In unserem Datenbankmigrationsskript wird die für Statistiken zuständige Ansicht wie folgt deklariert:

CREATE VIEW view_workspace_kpis 
WITH (security_invoker = on) AS 
SELECT 
    t.workspace_id,
    COUNT(tk.id) as total_incidents,
    AVG(tk.resolution_time) as mttr_minutes
FROM tenants t 
LEFT JOIN tickets tk ON tk.tenant_id = t.id 
GROUP BY t.workspace_id;

Ebenso verwenden Abfragen zur Anzeige des Arbeitslastzeitdiagramms eine gespeicherte Funktiongetdailyincident_countwas definiert ist mitSECURITY INVOKER.

Operative Auswirkungen und SOC 2-Konformität

Verwenden dieser CodezeileWITH (security_invoker = on), die Magie der nativen Cloud geschieht:

1. Der Analyst (authentifiziert über ein JWT-Token, das seine enthältauth.uid()) fordert die Anzeige seines Dashboards auf der Akuity-Oberfläche an.
2. Ansicht der API-Anfrageaufrufeviewworkspacekpis.
3. Die PostgreSQL-Engine wertet die Ansicht auswie dieser Analytiker.
4. Die nativen RLS-Regeln der zugrunde liegenden Tabellen (tenantsUndtickets) werden vor der Aggregation plötzlich angewendet. Kundenanschlüsse, auf die der Analyst keinen Zugriff hat, sind unsichtbar. AggregationCOUNT()OderAVG()erfolgt nur auf zulässigen Daten.

Warum Prüfer diese Architektur fordern

Während eines TypkonformitätsauditsSOC 2 Typ IIOderNIS 2Ziel des Audits ist der Nachweis, dass das System nicht ausschließlich auf Softwareversprechen (dem React/Next.js-Frontend-Code) basiert, sondern auf systemischen Sicherheitskontrollen („Security by Design“). Die gemeinsame Nutzung von RLS und ViewsSECURITY INVOKERbietet kryptografischen und mathematischen Nachweis der absoluten Datenisolation von Ihren Mandanten.

Fazit: SaaS-Analytics ohne Kompromisse

Das Erstellen von Dashboards für ein mandantenfähiges Sicherheitsbetriebszentrum sollte niemals eine Hintertür für Metadaten sein. Indem Sie eine einwandfreie Datenbankarchitektur auf Basis von PostgreSQL fordern, garantieren Sie Ihren MSSP-Kunden oder Ihrer Comex, dass die angezeigten Statistiken nicht nur korrekt, sondern von Natur aus wasserdicht sind.

Verwalten Sie Ihre KPIs mit Sicherheit auf Unternehmensniveau.> Entdecken Sie die souveräne Architektur unseresSOC RLS- und KPI-Dashboardsin Bayern entwickelt.