AWS SAA-C03/02 - IAM e Segurança2 min
IAM Users Groups e Roles
Responda com suas palavras antes de ler o resto da nota.
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off (custo, latência, operação)?
- Que sinal no enunciado aponta pra isso?
- Com o que isso é confundido na prova?
Conceito
IAM controla quem (principal) pode fazer o quê (ação) em qual recurso, sob quais condições.
| Entidade | Credencial | Vida útil | Use para |
|---|---|---|---|
| Root user | E-mail + senha | Permanente | Quase nada. Ativar MFA e guardar |
| IAM User | Senha e/ou access key | Permanente | Humano, ou sistema legado sem alternativa |
| Group | — | — | Agrupar users por função (não pode conter grupo) |
| IAM Role | Temporária via STS | Minutos a horas | EC2, Lambda, cross-account, federação |
Role é sempre a resposta preferida. Ela entrega credencial temporária rotacionada automaticamente, elimina segredo em disco e permite acesso cross-account sem compartilhar senha.
Como uma role é usada
- EC2: instance profile anexado à instância → SDK pega credencial do metadata service (use IMDSv2)
- Lambda: execution role definida na função
- Cross-account:
sts:AssumeRolecom trust policy na conta destino - Federação: usuário do AD/Okta/Google troca token por credencial AWS
O que só o root pode fazer
Fechar a conta, mudar o plano de suporte, alterar e-mail/nome da conta, restaurar permissão de política IAM excluída, habilitar MFA Delete no S3 e registrar como vendedor no Marketplace.
Trade-offs
User com access key é simples de configurar e péssimo de manter: a chave não expira, vaza em repositório, e rotacionar é manual. Role exige entender trust policy, mas resolve rotação, expiração e auditoria de uma vez.
Sinais de prova
- "Aplicação no EC2 precisa acessar o S3" → IAM Role na instância (nunca access key)
- "Conta A precisa acessar recurso da conta B" → Role com trust policy (ou resource policy)
- "Usuários do Active Directory corporativo" → federação SAML / IAM Identity Center
- "Credencial hardcoded no código" → sempre a alternativa errada
- Qualquer coisa feita com o root no dia a dia → errada
- "Aplicar a mesma permissão a 50 desenvolvedores" → Group
Habilitar MFA no root é a primeira recomendação de segurança da AWS e aparece direto em questão de "melhores práticas iniciais".
Relacionado
- IAM Policies
- Políticas de Identidade vs Recurso
- AWS Organizations e SCP
- Cognito e Federação de Identidade
Parte de 02 - MOC IAM e Segurança · Documentação AWS