Security and access control on data lake

Questa lezione, come le altre del binario ml-tabellare, affronta il tema che decide la fiducia in tutto il resto: un data lake raccoglie PII, dati finanziari, log applicativi e dataset condivisi tra team diversi. La sicurezza qui significa combinare IAM, bucket policy, encryption, permessi di catalogo e auditing, così che la flessibilità del lake non diventi esposizione. Il tema è tecnico e il punto è decidere chi accede a cosa, con quale tracciabilità e con quale rischio accettato.

L’idea in una frase

Proteggere un data lake su S3 significa applicare minimo privilegio, encryption e audit su ogni coppia tra identità e risorsa, così ogni team vede solo i dati necessari al proprio lavoro.

Come procedere, passo dopo passo

1. Inventaria ruoli, bucket, prefissi e tabelle con i dati classificati come sensibili.
2. Assegna a ogni ruolo il minimo privilegio su bucket policy, IAM e Lake Formation.
3. Attiva encryption a riposo e in transito con chiavi gestite e rotazione definita.
4. Registra ogni accesso con CloudTrail e rivedi i permessi su base periodica.
5. Simula un abuso di ruolo e verifica quale dato resterebbe esposto.

Access control come modello di responsabilità

Controllare gli accessi non significa solo bloccare. Significa concedere l’accesso minimo necessario, tenerlo tracciabile e mantenerlo coerente con classificazione, scopo e rischio del dato. Un analista che deve leggere metriche aggregate non ha motivo di vedere email e identificativi nei file grezzi. Il lavoro consiste nel tradurre questa logica in policy concrete, non in un divieto generico.

Una griglia per impostare le scelte

Conviene seguire una sequenza che lega ogni passaggio a una conseguenza concreta.

Step	Question to ask	Expected output
Decision	Quale livello di accesso stiamo definendo?	Policy esplicita
Signal	Chi accede a quali dati, e con quale frequenza?	Evento di accesso osservabile
Baseline	Qual è lo stato di accesso attuale?	Mappa dei permessi
Vincolo	Quali dati sono sensibili o regolati?	Classificazione dichiarata
Action	Quale policy o ruolo applichiamo?	Controllo verificabile

Ogni riga deve chiarire il costo di una scelta sbagliata, per esempio un permesso troppo ampio che espone PII.

Rendere misurabile la sicurezza

L’unità di ragionamento è la coppia tra identità e risorsa: un ruolo, un bucket, un prefisso, una tabella. Il segnale osservato sono gli accessi registrati e i tentativi negati. La baseline è la mappa dei permessi prima dell’intervento. La soglia decisionale è il minimo privilegio applicato a ogni ruolo. Il rischio residuo è concedere accessi ampi per comodità, scoprendo l’esposizione solo dopo un incidente.

Element	Operational Definition	Controllo minimo
Unit of analysis	Coppia identità e risorsa	Ruolo, bucket, tabella
Variabile osservata	Accessi e tentativi negati	Log CloudTrail
Baseline	Mappa permessi attuale	Inventario dei ruoli
Soglia decisionale	Minimo privilegio per ruolo	Policy scritta prima
Rischio residuo	Permessi troppo larghi	Audit periodico

I livelli di sicurezza

La protezione di un data lake si costruisce a strati. La bucket policy di S3 definisce chi può accedere al bucket e con quali azioni: è la prima barriera, granulare a livello di bucket o prefisso. I ruoli IAM assegnano permessi ad applicazioni e utenti secondo il minimo privilegio, cioè solo i permessi necessari. Lake Formation aggiunge il controllo a livello di tabella, colonna o riga per query engine come Athena, Redshift Spectrum ed EMR. L’encryption protegge i dati a riposo e in transito, con SSE-S3 gestita da AWS oppure KMS con chiavi gestite da te. Infine CloudTrail registra ogni accesso a S3, fornendo l’audit trail per la compliance.

Pattern: accessi per team

Un modello tipico di accesso per team su un data lake aziendale ha questa forma:

Data Engineering: RW on everything
Analytics Team: R on curated, RW on development schema
Marketing: R only on marketing marts, no raw data
Finance: R on finance marts, no customer PII
Data Science: R on raw and curated, RW on sandbox schema

Questo schema si implementa con ruoli IAM più policy Lake Formation, così ogni team opera con il proprio ruolo a permessi granulari. La logica è sempre la stessa: ognuno vede ciò che serve al proprio lavoro e nulla di più.

Un caso concreto

Un analyst deve leggere metriche aggregate ma non deve vedere email e identificativi personali nei file raw. Il caso mostra perché la sicurezza richiede separazione delle zone, policy IAM mirate, encryption, audit log e controlli a livello di catalogo o tabella. La protezione non vive in un singolo controllo, ma nella combinazione coerente di questi strati.

Observed evidence	Cautious interpretation	Recommended action
Un ruolo accede a dati che non gli servono	Permesso troppo ampio	Restringere al minimo privilegio
PII raggiungibili da team analytics	Manca separazione delle zone	Isolare raw e curated
Accessi non tracciati	Audit incompleto	Attivare CloudTrail e revisione

Typical mistake to avoid

L’errore più comune è concedere permessi ampi per non rallentare il lavoro, rimandando la stretta a dopo. Così alcuni ruoli vedono PII senza motivo e alcuni accessi restano senza traccia. La domanda di controllo è: se questi permessi finissero nelle mani sbagliate, quale dato esporrei? Se la risposta è un dato sensibile, la policy va ristretta prima, non dopo.

Verdetto: usa SSE-S3 per i dati standard, KMS con chiavi gestite per PII e dati regolati, e Lake Formation per i controlli a livello di colonna e riga.

References

• AWS. (2024). “Lake Formation Developer Guide.” docs.aws.amazon.com/lake-formation.
• AWS. (2024). “Security Best Practices for Amazon S3.” docs.aws.amazon.com/AmazonS3.

Il caso Equifax

Nel 2017 Equifax annunciò una violazione che espose i dati personali di circa 147 milioni di persone negli Stati Uniti. L’attacco sfruttò una vulnerabilità nota di Apache Struts rimasta senza patch sui sistemi esposti, restando attivo per settimane prima del rilevamento. L’azienda subì costi, cause e un accordo di risarcimento da centinaia di milioni di dollari, oltre a un danno reputazionale duraturo. Il caso mostra la tesi della lezione: permessi ampi, patch rimandate e audit incompleto trasformano un controllo mancato in un’esposizione di massa.

Domande per verificare quello che hai capito

1. Quale ruolo stai definendo e su quale bucket o tabella opera?
2. A quali dati deve accedere e quali devono restare fuori dalla sua portata?
3. Quali dati del tuo lake classifichi come sensibili o regolati?
4. Come tracci accessi riusciti e tentativi negati su quel ruolo?
5. Ogni quanto rivedi i permessi concessi e con quale audit?