AWS Elementi delle 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 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?.
Nota
Dopo aver creato il ruolo, è possibile modificare l'account in "*" 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.
Argomenti
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à:
-
Utente Account AWS e root
-
Ruoli IAM
-
Sessioni come ruolo
-
Utenti IAM
-
Principali utente federato
-
AWSServizi
-
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.
Principali dell'Account AWS
Puoi specificare identificatori di Account AWS nell'elemento Principal di una policy basata sulle risorse o in 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 specifichi un Account AWS, puoi utilizzare l'ARN dell'account (arn:aws:iam::account-ID:root) o un modulo abbreviato che include il prefisso "AWS": seguito dall'ID dell'account.
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 servizi AWS supportano ulteriori opzioni per specificare un'entità. Ad esempio, Amazon S3 ti consente di specificare un ID utente canonico utilizzando il formato seguente:
"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }Inoltre puoi specificare più di un Account AWS (o ID dell'utente canonico) come principale che utilizza una matrice. 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 gli ARN dei principali del ruolo IAM nell'elemento Principal di una policy basata sulle risorse o in 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 un principale della sessione come 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.
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à. In questo caso, l'ID principale viene visualizzato nelle policy basate sulle risorse perché AWS non può più mapparlo nuovamente a 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 il post Understanding AWS's Handling of Deleted IAM roles in Policies
In alternativa, è possibile specificare il principale del ruolo come principale in una policy basata sulle risorse oppure creare una policy di ampia autorizzazione 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 gli ARN delle chiavi di condizione in ID, se si elimina il ruolo e se ne crea un nuovo con lo stesso nome, le autorizzazioni concesse all'ARN del ruolo vengono conservate. 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 (*) 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 in AWS, diventano un principale della sessione come ruolo.
Il formato utilizzato per un principale della sessione come ruolo dipende dall'operazione AWS STS utilizzata per assumere il ruolo.
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.
Principali di sessione del ruolo assunto
Un principale della sessione come ruolo assunto è un principale di sessione che deriva dall'utilizzo dell'operazione AWS STS AssumeRole. Per ulteriori informazioni su quali principali possono assumere un ruolo utilizzando questa operazione, consulta Confronta le credenziali AWS STS.
Per specificare l'ARN della sessione come ruolo assunto nell'elemento Principal, utilizza questo formato:
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
Quando si specifica una sessione con assunzione di ruolo in un elemento Principal, non è possibile utilizzare un carattere jolly "*" per indicare tutte le sessioni. Le entità devono sempre fare riferimento a una sessione specifica.
Principali federati OIDC
Un principale federato OIDC è il principale utilizzato quando si chiama l'API AWS STS AssumeRoleWithWebIdentity con un token web JSON (JWT) da un IdP conforme a OIDC, noto anche come OpenID Provider (OP), per richiedere credenziali AWS temporanee. Un principale federato OIDC può rappresentare un IdP OIDC nel tuo account AWS o i quattro provider di identità integrati: Login with Amazon, Google, Facebook e Amazon Cognito.
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 sicurezza AWS 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. Per ulteriori informazioni, consulta Scenari comuni e Richiesta di credenziali tramite un provider OIDC.
Utilizza questo tipo di principale nella policy di attendibilità del ruolo per consentire o negare le autorizzazioni a effettuare chiamate AssumeRoleWIthWebIdentity utilizzando un IDP OIDC presente nel tuo Account AWS, o in uno dei quattro IDP incorporati. Per specificare l'ARN del principale federato OIDC nell'elemento Principal di una policy di attendibilità dei ruoli, utilizza uno dei quattro formati seguenti per gli IdP OIDC incorporati:
"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, come GitHub, specifichi l'ARN del provider nella policy di attendibilità del tuo ruolo. 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
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'API AWS STS AssumeRoleWithSAML per richiedere credenziali AWS 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. Analogamente a AssumeRoleWithWebIdentity, AssumeRoleWithSAML non richiede credenziali AWS per l'autenticazione. Gli utenti si autenticano prima con il proprio provider di identità SAML, quindi effettuano la chiamata API AssumeRoleWithSAML utilizzando la loro asserzione SAML o vengono reindirizzati alla pagina di accesso/SAML AWS per accedere alla Console di gestione AWS. Per ulteriori informazioni su quali principali possono assumere un ruolo utilizzando questa operazione, consulta Confronta le credenziali AWS STS.
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) 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à. In questo caso, l'ID principale viene visualizzato nelle policy basate sulle risorse perché AWS non può più mapparlo nuovamente a 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 nella Guida per l'utente di Centro identità IAM.
Principali utente federato AWS STS
È 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 di sessioni utente federato AWS STS. Invece, promuove l'uso di ruoli IAM.
Un principale utente federato AWS STS viene creato tramite l'operazione GetFederationToken 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 root dell'account AWS può autenticarsi utilizzando chiavi di accesso a lungo termine. Per ulteriori informazioni su quali principali possono eseguire la federazione utilizzando questa operazione, consulta Confronta le credenziali AWS STS.
-
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 richiedono credenziali temporanee da AWS STS utilizzando questa operazione, iniziano una sessione come utente federato 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" }
AWSPrincipali del servizio
È possibile specificare i servizi AWS nell'elemento Principal di una policy 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 servizio AWS sono chiamati ruoli di servizio. 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 AWSServizi che funzionano con IAM, 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" ] }
Principali dei servizi AWS nelle regioni di adesione
Puoi lanciare le risorse in diverse Regioni AWS, per alcune delle quali devi scegliere di aderire. Per un elenco completo delle regioni a cui aderire, consulta Gestione delle Regioni AWS nella Riferimenti generali di AWS.
Quando un servizio AWS servizio in una regione di adesione effettua una richiesta all'interno della stessa regione, il formato del nome del principale del servizio viene identificato come la versione non regionalizzata del nome principale del servizio:
service-name.amazonaws.com
Quando un servizio AWS servizio in una regione di adesione effettua una richiesta tra regioni a un'altra regione, il formato del nome del 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. Il nome del principale del servizio regionalizzato va utilizzato quando un servizio AWS in una regione di adesione effettua 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 (*) 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 concedono le autorizzazioni e le chiavi della condizione vengono utilizzate per limitare le condizioni di un'istruzione della policy.
Importante
Ti consigliamo di non utilizzare un carattere jolly (*) 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 (*) 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.
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 delle policy JSON: NotPrincipal per negare esplicitamente tutti i principali, eccetto quelli specificati nell'elemento Condition. Questa policy deve essere aggiunta a un bucket Amazon S3.
Ulteriori informazioni
Per ulteriori informazioni, consulta gli argomenti seguenti:
-
Esempi di policy di bucket nella Guida per l'utente di Amazon Simple Storage Service (Amazon S3)
-
Policy di esempio per Amazon SNS nella Guida per gli sviluppatori di Amazon Simple Notification Service
-
Policy di esempio per Amazon SQS nella Guida per gli sviluppatori di Amazon Simple Queue Service
-
Policy delle chiavi nella Guida per gli sviluppatori di AWS Key Management Service
-
Identificatori di account nella Riferimenti generali di AWS
