Lógica da avaliação de política

Quando uma entidade principal tenta usar o AWS Management Console, 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 de segurança 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.

2. Processamento do contexto da solicitação: a AWS processa as informações coletadas na solicitação para determinar quais políticas se aplicam à solicitação.

3. Avaliação de políticas em uma única conta: a AWS avalia todos os tipos de política, que afetam a ordem em que as políticas são avaliadas.

4. Determinar se uma solicitação é permitida ou negada em uma conta: 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.

Processamento do contexto da solicitação

A AWS processa a solicitação para reunir as seguintes informações em um contexto de solicitação:

• Ações (ou operações): as ações ou as operações que a entidade de segurança deseja executar.

• Recursos: o objeto de recurso da AWS no qual as ações ou operações são executadas.

• Entidade de segurança: o usuário, função, usuário federado ou aplicativo que enviou a solicitação. As informações sobre a entidade principal incluem as políticas que estão associadas à entidade principal.

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

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

A AWS usa essas informações para localizar as políticas que se aplicam ao contexto da solicitação.

Avaliação de políticas em uma única conta

A forma como o AWS avalia as políticas depende dos tipos de políticas que se aplicam ao contexto da solicitação. Os seguintes tipos de políticas, listados em ordem de frequência, 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 IAM. Para saber como a AWS avalia políticas para acesso entre contas, consulte Lógica de avaliação de política entre contas.

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

2. Políticas baseadas em recurso: as políticas baseadas em recurso concedem permissões à entidade principal (conta, usuário, função e entidades principais de sessão, como sessões de função e usuários federados do IAM ) especificada como entidade principal. As permissões definem o que a entidade principal pode fazer com o recurso ao qual a política está anexada. Se as políticas baseadas em recurso e as políticas baseadas em identidade se aplicarem a uma solicitação, o AWS verificará todas as políticas para pelo menos um Allow. Quando políticas baseadas em recursos são avaliadas, o ARN da entidade principal especificado na política determina se as negações implícitas em outros tipos de política são aplicáveis à decisão final.

3. Limites de permissões do IAM: limites de permissões são um recurso avançado que define as permissões máximas que uma política baseada em identidade pode conceder a uma entidade do IAM (usuário ou função). Quando você definir um limite de permissões para uma entidade, a entidade poderá executar apenas as ações que são permitidas por ambas as políticas baseadas em identidade e seus 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 saber mais, consulte Determinar se uma solicitação é permitida ou negada em uma conta mais adiante neste tópico.

4. Políticas de controle de serviço (SCPs) do AWS Organizations: as SCPs do Organizations especificam as permissões máximas para uma organização ou unidade organizacional (UO). O máximo de SCP se aplica a entidades principais em contas-membro, incluindo cada Usuário raiz da conta da AWS. Se uma SCP estiver presente, as políticas baseadas em identidade e baseadas em recurso concedem permissões a entidades principais em contas-membro somente se essas políticas e a SCP permitirem a ação. Se um limite de permissões e uma SCP estiverem presentes, o limite, o SCP e a política baseada em identidade devem permitir a ação.

5. Políticas de sessão: as políticas de sessão são políticas avançadas que você passa como parâmetros ao criar uma sessão temporária de forma programática para uma função ou um 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. Uma política baseada em recurso tem um efeito diferente na avaliação das permissões da política de sessão. A diferença depende de se o usuário ou o ARN da função ou o ARN da sessão está listado como a entidade principal na política baseada em recurso. Para obter mais informações, consulte Políticas de sessão.

Lembre-se de que uma negação explícita em qualquer uma dessas políticas substitui a permissão.

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 as permissões totais 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 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.

Avaliação das políticas baseadas em identidade com SCPs do Organizations

Quando um usuário pertence a uma conta que é membro de uma organização, as permissões resultantes são a interseção das políticas do usuário e a SCP. Isso significa que uma ação deve ser permitida tanto pela política baseada em identidade quanto pelo SCP. Uma negação explícita em qualquer uma dessas políticas substitui a permissão.

Você pode saber se sua conta é membro de uma organização no AWS Organizations. Os membros da organização podem ser afetados por uma SCP. Para visualizar esses dados usando o comando da AWS CLI ou a operação da API da AWS, você deve ter permissões para a ação organizations:DescribeOrganization da sua entidade do Organizations. Você deve ter permissões adicionais para executar a operação no console do Organizations. Para saber se uma SCP está negando acesso a uma solicitação específica ou alterar as permissões efetivas, entre em contato com o administrador do AWS Organizations.

Determinar se uma solicitação é permitida ou negada em uma conta

Suponha que uma entidade principal envie uma solicitação para a AWS para acessar um recurso na mesma conta que a entidade principal. O código de imposição da AWS decide se a solicitação deve ser permitida ou negada. A AWS avalia todas as políticas que são aplicáveis ao contexto da solicitação. A seguir apresentamos um resumo da lógica de avaliação da AWS para políticas em uma única conta.

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

• Uma permissão explícita em uma política baseada em recurso ou identidade substitui esse padrão.

• Se houver um limite de permissões, uma SCP do Organizations ou uma política de sessão, isso poderá substituir a permissão com uma negação implícita.

• Uma negação explícita em qualquer política substitui todas as permissões.

O seguinte fluxograma fornece detalhes sobre como a decisão é tomada. Este fluxograma não aborda o impacto de políticas baseadas em recursos e negações implícitas em outros tipos de políticas.

