In che modo la logica del codice di applicazione AWS valuta le richieste per consentire o negare l'accesso - AWS Identity and Access Management

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

In che modo la logica del codice di applicazione AWS valuta le richieste per consentire o negare l'accesso

Il codice di applicazione AWS decide se una richiesta inviata a AWS deve essere consentita o rifiutata. AWS valuta tutte le policy applicabili al contesto della richiesta. Di seguito è riportato un riepilogo della logica di valutazione della policy AWS:

  • Per impostazione predefinita, tutte le richieste vengono negate implicitamente con l'eccezione dell'Utente root dell'account AWS, che ha accesso completo.

  • Per essere consentite, le richieste devono essere esplicitamente consentite da una politica o da un insieme di policy che seguono la logica di valutazione riportata di seguito.

  • Un rifiuto esplicito sovrascrive un consenso esplicito.

Il seguente diagramma di flusso fornisce dettagli su come viene presa la decisione sia per l'accesso singolo che per l'accesso multi-account.

Diagramma di flusso della valutazione

  • Rifiuta valutazione: per impostazione predefinita, tutte le richieste vengono rifiutate. Si tratta del cosiddetto rifiuto implicito. Il codice di attuazione AWS valuta tutte le policy all'interno dell'account applicabili alla richiesta. Sono incluse le SCP e le RCP AWS Organizations, le policy basate sulle risorse, le policy basate sulle identità, i limiti delle autorizzazioni IAM e le policy di sessione. In tutte le policy, il codice di attuazione cerca un'istruzione Deny applicabile alla richiesta. Questa azione si chiama rifiuto esplicito. Se il codice di applicazione trova anche un solo rifiuto esplicito applicabile, restituisce Rifiuta come decisione finale. Se non c'è un rifiuto esplicito, la valutazione del codice di attuazione continua.

  • RCP di Organizations: il codice di applicazione valuta le policy di controllo delle risorse (RCP) AWS Organizations che si applicano alla richiesta. Le RCP si applicano alle risorse dell'account a cui sono collegate le RCP. Se il codice di applicazione non trova alcune istruzione Allow applicabile nelle RCP, restituisce Rifiuta come decisione finale. Tieni presente che una policy gestita da AWS chiamata RCPFullAWSAccess viene creata e allegata automaticamente a ogni entità dell'organizzazione, inclusa la root, ogni unità organizzativa e Account AWS quando sono abilitate le RCP. RCPFullAWSAccess non può essere scollegato, quindi ci sarà sempre una istruzione Allow. Se non c'è alcuna RCP oppure se l'RCP consente l'operazione richiesta, la valutazione del codice di applicazione continua.

  • SCP di Organizations: il codice di applicazione valuta le policy di controllo dei servizi (SCP) AWS Organizations che si applicano alla richiesta. Le SCP si applicano alle entità dell'account in cui sono collegate le SCP. Se il codice di applicazione non trova alcune istruzione Allow applicabile nelle SCP, restituisce Rifiuta come decisione finale. Se non c'è alcuna SCP oppure se l'SCP consente l'operazione richiesta, la valutazione del codice di attuazione continua.

  • Policy basate sulle risorse: all'interno dello stesso account, le policy basate sulle risorse influiscono sulla valutazione delle policy in modo diverso a seconda del tipo di principale che accede alla risorsa e al principale consentito nella policy basata sulle risorse. A seconda del tipo di principale, un Allow in una policy basata sulle risorse può comportare una decisione definitiva di Allow, anche se è presente un rifiuto implicito in una policy basata su identità, un limite delle autorizzazioni o una policy di sessione.

    Per la maggior parte delle risorse, è necessario solo un'autorizzazione Allow esplicita per il principale in una policy basata sulle identità o una policy basata sulle risorse per concedere l'accesso. Le policy di affidabilità dei ruoli IAM e le policy delle chiavi KMS sono eccezioni a questa logica, perché devono consentire esplicitamente l'accesso per i principali.

    La policy basata sulle risorse differisce dagli altri tipi di policy se il principale specificato è un utente IAM, un ruolo IAM o un principale di sessione. I principi della sessione includono sessioni come ruolo IAM o una sessione come utente federato IAM. Se una policy basata sulle risorse concede l'autorizzazione direttamente all'utente IAM o al principale di sessione che sta effettuando la richiesta, un rifiuto implicito in una policy basata sull'identità, un limite di autorizzazioni o una policy di sessione non influiscono sulla decisione finale.

    • Ruolo IAM: i criteri basati sulle risorse che concedono le autorizzazioni a un ARN del ruolo IAM sono limitati da un rifiuto implicito in un limite delle autorizzazioni o in una policy di sessione. È possibile specificare l'ARN del ruolo nell'elemento Principal o nella chiave di condizione aws:PrincipalArn. In entrambi i casi, il principale che effettua la richiesta è la sessione del ruolo IAM.

      I limiti delle autorizzazioni e le policy di sessione non limitano le autorizzazioni concesse tramite la chiave di condizione aws:PrincipalArn con un carattere jolly (*) nell'elemento Principal, a meno che le policy basate sulle identità non contengano un rifiuto esplicito. Per ulteriori informazioni, consulta IAMruoli principali.

      Esempio di ARN di ruolo

      arn:aws:iam::111122223333:role/examplerole

    • Sessione come ruolo IAM: all'interno dello stesso account, le policy basate sulle risorse che concedono le autorizzazioni all'ARN della sessione come ruolo IAM concedono le autorizzazioni direttamente alla sessione come ruolo assunto. Le autorizzazioni concesse direttamente a una sessione non sono limitate da un rifiuto implicito in una policy basata su identità, da un limite delle autorizzazioni o da una policy di sessione. Quando si assume un ruolo e si effettua una richiesta, il principale che effettua la richiesta è l'ARN della sessione come ruolo IAM e non l'ARN del ruolo stesso. Per ulteriori informazioni, consulta Principali della sessione come ruolo.

      Esempio di ARN della sessione come ruolo

      arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname

    • Utente IAM: all'interno dello stesso account, le politiche basate sulle risorse che concedono autorizzazioni all'ARN di un utente IAM (ovvero, non una sessione come utente federato) non sono limitate da un rifiuto implicito in una policy basata su identità o in un limite delle autorizzazioni.

      Esempio di ARN dell'utente IAM

      arn:aws:iam::111122223333:user/exampleuser

    • Sessioni come utente federato IAM: una sessione come utente federato IAM è una sessione creata chiamando GetFederationToken. Quando un utente federato effettua una richiesta, il principale che effettua la richiesta è l'ARN dell'utente federato e non l'ARN dell'utente IAM che ha eseguito la federazione. All'interno dello stesso account, le policy basate sulle risorse che concedono le autorizzazioni all'ARN dell'utente federato concedono le autorizzazioni direttamente alla sessione. Le autorizzazioni concesse direttamente a una sessione non sono limitate da un rifiuto implicito in una policy basata su identità, da un limite delle autorizzazioni o da una policy di sessione.

      Tuttavia, se una policy basata sulle risorse concede l'autorizzazione all'ARN dell'utente IAM che ha eseguito la federazione, le richieste fatte dall'utente federato durante la sessione sono limitate da un rifiuto implicito in un limite di autorizzazione o in una policy di sessione.

      Esempio di ARN della sessione come utente federato IAM

      arn:aws:sts::111122223333:federated-user/exampleuser

  • Policy basate su identità: il codice di applicazione verifica le policy basate su identità per il principale. Per un utente IAM, queste includono le policy utente e le policy dei gruppi a cui appartiene l'utente. Se non ci sono policy basate su identità o istruzioni nelle policy basata su identità che consentono l'operazione richiesta, la richiesta viene rifiutata implicitamente e il codice di applicazione restituisce Rifiuta come decisione finale. Se un'istruzione in qualsiasi policy basata su identità applicabile consente l'operazione richiesta, la valutazione del codice continua.

  • Limiti delle autorizzazioni IAM: il codice di applicazione controlla se l'entità IAM utilizzata dal principale ha un limite delle autorizzazioni. Se la policy utilizzata per impostare il limite delle autorizzazioni non consente l'operazione richiesta, la richiesta viene rifiutata implicitamente. Il codice di attuazione restituisce Deny (Rifiuta) come decisione finale. Se non c'è alcun limite delle autorizzazioni oppure se il limite delle autorizzazioni consente l'operazione richiesta, la valutazione del codice continua.

  • Policy di sessione: il codice di applicazione verifica se il principale è un principale di sessione. I principali di sessione includono una sessione come ruolo IAM o una sessione come utente federato IAM. Se il principale non è un principale di sessione, il codice di attuazione restituisce Allow (Consenti) come decisione finale.

    Per i principali della sessione, il codice di applicazione verifica se una policy di sessione è passata nella richiesta. Puoi passare una policy di sessione utilizzando l'AWS CLI o l'API AWS per ottenere le credenziali temporanee per un ruolo o un utente federato IAM. Se non hai approvato una policy di sessione, viene creata una policy di sessione predefinita e il codice di applicazione restituisce Consenti come decisione finale.

    • Se una policy di sessione è presente e non consente l'operazione richiesta, la richiesta viene rifiutata implicitamente. Il codice di attuazione restituisce Deny (Rifiuta) come decisione finale.

    • Il codice di applicazione verifica se il principale è una sessione del ruolo. Se il principale è una sessione come ruolo, la richiesta è autorizzata. In caso contrario, la richiesta viene negata implicitamente e iI codice di applicazione restituisce Rifiuta come decisione finale.

    • Se una policy di sessione è presente e consente l'operazione richiesta, il codice di attuazione restituisce Consenti come decisione finale.