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

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 policy o da un insieme di policy che seguono la logica di valutazione riportata di seguito.

  • Un rifiuto esplicito sovrascrive un consenso esplicito.

La valutazione della policy può variare a seconda che la richiesta riguardi un singolo account oppure più account. Per i dettagli su come viene presa una decisione di valutazione della policy per un ruolo o un utente IAM all'interno di un singolo account, consulta Valutazione delle policy per le richieste all'interno di un singolo account. Per i dettagli su come viene presa una decisione di valutazione della policy per le richieste tra più account, consulta Logica di valutazione della policy multiaccount.

  • 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 AWS 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 AWS 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. Le policy basate sulle risorse per servizi diversi da IAM e AWS KMS potrebbero richiedere anche una dichiarazione esplicita Allow all'interno dello stesso account per concedere l'accesso. Per ulteriori informazioni, consulta la documentazione per il servizio specifico che stai utilizzando.

    Per le richieste di valutazione delle policy per un singolo account, 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 principali della sessione includono sessioni di ruolo IAM o principali utente federato AWS STS. 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

    • Principale utente federato AWS STS: una sessione come utente federato è 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 di sessione utente federato

      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 AWS STS. 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 la AWS CLI o l'API AWS per ottenere le credenziali temporanee per un ruolo o un principale utente federato AWS STS. 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 di ruolo, la richiesta è Consentita. 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.