Che cos'è la sicurezza a livello di riga?

La sicurezza a livello di riga (RLS) è un controllo degli accessi al database che limita quali righe di una tabella un utente può leggere o modificare in base alla propria identità, al ruolo o al contesto della sessione.

Invece di limitare l'accesso a intere tabelle o a colonne specifiche, la RLS filtra i dati riga per riga. Il motore del database applica il filtro automaticamente al momento della query, quindi la stessa regola vale indipendentemente dallo strumento utilizzato dall'utente per accedere ai dati.

La RLS fa parte del controllo degli accessi granulare, insieme a:

• Sicurezza a livello di colonna
• Mascheramento dei dati
• Autorizzazioni a livello di tabella

Ad esempio, un addetto alle vendite può eseguire una query sulla tabella degli ordini dell'azienda ma visualizzare solo gli ordini per la regione assegnata, anche se la tabella contiene i dati di tutte le regioni. L'utente scrive una normale istruzione SELECT e il motore restituisce solo le righe che è autorizzato a vedere.

La RLS è oggi un elemento fondamentale per il SaaS multi-tenant, la segregazione dei dati regionali e i casi d'uso di conformità. Questo articolo spiega come funziona la RLS, dove è utile, quali sono i suoi limiti e come funziona sulla piattaforma Databricks.

Come funziona la sicurezza a livello di riga?

La sicurezza a livello di riga funziona applicando a una tabella una regola di filtro, spesso chiamata policy o predicato. Quando un utente esegue una query, il motore del database applica automaticamente tale filtro e restituisce solo le righe che l'utente è autorizzato a visualizzare.

In pratica, la RLS funziona solitamente in tre passaggi:

1. L'utente esegue una query: l'utente scrive una query standard senza aggiungere autonomamente alcun filtro di sicurezza.
2. Il database verifica l'identità dell'utente: il motore valuta l'utente tramite una funzione integrata come CURRENT_USER, una variabile di sessione impostata dall'applicazione o una tabella di mappatura che collega utenti e gruppi ai dati consentiti.
3. Il motore filtra il risultato: il predicato RLS restituisce TRUE per le righe che l'utente può visualizzare e FALSE per tutto il resto. Vengono restituite solo le righe che superano il predicato.

Poiché l'applicazione avviene a livello di database, la stessa regola si applica in modo coerente a ogni percorso di acesso, inclusi dashboard BI, notebook, SQL ad-hoc, API e strumenti di terze parti. Questa coerenza è ciò che rende potente la RLS: una sola regola, applicata ovunque, imposta dal motore.

La maggior parte dei motori distingue anche tra applicazione lato lettura e lato scrittura. Un predicato di lettura controlla ciò che restituisce una query SELECT. Un predicato di scrittura, spesso definito separatamente con una clausola WITH CHECK, controlla quali righe un utente può inserire, aggiornare o eliminare.

I due predicati possono essere uguali, ma non devono necessariamente esserlo. Ad esempio, a un utente potrebbe essere consentito di leggere le righe di tutte le regioni ma di inserire solo le righe della propria regione. Definire entrambi i lati è importante quando una tabella accetta scritture, perché saltare il controllo di scrittura è uno dei modi più comuni in cui i team configurano in modo errato la RLS in produzione.

Sicurezza a livello di riga vs sicurezza a livello di colonna e altri controlli degli accessi

La RLS è uno dei diversi controlli degli accessi granulari e in produzione è quasi sempre abbinata ad altri. La tabella seguente mostra come si inserisce ciascun controllo.

Questi controlli sono progettati per essere stratificati. Una configurazione tipica utilizza autorizzazioni a livello di tabella per controllare chi può accedere a una tabella, la RLS per definire quali righe sono visibili e la sicurezza a livello di colonna o il mascheramento dei dati per proteggere i campi sensibili all'interno di tali righe. Considerarli come uno stack piuttosto che come un menu di alternative rende la governance sia verificabile che resiliente. Una configurazione errata in un livello non compromette gli altri.

Casi d'uso comuni per la sicurezza a livello di riga

La RLS è il modo standard per imporre chi può vedere cosa all'interno di una tabella condivisa, filtrando le righe in base agli attributi di un utente rispetto a una colonna chiave come regione, tenant o classificazione. La maggior parte dei team vi ricorre quando un singolo dataset deve servire più destinatari con regole di visibilità diverse.

