Amazon SCS-C02: Gestione dell'identità e degli accessi — Guida allo studio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fa parte della AWS Security Specialty SCS-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Identità, Principal e Valutazione delle Policy

IAM distingue tra identità (utenti, gruppi, ruoli) e principal (l’entità autenticata che effettua una richiesta). Gli utenti sono a lunga durata con credenziali statiche; i ruoli non hanno credenziali proprie e vengono assunti per ottenere token STS a breve durata. I gruppi sono contenitori per associare policy agli utenti — non sono mai principal e non possono essere assunti.

Ogni chiamata API passa attraverso una catena di valutazione deterministica: un Deny esplicito prevale sempre, poi le SCP a livello di organization devono consentire l’azione, poi i permissions boundary devono consentirla, poi le policy di sessione (se presenti) devono consentirla e, infine, almeno una policy basata sull’identità o sulla risorsa deve contenere un Allow. La mancanza di un qualsiasi livello di Allow risulta in un deny implicito. Ecco perché la stratificazione è importante: una policy di identità che concede s3:* è inutile se una SCP nega s3:DeleteBucket o un permissions boundary omette completamente S3.

Le policy basate sulla risorsa (policy dei bucket S3, policy delle chiavi KMS, policy dei topic SNS, policy delle funzioni Lambda) possono concedere l’accesso direttamente a un principal senza alcuna policy di identità dal lato del chiamante — all’interno dello stesso account. Per l’accesso cross-account, sia la policy di identità nell’account di origine sia la policy della risorsa nell’account di destinazione devono consentire l’azione.

Ruoli, Policy di Attendibilità e AssumeRole

Un ruolo ha due documenti di policy: la policy di attendibilità (chi può assumerlo) e una o più policy dei permessi (cosa può fare una volta assunto). La policy di attendibilità è una policy basata sulla risorsa applicata al ruolo stesso, che utilizza l’azione sts:AssumeRole. Senza una policy di attendibilità corrispondente, AssumeRole fallisce con AccessDenied anche se il chiamante ha sts:AssumeRole nella sua policy di identità.

Per la delega cross-account, la policy di attendibilità nomina l’account attendibile o un ARN specifico di un ruolo/utente in quell’account e — aspetto critico per l’accesso di terze parti — impone un ExternalId:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

L’ExternalId protegge dal problema del “confused deputy”: senza di esso, un fornitore SaaS di terze parti che assume ruoli in molti account dei clienti potrebbe essere indotto con l’inganno ad agire sul ruolo del cliente sbagliato. Omettere sts:ExternalId nella condizione, o passare un valore errato durante la chiamata sts:AssumeRole, produce un AccessDenied al momento dell’assunzione del ruolo — una misconfigurazione comune durante l’onboarding di fornitori come strumenti di monitoraggio o CSPM.

Per i servizi AWS (Lambda, EC2, task ECS), la policy di attendibilità nomina un principal del servizio, ad es. "Service": "lambda.amazonaws.com". Una funzione Lambda che necessita di accesso a S3 dovrebbe assumere un ruolo di esecuzione la cui policy dei permessi concede s3:GetObject e s3:PutObject sul bucket; in modo equivalente, una policy del bucket S3 può nominare l’ARN del ruolo della funzione come principal. Entrambi i meccanismi funzionano singolarmente all’interno di un unico account.

Permissions Boundary

Un permissions boundary è un controllo avanzato associato a un utente o a un ruolo che limita i permessi massimi che quell’identità può mai avere, indipendentemente da ciò che concedono le policy basate sull’identità. I permessi effettivi sono l’intersezione tra la policy di identità e il boundary. Se una policy di gruppo concede ec2:* ma il boundary permette solo ec2:Describe*, l’utente potrà solo eseguire azioni di tipo describe.

I boundary sono comunemente usati per la delega dei permessi: consentire agli sviluppatori di creare ruoli IAM per le loro applicazioni, ma richiedere che ogni ruolo da loro creato sia associato a uno specifico boundary. La policy IAM per lo sviluppatore include una condizione come "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" sulle azioni iam:CreateRole e iam:PutRolePolicy. Questo previene la privilege escalation pur abilitando il self-service.

