Anatomia de um Documento de Política do IAM

Na AWS, as permissões são expressas por meio de políticas: documentos JSON que concedem ou negam acesso a ações em recursos. Ler uma política com fluência é uma habilidade essencial do SCS-C02, pois quase toda questão de acesso se resume ao que uma política permite, nega ou deixa de abranger. Esta lição analisa a estrutura parte por parte.

Uma política contém um campo Version (use "2012-10-17") e um elemento Statement, que pode ser um statement ou uma matriz deles. Cada statement é uma regra independente. A AWS avalia todos os statements, portanto um único documento pode permitir algumas ações e negar explicitamente outras.

Cada statement tem um Effect que pode ser Allow ou Deny. A AWS nega por padrão: sem um Allow correspondente, uma requisição é negada. Um Deny correspondente sempre prevalece sobre qualquer Allow. Reconhecer o Effect de cada statement é a primeira coisa a verificar ao analisar o acesso.

O elemento Action lista as operações da API às quais o statement se aplica, escritas como serviço:operação, por exemplo s3:GetObject. Caracteres curinga são permitidos, como s3:* ou s3:Get*. O inverso, NotAction, corresponde a todas as ações exceto as listadas e é fácil de usar incorretamente, por isso a prova o aborda com atenção.

O elemento Resource identifica os recursos aos quais as ações se aplicam, usando ARNs (nomes de recursos da Amazon). Por exemplo, um bucket específico e seus objetos. O valor "*" significa todos os recursos. NotResource corresponde a tudo, exceto aos ARNs listados. Restringir rigorosamente o escopo dos recursos é fundamental para aplicar o privilégio mínimo.

Esta política baseada em identidade permite somente a leitura de objetos de um bucket. Observe a ação, o ARN específico no nível do objeto e o efeito Allow explícito.

Um bloco Condition opcional restringe quando um statement se aplica, usando chaves de contexto e operadores. Por exemplo, permite o acesso somente se a requisição usar TLS (aws:SecureTransport) ou vier de um IP conhecido. As condições permitem adicionar um controle detalhado e sensível ao contexto, além de simplesmente definir ação e recurso.

As políticas baseadas em identidade omitem o elemento Principal porque já estão anexadas a um principal. As políticas baseadas em recursos (como uma política de bucket do S3) incluem Principal para identificar a quem a regra se aplica. Verificar se uma política contém um Principal informa qual tipo de política está sendo lido.

Caracteres curinga como "Action": "*" e "Resource": "*" juntos concedem acesso administrativo completo. A prova frequentemente apresenta uma política permissiva demais e pede que você a restrinja. A correção é substituir os curingas por ações e ARNs específicos, aplicando o privilégio mínimo.

Um ARN tem o formato arn:partition:service:region:account:resource. Alguns serviços omitem a região ou a conta (o S3 omite ambas na parte referente ao bucket). Ler os ARNs com precisão permite identificar se uma política tem como alvo um recurso, uma conta ou tudo, o que afeta diretamente o nível de acesso concedido.

Para analisar qualquer política: verifique o Effect, leia o Action (preste atenção a NotAction e aos curingas), restrinja o escopo do Resource (observe o "*") e examine qualquer Condition. Lembre-se de que a negação explícita prevalece sobre a permissão e que a negação é o padrão. Com prática, você poderá avaliar o alcance real de uma política em segundos, exatamente como a prova exige.

Teste sua habilidade de leitura de políticas.

Uma política do IAM é um JSON com uma Version e uma matriz de Statement. Cada statement tem um Effect (Allow/Deny), Action (ou NotAction), Resource por meio de ARNs (ou NotResource) e uma Condition opcional. As políticas baseadas em recursos adicionam um Principal. A negação é o padrão, a negação explícita sempre prevalece e os curingas indicam permissões excessivas que devem ser restringidas.