AWS IAM Access Control: Policy, Ruoli e Best Practice

AWS Identity and Access Management (IAM) è il servizio che governa autenticazione e autorizzazione per ogni chiamata API effettuata verso il vostro ambiente AWS. Determina chi può autenticarsi, quali azioni può eseguire e su quali risorse — attraverso ogni servizio AWS, in ogni region, per ogni account. Configurare correttamente IAM non è facoltativo; secondo le analisi post-incidente di AWS stessa, le policy IAM mal configurate sono coinvolte nella maggior parte delle violazioni di sicurezza cloud che raggiungono la divulgazione pubblica. Questo articolo tratta l'architettura di IAM, la logica di valutazione delle policy, i pattern pratici per scalare il controllo degli accessi e gli errori operativi che il SOC di Opsio riscontra ripetutamente su centinaia di account AWS.

Punti Chiave

• AWS IAM è il servizio fondamentale per controllare chi può fare cosa su ogni risorsa AWS, e la sua errata configurazione è la causa più comune degli incidenti di sicurezza nel cloud.
• Un IAM efficace richiede la stratificazione di identity policy, resource policy, permission boundary e Service Control Policy — non basta associare managed policy agli utenti.
• Le organizzazioni soggette a NIS2, GDPR o normative ACN devono trattare la configurazione IAM come un controllo di conformità, non come una semplice comodità operativa.
• ABAC (attribute-based access control) basato sui tag è oggi il pattern di scaling raccomandato per le organizzazioni con più di pochi account, ma la maggior parte dei team continua a utilizzare RBAC.
• I principali fallimenti IAM che il SOC di Opsio investiga non sono escalation di privilegi, ma credenziali obsolete e ruoli di servizio con permessi eccessivi che nessuno revisiona.

Come Funziona AWS IAM: Il Modello Fondamentale

IAM opera su un modello default-deny. Ogni richiesta API AWS viene valutata rispetto a un insieme di policy, e a meno che la valutazione non produca un Allow esplicito — senza alcun Deny che lo sovrascriva — la richiesta viene rifiutata. Comprendere questa catena di valutazione è il singolo concetto più importante nel controllo degli accessi AWS.

Principal, Azioni, Risorse e Condizioni

Ogni statement di una policy IAM ha quattro componenti:

• Principal — l'entità che effettua la richiesta (utente IAM, ruolo IAM, identità federata, servizio AWS)
• Action — l'operazione API specifica (s3:GetObject, ec2:RunInstances, iam:CreateUser)
• Resource — gli ARN a cui l'azione si applica
• Condition — vincoli opzionali (IP sorgente, stato MFA, orario, tag della risorsa)

Una policy è un documento JSON contenente uno o più statement, ciascuno con un Effect di Allow o Deny. La potenza — e la complessità — deriva dal modo in cui più policy interagiscono durante la valutazione.

La Catena di Valutazione delle Policy

Quando un principal effettua una richiesta all'interno di una AWS Organization, la valutazione segue questo ordine:

1. Service Control Policy (SCP) — guardrail a livello di organizzazione che definiscono i permessi massimi per gli account membri

2. Resource-based policy — associate alla risorsa stessa (es. bucket policy S3, key policy KMS)

3. IAM permission boundary — i permessi massimi che un'entità IAM può avere, indipendentemente dalle sue identity policy

4. Session policy — passate durante l'assunzione di un ruolo, per restringere ulteriormente la sessione

5. Identity-based policy — le policy associate all'utente IAM, al gruppo o al ruolo

Un Deny esplicito a qualsiasi livello sovrascrive tutti gli statement Allow. Questo modello a strati significa che è possibile imporre guardrail a livello di organizzazione (tramite SCP) anche se gli amministratori dei singoli account tentano di concedere accessi più ampi.

Comprendere questa catena non è un esercizio accademico — il NOC di Opsio traccia regolarmente errori access-denied a restrizioni SCP di cui gli amministratori a livello di account non erano a conoscenza. Se state facendo troubleshooting di un 403 su una chiamata API dove la identity policy dice chiaramente Allow, controllate prima le SCP.

I Componenti di IAM nella Pratica

Utenti IAM vs. Ruoli IAM vs. Identità Federate

