Raccomandazioni di sicurezza a livello di riga - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Raccomandazioni di sicurezza a livello di riga

La sicurezza a livello di riga (RLS) è necessaria per mantenere l'isolamento dei dati dei tenant in un modello in pool con PostgreSQL. RLS centralizza l'applicazione delle politiche di isolamento a livello di database e rimuove l'onere di mantenere tale isolamento dagli sviluppatori di software. Il modo più comune per implementare RLS è abilitare questa funzionalità nel DBMS PostgreSQL. RLS prevede il filtraggio dell'accesso alle righe di dati in base a un valore in una colonna specificata. È possibile utilizzare due metodi per filtrare l'accesso ai dati:

  • Una colonna di dati specificata in una tabella viene confrontata con il valore dell'utente PostgreSQL corrente. I valori nella colonna che sono equivalenti all'utente PostgreSQL che ha effettuato l'accesso sono accessibili a quell'utente.

  • Una colonna di dati specificata in una tabella viene confrontata con il valore di una variabile di runtime impostata dall'applicazione. I valori nella colonna che sono equivalenti alla variabile di runtime sono accessibili durante quella sessione.

La seconda opzione è preferita, perché la prima richiede la creazione di un nuovo utente PostgreSQL per ogni tenant. Invece, un'applicazione SaaS che utilizza PostgreSQL dovrebbe essere responsabile dell'impostazione di un contesto specifico del tenant in fase di esecuzione quando interroga PostgreSQL. Ciò avrà l'effetto di applicare RLS. È inoltre possibile abilitare RLS su base individuale. table-by-table Come procedura consigliata, è consigliabile abilitare RLS su tutte le tabelle che contengono dati dei tenant.

L'esempio seguente crea due tabelle e abilita RLS. Questo esempio confronta una colonna di dati con il valore della variabile runtime. app.current_tenant

-- 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);

Per ulteriori informazioni, consulta il post sul blog Isolamento dei dati multi-tenant con PostgreSQL Row Level Security. Il team AWS SaaS Factory ha anche alcuni esempi GitHub per aiutare nell'implementazione di RLS.