In che modo la logica del codice di applicazione AWS valuta le richieste per 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 policy che seguono la logica di valutazione riportata di seguito.

• Un rifiuto esplicito sovrascrive un consenso esplicito.

La valutazione delle politiche può variare a seconda che la richiesta riguardi un singolo account o una richiesta tra più account. Per i dettagli su come viene presa una decisione di valutazione delle policy per un ruolo o un utente IAM all'interno di un singolo account, consultaValutazione delle policy per le richieste all'interno di un singolo account. Per i dettagli su come viene presa una decisione di valutazione delle politiche per le richieste tra più account, consultaCross-account policy evaluation logic.

• 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 e RCPs, politiche basate sulle risorse, politiche basate sull'identità, limiti delle autorizzazioni IAM e politiche 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.

• Organizzazioni RCPs: il codice di applicazione valuta le politiche di controllo AWS Organizations delle risorse (RCPs) che si applicano alla richiesta. RCPs si applicano alle risorse dell'account a cui RCPs sono allegate. Se il codice di esecuzione non trova alcuna Allow dichiarazione applicabile nel RCPs, il codice di esecuzione restituisce una decisione finale di Deny. Tieni presente che una policy AWS gestita chiamata RCPFullAWSAccess viene automaticamente creata e allegata a ogni entità dell'organizzazione, inclusa la root, ogni unità organizzativa e Account AWS quando RCPs è abilitata. RCPFullAWSAccessnon può essere staccata, quindi ci sarà sempre una Allow dichiarazione. Se non c'è alcuna RCP oppure se l'RCP consente l'operazione richiesta, la valutazione del codice di applicazione continua.

• Organizzazioni SCPs: il codice di applicazione valuta le politiche di controllo del AWS Organizations servizio (SCPs) che si applicano alla richiesta. SCPs si applicano ai principali dell'account a cui SCPs sono allegati. Se il codice di esecuzione non trova alcuna Allow dichiarazione applicabile nel SCPs, il codice di esecuzione restituisce una decisione finale di Deny. 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. Politiche basate sulle risorse per servizi diversi da IAM e AWS KMS possono anche richiedere una Allow dichiarazione esplicita all'interno dello stesso account per concedere l'accesso. Per ulteriori informazioni, consulta la documentazione del servizio specifico con cui lavori.

  Per le richieste di valutazione delle policy basate su un solo account, la logica delle policy basata sulle risorse differisce dagli altri tipi di policy se il principale specificato è un utente IAM, un ruolo IAM o un responsabile 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 Principali ruolo IAM.

    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 mentre usi l' AWS API AWS CLI o per ottenere 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.