Un’idea sbagliata comune è che l’appartenenza a un gruppo o policy aggiuntive possano “sovrascrivere” un boundary o una SCP. Non è possibile: il boundary e la SCP sono dei massimali, non dei valori di base.

Applicazione dell’MFA tramite Condizioni

Due chiavi di condizione governano le policy MFA: aws:MultiFactorAuthPresent (booleano, true se la sessione è stata ottenuta usando l’MFA) e aws:MultiFactorAuthAge (numerico, secondi trascorsi dalla convalida dell’MFA). L’applicazione dell’MFA per API sensibili e la limitazione della durata della sessione si presentano così:

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

Due ore corrispondono a 7.200 secondi. L’uso di BoolIfExists invece di Bool è leggermente pericoloso per le chiamate da parte di principal di servizio che non includono mai questa chiave — viene valutato come true e di fatto aggira il controllo per tali chiamanti, quindi è preferibile usare Bool quando l’intento è l’applicazione per utenti umani.

Poiché le richieste da CLI e SDK che utilizzano chiavi di accesso a lungo termine non contengono il contesto MFA, gli utenti devono prima chiamare sts:GetSessionToken (con --serial-number e --token-code) o sts:AssumeRole con --serial-number/--token-code per ottenere credenziali temporanee che includano il contesto MFA. Queste credenziali a breve durata soddisfano quindi la condizione MultiFactorAuthPresent:

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center e Federazione

IAM Identity Center (precedentemente AWS SSO) centralizza l’accesso della forza lavoro attraverso un’AWS Organization. I set di autorizzazioni (permission sets) sono modelli che Identity Center materializza come ruoli IAM all’interno di ogni account di destinazione quando un utente o un gruppo viene assegnato. Le assegnazioni legano tre elementi: un principal (utente o gruppo dalla directory di Identity Center o da un IdP esterno come Okta/Entra ID), un set di autorizzazioni e uno o più account.

I set di autorizzazioni possono includere policy gestite da AWS, policy gestite dal cliente (referenziate per nome, quindi devono esistere in ogni account di destinazione), policy inline e un limite delle autorizzazioni (permissions boundary). Quando si modifica un set di autorizzazioni, Identity Center ri-esegue il provisioning dei ruoli sottostanti — non si modificano mai direttamente tali ruoli.

Per la federazione SAML al di fuori di Identity Center, AWS convalida la firma dell’asserzione rispetto ai metadati dell’IdP registrati sull’oggetto provider SAML di IAM. Quando l’IdP ruota il suo certificato di firma, è necessario caricare il file XML dei metadati aggiornato; altrimenti, STS restituisce InvalidIdentityToken / Response Signature Invalid. Aggiornare i metadati con aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ... è la correzione con il minor overhead — non è necessario ricreare il provider o riconfigurare le relazioni di fiducia.

Account Root, Report delle Credenziali e Principio del Minimo Privilegio

L’utente root ha un accesso completo e non rimovibile e deve essere trattato come un’identità di emergenza (“break-glass”): abilitare un dispositivo MFA hardware o virtuale, eliminare eventuali chiavi di accesso root, non usarlo per il lavoro quotidiano e conservare le credenziali offline. Utilizzare le SCP a livello di root dell’organizzazione o di OU per impedire persino agli amministratori negli account membri di disabilitare GuardDuty, eliminare CloudTrail o abbandonare regioni specifiche. Le SCP non concedono mai autorizzazioni — filtrano solo ciò che IAM nell’account membro può concedere.

Il principio del minimo privilegio viene reso operativo con strumenti piuttosto che con l’intuizione. Generare il report delle credenziali IAM (aws iam generate-credential-report e poi get-credential-report) per trovare utenti inutilizzati, chiavi di accesso obsolete e utenti senza MFA. Utilizzare IAM Access Analyzer per identificare le policy di risorsa che espongono dati in modalità cross-account e per generare policy dimensionate correttamente dall’attività di CloudTrail. Utilizzare i dati sull’ultimo accesso (aws iam get-service-last-accessed-details) per eliminare le autorizzazioni di servizio non utilizzate dai ruoli.