Gli utenti IAM sono identità di lunga durata con credenziali permanenti. Esistono ancora e funzionano, ma per gli operatori umani vanno considerati legacy. L'indicazione attuale di AWS — e la posizione operativa di Opsio — è di federare l'accesso umano tramite IAM Identity Center (ex AWS SSO), che emette credenziali temporanee via SAML 2.0 o OIDC.

I ruoli IAM sono il fulcro dell'IAM AWS moderno. Un ruolo non ha credenziali permanenti; i principal assumono il ruolo e ricevono token di sicurezza temporanei (tramite AWS STS). I ruoli vengono utilizzati per:

• Accesso cross-account (un workload nell'Account A assume un ruolo nell'Account B)
• Accesso service-to-service (un instance profile EC2, un execution role Lambda)
• Accesso umano via federazione (si assume un ruolo dopo l'autenticazione tramite il proprio IdP)

Le identità federate si autenticano presso un identity provider esterno (Okta, Azure AD / Entra ID, Google Workspace) e assumono ruoli IAM. Questo è il pattern che ogni organizzazione con più di dieci ingegneri dovrebbe utilizzare per l'accesso a console e CLI.

Policy IAM: Managed, Inline e Custom

Le AWS managed policy (es. ReadOnlyAccess, PowerUserAccess) sono mantenute da AWS e coprono pattern comuni. Sono comode ma spesso troppo ampie per l'uso in produzione. AdministratorAccess è la managed policy più comunemente associata che il SOC di Opsio riscontra nei finding di audit — e non è quasi mai giustificata per le operazioni quotidiane.

Le customer managed policy sono la scelta corretta per default. Scrivetele voi stessi, dimensionatele sui vostri workload reali, versionatele in Git e distribuitele tramite Infrastructure as Code (Terraform, CloudFormation o CDK).

Le inline policy sono incorporate direttamente in un utente, gruppo o ruolo. Hanno una relazione stretta 1:1. Usatele solo quando una policy non deve essere accidentalmente associata a un'altra entità — il che è raro.

Service Control Policy (SCP)

Le SCP sono il livello più potente — e più frainteso — dello stack IAM. Non concedono permessi; definiscono il confine massimo di ciò che qualsiasi principal in un account membro può fare. Una SCP che nega s3:DeleteBucket significa che nessuno in quell'account può eliminare un bucket, anche se dispone di AdministratorAccess.

Pattern SCP pratici che Opsio implementa per i clienti:

• Restrizione regionale — negare tutte le azioni al di fuori di eu-south-1 (Milano), eu-west-1 e eu-central-1 (per imporre la sovranità dei dati in conformità con GDPR e le indicazioni ACN su Cloud Italia)
• SCP guardrail — impedire la disabilitazione di CloudTrail, l'eliminazione dei VPC flow log o la modifica del ruolo IAM di audit
• Deny-list di servizi — bloccare i servizi non utilizzati dall'organizzazione (es. Lightsail, GameLift) per ridurre la superficie d'attacco

Guardrail di sicurezza AWS

RBAC vs. ABAC: Scegliere il Modello Giusto

RBAC (Role-Based Access Control)

RBAC in AWS significa creare ruoli IAM distinti per ciascuna funzione lavorativa — DevOps-Engineer, Data-Analyst, Security-Auditor — e associare le relative policy. È intuitivo e funziona bene quando:

• Si hanno meno di ~20 ruoli distinti
• I team sono chiaramente separati
• La proliferazione di account è limitata

Lo svantaggio è l'esplosione combinatoria. Se avete 5 funzioni lavorative, 4 ambienti (dev/staging/prod/sandbox) e 3 progetti, potreste aver bisogno di 60 definizioni di ruolo — ciascuna con policy separate.

ABAC (Attribute-Based Access Control)

ABAC utilizza i tag sia sui principal che sulle risorse per prendere decisioni di autorizzazione. Invece di 60 ruoli, si scrive un set ridotto di policy con condizioni come:

```json

"Condition": {

"StringEquals": {

"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",

"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"

}

}

```

Questo consente a uno sviluppatore taggato Project=payments, Environment=dev di accedere solo alle risorse taggate allo stesso modo — senza creare ruoli specifici per progetto o ambiente.

La documentazione IAM di AWS raccomanda esplicitamente ABAC come modello preferito per lo scaling. Nella pratica, la maggior parte delle organizzazioni gestite da Opsio utilizza un approccio ibrido: RBAC per la separazione ampia per funzione lavorativa, ABAC per il controllo granulare delle risorse all'interno di quei ruoli.

L'aspetto critico operativo: ABAC funziona solo se il tagging è disciplinato. Se i team non taggano le risorse in modo coerente, le condizioni falliscono in modo aperto o chiuso in modi imprevedibili. Imponete il tagging con SCP e regole AWS Config prima di puntare su ABAC.

Governance dei tag e FinOps

Best Practice IAM: Cosa Conta Davvero

Il Security Pillar dell'AWS Well-Architected Framework definisce le best practice IAM in cinque aree. Ecco cosa riscontriamo essere davvero rilevante in produzione — non la teoria:

1. Eliminare le Access Key di Lunga Durata

Ogni access key è una credenziale che può essere esfiltrata. Il SOC di Opsio ha investigato incidenti in cui access key committate in repository GitHub pubblici sono state sfruttate entro pochi minuti da scanner automatizzati. La soluzione:

• Utilizzare ruoli IAM con credenziali temporanee per tutti i workload (instance profile EC2, task role ECS, execution role Lambda)
• Federare l'accesso umano tramite IAM Identity Center
• Per i rari casi in cui le access key sono inevitabili (integrazioni legacy), imporre la rotazione tramite la regola AWS Config access-keys-rotated con un'età massima di 90 giorni

2. Imporre MFA — Ovunque Sia Rilevante

MFA sull'account root è il minimo indispensabile. Ma imponete MFA anche per:

• Tutti gli utenti IAM umani (se ne avete ancora)
• L'assunzione di ruoli sensibili (iam:AssumeRole con Condition: { "Bool": { "aws:MultiFactorAuthPresent": "true" }})
• Il flusso di autenticazione IAM Identity Center (MFA con notifica push, non SMS)

3. Applicare il Least Privilege in Modo Iterativo

Nessuno riesce a ottenere il least privilege corretto al primo tentativo. L'approccio pratico:

1. Partire con AWS managed policy leggermente più ampie del necessario

2. Abilitare IAM Access Analyzer per monitorare quali permessi vengono effettivamente utilizzati

3. Dopo 30-90 giorni, generare una policy di least privilege basata sull'attività di accesso di CloudTrail

4. Sostituire la policy ampia con quella generata

5. Ripetere trimestralmente

La funzionalità di generazione policy di IAM Access Analyzer è genuinamente utile e sottoutilizzata. Legge i log di CloudTrail e produce una policy calibrata che corrisponde solo alle azioni e risorse effettivamente invocate.

4. Utilizzare i Permission Boundary per l'Amministrazione Delegata

Se consentite a sviluppatori o team lead di creare ruoli IAM (es. per funzioni Lambda), impostate un permission boundary che limiti ciò che quei ruoli creati possono fare. Senza questo meccanismo, uno sviluppatore può creare un ruolo con AdministratorAccess — il che rappresenta un percorso di escalation dei privilegi.

5. Auditing Continuo, Non Annuale

Una revisione IAM annuale è un esercizio di mera conformità formale. Piuttosto:

• Eseguite IAM Access Analyzer in modo continuativo per rilevare accessi esterni e inutilizzati
• Monitorate le chiamate API IAM anomale tramite CloudTrail + Amazon GuardDuty
• Utilizzate le regole AWS Config per segnalare automaticamente le configurazioni IAM non conformi
• Convogliate i finding in un SIEM centralizzato o nella pipeline di alerting del vostro SOC

Monitoraggio SOC 24/7

IAM in una AWS Organization Multi-Account

Gli ambienti AWS con un singolo account sono sempre più rari in produzione. AWS Organizations, combinato con IAM Identity Center, è il pattern standard per la gestione degli accessi su decine o centinaia di account.

IAM Identity Center (Ex AWS SSO)

IAM Identity Center fornisce un unico punto per gestire l'accesso umano su tutti gli account della vostra organizzazione. Gli utenti si autenticano una sola volta (tramite il vostro IdP aziendale o la directory integrata) e ricevono credenziali temporanee per qualsiasi account e permission set selezionino.

I permission set in IAM Identity Center sono astrazioni che creano ruoli IAM in ogni account di destinazione. Li definite una volta centralmente e li assegnate a utenti o gruppi per account. Questo è drasticamente più semplice rispetto alla gestione indipendente dei ruoli IAM in ogni singolo account.

Assunzione di Ruolo Cross-Account

Per l'accesso service-to-service tra account (es. una pipeline CI/CD nell'account di tooling che effettua il deploy in produzione), il pattern è:

