Che cos’è la sicurezza a livello di riga (RLS)?
Row-level security (RLS) is designed to restrict which rows individual users or roles can retrieve from a database – helping enforce data boundaries within shared tables based on identity, role, or contextual attributes, without duplicating data.
Punti di forza
Controllo dell’accesso ai dati su larga scala
Row-level security is designed to help enforce data access at the record level – enabling fine-grained control across shared platforms without schema changes, data duplication, or reliance on user-applied query filters.
Row-Level Security Defined: RLS helps restrict which rows a user or role can retrieve from a database – enabling fine-grained data isolation within shared tables without duplicating datasets or restructuring schemas.
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.
Native vs. Centralized Approaches: Some databases offer native row-level controls – but managing them at scale across multiple data stores can create policy sprawl, maintenance overhead, and visibility gaps.
Policy-Driven, Identity-Aware: Modern RLS ties access decisions to identity provider attributes – enabling dynamic, context-aware controls that respond to user, group, and attribute changes without schema modifications.
Centralized Management Across Platforms: A centralized security layer helps apply row-level policies consistently across data warehouses, cloud databases, and data lakes – from a single policy engine rather than per-database configurations.
No Secure Views Required: Platform-based RLS helps reduce dependency on secure views – removing query optimization penalties while enabling more sophisticated controls, combining row and column restrictions in one policy.
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 – and over-permissioned data access remains a cause. RLS helps close the gap between what users can access and what they should access by enforcing boundaries at the record level before unauthorized data ever leaves the 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:
- A regional sales team can query only their territory’s records.
- 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à?
GDPR, HIPAA, CCPA, and PCI DSS require demonstrable controls over which users can access personal and sensitive records. RLS helps provide enforcement at the point of query – automatically scoping results to authorized records – and helps generate the audit trail evidence regulators require. Organizations in financial services, healthcare, and enterprise data environments may depend on RLS to help maintain compliance posture without restructuring data or replicating sensitive datasets.
In che modo RLS si adatta agli ambienti con più negozi?
Most organizations manage data across multiple platforms, each with their own RLS implementations. Native controls typically work within a single platform but create policy fragmentation across environments. A centralized security layer is designed to apply consistent row-level access policies across data store from a single control point – helping reduce maintenance overhead and helping maintain compliance posture as the data stack evolves.
Concetti fondamentali
Come funziona la sicurezza a livello di riga
RLS helps restrict query results by evaluating access conditions at execution time – filtering rows based on the requesting user’s identity, role, or attributes – before returning results. Implementations range from native database mechanisms to centralized policy layers that apply consistently across multiple data platforms.
Filtraggio delle righe esplicito e implicito
RLS is implemented in two fundamental modes: explicit and implicit. Explicit enforcement requires users to include filter conditions in every query – making compliance dependent on user behavior and creating risk when filters are omitted. Implicit enforcement applies filtering automatically through secure views, row access policies, or a platform security layer – so users receive only the rows they are authorized to access, regardless of how the query is written.
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 implements RLS through Row Access Policies (RAPs) – schema-level objects created once and attached to one or more tables or views. At query time, Snowflake wraps the protected object in a dynamic secure view, evaluates the policy body against actual row values, and returns only the rows where the expression is TRUE. RAPs require Enterprise Edition or higher and execute with the policy owner’s role – not the querying user’s role – helping prevent privilege escalation. RAPs combine with Dynamic Data Masking to help enable simultaneous row and column-level protection on the same table.
RLS centralizzato e multipiattaforma
Native RLS mechanisms – secure views, row access policies, virtual private databases – may be effective within a single data store but can create fragmentation in multi-platform environments. A centralized security layer helps apply row-level policies across every data store from a single policy engine, using identity provider attributes from Okta or other identity providers to make access decisions dynamically. This reduces the need to replicate user-to-row mappings in each database and helps provide consistent enforcement regardless of which data platform is queried.
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
Financial institutions managing sales data, customer account records, and transaction histories should restrict access by business unit, region, or role without restructuring shared data platforms. RLS is designed to enforce data boundaries at query time – so analysts and sales representatives retrieve only the records their role authorizes. And helps compliance teams maintain audit trails for GDPR, CCPA, and PCI DSS requirements without duplicating sensitive datasets across multiple restricted copies.
Accesso alle cartelle cliniche dei pazienti per operatore sanitario e reparto
Healthcare organizations handling electronic health records should enforce HIPAA-compliant access controls – so providers access only their patients’ records, departments see only relevant cases, and researchers receive only de-identified data. RLS helps apply these boundaries at query time without requiring separate data copies for each access tier. Combined with column-level data masking, RLS helps enable analytics and AI workloads on production data without compromising patient privacy or HIPAA obligations.
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 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 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 dell’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 policy 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 dell’interrogazione: 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 interrogazione 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)
