O que as políticas IAM realmente conseguem controlar?
Quem trabalha com segurança na AWS já se deparou com perguntas do tipo: “Consigo usar uma SCP do AWS Organizations para bloquear a criação de security groups que permitem tráfego de 0.0.0.0/0?” ou “Dá para impedir o upload de objetos no S3 que não estejam criptografados?” ou ainda “Posso bloquear funções Lambda com mais de 512 MB de memória alocada?”
Algumas dessas situações são perfeitamente controláveis via políticas Gerenciamento de Identidade e Acesso (IAM). Outras, simplesmente não são. A diferença está em um princípio fundamental da autorização na AWS: as políticas tomam decisões com base nas informações disponíveis no contexto de autorização no momento da chamada de API. Se a informação não estiver nesse contexto, a política não tem como avaliá-la.
A AWS publicou um post detalhado no blog de segurança explicando exatamente como usar o AWS Service Authorization Reference para descobrir o que é ou não controlável por políticas — e o que fazer quando as políticas não são suficientes.
Como funciona o contexto de autorização na AWS
Toda vez que uma requisição é feita à AWS — seja pelo console, pela Interface de Linha de Comando (AWS CLI) ou por um SDK — o serviço que recebe a requisição monta um contexto de requisição com as informações sobre aquela operação. É esse contexto que será usado para avaliar as políticas.
Esse contexto segue o modelo PARC, com quatro componentes:
- Principal: quem está fazendo a requisição, incluindo atributos como tags e contexto de sessão
- Action (Ação): a operação de API solicitada (por exemplo,
s3:PutObjectouec2:RunInstances) - Resource (Recurso): o recurso AWS de destino, identificado pelo ARN (Nome de Recurso da Amazon)
- Condition (Condição): contexto adicional disponível no momento da requisição, como endereço IP, horário, parâmetros de criptografia, status de MFA (Autenticação Multifator) e atributos específicos do serviço
Para ilustrar, veja como seria o contexto de uma requisição de upload de objeto no Amazon S3:
Principal: AIDA123456789EXAMPLE
Action: s3:PutObject
Resource: arn:aws:s3:::my-bucket/documents/samplereport.pdf
Condition:
aws:PrincipalTag/Department=Finance
aws:RequestedRegion=us-east-1
aws:SourceIp=x.x.x.x
aws:MultiFactorAuthPresent=true
s3:x-amz-server-side-encryption=AES256
s3:x-amz-storage-class=STANDARD_IARepare que o contexto inclui o método de criptografia e a classe de armazenamento especificados — e isso significa que uma política pode avaliar esses atributos. Por outro lado, o conteúdo real do arquivo, o tamanho do objeto ou padrões de dados internos não fazem parte do contexto, portanto não podem ser avaliados por políticas IAM.
O Service Authorization Reference: a fonte definitiva
O Service Authorization Reference é a documentação oficial da AWS que lista, para cada serviço, quais ações podem ser controladas por políticas, quais tipos de recursos podem ser alvos dessas ações e — o mais importante — quais condition keys (chaves de condição) estão disponíveis para cada ação.
As chaves de condição se dividem em duas categorias:
- Chaves de condição globais: aplicáveis a qualquer serviço AWS (como
aws:SourceIp,aws:PrincipalTag, etc.) - Chaves de condição específicas de serviço: definidas para uso com um serviço específico (como
s3:x-amz-server-side-encryptionouec2:InstanceType)
A regra é simples: se a informação que você quer controlar não aparece como uma chave de condição nessa documentação, você não conseguirá controlá-la apenas com políticas IAM.
Como usar o Service Authorization Reference na prática
O processo para verificar se um requisito pode ser atendido por políticas IAM é direto:
- Acesse a página do serviço específico no Service Authorization Reference — por exemplo, ações, recursos e chaves de condição para o Amazon S3
- Localize a ação que você quer controlar (seja preciso, pois diferentes ações têm diferentes chaves disponíveis)
- Examine a coluna de chaves de condição para aquela ação
- Se a informação que você precisa não estiver listada como chave de condição, uma política IAM não será suficiente
Como exemplo, ao examinar a ação RunInstances do Amazon Elastic Compute Cloud (Amazon EC2) na seção do EC2 no Service Authorization Reference, é possível ver que diferentes tipos de recursos têm chaves de condição diferentes. Para o tipo de recurso instance*, estão disponíveis chaves como ec2:InstanceType, ec2:EbsOptimized e aws:RequestTag/. Para network-interface*, há chaves como ec2:Subnet, ec2:Vpc e ec2:AssociatePublicIpAddress. O reference completo lista dezenas de chaves de condição para os vários tipos de recursos afetados pelo RunInstances.
Acesso programático ao Service Authorization Reference
Além da documentação em formato legível, a AWS disponibiliza o Service Authorization Reference em formato JSON para automação de fluxos de trabalho de gerenciamento de políticas. Para detalhes sobre a estrutura JSON e definições dos campos, consulte a documentação sobre acesso programático às informações simplificadas de serviços AWS. Desenvolvedores também podem usar o IAM MCP Server para operações IAM com assistentes de IA, gerenciando usuários, funções, políticas e permissões seguindo boas práticas de segurança.
Exemplos práticos: o que é possível controlar com políticas IAM
Exemplo 1: Exigir criptografia AES-256 em uploads no S3
No Service Authorization Reference do Amazon S3, a chave de condição s3:x-amz-server-side-encryption está disponível para a ação s3:PutObject. Isso significa que é possível criar uma política que bloqueie uploads sem criptografia AES-256:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnencryptedObjectUploads",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
}
]
}Essa é uma política baseada em recurso que pode ser aplicada diretamente no bucket S3. Ela nega qualquer requisição PutObject que não especifique criptografia AES-256.
Exemplo 2: Restringir tipos de instância EC2 por centro de custo
No Service Authorization Reference do Amazon EC2, a chave ec2:InstanceType está disponível para a ação ec2:RunInstances. Combinando essa chave com a chave global aws:PrincipalTag/tag-key, é possível criar uma política baseada em identidade que aplica restrições diferentes dependendo do centro de custo do usuário:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowDevInstanceTypes",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/CostCenter": "Development"
},
"StringLike": {
"ec2:InstanceType": "t3.*"
}
}
},
{
"Sid": "AllowProdInstanceTypes",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/CostCenter": "Production"
},
"StringLike": {
"ec2:InstanceType": [
"m5.*",
"c5.*",
"r5.*"
]
}
}
}
]
}Com essa política, usuários com a tag CostCenter=Development só podem lançar instâncias T3 (mais econômicas), enquanto usuários de produção têm acesso às famílias M5, C5 e R5. Essa abordagem permite controle de custos dinâmico com base na identidade do solicitante. Atenção: recursos adicionais são necessários na política IAM para lançar instâncias EC2 com sucesso — consulte a documentação de lançamento de instâncias para a lista completa.
Exemplo 3: Controle de acesso granular no DynamoDB por nome de usuário
O Service Authorization Reference do Amazon DynamoDB expõe valores de chave de partição no contexto de autorização para as ações GetItem, PutItem e UpdateItem. Isso permite criar uma política em que cada usuário só acessa os itens onde a chave de partição corresponde ao seu próprio nome de usuário:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem"
],
"Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/UserProfiles",
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:LeadingKeys": ["${aws:username}"]
}
}
}
]
}Com essa política, se a usuária alice tentar acessar um item com chave de partição bob, a requisição será negada automaticamente.
Cenários que exigem mais do que políticas IAM
Alguns requisitos de segurança simplesmente não podem ser atendidos apenas com políticas IAM — e o Service Authorization Reference é a ferramenta certa para descobrir isso antes de perder tempo tentando.
Cenário 1: Bloquear criação de regras de security group com 0.0.0.0/0 na porta 22
A ação responsável por adicionar regras de entrada em security groups é a ec2:AuthorizeSecurityGroupIngress. Ao consultar o Service Authorization Reference do Amazon EC2 e examinar as chaves de condição disponíveis para a ação AuthorizeSecurityGroupIngress, encontramos apenas:
aws:ResourceTag/${TagKey}: filtra por tag do recursoec2:ResourceTag/${TagKey}: filtra por tag do recurso EC2ec2:SecurityGroupID: filtra pelo ID do security groupec2:Vpc: filtra pela VPC
Não há nenhuma chave de condição para blocos CIDR, números de porta ou protocolos. O contexto de autorização simplesmente não inclui essas informações — portanto, políticas IAM não conseguem controlar esses atributos.
Solução alternativa: usar uma abordagem reativa com o AWS Config e a regra gerenciada INCOMING_SSH_DISABLED para detectar regras excessivamente permissivas. Também é possível combinar o Amazon EventBridge com Lambda para notificar a equipe de segurança ou reverter automaticamente a configuração não conforme. Para mais detalhes, a AWS publicou um guia sobre como reverter automaticamente e receber notificações sobre alterações em security groups da VPC.
Cenário 2: Impedir criação de funções Lambda com mais de 512 MB de memória
Seguindo a mesma metodologia, ao consultar o Service Authorization Reference do AWS Lambda e examinar as chaves de condição disponíveis para a ação CreateFunction com o tipo de recurso function*, encontramos apenas chaves como lambda:CodeSigningConfigArn, lambda:Layer e lambda:VpcIds. Não existe nenhuma chave de condição para alocação de memória, timeout, armazenamento efêmero ou seleção de runtime.
Soluções alternativas:
- Usar uma abordagem de política como código (PaC) com AWS CloudFormation Hooks — veja o guia prático introdução à política como código
- Usar o AWS Service Catalog para disponibilizar configurações pré-aprovadas de Lambda
- Aplicar a regra do AWS Config
LAMBDA_FUNCTION_SETTINGS_CHECKpara detectar funções não conformes
Princípios para trabalhar com políticas IAM de forma eficaz
Com base no que a AWS detalhou, vale reforçar alguns pontos fundamentais:
- Políticas controlam o que está no contexto de autorização, não todos os parâmetros visíveis na documentação de API
- O Service Authorization Reference é a fonte definitiva: se algo não está listado como chave de condição, não é controlável via políticas
- Ações diferentes têm contextos diferentes, mesmo dentro do mesmo serviço
- Abordagens alternativas existem: AWS Config, EventBridge e controles específicos de serviços cobrem o que as políticas não alcançam
- Segurança em camadas é essencial: combine controles preventivos, detectivos e responsivos para uma defesa em profundidade eficaz
Próximos passos recomendados
Para quem quer aprofundar o conhecimento em políticas IAM, a AWS sugere explorar o simulador de políticas IAM para testar e depurar políticas, ler sobre tipos de políticas IAM e quando usar cada uma, e assistir ao vídeo Entendendo a linguagem de políticas IAM da AWS: elementos, avaliação e boas práticas.
O ponto central é que as políticas IAM são ferramentas poderosas de prevenção, mas a segurança eficaz na AWS não depende de um único controle perfeito — ela vem da combinação inteligente de medidas preventivas, detectivas e responsivas.
Fonte
Can I do that with policy? Understanding the AWS Service Authorization Reference (https://aws.amazon.com/blogs/security/can-i-do-that-with-policy-understanding-the-aws-service-authorization-reference/)
Leave a Reply