Hai mai ricevuto un “Access Denied” su AWS? Ecco cosa controllare

Sono le 22:30. Francesco sta finalmente provando a configurare il suo primo bucket S3 con un sito statico. Carica index.html. Apre il browser. Incolla l’URL.

Access Denied.

Ricontrolla la URL. Stessa cosa. Apre la bucket policy. Sembra giusta. Si logga di nuovo. Niente. Disattiva qualcosa, riattiva qualcos’altro, sostituisce un asterisco con due asterischi, googla “AWS access denied site web”, arriva a Stack Overflow del 2018, prova una soluzione, peggiora la situazione.

Mezzanotte. Tab chiuso. Frustrazione totale.

La parte triste è che nove volte su dieci la diagnosi corretta richiede meno di cinque minuti, se sai dove guardare. La parte bella è che dopo aver letto questo articolo lo saprai.

Vediamolo insieme.

L’errore che sembra uno solo (ma sono tre)

Prima cosa da capire. Access Denied su AWS non è un errore singolo. È un’etichetta che AWS appiccica sopra a tre origini molto diverse. E finché non sai distinguerle, vai a tentoni.

Pensalo come un buttafuori al portone di un locale. Lui non decide nulla, gli è arrivata un’istruzione e la esegue. Quello che devi capire è chi gliel’ha data. Tre figure dietro le quinte possono averti escluso:

1. Il responsabile della sicurezza personale, la tua identity-based policy. Manca sul tuo user, sul tuo role o sul tuo group il permesso per fare quella specifica azione su quella specifica risorsa. È il caso più comune.

2. Il proprietario del locale, la resource-based policy. La risorsa stessa (un bucket S3, una key KMS, una secret di Secrets Manager) ha una propria policy che nega o non concede l’accesso. Tu potresti avere il permesso “in tasca”, ma la porta di quel locale ha una serratura ulteriore.

3. Il direttore del franchising, un explicit Deny che vive più in alto. Una Service Control Policy a livello di AWS Organizations, una permission boundary sul tuo IAM user, una session policy applicata al volo. Il Deny esplicito vince sempre, anche contro un Allow precedente.

Bonus, fuori dalla famiglia: a volte non è nemmeno un problema di permessi. È un token scaduto, un endpoint sbagliato, un Security Group che blocca a livello di rete. Anche di questo parliamo più sotto.

Una volta che hai questa mappa in testa, Access Denied smette di essere un mistero. Diventa una domanda: quale dei tre?

La checklist in 5 punti (cinque minuti, davvero)

Quando arriva un Access Denied, segui questo ordine. È costruito per escludere le ipotesi più probabili per prime.

Sei sicuro di essere tu? Sembra banale, e invece. Stai chiamando da CLI con un profilo --profile dev che pensavi essere il tuo? Sei in console loggato come root mentre la prova la stai facendo dall’SDK con altre chiavi? La Lambda sta usando il role che credi tu? Apri un terminale e fai aws sts get-caller-identity: ti dice esattamente chi sta parlando con AWS in questo momento. Più della metà dei casi finisce qui.
Leggi il messaggio d’errore con attenzione. Da qualche anno AWS è molto meno avaro con gli Access Denied: ti dice spesso quale azione, su quale risorsa, e quale tipo di policy ha negato. Se nella stringa vedi with an explicit deny in a service control policy, hai già la risposta, non perdere altro tempo a guardare la policy del tuo user.
Controlla l’identity policy. Vai in IAM, apri il tuo user/role, guarda le policy attached. Hai davvero il permesso per quella action (s3:GetObject) su quella resource (l’ARN esatto del bucket)? Wildcard o specifico? Se hai s3:Get* stai bene per GetObject. Se hai s3:GetBucketLocation, no. La tentazione di “leggere veloce” qui costa cara.
Controlla la resource policy. Vai sulla risorsa interessata e guarda se ha una policy. Per S3 è la bucket policy + le impostazioni di Block Public Access. Per KMS è la key policy. Per le code SQS è la queue policy. È un controllo che molti dimenticano perché “il problema è del mio utente”. Spesso non lo è.
Esiste un Deny esplicito da qualche parte sopra? Sei in un account che fa parte di un’AWS Organization? Allora controlla le SCP attive su quell’account. Hai un user con permission boundary? Apri quella e leggila. Se vedi un "Effect": "Deny" ovunque nella catena, vince lui, anche contro un Allow grande come una casa.

C’è uno strumento che vale la pena conoscere: il IAM Policy Simulator. Lo trovi nella console IAM. Inserisci uno user (o role), un’azione, una risorsa, e ti dice esattamente se l’accesso sarebbe consentito e, se no, quale policy specifica lo nega. Per i casi complicati cross-account vale i 30 secondi che ti chiede di setup.

Gli scenari che vedo ripetersi più spesso

Sui forum, nelle community, nei messaggi degli studenti. Questi sono i quattro scenari che si ripetono di gran lunga più spesso.

S3: “il sito non si apre, Access Denied”. Combo classica. Nove volte su dieci il problema è uno tra: oggetto privato senza una bucket policy che lo renda pubblicamente leggibile, oppure il Block Public Access attivo a livello di bucket o di account che annulla qualunque policy. Dal 2023 i nuovi bucket sono privati di default, e questo è la causa numero uno di tutti i tutorial “Hello World” che falliscono al primo tentativo.

