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 sulla 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
Nel 2025 le violazioni dei dati costeranno alle organizzazioni in media 4,44 milioni di dollari – e l’accesso ai dati con autorizzazioni eccessive rimane una delle cause. L’RLS aiuta 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 lascino il database.
In che modo la RLS garantisce l’accesso con il privilegio minimo?
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. La RLS è progettata per applicare l’accesso secondo il principio del privilegio minimo a livello di record, in modo che:
- Un team di vendita regionale possa interrogare solo i record relativi al proprio territorio.
- Un operatore sanitario possa visualizzare solo i propri pazienti
- Un analista possa recuperare solo le righe autorizzate dal proprio ruolo.
Questa granularità contribuisce a ridurre l’entità del danno in caso di compromissione delle credenziali e aiuta a prevenire l’esposizione interna dei dati senza modifiche allo schema o duplicazione dei dati.
In che modo l’RLS aiuta a soddisfare i requisiti di conformità?
GDPR, HIPAA, CCPA e PCI DSS richiedono controlli dimostrabili su quali utenti possano accedere a record personali e sensibili. L’RLS contribuisce a garantire l’applicazione delle regole nel momento stesso della query – limitando automaticamente i risultati ai record autorizzati – e aiuta a generare le prove di audit richieste dalle autorità di regolamentazione. Le organizzazioni nei settori dei servizi finanziari, della sanità e degli ambienti di dati aziendali possono affidarsi all’RLS per mantenere la conformità senza dover ristrutturare i dati o replicare insiemi di dati sensibili.
In che modo RLS si adatta agli ambienti con più archivi?
La maggior parte delle organizzazioni gestisce i dati su più piattaforme, ciascuna con le proprie implementazioni di RLS. I controlli nativi funzionano in genere all’interno di una singola piattaforma, ma creano 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.
In pratica
Casi d’uso della sicurezza a livello di riga
Le organizzazioni che operano 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. L’RLS è progettato 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 insiemi 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 queste restrizioni al momento della query senza richiedere copie separate dei dati per ogni livello di accesso. In combinazione con la mascheratura 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)?
La 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, la RLS contribuisce a far rispettare i limiti di accesso a livello di singolo record, consentendo a diversi utenti 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 regolamentati.
Qual è la differenza tra la sicurezza a livello di riga e quella a livello di colonna?
La sicurezza a livello di riga è progettata per limitare quali record 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 può visualizzare, nascondendo o oscurando i valori sensibili per gli utenti non autorizzati. I due meccanismi sono complementari: l’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 politiche di accesso alle righe (Row Access Policies, RAP): oggetti a livello di schema disponibili nell’Enterprise Edition o nelle versioni superiori. Ogni RAP definisce un’espressione BOOLEANA; al momento della query, Snowflake racchiude l’oggetto protetto in una vista sicura dinamica, valuta il corpo della politica e restituisce solo le righe in cui l’espressione è TRUE. Le RAP 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 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 la frammentazione delle politiche in ambienti con più archivi. Ogni archivio dati richiede una propria configurazione e manutenzione delle politiche. Gli approcci basati sulle viste sicure comportano un rallentamento nell’ottimizzazione delle query. Le mappature da ruolo a riga devono rimanere sincronizzate con le modifiche apportate dal provider di identità. In ambienti con più archivi dati o un numero elevato di ruoli, l’RLS nativo può diventare operativamente complesso da mantenere in modo coerente nell’intero stack di dati.
In che modo Commvault supporta l’RLS?
Le funzionalità di sicurezza dei dati e di intelligenza artificiale di Commvault contribuiscono a garantire l’applicazione centralizzata dell’RLS su più archivi dati – inclusi data warehouse nel cloud, database on-premise e data lake – da un unico livello di policy. Le policy a livello di riga utilizzano gli attributi di identità provenienti da provider di identità collegati, come Okta, contribuendo a consentire 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 di dati presenti nell’ambiente, con la registrazione degli eventi di accesso nei log 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 a dati personali, sanitari e finanziari. L’RLS è progettato per supportare direttamente la conformità, aiutando a far rispettare i limiti di accesso al momento della query, in modo che gli utenti non autorizzati non ricevano i record a cui non dovrebbero accedere, automaticamente e senza fare affidamento su filtri di query applicati dall’utente. Registri di audit completi degli eventi di accesso aiutano a identificare chi ha interrogato quali dati e quando, per fornire le prove richieste dai revisori e ridurre lo sforzo di rendicontazione della conformità.