Un’ultima trappola che vale la pena menzionare esplicitamente: presumere che aggiungere un Allow a un’identità sia sufficiente. Se una policy di una chiave KMS non nomina il tuo ruolo, una SCP nega l’azione o un limite delle autorizzazioni la omette, la chiamata fallirà comunque. Verificare sempre l’intero stack — SCP, limite delle autorizzazioni, policy di identità, policy di risorsa e policy di sessione — durante la risoluzione di un AccessDenied.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Financial gestisce un’AWS Organization con tre account per carichi di lavoro di gestione, produzione e sviluppo, con dati sensibili di trading e dei clienti nell’account di produzione. Attualmente hanno un mix di utenti IAM legacy con credenziali a lunga durata, account di collaboratori esterni e un identity provider SAML Okta, il che produce controlli di accesso incoerenti e configurazioni di ruoli sparse tra gli account.

Sfida: Un incidente recente ha coinvolto le credenziali compromesse di un collaboratore che ha assunto un ruolo cross-account senza MFA e ha eseguito azioni eccessive perché non c’erano limiti delle autorizzazioni o set di autorizzazioni centralizzati. Meridian deve rafforzare la federazione, la fiducia dei ruoli e imporre l’MFA e il principio del minimo privilegio su tutti gli account.

Approccio Raccomandato:

Implementare AWS IAM Identity Center integrato con Okta SAML come piano di identità federata unico e migrare tutti gli utenti umani e i collaboratori esterni dagli utenti IAM con credenziali a lunga durata ad account basati su Identity Center, disabilitando la console/le chiavi per gli utenti IAM legacy.
Creare set di autorizzazioni centralizzati in IAM Identity Center che si mappano a ruoli IAM negli account membri e implementare limiti delle autorizzazioni IAM (definiti come policy IAM) per tutti i ruoli; distribuire questi limiti e modelli di ruolo tra gli account utilizzando AWS CloudFormation StackSets.
Aggiornare le policy di fiducia dei ruoli cross-account per consentire sts:AssumeRole solo dai principal ARN di Identity Center e includere condizioni che richiedono l’MFA (es. aws:MultiFactorAuthPresent) e restrizioni sull’account di origine; richiedere che i tag di sessione trasportino gli attributi di identità.
Imporre l’MFA a livello di IdP (Okta) e riflettere tale imposizione in AWS richiedendo condizioni MFA sulle sessioni dei ruoli; negare la creazione di accessi alla console o di nuovi utenti IAM applicando Service Control Policies (SCP) in AWS Organizations.
Abilitare AWS CloudTrail, AWS Config e IAM Access Analyzer per il monitoraggio continuo e la validazione delle policy, e inviare i risultati a CloudWatch/GuardDuty per flussi di lavoro di allerta e remediation automatizzata.

Logica: Centralizzare la federazione tramite IAM Identity Center, applicare il principio del minimo privilegio con set di autorizzazioni e limiti, richiedere l’MFA nelle policy di fiducia e applicare SCP a livello di organizzazione oltre al monitoraggio si allinea con le best practice di AWS per ridurre il raggio d’impatto, prevenire l’escalation dei privilegi e fornire auditabilità.

Ruoli IAM e Policy di attendibilità: PassRole e AssumeRole

Un ruolo IAM ha due superfici di policy distinte, e confonderle è la causa principale della maggior parte dei fallimenti di autorizzazione tra account. La policy di attendibilità (il AssumeRolePolicyDocument) risponde a chi può assumere il ruolo e in quali condizioni. La policy di autorizzazione risponde a cosa il ruolo può fare una volta assunto. Entrambe devono permettere l’azione; la sola policy di attendibilità non concede mai l’accesso a S3, KMS o a qualsiasi altra cosa.

