# Lógica da avaliação de política
Quando uma entidade principal tenta usar o Console de gerenciamento da AWS, a API da AWS ou a AWS CLI, ela envia uma *solicitação* para a AWS. Quando um serviço da AWS recebe a solicitação, a AWS realiza várias etapas para determinar se deve permitir ou negar a solicitação.
1. **Autenticação**: a AWS primeiro autentica a entidade principal que faz a solicitação, se necessário. Essa etapa não é necessária para alguns serviços, como o Amazon S3, que permite algumas solicitações de usuários anônimos.
1. **[Processamento do contexto da solicitação](reference_policies_evaluation-logic_policy-eval-reqcontext.md)** – AWS a processa as informações coletadas na solicitação para determinar quais políticas se aplicam à solicitação.
1. **[Como a lógica do código de imposição da AWS avalia as solicitações para permitir ou negar acesso](reference_policies_evaluation-logic_policy-eval-denyallow.md)**: a AWS avalia todos os tipos de política, e a ordem das políticas afeta a forma como são avaliadas. A AWS então processa as políticas em relação ao contexto da solicitação para determinar se a solicitação é permitida ou negada.
## Avaliação das políticas baseadas em identidade com políticas baseadas em recurso
As políticas baseadas em identidade e as baseadas em recurso concedem permissões para as identidades ou recursos aos quais elas estão conectadas. Quando uma entidade do IAM (usuário ou função) solicita acesso a um recurso na mesma conta, a AWS avalia todas as permissões concedidas pelas políticas baseadas em identidade e as políticas baseadas em recurso. As permissões resultantes são a união das permissões dos dois tipos. Se uma ação for permitida por uma política baseada em identidade, uma política baseada em recurso ou ambas, o AWS permitirá a ação. Uma negação explícita em qualquer uma dessas políticas substitui a permissão.
![\[Avaliação das políticas baseadas em identidade e políticas baseadas em recurso\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/permissions_policies_effective.png)
## Avaliação das políticas baseadas em identidade com limites de permissões
Quando o AWS avalia as políticas baseadas em identidade e limites de permissões para um usuário, as permissões resultantes são a interseção das duas categorias. Isso significa que, quando você adiciona um limite de permissões a um usuário com políticas baseadas em identidade existentes, você pode reduzir as ações que o usuário pode executar. Como alternativa, quando você remove o limite de permissões de um usuário, você pode aumentar as ações que ele pode executar. Uma negação explícita em qualquer uma dessas políticas substitui a permissão. Para visualizar informações sobre como outros tipos de política são avaliadas com limites de permissões, consulte [Avaliar permissões efetivas com limites](access_policies_boundaries.md#access_policies_boundaries-eval-logic).
![\[Avaliação das políticas baseadas em identidade com limites de permissões\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/permissions_boundary.png)
## Avaliação das políticas baseadas em identidade com SCPs ou RCPs do AWS Organizations
Quando um usuário pertence a uma conta que é membro de uma organização e acessa um recurso que não tenha uma política baseada em recursos configurada, as permissões resultantes são a interseção das políticas do usuário, políticas de controle de serviços (SCPs) e política de controle de recursos (RCP). Isso significa que uma ação deve ser permitida pelos três tipos de política. Uma negação explícita na política baseada em identidade, uma SCP ou uma RCP se sobrepõem à permissão.
![\[Avaliação de políticas baseadas em identidade e SCPs ou RCPs\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/permissions_scp-idp.png)
É possível saber [se sua conta é membro de uma organização](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account) no AWS Organizations. Os membros da organização podem ser afetados por uma SCP ou RCP. Para visualizar esses dados usando o comando da AWS CLI ou operação de API da AWS, você deve ter permissões para a ação `organizations:DescribeOrganization` da sua entidade do AWS Organizations. Você deve ter permissões adicionais para executar a operação no console do AWS Organizations. Para saber se uma SCP ou RCP está negando acesso a uma solicitação específica ou alterar as permissões efetivas, entre em contato com seu administrador do AWS Organizations.
# Processamento do contexto da solicitação
*Quando a AWS avalia e autoriza uma solicitação, ela reúne as informações da solicitação em um contexto da solicitação*. O contexto da solicitação contém todas as informações que podem ser usadas na avaliação de políticas.
+ **Entidade principal**: o usuário, perfil ou entidade principal de usuário federado que enviou a solicitação. As informações sobre a entidade principal incluem as políticas que estão associadas à entidade principal.
+ **Ações**: uma ou mais ações que a entidade principal deseja realizar.
+ **Recursos**: um ou mais objetos de recurso da AWS em que ações ou operações são realizadas.
+ **Dados do recurso** – Dados relacionados ao recurso que está sendo solicitado. Isso pode incluir informações como um nome da tabela do DynamoDB ou uma tag em uma instância do Amazon EC2.
+ **Dados do ambiente** – Informações sobre o endereço IP, o agente de usuário, o status do SSL habilitado ou a hora do dia.
Essas informações são comparadas com as políticas aplicáveis para determinar se a solicitação deve ser permitida ou negada. Você pode organizar essas informações de propriedade usando o modelo **Entidade principal**, **Ação**, **Recurso** e **Condição** (PARC) para entender melhor como as políticas da AWS são avaliadas.
## Entender o modelo PARC
O modelo PARC representa o contexto da solicitação com base nos quatro elementos em JSON do texto da política:
+ [Principal](reference_policies_elements_principal.md): a entidade que está fazendo a solicitação. Uma entidade principal do IAM representa um usuário humano ou uma workload programática que pode ser autenticada e depois autorizada a executar ações nas Contas da AWS.
+ [Action](reference_policies_elements_action.md): a operação sendo realizada. Frequentemente, a ação será mapeada para uma ação da API.
+ [Resource](reference_policies_elements_resource.md): o recurso da AWS em que a ação está sendo realizada.
+ [Condition](reference_policies_elements_condition.md): restrições adicionais que devem ser atendidas para que a solicitação seja permitida.
O seguinte exemplo mostra como o modelo PARC poderia representar o contexto de uma solicitação:
```
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:UserId=AIDA123456789EXAMPLE:BobsSession
- aws:PrincipalAccount=123456789012
- aws:PrincipalOrgId=o-example
- aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR
- aws:MultiFactorAuthPresent=true
- aws:CurrentTime=...
- aws:EpochTime=...
- aws:SourceIp=...
- aws:PrincipalTag/dept=123
- aws:PrincipalTag/project=blue
- aws:RequestTag/dept=123
```
## Importância do contexto da solicitação
Entender o contexto da solicitação e como ele interage com a avaliação de políticas é essencial para:
+ Solucionar problemas de acesso em geral
+ Criar políticas eficazes e seguras
+ Entender todo o escopo das permissões concedidas por uma política
+ Prever o resultado das avaliações de políticas em diferentes cenários
Se visualizar o contexto da solicitação usando o modelo PARC, você poderá entender com mais facilidade como a AWS toma decisões de autorização e criar políticas mais eficazmente.
## Como a AWS usa o contexto da solicitação
Ao avaliar políticas, a AWS compara as informações do contexto da solicitação com as informações especificadas em todas as políticas aplicáveis. Isso inclui as políticas baseadas em identidades, as políticas baseadas em recursos, os limites de permissões do IAM, as SCPs das organizações, as RCPs das organizações e as políticas de sessão.
Para cada tipo de política, a AWS usa o contexto da solicitação para verificar:
+ Se a política se aplica à solicitação com base na entidade principal.
+ Se a ação solicitada é permitida no recurso especificado.
+ Se alguma das condições especificadas na política é atendida pelo contexto da solicitação.
A forma como o AWS avalia as políticas depende dos tipos de políticas que se aplicam ao contexto da solicitação. Esses tipos de políticas estão disponíveis para uso em uma única Conta da AWS. Para obter mais informações sobre esses tipos de política, consulte [Políticas e permissões no AWS Identity and Access Management](access_policies.md). Para saber como a AWS avalia políticas para acesso entre contas, consulte [Lógica de avaliação de política entre contas](reference_policies_evaluation-logic-cross-account.md).
+ **Políticas de controle de recursos (RCPs) do AWS Organizations**: as RCPs do AWS Organizations especificam o número máximo de permissões disponíveis para recursos nas contas da sua organização ou unidade organizacional (UO). As RCPs se aplicam aos recursos nas contas de membros e afetam as permissões efetivas das entidades principais, incluindo o Usuário raiz da conta da AWS, independentemente de as entidades principais pertencerem à organização. As RCPs não se aplicam a recursos na conta de gerenciamento da organização e a chamadas feitas por perfis vinculados ao serviço. Se existir uma RCP, as permissões concedidas pelas políticas baseadas em identidades e baseadas em recursos às entidades principais nas contas de membros terão efeito apenas se a RCP permitir a ação.
+ **Políticas de controle de serviço (SCPs) do AWS Organizations**: as SCPs do AWS Organizations especificam as permissões máximas disponíveis para entidades principais nas contas em uma organização ou unidade organizacional (UO). As SCPs se aplicam a entidades principais em contas-membro, incluindo cada Usuário raiz da conta da AWS. Se uma SCP estiver presente, as permissões concedidas por políticas baseadas em identidade e baseadas em recurso a entidades principais nas suas contas-membro somente estarão efetivas se a SCP permitir a ação. As únicas exceções são as entidades principais na conta de gerenciamento da organização e os perfis vinculados ao serviço.
+ **Políticas baseadas em recursos**: as políticas baseadas em recursos concedem permissões para as entidades principais especificadas na política. As permissões definem o que a entidade principal pode fazer com o recurso ao qual a política está anexada.
+ **Limites de permissões**: os limites de permissões são um atributo que define as permissões máximas que uma política baseada em identidades pode conceder a uma entidade do IAM (usuário ou perfil). Quando você definir um limite de permissões para uma entidade, a entidade poderá executar apenas as ações que sejam permitidas tanto pelas políticas baseadas em identidade quanto pelo seu limites de permissões. Em alguns casos, uma negação implícita em um limite de permissões pode limitar as permissões concedidas por uma política baseada em recursos. Para obter mais informações, consulte [Como a lógica do código de imposição da AWS avalia as solicitações para permitir ou negar acesso](reference_policies_evaluation-logic_policy-eval-denyallow.md).
+ **Políticas baseadas em identidade**: as políticas baseadas em identidade são anexadas a uma identidade do IAM (usuário, grupo de usuários ou função) e concedem permissões a entidades do IAM (usuários e funções). Se somente políticas baseadas em identidade se aplicarem a uma solicitação, o AWS verificará todas essas políticas para pelo menos um `Allow`.
+ **Políticas de sessão**: políticas de sessão são políticas que você passa como parâmetros ao criar de forma programática uma sessão temporária para um perfil ou sessão de usuário federado. Para criar uma sessão de função de forma programática, use uma das operações da API `AssumeRole*`. Quando você faz isso e passa políticas de sessão, as permissões de sessão resultantes são a interseção da política baseada em identidade do IAM e as políticas de sessão. Para criar uma sessão de usuário federado, use as chaves de acesso do usuário do IAM para chamar de forma programática a operação da API `GetFederationToken`. Para obter mais informações, consulte [Políticas de sessão](access_policies.md#policies_session).
Lembre-se de que uma negação explícita em qualquer uma dessas políticas substitui a permissão.
**nota**
As **políticas declarativas do AWS Organizations** permitem que você declare e aplique centralmente a configuração desejada para um determinado AWS service (Serviço da AWS) em grande escala em uma organização. Como as políticas declarativas são aplicadas diretamente no nível do serviço, elas não afetam diretamente as solicitações de avaliação de políticas e não são incluídas no contexto da solicitação. Para obter mais informações, consulte [Políticas declarativas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) no Guia do Usuário do AWS Organizations.
## Exemplo de avaliação de políticas usando o modelo PARC
Para ilustrar como o contexto da solicitação interage com a avaliação da políticas, vamos considerar um exemplo de política:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/dept": "123"
}
}
}
]
}
```
------
Nesse exemplo, a política permitiria a ação `CreateBucket` apenas quando o contexto da solicitação incluísse um valor `aws:PrincipalTag/dept` de "123" e o recurso correspondesse ao nome de bucket `amzn-s3-demo-bucket1`. A tabela a seguir mostra como a AWS usa o contexto da solicitação para avaliar essa política e tomar decisões de autorização.
| Política | Contexto da solicitação | Resultado da avaliação |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=123
| **correspondência** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=123
| **Nenhuma correspondência** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=321
| **Nenhuma correspondência** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
Nenhum `aws:PrincipalTag` na solicitação. | **Nenhuma correspondência** |
# Como a lógica do código de imposição da AWS avalia as solicitações para permitir ou negar acesso
O código de imposição da AWS decide se a solicitação enviada a AWS deve ser permitida ou negada. A AWS avalia todas as políticas que são aplicáveis ao contexto da solicitação. A seguir há um resumo sobre a lógica de avaliação de políticas da AWS.
+ Por padrão, todas as solicitações são implicitamente negadas, com exceção do Usuário raiz da conta da AWS, que tem acesso total.
+ As solicitações devem ser explicitamente permitidas por uma política ou conjunto de políticas seguindo a lógica de avaliação abaixo para serem permitidas.
+ Uma negação explícita se sobrepõe a uma permissão explícita.
A avaliação da política pode diferir dependendo se a solicitação está dentro de uma única conta ou é uma solicitação entre contas. Para obter detalhes de como uma decisão de avaliação de política é tomada para um perfil ou usuário do IAM em uma única conta, consulte [Avaliação de políticas para solicitações em uma única conta](reference_policies_evaluation-logic_policy-eval-basics.md). Para obter detalhes de como uma decisão de avaliação de política é tomada para solicitações entre contas, consulte [Lógica de avaliação de política entre contas](reference_policies_evaluation-logic-cross-account.md).
+ **Avaliação de negação**: por padrão, todas as solicitações são negadas. Isso é chamado de [negação implícita](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). O código de imposição do AWS avalia todas as políticas na conta que se aplicam à solicitação. Isso inclui SCPs e RCPs do AWS Organizations, políticas baseadas em recurso, políticas baseadas em identidade, limites de permissões do IAM e políticas de sessão. Em todas essas políticas, o código de imposição procura por uma declaração `Deny` aplicável à solicitação. Esse processo é chamado de [negação explícita](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). Se o código de imposição encontrar uma única negação explícita aplicável, ele retornará uma decisão final de **Negar**. Se não houver uma negação explícita, a avaliação do código de imposição continuará.
+ **RCPs do AWS Organizations**: o código de imposição avalia as políticas de controle de recursos (RCPs) do AWS Organizations que se aplicam à solicitação. As RCPs se aplicam aos recursos da conta à qual as RCPs estão vinculadas. Se o código de imposição não encontrar nenhuma instrução `Allow` aplicável nas RCPs, ele retornará uma decisão final de **Negar**. Observe que uma política gerenciada pela AWS chamada `RCPFullAWSAccess` é criada e anexada automaticamente a cada entidade em sua organização, incluindo a raiz, cada OU e Conta da AWS quando as RCPs estão habilitadas. A `RCPFullAWSAccess` não pode ser separada, então sempre haverá uma instrução `Allow`. Se não houver uma RCP ou se a RCP permitir a ação solicitada, a avaliação do código de imposição continuará.
+ **SCPs do AWS Organizations**: o código de imposição avalia as políticas de controle de serviços (SCPs) do AWS Organizations que se aplicam à solicitação. As SCP aplicam-se às entidades principais da conta em que as SCP estão associadas. Se o código de imposição não encontrar nenhuma instrução `Allow` aplicável nas SCPs, ele retornará uma decisão final de **Negar**. Se não houver uma SCP ou se a SCP permitir a ação solicitada, a avaliação do código de imposição continuará.
+ **Políticas baseadas em recursos**: na mesma conta, as políticas baseadas em recursos afetam a avaliação de política de maneira diferente, dependendo do tipo de entidade principal que está acessando o recurso e a entidade principal que é permitida na política baseada em recursos. Dependendo do tipo de entidade principal, um `Allow` em uma política baseada em recursos pode resultar em uma decisão final de `Allow`, mesmo se houver uma negação implícita em uma política baseada em identidade, limite de permissões ou política de sessão.
Para a maioria dos recursos, você só precisa de um `Allow` explícito para a entidade principal em uma política baseada em identidade ou em recurso para conceder acesso. [Políticas de confiança de perfil do IAM](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies) e [políticas de chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) são exceções a essa lógica, porque devem permitir explicitamente o acesso para [entidades principais](reference_policies_elements_principal.md). As políticas baseadas em recursos para serviços diferentes do IAM e do AWS KMS também podem exigir uma declaração `Allow` explícita na mesma conta para conceder o acesso. Para obter mais informações, consulte a documentação do serviço específico com o qual está trabalhando.
Para solicitações de avaliação de política em uma única conta, a lógica de política baseada em recurso difere de outros tipos de política se a entidade principal especificada for um usuário do IAM, um perfil do IAM ou uma entidade principal de sessão. As entidades principais de sessão incluem [sessões de perfil do IAM](reference_policies_elements_principal.md#principal-role-session) ou [entidades principais de usuário federado do AWS STS](reference_policies_elements_principal.md#sts-session-principals). Se uma política baseada em recursos conceder permissão diretamente ao usuário do IAM ou à entidade principal de sessão que está fazendo a solicitação, uma negação implícita em uma política baseada em identidade, um limite de permissões ou uma política de sessão não afetará a decisão final.
+ **Função do IAM**: as políticas baseadas em recursos que concedem permissões a um ARN de função do IAM são limitadas por uma negação implícita em um limite de permissões ou política de sessão. É possível especificar o ARN do perfil no elemento da entidade principal ou a chave de condição `aws:PrincipalArn`. Em ambos os casos, a entidade principal que faz a solicitação é a **sessão de perfil do IAM**.
Limites de permissões ou políticas de sessão não limitam as permissões concedidas usando a chave de condição `aws:PrincipalArn` com um curinga (\$1) no elemento de entidade principal, a menos que as políticas baseadas em identidade contenham uma negação explícita. Para obter mais informações, consulte [Entidades de segurança de função do IAM](reference_policies_elements_principal.md#principal-roles).
**Exemplo de ARN de função**
```
arn:aws:iam::111122223333:role/examplerole
```
+ **Sessão de função do IAM**: na mesma conta, as políticas baseadas em recursos que concedem permissões a um ARN de sessão de função do IAM concedem permissões diretamente para a sessão de função assumida. As permissões concedidas diretamente a uma sessão não são limitadas por uma negação implícita em uma política baseada em identidade, um limite de permissões ou uma política de sessão. Quando você assume uma função e faz uma solicitação, a entidade principal que faz a solicitação é o ARN da sessão de função do IAM e não o ARN da função em si. Para obter mais informações, consulte [Entidades principais da sessão de função](reference_policies_elements_principal.md#principal-role-session).
**Exemplo de ARN de sessão de função**
```
arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
```
+ **Usuário do IAM**: na mesma conta, as políticas baseadas em recursos que concedem permissões a um ARN de usuário do IAM (que não é uma sessão de usuário federado) não são limitadas por uma negação implícita em uma política baseada em identidade ou limite de permissões.
**Exemplo de ARN de usuário do IAM**
```
arn:aws:iam::111122223333:user/exampleuser
```
+ **Entidade principal de usuário federado do AWS STS**: uma sessão de usuário federado é uma sessão criada por meio de um chamado a [`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken). Quando um usuário federado faz uma solicitação, a entidade principal que faz a solicitação é o ARN do usuário federado e não o ARN do usuário do IAM que federou. Na mesma conta, as políticas baseadas em recursos que concedem permissões a um ARN de usuário federado concedem permissões diretamente para a sessão. As permissões concedidas diretamente a uma sessão não são limitadas por uma negação implícita em uma política baseada em identidade, um limite de permissões ou uma política de sessão.
No entanto, se uma política baseada em recursos conceder permissão ao ARN do usuário do IAM que se federou, as solicitações feitas pelo usuário federado durante a sessão serão limitadas por uma negação implícita em um limite de permissão ou política de sessão.
**Exemplo de ARN de sessão de usuário federado**
```
arn:aws:sts::111122223333:federated-user/exampleuser
```
+ **Políticas baseadas em identidade**: o código de imposição verifica as políticas baseadas em identidade para a entidade principal. Para um usuário do IAM, isso inclui políticas de usuário e políticas de grupos aos quais o usuário pertence. Se não houver políticas baseadas em identidade ou instruções em políticas baseadas em identidade que permitam a ação solicitada, a solicitação será implicitamente negada e o código de imposição retornará uma decisão final de **Negar**. Se uma instrução em qualquer política aplicável baseada em identidade permitir a ação solicitada, a avaliação do código prosseguirá.
+ **Limites de permissões do IAM**: o código de aplicação verifica se a entidade do IAM que é usada pela entidade principal tem um limite de permissões. Se a política que é usada para definir o limite de permissões não permitir a ação solicitada, a solicitação será implicitamente negada. O código de imposição retorna uma decisão final de **Deny** (Negação). Se não houver um limite de permissões ou se o limite de permissões permitir a ação solicitada, a avaliação do código prosseguirá.
+ **Políticas de sessão**: o código de imposição confere se a entidade principal é uma entidade principal de sessão. As entidades principais de sessão incluem uma sessão de perfil do IAM ou uma sessão de usuário federado do AWS STS. Se a entidade principal não for uma entidade principal de sessão, o código de imposição retornará uma decisão final de **Allow** (Permitir).
Para entidades principais de sessão, o código de imposição confere se uma política de sessão foi transmitida na solicitação. É possível passar uma política de sessão enquanto usa a API AWS CLI ou AWS para obter credenciais temporárias para um perfil ou uma entidade principal de usuário federado do AWS STS. Se você não aprovou uma política de sessão, uma política de sessão padrão será criada, e o código de imposição retornará uma decisão final de **Permitir**.
+ Se houver uma política de sessão presente e ela não permitir a ação solicitada, a solicitação será implicitamente negada. O código de imposição retorna uma decisão final de **Deny** (Negação).
+ O código de imposição confere se a entidade principal é uma sessão de perfil. Se a entidade principal for uma sessão de perfil, a solicitação será **Permitida**. Caso contrário, a solicitação é implicitamente negada e o código de imposição retorna uma decisão final de **Negar**.
+ Se houver uma política de sessão presente e ela permitir a ação solicitada, o código de imposição retorna uma decisão final de **Allow** (Permitir).
# Avaliação de políticas para solicitações em uma única conta
## Avaliação de política para um perfil do IAM
O fluxograma a seguir fornece detalhes sobre como uma decisão de avaliação de política é tomada para um perfil do IAM em uma única conta.
![\[Fluxograma de avaliação para um perfil do IAM em uma única conta\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png)
## Avaliação de política para um usuário do IAM
O fluxograma a seguir fornece detalhes de como uma decisão de avaliação de política é tomada para um usuário do IAM em uma única conta.
![\[Fluxograma de avaliação para um usuário do IAM em uma única conta\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png)
## Exemplo de avaliação das políticas baseadas em identidade e políticas baseadas em recurso
Os tipos de políticas mais comuns são políticas baseadas em identidade e políticas baseadas em recurso. Quando o acesso a um recurso é solicitado, a AWS avalia todas as permissões concedidas pelas políticas para **pelo menos uma permissão** na mesma conta. Uma negação explícita em qualquer uma das políticas substitui a permissão.
**Importante**
Se a política baseada em identidade ou a política baseada em recursos na mesma conta permitir a solicitação, mas a outra política não, a solicitação ainda será permitida.
Suponha que Carlos tem o nome de usuário `carlossalazar` e tente salvar um arquivo no bucket `amzn-s3-demo-bucket-carlossalazar-logs` do Amazon S3.
Suponha também que a política a seguir esteja anexada ao usuário do IAM `carlossalazar`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3ListRead",
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetAccountPublicAccessBlock",
"s3:ListAccessPoints",
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "AllowS3Self",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
]
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::*log*"
}
]
}
```
------
A instrução `AllowS3ListRead` nessa política permite que Carlos visualize uma lista de todos os buckets da conta. A instrução `AllowS3Self` permite a Carlos acesso total ao bucket com o mesmo nome que seu nome de usuário. A instrução `DenyS3Logs` nega a Carlos acesso a qualquer bucket do S3 com `log` em seu nome.
Além disso, a seguinte política baseada em recurso (chamada de política de bucket) está anexada ao bucket `amzn-s3-demo-bucket-carlossalazar`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/carlossalazar"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
]
}
]
}
```
------
Essa política especifica que apenas o usuário `carlossalazar` pode acessar o bucket `amzn-s3-demo-bucket-carlossalazar`.
Quando Carlos faz sua solicitação para salvar um arquivo no bucket `amzn-s3-demo-bucket-carlossalazar-logs`, a AWS determina quais políticas são aplicáveis à solicitação. Nesse caso, somente a política baseada em identidade e a política baseada em recurso são aplicáveis. Essas são duas políticas de permissões. Como nenhum limite de permissões se aplica, a lógica de avaliação é reduzida à lógica a seguir.
![\[Fluxograma de avaliação\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/EffectivePermissionsShort.png)
A AWS primeiro verifica se há uma instrução `Deny` aplicável ao contexto da solicitação. Ele encontra uma, pois a política baseada em identidade nega explicitamente a Carlos o acesso a qualquer bucket do S3 usado para log. O acesso é negado a Carlos.
Suponha que ele perceba seu erro e tente salvar o arquivo no bucket `amzn-s3-demo-bucket-carlossalazar`. A AWS verifica se há uma instrução `Deny` e não encontra uma. Em seguida, ela verifica a políticas de permissões. Tanto a política baseada em identidade quanto a política baseada em recursos permitem a solicitação. Portanto, a AWS permite a solicitação. Se qualquer uma delas tivesse negado explicitamente a instrução, a solicitação teria sido negada. Se um dos tipos de política permitir a solicitação e o outro não, a solicitação ainda será permitida.
# Lógica de avaliação de política entre contas
É possível permitir que um principal em uma conta acesse os recursos em uma segunda conta. Isso é chamado de acesso entre contas. Quando você permite o acesso entre contas, a conta na qual o principal existe é chamada de conta *confiável*. A conta na qual o recurso existe é a conta *de confiança*.
Para permitir o acesso entre contas, anexe uma política baseada em recursos ao recurso que deseja compartilhar. É necessário anexar uma política baseada em identidade para a identidade que atua como entidade principal na solicitação. A política baseada em recursos na conta de confiança deve especificar o principal da conta confiável que terá acesso ao recurso. É possível especificar toda a conta ou seus usuários do IAM, entidades principais de usuários federados do AWS STS, perfis do IAM ou sessões de perfil assumido. Você também pode especificar um serviço da AWS como principal. Para obter mais informações, consulte [Como especificar uma entidade principal](reference_policies_elements_principal.md#Principal_specifying).
A política baseada em identidade do principal deve permitir o acesso solicitado ao recurso no serviço de confiança. É possível fazer isso especificando o ARN do recurso.
No IAM, você pode anexar uma política baseada em recurso a uma função do IAM para permitir que entidades de segurança em outras contas assumam essa função. A política baseada em recursos da função é chamada de política de confiança da função. Depois de assumir essa função, os principais permitidos podem usar as credenciais temporárias resultantes para acessar vários recursos na conta. Esse acesso é definido na política de permissões baseadas na identidade da função. Para saber como a ação de permitir o acesso entre contas usando as funções difere da ação de permitir o acesso entre contas usando outras políticas baseadas em recursos, consulte [Acesso a recursos entre contas no IAM](access_policies-cross-account-resource-access.md).
**Importante**
Outros serviços podem afetar a lógica de avaliação da política. Por exemplo, o AWS Organizations oferece suporte a [políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) e [políticas de controle de recursos](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) que podem ser aplicadas a entidades principais e a recursos em uma ou mais contas. O AWS Resource Access Manager oferece suporte a [fragmentos de políticas](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html) que controlam quais ações as entidades principais têm permissão para executar nos recursos compartilhados com elas.
## Determinar se uma solicitação entre contas é permitida
Para solicitações entre contas, o solicitante na `AccountA` confiável deve ter uma política baseada em identidade. Essa política deve permitir fazer uma solicitação para o recurso na de confiança `AccountB`. Além disso, a política baseada em recursos na `AccountB` deve permitir que o solicitante na `AccountA` acesse o recurso.
Ao fazer uma solicitação entre contas, a AWS executa duas avaliações. A AWS avalia a solicitação na conta de confiança e na conta confiável. Para obter mais informações sobre como uma solicitação é avaliada dentro de uma única conta, consulte [Como a lógica do código de imposição da AWS avalia as solicitações para permitir ou negar acesso](reference_policies_evaluation-logic_policy-eval-denyallow.md). A solicitação é permitida somente se ambas as avaliações retornarem uma decisão de `Allow`.
![\[Avaliação entre contas\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png)
1. Quando um principal em uma conta fazer uma solicitação para acessar um recurso em outra conta, esta é uma solicitação entre contas.
1. O principal solicitante existe na conta confiável (`AccountA`). Quando a AWS avalia essa conta, ela verifica a política baseada em identidade e as políticas que podem limitar uma política baseada em identidade. Para obter mais informações, consulte [Avaliação das políticas baseadas em identidade com limites de permissões](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound).
1. O recurso solicitado existe na conta de confiança (`AccountB`). Quando a AWS avalia esta conta, ela verifica a política baseada em recursos que está em anexo ao recurso solicitado e todas as políticas que podem limitar uma política baseada em recursos. Para obter mais informações, consulte [Avaliação das políticas baseadas em identidade com políticas baseadas em recurso](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp).
1. AWSA permite a solicitação somente se ambas avaliações de política de conta permitirem a solicitação.
O fluxograma a seguir fornece uma ilustração mais detalhada de como uma decisão de avaliação de política é tomada para uma solicitação entre contas. Mais uma vez, a AWS permitirá a solicitação somente se ambas avaliações de política de conta permitirem a solicitação.
![\[Avaliação detalhada de políticas entre contas\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png)
## Exemplo de avaliação de política entre contas
O exemplo a seguir demonstra um cenário no qual um perfil em uma conta recebe permissões por meio de uma política baseada em recursos em uma segunda conta.
Suponha que Carlos seja um desenvolvedor com um perfil do IAM de nome `Demo` na conta 111111111111. Ele quer salvar um arquivo no bucket `amzn-s3-demo-bucket-production-logs` do Amazon S3 na conta 222222222222.
Suponha também que a política a seguir esteja anexada ao perfil do IAM `Demo`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3ListRead",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "AllowS3ProductionObjectActions",
"Effect": "Allow",
"Action": "s3:*Object*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::*log*",
"arn:aws:s3:::*log*/*"
]
}
]
}
```
------
A instrução `AllowS3ListRead` nesta política permite que o Carlos visualize uma lista de todos os buckets no Amazon S3. A declaração `AllowS3ProductionObjectActions` permite que Carlos tenha acesso total a objetos no bucket `amzn-s3-demo-bucket-production`.
Além disso, a política baseada em recurso a seguir (chamada de política de bucket) está anexada ao bucket `amzn-s3-demo-bucket-production` na conta 222222222222.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject*",
"s3:PutObject*",
"s3:ReplicateObject",
"s3:RestoreObject"
],
"Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" },
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
}
]
}
```
------
Essa política permite que o perfil `Demo` acesse objetos no bucket `amzn-s3-demo-bucket-production`. O perfil poderá criar e editar, mas não excluir os objetos no bucket. O perfil não conseguirá gerenciar o bucket propriamente dito.
Quando Carlos faz sua solicitação para salvar um arquivo no bucket `amzn-s3-demo-bucket-production-logs`, a AWS determina quais políticas são aplicáveis à solicitação. Nesse caso, a política baseada em identidade anexada ao perfil `Demo` é a única política aplicável à conta `111111111111`. Na conta `222222222222`, não há uma política baseada em recursos anexada ao bucket `amzn-s3-demo-bucket-production-logs`. Quando a AWS avalia a conta `111111111111`, ela retorna uma decisão de `Deny`. Isto ocorre porque a declaração `DenyS3Logs` na política baseada em identidade explicitamente nega o acesso a quaisquer buckets de log. Para obter mais informações sobre como uma solicitação é avaliada dentro de uma única conta, consulte [Como a lógica do código de imposição da AWS avalia as solicitações para permitir ou negar acesso](reference_policies_evaluation-logic_policy-eval-denyallow.md).
Como a solicitação é explicitamente negada dentro de uma das contas, a decisão final é negar a solicitação.
![\[Solicitar a um bucket amzn-s3-demo-bucket-production-logs\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png)
Suponha que o Carlos perceba o erro e tente salvar o arquivo no bucket `Production`. A AWS primeiro verifica a conta `111111111111` para determinar se a solicitação é permitida. Somente a política baseada em identidade se aplica e permite a solicitação. A AWS verificará a conta `222222222222`. Somente a política baseada em recursos anexada ao bucket `Production` é aplicável, e permite a solicitação. Como ambas as contas permitem a solicitação, a decisão final é permitir a solicitação.
![\[Bucket de solicitação para produção\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png)
# A diferença entre negações explícitas e implícitas
Uma solicitação resultará em uma negação explícita aplicável se uma política aplicável incluir uma instrução `Deny`. Se as políticas aplicáveis a uma solicitação incluírem uma instrução `Allow` e uma instrução `Deny`, a instrução `Deny` superará a instrução `Allow`. A solicitação será negada explicitamente.
Uma negação implícita ocorre quando não há uma instrução `Deny` aplicável, mas também nenhuma instrução `Allow` aplicável. Como o acesso da entidade principal do IAM é negado por padrão, ela deve ter permissão explícita para executar uma ação. Caso contrário, o acesso será implicitamente negado.
Ao projetar sua estratégia de autorização, você deve criar políticas com instruções `Allow` para permitir que suas entidades principais façam solicitações com êxito. No entanto, você pode escolher qualquer combinação de negações implícitas e explícitas.
Por exemplo, é possível criar a seguinte política que inclui ações permitidas, ações negadas implicitamente e ações negadas explicitamente. A declaração `AllowGetList` **permite** acesso do tipo somente leitura a ações do IAM que comecem com os prefixos `Get` e `List`. Todas as outras ações no IAM, como `iam:CreatePolicy`, são **negadas implicitamente**. A declaração `DenyReports` **nega explicitamente** o acesso a relatórios do IAM, negando acesso a ações que incluem o sufixo `Report`, como `iam:GetOrganizationsAccessReport`. Se alguém adicionar outra política a essa entidade principal para conceder acesso a relatórios do IAM, como `iam:GenerateCredentialReport`, solicitações relacionadas a relatórios ainda serão negadas por causa dessa negação explícita.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGetList",
"Effect": "Allow",
"Action": [
"iam:Get*",
"iam:List*"
],
"Resource": "*"
},
{
"Sid": "DenyReports",
"Effect": "Deny",
"Action": "iam:*Report",
"Resource": "*"
}
]
}
```
------