IAM: identità, ruoli e least privilege

AWS IAM controlla chi (il principal) può fare cosa (action) su quali risorse (resource). Il principio del least privilege impone di concedere solo i permessi strettamente necessari, partendo da un set restrittivo ed espandendolo su evidenza. In architettura si distinguono due famiglie di policy. Le identity-based policy si attaccano a user, group o role e descrivono cosa quel principal può fare. Le resource-based policy si attaccano direttamente alla risorsa (bucket policy di Amazon S3, key policy di AWS KMS, policy di Amazon SQS/SNS o di AWS Lambda) e dichiarano chi può accedervi, anche da un altro account.

I ruoli IAM sono identità assumibili senza credenziali permanenti: si usano per far accedere Amazon EC2, AWS Lambda o i container ai servizi AWS tramite un role invece di access key long-term incorporate nel codice. Un instance profile associa un role a un’istanza EC2 ed è sempre preferibile alle chiavi statiche.

STS e accesso cross-account

AWS STS (Security Token Service) emette credenziali temporanee a scadenza quando un principal assume un role. È il meccanismo dietro ruoli, federazione e accesso tra account. Nel pattern cross-account classico si crea un role nell’account che possiede la risorsa (account B) con una trust policy che autorizza il principal dell’account chiamante (account A) ad assumerlo; l’utente di A ottiene così credenziali temporanee valide in B. In alternativa, per le risorse che supportano resource-based policy (tipicamente S3), si concede l’accesso cross-account direttamente nella policy della risorsa, senza far assumere alcun role. In generale preferisci le credenziali temporanee di STS alle chiavi statiche condivise.

Organizations e Service Control Policy

AWS Organizations gestisce più account sotto un’unica struttura, con consolidated billing e raggruppamento in Organizational Unit (OU). Le Service Control Policy (SCP) sono guardrail applicati a OU o account: definiscono il massimo insieme di permessi disponibili, ma non concedono nulla. Un permesso è effettivo solo se consentito sia dalla policy IAM del principal sia dalle SCP applicabili: l’accesso reale è l’intersezione delle due. Una SCP può quindi togliere permessi anche a chi ha una policy IAM con Allow ampio, ma da sola non abilita mai un’azione. Nota: le SCP non si applicano al management account dell’organizzazione.

Federazione e accesso applicativo

Per l’accesso della forza lavoro, la federazione SAML 2.0 consente agli utenti di un identity provider aziendale (es. Active Directory tramite ADFS) di ottenere credenziali temporanee AWS senza IAM user dedicati. Quando gli account sono molti, la soluzione gestita è AWS IAM Identity Center: si collega a un IdP esterno e assegna permission set agli account, centralizzando l’accesso. Per le applicazioni rivolte agli utenti finali si usa invece Amazon Cognito: i User Pool forniscono directory e autenticazione applicativa (sign-up/sign-in, emissione di token), mentre gli Identity Pool scambiano quei token per credenziali AWS temporanee (via STS) con cui l’app accede alle risorse AWS. Regola pratica: workforce su molti account → IAM Identity Center; utenti di un’app web/mobile → Cognito.

Trappole tipiche d’esame

  • Una SCP deve “dare” accesso a un servizio → soluzione: una SCP non concede mai permessi, li filtra soltanto; serve comunque una policy IAM con Allow, e l’accesso effettivo è l’intersezione tra SCP e policy identity-based.
  • App web/mobile con moltissimi utenti da autenticare → soluzione: Amazon Cognito (User Pool per l’autenticazione, Identity Pool per le credenziali AWS temporanee), non creare IAM user per gli utenti finali.
  • Dipendenti che accedono a più account AWS → soluzione: AWS IAM Identity Center con federazione verso l’IdP aziendale, non IAM user replicati account per account.
  • EC2 che deve leggere da S3 → soluzione: assegna un IAM role tramite instance profile, mai access key long-term nel codice o nei file di configurazione.
  • Accesso a un bucket S3 da un altro account → soluzione: resource-based policy (bucket policy) verso il principal esterno oppure un role cross-account assunto via STS; entrambe valide, scegli in base al pattern richiesto.
  • Servono credenziali a scadenza per accesso temporaneo → soluzione: AWS STS emette credenziali temporanee tramite assunzione di un role, evitando chiavi permanenti.