Lógica da avaliação de política - AWS Identity and Access Management

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

  2. Processar o contexto da solicitação – a AWS processa as informações coletadas na solicitação para determinar quais políticas aplicar à solicitação.

  3. Avaliar políticas em uma única conta – a AWS avalia todos os tipos de políticas, o que afeta a ordem em que as políticas são avaliadas.

  4. Determinar se uma solicitação é permitida ou negada em uma conta – a AWS processa as políticas no contexto da solicitação para determinar se a solicitação é permitida ou negada.

Processar o 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 o principal deseja executar.

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

  • Principal – O usuário, a função, o usuário federado ou o 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.

Avaliar 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 do 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 identidade são anexadas a uma identidade do IAM (usuário, grupo de usuários ou função) e conceder permissões para 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 ou usuário federado) especificada como 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.

  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 com base 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. Uma negação implícita em um limite de permissões não limita as permissões concedidas por uma política baseada em recursos.

  4. Políticas de controle de serviço (SCPs) AWS Organizations – Os SCPs do Organizations especificam o máximo de permissões 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 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.

Avaliar 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 e políticas baseadas em recurso

Avaliar 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 limites de permissões

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


          Avaliação das políticas baseadas em identidade e SCPs

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 operação de 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 aplicação da AWS decide se a solicitação deve ser permitida ou negada. A AWS reúne todas as políticas aplicáveis ao contexto da solicitação. Veja a seguir um resumo de nível superior da lógica de avaliação do AWS sobre essas políticas em uma única conta.

  • Por padrão, todas as solicitações são implicitamente negadas. (Opcionalmente, por padrão, Usuário raiz da Conta da AWS 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, SCP de Organizations ou 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.


        Fluxograma de avaliação
  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. Entre eles estão SCPs do AWS Organizations, políticas baseadas em recurso, limites de permissões do IAM, políticas de sessão de função e políticas baseadas em identidade. 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 encontrar uma única negação explícita aplicável, o código retornará uma decisão final de Negação. Se não houver uma negação explícita, o código continuará.

  2. SCPs do Organizations – Em seguida, o código avalia as políticas de controle de serviço (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, a solicitação será negada implicitamente. O código retorna uma decisão final de Negação. Se não houver uma SCP ou se a SCP permitir a ação solicitada, o código continuará.

  3. Políticas baseadas em recurso – se o recurso solicitado tiver uma política baseada em recurso que permite que a entidade principal execute a ação solicitada, o código retornará uma decisão final de Permissão. Se não houver uma política baseada em recurso ou se a política não incluir uma instrução Allow, o código continuará.

    nota

    Essa lógica poderá se comportar de maneira diferente se você especificar o ARN de uma função ou usuário do IAM como o principal da política baseada em recurso. Quando você assume a função ou federa o usuário, ele gera uma sessão. Nesse caso, as permissões efetivas concedidas pela política baseada em recursos são restringidas por um limite de permissões ou política de sessão para esse principal. Para obter mais informações sobre permissões efetivas para sessões de função assumida ou sessões de usuário federado, consulte Políticas de sessão e Avaliação de permissões efetivas com limites.

  4. Limites de permissões do IAM – O código de aplicação verifica se a entidade do IAM que é usada pelo 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á.

  5. Políticas de sessão – o código verifica se a entidade principal está usando uma sessão que foi assumida como transmitindo uma política de sessão. Você pode passar uma política de sessão usando a API do AWS CLI ou AWS para obter credenciais temporárias para uma função ou usuário federado. Se a política de sessão estiver presente e 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 uma política de sessão ou se a política permitir a ação solicitada, o código continuará.

  6. Políticas baseadas em identidade – o código verifica as políticas baseadas em identidade para a entidade principal. Para um usuário do IAM, esses incluem políticas de usuário e políticas de grupos aos quais o usuário pertence. Se uma instrução em qualquer política baseada em identidade aplicável permitir a ação solicitada, o código de imposição retornará uma decisão final de Permissão. Se não houver instruções que permitem a ação solicitada, a solicitação será implicitamente negada, e o código retornará uma decisão final de Negação.

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

Exemplo de avaliação de política baseada em identidade e política baseada em recurso

Os tipos de políticas mais comuns são políticas baseadas em identidade e políticas baseadas em recurso.

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 carlossalazar do IAM

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:HeadBucket" ], "Resource": "*" }, { "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*", "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", "Action": "s3:*", "Principal": { "AWS": "arn:aws:iam::111122223333:user/carlossalazar" }, "Resource": "*" } ] }

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.


        Fluxograma de avaliação

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 um usuário, uma função ou um usuário federado do IAM, é negado por padrão, eles devem 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, você pode criar a seguinte política para permitir a um usuário administrador acesso total a todos os recursos no AWS, mas negar explicitamente acesso ao faturamento. Se alguém adicionar outra política a esse administrador concedendo acesso ao faturamento a ele, esse acesso ainda será negado por causa daquela negação explícita.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "aws-portal:*", "Resource": "*" } ] }

Como alternativa, você pode criar a seguinte política para permitir que um usuário gerencie usuários, mas não grupos ou quaisquer outros recursos no IAM. Essas ações são implicitamente negadas, assim como as ações em outros serviços. No entanto, se alguém adicionar uma política ao usuário que permita que ele execute essas outras ações, ele será permitido.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:CreateUser", "iam:DeleteUser", "iam:DeleteUserPolicy", "iam:DetachUserPolicy", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:ListUsers", "iam:PutUserPolicy", "iam:UpdateUser" ], "Resource": "*" } }