Row-level security spiegata ai fondatori non tecnici

Row-level security spiegata: l'RLS è una funzione del database che filtra automaticamente ogni query, così ogni cliente può vedere solo i propri dati, anche se il codice della tua applicazione ha dei bug. Definisci la regola una volta, nel database, e non può essere aggirata. È, onestamente, il motivo per cui dormo la notte.

Se stai costruendo un SaaS con l'IA e non sei tecnico, l'RLS è l'unico concetto di sicurezza che vale davvero la pena capire. Ecco cos'è, perché batte ogni alternativa e la checklist da dare alla tua IA.

Row-level security spiegata: l'analogia del buttafuori

Immagina che il tuo database sia un archivio e che i record di ogni cliente siano cartelle al suo interno. Senza RLS la porta dell'archivio è aperta, e conti sul fatto che ogni dipendente, cioè ogni pezzo del codice della tua applicazione, si ricordi, ogni singola volta, di prendere solo le cartelle del cliente giusto. Un momento di distrazione, e qualcuno esce con i file di un concorrente.

L'RLS mette un buttafuori dentro l'archivio stesso. Il buttafuori controlla il documento di chi chiede e consegna fisicamente solo le cartelle che appartengono alla sua organizzazione. Non importa se il dipendente dimentica di chiedere correttamente o chiede tutto: il buttafuori filtra ciò che torna indietro. Ogni richiesta. Automaticamente. Senza eccezioni.

Tecnicamente: invece di far filtrare i dati alla tua applicazione ("mostra solo le righe di questo cliente"), definisci quella regola una volta, dentro il database, come policy. Da quel momento ogni query viene filtrata prima che qualsiasi dato lasci il database. È integrata in PostgreSQL, e piattaforme come Supabase ne fanno una funzione di prima classe.

Perché filtrare nel codice dell'app non basta

Ecco la scomoda verità sull'alternativa. Senza RLS, l'isolamento dei dati dipende da una persona, o da un'IA, che si ricordi di aggiungere "solo per questo cliente" in ogni singolo punto in cui il tuo prodotto tocca i dati. Centinaia di punti. Per sempre. Ogni nuova funzionalità, ogni correzione rapida, ogni modifica a tarda notte.

Le persone dimenticano. Anche l'IA dimentica: chiedile una funzione di report in un martedì stanco e potrebbe allegramente interrogare tutto. Un esempio reale dal campo: uno sviluppatore ha dimenticato di filtrare per organizzazione in un endpoint dei report. Senza RLS, avrebbe fatto trapelare dati dei clienti ai concorrenti. Con l'RLS, il database ha bloccato automaticamente l'accesso non autorizzato. Nessuno se n'è accorto fino alla revisione del codice, perché non è successo niente di male.

Gli esperti di sicurezza lo chiamano defense in depth: non affidarti a un solo livello perfetto. Il codice della tua app filtra i dati (primo livello) e l'RLS lo impone nel database (secondo livello). Se il primo livello fallisce, per un bug, un prompt sbagliato, un'allucinazione dell'IA, il secondo tiene. Conta il doppio quando l'IA scrive la maggior parte del tuo codice, perché il codice generato dall'IA fallisce in modi che non noterai finché non costa caro.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

I quattro permessi di cui ogni tabella ha bisogno

Le policy RLS sono di quattro tipi, una per ogni cosa che un utente può fare con i dati. Pensale come quattro domande che pone il buttafuori:

Ogni tabella che contiene dati dei clienti le ha tutte e quattro. Questo è l'intero sistema: l'etichetta organization_id su ogni tabella dice chi possiede ogni riga; le quattro policy fanno sì che il database lo faccia rispettare.

Come ho imparato l'RLS (da Claude)

Sarò onesto: non ho imparato l'RLS da un corso di sicurezza. L'ho imparato da Claude. Quando ho iniziato con Supabase ho chiesto: "Come faccio ad avere la certezza che gli utenti vedano solo i dati della propria organizzazione?" Claude mi ha spiegato le policy RLS. Le ho implementate su ogni tabella. Ora è automatico.

È questo il punto per i fondatori non tecnici: non scrivi queste policy a mano. Capisci il concetto, il buttafuori nell'archivio, quattro permessi per tabella, e istruisci la tua IA: "Abilita la row-level security su ogni tabella, con policy per visualizzare, creare, aggiornare ed eliminare, limitate all'organizzazione dell'utente." L'IA produce le policy; il database le fa rispettare per sempre.

La mia piattaforma, FIKR Space, ha 964 tabelle. Tutte sono protette così. Nessuna eccezione. Quella scala è gestibile solo perché la regola è imposta dal database, non dalla mia memoria: lo stesso motivo per cui sostengo di progettare il database prima di scrivere qualsiasi funzionalità.

La checklist RLS del fondatore

Non devi scrivere una riga di SQL. Devi insistere su cinque cose:

1. RLS abilitata su ogni tabella con dati dei clienti. Chiedilo direttamente alla tua IA: "La row-level security è abilitata su tutte le tabelle? Elenca quelle dove non lo è."
2. Tutti e quattro i tipi di policy per tabella: visualizzare, creare, modificare, eliminare. Una tabella con la sola policy di visualizzazione perde comunque dati dalle scritture.
3. Policy limitate per organizzazione, coerenti con la tua configurazione multi-tenancy.
4. Testa con due account. Crea due organizzazioni di prova. Accedi come una, prova a leggere e modificare i dati dell'altra. Se torna qualcosa, fermati e correggi prima di rilasciare.
5. Ricontrolla dopo ogni nuova tabella. Fai di "abilita l'RLS con le quattro policy standard" una regola permanente che la tua IA applica a ogni tabella che crea, non qualcosa che ricordi funzionalità per funzionalità.

Il bonus è un codice dell'app più semplice: quando il database impone l'isolamento, le tue funzionalità non hanno bisogno di logica di filtro per cliente sparsa ovunque. Sicurezza di default, meno codice, e smetti di preoccuparti dell'unica query che qualcuno ha dimenticato.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

Domande frequenti

Cos'è la row-level security in parole semplici?

È una regola che definisci una volta dentro il database e che filtra automaticamente ogni query, così ogni utente vede sempre e solo le righe della propria organizzazione. Come un buttafuori dentro l'archivio: chiunque chieda e comunque lo faccia, escono solo le cartelle giuste.

Mi serve l'RLS se la mia applicazione filtra già i dati?

Sì. Il filtro applicativo dipende dal fatto che ogni pezzo di codice, scritto da persone o da IA, si ricordi il filtro, per sempre. L'RLS è la rete di sicurezza quando qualcosa dimentica: un bug nella tua app non può più diventare una violazione dei dati, perché è il database stesso a bloccare la fuga.

Posso configurare l'RLS senza conoscere SQL?

Sì. Capisci il concetto, poi istruisci la tua IA: "Abilita la row-level security su ogni tabella, con policy per visualizzare, creare, aggiornare ed eliminare, limitate all'organizzazione dell'utente." Poi verifica con due account di prova che provano a leggere i dati l'uno dell'altro. L'IA scrive le policy; tu possiedi la checklist.

L'RLS rallenta il mio prodotto?

Non in modo significativo, se le tue tabelle sono impostate bene: la chiave è avere un indice sulla colonna dell'organizzazione che le policy controllano (qualcosa da includere nelle istruzioni permanenti della tua IA). Le piattaforme con migliaia di tabelle protette girano esattamente su questo schema; FIKR Space ne gestisce 964.