Cos'è RLS - Row Level Security? Definizione Completa e Guida Pratica
Il Row Level Security (RLS) è un meccanismo di sicurezza database che controlla l'accesso ai dati riga per riga, in base all'identità dell'utente autenticato. Invece di consentire o negare l'accesso all'intera tabella, RLS filtra automaticamente le righe visibili a ciascun utente, garantendo che ogni persona veda solo i dati a cui è autorizzata.
Cos'è il Row Level Security (RLS)?
Tradizionalmente, la sicurezza database funzionava a livello di tabella: un utente aveva accesso all'intera tabella o non ne aveva affatto. Questa granularità grossolana non soddisfa le esigenze di applicazioni multi-tenant moderne, dove utenti diversi devono vedere sottoinsiemi diversi degli stessi dati.
Il Row Level Security risolve questo problema consentendo di definire policyche filtrano automaticamente le righe restituibili a ciascun utente in base alla sua identità. Queste policy vengono applicate dal motore del database per ogni query, prima che i risultati vengano restituiti all'applicazione.
Il vantaggio fondamentale è che RLS opera indipendentemente dal codice applicativo: anche se un bug nel codice "dimentica" di filtrare per tenant_id, il database restituirà comunque solo le righe autorizzate per l'utente autenticato. Questo crea un secondo livello di difesa che protegge contro errori di programmazione.
Come Funzionano le Policy RLS in PostgreSQL
Abilitazione RLS su una Tabella
Per attivare RLS su una tabella, si usa il comando ALTER TABLE. Una volta abilitato, di default nessuna riga è accessibile (deny-by-default) fino a quando non vengono definite policy esplicite che consentono l'accesso.
ALTER TABLE chatbots ENABLE ROW LEVEL SECURITY;Definizione di una Policy
Una policy RLS specifica: chi può eseguire quale operazione (SELECT, INSERT, UPDATE, DELETE) e quale condizione deve essere vera per le righe accessibili. La clausola USING si applica alla lettura, WITH CHECK alla scrittura.
-- Solo il proprietario può vedere i propri chatbot
CREATE POLICY "owner_sees_own_chatbots"
ON chatbots FOR SELECT
USING (owner_id = auth.uid());
-- Solo il proprietario può modificare i propri chatbot
CREATE POLICY "owner_manages_own_chatbots"
ON chatbots FOR ALL
USING (owner_id = auth.uid())
WITH CHECK (owner_id = auth.uid());Policy per Ruoli Gerarchici
Le policy possono implementare logiche di accesso gerarchiche. In V Support, i proprietari account vedono tutto, i clienti vedono solo le proprie risorse, gli utenti anonimi vedono solo i widget pubblici:
-- Clienti vedono solo le proprie conversazioni
CREATE POLICY "clients_see_own_conversations"
ON chat_conversations FOR SELECT
USING (
chatbot_id IN (
SELECT id FROM chatbots
WHERE client_id = auth.uid()
)
);RLS vs Sicurezza a Livello Applicativo
Sicurezza Solo Applicativa (Rischiosa)
Affidarsi solo al codice applicativo per filtrare i dati espone a rischi significativi:
- Un bug nel codice può esporre tutti i dati di tutti i tenant
- SQL injection bypassa i filtri applicativi
- Accesso diretto al database (manutenzione) ignora i filtri
- Ogni nuovo endpoint/query deve implementare manualmente i filtri
- Difficile verificare la correttezza di tutti i filtri
Con RLS (Difesa in Profondità)
RLS aggiunge un livello di difesa robusto e indipendente:
- Bug applicativi non possono esporre dati di altri tenant
- SQL injection non bypassa le policy database
- Accesso diretto al database rispetta ancora le policy
- Policy centralizzate: un unico punto di verifica
- Verificabile con test specifici per ogni policy
Best Practice per RLS in Produzione
Testare le Policy con Utenti Diversi
Ogni policy RLS deve essere testata da tre prospettive: un utente che dovrebbe vedere i dati (verifica accesso corretto), un utente che non dovrebbe vederli (verifica isolamento) e un utente non autenticato (verifica accesso anonimo). I test automatizzati di RLS sono fondamentali per garantire che le policy non vengano rotte da future modifiche allo schema.
Evitare Ricorsione nelle Policy
Una policy su una tabella A non dovrebbe fare subquery su una tabella B che ha a sua volta una policy che fa subquery su A: questo crea ricorsione infinita. Usare funzioni sicure (SECURITY DEFINER con permessi minimi) per le subquery nelle policy RLS evita questo problema.
Monitorare l'Impatto sulle Performance
Le policy RLS aggiungono condizioni WHERE a ogni query, il che può impattare le performance se non si hanno gli indici corretti. Le colonne usate nelle policy (tipicamente tenant_id, owner_id, client_id) devono essere indicizzate. Analizzare periodicamente i query plan con EXPLAIN ANALYZE per verificare che gli indici vengano effettivamente usati.
Domande Frequenti
Cos'è il Row Level Security?
Il Row Level Security è un meccanismo di PostgreSQL (e altri database enterprise) che filtra automaticamente le righe accessibili in base all'identità dell'utente. Ogni tabella può avere policy che specificano chi può vedere o modificare quali righe. Opera indipendentemente dal codice applicativo, creando un secondo livello di difesa contro bug e attacchi.
RLS è sufficiente per proteggere i dati?
RLS è uno strumento potente e fondamentale, ma va usato in una strategia di sicurezza complessiva: autenticazione robusta, validazione input, cifratura dei dati sensibili, audit logging e monitoring. Da solo non sostituisce una progettazione sicura, ma aggiunge un layer di protezione critico che garantisce l'isolamento dei dati anche in presenza di bug applicativi.
V Support usa RLS per proteggere i dati dei clienti?
Sì. V Support usa PostgreSQL tramite Supabase con RLS abilitato su tutte le tabelle contenenti dati dei clienti. Le policy implementano un modello gerarchico: i proprietari account vedono tutti i dati dei propri clienti, i clienti vedono solo le proprie risorse, gli utenti anonimi accedono solo ai widget pubblici. Il database garantisce questo isolamento indipendentemente dal codice applicativo.
Termini Correlati
Implementa RLS - Row Level Security nella Tua Azienda
Scopri come V Support può aiutarti a sfruttare l'AI per il tuo customer service. Demo gratuita di 30 minuti.