Che cos’è la sicurezza a livello di riga (RLS)?
La sicurezza a livello di riga (RLS) è progettata per limitare le righe che i singoli utenti o ruoli possono recuperare da un database, contribuendo a far rispettare i confini dei dati all’interno delle tabelle condivise in base all’identità, al ruolo o agli attributi contestuali, senza duplicare i dati.
Punti di forza
Controllo dell’accesso ai dati su larga scala
La sicurezza a livello di riga è progettata per aiutare a controllare l’accesso ai dati a livello di record, consentendo un controllo granulare su piattaforme condivise senza modifiche allo schema, duplicazione dei dati o dipendenza da filtri di query applicati dall’utente.
Definizione della sicurezza a livello di riga (RLS): l’RLS consente di limitare le righe che un utente o un ruolo può recuperare da un database, garantendo un isolamento granulare dei dati all’interno di tabelle condivise senza duplicare i set di dati né ristrutturare gli schemi.
Fondamentale per la conformità: GDPR, HIPAA, CCPA e PCI DSS richiedono controlli di accesso dimostrabili a livello di record. L’RLS è progettato per applicare i controlli di accesso al momento della query, limitando automaticamente i risultati ai soli record autorizzati.
Approcci nativi vs. centralizzati: alcuni database offrono controlli nativi a livello di riga, ma gestirli su larga scala su più archivi di dati può causare una proliferazione delle politiche, costi di manutenzione e lacune nella visibilità.
Basato su policy e sensibile all’identità: il moderno RLS collega le decisioni di accesso agli attributi del provider di identità, consentendo controlli dinamici e sensibili al contesto che rispondono alle modifiche relative a utenti, gruppi e attributi senza necessità di modificare lo schema.
Gestione centralizzata su più piattaforme: un livello di sicurezza centralizzato aiuta ad applicare le politiche a livello di riga in modo coerente su data warehouse, database cloud e data lake, da un unico motore di politiche anziché tramite configurazioni per singolo database.
Non sono necessarie viste sicure: l’RLS basato su piattaforma contribuisce a ridurre la dipendenza dalle viste sicure, eliminando le penalizzazioni nell’ottimizzazione delle query e consentendo al contempo controlli più sofisticati, combinando restrizioni a livello di riga e di colonna in un’unica politica.
Risk di divulgazione dei dati
Perché la sicurezza a livello di riga è importante
Le violazioni dei dati costano alle organizzazioni in media4,44 milioni di dollari nel 2025â e l’accesso ai dati con autorizzazioni eccessive rimane una delle cause. RLS contribuisce a colmare il divario tra ciò a cui gli utenti possono accedere e ciò a cui dovrebbero accedere, applicando dei limiti a livello di record prima che i dati non autorizzati escano dal database.
In che modo RLS garantisce l’accesso con il minimo privilegio?
Nelle organizzazioni in cui più team, regioni o unità aziendali condividono piattaforme di dati, le autorizzazioni a livello di tabella tendono ad essere troppo generiche. L’RLS è progettato per applicare il principio del privilegio minimo a livello di record, in modo che:
- Un team di vendita regionale può consultare solo i dati relativi al proprio territorio.
- Un operatore sanitario può visualizzare solo i propri pazienti
- Un analista può recuperare solo le righe autorizzate dal proprio ruolo.
Questo livello di granularità contribuisce a ridurre l’impatto della compromissione delle credenziali e aiuta a prevenire la divulgazione interna dei dati senza richiedere modifiche allo schema o la duplicazione dei dati.
In che modo RLS contribuisce al rispetto dei requisiti di conformità?
Il GDPR, l’HIPAA, il CCPA e lo standard PCI DSS richiedono controlli dimostrabili relativi agli utenti autorizzati ad accedere a dati personali e sensibili. RLS contribuisce a garantire l’applicazione delle norme già al momento della query — limitando automaticamente i risultati ai dati autorizzati — e aiuta a generare la traccia di audit richiesta dalle autorità di regolamentazione. Le organizzazioni operanti nei settori dei servizi finanziari, della sanità e della gestione dei dati aziendali possono affidarsi a RLS per mantenere la conformità senza dover ristrutturare i dati o replicare set di dati sensibili.
In che modo RLS si adatta agli ambienti con più negozi?
La maggior parte delle organizzazioni gestisce i dati su più piattaforme, ciascuna con le proprie implementazioni RLS. I controlli nativi funzionano in genere all’interno di una singola piattaforma, ma causano una frammentazione delle politiche tra i diversi ambienti. Un livello di sicurezza centralizzato è progettato per applicare politiche di accesso coerenti a livello di riga in tutti gli archivi dati da un unico punto di controllo — contribuendo a ridurre i costi di manutenzione e a mantenere la conformità man mano che lo stack di dati si evolve.
Concetti fondamentali
Come funziona la sicurezza a livello di riga
La RLS contribuisce a limitare i risultati delle query valutando le condizioni di accesso al momento dell’esecuzione – filtrando le righe in base all’identità, al ruolo o agli attributi dell’utente richiedente – prima di restituire i risultati. Le implementazioni spaziano dai meccanismi nativi del database a livelli di policy centralizzati che si applicano in modo coerente su più piattaforme di dati.
Filtraggio delle righe esplicito e implicito
La RLS viene implementata in due modalità fondamentali: esplicita e implicita. L’applicazione esplicita richiede agli utenti di includere condizioni di filtro in ogni query, rendendo la conformità dipendente dal comportamento dell’utente e creando un rischio quando i filtri vengono omessi. L’applicazione implicita applica il filtraggio automaticamente tramite viste sicure, politiche di accesso alle righe o un livello di sicurezza della piattaforma, in modo che gli utenti ricevano solo le righe a cui sono autorizzati ad accedere, indipendentemente da come è scritta la query.
L’applicazione implicita è lo standard per gli ambienti di produzione che richiedono un controllo degli accessi affidabile e verificabile.
Politiche di accesso alle righe di Snowflake
Snowflake implementa l’RLS tramite le politiche di accesso alle righe (RAP), oggetti a livello di schema creati una sola volta e associati a una o più tabelle o viste. Al momento della query, Snowflake racchiude l’oggetto protetto in una vista sicura dinamica, valuta il corpo della politica rispetto ai valori effettivi delle righe e restituisce solo le righe in cui l’espressione è TRUE. Le RAP richiedono l’Enterprise Edition o versioni superiori e vengono eseguite con il ruolo del proprietario della politica – non con quello dell’utente che esegue la query – contribuendo a prevenire l’escalation dei privilegi. Le RAP si combinano con il mascheramento dinamico dei dati (Dynamic Data Masking) per consentire la protezione simultanea a livello di riga e di colonna sulla stessa tabella.
RLS centralizzato e multipiattaforma
I meccanismi RLS nativi – viste protette, politiche di accesso a livello di riga, database privati virtuali – possono essere efficaci all’interno di un singolo archivio dati, ma possono creare frammentazione in ambienti multipiattaforma. Un livello di sicurezza centralizzato consente di applicare le politiche a livello di riga in tutti i data store da un unico motore di politiche, utilizzando gli attributi dei provider di identità di Okta o di altri provider per prendere decisioni di accesso in modo dinamico. Ciò riduce la necessità di replicare le mappature utente-riga in ogni database e contribuisce a garantire un’applicazione coerente indipendentemente dalla piattaforma dati interrogata.
Nella pratica
Casi d’uso della sicurezza a livello di riga
Le organizzazioni operanti nei settori dei servizi finanziari, della sanità e dell’analisi aziendale possono applicare l’RLS per aiutare a far rispettare i limiti dei dati, proteggere i record sensibili e soddisfare i requisiti normativi in ambienti dati condivisi e multi-tenant.
Isolamento regionale dei dati per le vendite e l’analisi
Gli istituti finanziari che gestiscono dati di vendita, registrazioni dei conti dei clienti e cronologie delle transazioni dovrebbero limitare l’accesso per unità aziendale, regione o ruolo senza dover ristrutturare le piattaforme di dati condivise. La RLS è progettata per far rispettare i confini dei dati al momento della query, in modo che analisti e rappresentanti di vendita recuperino solo i record autorizzati dal loro ruolo. Inoltre, aiuta i team di conformità a mantenere le tracce di audit per i requisiti GDPR, CCPA e PCI DSS senza duplicare set di dati sensibili in più copie soggette a restrizioni.
Accesso alle cartelle cliniche dei pazienti per operatore sanitario e reparto
Le organizzazioni sanitarie che gestiscono cartelle cliniche elettroniche devono applicare controlli di accesso conformi all’HIPAA, in modo che gli operatori sanitari accedano solo alle cartelle dei propri pazienti, i reparti vedano solo i casi rilevanti e i ricercatori ricevano solo dati anonimizzati. RLS aiuta ad applicare questi limiti al momento della query senza richiedere copie separate dei dati per ogni livello di accesso. In combinazione con il mascheramento dei dati a livello di colonna, RLS consente di eseguire analisi e carichi di lavoro di intelligenza artificiale sui dati di produzione senza compromettere la privacy dei pazienti né gli obblighi previsti dall’HIPAA.
Condivisione sicura dei dati multi-tenant e tra team
Le piattaforme dati aziendali al servizio di più unità aziendali, partner esterni o carichi di lavoro multi-tenant richiedono in genere garanzie di isolamento dei dati all’interno dell’infrastruttura condivisa. RLS contribuisce a limitare ogni tenant, team o partner ai record autorizzati all’interno delle tabelle condivise, contribuendo a ridurre i set di dati duplicati e la separazione fisica dei dati. Un livello di sicurezza centralizzato aiuta ad applicare queste politiche in modo coerente nei data warehouse e nei data lake cloud man mano che la piattaforma si espande.
Domande frequenti
Che cos’è la sicurezza a livello di riga (RLS)?
L’RLS è un metodo di controllo dell’accesso ai dati progettato per limitare le righe che un utente, un ruolo o un gruppo può recuperare da una tabella del database in base a condizioni legate all’identità, al ruolo o agli attributi contestuali del richiedente. A differenza delle autorizzazioni a livello di tabella, l’RLS contribuisce a far rispettare i limiti di accesso a livello di singolo record, consentendo a utenti diversi che eseguono query sulla stessa tabella di ricevere sottoinsiemi diversi di righe in base alla loro autorizzazione. Può rappresentare una funzionalità fondamentale per l’isolamento dei dati in piattaforme condivise, ambienti multi-tenant e carichi di lavoro con dati soggetti a normative.
Qual è la differenza tra la sicurezza a livello di riga e quella a livello di colonna?
La sicurezza a livello di riga (RLS) è progettata per limitare i record che un utente può recuperare da una tabella, filtrando i risultati in base all’identità o al ruolo. La sicurezza a livello di colonna (mascheramento dei dati) aiuta a limitare quali campi all’interno di tali record l’utente possa visualizzare, nascondendo o oscurando i valori sensibili agli utenti non autorizzati. I due meccanismi sono complementari: la RLS aiuta a controllare l’accesso a livello di record, mentre la sicurezza a livello di colonna aiuta a controllare la visibilità a livello di campo all’interno dei record a cui l’utente è autorizzato ad accedere. Molte organizzazioni applicano entrambi contemporaneamente per garantire una protezione dei dati a più livelli in ambienti regolamentati.
In che modo Snowflake implementa l’RLS?
Snowflake fornisce l’RLS tramite le Row Access Policies (RAP), ovvero oggetti a livello di schema disponibili nella versione Enterprise Edition o successive. Ogni RAP definisce un’espressione BOOLEANA; al momento dell’esecuzione della query, Snowflake racchiude l’oggetto protetto in una vista sicura dinamica, valuta il corpo della policy e restituisce solo le righe in cui l’espressione è TRUE. Le RAP vengono eseguite con il ruolo del proprietario della policy, non con quello dell’utente che esegue la query, contribuendo a prevenire l’escalation dei privilegi. Le RAP sono riutilizzabili su più tabelle e si combinano con il Dynamic Data Masking per garantire una protezione simultanea a livello di riga e di colonna sulla stessa tabella.
Quali sono i limiti dell’RLS nativo su larga scala?
I meccanismi RLS nativi sono in genere efficaci all’interno delle rispettive piattaforme, ma possono causare una frammentazione delle politiche in ambienti con più archivi dati. Ogni archivio dati richiede una propria configurazione e manutenzione delle politiche. Gli approcci basati su “secure view” comportano un rallentamento nell’ottimizzazione delle query. Le mappature tra ruoli e righe dovrebbero rimanere sincronizzate con le modifiche apportate dal provider di identità. In ambienti con più archivi dati o un numero elevato di ruoli, i sistemi RLS nativi possono diventare operativamente complessi da mantenere in modo coerente lungo l’intero stack di dati.
In che modo Commvault supporta l’RLS?
Le funzionalità di sicurezza dei dati e di IA di Commvault consentono di applicare in modo centralizzato le politiche RLS su più archivi di dati — inclusi data warehouse nel cloud, database on-premise e data lake — da un unico livello di policy. Le politiche a livello di riga utilizzano gli attributi di identità provenienti da provider di identità collegati, come Okta, consentendo decisioni di accesso dinamiche e basate sugli attributi senza richiedere la sincronizzazione dei ruoli del database. Le politiche vengono applicate in modo coerente su tutte le piattaforme dati presenti nell’ambiente, con la registrazione degli eventi di accesso a fini di audit e la classificazione automatica per aiutare a identificare quali righe contengono dati sensibili.
In che modo l’RLS contribuisce alla conformità normativa?
Il GDPR, l’HIPAA, il CCPA e lo standard PCI DSS richiedono controlli dimostrabili su quali utenti possano accedere ai dati personali, sanitari e finanziari. RLS è progettato per supportare direttamente la conformità, contribuendo a far rispettare i limiti di accesso al momento della consultazione: in questo modo, gli utenti non autorizzati non ricevono i dati a cui non dovrebbero accedere, in modo automatico e senza dover ricorrere a filtri di consultazione applicati dall’utente. Registri di audit completi relativi agli eventi di accesso consentono di identificare chi ha interrogato quali dati e quando, fornendo così le prove richieste dai revisori e riducendo lo sforzo necessario per la rendicontazione di conformità.
classificazione dei dati
Gestione delle identità e degli accessi (IAM)