Quando un’entità principale (principal) chiama sts:AssumeRole, STS valuta la policy di attendibilità del ruolo di destinazione rispetto all’identità chiamante e al contesto della sessione (indirizzo IP di origine, stato MFA, tag di sessione, ID esterno). L’entità chiamante deve anche avere un Allow basato sull’identità per sts:AssumeRole su quell’ARN del ruolo. Questo doppio requisito è ciò che rende sicura l’assunzione di ruoli tra account diversi.

Una policy di attendibilità canonica per l’accesso tra account che richiede MFA e un ID esterno ha questo aspetto:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

La chiave aws:MultiFactorAuthPresent ha significato solo nella policy di attendibilità di un ruolo assumibile, perché il contesto MFA viene stabilito al momento della chiamata a STS, non nelle chiamate ai servizi a valle. Aggiungere condizioni MFA alla policy del bucket S3 o alla policy di autorizzazione del ruolo è un errore comune: la sessione del ruolo assunto di solito non porta con sé aws:MultiFactorAuthPresent=true anche se l’utente umano originale si è autenticato con MFA, quindi tali condizioni negano silenziosamente ogni operazione. Imponi l’MFA al momento dell’assunzione del ruolo; usa aws:MultiFactorAuthAge per forzare una nuova autenticazione per le sessioni di lunga durata.

PassRole è il secondo ostacolo che trae in inganno negli scenari d’esame. Quando si indica a un servizio come CloudFormation, EC2, Lambda o CodeBuild di essere eseguito come un ruolo, l’identità chiamante deve avere l’autorizzazione iam:PassRole.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Financial gestisce una AWS Organization multi-account con account separati per produzione, sviluppo e strumenti di CI/CD; utilizzano ruoli IAM centralizzati per i deployment tra account e agenti CI di terze parti che assumono ruoli per eseguire modifiche all’infrastruttura. I confini dell’identità sono imposti dalle policy di attendibilità dei ruoli e alcuni team utilizzano profili di istanza e funzioni Lambda di lunga durata a cui è concesso iam:PassRole per associare ruoli a istanze o task.

Sfida: Un audit recente ha rilevato un’autorizzazione iam:PassRole eccessivamente permissiva che ha consentito a un’entità principale di CI/CD di passare un ruolo di Amministratore a un profilo di istanza EC2, e un utente malintenzionato ha sfruttato una policy di attendibilità di AssumeRole per ottenere privilegi eccessivi su più account.

Approccio Raccomandato:

Utilizzare AWS CloudTrail e Amazon EventBridge per identificare le chiamate API iam:PassRole e sts:AssumeRole recenti, ed eseguire query in CloudTrail Lake o Athena per elencare quali entità principali hanno passato quali ARN di ruoli e quando.
Eseguire IAM Access Analyzer (per IAM) su tutti gli account per scoprire le esposizioni delle policy di attendibilità basate sulle risorse ed elencare i ruoli che sono assumibili dall’esterno dell’Organization o da entità principali esterne.
Sostituire le policy iam:PassRole generiche con policy IAM basate sul principio del privilegio minimo che specificano gli ARN esatti dei ruoli nell’elemento Resource, e aggiungere chiavi di condizione come aws:PassedToService o aws:PrincipalOrgID per limitare chi e cosa può ricevere il ruolo.
Rafforzare le policy di attendibilità dei ruoli per richiedere condizioni — usare aws:PrincipalOrgID, sts:ExternalId per terze parti, richiedere aws:SourceIdentity e imporre durate massime per le sessioni — per impedire un AssumeRole generico da parte di entità principali sconosciute.
Configurare regole di Amazon EventBridge per rilevare anomalie in iam:PassRole e AssumeRole, inviare avvisi ad Amazon SNS e creare playbook Lambda automatizzati per revocare o correggere le policy eccessivamente permissive, e registrare i risultati in AWS Security Hub e AWS Config per la conformità continua.

Motivazione: Questo approccio applica il principio del privilegio minimo e della difesa in profondità (defense-in-depth) restringendo i target di PassRole e le policy di attendibilità, abilitando al contempo il rilevamento e la correzione automatizzata tramite la registrazione e il monitoraggio — in linea con le best practice AWS per IAM e la federazione.

Tutti i domini · Rilevamento delle minacce e avvisi →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →