Che cos'è la sicurezza a livello di riga (RLS)?

La sicurezza a livello di riga è un meccanismo del database in cui delle policy filtrano, a ogni query, le righe che ciascuno può vedere o modificare. Il modello mentale è quello di una clausola WHERE invisibile e obbligatoria: la condizione che altrimenti andrebbe ricordata in ogni query diventa una proprietà della tabella stessa – applicata dal motore, su ogni percorso di accesso, compresi quelli che il codice applicativo non vede mai.

Punti chiave

RLS in dieci righe di SQL

CREATE TABLE invoices (
  tenant_id uuid NOT NULL,
  total     numeric(10,2)
);

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;   -- da qui: rifiuto predefinito

CREATE POLICY tenant_isolation ON invoices
  USING      (tenant_id = current_setting('app.tenant')::uuid)   -- ciò che si può leggere
  WITH CHECK (tenant_id = current_setting('app.tenant')::uuid);  -- ciò che si può scrivere

-- Ogni query ora si comporta come se finisse con WHERE tenant_id = <il proprio>.
-- Una query che dimentica il filtro non restituisce nulla – non tutto.

La stessa garanzia esiste nei database documentali come controllo degli accessi portato dalla riga stessa – ogni oggetto porta la propria ACL, e la piattaforma la fa rispettare a ogni richiesta:

// JavaScript / Node.js — Back4app JS SDK
// Row-level security as data: this row is readable by its owner, period
const note = new Parse.Object('Note');
note.set('text', 'Q3 salary planning');
note.setACL(new Parse.ACL(Parse.User.current())); // owner-only, on the row itself
await note.save();

// Later, any query by any user — the row exists only for its owner
const notes = await new Parse.Query('Note').find(); // others never see it

// Flutter / Dart — Back4app Flutter SDK
// Row-level security as data: this row is readable by its owner, period
final user = await ParseUser.currentUser() as ParseUser;
final acl = ParseACL(owner: user); // owner-only, on the row itself

final note = ParseObject('Note')
  ..set('text', 'Q3 salary planning')
  ..setACL(acl);
await note.save(); // other users' queries never return this row

// iOS / Swift — Back4app Swift SDK
// Row-level security as data: this row is readable by its owner, period
var note = Note()
note.text = "Q3 salary planning"
note.ACL = try ParseACL.defaultACL() // owner-only, on the row itself
note.save { result in
  if case .success = result {
    print("saved — other users' queries never return this row")
  }
}

// Android / Kotlin — Back4app Android SDK
// Row-level security as data: this row is readable by its owner, period
val note = ParseObject("Note").apply {
  put("text", "Q3 salary planning")
  acl = ParseACL(ParseUser.getCurrentUser()) // owner-only, on the row itself
}
note.saveInBackground { e ->
  if (e == null) Log.d("Notes", "saved — invisible to every other user")
}

Che cosa fa il motore con una query

USING vs. WITH CHECK, policy permissive vs. restrittive

Due regole di composizione da ricordare dalla documentazione di PostgreSQL: omettere WITH CHECK riusa USING per le scritture, e almeno una policy permissiva deve passare prima che le restrittive vengano perfino consultate – solo policy restrittive significa che non entra nessuno.

Dove RLS è supportata

L’ultima riga è quella che interessa a questo glossario: sugli archivi documentali il confine a livello di riga è tipicamente un dato portato dalla riga (le ACL) invece di un predicato nel motore – stessa garanzia, meccanismo diverso, spiegato in dettaglio nell’articolo di ingegneria di Back4app.

Le insidie, finalmente in un unico posto

• Le sorprese del rifiuto predefinito. Abilitare RLS senza nessuna policy blocca tutti tranne il proprietario – metà delle storie “RLS ha rotto la produzione” è questa.
• La matrice di aggiramento. Superutenti, ruoli BYPASSRLS e proprietari delle tabelle ignorano le policy – conviene impostare FORCE ROW LEVEL SECURITY se il proprietario è anche l’utente dell’applicazione, e verificare chi detiene cosa.
• Le viste si eseguono con i diritti del proprietario per impostazione predefinita – una vista su una tabella con RLS può aggirarlo silenziosamente, a meno che non sia creata con i diritti del chiamante (security_invoker in PostgreSQL).
• I vincoli tradiscono l’esistenza. Una violazione di unicità o di chiave esterna può rivelare che esiste una riga invisibile – il canale nascosto documentato; l’unicità sui valori protetti va trattata di conseguenza.
• Gli errori possono tradire i valori. Espressioni costruite per fallire su dati precisi (una divisione per zero quando un valore nascosto corrisponde) esfiltrano attraverso i messaggi di errore – la classe di canali laterali descritta dalla documentazione di SQL Server.
• Dump e pool hanno delle modalità. Gli strumenti di backup possono richiedere la disattivazione della sicurezza per riga per esportare tutto; i pooler in modalità transazione richiedono un contesto con portata di transazione (SET LOCAL), altrimenti i tenant si mescolano da una richiesta all’altra.

Prestazioni: le policy sono codice sull’hot path

Tre regole coprono quasi tutta l’esperienza di campo: indicizzare ogni colonna a cui una policy fa riferimento (il predicato viene eseguito prima dei filtri propri della query – senza indice è una scansione completa); tenere i predicati senza join, spostando le ricerche in funzioni o in controlli di ruolo; e far valutare le funzioni per richiesta una volta per query, non una volta per riga, avvolgendole in una sottoquery scalare. Misurata bene, RLS costa qualche punto percentuale; misurata male, è il rallentamento misterioso su ogni tabella messa in sicurezza.

Casi d’uso tipici

• SaaS multi-tenant. Il caso canonico – l’isolamento dei tenant applicato sotto l’applicazione, dove un filtro dimenticato non può diventare una violazione.
• Dati per utente. Messaggi, documenti, cartelle cliniche: ciascuno vede le proprie righe, punto.
• Confini fra reparti e fra regioni. I commerciali vedono la propria regione; i revisori vedono tutto, in sola lettura – la stratificazione delle policy all’opera.
• Regimi di conformità. Controllo degli accessi dimostrabile al livello dei dati, che è dove piace ai revisori.
• Accesso analitico condiviso. Chi fa analisi interroga direttamente le repliche di produzione e vede solo ciò che il proprio ruolo consente – sicuro perché è il database a farlo rispettare, non la dashboard.

Conviene applicare il controllo a livello di riga? Matrice decisionale

La sintesi onesta delle due colonne: tenere il partizionamento nell’applicazione per leggibilità – e farlo rispettare comunque nel database. La difesa in profondità è tutto il senso dell’operazione.

Limiti e trade-off

• Le policy sono invisibili per progetto – il che rende il debug di “dove sono finite le mie righe?” una competenza vera e propria; conviene registrare per primo il contesto di sessione.
• L’autorizzazione complessa esce dai predicati. Le regole che hanno bisogno di stato di workflow o di logica fra entità appartengono ai livelli di autorizzazione applicativi, con RLS come rete di sicurezza.
• La superficie operativa è reale. La matrice di aggiramento, le modalità di dump e il contesto di pooling sono conoscenza operativa continua, non una configurazione una volta per tutte.
• La valutazione riga per riga è una tassa – modesta quando è progettata bene, illimitata quando non lo è.
• Mette in sicurezza le righe, non le colonne. Nascondere i campi è sicurezza a livello di colonna; combinando le due si ottiene l’effetto a livello di cella.

La sicurezza a livello di riga su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il suo modello a livello di riga è il meccanismo ACL-come-dato delle schede qui sopra: ogni oggetto porta la propria lista di accessi, i ruoli esprimono tenant e team, e la piattaforma fa rispettare entrambi a ogni richiesta – SDK, REST, GraphQL e dashboard compresi, con i permessi di classe come livello restrittivo al di sopra. È la garanzia della clausola WHERE obbligatoria, consegnata su un database documentale, con l’elenco di insidie qui sopra assorbito dalla piattaforma invece di essere affidato a chi sviluppa.