import pandas as pd

Security and access control on data lake

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 in modo 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 livello di rischio accettato.

Access control come modello di responsabilità

Controllare gli accessi non vuol dire solo bloccare. Vuol dire concedere l’accesso minimo necessario, tenerlo tracciabile e mantenerlo coerente con la classificazione, lo scopo e il rischio del dato. Un analista che deve leggere metriche aggregate non ha motivo di vedere email e identificativi personali 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 rendere chiaro il costo di una scelta sbagliata, per esempio un permesso troppo ampio che espone PII.

Rendere misurabile la sicurezza

L’unità su cui ragioni è la coppia tra identità e risorsa: un ruolo, un bucket, un prefisso, una tabella. Il segnale che osservi sono gli accessi registrati e i tentativi negati. La baseline è la mappa dei permessi prima dell’intervento. La soglia decisionale è il principio del minimo privilegio applicato a ogni ruolo. Il rischio residuo è concedere accessi ampi per comodità operativa, 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 seguendo il principio del minimo privilegio, cioè solo i permessi necessari. Lake Formation aggiunge il controllo accessi a livello di tabella, colonna o riga per i 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 necessario 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, in modo che ogni team operi con il proprio ruolo a permessi granulari. La logica è sempre la stessa: ognuno vede ciò che gli serve per il proprio lavoro e nulla di più.

Un caso concreto

Un analyst deve leggere metriche aggregate ma non deve vedere email e identificativi personali presenti nei file raw. Il caso mostra perché la sicurezza su data lake richiede separazione delle zone, policy IAM mirate, encryption, audit log e controlli al 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

Esercizio

Per il livello base, scrivi in cinque righe quale decisione di accesso vuoi definire: ruolo, risorsa, dati sensibili coinvolti e rischio principale.

Per il livello intermedio, costruisci una tabella con tre ruoli. Per ciascuno indica i dati a cui può accedere, quelli che deve restare fuori portata e il controllo che useresti per verificarlo.

Per il livello research-grade, prepara un memo che includa classificazione dei dati, mappa dei permessi attuali, principio di minimo privilegio applicato, rischio residuo e piano di audit periodico. Come dataset usa S3, Parquet, Athena, Glue o un log storage; se non hai dati reali, genera un set sintetico con almeno 200 righe, una dimensione temporale, un segmento e una metrica di outcome.

Typical mistake to avoid

L’errore più comune è concedere permessi ampi per non rallentare il lavoro, rimandando la stretta a “dopo”. Si arriva così a ruoli che vedono PII senza motivo e ad accessi che nessuno 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.

Checkpoint

1. Quale ruolo o identità stai definendo?
2. A quali dati deve accedere e quali deve evitare?
3. Quali dati sono classificati come sensibili o regolati?
4. Come tracci gli accessi e i tentativi negati?
5. Ogni quanto rivedi i permessi concessi?

Summary

La sicurezza di un data lake nasce dal minimo privilegio applicato a strati: bucket policy, ruoli IAM, controlli Lake Formation a livello di tabella e colonna, encryption a riposo e in transito, audit con CloudTrail. Ogni team vede solo ciò che gli serve, le PII restano separate, e gli accessi sono tracciabili. La policy regge quando puoi dire, per ogni ruolo, esattamente quale dato esporrebbe in caso di abuso.

---

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.