Padroneggiare AWS IAM: Risolvere Efficacemente gli Errori di Accesso Negato

Gli errori AWS IAM AccessDenied significano che AWS ha valutato la tua richiesta e non ha trovato un percorso di autorizzazione efficace. La soluzione più rapida non è indovinare una policy più ampia, ma identificare l'esatta azione, risorsa, principale e contesto di condizione che AWS ha valutato.

La maggior parte dei fallimenti IAM deriva da uno di quattro punti: nessun Allow corrispondente, un Deny esplicito, un limite di autorizzazioni o una policy di controllo dei servizi che limita l'identità, oppure una condizione che non corrisponde alla richiesta.

Inizia con la Logica di Valutazione IAM

AWS parte da un rifiuto predefinito. Una richiesta è consentita solo quando una policy applicabile la permette e nessuna policy applicabile la nega.

Un Deny esplicito prevale su ogni Allow. Tale rifiuto può provenire da una policy di identità, policy di risorsa, limite di autorizzazioni, policy di sessione, policy di controllo dei servizi o altro tipo di policy applicabile.

Per l'accesso nello stesso account, le policy di identità e le policy di risorsa spesso lavorano insieme. Per l'accesso tra account, di solito è necessaria l'autorizzazione su entrambi i lati: l'identità del chiamante deve essere autorizzata a effettuare la richiesta, e la risorsa di destinazione o l'account di destinazione deve fidarsi o autorizzare quel chiamante.

Cattura la Richiesta Fallita Esatta

Prima di modificare le policy, cattura questi dettagli:

• Principale: utente, ruolo, sessione ruolo-assunto o principale del servizio AWS.
• Azione: l'operazione API, come s3:GetObject o ec2:RunInstances.
• Risorsa: l'ARN o l'ID della risorsa.
• Regione e account.
• Condizioni: IP di origine, endpoint VPC, MFA, tag, contesto di crittografia o regione richiesta.

CloudTrail è di solito la fonte migliore. Cerca l'evento fallito intorno al momento dell'errore e ispeziona eventName, userIdentity, resources, errorCode e errorMessage.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --max-results 10

CloudTrail non spiega ogni decisione di autorizzazione in dettaglio perfetto, ma spesso fornisce l'azione mancante e il principale reale. Questo da solo cattura molti errori di ruolo-assunto e nome-sessione.

Usa Strumenti di Simulazione e Analisi degli Accessi

Il Simulatore di Policy IAM può testare molte domande sulle policy basate sull'identità prima di modificare le autorizzazioni di produzione. Seleziona l'utente o il ruolo, scegli l'azione del servizio, fornisci l'ARN della risorsa quando possibile e includi le chiavi di condizione pertinenti.

Per account e servizi AWS recenti, controlla anche il messaggio di accesso negato stesso. Alcuni servizi restituiscono un messaggio di errore di autorizzazione codificato. Se hai l'autorizzazione, decodificalo con STS:

aws sts decode-authorization-message \
  --encoded-message '<messaggio-codificato-dall-errore>'

Quel messaggio decodificato può mostrare quale tipo di policy ha contribuito al rifiuto.

IAM Access Analyzer è utile per domande su policy di risorsa e tra account. Può aiutarti a trovare accessi esterni non intenzionali e convalidare alcune policy prima della distribuzione.

Controlla Ogni Livello di Policy

Le policy basate sull'identità sono allegate a utenti, gruppi e ruoli. Rispondono a cosa può fare l'identità.

Le policy basate sulla risorsa sono allegate a risorse come bucket S3, chiavi KMS, code SQS, funzioni Lambda e policy di fiducia dei ruoli. Rispondono a chi può usare quella risorsa o assumere quel ruolo.

I limiti di autorizzazioni impostano le autorizzazioni massime per un utente o ruolo. Non concedono accesso da soli. Le autorizzazioni effettive sono l'intersezione tra la policy di identità e il limite.

Le policy di controllo dei servizi in AWS Organizations impostano le autorizzazioni massime per account o unità organizzative. Anche le SCP non concedono accesso da sole. Possono bloccare un'azione anche quando una policy IAM la permette.

Le policy di sessione e i tag di autorizzazione possono anche ridurre l'accesso per sessioni di ruolo assunto. Se un ruolo funziona in un percorso ma fallisce quando assunto da un lavoro CI, confronta la policy di sessione, i tag di sessione e le condizioni della policy di fiducia.

Pattern Comuni di AccessDenied

Azioni Dipendenti Mancanti

Alcune operazioni AWS richiedono più dell'azione ovvia. Ad esempio, avviare un'istanza EC2 crittografata può richiedere autorizzazioni EC2 più autorizzazioni KMS per la chiave. CloudTrail e la documentazione del servizio sono i tuoi migliori riferimenti per le azioni dipendenti.

ARN di Risorsa Errato

Gli ARN a livello di bucket S3 e a livello di oggetto sono diversi:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

arn:aws:s3:::my-bucket copre il bucket. arn:aws:s3:::my-bucket/* copre gli oggetti nel bucket. Molti errori S3 derivano dalla concessione di uno quando la chiamata API necessita dell'altro.

Disallineamento delle Condizioni

Le condizioni devono corrispondere esattamente al contesto della richiesta. Una policy che consente l'accesso solo attraverso un endpoint VPC negherà le richieste da un altro endpoint, dall'endpoint pubblico AWS o da una regione diversa se la condizione controlla quella regione.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-sensitive-data",
    "arn:aws:s3:::my-sensitive-data/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

Quella dichiarazione nega le richieste HTTP e permette alle richieste HTTPS di continuare attraverso il resto della valutazione della policy. Non concede accesso da sola.

Lacune nella Policy delle Chiavi KMS

KMS è una fonte comune di errori di accesso confusi. Una policy IAM può permettere kms:Decrypt, ma la policy della chiave deve anche permettere direttamente il principale o permettere all'account di delegare l'accesso tramite policy IAM.

Controlla la policy della chiave, le concessioni, le condizioni del contesto di crittografia e il servizio che utilizza la chiave.

Un Flusso Pratico di Risoluzione dei Problemi

Prima, riproduci o cattura la chiamata fallita. Ottieni l'azione API esatta e il principale da CloudTrail.

Successivamente, cerca rifiuti espliciti in SCP, policy di risorsa, limiti di autorizzazioni e policy di identità. I rifiuti espliciti fanno risparmiare tempo perché prevalgono su tutto il resto.

Poi conferma che esiste un allow corrispondente per l'azione e la risorsa esatte. Includi azioni dipendenti e risorse correlate come chiavi KMS, ruoli IAM passati ai servizi, interfacce di rete o gruppi di log.

Infine, testa con la modifica di policy più ristretta possibile. Evita di risolvere un rifiuto sconosciuto con Action: "*" o Resource: "*"; questo nasconde il problema e crea un nuovo rischio di sicurezza.

L'abitudine utile è trattare ogni AccessDenied come un problema di evidenza. Una volta che conosci il principale, l'azione, la risorsa e il livello di policy, la soluzione è di solito piccola e chiara.