Executive summary
Nelle organizzazioni che trattano dati sensibili, stabilire con precisione chi può vedere quali informazioni, e dimostrarlo in caso di verifica, è un requisito tanto tecnico quanto legale. Questo articolo analizza i principali modelli per il controllo degli accessi ai dati, dai sistemi basati su ruoli predefiniti a quelli che valutano dinamicamente le caratteristiche dell'utente e del contesto, fino alle restrizioni applicate a singole righe o colonne di una tabella. L'analisi mostra che nessun modello è universalmente superiore: la scelta dipende dal grado di granularità richiesto, dalla dinamicità del contesto e dal costo di amministrazione accettabile. La registrazione sistematica degli accessi, integrata con i meccanismi di autenticazione federata, è l'elemento che trasforma le politiche di accesso da intenzione dichiarata a prova verificabile di fronte alle autorità di controllo.
Background
Il controllo degli accessi è uno dei problemi fondamentali della sicurezza informatica: dati i soggetti (utenti, processi, applicazioni), le risorse (tabelle, colonne, report, API) e le operazioni (lettura, scrittura, esportazione), è necessario determinare quali combinazioni siano permesse e registrare quelle che si verificano. I primi sistemi di controllo degli accessi erano basati su liste di controllo (Access Control List, ACL), in cui ogni risorsa manteneva un elenco esplicito di soggetti autorizzati. Questo approccio, sebbene semplice, non scala in ambienti con migliaia di utenti e risorse, poiché ogni modifica organizzativa richiede aggiornamenti capillari sulle singole risorse.
Il modello Role-Based Access Control (RBAC) è stato formalizzato da Ferraiolo e Kuhn nel 1992 [1] e unificato nel modello NIST da Sandhu, Ferraiolo e Kuhn nel 2000 [2]. RBAC introduce il concetto di ruolo come entità intermedia: i permessi sono assegnati ai ruoli e gli utenti vengono associati ai ruoli, non direttamente alle risorse. Questo disaccoppiamento riduce drasticamente la complessità amministrativa. Il modello NIST RBAC è organizzato in quattro livelli cumulativi (Flat RBAC, Hierarchical RBAC, Constrained RBAC e Symmetric RBAC) e fu adottato come standard ANSI/INCITS 359-2004 nel 2004, rivisto nel 2012 [2].
L'Attribute-Based Access Control (ABAC) emerge come risposta alle limitazioni di RBAC in contesti dinamici. Invece di assegnare permessi attraverso ruoli statici, le decisioni di accesso vengono calcolate a runtime valutando gli attributi del soggetto richiedente, della risorsa, dell'azione richiesta e del contesto ambientale [3]. Il National Institute of Standards and Technology ha pubblicato nel 2014 la guida definitiva sull'ABAC, posizionandolo come complemento naturale di RBAC per ambienti in cui la granularità richiesta supera quanto i ruoli possono esprimere [3]. Il linguaggio standard per l'implementazione di politiche ABAC è XACML (eXtensible Access Control Markup Language), portato alla versione 3.0 da OASIS nel 2013 [4].
Il Regolamento Generale sulla Protezione dei Dati (GDPR, Regolamento UE 2016/679) ha trasformato il controllo degli accessi da scelta architetturale a obbligo normativo [5]. Il principio di responsabilizzazione (accountability) sancito dall'Art. 5(2) e dall'Art. 24 impone ai titolari del trattamento di dimostrare la conformità attraverso misure tecniche ed organizzative appropriate. L'Art. 30 richiede la tenuta di un registro delle attività di trattamento, mentre l'Art. 32 impone l'adozione di misure tecniche idonee alla protezione dei dati. Le autorità di controllo interpretano l'assenza di audit log strutturati come segnale di negligenza nella gestione della sicurezza.
RBAC e ABAC: architettura dei modelli di autorizzazione
Il modello RBAC nella sua forma gerarchica (Hierarchical RBAC) stabilisce una relazione di parziale ordinamento sui ruoli: se il ruolo $r_1$ è superiore a $r_2$ nella gerarchia, allora $r_1$ eredita tutti i permessi di $r_2$. Il Constrained RBAC aggiunge il concetto di Separation of Duty (SoD): vincoli che impediscono a un singolo utente di assumere ruoli mutuamente esclusivi, prevenendo conflitti di interesse critici in contesti come la contabilità o la gestione degli appalti [2]. Formalmente, un vincolo di separazione statica dei compiti è definito come una coppia $(RS, n)$ dove $RS$ è un insieme di ruoli in conflitto e nessun utente può essere assegnato ad $n$ o più ruoli in $RS$ [2].
Il limite strutturale di RBAC emerge quando i criteri di accesso dipendono dal contesto: l'accesso ai dati di un reparto aziendale deve essere concesso solo durante le ore lavorative, oppure l'accesso a un report finanziario è permesso solo se l'utente accede dalla rete aziendale. Esprimere questi vincoli con RBAC richiederebbe la proliferazione di ruoli altamente specifici, un fenomeno noto come role explosion, che annulla i vantaggi amministrativi del modello. ABAC risolve questo problema rappresentando la politica di accesso come una funzione $f(A_s, A_r, A_a, A_e) \rightarrow {\text{permit}, \text{deny}}$, dove $A_s$ sono gli attributi del soggetto, $A_r$ della risorsa, $A_a$ dell'azione e $A_e$ dell'ambiente [3].
Lo standard XACML 3.0 [4] formalizza l'architettura a quattro componenti che implementa ABAC in produzione: il Policy Enforcement Point (PEP) intercetta le richieste e applica le decisioni; il Policy Decision Point (PDP) valuta la richiesta contro le policy; il Policy Information Point (PIP) recupera gli attributi necessari alla valutazione; il Policy Administration Point (PAP) gestisce il ciclo di vita delle policy. Ogni richiesta attraversa questi quattro componenti in sequenza, il che introduce latenza misurabile: in implementazioni non ottimizzate, ogni decisione ABAC può richiedere decine di millisecondi per il recupero degli attributi da sistemi esterni. Il caching degli attributi con politiche di invalidazione basate su eventi è la tecnica prevalente per mitigare questo overhead [4].
Nella pratica, i sistemi di produzione adottano un approccio ibrido: RBAC per la struttura di base (ruoli aziendali, struttura organizzativa) e ABAC per le politiche fine-grained che RBAC non può esprimere economicamente. Un ruolo come "analista finanziario" determina le macro-autorizzazioni, mentre policy ABAC raffinano l'accesso in funzione del dipartimento di appartenenza, della classificazione del dato e del periodo temporale. Il NIST SP 800-178 riconosce esplicitamente che RBAC può essere considerato un caso speciale di ABAC in cui il ruolo è l'unico attributo del soggetto rilevante per la decisione [3].
Row-Level Security e Column-Level Security nei data warehouse e negli strumenti BI
La sicurezza a livello di riga (Row-Level Security, RLS) e la sicurezza a livello di colonna (Column-Level Security, CLS) sono le proiezioni dei modelli di autorizzazione sull'architettura fisica dei dati tabulari. Questi meccanismi rispondono a un'esigenza diversa rispetto al controllo degli accessi a livello di oggetto (tabella, schema, database): permettono a utenti diversi di eseguire la stessa query sulla stessa tabella ottenendo risultati filtrati in base alla propria identità, senza richiedere la creazione di viste dedicate per ogni segmento utente.
Nei data warehouse moderni, RLS è implementata attraverso predicati di sicurezza: funzioni valutate automaticamente dal motore di query su ogni accesso alla tabella protetta, indipendentemente dalla formulazione della query. Snowflake implementa le Row Access Policies come oggetti separati associati alla tabella: la policy riceve la riga come argomento e restituisce un booleano che determina se la riga è visibile per la sessione corrente [6]. BigQuery supporta Row-Level Access Policies dichiarative associate a filtri su valori di colonna specifici, con la possibilità di utilizzare attributi della sessione IAM come condizione. L'implementazione è sempre lato server: non esiste query che un utente possa formulare per aggirare il predicato, poiché il filtro viene applicato dal motore prima che i dati siano esposti al layer di rete.
La CLS si occupa della dimensione ortogonale: limitare la visibilità di specifiche colonne a determinati utenti o ruoli. Snowflake supporta il Dynamic Data Masking: invece di negare l'accesso a una colonna, una masking policy trasforma il valore restituito in funzione del ruolo attivo [6]. L'utente con privilegi ridotti riceve un valore mascherato (es. ***-**-1234 per un numero fiscale), mentre l'utente autorizzato riceve il valore reale. Questa tecnica è particolarmente rilevante per la conformità GDPR: il principio di minimizzazione dei dati (Art. 5(1)(c)) richiede che siano trattati solo i dati strettamente necessari, e il masking permette di costruire ambienti di analisi in cui analisti con accesso parziale ai dati possono operare su dataset funzionalmente completi senza esporre informazioni personali.
L'interazione tra RLS/CLS e gli strumenti di Business Intelligence introduce complessità architetturale critica. Quando un utente esegue una query da uno strumento BI come Tableau, Power BI o Metabase, la query viene generata automaticamente dallo strumento. Se le policy di sicurezza sono definite esclusivamente nel layer semantico dello strumento BI piuttosto che nel data warehouse, un accesso diretto via client SQL, un'esportazione tramite API o un'integrazione con uno strumento di terze parti bypassa completamente i filtri. La raccomandazione architetturale prevalente è di implementare RLS e CLS nel data warehouse (push-down security) e lasciare che gli strumenti BI ereditino le restrizioni dalla connessione autenticata [6].
OAuth 2.0 e OpenID Connect: autenticazione federata per l'ecosistema dati
OAuth 2.0 è il framework di autorizzazione definito in RFC 6749 [7]: stabilisce un protocollo mediante il quale un'applicazione client può ottenere accesso limitato a un servizio HTTP per conto di un proprietario di risorse, senza che il client conosca le credenziali del proprietario. Il framework introduce quattro ruoli (Resource Owner, Client, Resource Server e Authorization Server) e definisce i flussi di autorizzazione (grant types) pensati per scenari applicativi diversi: Authorization Code con PKCE (per applicazioni web e mobile), Client Credentials (per comunicazioni machine-to-machine) e Device Authorization Grant (per dispositivi con capacità di input limitate). Il token Bearer, definito in RFC 6750, è il meccanismo di trasmissione dell'autorizzazione al Resource Server.
OpenID Connect (OIDC) estende OAuth 2.0 aggiungendo un layer di autenticazione [8]. Mentre OAuth 2.0 risponde alla domanda "a cosa può accedere questa applicazione?", OIDC risponde alla domanda "chi è questo utente?". OIDC introduce l'ID Token, un JSON Web Token (JWT) firmato dall'Authorization Server che contiene affermazioni (claims) sull'identità dell'utente (sub, email, name) e sulla sessione di autenticazione (iss, aud, exp, iat). La specificazione OIDC Core 1.0, mantenuta dall'OpenID Foundation, è lo standard de facto per la federazione delle identità negli ecosistemi enterprise [8].
Nel contesto dei data warehouse e degli strumenti BI, l'integrazione con OAuth 2.0/OIDC serve a due scopi distinti. Il primo è l'autenticazione dell'utente finale: quando un utente accede a uno strumento BI, l'applicazione delega l'autenticazione all'identity provider aziendale (Azure Active Directory, Okta) tramite OIDC, ottenendo un token che identifica l'utente senza che le credenziali siano gestite dallo strumento. Il secondo, e più critico per la correttezza di RLS, è la propagazione dell'identità al data warehouse: affinché le Row Access Policies di Snowflake funzionino correttamente per singolo utente, il data warehouse deve sapere quale utente finale sta eseguendo la query, non quale service account dello strumento BI. Snowflake supporta la propagazione dell'identità tramite OAuth, consentendo che il token dell'utente finale venga presentato al warehouse come identità di valutazione delle policy [6].
L'architettura di identity propagation richiede che l'identity provider sia configurato come Authorization Server attendibile nel data warehouse, e che ogni strumento BI ottenga token con scope appropriati per ogni utente. In assenza di una strategia deliberata, i data warehouse operano con un unico service account condiviso tra tutti gli utenti dello strumento BI, rendendo RLS inefficace a livello di warehouse e delegandola interamente al layer BI, con i rischi di bypass già descritti. La coordinazione tra team di identità, team dati e vendor degli strumenti BI necessaria per una corretta implementazione è uno degli aspetti più sottovalutati nella progettazione di architetture dati sicure.
Audit logging: architettura, completezza e conformità GDPR
L'audit log è la registrazione immutabile e ordinata nel tempo degli eventi di accesso ai dati: chi ha acceduto a quale risorsa, quando, da quale contesto (indirizzo IP, applicazione, sessione), e con quale esito. Dal punto di vista della conformità GDPR, il log di accesso è lo strumento primario per soddisfare il principio di accountability (Art. 5(2)) [5]: in assenza di registrazione sistematica, un'organizzazione non è in grado di dimostrare che i dati personali siano stati trattati esclusivamente da soggetti autorizzati per finalità legittime.
L'architettura di un sistema di audit efficace per un data warehouse deve affrontare tre problemi tecnici distinti. Il primo è la completezza: il log deve catturare non solo le query eseguite con successo, ma anche i tentativi di accesso negati, le query che hanno restituito zero righe per effetto di RLS, le operazioni di esportazione e le modifiche alle politiche di accesso stesse. Il secondo è l'integrità: il log deve essere protetto da modifiche successive, sia da parte di utenti ordinari che di amministratori. Questo richiede la scrittura del log in un sistema separato (object storage immutabile, sistema SIEM) con controllo di accesso distinto rispetto al sistema operativo. Il terzo è la retention: il GDPR e normative settoriali impongono periodi di conservazione specifici per i log di accesso ai dati personali, che vanno calibrati in funzione della natura dei dati e delle normative applicabili.
I data warehouse nativi cloud offrono meccanismi di audit integrati con diversi livelli di completezza. Snowflake registra tutte le query nella vista di sistema QUERY_HISTORY, con informazioni sul testo della query, l'utente, il ruolo attivo, il warehouse computazionale e i tempi di esecuzione. BigQuery mantiene un audit log strutturato in Cloud Logging, distinto in Data Access logs (accessi ai dati) e Admin Activity logs (operazioni amministrative), con durate di conservazione configurabili. Databricks Unity Catalog aggiunge un livello di governance centralizzato con audit log per le operazioni sui dati, integrabile con i principali sistemi SIEM tramite esportazione in formato JSON.
La sfida operativa più comune nell'implementazione di audit trail efficaci è la correlazione tra eventi. Una singola operazione utente, come il download di un report da uno strumento BI, può generare decine di query sul warehouse, ognuna registrata separatamente. Per ricostruire la catena causale, dall'azione utente alla query generata dallo strumento al result set estratto, è necessario propagare un identificatore di correlazione (trace ID) attraverso tutti i layer. Questo pattern, analogo al distributed tracing dei sistemi a microservizi [9], richiede cooperazione tra lo strumento BI, il layer semantico e il data warehouse, e la sua assenza rende i log di per sé raccolti difficilmente utilizzabili durante un'indagine.
Limiti e problemi aperti
La gestione del ciclo di vita delle politiche di accesso è un problema prevalentemente organizzativo prima che tecnico. In organizzazioni di medie dimensioni, le politiche di accesso vengono raramente riviste e tendono ad accumularsi in modo incrementale, portando a situazioni di permission creep, ovvero utenti che conservano permessi non più necessari dopo cambi di ruolo. Il principio del privilegio minimo, raccomandato da NIST [3], richiede processi di revisione periodica (access review) e workflow di deprovisioning automatizzato che molte organizzazioni non hanno ancora maturato.
La scalabilità di ABAC in produzione solleva problemi tecnici concreti. La valutazione delle policy a runtime richiede che il PDP recuperi gli attributi del soggetto e della risorsa prima di emettere una decisione; in presenza di centinaia di attributi e migliaia di richieste al secondo, questo diventa il collo di bottiglia dell'intera architettura. Il caching degli attributi mitiga il problema ma introduce sfide di invalidazione: se gli attributi dell'utente cambiano (es. revoca di un accesso), le decisioni in cache potrebbero rimanere valide per un intervallo di tempo inaccettabile in contesti ad alto rischio [4]. La granularità del caching deve essere calibrata caso per caso in funzione della sensibilità dei dati e della frequenza di modifica degli attributi.
La compatibilità tra RLS implementata nel data warehouse e gli strumenti BI rimane un'area di frizione aperta. Non tutti gli strumenti di BI supportano la propagazione dell'identità utente al database sottostante: molti utilizzano un service account condiviso e implementano i filtri di sicurezza nel proprio layer semantico. Questo approccio è architetturalmente fragile perché ogni accesso che bypassa lo strumento BI (client SQL diretto, script ETL, export via API) aggira completamente i controlli. La soluzione tecnica è disponibile (identity propagation via OAuth token), ma la sua implementazione richiede coordinamento tra team diversi che non tutte le organizzazioni riescono a garantire in modo sistematico.
Il provisioning automatizzato delle identità nei sistemi di dati rimane un problema parzialmente irrisolto. Lo standard SCIM (RFC 7644) [10] affronta la sincronizzazione degli utenti tra identity provider e sistemi applicativi, ma la sua integrazione con le politiche di accesso granulari a livello di riga o colonna nei data warehouse rimane prevalentemente manuale nella quasi totalità dei sistemi attuali. Un utente onboarded automaticamente via SCIM può ricevere il ruolo corretto nel warehouse, ma l'associazione tra quel ruolo e le Row Access Policies appropriate richiede ancora configurazione esplicita.
Riferimenti
[1] D. F. Ferraiolo e D. R. Kuhn, "Role-Based Access Controls," in Proc. 15th NIST-NCSC National Computer Security Conference, 1992. https://csrc.nist.gov/CSRC/media/Publications/conference-paper/1992/10/13/role-based-access-controls/documents/ferraiolo-kuhn-92.pdf
[2] R. Sandhu, D. Ferraiolo e R. Kuhn, "The NIST Model for Role-Based Access Control: Towards a Unified Standard," in Proc. 5th ACM Workshop on Role-Based Access Control, 2000. https://dl.acm.org/doi/10.1145/344287.344301
[3] V. C. Hu et al., "Guide to Attribute Based Access Control (ABAC) Definition and Considerations," NIST Special Publication 800-162, 2014. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf
[4] OASIS, "eXtensible Access Control Markup Language (XACML) Version 3.0," OASIS Standard, 2013. https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
[5] Parlamento Europeo e Consiglio dell'Unione Europea, "Regolamento (UE) 2016/679 — Regolamento Generale sulla Protezione dei Dati (GDPR)," Gazzetta Ufficiale dell'Unione Europea, 2016. https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX%3A32016R0679
[6] Snowflake Inc., "Snowflake Security Documentation: Row Access Policies, Dynamic Data Masking, OAuth Integration," 2024. https://docs.snowflake.com/en/user-guide/security-access-control-overview
[7] D. Hardt (Ed.), "The OAuth 2.0 Authorization Framework," IETF RFC 6749, 2012. https://datatracker.ietf.org/doc/html/rfc6749
[8] N. Sakimura et al., "OpenID Connect Core 1.0 incorporating errata set 2," OpenID Foundation, 2023. https://openid.net/specs/openid-connect-core-1_0.html
[9] B. H. Sigelman et al., "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure," Google Technical Report, 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/
[10] P. Hunt et al., "System for Cross-domain Identity Management: Protocol (SCIM)," IETF RFC 7644, 2015. https://datatracker.ietf.org/doc/html/rfc7644