1. Creare un ruolo nell'account di destinazione con una trust policy che consenta il ruolo dell'account sorgente

2. Il workload sorgente chiama sts:AssumeRole per ottenere credenziali temporanee

3. Utilizzare external ID per prevenire attacchi confused-deputy quando sono coinvolte terze parti

Opsio configura l'accesso cross-account utilizzando un modello hub-and-spoke: un account di sicurezza centrale detiene ruoli di audit che possono leggere (ma non scrivere) in tutti gli account membri. Questo design supporta sia le operazioni SOC sia la raccolta di evidenze di conformità.

Strategia multi-account

Dimensioni di Conformità: NIS2, GDPR e Normativa ACN

La configurazione IAM è direttamente referenziata in ogni principale framework di conformità con cui Opsio opera:

Direttiva NIS2 (UE) — L'Articolo 21 richiede "politiche di controllo degli accessi" inclusa la gestione degli accessi privilegiati. Le organizzazioni classificate come entità essenziali o importanti devono dimostrare che i controlli IAM sono proporzionati al rischio, che gli accessi privilegiati sono monitorati e che le revisioni degli accessi vengono condotte regolarmente. In ambito AWS, questo si traduce in SCP, CloudTrail, IAM Access Analyzer e procedure documentate di revisione degli accessi. In Italia, l'ACN (Agenzia per la Cybersicurezza Nazionale) è l'autorità competente per il recepimento della NIS2 e le organizzazioni devono allinearsi anche alle sue indicazioni operative.

