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à. # Logica di valutazione delle policy Quando un principale tenta di utilizzare l' Console di gestione AWS, l' AWS API o il AWS CLI, quel principale invia una *richiesta* a. AWS Quando un AWS servizio riceve la richiesta, AWS completa diversi passaggi per determinare se consentire o rifiutare la richiesta. 1. **Autenticazione**: autentica AWS innanzitutto il principale che effettua la richiesta, se necessario. Questo passaggio non è necessario per alcuni servizi, ad esempio Amazon S3, che consentono alcune richieste da parte di utenti anonimi. 1. **[Elaborazione del contesto della richiesta](reference_policies_evaluation-logic_policy-eval-reqcontext.md)**— AWS elabora le informazioni raccolte nella richiesta per determinare quali politiche si applicano alla richiesta. 1. **[In che modo la logica del codice di AWS applicazione valuta le richieste di consentire o negare l'accesso](reference_policies_evaluation-logic_policy-eval-denyallow.md)**— AWS valuta tutti i tipi di policy e l'ordine delle policy influisce sul modo in cui vengono valutate. AWS quindi elabora le politiche in base al contesto della richiesta per determinare se la richiesta è consentita o rifiutata. ## Valutazione delle policy basate su identità con policy basate su risorse Le policy basate su identità e le policy basate su risorse concedono autorizzazioni alle identità o alle risorse a cui sono collegate. Quando un'entità IAM (utente o ruolo) richiede l'accesso a una risorsa all'interno dello stesso account, AWS valuta tutte le autorizzazioni concesse dalle politiche basate sull'identità e sulle risorse. Le autorizzazioni risultanti sono le autorizzazioni totali dei due tipi. Se un'azione è consentita da una policy basata sull'identità, una policy basata sulle risorse o entrambe, allora consente l'azione. AWS Un rifiuto esplicito in una di queste policy sostituisce l'autorizzazione. ![\[Valutazione delle policy basate su identità e delle policy basate su risorse\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/permissions_policies_effective.png) ## Valutazione delle policy basate su identità con i limiti delle autorizzazioni Quando si AWS valutano le politiche basate sull'identità e i limiti delle autorizzazioni per un utente, le autorizzazioni risultanti sono l'intersezione delle due categorie. Ciò significa che quando aggiungi un limite delle autorizzazioni a un utente con policy basate su identità esistenti, potresti ridurre il numero di operazioni che l'utente può eseguire. Di contro, quando rimuovi un limite delle autorizzazioni da un utente, potresti aumentare il numero di operazioni che può eseguire. Un rifiuto esplicito in una di queste policy sostituisce l'autorizzazione. Per informazioni su come altri tipi di policy vengono valutati con i limiti delle autorizzazioni, consulta [Valutazione delle autorizzazioni valide con i limiti](access_policies_boundaries.md#access_policies_boundaries-eval-logic). ![\[Valutazione delle policy basate su identità e dei limiti delle autorizzazioni\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/permissions_boundary.png) ## Valutazione delle AWS Organizations SCPs politiche basate sull'identità con o RCPs Quando un utente appartiene a un account membro di un'organizzazione e accede a una risorsa per la quale non è configurata una politica basata sulle risorse, le autorizzazioni risultanti sono l'intersezione tra le politiche dell'utente, le politiche di controllo dei servizi () e le politiche di controllo delle risorse (SCPsRCP). Ciò significa che un'azione deve essere consentita da tutti e tre i tipi di policy. Un rifiuto esplicito nella policy basata sull'identità, una SCP o una RCP ha la precedenza sull'autorizzazione. ![\[Valutazione delle politiche basate sull'identità e/o SCPs RCPs\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/permissions_scp-idp.png) Puoi scoprire [se il tuo account è un membro di un'organizzazione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account) in AWS Organizations. I membri dell'organizzazione potrebbero essere influenzati da una SCP o una RCP. Per visualizzare questi dati utilizzando il AWS CLI comando o l'operazione AWS API, è necessario disporre delle autorizzazioni per l'`organizations:DescribeOrganization`azione per l'entità. AWS Organizations È necessario disporre di autorizzazioni aggiuntive per eseguire l'operazione nella AWS Organizations console. Per sapere se un SCP o RCP sta negando l'accesso a una richiesta specifica o per modificare le autorizzazioni effettive, contatta l'amministratore. AWS Organizations # Elaborazione del contesto della richiesta *Quando AWS valuta e autorizza una richiesta, assembla le informazioni sulla richiesta in un contesto di richiesta.* Il contesto della richiesta contiene tutte le informazioni che possono essere utilizzate nella valutazione delle policy. + **Principale**: l’utente, il ruolo o il principale utente federato che ha inviato la richiesta. Le informazioni sull'entità principale includono le policy associate a tale entità principale. + **Azioni**: una o più azioni che il principale desidera eseguire. + **Risorse**: uno o più oggetti AWS risorsa su cui vengono eseguite le azioni o le operazioni. + **Dati sulla risorsa** – I dati correlati alla risorsa che viene richiesta. Possono essere incluse informazioni quali un nome di tabella di DynamoDB o un tag su un'istanza Amazon EC2. + **Dati di ambiente**: informazioni sull'indirizzo IP, l'agente utente, lo stato SSL abilitato o l'ora del giorno. Queste informazioni vengono confrontate con le policy applicabili per determinare se accettare o rifiutare la richiesta. È possibile organizzare queste informazioni sulle proprietà utilizzando il modello **Principal**, **Action**, **Resource** and **Condition** (PARC) per comprendere meglio come vengono valutate AWS le politiche. ## Comprensione del modello PARC Il modello PARC rappresenta il contesto della richiesta basato sui quattro elementi JSON nel linguaggio della policy: + [Principal](reference_policies_elements_principal.md): l’entità che effettua la richiesta. Un principale rappresenta un utente umano o un carico di lavoro programmatico che può essere autenticato e quindi autorizzato a eseguire azioni negli Account AWS. + [Action](reference_policies_elements_action.md): l’operazione in corso. Spesso l’operazione verrà mappata a un’operazione API. + [Resource](reference_policies_elements_resource.md): la risorsa AWS su cui viene eseguita l’operazione. + [Condition](reference_policies_elements_condition.md): vincoli aggiuntivi che devono essere soddisfatti affinché la richiesta sia consentita. Di seguito è illustrato un esempio di come il modello PARC potrebbe rappresentare un contesto della richiesta: ``` Principal: AIDA123456789EXAMPLE Action: s3:CreateBucket Resource: arn:aws:s3:::amzn-s3-demo-bucket1 Context: - aws:UserId=AIDA123456789EXAMPLE:BobsSession - aws:PrincipalAccount=123456789012 - aws:PrincipalOrgId=o-example - aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR - aws:MultiFactorAuthPresent=true - aws:CurrentTime=... - aws:EpochTime=... - aws:SourceIp=... - aws:PrincipalTag/dept=123 - aws:PrincipalTag/project=blue - aws:RequestTag/dept=123 ``` ## Importanza del contesto della richiesta Comprendere il contesto della richiesta e il modo in cui interagisce con la valutazione delle policy è fondamentale per le seguenti finalità: + Risoluzione dei problemi di accesso + Progettazione di policy efficaci e sicure + Comprensione dell’ambito completo delle autorizzazioni concesse da una policy + Previsione dell’esito delle valutazioni delle policy in vari scenari Visualizzando il contesto della richiesta utilizzando il modello PARC, è possibile comprendere più facilmente come AWS prende le decisioni di autorizzazione e progetta le politiche in modo più efficace. ## Come AWS utilizza il contesto della richiesta Durante la valutazione delle politiche, AWS confronta le informazioni nel contesto della richiesta con le informazioni specificate in tutte le politiche applicabili. Ciò include politiche basate sull'identità, politiche basate sulle risorse, limiti delle autorizzazioni IAM, Organizations, Organizations e policy di sessione. SCPs RCPs Per ogni tipo di policy, utilizza il contesto della richiesta per verificare AWS : + Se la policy si applica alla richiesta in base al principale. + Se l’operazione richiesta è consentita sulla risorsa specificata. + Se le condizioni specificate nella policy sono soddisfatte dal contesto della richiesta. Il modo in cui AWS valuta le politiche dipende dai tipi di politiche che si applicano al contesto della richiesta. Questi tipi di policy possono essere utilizzati in un singolo Account AWS. Per ulteriori informazioni su questi tipi di policy, consulta [Politiche e autorizzazioni in AWS Identity and Access Management](access_policies.md). Per informazioni su come AWS valuta le politiche per l'accesso tra account diversi, consulta. [Cross-account policy evaluation logic](reference_policies_evaluation-logic-cross-account.md) + **AWS Organizations politiche di controllo delle risorse (RCPs)**: AWS Organizations RCPs specificano le autorizzazioni massime disponibili per le risorse all'interno degli account di un'organizzazione o di un'unità organizzativa (OU). RCPs si applicano alle risorse degli account dei membri e influiscono sulle autorizzazioni effettive per i responsabili, incluse le Utente root dell'account AWS, indipendentemente dal fatto che i responsabili appartengano all'organizzazione. RCPs non si applicano alle risorse dell'account di gestione dell'organizzazione e alle chiamate effettuate da ruoli collegati al servizio. Se una RCP è presente, le autorizzazioni concesse da policy basate su identità e policy basate su risorse alle risorse negli account membri sono effettive solo se l’RCP consente l’operazione. + **AWS Organizations policy di controllo del servizio (SCPs)**: AWS Organizations SCPs specificano le autorizzazioni massime disponibili per i responsabili all'interno degli account di un'organizzazione o di un'unità organizzativa (OU). SCPs si applicano ai responsabili degli account dei membri, compresi ciascuno. Utente root dell'account AWS Se una SCP è presente, le autorizzazioni concesse da policy basate su identità e policy basate su risorse ai principali negli account membri sono effettive solo se l’SCP consente l’operazione. Le uniche eccezioni sono i principali dell'account di gestione dell'organizzazione e i ruoli collegati ai servizi. + **Policy basate sulle risorse**: le policy basate sulle risorse concedono le autorizzazioni per i principali specificati nella policy. Le autorizzazioni definiscono ciò che l'entità principale può fare con la risorsa a cui è collegata la policy. + **Limiti delle autorizzazioni**: i limiti delle autorizzazioni sono una funzionalità avanzata che imposta il numero massimo di autorizzazioni che una policy basata su identità può concedere a un’entità IAM (utente o ruolo). Quando si imposta un limite delle autorizzazioni per un'entità, l'entità può eseguire solo le operazioni consentite dalle sue policy basate su identità e dai suoi limiti delle autorizzazioni. In alcuni casi, un rifiuto implicito in un limite delle autorizzazioni può limitare le autorizzazioni concesse da una policy basata sulle risorse. Per ulteriori informazioni, consulta [In che modo la logica del codice di AWS applicazione valuta le richieste di consentire o negare l'accesso](reference_policies_evaluation-logic_policy-eval-denyallow.md). + **Policy basate su identità**: le policy basate su identità sono collegate a un'identità IAM (utente, gruppo di utenti o ruolo) e concede le autorizzazioni per entità IAM (utenti e ruoli). Se a una richiesta si applicano solo politiche basate sull'identità, AWS verifica che tutte queste politiche ne accertino almeno una. `Allow` + **Policy di sessione**: le policy di sessione sono policy che si inviano come parametro quando si crea in modo programmatico una sessione temporanea per un ruolo o una sessione utente federato. Per creare una sessione del ruolo in modo programmatico, è possibile utilizzare una delle operazioni API `AssumeRole*`. Quando esegui questa operazione e passi le policy di sessione, le autorizzazioni della sessione risultante sono l'intersezione della policy basata su identità dell'utente dell'entità IAM e delle policy di sessione. Per creare una sessione per l'utente federato, si utilizzano le chiavi di accesso dell'utente IAM per chiamare in modo programmatico l'operazione API `GetFederationToken`. Per ulteriori informazioni, consulta [Policy di sessione](access_policies.md#policies_session). Occorre ricordare che un rifiuto esplicito in una qualsiasi di queste policy sostituisce l'autorizzazione. **Nota** **AWS Organizations le politiche dichiarative consentono di** dichiarare e applicare in modo centralizzato la configurazione desiderata per un determinato Servizio AWS aspetto su larga scala all'interno dell'organizzazione. Poiché le policy dichiarative vengono applicate direttamente a livello di servizio, non influiscono direttamente sulle richieste di valutazione delle policy e non sono incluse nel contesto della richiesta. Per ulteriori informazioni, consulta [Politiche dichiarative](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) nella Guida per l'utente. AWS Organizations ## Esempio di valutazione delle policy utilizzando il modello PARC Per illustrare come il contesto della richiesta interagisce con la valutazione delle policy, prendiamo in considerazione un esempio di policy: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1", "Condition": { "StringEquals": { "aws:PrincipalTag/dept": "123" } } } ] } ``` ------ In questo esempio, la policy consentirebbe l’operazione `CreateBucket` solo quando il contesto della richiesta include un valore `aws:PrincipalTag/dept` di “123” e la risorsa corrisponde al nome del bucket `amzn-s3-demo-bucket1`. La tabella seguente mostra come AWS utilizza il contesto della richiesta per valutare questa policy e prendere decisioni di autorizzazione. | Policy | Contesto della richiesta | Risultato della valutazione | | --- | --- | --- | | 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
| 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123
| **Partita** | | 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
| 
Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123
| **Nessuna corrispondenza** | | 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
| 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=321
| **Nessuna corrispondenza** | | 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
| 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
Nessun `aws:PrincipalTag` nella richiesta. | **Nessuna corrispondenza** | # 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 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](reference_policies_evaluation-logic_policy-eval-basics.md). Per i dettagli su come viene presa una decisione di valutazione della policy per le richieste tra più account, consulta [Cross-account policy evaluation logic](reference_policies_evaluation-logic-cross-account.md). + **Rifiuta valutazione**: per impostazione predefinita, tutte le richieste vengono rifiutate. Si tratta del cosiddetto [rifiuto implicito](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). 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](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). 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 RCPs**— Il codice di applicazione valuta le politiche di controllo AWS Organizations delle risorse () che si applicano alla richiesta. RCPs 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. `RCPFullAWSAccess`non 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. + **AWS Organizations SCPs**— Il codice di applicazione valuta le politiche di controllo del AWS Organizations servizio (SCPs) che si applicano alla richiesta. SCPs si applicano ai capitali del conto 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](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies) e [le policy delle chiavi KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) sono eccezioni a questa logica, perché devono consentire esplicitamente l'accesso per [i principali](reference_policies_elements_principal.md). 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](reference_policies_elements_principal.md#principal-role-session) o [principali utente federato AWS STS](reference_policies_elements_principal.md#sts-session-principals). 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 (\$1) nell'elemento Principal, a meno che le policy basate sulle identità non contengano un rifiuto esplicito. Per ulteriori informazioni, consulta [Principali ruolo IAM](reference_policies_elements_principal.md#principal-roles). **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](reference_policies_elements_principal.md#principal-role-session). **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 principale utente federato**: una sessione utente federata è una sessione creata mediante chiamata. [`GetFederationToken`](id_credentials_temp_request.md#api_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 della sessione includono una sessione di ruolo IAM o una sessione utente AWS STS federata. 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. # Valutazione delle policy per le richieste all'interno di un singolo account ## Valutazione della policy per un ruolo IAM Il seguente diagramma di flusso fornisce dettagli su come viene presa una decisione di valutazione della policy per un ruolo IAM all’interno di un singolo account. ![\[Diagramma di flusso di valutazione per un ruolo IAM all’interno di un singolo account\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png) ## Valutazione della policy per un utente IAM Il seguente diagramma di flusso fornisce dettagli su come viene presa una decisione di valutazione della policy per un utente IAM all’interno di un singolo account. ![\[Diagramma di flusso di valutazione per un utente IAM all’interno di un singolo account\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png) ## Esempio di valutazione delle policy basate su identità e delle policy basate su risorse I tipi di policy più comuni sono quelle basate su identità e quelle basate su risorse. Quando viene richiesto l'accesso a una risorsa, AWS valuta tutte le autorizzazioni concesse dalle politiche per **almeno un Consenti** all'interno dello stesso account. Un rifiuto esplicito in una qualsiasi di queste policy sostituisce l'autorizzazione. **Importante** Se la policy basata sull'identità o la policy basata sulle risorse all'interno dello stesso account consente la richiesta e l'altra no, la richiesta è comunque consentita. Supponiamo che Carlos, con il nome utente `carlossalazar`, voglia salvare un file nel bucket `amzn-s3-demo-bucket-carlossalazar-logs` di Amazon S3. Supponi inoltre che la policy seguente sia collegata all'utente IAM `carlossalazar`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowS3Self", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::*log*" } ] } ``` ------ L'istruzione `AllowS3ListRead` in questa policy consente a Carlos di visualizzare un elenco di tutti i bucket nell'account. L'istruzione `AllowS3Self` consente a Carlos l'accesso completo al bucket con lo stesso nome usato per il nome utente. L'istruzione `DenyS3Logs` nega a Carlos l'accesso a qualsiasi bucket di S3 il cui nome includa `log`. Inoltre, la seguente policy basata su risorse (detta policy del bucket) viene collegata al bucket `amzn-s3-demo-bucket-carlossalazar`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/carlossalazar" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] } ] } ``` ------ Questa policy specifica che solo l'utente `carlossalazar` può accedere al bucket `amzn-s3-demo-bucket-carlossalazar`. Quando Carlos richiede di salvare un file nel `amzn-s3-demo-bucket-carlossalazar-logs` bucket, AWS determina quali politiche si applicano alla richiesta. In questo caso, sono applicabili solo la policy basata su identità e la policy basata su risorse. Entrambe sono policy di autorizzazione. Poiché non ci sono limiti di autorizzazione applicabili, la logica di valutazione viene ridotta a quanto segue. ![\[Diagramma di flusso della valutazione\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/EffectivePermissionsShort.png) AWS verifica innanzitutto la presenza di un'`Deny`istruzione che si applichi al contesto della richiesta. Ne trova una, perché la policy basata su identità rifiuta esplicitamente a Carlos l'accesso a qualsiasi bucket di S3 utilizzato per la creazione di log. A Carlos viene negato l'accesso. Supponiamo che poi si renda conto del suo errore e cerchi di salvare il file nel `amzn-s3-demo-bucket-carlossalazar` bucket. AWS verifica la presenza di una `Deny` dichiarazione e non la trova. Verifica quindi le policy di autorizzazione. Sia la policy basata sull'identità che la policy basata sulle risorse consentono la richiesta. Pertanto, AWS consente la richiesta. Se uno dei due avesse rifiutato esplicitamente l'istruzione, la richiesta sarebbe stata negata. Se uno dei tipi di policy consente la richiesta e l'altro no, la richiesta è comunque consentita. # Cross-account policy evaluation logic Puoi consentire a un principale in un account di accedere alle risorse in un secondo account. Questo è chiamato accesso tra account. Quando consenti l'accesso tra account, l'account in cui si trova il principale viene denominato l'account *attendibile* . L'account in cui si trova la risorsa è l'account *che concede fiducia* . Per consentire l'accesso tra account, collega una policy basata sulle risorse alla risorsa che desideri condividere. Devi inoltre collegare una policy basata sull'identità all'identità che agisce come il principale nella richiesta. La policy basata su risorse nell'account che concede fiducia deve specificare il principale dell'account attendibile che avrà accesso alla risorsa. Puoi specificare l'intero account o i relativi utenti IAM, i principali utenti AWS STS federati, i ruoli IAM o le sessioni con ruolo presunto. Puoi anche specificare un AWS servizio come principale. Per ulteriori informazioni, consulta [Come specificare un principale](reference_policies_elements_principal.md#Principal_specifying). La policy basata su identità del principale deve consentire l'accesso richiesto alla risorsa nel servizio che concede fiducia. A questo scopo, specifica l'ARN della risorsa. In IAM, puoi collegare una policy basata sulle risorse a un ruolo IAM per consentire ai principali in altri account di assumere tale ruolo. La policy basata sulle risorse del ruolo è denominata policy di attendibilità del ruolo. Dopo aver assunto tale ruolo, i principali consentiti possono utilizzare le credenziali temporanee risultanti per accedere a più risorse nell'account. Questo accesso è definito nella policy di autorizzazioni basata su identità del ruolo. Per informazioni sul perché consentire l'accesso tra account utilizzando i ruoli è diverso dal consentire l'accesso tra account utilizzando altre policy basate sulle risorse, consulta [Accesso alle risorse multi-account in IAM](access_policies-cross-account-resource-access.md). **Importante** Altri servizi possono influire sulla logica di valutazione dei criteri. Ad esempio, AWS Organizations supporta [le politiche di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) e [le politiche di controllo delle risorse](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) che possono essere applicate ai principali e alle risorse di uno o più account. AWS Resource Access Manager supporta [frammenti di policy](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html) che controllano le azioni che i responsabili sono autorizzati a eseguire sulle risorse condivise con loro. ## Determinare se una richiesta tra account è consentita Per le richieste tra account, il richiedente nell'`AccountA` attendibile deve disporre di una policy basata su identità. Tale policy deve consentire di effettuare una richiesta alla risorsa nell' che concede fiducia `AccountB`. Inoltre, la policy basata sulle risorse nell'`AccountB` deve consentire al richiedente nell'`AccountA` di accedere alla risorsa. Quando effettui una richiesta tra più account, AWS esegue due valutazioni. AWS valuta la richiesta nell'account fiduciario e nell'account fidato. Per ulteriori informazioni su come una richiesta viene valutata all'interno di un singolo account, consulta [In che modo la logica del codice di AWS applicazione valuta le richieste di consentire o negare l'accesso](reference_policies_evaluation-logic_policy-eval-denyallow.md). La richiesta è consentita solo se entrambe le valutazioni restituiscono come decisione `Allow`. ![\[Valutazione tra account\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png) 1. Quando un principale in un account effettua una richiesta per accedere a una risorsa in un altro account, questa è una richiesta tra account. 1. Il principale che esegue la richiesta esiste nell'account attendibile (`AccountA`). Quando AWS valuta questo account, controlla la policy basata su identità e le eventuali policy che possono limitare una policy basata su identità. Per ulteriori informazioni, consulta [Valutazione delle policy basate su identità con i limiti delle autorizzazioni](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound). 1. La risorsa richiesta esiste nell'account che concede fiducia (`AccountB`). Quando AWS valuta questo account, controlla la policy basata sulle risorse collegata alla risorsa richiesta e le eventuali policy che possono limitare una policy basata sulle risorse. Per ulteriori informazioni, consulta [Valutazione delle policy basate su identità con policy basate su risorse](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp). 1. AWS consente la richiesta solo se entrambe le valutazioni delle politiche dell'account consentono la richiesta. Il seguente diagramma di flusso fornisce un’illustrazione più dettagliata di come viene presa una decisione di valutazione delle policy per una richiesta multi-account. Ancora una volta, AWS consente la richiesta solo se entrambe le valutazioni delle politiche dell'account consentono la richiesta. ![\[Valutazione dettagliata della policy multi-account\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png) ## Esempio di valutazione della policy multiaccount Nell'esempio seguente viene illustrato uno scenario in cui a un utente in un account vengono concesse autorizzazioni da una policy basata sulle risorse in un secondo account. Supponiamo che Carlos sia uno sviluppatore con un ruolo IAM denominato `Demo` nell'account 111111111111. Vuole salvare un file nel bucket `amzn-s3-demo-bucket-production-logs` di Amazon S3 nell'account 222222222222. Supponiamo inoltre che la policy seguente sia collegata al ruolo IAM `Demo`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "AllowS3ProductionObjectActions", "Effect": "Allow", "Action": "s3:*Object*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*log*", "arn:aws:s3:::*log*/*" ] } ] } ``` ------ L'istruzione `AllowS3ListRead` in questa policy consente a Carlos di visualizzare un elenco di tutti i bucket in Amazon S3. L'istruzione `AllowS3ProductionObjectActions` consente a Carlos l'accesso completo al bucket `amzn-s3-demo-bucket-production`. Inoltre, la seguente policy basata sulle risorse (denominata policy del bucket) è collegata al bucket `amzn-s3-demo-bucket-production` nell'account 222222222222. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject*", "s3:ReplicateObject", "s3:RestoreObject" ], "Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" }, "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" } ] } ``` ------ Questa policy consente al ruolo `Demo` di accedere agli oggetti nel bucket `amzn-s3-demo-bucket-production`. Il ruolo può creare e modificare, ma non eliminare gli oggetti nel bucket. Il ruolo non riesce a gestire il bucket da solo. Quando Carlos fa la sua richiesta di salvare un file nel `amzn-s3-demo-bucket-production-logs` bucket, AWS determina quali politiche si applicano alla richiesta. In questo caso, la policy basata su identità collegata al ruolo `Demo` è la sola policy valida nell'account `111111111111`. Nell'account `222222222222`, non esiste una policy basata sulle risorse collegata al bucket `amzn-s3-demo-bucket-production-logs`. Quando AWS valuta l'account`111111111111`, restituisce una decisione di. `Deny` Questo perché l'istruzione `DenyS3Logs` nella policy basata su identità nega esplicitamente l'accesso a qualsiasi bucket di log. Per ulteriori informazioni su come una richiesta viene valutata all'interno di un singolo account, consulta [In che modo la logica del codice di AWS applicazione valuta le richieste di consentire o negare l'accesso](reference_policies_evaluation-logic_policy-eval-denyallow.md). Poiché la richiesta viene negata esplicitamente all'interno di uno degli account, la decisione finale è di negare la richiesta. ![\[Richiesta a amzn-s3- bucket demo-bucket-production-logs\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png) Supponiamo che Carlos si accorga allora del suo errore e cerchi di salvare il file nel bucket. `Production` AWS controlla innanzitutto l'account `111111111111` per determinare se la richiesta è consentita. Si applica solo la politica basata sull'identità e consente la richiesta. AWS quindi controlla l'account. `222222222222` Vale solo la policy basata sulle risorse collegata al bucket `Production` e consente la richiesta. Poiché entrambi gli account consentono la richiesta, la decisione finale è di consentire la richiesta. ![\[Richiesta a bucket di produzione\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png) # Differenza tra rifiuto esplicito e implicito Una richiesta genera un rifiuto esplicito se policy applicabile include un'istruzione `Deny`. Se le policy applicabili a una richiesta includono un'istruzione `Allow` e un'istruzione `Deny`, l'istruzione `Deny` prevale sull'istruzione `Allow`. La richiesta viene rifiutata esplicitamente. Una rifiuto implicito si verifica quando non c'è un'istruzione `Deny` applicabile ma non c'è neanche un'istruzione `Allow` applicabile. Poiché a un principale IAM viene rifiutato l'accesso per impostazione predefinita, questo deve essere autorizzato esplicitamente a eseguire un'operazione. In caso contrario, l'accesso viene negato implicitamente. Quando progetti una strategia di autorizzazione, devi creare policy con istruzioni `Allow` per consentire alle entità principali di eseguire richieste. Tuttavia, puoi scegliere qualsiasi combinazione di rifiuti espliciti e impliciti. Ad esempio, è possibile creare la seguente policy che include operazioni consentite, operazioni rifiutate implicitamente e operazioni rifiutate esplicitamente. La dichiarazione `AllowGetList` **permette** l'accesso in sola lettura alle operazioni IAM che iniziano con i prefissi `Get` e `List`. Tutte le altre azioni in IAM, come `iam:CreatePolicy`, sono **rifiutate implicitamente**. La dichiarazione `DenyReports` **impedisce esplicitamente** l'accesso ai report IAM impedendo l'accesso alle operazioni che includono il suffisso `Report`, come `iam:GetOrganizationsAccessReport`. Se qualcuno aggiunge un'altra policy a questo principale per concedere l'accesso ai report IAM, come `iam:GenerateCredentialReport`, le richieste relative ai report vengono ancora rifiutate a causa di questo rifiuto esplicito. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowGetList", "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*" ], "Resource": "*" }, { "Sid": "DenyReports", "Effect": "Deny", "Action": "iam:*Report", "Resource": "*" } ] } ``` ------