# Controle de acesso ao AWS STS com as políticas de endpoint da VPC
<a name="reference_sts_vpc_endpoint_policies"></a>

Ao criar um endpoint de interface da VPC para AWS Security Token Service (AWS STS), é possível anexar uma política de endpoint. A política controla quais entidades principais podem usar o endpoint e quais ações do AWS STS elas podem realizar. Se você não anexar uma política, o endpoint usará a política padrão que permite acesso irrestrito a todas as ações do AWS STS para todas as entidades principais.

As políticas de endpoint da VPC não concedem permissões por conta própria. Elas atuam como um limite adicional que funciona junto com outras políticas. Tanto a política do endpoint quanto as políticas aplicáveis do chamador precisam permitir uma solicitação para que ela tenha êxito.

Para obter ter mais informações sobre as políticas de endpoint da VPC, consulte [Controlar o acesso aos endpoints da VPC usando políticas de endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*.

**Topics**
+ [Política de endpoint da VPC padrão](#reference_sts_vpc_endpoint_policies_default)
+ [Considerações importantes sobre as políticas de endpoint da VPC do AWS STS](#reference_sts_vpc_endpoint_policies_considerations)
+ [Chaves de condição disponíveis para políticas de endpoint da VPC do AWS STS](#reference_sts_vpc_endpoint_policies_condition_keys)
+ [Exemplo: permitir todas as ações do AWS STS para sua organização](#reference_sts_vpc_endpoint_policies_example_org)
+ [Exemplo: permitir todas as ações do AWS STS para contas específicas](#reference_sts_vpc_endpoint_policies_example_accounts)
+ [Exemplo: restringir a ações específicas do AWS STS](#reference_sts_vpc_endpoint_policies_example_actions)
+ [Exemplo: negar acesso de pessoas não pertencentes à organização e, ao mesmo tempo, permitir a federação](#reference_sts_vpc_endpoint_policies_example_deny)

## Política de endpoint da VPC padrão
<a name="reference_sts_vpc_endpoint_policies_default"></a>

Se você não anexar uma política personalizada ao criar o endpoint, a AWS anexará a política padrão a seguir. Essa política permite acesso irrestrito ao endpoint.

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*"
        }
    ]
}
```

Para limitar o acesso ao endpoint, anexe uma política de endpoint personalizada.

## Considerações importantes sobre as políticas de endpoint da VPC do AWS STS
<a name="reference_sts_vpc_endpoint_policies_considerations"></a>

O AWS STS lida com solicitações de dois tipos fundamentalmente diferentes de chamadores. Sua política de endpoint da VPC precisa considerar os dois tipos para evitar o bloqueio involuntário de solicitações legítimas.

**Entidades principais da AWS autenticadas**  
Usuários do IAM e perfis do IAM que assinam as solicitações com o AWS Signature Version 4 (SigV4). Esses chamadores têm chaves de condição padronizadas, como `aws:PrincipalOrgID`, `aws:PrincipalAccount` e `aws:PrincipalArn`, disponíveis no contexto da solicitação.

**Chamadores federados**  
Entidades principais SAML 2.0 e OpenID Connect (OIDC) que chamam `AssumeRoleWithSAML` ou `AssumeRoleWithWebIdentity`. Esses chamadores se autenticam com asserções SAML ou JSON Web Tokens (JWTs), não com assinaturas SigV4. Como eles não têm nenhuma identidade da AWS no momento da solicitação, o contexto da solicitação não inclui as chaves de condição baseadas nas entidades principais, como `aws:PrincipalOrgID`, `aws:PrincipalAccount` e `aws:PrincipalArn`.

**Importante**  
Se sua política de endpoint da VPC depende apenas de `aws:PrincipalOrgID` para permitir o acesso, as chamadas federadas `AssumeRoleWithSAML` e `AssumeRoleWithWebIdentity` serão negadas implicitamente porque não há chave de condição para as entidades principais que não são da AWS.

### Como o AWS STS avalia as políticas de endpoint da VPC para chamadores federados
<a name="reference_sts_vpc_endpoint_policies_federated_evaluation"></a>

Quando um chamador federado invoca `AssumeRoleWithSAML` ou `AssumeRoleWithWebIdentity` por meio de um endpoint da VPC, o seguinte se aplica:
+ O chamador não é uma entidade principal da AWS. As chaves de condição, como `aws:PrincipalOrgID`, `aws:PrincipalAccount` e `aws:PrincipalArn`, não estão disponíveis no contexto da solicitação.
+ Os chamadores federados não têm a chave de condição `aws:PrincipalIsAWSService` no contexto da solicitação.
+ A função que está sendo assumida é um recurso da AWS. As chaves de condição baseadas em recursos, como `aws:ResourceOrgID` e `aws:ResourceAccount`, estão disponíveis e se referem à função de destino.
+ A política de confiança da função continua sendo a principal porta de autorização para o acesso federado. A política de endpoint da VPC fornece um limite adicional de rede.

Recomendamos o uso de `aws:ResourceOrgID` ou `aws:ResourceAccount` ao escrever as instruções da política de endpoint da VPC que devem ser aplicadas aos chamadores federados porque esses chamadores não têm chaves de condição disponíveis baseadas nas entidades principais.

## Chaves de condição disponíveis para políticas de endpoint da VPC do AWS STS
<a name="reference_sts_vpc_endpoint_policies_condition_keys"></a>

A tabela a seguir mostra as chaves de condição comumente usadas e sua disponibilidade no contexto da solicitação para cada tipo de chamador ao fazer solicitações por meio de um endpoint da VPC do AWS STS. Estão disponíveis chaves de condição adicionais, além das listadas aqui.


**Disponibilidade da chave de condição por tipo de chamador**  

| Chave de condição | Entidades principais da AWS autenticadas | Chamadores federados | Descrição | 
| --- | --- | --- | --- | 
| `aws:PrincipalOrgID` | Sim | Não | A ID da organização da entidade principal que faz a chamada | 
| `aws:PrincipalAccount` | Sim | Não | A ID da conta da entidade principal que faz a chamada | 
| `aws:PrincipalArn` | Sim | Não | O ARN da entidade principal que faz a chamada | 
| `aws:PrincipalIsAWSService` | Sim (avalia como falso) | Não (a chave está ausente) | Se o chamador é uma entidade principal de um serviço da AWS | 
| `aws:ResourceOrgID` | Sim | Sim | A ID da organização da conta que possui o recurso solicitado | 
| `aws:ResourceAccount` | Sim | Sim | A ID da conta que possui o recurso solicitado | 

**nota**  
No caso de entidades principais da AWS autenticadas (usuários e perfis do IAM), o `aws:PrincipalIsAWSService` está presente no contexto da solicitação e avalia como falso. Para chamadores federados, essa chave está totalmente ausente do contexto da solicitação. Uma condição que verifica `"Bool": {"aws:PrincipalIsAWSService": "false"}` não corresponde aos chamadores federados porque a chave não está presente.

## Exemplo: permitir todas as ações do AWS STS para sua organização
<a name="reference_sts_vpc_endpoint_policies_example_org"></a>

A política de endpoint a seguir restringe o endpoint da VPC do AWS STS à sua organização e, ao mesmo tempo, oferece suporte ao acesso federado. Ela permite todas as ações do AWS STS para as entidades principais autenticadas em sua organização e, separadamente, permite que chamadores federados assumam funções em sua organização. Os chamadores federados (`AssumeRoleWithSAML` e `AssumeRoleWithWebIdentity`) precisam de uma instrução separada porque não têm uma `aws:PrincipalOrgID` no contexto da solicitação.

```
{
    "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"
                }
            }
        }
    ]
}
```

A primeira instrução usa `"Principal": {"AWS": "*"}` com `aws:PrincipalOrgID` para permitir entidades principais da AWS autenticadas de sua organização. A segunda instrução usa `"Principal": "*"` para corresponder aos chamadores federados e restringe a função de destino à sua organização mediante o uso de `aws:ResourceOrgID`. A política de confiança da função continua sendo o controle principal para definir as funções que as identidades federadas podem assumir.

Para obter mais informações sobre a implementação de controles de perímetro de rede, consulte [Como criar um perímetro de dados na AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) e os [exemplos de políticas de perímetro de dados](https://github.com/aws-samples/data-perimeter-policy-examples) no site do GitHub.

## Exemplo: permitir todas as ações do AWS STS para contas específicas
<a name="reference_sts_vpc_endpoint_policies_example_accounts"></a>

A política de endpoint a seguir permite todas as ações do AWS STS para entidades principais em contas específicas. Use essa política quando suas contas não fizerem parte de uma organização. Os chamadores federados são permitidos em uma instrução separada porque não têm uma `aws:PrincipalAccount` no contexto da solicitação.

```
{
    "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"
                    ]
                }
            }
        }
    ]
}
```

A primeira instrução usa `"Principal": {"AWS": "*"}` com `aws:PrincipalAccount` para permitir entidades principais da AWS autenticadas das contas especificadas. A segunda instrução usa `"Principal": "*"` para fazer a correspondência dos chamadores federados e restringe a função de destino às mesmas contas mediante o uso de `aws:ResourceAccount`. A política de confiança da função continua sendo o controle principal para definir as funções que as identidades federadas podem assumir.

## Exemplo: restringir a ações específicas do AWS STS
<a name="reference_sts_vpc_endpoint_policies_example_actions"></a>

A política de endpoint a seguir permite somente `AssumeRole` para as entidades principais autenticadas e `AssumeRoleWithSAML` para os chamadores federados, ambos com escopo definido para funções em sua organização.

```
{
    "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"
                }
            }
        }
    ]
}
```

Essa política bloqueia outras ações do AWS STS, como `GetCallerIdentity`, `GetSessionToken` e `AssumeRoleWithWebIdentity`, por meio desse endpoint. Ajuste os elementos da `Action` para atender às suas necessidades.

## Exemplo: negar acesso de pessoas não pertencentes à organização e, ao mesmo tempo, permitir a federação
<a name="reference_sts_vpc_endpoint_policies_example_deny"></a>

A política de endpoint a seguir usa uma negação explícita para bloquear as entidades principais autenticadas de fora da sua organização, enquanto preserva o acesso para chamadores federados. Essa abordagem começa com uma permissão ampla e adiciona uma instrução de negação direcionada.

```
{
    "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"
                }
            }
        }
    ]
}
```

A instrução de negação usa `"Principal": {"AWS": "*"}`, que a define apenas para as entidades principais da AWS autenticadas. Os chamadores federados (SAML e OIDC) não são entidades principais da AWS e não são correspondidos por esse elemento `Principal`. Portanto, a negação não se aplica a eles. Essa abordagem evita a necessidade de condições complexas `Null` ou `Bool` para criar exceções para chamadores federados.

**nota**  
A primeira instrução permite todas as ações para todas as entidades principais. A negação na segunda instrução tem precedência para as entidades principais da AWS autenticadas de fora da sua organização. Os chamadores federados são permitidos pela primeira instrução e não são afetados pela negação porque o elemento `Principal` na instrução de negação não corresponde a eles.