Data classification con Amazon Macie

La classificazione dei dati è il presupposto di ogni controllo di protezione: non puoi proteggere ciò che non sai di avere. Amazon Macie è il servizio managed di data discovery e classification per Amazon S3. Usa pattern matching e machine learning per individuare sensitive data (PII, PHI, credenziali, chiavi) nei bucket e produce findings su cosa è esposto e dove.

All’esame Macie compare in due modi. Primo, come motore di discovery ricorrente: puoi definire discovery jobs one-time o scheduled con managed data identifiers (pattern predefiniti per numeri di carta, passaporti, IBAN) oppure custom data identifiers basati su regex per formati proprietari. Secondo, come fonte di posture monitoring su S3: Macie valuta di continuo se i bucket sono public, non cifrati o condivisi con account esterni, senza scansionare gli oggetti. Macie invia i findings a EventBridge e Security Hub, così puoi automatizzare la remediation. In scenari multi-account, Macie si integra con AWS Organizations: si designa un delegated administrator che abilita e monitora Macie su tutti gli account membri.

Protezione di Amazon S3

S3 è dove risiedono i dati, quindi la sua protezione è centrale. I controlli si stratificano.

S3 Block Public Access (BPA) è il guardrail contro l’esposizione accidentale. Le quattro impostazioni (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) si applicano a livello di account o di singolo bucket. Attivare BPA a livello account è la best practice: prevale su qualsiasi ACL o bucket policy che tenti di rendere pubblico un bucket. Se una domanda chiede “come impedire che chiunque renda pubblico un bucket in tutto l’account”, la risposta è BPA a livello account, non l’editing delle policy.

Bucket policy e enforcement dell’encryption. Le bucket policy sono resource-based policy. Un pattern d’esame ricorrente è forzare la cifratura in transito e a riposo tramite condition key in un Deny: negare le richieste con aws:SecureTransport = false (blocca HTTP) e negare i PutObject privi dell’header corretto usando s3:x-amz-server-side-encryption o, per KMS specifico, s3:x-amz-server-side-encryption-aws-kms-key-id. Ricorda che oggi S3 applica SSE-S3 di default; l’enforcement via policy serve quando vuoi imporre SSE-KMS con una chiave precisa e rifiutare tutto il resto.

S3 Object Lock implementa la ritenzione WORM (write-once-read-many) per requisiti di compliance e protezione da ransomware/cancellazione. Va abilitato alla creazione del bucket (richiede versioning). Ha due modalità: Governance (utenti con permesso s3:BypassGovernanceRetention possono rimuovere il lock) e Compliance (nessuno, nemmeno il root account, può alterare o cancellare l’oggetto fino a scadenza). Esiste anche il Legal Hold, indipendente dal periodo di retention. Compliance mode è la scelta per requisiti regolatori inderogabili.

S3 Access Points semplificano la gestione degli accessi su bucket condivisi da molte applicazioni: ogni access point ha un proprio hostname e una propria policy, evitando bucket policy monolitiche ingestibili. Utili in scenari multi-tenant o multi-team.

Gestione dei secret: Secrets Manager vs Parameter Store

AWS Secrets Manager è pensato per credenziali e secret con rotazione automatica: si integra nativamente con RDS, Redshift, DocumentDB e supporta rotation tramite funzione Lambda per secret custom. Cifra i secret con KMS, applica resource-based policy e registra ogni accesso in CloudTrail.

L’alternativa è SSM Parameter Store: i SecureString sono cifrati con KMS e adatti a configurazione e secret semplici. La differenza da ricordare: Parameter Store non offre rotazione automatica gestita né integrazione nativa con i database; lo standard tier è gratuito. Secrets Manager ha un costo per secret ma porta rotation, generazione di password casuali e replica cross-region. Scegli Secrets Manager quando la domanda cita “rotazione automatica” o “credenziali di database”; Parameter Store quando cita “config a basso costo senza rotazione”.

Trappole tipiche d’esame

  • Impedire l’esposizione pubblica di S3 in tutto l’account → S3 Block Public Access a livello account: prevale su ACL e bucket policy successive; non basta correggere le singole policy.
  • Ritenzione immutabile inderogabile anche dal root → Object Lock in Compliance mode: la Governance mode è aggirabile con s3:BypassGovernanceRetention, quindi non soddisfa requisiti regolatori stringenti.
  • Rotazione automatica di credenziali di database → Secrets Manager, non Parameter Store: SecureString di SSM è cifrato ma non ruota da solo; distrattore classico che punta sul costo inferiore.
  • Forzare SSE-KMS con una chiave specifica → Deny nella bucket policy con condition key s3:x-amz-server-side-encryption-aws-kms-key-id: l’encryption di default di S3 non garantisce la chiave voluta; serve il deny esplicito.
  • Scoprire dove risiedono le PII in S3 → Amazon Macie, non GuardDuty né Inspector: GuardDuty analizza minacce, Inspector le vulnerabilità; solo Macie classifica il contenuto sensibile.
  • Ridurre la superficie di bucket policy su dati condivisi da molte app → S3 Access Points: ogni endpoint ha policy dedicata; evita di gonfiare un’unica bucket policy fragile.