In che modo la logica del codice di AWS applicazione valuta le richieste di 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 AWS applicazione valuta le richieste di consentire o negare l'accesso

Il codice di AWS applicazione decide se una richiesta inviata a AWS debba essere accolta o rifiutata. AWS valuta tutte le politiche applicabili al contesto della richiesta. Di seguito è riportato un riepilogo della logica di valutazione delle AWS politiche.

  • 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 politiche che seguono la logica di valutazione riportata di seguito.

  • Un rifiuto esplicito ha la precedenza su un permesso esplicito.

Il seguente diagramma di flusso fornisce dettagli su come viene presa la decisione per l'accesso sia da un singolo account che da più 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 AWS applicazione valuta tutte le politiche all'interno dell'account che si applicano alla richiesta. Queste includono AWS Organizations SCPs eRCPs, politiche basate sulle risorse, politiche basate sull'identità, limiti di autorizzazioni e politiche di sessione. IAM 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 rileva anche una sola negazione esplicita applicabile, restituisce una decisione finale di Deny. Se non c'è un rifiuto esplicito, la valutazione del codice di attuazione continua.

  • Organizzazioni RCPs: il codice di applicazione valuta le politiche di controllo AWS Organizations delle risorse (RCPs) che si applicano alla richiesta. RCPssi applicano alle risorse dell'account a cui RCPs sono allegate. Se il codice di esecuzione non trova alcuna Allow dichiarazione applicabile nelRCPs, il codice di esecuzione restituisce una decisione finale di Deny. Se non esisteRCP, o se RCP consente l'azione richiesta, la valutazione del codice di esecuzione continua.

  • Organizzazioni SCPs: il codice di applicazione valuta le politiche di controllo del AWS Organizations servizio (SCPs) che si applicano alla richiesta. SCPssi applicano ai principali dell'account a cui SCPs sono allegati. Se il codice di esecuzione non trova alcuna Allow dichiarazione applicabile nelSCPs, il codice di esecuzione restituisce una decisione finale di Deny. Se non esisteSCP, o se SCP consente l'azione richiesta, la valutazione del codice di esecuzione 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, è sufficiente un'indicazione esplicita Allow per il principale in una politica basata sull'identità o in una politica basata sulle risorse per concedere l'accesso. IAMi role trust policy e i KMSkey policy sono eccezioni a questa logica, in quanto devono consentire esplicitamente l'accesso ai principali.

    La logica delle policy basata sulle risorse si differenzia dagli altri tipi di policy se il principale specificato è un IAM utente, un ruolo o un principale di sessione. IAM I principali della sessione includono sessioni di IAM ruolo o una sessione utente federata. IAM Se una politica basata sulle risorse concede l'autorizzazione direttamente all'IAMutente o al responsabile della sessione che effettua la richiesta, una negazione implicita in una politica basata sull'identità, un limite di autorizzazioni o una politica di sessione non influisce sulla decisione finale.

    • IAMruolo: le politiche basate sulle risorse che concedono le autorizzazioni a un ruolo sono limitate da una negazione implicita in un limite di autorizzazioni o in un criterio di sessioneIAM. ARN È possibile specificare il ruolo nell'elemento Principal o ARN nella chiave di condizione. aws:PrincipalArn In entrambi i casi, il principale che effettua la richiesta è la sessione di IAM ruolo.

      I limiti delle autorizzazioni e le politiche di sessione non limitano le autorizzazioni concesse utilizzando la chiave aws:PrincipalArn condition con un carattere jolly (*) nell'elemento Principal, a meno che le politiche basate sull'identità non contengano un rifiuto esplicito. Per ulteriori informazioni, consulta IAMprincipi di ruolo.

      Ruolo di esempio ARN

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

    • IAMsessione di ruolo: all'interno dello stesso account, le politiche basate sulle risorse che concedono le autorizzazioni a una sessione di IAM ruolo le ARN concedono direttamente alla sessione di ruolo presunta. 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 è la sessione di IAM ruolo ARN e non la responsabile del ARN ruolo stesso. Per ulteriori informazioni, consulta Principali della sessione come ruolo.

      Esempio di sessione di ruolo ARN

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

    • IAMutente: all'interno dello stesso account, le politiche basate sulle risorse che concedono autorizzazioni a un IAM utente ARN (che non è una sessione utente federata) non sono limitate da una negazione implicita in un limite di policy o autorizzazioni basato sull'identità.

      Utente di esempio IAM ARN

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

    • IAMsessioni utente federate: una sessione utente IAM federata è una sessione creata chiamando. GetFederationToken Quando un utente federato effettua una richiesta, il principale che effettua la richiesta è l'utente federato ARN e non l'utente che ha effettuato la ARN federazione. IAM All'interno dello stesso account, le politiche basate sulle risorse che concedono le autorizzazioni a un utente federato concedono le autorizzazioni direttamente alla sessione. ARN 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 politica basata sulle risorse concede l'autorizzazione all'IAMutente che ha effettuato la federazione, le ARN richieste effettuate dall'utente federato durante la sessione sono limitate da una negazione implicita in un limite di autorizzazione o in un criterio di sessione.

      Esempio di sessione utente federata IAM ARN

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

  • Politiche basate sull'identità: il codice di applicazione verifica le politiche basate sull'identità del principale. Per un IAM utente, queste includono le politiche utente e le politiche dei gruppi a cui l'utente appartiene. Se non ci sono politiche basate sull'identità o non ci sono dichiarazioni nelle politiche basate sull'identità che consentano l'azione richiesta, la richiesta viene implicitamente negata e il codice di applicazione restituisce una decisione finale di Deny. Se una dichiarazione in una delle politiche basate sull'identità applicabili consente l'azione richiesta, la valutazione del codice continua.

  • IAMlimiti delle autorizzazioni: il codice di applicazione verifica se l'IAMentità utilizzata dal principale ha un limite di 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 esiste un limite di autorizzazioni o se il limite delle autorizzazioni consente l'azione richiesta, la valutazione del codice continua.

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

    Per i principali di sessione, il codice di applicazione verifica se nella richiesta è stata inserita una politica di sessione. È possibile passare una politica di sessione mentre si utilizza AWS CLI o AWS API per ottenere credenziali temporanee per un ruolo o un utente IAM federato. Se non hai approvato un criterio di sessione, viene creato un criterio di sessione predefinito e il codice di applicazione restituisce la decisione finale di Allow.

    • 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 di ruolo. Se il principale è una sessione come ruolo, la richiesta è autorizzata. In caso contrario, la richiesta viene implicitamente respinta e il codice di esecuzione restituisce una decisione finale di Deny.

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