GDPR — L'Articolo 32 richiede "la capacità di assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento", che il Garante per la Protezione dei Dati Personali interpreta come inclusivo della gestione delle identità e degli accessi. I titolari del trattamento devono dimostrare che l'accesso ai dati personali è limitato al personale che ne ha effettiva necessità — il che significa policy IAM calibrate su specifiche tabelle DynamoDB, prefissi S3 o istanze RDS contenenti dati personali.

Cloud Italia e Strategia Cloud Nazionale — Per le organizzazioni italiane, in particolare le pubbliche amministrazioni, le linee guida ACN sulla classificazione dei dati e sull'adozione di servizi cloud richiedono controlli di accesso documentati e verificabili. I workload che risiedono nella region eu-south-1 (Milano) o su Azure Italy North devono rispettare requisiti di sovranità dei dati che si traducono direttamente in restrizioni regionali via SCP e configurazioni IAM rigorose.

Il filo conduttore: tutti questi framework richiedono non solo che i controlli esistano, ma che siano monitorati e revisionati. Una configurazione IAM senza logging CloudTrail e revisione periodica degli accessi non soddisfa nessuno di essi.

Errori IAM Comuni Riscontrati dal SOC di Opsio

Sulla base di incidenti reali e finding di audit nei nostri account gestiti:

1. ARN con wildcard nelle policy di produzione — "Resource": "*" è accettabile durante il prototyping. In produzione, significa che un principal compromesso può accedere a ogni risorsa di quel tipo nell'account.

2. Ruoli di servizio con AdministratorAccess — Le funzioni Lambda e i task ECS dovrebbero avere execution role strettamente delimitati. Associare accesso admin "perché è più facile" trasforma ogni vulnerabilità applicativa in una compromissione totale dell'account.

3. Nessun guardrail SCP sugli account membri — Senza SCP, qualsiasi amministratore di account può concedersi qualsiasi permesso. Le SCP sono l'unico meccanismo che vincola persino l'utente root dell'account (negli account membri).

4. Utenti IAM e access key obsolete — Riscontriamo regolarmente utenti IAM di dipendenti che hanno lasciato l'organizzazione mesi o anni fa. Utilizzate la regola AWS Config iam-user-unused-credentials-check e configuratela per segnalare credenziali inutilizzate da 45 giorni.

5. Ignorare le resource-based policy — Le bucket policy S3, le key policy KMS e le queue policy SQS possono concedere accesso indipendentemente dalle identity policy. Un bucket S3 con "Principal": "*" nella sua bucket policy è accessibile pubblicamente, indipendentemente da quanto siano restrittivi i vostri ruoli IAM.

Per Iniziare: Una Sequenza Operativa Pratica

Per le organizzazioni che non hanno ancora formalizzato la governance IAM, ecco l'ordine che produce risultati più rapidamente:

1. Abilitare CloudTrail in tutti gli account, in tutte le region, con logging verso un bucket S3 centralizzato in un account di log archive

2. Abilitare IAM Access Analyzer in ogni account (è gratuito)

3. Migrare l'accesso umano dagli utenti IAM a IAM Identity Center con MFA

4. Implementare SCP di base — negare le region inutilizzate, proteggere l'infrastruttura di audit, richiedere la crittografia

5. Auditare ruoli e policy IAM esistenti — utilizzare i finding di Access Analyzer per identificare ruoli inutilizzati e policy con permessi eccessivi

6. Implementare Infrastructure as Code per tutte le risorse IAM — basta ClickOps nella console IAM

Migrazione e modernizzazione cloud

Questa sequenza funziona sia che abbiate 2 account o 200. La differenza è quanto tempo richiede il punto 5.

Domande Frequenti

Cosa sono i controlli di accesso IAM?

I controlli di accesso IAM sono le policy, i ruoli e i meccanismi all'interno di AWS Identity and Access Management che determinano quali principal (utenti, ruoli, servizi) possono eseguire quali azioni su quali risorse. Operano su un modello default-deny: a meno che una policy non consenta esplicitamente un'azione, questa viene negata. I controlli includono identity-based policy, resource-based policy, permission boundary, session policy e Service Control Policy a livello di organizzazione.

IAM è RBAC o ABAC?

AWS IAM supporta entrambi. Il controllo di accesso basato sui ruoli (RBAC) si realizza creando ruoli IAM con set di permessi specifici e assegnandoli a utenti o gruppi. Il controllo di accesso basato sugli attributi (ABAC) utilizza i tag su principal e risorse per prendere decisioni di autorizzazione dinamiche. AWS raccomanda ABAC per scalare su molti account perché riduce il numero di policy distinte da gestire. La maggior parte degli ambienti di produzione utilizza un approccio ibrido.

Cos'è l'accesso IAM in AWS?

L'accesso IAM in AWS si riferisce alla capacità autenticata e autorizzata di un principal — un utente IAM, un'identità federata o un ruolo IAM — di interagire con i servizi e le risorse AWS. Ogni chiamata API ad AWS viene valutata rispetto alle policy IAM. L'accesso è concesso solo quando le policy applicabili producono un Allow esplicito e nessuna policy applicabile produce un Deny esplicito.

Quali sono i 4 pilastri di IAM?

I quattro pilastri comunemente citati nella gestione delle identità sono: autenticazione (dimostrare chi si è), autorizzazione (cosa si è autorizzati a fare), amministrazione (gestione di identità e policy su larga scala) e auditing (registrazione e revisione delle attività di accesso). In termini AWS, corrispondono rispettivamente ai meccanismi di autenticazione IAM, alle policy IAM, ad AWS Organizations/IAM Identity Center e ad AWS CloudTrail.

Qual è la relazione tra AWS IAM e la conformità NIS2?

NIS2 richiede che le entità essenziali e importanti implementino policy di controllo degli accessi proporzionate al rischio, mantengano capacità di risposta agli incidenti e dimostrino accountability per gli accessi privilegiati. AWS IAM fornisce i controlli tecnici — MFA, policy di least privilege, SCP, logging CloudTrail — ma la conformità richiede processi documentati, revisioni periodiche degli accessi e l'evidenza che questi controlli siano attivamente monitorati. Un SOC gestito può colmare il divario tra avere i controlli e dimostrare che funzionano.