Il modello di permessi fine-grained di Lake Formation

AWS Lake Formation aggiunge un layer di autorizzazione centralizzato sopra i dati del data lake registrati in Amazon S3, sostituendo il modello frammentato basato solo su bucket policy e IAM. Il flusso concettuale è: registri una S3 location come data lake location (delegando a Lake Formation un ruolo che accede allo storage), poi concedi permessi sulle risorse del catalogo — database, table, column e row — a IAM principal (utenti e ruoli). I motori integrati — Amazon Athena, Amazon Redshift Spectrum, AWS Glue, Amazon EMR — non leggono più S3 direttamente con le proprie credenziali: chiedono a Lake Formation credenziali temporanee e ricevono già filtrato ciò che il principal non è autorizzato a vedere.

Il valore d’esame sta nella granularità. Puoi concedere SELECT solo su alcune colonne (column-level security), definire data filters con una row filter expression per il row-level security, o combinarli per il cell-level. Nessuna di queste cose è ottenibile con le sole bucket policy, che ragionano a livello di oggetto o prefix e ignorano completamente lo schema tabellare.

Per scalare su centinaia di tabelle senza gestire grant una per una, usa il tag-based access control con le LF-Tags: assegni tag alle risorse del catalogo e concedi i permessi sui tag. Una nuova tabella che eredita il tag corretto diventa immediatamente accessibile ai principal autorizzati su quel tag, senza nuove concessioni manuali.

Il Data Catalog come single source of truth

Lake Formation e AWS Glue condividono lo stesso AWS Glue Data Catalog: il registro centrale di database, table, schema, partizioni e location fisiche in S3. I Glue crawler popolano il catalogo inferendo schema e partizioni dai file; Lake Formation vi sovrappone la governance. Athena, Redshift Spectrum ed EMR risolvono le query proprio contro questo catalogo, quindi mantenerlo accurato è precondizione sia per l’esecuzione sia per l’enforcement dei permessi.

La condivisione cross-account si appoggia al catalogo: con LF-Tags e AWS Resource Access Manager (RAM) esponi database e table a un altro account senza copiare i dati né duplicare bucket policy. L’account consumatore vede le risorse condivise nel proprio catalogo e le interroga con i motori integrati, sempre nel rispetto dei permessi fine-grained.

Audit e tracciabilità con CloudTrail

AWS CloudTrail registra le chiamate API come eventi ed è lo strumento di riferimento per l’audit della governance. Con i management events (attivi di default) tracci chi ha concesso o revocato permessi, chi ha registrato location e chi ha richiesto credenziali dati tramite Lake Formation — utile per ricostruire “chi ha dato accesso a cosa e quando”. I log confluiscono in S3 e sono interrogabili con Athena o monitorabili via Amazon CloudWatch.

Attenzione al livello: per sapere quale principal ha effettivamente letto un singolo oggetto S3 servono i data events (S3 object-level), che vanno abilitati esplicitamente su un trail e hanno un costo aggiuntivo. I management events da soli non registrano le operazioni sugli oggetti.

Trappole tipiche d’esame

  • Permessi fine-grained che sembrano ignorati → rimuovi IAMAllowedPrincipals: finché quel gruppo mantiene grant sulla table, Lake Formation opera in modalità pass-through IAM e le restrizioni per colonna o riga non vengono applicate. Va revocato perché l’enforcement diventi effettivo.
  • Serve mascherare singole colonne → Lake Formation, non bucket policy: le bucket policy S3 non conoscono le colonne; solo un grant per-colonna o un data filter di Lake Formation nasconde le colonne sensibili.
  • Isolamento righe multi-tenant → data filter con row filter expression: non creare una table separata per tenant; definisci un data filter che filtra le righe in base a una condizione.
  • Condividere dati tra account senza copiarli → LF-Tags + AWS RAM: evita di duplicare bucket o dati; condividi le risorse del catalogo e lascia che i permessi seguano i tag.
  • Chi ha letto quale oggetto S3 → CloudTrail S3 data events: i management events non registrano le GetObject; per l’audit a livello di oggetto abilita esplicitamente i data events.
  • Un motore bypassa i permessi → usa solo engine integrati e revoca l’accesso S3 diretto: se un ruolo accede direttamente al bucket con IAM saltando Lake Formation, la governance fine-grained non si applica.