• SaaS multi-tenant: isola i dati di ciascun cliente all'interno di tabelle condivise utilizzando una colonna tenant_id e il contesto della sessione. Ciò evita il costo operativo di uno schema o di un database per tenant, mantenendo i dati di ciascun cliente completamente separati al momento della query.
• Segregazione regionale: limita i dati sulle vendite, sulle risorse umane (HR) o sugli ordini in modo che gli utenti vedano solo i record relativi al proprio paese o alla propria regione, senza dividere la tabella sottostante in base alla geografia.
• Accesso dipartimentale: consente ai team di finanza, marketing e operations di accedere alla stessa tabella ma a righe diverse, mappate da una colonna relativa al reparto o al centro di costo.
• Conformità normativa: applica le regole di residenza dei dati, ad esempio mantenendo i record dell'UE visibili solo al personale con sede nell'UE ai sensi del GDPR, o limitando le categorie protette ai sensi di HIPAA, CCPA o normative specifiche del settore.
• Dati sanitari e clinici: consente ai medici di condividere una tabella dei pazienti visualizzando solo i propri pazienti, supportando l'accesso minimo necessario previsto dall'HIPAA senza duplicare i record tra i vari silos.
• Portali per partner e fornitori: condividi un unico dataset tra partner esterni filtrando ciascuno in base ai propri record, in modo che una sola tabella come unica fonte di verità possa alimentare decine di viste rivolte ai partner.

Come implementare la sicurezza a livello di riga: 4 passaggi

Il modello generale è coerente tra le varie piattaforme, con l'inserimento della sintassi specifica del fornitore dove necessario.

1. Identificare la logica del filtro: stabilire cosa determina l'accesso: ID utente, appartenenza a un gruppo, regione, ID tenant o una tabella di mappatura. La logica del filtro deve essere derivabile dal contesto della sessione o da una ricerca stabile, non da valori controllati dall'utente al momento della query.
2. Aggiungere o confermare la colonna chiave: assicurarsi che la tabella contenga una colonna utilizzabile dal filtro, come tenant_id, region o owner_id. Se tale colonna non esiste ancora, pianificare un backfill prima che la policy diventi attiva e valutare l'indicizzazione della colonna per mantenere il predicato economico.
3. Definire la policy o il filtro di riga: scrivere il predicato che restituisce TRUE per le righe che l'utente è autorizzato a visualizzare e un controllo separato per le scritture se la tabella le accetta. Se possibile, mantenere la logica in SQL. La maggior parte dei motori ottimizza i predicati SQL meglio delle chiamate di funzione in altri linguaggi.
4. Testare con più identità utente: eseguire query con ruoli diversi e confermare che vengano visualizzate le righe corrette e che non vi siano fughe di dati tra i tenant. Includere un test negativo: un utente senza righe corrispondenti dovrebbe vedere un risultato vuoto, non un errore, e un utente con privilegi elevati dovrebbe essere testato separatamente per confermare il comportamento di bypass del proprietario.

Vantaggi della sicurezza a livello di riga

Spostare la logica di accesso nel livello dati offre diversi vantaggi pratici. In breve, il database diventa l'unica fonte di verità per l'accesso, anziché ogni singola applicazione che tocca i dati.

• Logica centralizzata: le regole di accesso risiedono con i dati, anziché essere sparse nel codice dell'applicazione o negli strumenti di BI.
• Applicazione coerente: si applica la stessa regola indipendentemente dal fatto che un utente esegua una query da un notebook, da una dashboard o da un'API.
• Difesa in profondità: la RLS aggiunge un secondo livello di protezione nel caso in cui i controlli a livello di applicazione vengano aggirati o presentino bug.
• Codice dell'applicazione più semplice: gli sviluppatori non devono aggiungere manualmente clausole WHERE in ogni query.
• Audit più semplici: i team di conformità possono esaminare una sola policy invece di tracciare la logica di accesso tra i vari sistemi.
• Onboarding più rapido per i nuovi strumenti: un nuovo strumento di BI o ambiente notebook eredita le regole a livello di riga esistenti senza richiedere attività di integrazione personalizzate.

Limitazioni e rischi della sicurezza a livello di riga

La RLS è potente, ma presenta alcune insidie ben note che i team dovrebbero pianificare. La maggior parte di queste emerge solo in produzione o durante un audit, il che rende utile conoscerle in anticipo.

Bypass di amministratori e proprietari

In molti database, i proprietari delle tabelle e gli amministratori con privilegi elevati bypassano la RLS per impostazione predefinita. PostgreSQL, ad esempio, richiede l'impostazione FORCE ROW LEVEL SECURITY per applicare i criteri al proprietario della tabella, e impostazioni simili esistono in altri motori. Questo è un riscontro comune negli audit: presupponi che gli utenti con privilegi vedano ogni riga, a meno che la configurazione non imponga esplicitamente l'applicazione del criterio anche a loro. Testa il criterio da una sessione con privilegi, non solo da una normale, prima di approvarlo.

Nessun oscuramento di colonne o riepiloghi

La RLS filtra le righe, ma non nasconde le colonne né blocca i risultati aggregati. Un analista a cui è impedito di vedere i singoli record dell'EU può comunque eseguire SELECT COUNT(*) sulla tabella non filtrata se la RLS non è associata a restrizioni sulle colonne o sulle aggregazioni. Associa la RLS alla sicurezza a livello di colonna o al data masking per colmare questa lacuna, e valuta se le query aggregate stesse debbano essere regolate per le tabelle più sensibili.

Impatto sulle prestazioni

