Sicurezza e access control su 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.

Passaggio	Domanda da fare	Output atteso
Decisione	Quale livello di accesso stiamo definendo?	Policy esplicita
Segnale	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
Azione	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.

Elemento	Definizione operativa	Controllo minimo
Unità di analisi	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 su tutto
Analytics Team: R su curated, RW su schema di sviluppo
Marketing: R solo su marts marketing, no dati grezzi
Finance: R su marts finance, no PII clienti
Data Science: R su raw e curated, RW su schema sandbox

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.

Evidenza osservata	Lettura prudente	Azione consigliata
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

Errore tipico da evitare

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.

Riferimenti

• 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?