Specifica di un'entità principale Account AWS presidi Principali ruolo IAM Principali della sessione come ruolo Principali dell'utente IAM Principi di Centro identità IAM Principali di sessione come utente federato AWS presidi del servizio AWS i principali del servizio nelle regioni che accettano l'adesione Tutti i principali Ulteriori informazioni

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 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

Specifica di un'entità principale
Account AWS presidi
Principali ruolo IAM
Principali della sessione come ruolo
Principali dell'utente IAM
Principi fondamentali di Centro identità IAM
AWS STS principi di sessione utente federati
AWS presidi del servizio
AWS i principali del servizio nelle regioni che accettano l'adesione
Tutti i principali
Ulteriori informazioni

Specifica di un'entità 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
Sessioni come 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'Principalelemento 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:: account-ID:root) 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 servizi supportano opzioni aggiuntive per specificare l'intestatario dell'account. AWS Ad esempio, Amazon S3 ti consente di specificare un ID utente canonico 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 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 i principali della sessione di ruolo.

I ruoli IAM sono identità esistenti in IAM. I ruoli si affidano a un'altra identità autenticata, ad esempio un titolare AWS o un utente di un provider di identità esterno. Quando un principal o un'identità assume un ruolo, ricevono credenziali di sicurezza temporanee. Possono quindi utilizzare tali credenziali come principale della sessione come ruolo per eseguire operazioni in AWS.

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à. 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.

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, 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 (*) 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.

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 di sessione con ruolo presunto è un principale di sessione che risulta dall'utilizzo dell'operazione. AWS STS AssumeRole Per ulteriori informazioni su quali principali possono assumere un ruolo utilizzando questa operazione, consulta Confronto delle operazioni AWS STS API.

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.

Principi della sessione OIDC

Un principale di sessione OIDC è un principale di sessione che risulta dall'utilizzo dell'operazione. AWS STS AssumeRoleWithWebIdentity Puoi utilizzare un provider OIDC (IdP) esterno per accedere e quindi assumere un ruolo IAM utilizzando questa operazione. Ciò sfrutta la federazione delle identità e genera una sessione come ruolo. Per ulteriori informazioni su quali principali possono assumere un ruolo utilizzando questa operazione, consulta Confronto delle operazioni AWS STS API.

Quando si assegna un ruolo da un provider OIDC, si ottiene questo tipo speciale di sessione principale che include informazioni sul provider OIDC.

Utilizzare questo tipo di principale nella policy per consentire o negare l'accesso in base al provider di identità Web attendibile. Per specificare l'ARN della sessione di ruolo OIDC nell'Principalelemento di una policy di attendibilità dei ruoli, utilizzare il formato seguente:


"Principal": { "Federated": "cognito-identity.amazonaws.com" }


"Principal": { "Federated": "www.amazon.com" }


"Principal": { "Federated": "graph.facebook.com" }


"Principal": { "Federated": "accounts.google.com" }

Principali della sessione SAML

Un principale di sessione SAML è un principale di sessione che risulta dall'utilizzo dell'operazione. AWS STS AssumeRoleWithSAML È possibile utilizzare un provider di identità SAML (IdP) esterno per accedere e quindi assumere un ruolo IAM utilizzando questa operazione. Ciò sfrutta la federazione delle identità e genera una sessione come ruolo. Per ulteriori informazioni su quali principali possono assumere un ruolo utilizzando questa operazione, consulta Confronto delle operazioni AWS STS API.

Quando si emette un ruolo da un provider di identità SAML, si ottiene questo tipo speciale di principale di sessione che include informazioni sul provider di identità SAML.

Utilizza questo tipo di principale nella policy per consentire o negare l'accesso 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à. 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 nella Guida per l'utente di Centro identità IAM.

AWS STS principi di sessione 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 utilizzare sessioni utente AWS STS federate solo quando necessario, ad esempio quando è richiesto l'accesso da parte dell'utente root. Utilizzare invece i ruoli per delegare le autorizzazioni.

Un principale di sessione utente AWS STS federato è un principale di sessione che risulta dall'utilizzo dell' AWS STS GetFederationTokenoperazione. In questo caso, AWS STS utilizza la federazione delle identità come metodo per ottenere token di accesso temporaneo anziché utilizzare i ruoli IAM.

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 Confronto delle operazioni AWS STS API.

Utente federato IAM: un utente IAM esegue la federazione utilizzando l'operazione GetFederationToken, che si traduce in un principale di 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 un principale di 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'Principalelemento 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. 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 service principal in una policy IAM non può esserlo"Service": "*".

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, 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 i principali del 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 nella Riferimenti generali di AWSguida.

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 (*) 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 su 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 Specifica di NotPrincipal con Deny per negare esplicitamente tutti i principali, eccetto quelli specificati nell'elemento Condition.


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
      "Effect": "Deny",
      "Action": "s3:*",
      "Principal": "*",
      "Resource": [
        "arn:aws:s3:::BUCKETNAME/*",
        "arn:aws:s3:::BUCKETNAME"
      ],
      "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 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
Federazione OIDC

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Effect

NotPrincipal