View a markdown version of this page

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

Il codice di AWS applicazione decide se una richiesta inviata a AWS deve 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 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 Cross-account logica di valutazione delle politiche.

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

  • AWS Organizations RCP: il codice di applicazione valuta AWS Organizations le politiche di controllo delle risorse (RCP) applicabili 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.

  • AWS Organizations SCP: il codice di applicazione valuta le politiche di controllo del AWS Organizations servizio (SCP) applicabili 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.

  • Resource-based politiche: all'interno dello stesso account, le politiche basate sulle risorse influiscono sulla valutazione delle politiche in modo diverso a seconda del tipo di principale che accede alla risorsa e del principale consentito nella politica 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 politiche di fiducia del ruolo IAM e le politiche chiave del KMS sono eccezioni a questa logica, perché devono consentire esplicitamente l'accesso ai committenti. AWS Elementi della policy JSON: Principale Resource-based politiche 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 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: Resource-based le politiche che concedono autorizzazioni a un ruolo IAM ARN sono limitate da una negazione implicita in un limite di 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

    • AWS STS utente principale federato: una sessione utente federata è 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

  • Identity-based politiche: il codice di applicazione controlla le politiche basate sull'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 titolari delle sessioni includono una sessione di ruolo IAM o una sessione utente federata 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 mentre usi l' AWS API AWS CLI or per ottenere credenziali temporanee per un ruolo o un utente principale AWS STS federato. 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.