1. Avaliação de negação: por padrão, todas as solicitações são negadas. Isso é chamado de negação implícita. O código de imposição do AWS avalia todas as políticas na conta que se aplicam à solicitação. Isso inclui SCPs 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 uma instrução Deny que se aplica à solicitação. Esse processo é chamado de negação explícita. Se o código de imposição encontrar uma única negação explícita aplicável, o código retornará uma decisão final Deny (Negação). Se não houver uma negação explícita, a avaliação do código de imposição continuará.

2. SCPs do Organizations: em seguida, 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 uma declaração Allow aplicável nas SCPs, a solicitação será negada implicitamente, mesmo que a negação seja implícita. O código de imposição retorna uma decisão final de Deny (Negação). 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á.

3. 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 uma permissão explícita 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 e políticas de chave do KMS são exceções a essa lógica, porque devem permitir explicitamente o acesso para entidades principais.

   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 as sessões de função do IAM ou uma sessão de usuário federado do IAM. 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.

   A tabela a seguir ajuda a entender o impacto de políticas baseadas em recurso para diferentes tipos de entidades principais quando negações implícitas estão presentes em políticas baseadas em identidade, limites de permissões e políticas de sessão.

   Políticas baseadas em recursos e negações implícitas em outros tipos de política (mesma conta)
   Entidade principal fazendo a solicitação	Política baseada em recurso	Política baseada em identidade	Limite de permissões	Política de sessão	Result	Motivo
   Perfil do IAM	Não aplicável	Não aplicável	Não aplicável	Não aplicável	Não aplicável	Uma função não pode fazer uma solicitação por conta própria. As solicitações são feitas com a sessão de função depois que uma função é assumida.
   Sessão de função do IAM	Permite o ARN de função	Negação implícita	Negação implícita	Negação implícita	DENY	O limite de permissões e a política de sessão são avaliados como parte da decisão final. Uma negação implícita em qualquer política resulta em uma decisão DENY (negar).
   Sessão de função do IAM	Permite ARN de sessão de função	Negação implícita	Negação implícita	Negação implícita	PERMISSÃO	As permissões são concedidas diretamente à sessão. Outros tipos de política não afetam a decisão.
   Usuário do IAM	Permite o ARN de usuário do IAM	Negação implícita	Negação implícita	Não aplicável	PERMISSÃO	As permissões são concedidas diretamente ao usuário. Outros tipos de política não afetam a decisão.
   Usuário federado do IAM (GetFederationToken)	Permite o ARN de usuário do IAM	Negação implícita	Negação implícita	Negação implícita	DENY	Uma negação implícita seja no limite de permissões ou na política de sessão resulta em DENY (negar).
   Usuário federado do IAM (GetFederationToken)	Permite ARN de sessão de usuário federado do IAM	Negação implícita	Negação implícita	Negação implícita	PERMISSÃO	As permissões são concedidas diretamente à sessão. Outros tipos de política não afetam a decisão.
   usuário raiz	Permite o ARN de usuário raiz	Não aplicável	Não aplicável	Não aplicável	PERMISSÃO	O usuário raiz tem acesso completo e irrestrito a todos os recursos na sua Conta da AWS. Para aprender como controlar o acesso de usuários raiz em contas no AWS Organizations, consulte Políticas de controle de serviços (SCPs), no Guia do usuário do Organizations.
   Principal do serviço da AWS	Permite uma entidade principal de serviço da AWS	Não aplicável	Não aplicável	Não aplicável	PERMISSÃO	Quando uma política baseada em recursos concede permissões diretamente a uma entidade principal de serviço da AWS, outros tipos de política não afetam a decisão.

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

     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.

     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

   • Sessões de usuário federado do IAM: uma sessão de usuário federado do IAM é uma sessão criada mediante o chamado de 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 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 do IAM

     arn:aws:sts::111122223333:federated-user/exampleuser

4. Políticas baseadas em identidade: o código verifica as políticas baseadas em identidade para a entidade de segurança. 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 declarações em políticas baseadas em identidade que permitam a ação solicitada, a solicitação será implicitamente negada e o código retornará uma decisão final de Deny (Negar). Se uma declaração em qualquer política aplicável baseada em identidade permitir a ação solicitada, o código continuará.

5. Limites de permissões do IAM: em seguida, o código confere 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 retorna uma decisão final de Negação. Se não houver um limite de permissões ou se o limite de permissões permitir a ação solicitada, o código continuará.

6. Políticas de sessão: em seguida, o código confere se a entidade principal é uma entidade principal de sessão. As entidades principais de sessão incluem uma sessão de função do IAM ou uma sessão de usuário federado do IAM. 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 confere se uma política de sessão foi transmitida na solicitação. Você pode transmitir uma política de sessão enquanto usa a AWS CLI ou API da AWS para obter credenciais temporárias para uma função ou um usuário federado do IAM.

   • 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 retorna uma decisão final de Negação.

   • Se não houver política de sessão, o código vai conferir se a entidade principal é uma sessão de função. Se a entidade principal for uma sessão de função, a solicitação será Permitida. Caso contrário, a solicitação é implicitamente negada e o código retorna uma decisão final de Deny (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).

7. Erros: Se o código de aplicação da AWS encontrar um erro em qualquer ponto durante a avaliação, ele gerará uma exceção e será fechado.

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 carlossalazar-logs do Amazon S3.

Suponha também que a política a seguir esteja anexada ao usuário do IAM carlossalazar.

{
    "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:::carlossalazar/*",
                "arn:aws:s3:::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 carlossalazar.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/carlossalazar"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        }
    ]
}

Essa política especifica que apenas o usuário carlossalazar pode acessar o bucket carlossalazar.

Quando Carlos faz sua solicitação para salvar um arquivo no 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.

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

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.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGetList",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyReports",
            "Effect": "Deny",
            "Action": "iam:*Report",
            "Resource": "*"
        }
    ]
}