Terceiro post do Nível Intermediário da série AWS IAM. Vamos aplicar tudo o que vimos até aqui em um dos usos mais frequentes e importantes das roles: dar permissões a serviços e aplicações sem expor chaves. Este é o padrão que você vai repetir dezenas de vezes na vida real.
📚 O que você vai aprender neste post:
- As duas políticas que compõem uma role (trust e permission);
- Um exemplo prático completo de Lambda gravando no DynamoDB;
- O que é um instance profile na EC2;
- Como as credenciais chegam ao serviço automaticamente;
- Erros comuns a evitar.
As duas políticas de uma role
Toda role combina duas peças que trabalham juntas — e confundir os papéis delas é fonte de muita dor de cabeça:
- Trust policy (política de confiança) — define quem pode assumir a role (o principal). Sem ela correta, ninguém consegue usar a role.
- Permission policy (política de permissão) — define o que a role pode fazer depois de assumida.
Uma boa analogia: a trust policy é a lista de convidados na porta (quem entra); a permission policy é o que o convidado pode fazer depois de dentro.
🛠️ Mão na massa: uma Lambda que grava no DynamoDB
Vamos montar, do zero, a role de uma função Lambda que insere pedidos em uma tabela DynamoDB chamada Pedidos. Passo a passo:
- Criar a role escolhendo Lambda como serviço confiável — isso gera a trust policy abaixo.
- Anexar a permission policy com a única ação necessária.
- Associar a role à função Lambda (campo “Execution role”).
- No código, usar o SDK normalmente — sem configurar credenciais.
A trust policy autoriza o serviço Lambda a assumir a role:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
A permission policy concede apenas a ação necessária, num recurso específico (menor privilégio em ação):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "dynamodb:PutItem", "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Pedidos" } ] }
Pronto: a Lambda grava na tabela Pedidos usando credenciais temporárias, sem nenhuma chave armazenada no código. Se amanhã ela também precisar ler a tabela, você adiciona dynamodb:GetItem — e só isso.
E na EC2? O instance profile
Com a EC2 há um detalhe a mais: a role é entregue à instância por meio de um instance profile — um “contêiner” que embrulha a role e é anexado à máquina. Ao criar a associação pelo console, esse instance profile é gerado automaticamente, então na prática você raramente pensa nele. Mas, ao usar Terraform, CloudFormation ou a CLI, é preciso criá-lo explicitamente — e essa é uma pegadinha frequente.
Como as credenciais chegam ao serviço
Você não gerencia nada disso manualmente. A AWS injeta as credenciais temporárias no ambiente de execução (via STS nos bastidores), e o SDK as descobre e utiliza automaticamente, seguindo a “cadeia padrão de provedores de credenciais”. Para a EC2, elas ficam disponíveis através do IMDS (o serviço de metadados da instância); para a Lambda, via variáveis de ambiente gerenciadas pela própria plataforma.
⚠️ Erros comuns a evitar
- Permissões amplas demais — evite
dynamodb:*ouResource: "*"quando você sabe exatamente a tabela e a ação. - Reutilizar uma role “faz-tudo” entre serviços diferentes — crie roles específicas por função.
- Esquecer a trust policy — sem o principal correto, o serviço não consegue assumir a role.
- Esquecer o instance profile na EC2 ao usar IaC — a role existe, mas não chega à instância.
💡 Fechamento do Nível Intermediário
Você agora entende a anatomia das policies, os tipos de política e como usar roles para dar acesso seguro a serviços — a trust policy diz quem assume, a permission policy diz o que pode fazer. Esses são os pilares operacionais do IAM no dia a dia.
Cadeia de provedores de credenciais
Vale entender como o SDK “acha” as credenciais da role automaticamente. Ele segue uma cadeia de provedores, verificando fontes em ordem: variáveis de ambiente, arquivos de configuração, credenciais de contêiner (ECS) e, por fim, o serviço de metadados da instância (EC2). Ao rodar dentro da AWS com uma role anexada, as últimas etapas da cadeia entregam as credenciais temporárias sem que você escreva uma linha de configuração.
Esse comportamento tem uma consequência prática importante: se alguém definir chaves de acesso em variáveis de ambiente na mesma máquina, elas têm precedência sobre a role — e podem mascarar problemas ou introduzir credenciais permanentes indesejadas. Em ambientes com roles, mantenha a máquina “limpa” de chaves para que a role seja de fato usada.
Protegendo serviços contra o “confused deputy”
Quando um serviço da AWS assume uma role em seu nome (por exemplo, o SNS invocando uma função, ou o CloudWatch executando uma ação), é boa prática restringir a confiança com as condições aws:SourceArn e aws:SourceAccount na trust policy. Elas garantem que apenas o recurso específico (e a sua conta) possa acionar aquela role, evitando que outro recurso — potencialmente de terceiros — se aproveite da relação de confiança.
Esse é o mesmo princípio do “confused deputy” que veremos no acesso cross-account, aplicado a serviços. Adotá-lo desde cedo evita uma classe inteira de configurações perigosas que passam despercebidas.
No próximo post
Entramos no Nível Avançado, começando por permission boundaries — como limitar o teto de privilégio de identidades com segurança. 🟠
Informações sobre o autor
Dennis Silva atua com Segurança da Informação e Cibersegurança há +18 anos e iniciou sua carreira em uma das Big Four em auditoria de sistemas.
Atualmente, atua como Consultor de Cibersegurança no time de Professional Services da AWS na América Latina (Brasil), função que exerce há mais de 4 anos, com foco no atendimento a instituições financeiras.
Trabalhou como Coordenador de Segurança da Informação na maior empresa de desenvolvimento de software na América Latina. Anteriormente, atuou como consultor de Segurança da Informação, com foco em identificar e avaliar os riscos inerentes ao negócio e validar os controles existentes por meio de testes de invasão em infraestrutura interna/externa, aplicações Web e ERPs como SAP e TOTVS.
Foi responsável pela implementação da certificação ISO/IEC 27001:2013 na maior empresa de desenvolvimento de software da América Latina, potencializando a principal oferta de comercialização de software como serviço (SaaS) em datacenter próprio.