A ogni query viene applicato il predicato RLS, il che può rallentare le prestazioni se la logica del filtro è complessa o se la colonna chiave non è indicizzata. Indicizza le colonne a cui fa riferimento il criterio e mantieni il predicato il più semplice possibile. Preferisci espressioni CASE lineari rispetto a sottoquery o ricerche in tabelle di mappatura all'interno del filtro. Se il motore lo supporta, materializza la mappatura utente-righe in una tabella piccola e ben indicizzata anziché calcolarla al volo.

Complessità del debug

I set di risultati vuoti causati dalla RLS sembrano identici a "nessun dato corrispondente". Gli sviluppatori alla ricerca di una riga mancante spesso passano ore prima di rendersi conto che il criterio l'ha filtrata. Registra l'identità dell'utente effettiva e la versione del criterio durante lo sviluppo, offri agli ingegneri un modo per verificare se la RLS è attiva quando i risultati sembrano errati e documenta il criterio nello stesso posto dello schema della tabella in modo che sia facilmente individuabile.

Regole di scrittura configurate in modo errato

I criteri RLS hanno spesso due lati: una clausola USING che filtra ciò che gli utenti possono leggere e una clausola WITH CHECK che controlla ciò che possono inserire o aggiornare. Definire l'una senza l'altra è un errore classico: il filtraggio in lettura senza controllo in scrittura consente agli utenti di inserire o aggiornare righe di cui non dovrebbero essere proprietari. Definisci sempre entrambi i lati quando la tabella accetta scritture ed esegui un test sul lato scrittura come parte della revisione del criterio.

Sicurezza a livello di riga sulla piattaforma Databricks

Sulla piattaforma Databricks, la sicurezza a livello di riga viene gestita tramite filtri di riga in Unity Catalog, il livello di governance unificato di Databricks per dati e IA. Il pattern è semplice: definisci una funzione definita dall'utente SQL che restituisce true per le righe che un determinato utente è autorizzato a vedere, quindi associala alla tabella di destinazione. Il filtro viene eseguito automaticamente al momento della query, utilizzando l'identità dell'utente corrente o il contesto di sessione per determinare quali righe restituire.

I filtri di riga vengono applicati in modo coerente in Databricks SQL, notebook, job e strumenti di BI connessi, senza richiedere logica personalizzata per ciascuna interfaccia. Funzionano insieme alle maschere di colonna per un controllo completo dell'accesso granulare, e ogni query che interessa una tabella filtrata viene acquisita nei log di lineage e di audit di Unity Catalog, in modo che i team di governance e sicurezza possano vedere esattamente quali criteri si applicano a quali tabelle e quali utenti hanno eseguito query su cosa.

Domande frequenti

Cos'è la sicurezza dinamica a livello di riga? La RLS dinamica valuta la regola di accesso al momento della query utilizzando l'identità dell'utente corrente o il contesto di sessione, in modo che lo stesso criterio restituisca risultati diversi per utenti diversi. Tutte le moderne implementazioni di RLS funzionano in questo modo, inclusi i criteri ABAC di Databricks, i filtri di riga e le viste dinamiche.

Qual è la differenza tra la sicurezza a livello di riga e la sicurezza a livello di colonna? La RLS limita le righe che un utente può vedere; la sicurezza a livello di colonna limita le colonne, in genere per nascondere campi sensibili come lo stipendio o i numeri di previdenza sociale. La maggior parte delle distribuzioni in produzione utilizza entrambe le soluzioni insieme.

La sicurezza a livello di riga è sufficiente da sola per proteggere i dati sensibili? No. La RLS gestisce la visibilità delle righe ma non maschera i valori delle colonne, non blocca le query aggregate né sostituisce la gestione delle identità e degli accessi. Associala alla sicurezza a livello di colonna, alle autorizzazioni a livello di tabella e alla registrazione degli audit come parte di una strategia di difesa approfondita.

In che modo Databricks implementa la sicurezza a livello di riga? Tramite Unity Catalog, con tre opzioni: criteri ABAC, filtri di riga a livello di tabella e viste dinamiche. L'ABAC è consigliato per la governance su larga scala; i filtri di riga e le viste dinamiche sono disponibili per esigenze più personalizzate.

La sicurezza a livello di riga influisce sulle prestazioni delle query? Sì, ma l'impatto è solitamente gestibile. Mantieni semplice la logica dei criteri, indicizza le colonne a cui fa riferimento il criterio e preferisci le UDF SQL rispetto alle UDF Python. Analizza il profilo delle query prima e dopo le modifiche ai criteri per individuare tempestivamente eventuali regressioni.

Inizia a utilizzare il controllo dell'accesso granulare su Databricks

La sicurezza a livello di riga è più efficace se inserita in un modello di governance più ampio che copre anche colonne, mascheramento, lineage e audit. Scopri come Unity Catalog unisce la sicurezza a livello di riga, il mascheramento delle colonne e la governance unificata sulla piattaforma Databricks.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale