Sicherheitsempfehlungen auf Zeilenebene - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Sicherheitsempfehlungen auf Zeilenebene

Sicherheit auf Zeilenebene (RLS) ist erforderlich, um die Isolierung der Mandantendaten in einem Poolmodell mit PostgreSQL aufrechtzuerhalten. RLS zentralisiert die Durchsetzung von Isolationsrichtlinien auf Datenbankebene und nimmt Softwareentwicklern die Last, diese Isolation aufrechtzuerhalten. Die gängigste Methode zur Implementierung von RLS besteht darin, diese Funktion im PostgreSQL-DBMS zu aktivieren. RLS beinhaltet das Filtern des Zugriffs auf Datenzeilen auf der Grundlage eines Werts in einer angegebenen Spalte. Sie können zwei Methoden verwenden, um den Zugriff auf Daten zu filtern:

  • Eine angegebene Datenspalte in einer Tabelle wird mit dem Wert des aktuellen PostgreSQL-Benutzers verglichen. Werte in der Spalte, die dem angemeldeten PostgreSQL-Benutzer entsprechen, sind für diesen Benutzer zugänglich.

  • Eine angegebene Datenspalte in einer Tabelle wird mit dem Wert einer von der Anwendung festgelegten Laufzeitvariablen verglichen. Auf Werte in der Spalte, die der Laufzeitvariablen entsprechen, kann während dieser Sitzung zugegriffen werden.

Die zweite Option wird bevorzugt, da die erste Option die Erstellung eines neuen PostgreSQL-Benutzers für jeden Mandanten erfordert. Stattdessen sollte eine SaaS-Anwendung, die PostgreSQL verwendet, dafür verantwortlich sein, zur Laufzeit einen mandantenspezifischen Kontext festzulegen, wenn sie PostgreSQL abfragt. Dies wird die Durchsetzung von RLS zur Folge haben. Sie können RLS auch auf einer Basis aktivieren. table-by-table Als bewährte Methode sollten Sie RLS für alle Tabellen aktivieren, die Mandantendaten enthalten.

Im folgenden Beispiel werden zwei Tabellen erstellt und RLS aktiviert. In diesem Beispiel wird eine Datenspalte mit dem Wert der Laufzeitvariablen app.current_tenant verglichen.

-- Create a table for our tenants with indexes on the primary key and the tenant’s name
CREATE TABLE tenant (
    tenant_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    name VARCHAR(255) UNIQUE,
    status VARCHAR(64) CHECK (status IN ('active', 'suspended', 'disabled')),
    tier VARCHAR(64) CHECK (tier IN ('gold', 'silver', 'bronze'))
);
 
-- Create a table for users of a tenant
CREATE TABLE tenant_user (
    user_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    tenant_id UUID NOT NULL REFERENCES tenant (tenant_id) ON DELETE RESTRICT,
    email VARCHAR(255) NOT NULL UNIQUE,
    given_name VARCHAR(255) NOT NULL CHECK (given_name <> ''),
    family_name VARCHAR(255) NOT NULL CHECK (family_name <> '')
);
 
-- Turn on RLS
ALTER TABLE tenant ENABLE ROW LEVEL SECURITY;
 
-- Restrict read and write actions so tenants can only see their rows
-- Cast the UUID value in tenant_id to match the type current_setting
-- This policy implies a WITH CHECK that matches the USING clause
CREATE POLICY tenant_isolation_policy ON tenant
USING (tenant_id = current_setting('app.current_tenant')::UUID);
 
-- And do the same for the tenant users
ALTER TABLE tenant_user ENABLE ROW LEVEL SECURITY;
 
CREATE POLICY tenant_user_isolation_policy ON tenant_user
USING (tenant_id = current_setting('app.current_tenant')::UUID);

Weitere Informationen finden Sie im Blogbeitrag Multi-Tenant-Datenisolierung mit PostgreSQL Row Level Security. Das AWS SaaS Factory-Team hat auch einige Beispiele GitHub, die Sie bei der Implementierung von RLS unterstützen.