Avaliação de políticas IAM e negação explícita

Usando a segurança da AWS para desenvolvedores

Rahul Singh

Technical Product Manager

Uma policy é uma lista de regras

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Três campos de uma declaração IAM empilhados em uma única coluna e numerados de um a três: Effect é allow ou deny, Action é qual chamada de API, e Resource é para que recurso aponta, nomeado por um ARN.

Uma policy é uma lista de regras

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Quatro campos de uma declaração IAM empilhados em uma única coluna e numerados de um a quatro: Effect é allow ou deny, Action é qual chamada de API, Resource é para que recurso aponta, nomeado por um ARN, e Condition é quais circunstâncias devem valer. Uma linha final diz: quatro campos, uma regra.

Três campos perguntam, um campo responde

A pergunta

Action: é esta a chamada
Resource: é este o alvo
Condition: as circunstâncias batem

A resposta

Effect: allow ou deny

Quatro campos de uma declaração IAM empilhados verticalmente: Action, Resource e Condition agrupados por um colchete rotulado "A pergunta", e Effect agrupado por um segundo colchete rotulado "A resposta".

Regras vêm de mais de um lugar

Um documento de policy anexado a uma role, com uma seta da role até um bucket.

Baseada em identidade

Anexada à role
O que esta role pode fazer

Regras vêm de mais de um lugar

Um documento de policy anexado a uma role, com uma seta da role até um bucket.

Um documento de policy anexado a um recurso, com uma seta do principal até um bucket.

Baseada em identidade

Anexada à role
O que esta role pode fazer

Baseada em recurso

Anexada ao alvo acessado
Quem pode acessar este bucket

Quando as regras entram em conflito

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Quando as regras entram em conflito

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Requisição: s3:DeleteObject resulta em: Negado.

Uma negação explícita vence qualquer permissão, por mais ampla que seja

Uma declaração allow e uma deny alimentando a mesma requisição, com o caminho de deny destacado e o resultado marcado como negado.

A ordem de avaliação e a negação implícita

Fluxograma da avaliação de políticas IAM: uma chamada de API verifica primeiro se há uma negação explícita aplicável, depois se há uma permissão aplicável, e cai em negação implícita quando nenhuma é encontrada.

Negação explícita: algo disse não
Permitir: algo disse sim e nada disse não
Negação implícita: nada disse nada

Quatro requisições, três resultados

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "*"}

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}

s3:GetObject → permitir: o allow amplo cobre isso
s3:DeleteObject → negação explícita: uma declaração diz não
kms:Decrypt, dynamodb:GetItem → negação implícita: esta policy não menciona esses serviços
KMS guarda chaves de criptografia; DynamoDB é um banco chave-valor gerenciado

Por que adicionar permissões costuma falhar

Mesmo erro, duas causas

Negação explícita

Outro allow não muda nada
Ache a deny e restrinja ou remova

Negação implícita

Um allow específico resolve
Na identidade que fez a chamada

Um erro AccessDenied ramificando em duas causas. À esquerda, uma deny foi encontrada, então mais allows não mudam nada. À direita, nenhum allow foi encontrado, então um allow específico na identidade que chamou resolve.

Vamos praticar!

Usando a segurança da AWS para desenvolvedores