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à. # AWS Elementi della policy JSON: Principal Utilizzare l'elemento `Principal` in una policy JSON basata sulle risorse per specificare il principale a cui è consentito o negato l'accesso a una risorsa. Nelle [policy basate sulle risorse](access_policies_identity-vs-resource.md) devi utilizzare l'elemento `Principal`. Diversi servizi supportano le policy basate sulle risorse, tra cui IAM. Il tipo di policy basata sulle risorse IAM è una policy di attendibilità del ruolo. Nei ruoli IAM, utilizza l'elemento `Principal` nella policy di attendibilità del ruolo per specificare chi può assumere il ruolo. Per l'accesso tra account, è necessario specificare l'identificatore a 12 cifre dell'account affidabile. Per capire se i principali negli account esterni alla zona di attendibilità (organizzazione o account attendibile) dispongono dell'accesso per assumere i ruoli, consulta [Cos'è IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). **Nota** Dopo aver creato il ruolo, è possibile modificare l'account in "\$1" per consentire a tutti di assumere il ruolo. In questo caso, è consigliabile limitare gli utenti che possono accedere al ruolo attraverso altri mezzi, ad esempio un elemento `Condition` che limita l'accesso solo a determinati indirizzi IP. Non permettere che il ruolo sia accessibile a tutti. Altri esempi di risorse che supportano le policy basate sulle risorse includono un bucket Amazon S3 o AWS KMS key. Non puoi usare l'elemento `Principal` in una policy basata su identità Le policy basate su identità sono policy di autorizzazione che si collegano a identità IAM (utenti, gruppi o ruoli). In questi casi, il principale è implicito nell'identità dove è collegata la policy. **Topics** + [Come specificare un principale](#Principal_specifying) + [Account AWS presidi](#principal-accounts) + [Principali ruolo IAM](#principal-roles) + [Principali della sessione come ruolo](#principal-role-session) + [Principali federati OIDC](#principal-federated-web-identity) + [Principali federati SAML](#principal-saml) + [Principali dell'utente IAM](#principal-users) + [Principi fondamentali di Centro identità IAM](#principal-identity-users) + [AWS STS principi utente federati](#sts-session-principals) + [AWS presidi del servizio](#principal-services) + [AWS principali di servizio nelle regioni che accettano l'adesione](#principal-services-in-opt-in-regions) + [Tutti i principali](#principal-anonymous) + [Ulteriori informazioni](#Principal_more-info) ## Come specificare un principale È possibile specificare un principale nell'elemento `Principal` di una policy basata sulle risorse o in chiavi di condizione che supportano i principali. In una policy è possibile specificare una delle seguenti entità: + Account AWS e utente root + Ruoli IAM + Sessioni come ruolo + Utenti IAM + Principali utente federato + AWS servizi + Tutti i principali Non è possibile identificare un gruppo di utenti come principale in una policy (ad esempio una policy basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principali sono entità IAM autenticate. È possibile specificare più di un principale per ciascuno dei tipi di entità nelle sezioni seguenti utilizzando un array. Gli array possono richiedere uno o più valori. Quando si specifica più di un principale in un elemento, si concedono le autorizzazioni a ciascun principale. Questo è un `OR` logico e non un `AND` logico, perché si viene autenticati come un principale alla volta. Se includi più di un valore, utilizza parentesi quadre (`[` e `]`) e delimita con le virgole ogni voce per l'array. La seguente policy di esempio definisce le autorizzazioni per l'account 123456789012 o per l'account 555555555555. ``` "Principal" : { "AWS": [ "123456789012", "555555555555" ] } ``` **Nota** Non è possibile utilizzare un carattere jolly per associare parte di un nome di un principale o di un ARN. ## Account AWS presidi È possibile specificare Account AWS gli identificatori nell'`Principal`elemento di una politica basata sulle risorse o nelle chiavi di condizione che supportano i principali. In questo modo l'autorità viene delegata all'account. Quando consenti l'accesso a un altro account, un amministratore di tale account deve concedere l'accesso a un'identità (utente o ruolo IAM) in tale account. Quando si specifica un Account AWS, è possibile utilizzare l'account ARN (arn:aws:iam: :root*account-ID*) o un modulo abbreviato costituito dal prefisso seguito dall'ID dell'account. `"AWS":` Ad esempio, fornendo un account ID di `123456789012`, è possibile utilizzare uno dei seguenti metodi per specificare l'account nell'elemento `Principal`: ``` "Principal": { "AWS": "arn:aws:iam::123456789012:root" } ``` ``` "Principal": { "AWS": "123456789012" } ``` L'ARN dell'account e l'ID dell'account abbreviato si comportano allo stesso modo: entrambi delegano le autorizzazioni all'account. L'utilizzo dell'ARN dell'account nell'elemento `Principal` non limita le autorizzazioni solo per l'utente root dell'account. **Nota** Quando salvi una policy basata sulle risorse che include l'ID dell'account abbreviato, il servizio potrebbe convertirlo nell'ARN del principale. Ciò non modifica la funzionalità della policy. Alcuni AWS servizi supportano opzioni aggiuntive per specificare l'intestazione di un account. Ad esempio, Amazon S3 ti consente di specificare un [ID utente canonico](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) utilizzando il formato seguente: ``` "Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" } ``` È inoltre possibile specificarne più di uno Account AWS(o un ID utente canonico) come principale utilizzando un array. Ad esempio, è possibile specificare un principale in una policy del bucket utilizzando tutti e tre i metodi. ``` "Principal": { "AWS": [ "arn:aws:iam::123456789012:root", "999999999999" ], "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" } ``` ## Principali ruolo IAM È possibile specificare il ruolo principale IAM ARNs nell'`Principal`elemento di una policy basata sulle risorse o nelle chiavi di condizione che supportano i principali. I ruoli IAM sono identità. In IAM, le identità sono risorse a cui è possibile assegnare autorizzazioni. I ruoli si affidano a un'altra identità autenticata per assumere tale ruolo. Ciò include un principale in AWS o un utente di un provider di identità esterno (IdP). Quando un principal o un'identità assume un ruolo, ricevono credenziali di sicurezza temporanee con le autorizzazioni del ruolo assunto. *Quando utilizzano tali credenziali di sessione per eseguire operazioni in AWS, diventano responsabili della sessione di ruolo.* Quando si specifica un principale del ruolo in una policy basata sulle risorse, le autorizzazioni effettive per il principale sono limitate da qualsiasi tipo di policy che limita le autorizzazioni per il ruolo. Ciò include le policy di sessione e i limiti delle autorizzazioni. Per ulteriori informazioni su come vengono valutate le autorizzazioni effettive per una sessione come ruolo, consulta [Logica di valutazione delle policy](reference_policies_evaluation-logic.md). Per specificare l'ARN del ruolo nell'elemento `Principal`, utilizza questo formato: ``` "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" } ``` **Importante** Se l’elemento `Principal` in una policy di attendibilità del ruolo contiene un ARN che punta a un determinato ruolo IAM, allora l’ARN si trasforma nell’ID principale univoco del ruolo quando si salva la policy. Ciò aiuta a mitigare il rischio che qualcuno aumenti i propri privilegi rimuovendo e ricreando il ruolo. Questa ID nella console non è normalmente presente, in quanto IAM usa una trasformazione inversa verso l'ARN del ruolo quando la policy di affidabilità viene visualizzata. Tuttavia, se si elimina il ruolo, la relazione viene interrotta. La policy non è più applicabile, anche se si ricrea il ruolo perché il nuovo ruolo ha un nuovo ID principale che non corrisponde all'ID principale archiviato nella policy di affidabilità. Quando ciò accade, l'ID principale viene visualizzato nelle politiche basate sulle risorse perché non è più AWS possibile mapparlo su un ARN valido. Il risultato finale è che se si elimina e si ricrea un ruolo referenziato in un elemento `Principal` della policy di attendibilità, è necessario modificare il ruolo nella policy per sostituire l'ID principale con il nome ARN corretto. L'ARN si trasforma nuovamente nel nuovo ID principale del ruolo quando si salva la policy. Per ulteriori informazioni, consulta [Understanding sulla gestione AWS dei ruoli IAM eliminati](https://repost.aws/articles/ARSqFcxvd7R9u-gcFD9nmA5g/understanding-aws-s-handling-of-deleted-iam-roles-in-policies) nelle politiche. In alternativa, è possibile specificare il principale del ruolo come principale in una policy basata sulle risorse oppure [creare una policy di ampia autorizzazione](#principal-anonymous) che usa la chiave di condizione `aws:PrincipalArn`. Quando si utilizza questa chiave, al principale della sessione come ruolo vengono concesse le autorizzazioni in base all'ARN del ruolo assunto e non all'ARN della sessione risultante. Poiché AWS non converte la chiave ARNs di condizione in IDs, le autorizzazioni concesse al ruolo ARN persistono se si elimina il ruolo e quindi si crea un nuovo ruolo con lo stesso nome. I tipi di policy basati su identità, come i limiti delle autorizzazioni o 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 su identità non contengano un rifiuto esplicito. ## Principali della sessione come ruolo È possibile specificare le sessioni come ruolo nell'elemento `Principal` di una policy basata sulle risorse o in chiavi in condizione che supportano i principali. Quando un principal o un'identità assume un ruolo, ricevono credenziali di sicurezza temporanee con le autorizzazioni del ruolo assunto. *Quando utilizzano tali credenziali di sessione per eseguire operazioni AWS, diventano responsabili della sessione di ruolo.* Il formato utilizzato per un responsabile della sessione di ruolo dipende dall' AWS STS operazione utilizzata per assumere il ruolo. **Importante** AWS consiglia di utilizzare i [role principal IAM](#principal-roles) nelle policy anziché quelli delle sessioni di ruolo, laddove possibile. Se necessario, utilizza `Condition` istruzioni e chiavi di condizione per definire ulteriormente l'accesso. Per specificare l'ARN principale della sessione di ruolo nell'`Principal`elemento, utilizzate il seguente formato: ``` "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" } ``` Inoltre, gli amministratori possono progettare un processo per controllare il modo di emissione delle sessioni come ruolo. Ad esempio, possono fornire una soluzione con un clic per gli utenti che creano un nome della sessione prevedibile. Se l'amministratore compie questa operazione, è possibile utilizzare i principali della sessione come ruolo nelle policy o nelle chiavi di condizione. In caso contrario, è possibile specificare l'ARN del ruolo come principale nella chiave di condizione `aws:PrincipalArn`. Il modo in cui si specifica il ruolo come principale può modificare le autorizzazioni effettive per la sessione risultante. Per ulteriori informazioni, consulta [Principali ruolo IAM](#principal-roles). ## Principali federati OIDC Un principal federato OIDC è il principale utilizzato quando si chiama l' AWS STS `AssumeRoleWithWebIdentity`API con un token web JSON (JWT) da un IDP conforme a OIDC, noto anche come OpenID Provider (OP), per richiedere credenziali temporanee. AWS [Un principal federato OIDC può rappresentare un IDP OIDC nel tuo AWS account o i 4 provider di identità integrati:Login with Amazon,, e Amazon Cognito. GoogleFacebook](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html) Gli utenti, i carichi di lavoro o i sistemi a cui è stato rilasciato un JWT dal proprio IDP OIDC possono effettuare chiamate `AssumeRoleWithWebIdentity` utilizzando JWT per richiedere credenziali di AWS sicurezza temporanee per un ruolo IAM configurato per considerare attendibile l'IDP OIDC che ha emesso il JWT. Il JWT può essere un ID token, un token di accesso o un token JWT fornito con qualsiasi altro metodo purché soddisfi i [requisiti elencati da AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-prerequisites). Per ulteriori informazioni, consulta [Scenari comuni](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_federation_common_scenarios.html) e [Richiesta di credenziali tramite un provider OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity). Utilizza questo tipo principale nella tua policy di affidabilità dei ruoli per consentire o negare le autorizzazioni alle chiamate `AssumeRoleWIthWebIdentity` utilizzando un IDP OIDC esistente nel tuo o uno dei quattro integrati. Account AWS IDPs Per specificare l'ARN principale federato OIDC nell'`Principal`elemento di una policy di trust dei ruoli, utilizza uno dei seguenti quattro formati per l'OIDC integrato: IDPs ``` "Principal": { "Federated": "cognito-identity.amazonaws.com" } ``` ``` "Principal": { "Federated": "www.amazon.com" } ``` ``` "Principal": { "Federated": "graph.facebook.com" } ``` ``` "Principal": { "Federated": "accounts.google.com" } ``` Quando utilizzi un provider OIDC che aggiungi al tuo account, ad esempio, specifichi l'ARN del provider nella politica di fiducia del tuo ruolo. GitHub Questa configurazione ti consente di scrivere policy IAM che controllano l’accesso in modo specifico per gli utenti autenticati tramite il tuo provider di identità personalizzato. ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" } ``` Ad esempio, se GitHub è il provider di identità web attendibile, l’ARN della sessione del ruolo OIDC nell’elemento `Principal` di una policy di attendibilità dei ruoli utilizza il seguente formato: ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" } ``` Per ulteriori informazioni, consulta [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). I principali federati OIDC non sono supportati in tipi di policy diversi dalle policy di attendibilità dei ruoli. ## Principali federati SAML Un principale *federato SAML è un principale* utilizzato quando si chiama l' AWS STS `AssumeRoleWithSAML`API per richiedere AWS credenziali temporanee utilizzando un'asserzione SAML. È possibile utilizzare un gestore dell’identità digitale (IdP) SAML esterno per accedere e quindi assumere un ruolo IAM utilizzando questa operazione. Simile a`AssumeRoleWithWebIdentity`, `AssumeRoleWithSAML` non richiede credenziali per l'autenticazione. AWS Invece, gli utenti si autenticano prima con il proprio provider di identità SAML, quindi effettuano la chiamata `AssumeRoleWithSAML` API utilizzando la loro asserzione SAML o vengono reindirizzati alla pagina di accesso/SAML per AWS accedere a. Console di gestione AWS Per ulteriori informazioni su quali principali possono assumere un ruolo utilizzando questa operazione, consulta [Confronta le AWS STS credenziali](id_credentials_sts-comparison.md). Utilizza questo tipo di principale nella policy di attendibilità del ruolo per consentire o negare l’autorizzazione in base al provider di identità SAML attendibile. Per specificare l'ARN della sessione del ruolo dell'identità Web nell'elemento `Principal` di una policy di attendibilità dei ruoli, utilizza questo formato: ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" } ``` ## Principali dell'utente IAM Puoi specificare gli utenti IAM nell'elemento `Principal` di una policy basata sulle risorse o nelle chiavi della condizione che supportano i principali. **Nota** In un elemento `Principal`, la parte del nome utente dell'[*Amazon Resource Name*(ARN)](reference_identifiers.md#identifiers-arns) fa distinzione tra maiuscole e minuscole. ``` "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" } ``` ``` "Principal": { "AWS": [ "arn:aws:iam::AWS-account-ID:user/user-name-1", "arn:aws:iam::AWS-account-ID:user/user-name-2" ] } ``` Quando si specificano gli utenti in un elemento `Principal`, non è possibile utilizzare un carattere jolly (`*`) che indica "tutti gli utenti". I principali devono sempre nominare utenti determinati. **Importante** Se l'elemento `Principal` in una policy di attendibilità del ruolo contiene un nome ARN che punta a un determinato utente o IAM, allora IAM trasforma l'ARN nell'ID principale univoco dell'utente quando la policy viene salvata. Ciò aiuta a mitigare il rischio che qualcuno aumenti i propri privilegi rimuovendo e ricreando il ruolo o l'utente. Questa ID nella console non è normalmente presente, in quanto c'è anche una trasformazione inversa verso il nome ARN dell'utente quando la policy di affidabilità viene visualizzata. Tuttavia, se si elimina l'utente, la relazione viene interrotta. La policy non è più applicabile, anche se viene ricreato l'utente. Questo perché il nuovo utente ha un nuovo ID principale che non corrisponde all'ID archiviato nella policy di affidabilità. Quando ciò accade, l'ID principale viene visualizzato nelle politiche basate sulle risorse perché non è più AWS possibile mapparlo su un ARN valido. Il risultato è che se si elimina e si ricrea un utente o referenziato in un elemento `Principal` della policy di attendibilità, è necessario modificare il ruolo per sostituire l'ID principale non corretto con il nome ARN corretto. IAM trasforma nuovamente l'ARN nel nuovo ID principale dell'utente quando si salva la policy. ## Principi fondamentali di Centro identità IAM In Centro identità IAM, il principio di una policy basata sulle risorse deve essere definito come principale dell' Account AWS . Per specificare l'accesso, fai riferimento all'ARN del ruolo del set di autorizzazioni nel blocco delle condizioni. Per ulteriori dettagli, consulta la sezione [Referenziare i set di autorizzazioni nelle policy delle risorse, in Amazon EKS e in AWS KMS](https://docs.aws.amazon.com/singlesignon/latest/userguide/referencingpermissionsets.html) nella *Guida per l'utente di Centro identità IAM*. ## AWS STS principi utente federati È possibile specificare le *sessioni come utente federato* nell'elemento `Principal` di una policy basata sulle risorse o in chiavi di condizione che supportano i principali. **Importante** AWS consiglia di limitare l'uso delle sessioni utente AWS STS federate. Invece, promuove l’uso di [ruoli IAM](IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). Un user principal AWS STS federato viene creato tramite l'`GetFederationToken`operazione richiamata con credenziali IAM di lunga durata. Le autorizzazioni dell’utente federato sono l’intersezione tra il principale che ha effettuato la chiamata `GetFederationToken` e le policy della sessione passate come parametri all’API `GetFederationToken`. In AWS, gli utenti IAM o un utente Utente root dell'account AWS possono autenticarsi utilizzando chiavi di accesso a lungo termine. Per ulteriori informazioni su quali principali possono eseguire la federazione utilizzando questa operazione, consulta [Confronta le AWS STS credenziali](id_credentials_sts-comparison.md). + **Utente federato IAM**: un utente IAM esegue la federazione utilizzando l’operazione `GetFederationToken`, che si traduce in una sessione come utente federato per quell’utente IAM. + **Utente root federato**: un utente root esegue la federazione usando l’operazione `GetFederationToken`, che si traduce in una sessione come utente federato per quell’utente root. Quando un utente IAM o un utente root richiede credenziali temporanee per AWS STS utilizzare questa operazione, inizia una sessione utente federata temporanea. L'ARN di questa sessione si basa sull'identità originale federata. Per specificare l'ARN della sessione come utente federato nell'elemento `Principal`, utilizza questo formato: ``` "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" } ``` ## AWS presidi del servizio È possibile specificare AWS i servizi nell'`Principal`elemento di una politica basata sulle risorse o in chiavi di condizione che supportano i principali. Un *principale del servizio* è un identificatore per un servizio. *[I ruoli IAM che possono essere assunti da un AWS servizio sono chiamati ruoli di servizio.](id_roles.md#iam-term-service-role)* I ruoli di servizio devono includere una policy di affidabilità. Le *Policy di affidabilità* sono policy basate su risorse collegate a un ruolo che definisce quali principali possono assumere il ruolo. Alcuni ruoli di servizio hanno policy di affidabilità predefinite. Tuttavia, in alcuni casi, è necessario specificare il principale del servizio nella policy di affidabilità. Il principale del servizio in una policy IAM non può essere `"Service": "*"`. **Importante** L'identificatore di un principale del servizio include il nome del servizio ed è solitamente nel formato seguente: `service-name.amazonaws.com` Il principale del servizio è definito dal servizio. Puoi trovare il principale del servizio aprendo [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md), controllando se il servizio ha impostato **Sì** nella colonna **Ruolo collegato ai servizi** e aprendo il collegamento **Sì** per visualizzare la documentazione del ruolo collegato a tale servizio. Trova la sezione **Autorizzazioni del ruolo collegato ai servizi** per quel servizio per visualizzare il principale del servizio L'esempio seguente mostra una policy che può essere collegata a un ruolo del servizio. Questa policy consente a due servizi, Amazon ECS e Elastic Load Balancing, di assumere il ruolo. I servizi possono eseguire qualsiasi attività concesse da una policy di autorizzazioni assegnata al ruolo (non visualizzato). Per specificare più principali del servizio, non si specificano due elementi `Service`, è possibile averne solo uno. Utilizzare invece una serie di principali del servizio come il valore di un elemento singolo `Service`. ``` "Principal": { "Service": [ "ecs.amazonaws.com", "elasticloadbalancing.amazonaws.com" ] } ``` ## AWS principali di servizio nelle regioni che accettano l'adesione Puoi lanciare risorse in diverse AWS regioni e in alcune di esse devi aderire. Per un elenco completo delle regioni a cui devi aderire, consulta [Gestire AWS le regioni](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) nella *Riferimenti generali di AWS*guida. Quando un AWS servizio in una regione opt-in effettua una richiesta all'interno della stessa regione, il formato del nome principale del servizio viene identificato come la versione non regionalizzata del nome principale del servizio: `service-name.amazonaws.com` Quando un AWS servizio in una regione opt-in invia una richiesta interregionale a un'altra regione, il formato del nome principale del servizio viene identificato come la versione regionalizzata del nome principale del servizio: `service-name.{region}.amazonaws.com` Ad esempio, si consideri un argomento Amazon SNS situato nella Regione `ap-southeast-1` e un bucket Amazon S3 nella Regione di adesione `ap-east-1`. Supponiamo che si desideri configurare le notifiche bucket S3 per pubblicare messaggi nell'argomento SNS. Per consentire al servizio S3 di inviare messaggi all'argomento SNS, è necessario concedere l'autorizzazione `sns:Publish` del principale del servizio S3 tramite la policy di accesso basata sulle risorse dell'argomento. Se si specifica la versione non regionalizzata del principale del servizio S3 `s3.amazonaws.com`, nella policy di accesso all'argomento, la richiesta `sns:Publish` dal bucket all'argomento avrà esito negativo. L'esempio seguente specifica il principale del servizio S3 non regionalizzato nell'elemento della policy `Principal` della policy di accesso all'argomento SNS. ``` "Principal": { "Service": "s3.amazonaws.com" } ``` Poiché il bucket si trova in una regione di adesione e la richiesta viene effettuata al di fuori della stessa regione, il principale del servizio S3 appare come nome del principale del servizio regionalizzato, `s3.ap-east-1.amazonaws.com`. È necessario utilizzare il nome principale del servizio regionalizzato quando un AWS servizio in una regione opt-in invia una richiesta a un'altra regione. Dopo aver specificato il nome del principale del servizio regionalizzato, se il bucket effettua una richiesta `sns:Publish` all'argomento SNS situato in un'altra regione, la richiesta avrà esito positivo. L'esempio seguente specifica il principale del servizio S3 regionalizzato nell'elemento della policy `Principal` della policy di accesso all'argomento SNS. ``` "Principal": { "Service": "s3.ap-east-1.amazonaws.com" } ``` Le policy di risorse o gli elenchi di autorizzazioni basati sui principali dei servizi per le richieste tra regioni da una regione di adesione a un'altra regione avranno esito positivo solo se si specifica il nome del principale del servizio regionalizzato. **Nota** Per le policy di attendibilità dei ruoli IAM, consigliamo di utilizzare il nome del principale del servizio non regionalizzato. Le risorse IAM sono globali e quindi lo stesso ruolo può essere utilizzato in qualsiasi regione. ## Tutti i principali Puoi utilizzare un carattere jolly (\$1) per specificare tutti i principali nell'elemento `Principal` di una policy basata sulle risorse o nelle chiavi della condizione che supportano tali entità. [Policy basate sulle risorse](access_policies.md#policies_resource-based) *concedono* le autorizzazioni e le [chiavi della condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) vengono utilizzate per limitare le condizioni di un'istruzione della policy. **Importante** Ti consigliamo di non utilizzare un carattere jolly (\$1) nell'elemento `Principal` di una policy basata sulle risorse con un effetto `Allow` a meno che tu non intenda concedere un accesso pubblico o anonimo. In caso contrario, specifica i principali, i servizi o gli account AWS previsti nell'elemento `Principal`, quindi limita ulteriormente l'accesso nell'elemento `Condition`. Ciò vale in special modo per le policy di attendibilità del ruolo IAM, perché consentono ad altri principali di diventare un principale nel tuo account. Per le policy basate sulle risorse, l'utilizzo di un carattere jolly (\$1) con un effetto `Allow` concede l'accesso a tutti gli utenti, compresi gli utenti anonimi (accesso pubblico). Per gli utenti IAM e i principali del ruolo all'interno del tuo account non sono richieste altre autorizzazioni. Per i principali di altri account, devono inoltre disporre di autorizzazioni basate su identità nel proprio account che consentano loro di accedere alla tua risorsa. Questo è chiamato [accesso tra account](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html). Per gli utenti anonimi, i seguenti elementi sono equivalenti: ``` "Principal": "*" ``` ``` "Principal" : { "AWS" : "*" } ``` Non è possibile utilizzare un carattere jolly per associare parte di un nome di un principale o di un ARN. L'esempio seguente mostra una policy basata sulle risorse che può essere utilizzata al posto di [AWS Elementi della policy JSON: NotPrincipal](reference_policies_elements_notprincipal.md) per negare esplicitamente tutti i principali, *eccetto* quelli specificati nell'elemento `Condition`. Questa policy deve essere [aggiunta a un bucket Amazon S3](https://docs.aws.amazon.com//AmazonS3/latest/userguide/add-bucket-policy.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny", "Effect": "Deny", "Action": "s3:*", "Principal": "*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*", "arn:aws:s3:::amzn-s3-demo-bucket" ], "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name" } } } ] } ``` ------ ## Ulteriori informazioni Per ulteriori informazioni, consulta gli argomenti seguenti: + [Esempi di policy di bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) nella *Guida per l'utente di Amazon Simple Storage Service (Amazon S3)* + [Policy di esempio per Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#ExamplePolicies_SNS) nella *Guida per gli sviluppatori di Amazon Simple Notification Service* + [Policy di esempio per Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html) nella *Guida per gli sviluppatori di Amazon Simple Queue Service* + [Policy delle chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) nella *Guida per gli sviluppatori di AWS Key Management Service * + [Identificatori di account](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) nella *Riferimenti generali di AWS* + [Federazione OIDC](id_roles_providers_oidc.md)