Lambda non riesce a scrivere su DynamoDB. Il role che hai assegnato alla Lambda non ha la policy che permette dynamodb:PutItem su quella tabella. Errore tipico del principiante: aver assegnato AWSLambdaBasicExecutionRole (che dà solo log su CloudWatch) e dimenticato di aggiungere i permessi di accesso ai dati.

Cross-account: l’altro account dice di no. Stai assumendo un role in un secondo account. Il tuo ha tutto in regola. Ma per un cross-account access servono due benestare: il tuo (puoi assumere) e la trust policy del role nell’altro account che ti elenca esplicitamente come trusted entity. Se manca uno dei due, Access Denied.

Improvvisamente non funziona più nulla. Stamattina andava, adesso no, niente è cambiato dal tuo lato. Quasi sempre: qualcuno ha attivato o modificato una SCP a livello di Organization, o ha cambiato una permission boundary. Apri CloudTrail, filtra per gli eventi PutPolicy, AttachPolicy, e di solito trovi il colpevole.

Per ognuno di questi, il pattern è lo stesso. Prima identifichi chi sta parlando con AWS (get-caller-identity), poi leggi il messaggio d’errore, poi vai a guardare la policy giusta. Niente magia.

Quando NON è IAM (e cosa fare)

Ogni tanto Access Denied non c’entra con IAM. È un altro livello che ti sta bloccando. I casi tipici sono tre.

Rete. Se l’errore arriva da dentro una VPC, può non essere IAM ma il VPC Endpoint di S3 con una endpoint policy restrittiva, o un Security Group che blocca la chiamata HTTPS, o una NACL stratificata. La diagnosi si fa con VPC Flow Logs, non con il Policy Simulator.

Encryption / KMS. L’oggetto S3 è cifrato con una KMS key di cui il tuo user/role non può fare kms:Decrypt. Risultato: bucket policy ok, IAM policy ok, ma Access Denied. Il debugger lo vede solo se sa che esiste questo livello.

Token scaduto o credenziali ruotate. Le sessioni STS hanno una durata massima. Se hai assunto un role e sono passate 12 ore, le credenziali sono scadute. Tecnicamente è “ExpiredToken”, ma a volte AWS o l’SDK risponde con un Access Denied “generico” che confonde. Il fix è un nuovo assume-role.

Quando hai escluso IAM e queste tre cose, sei davanti a un caso davvero esotico. Vai su CloudTrail, cerca l’evento esatto della chiamata fallita (è registrato in chiaro, con il motivo del rifiuto), e parti da lì.

Domande frequenti su Access Denied su AWS

Posso testare in anticipo se un permesso funziona? Sì, con il IAM Policy Simulator. Lo trovi nella console IAM. Selezioni uno user/role, un’azione (es. s3:GetObject), una risorsa (l’ARN del bucket), e ottieni il verdetto + lo statement esatto che ha deciso.

CloudTrail mi dice perché ho ricevuto Access Denied? Spesso sì. Cerca l’evento corrispondente alla chiamata fallita, apri il dettaglio JSON, e cerca i campi errorCode ed errorMessage. Per le SCP, il messaggio è esplicito: with an explicit deny in a service control policy. Per le bucket policy: with an explicit deny in a resource-based policy.

Esiste uno strumento che mi mostra solo lo statement specifico che ha negato? Per le risorse policiate (S3, KMS, SQS, Secrets Manager) il nuovo formato del messaggio Access Denied indica spesso il tipo di policy che ha bloccato. Per casi cross-account o multi-policy, l’IAM Access Analyzer ti aiuta a trovare incongruenze.

A cosa serve l’Access Analyzer e quando lo uso? L’IAM Access Analyzer serve a trovare risorse esposte involontariamente (bucket pubblici per sbaglio, role assumibili da account esterni) e a generare policy IAM minime sulla base degli accessi reali registrati da CloudTrail. È più uno strumento di security review che di troubleshooting acuto.

Posso negare a tutto un account un’azione, anche se i singoli IAM user l’hanno consentita? Sì, ed è esattamente lo scopo delle SCP in AWS Organizations. Una SCP Deny su s3:DeleteBucket blocca la cancellazione di bucket per chiunque nell’account, root incluso. È il guardrail più potente della piattaforma.

Access Denied non è un mistero. È un buttafuori che fa solo quello che gli è stato detto di fare. La tua rabbia legittima, ma sprecata su di lui, la persona da cercare è chi gli ha dato l’istruzione.

E quella persona vive in uno di tre posti soltanto: la tua identity policy, la resource policy, o un Deny più in alto. Cinque minuti di diagnosi ordinata, e l’hai trovata.

Se ti sei riconosciuto in Francesco, quello dell’1:30 di notte con la frustrazione alle stelle, il Cloud Practitioner Starter Kit include una sezione sulla logica IAM con esempi pratici proprio sui casi più frequenti di Access Denied. È gratuito, scaricabile in 30 secondi, e ti risparmia esattamente il tipo di nottata che hai appena letto.

E se vuoi capire IAM in profondità, perché chi padroneggia IAM non vede mai più un Access Denied a sorpresa, il pezzo precedente sulla logica del badge aziendale è il punto di partenza naturale.

La prossima volta che apri un browser e leggi Access Denied, ricorda: non sei davanti a un errore. Sei davanti a una domanda. Quale dei tre?

Ti è stata utile questa guida? Condividila con un collega che è ancora alle prese con il suo primo “Access Denied”, gli risparmi un’ora di nottata.