Identity-based policy e resource-based policy

La distinzione fondamentale in IAM è a chi è attaccata la policy. Una identity-based policy si applica a un principal (user, group o role) e descrive cosa quel principal può fare; non ha un elemento Principal perché il soggetto è implicito. Una resource-based policy si attacca invece alla risorsa (S3 bucket policy, KMS key policy, SQS/SNS, Lambda, Secrets Manager) e include obbligatoriamente il campo Principal, che indica chi ottiene l’accesso.

Il punto d’esame è la combinazione nell’accesso cross-account. Nello stesso account, è sufficiente che una delle due policy (identity o resource) conceda l’azione: vale l’unione. In cross-account, invece, servono entrambe: la identity-based policy nell’account chiamante deve consentire l’azione e la resource-based policy nell’account proprietario deve consentirla al principal remoto. Manca uno dei due allow e la richiesta fallisce, anche senza nessun deny.

Ruoli IAM, trust policy e AWS STS

Un IAM role non ha credenziali permanenti: viene assunto per ottenere credenziali temporanee. Ogni role ha due policy distinte. La permissions policy (identity-based) definisce cosa il role può fare; la trust policy è una resource-based policy speciale che, tramite Principal e l’azione sts:AssumeRole, definisce chi può assumere il role (un altro account, un servizio AWS, un IdP federato).

AWS STS rilascia le credenziali temporanee. Le API chiave sono AssumeRole (cross-account e uso interno), AssumeRoleWithSAML (federazione SAML) e AssumeRoleWithWebIdentity (OIDC/web identity). Concetti da padroneggiare:

  • External ID: quando un terzo (es. un vendor SaaS) assume un tuo role, imponi nella trust policy la condition key sts:ExternalId. Serve a mitigare il confused deputy problem, impedendo che il vendor usi il tuo trust per conto di un altro cliente.
  • Session policy: policy JSON passata al momento di AssumeRole che restringe ulteriormente i permessi. I permessi effettivi sono l’intersezione tra permissions policy del role e session policy: la session policy non può ampliare, solo ridurre.

Logica di valutazione delle policy

Regola d’oro: un explicit Deny prevale sempre, in qualunque policy compaia. In assenza di deny esplicito, l’accesso è negato di default (implicit deny) e richiede un allow esplicito.

I diversi tipi di policy si combinano così: una Service Control Policy (SCP) è un guardrail a livello di Organization/OU/account che stabilisce il massimo dei permessi possibili, ma non concede nulla; una permission boundary limita il massimo che le identity-based policy possono concedere a quel principal, anch’essa senza concedere; la session policy interseca al momento dell’assunzione. Perché un’azione sia consentita deve superare tutti i filtri applicabili (SCP, boundary, session) ed essere concessa da identity o resource policy, senza alcun deny esplicito lungo la catena.

IAM Identity Center e federazione

AWS IAM Identity Center (ex AWS SSO) centralizza l’accesso multi-account. L’identity source può essere la directory interna, Active Directory, o un IdP esterno via SAML 2.0; il provisioning degli utenti avviene tramite SCIM. Il costrutto centrale è il permission set: un insieme di policy che, assegnato a un utente/gruppo su un account, viene materializzato come IAM role (nome AWSReservedSSO_*) in quell’account. Da preferire agli IAM user long-lived per l’accesso umano.

La federazione evita di creare identità in AWS: gli utenti si autenticano presso l’IdP e ricevono credenziali temporanee. Con SAML si usa AssumeRoleWithSAML, con OIDC (workload esterni, mobile) AssumeRoleWithWebIdentity. Per l’accesso cross-account umano, il pattern robusto è role con trust policy verso l’account di origine più la condition aws:MultiFactorAuthPresent per esigere l’MFA all’assunzione.

Trappole tipiche d’esame

  • Accesso cross-account che fallisce nonostante l’allow → soluzione: verifica entrambe le policy; in cross-account servono sia identity policy (chiamante) sia resource policy (proprietaria). L’unione vale solo nello stesso account.
  • Un vendor terzo deve assumere il tuo role in sicurezza → soluzione: trust policy con condition sts:ExternalId, non credenziali statiche; è la difesa contro il confused deputy.
  • “Concedere permessi tramite SCP” → soluzione: le SCP e le permission boundary non concedono nulla, limitano soltanto; serve sempre un allow in una identity o resource policy.
  • Un allow non basta perché qualcosa nega → soluzione: cerca l’explicit deny (in SCP, boundary o policy): prevale sempre su qualsiasi allow.
  • Ampliare i permessi con una session policy → soluzione: impossibile; i permessi effettivi sono l’intersezione, la session policy può solo restringere.
  • Accesso umano ricorrente multi-account con MFA → soluzione: IAM Identity Center con permission set e IdP federato, non IAM user long-lived; imponi l’MFA con aws:MultiFactorAuthPresent.