// TL;DR

Il problema reale

Quando si parla di breach cloud, la narrativa dominante è sempre la stessa: attacco sofisticato, zero-day, hacker con cappuccio. La realtà è quasi sempre più banale. La maggior parte dei compromessi AWS parte da IAM.

Non perché IAM sia difettoso. Perché è potente, flessibile, e quella flessibilità viene usata male — spesso per velocità, spesso per comodità. Il risultato è lo stesso.

Errore #1 — Wildcard su Action

// 01
Action: "*" — La policy che fa tutto

Una policy con Action: "*" concede all'identità la possibilità di eseguire qualsiasi operazione AWS. Listare bucket S3, creare utenti IAM, accedere a Secrets Manager. Qualsiasi cosa. 

// ❌ Quello che si vede troppo spesso
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// ✅ Quello che dovrebbe esserci
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-specific-bucket/*"
}

Errore #2 — Chiavi di accesso statiche

// 02
Access Key hardcoded nel codice

Le chiavi statiche non scadono, non ruotano automaticamente, e quando finiscono in un repo GitHub (anche per 30 secondi) sono già nelle mani di qualcuno.

// Attenzione

Da quando una chiave AWS appare in un commit pubblico a quando viene usata: meno di 5 minuti in media. I bot che scansionano GitHub in tempo reale cercano esattamente questo pattern.

La soluzione non è nascondere le chiavi meglio. È non usarle. IAM Roles per EC2, Lambda, ECS — le credenziali temporanee rotano automaticamente e non possono essere esfiltrate nel modo classico.

Errore #3 — Ruoli cross-account senza condizioni

// 03
Trust policy aperta a qualsiasi account

Un ruolo con trust policy che permette l'assume da arn:aws:iam::*:root può essere assunto da qualsiasi account AWS nel mondo. 

// ❌ Trust policy aperta
"Principal": { "AWS": "arn:aws:iam::*:root" }

// ✅ Specifica l'account e aggiungi ExternalId
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Condition": { "StringEquals": { "sts:ExternalId": "MySecretExternalId" } }

Errore #4 — MFA non abilitata

// 04
Root account senza MFA

L'account root AWS ha accesso illimitato e non può essere ristretto da policy. Senza MFA, una password compromessa equivale a perdita totale dell'ambiente.

Il root account non dovrebbe mai essere usato per operazioni quotidiane. Si crea, si abilita MFA hardware, si chiude in cassaforte. Per tutto il resto si usano utenti IAM o ruoli con permessi minimi.

Errore #5 — Permission boundary assenti

// 05
Nessun limite massimo ai permessi delegabili

Senza permission boundary, un utente con permessi di creazione ruoli può creare un ruolo con più permessi di quanti ne abbia lui stesso. È privilege escalation by design.

// Strumenti consigliati

Prowler — audit automatizzato AWS con centinaia di check IAM.
IAM Access Analyzer — nativo AWS, gratuito, trova accessi pubblici e cross-account.
CloudTrail + Athena — analisi storica di chi ha fatto cosa e quando.

Conclusione

IAM è la superficie d'attacco più sottovalutata del cloud. Richiede di pensare come un attaccante per vedere i problemi. Cosa può fare questo ruolo? Chi può assumerlo? Da dove?

Fare quelle domande prima degli altri è esattamente la differenza tra un assessment e un incident report.