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à. # Controlla l'accesso a AWS STS con politiche per gli endpoint VPC Quando crei un endpoint VPC di interfaccia per Servizio di token di sicurezza AWS (AWS STS), puoi allegare una policy sugli endpoint. La policy controlla quali principali possono utilizzare l'endpoint e quali AWS STS azioni possono eseguire. Se non alleghi una policy, l'endpoint utilizza la policy predefinita che consente l'accesso illimitato a tutte le AWS STS azioni per tutti i principali. Le policy degli endpoint VPC non concedono autorizzazioni da sole. Agiscono come un limite aggiuntivo che funziona insieme ad altre politiche. Sia la policy sugli endpoint che le politiche applicabili del chiamante devono consentire l'esito positivo di una richiesta. Per ulteriori informazioni sulle politiche degli endpoint VPC, consulta [ Control access to VPC endpoint using endpoint policy ](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) nella Amazon VPC User Guide. * * **Topics** + [Policy di endpoint VPC predefinita](#reference_sts_vpc_endpoint_policies_default) + [Considerazioni importanti per AWS STS Policy di endpoint VPC](#reference_sts_vpc_endpoint_policies_considerations) + [Chiavi di condizione disponibili per AWS STS Policy di endpoint VPC](#reference_sts_vpc_endpoint_policies_condition_keys) + [Esempio: consenti tutto AWS STS azioni per la tua organizzazione](#reference_sts_vpc_endpoint_policies_example_org) + [Esempio: consenti tutto AWS STS azioni per account specifici](#reference_sts_vpc_endpoint_policies_example_accounts) + [Esempio: limita a uno specifico AWS STS actions](#reference_sts_vpc_endpoint_policies_example_actions) + [Esempio: negare l'accesso a soggetti esterni all'organizzazione pur consentendo la federazione](#reference_sts_vpc_endpoint_policies_example_deny) ## Policy di endpoint VPC predefinita Se non alleghi una policy personalizzata quando crei l'endpoint, allega la seguente policy predefinita. AWS Questa policy consente l'accesso illimitato all'endpoint. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } ``` Per limitare l'accesso all'endpoint, allega una policy personalizzata per gli endpoint. ## Considerazioni importanti per AWS STS Policy di endpoint VPC AWS STS gestisce le richieste provenienti da due tipi di chiamanti fondamentalmente diversi. La tua policy sugli endpoint VPC deve tenere conto di entrambi i tipi per evitare di bloccare involontariamente le richieste legittime. ** AWS Principal autenticati** Utenti IAM e ruoli IAM che firmano le richieste con AWS Signature Version 4 (Sigv4). Questi chiamanti dispongono di chiavi di condizione standard come `aws:PrincipalOrgID``aws:PrincipalAccount`, e `aws:PrincipalArn` disponibili nel contesto della richiesta. **Chiamanti federati** Principal SAML 2.0 e OpenID Connect (OIDC) che chiamano o. `AssumeRoleWithSAML` `AssumeRoleWithWebIdentity` Questi chiamanti si autenticano con asserzioni SAML o JSON Web Tokens (JWT), non con firme SIGv4. Poiché non hanno un' AWS identità al momento della richiesta, il contesto della richiesta non include chiavi di condizione basate sui principali come, e. `aws:PrincipalOrgID` `aws:PrincipalAccount` `aws:PrincipalArn` **Importante** Se la tua policy sugli endpoint VPC si basa esclusivamente sulla `aws:PrincipalOrgID` possibilità di accesso, le chiamate federate `AssumeRoleWithSAML` e `AssumeRoleWithWebIdentity` le chiamate vengono implicitamente negate perché la chiave di condizione è assente per i non principali.AWS ### In che modo AWS STS valuta le politiche degli endpoint VPC per i chiamanti federati Quando un chiamante federato richiama `AssumeRoleWithSAML` o `AssumeRoleWithWebIdentity` tramite un endpoint VPC, vale quanto segue: + Il chiamante non è un principale. AWS Chiavi di condizione come `aws:PrincipalOrgID``aws:PrincipalAccount`, e non `aws:PrincipalArn` sono disponibili nel contesto della richiesta. + I chiamanti federati non dispongono della chiave di condizione `aws:PrincipalIsAWSService` nel contesto della richiesta. + Il ruolo assunto è una AWS risorsa. Resource-based le chiavi di condizione come `aws:ResourceOrgID` e `aws:ResourceAccount` sono disponibili e si riferiscono al ruolo di destinazione. + La politica di fiducia del ruolo rimane la porta di autorizzazione principale per l'accesso federato. La politica degli endpoint VPC fornisce un limite aggiuntivo a livello di rete. Consigliamo di utilizzare `aws:ResourceOrgID` o `aws:ResourceAccount` quando si scrivono dichiarazioni di policy sugli endpoint VPC che devono essere applicate ai chiamanti federati, poiché questi chiamanti non dispongono di chiavi di condizione basate sull'indirizzo principale. ## Chiavi di condizione disponibili per AWS STS Policy di endpoint VPC La tabella seguente mostra le chiavi di condizione comunemente utilizzate e la loro disponibilità nel contesto della richiesta per ogni tipo di chiamante quando si effettuano richieste tramite un endpoint AWS STS VPC. Sono disponibili chiavi di condizione aggiuntive oltre a quelle elencate qui. **Disponibilità della chiave condizionale per tipo di chiamante** | Chiave di condizione | Responsabili autenticati AWS | Chiamanti federati | Description | | --- | --- | --- | --- | | `aws:PrincipalOrgID` | Sì | No | L'ID organizzativo del principale chiamante | | `aws:PrincipalAccount` | Sì | No | L'ID dell'account del principale chiamante | | `aws:PrincipalArn` | Sì | No | L'ARN del principale chiamante | | `aws:PrincipalIsAWSService` | Sì (risulta falso) | No (la chiave è assente) | Se il chiamante è un AWS titolare del servizio | | `aws:ResourceOrgID` | Sì | Sì | L'ID dell'organizzazione dell'account proprietario della risorsa richiesta | | `aws:ResourceAccount` | Sì | Sì | L'ID dell'account proprietario della risorsa richiesta | **Nota** Per AWS i principali autenticati (utenti e ruoli IAM), `aws:PrincipalIsAWSService` è presente nel contesto della richiesta e viene valutato come falso. Per i chiamanti federati, questa chiave è completamente assente dal contesto della richiesta. Una condizione che verifica non `"Bool": {"aws:PrincipalIsAWSService": "false"}` corrisponde ai chiamanti federati perché la chiave non è presente. ## Esempio: consenti tutto AWS STS azioni per la tua organizzazione La seguente politica sugli endpoint limita l'endpoint AWS STS VPC alla tua organizzazione supportando al contempo l'accesso federato. Consente tutte le AWS STS azioni per i principali autenticati dell'organizzazione e consente separatamente ai chiamanti federati di assumere ruoli all'interno dell'organizzazione. I chiamanti federati (`AssumeRoleWithSAML`e`AssumeRoleWithWebIdentity`) richiedono una dichiarazione separata perché non ne hanno una nel contesto della richiesta. `aws:PrincipalOrgID` ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowOrganizationPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } }, { "Sid": "AllowFederatedAssumeRole", "Effect": "Allow", "Principal": "*", "Action": [ "sts:AssumeRoleWithSAML", "sts:AssumeRoleWithWebIdentity" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-exampleorgid" } } } ] } ``` La prima istruzione utilizza `"Principal": {"AWS": "*"}` with `aws:PrincipalOrgID` per consentire l'autenticazione AWS dei principali dell'organizzazione. La seconda istruzione viene utilizzata `"Principal": "*"` per abbinare i chiamanti federati e limita il ruolo di destinazione utilizzato dall'organizzazione. `aws:ResourceOrgID` La politica di fiducia del ruolo rimane il controllo principale per il quale le identità federate possono assumere quali ruoli. Per ulteriori informazioni sull'implementazione dei controlli perimetrali di rete, consulta [ Creazione di un perimetro di dati AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) e gli esempi di policy sul perimetro [ dei dati sul sito Web. ](https://github.com/aws-samples/data-perimeter-policy-examples) GitHub ## Esempio: consenti tutto AWS STS azioni per account specifici La seguente politica sugli endpoint consente tutte le AWS STS azioni per i committenti in account specifici. Utilizza questa politica quando i tuoi account non fanno parte di un'organizzazione. I chiamanti federati possono inserire una dichiarazione separata perché non ne hanno una `aws:PrincipalAccount` nel contesto della richiesta. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSpecificAccountPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalAccount": [ "111122223333", "444455556666" ] } } }, { "Sid": "AllowFederatedAssumeRole", "Effect": "Allow", "Principal": "*", "Action": [ "sts:AssumeRoleWithSAML", "sts:AssumeRoleWithWebIdentity" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceAccount": [ "111122223333", "444455556666" ] } } } ] } ``` La prima istruzione utilizza `"Principal": {"AWS": "*"}` with `aws:PrincipalAccount` per consentire l'autenticazione dei AWS principali dagli account specificati. La seconda istruzione viene utilizzata `"Principal": "*"` per abbinare i chiamanti federati e limita il ruolo di destinazione agli stessi account utilizzati. `aws:ResourceAccount` La politica di fiducia del ruolo rimane il controllo principale per il quale le identità federate possono assumere quali ruoli. ## Esempio: limita a uno specifico AWS STS actions La seguente policy sugli endpoint è valida solo `AssumeRole` per i principali autenticati e `AssumeRoleWithSAML` per i chiamanti federati, entrambi riservati ai ruoli nell'organizzazione. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAssumeRoleByOrgPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:AssumeRole", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } }, { "Sid": "AllowSAMLFederation", "Effect": "Allow", "Principal": "*", "Action": "sts:AssumeRoleWithSAML", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-exampleorgid" } } } ] } ``` Questa policy blocca altre AWS STS azioni come`GetCallerIdentity`, `GetSessionToken` e attraverso questo endpoint. `AssumeRoleWithWebIdentity` Modifica gli `Action` elementi in base alle tue esigenze. ## Esempio: negare l'accesso a soggetti esterni all'organizzazione pur consentendo la federazione La seguente politica sugli endpoint utilizza un rifiuto esplicito per bloccare i principali autenticati esterni all'organizzazione, preservando al contempo l'accesso per i chiamanti federati. Questo approccio inizia con un'ampia autorizzazione e aggiunge una dichiarazione di rifiuto mirata. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAll", "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" }, { "Sid": "DenyNonOrgPrincipals", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } } ] } ``` L'istruzione deny utilizza`"Principal": {"AWS": "*"}`, che la limita solo ai principali AWS autenticati. I chiamanti federati (SAML e OIDC) non sono AWS principali e non corrispondono a questo `Principal` elemento, quindi il rifiuto non si applica a loro. Questo approccio evita la necessità di ricorrere a `Bool` condizioni complesse per individuare eccezioni per i `Null` chiamanti federati. **Nota** La prima dichiarazione consente tutte le azioni per tutti i principali. La negazione contenuta nella seconda dichiarazione ha la precedenza per i AWS committenti autenticati esterni all'organizzazione. I chiamanti federati sono consentiti dalla prima istruzione e non sono interessati dalla negazione perché l'`Principal`elemento nell'istruzione di rifiuto non corrisponde a loro.