Segundo post do Nível Básico da série AWS IAM. No post anterior conhecemos os blocos fundamentais. Agora vamos resolver uma das dúvidas mais comuns de quem começa: quando usar um usuário e quando usar uma role? Essa decisão, aparentemente simples, é uma das que mais impactam a segurança da sua conta.
📚 O que você vai aprender neste post:
- A diferença entre credenciais permanentes e temporárias;
- O que é o AWS STS e como ele emite credenciais;
- Por que roles são consideradas mais seguras;
- Um exemplo prático passo a passo (EC2 lendo o S3);
- Uma regra clara para decidir entre usuário e role;
- Erros comuns e um resumo dos pontos-chave.
A diferença essencial: credenciais permanentes x temporárias
Um usuário IAM possui credenciais de longo prazo: uma senha para o console e/ou um par de chaves de acesso (Access Key ID + Secret Access Key) que não expiram até que você as remova manualmente. Elas ficam “vivas” indefinidamente — o que é conveniente, mas perigoso: se vazarem e você não perceber, o acesso indevido pode durar meses.
Uma role IAM, por outro lado, não tem credenciais fixas. Quando alguém (uma pessoa, um serviço ou outra conta) a “assume”, a AWS emite credenciais temporárias que expiram automaticamente — normalmente em algo entre 15 minutos e algumas horas. Menos tempo de vida significa uma janela de risco muito menor caso algo vaze.
Essas credenciais temporárias são compostas por três elementos: um Access Key ID, um Secret Access Key e um Session Token. É esse token de sessão, com validade curta, que diferencia uma credencial temporária de uma permanente.
Quem emite as credenciais: o AWS STS
Por trás de toda role está o AWS Security Token Service (STS). É ele quem, ao receber uma chamada de AssumeRole, valida se o solicitante tem permissão e então gera as credenciais temporárias. Você raramente chama o STS manualmente — os SDKs, a CLI e os próprios serviços da AWS fazem isso automaticamente nos bastidores. Mas entender que o STS é a “fábrica de credenciais temporárias” ajuda a visualizar por que roles são tão centrais no IAM moderno.
Por que roles são mais seguras
- Sem segredos armazenados — não há chaves em arquivos de configuração, variáveis de ambiente ou código-fonte, uma das principais causas de incidentes na nuvem.
- Rotação automática — as credenciais temporárias são renovadas sozinhas pela AWS, sem intervenção humana.
- Expiração natural — mesmo que vazem, deixam de funcionar em pouco tempo.
- Rastreabilidade — o CloudTrail registra quem assumiu qual role e quando, facilitando auditorias.
🛠️ Mão na massa: EC2 lendo o S3 sem chaves
Vamos ao cenário mais clássico. Uma aplicação roda em uma instância EC2 e precisa ler arquivos de um bucket S3. Veja o passo a passo da forma correta:
- Criar uma role do tipo “serviço AWS”, escolhendo EC2 como serviço confiável.
- Anexar uma permission policy que permita apenas a leitura no bucket (
s3:GetObject). - Associar a role à instância EC2 por meio de um instance profile (o console faz isso automaticamente).
- Na aplicação, não configurar chave nenhuma — o SDK detecta as credenciais temporárias fornecidas pela instância e as usa sozinho.
A trust policy que autoriza a EC2 a assumir essa role é esta:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
Compare com a forma errada: criar um usuário IAM, gerar chaves de acesso e colá-las em um arquivo .env dentro da instância. Se essa instância for comprometida — ou se a imagem/AMI for compartilhada por engano — essas chaves permanentes vazam e continuam válidas até alguém percebê-las e revogá-las. Com a role, não há chave para vazar.
Regra prática para decidir
- É um serviço ou aplicação da AWS (EC2, Lambda, ECS…) precisando de acesso? Use uma role.
- É outra conta AWS que precisa acessar recursos seus? Use uma role (acesso cross-account, tema do nível avançado).
- É uma aplicação fora da AWS (on-premises ou outra nuvem)? Considere federação ou o IAM Roles Anywhere, evitando chaves fixas.
- São pessoas fazendo login? O ideal moderno é o IAM Identity Center (federação), que também entrega credenciais temporárias. Usuários IAM tradicionais ficam para casos específicos e legados.
Perceba o padrão: em praticamente todos os cenários, a resposta recomendada envolve credenciais temporárias. As chaves permanentes de usuário são a exceção, não a regra.
⚠️ Erros comuns
- Gerar chaves de acesso para um serviço quando uma role resolveria — cria segredos permanentes desnecessários.
- Deixar chaves antigas ativas “por via das dúvidas” — cada chave viva é um risco.
- Reutilizar as mesmas chaves em vários lugares — dificulta rotação e rastreabilidade.
- Embutir chaves em imagens de contêiner ou AMIs — elas viajam para todo lugar onde a imagem for parar.
💡 Resumo dos pontos-chave
Usuários usam credenciais permanentes; roles usam credenciais temporárias emitidas pelo STS, que expiram sozinhas. Para serviços, cross-account e pessoas, prefira roles/federação. A tendência da AWS é clara: menos chaves permanentes, menor superfície de ataque.
No próximo post
Vamos fechar o Nível Básico falando de credenciais: chaves de acesso, senhas, a importância do MFA e os cuidados essenciais com a conta root. 🔐
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.