Terceiro e último post do Nível Básico da série AWS IAM. Vamos falar do que protege — ou compromete — toda a sua conta: as credenciais. É aqui que moram os erros mais comuns e também as defesas mais eficazes. Um deslize com credenciais pode abrir sua conta inteira; uma boa higiene, por outro lado, elimina a maioria dos riscos.
📚 O que você vai aprender neste post:
- Os tipos de credenciais na AWS e quando cada um aparece;
- Por que o MFA é sua defesa mais barata e eficaz;
- Como tratar a conta root com segurança;
- Um roteiro prático para blindar uma conta nova;
- Boas práticas de higiene de credenciais e ferramentas de auditoria.
Tipos de credenciais na AWS
Antes de proteger, é preciso conhecer o que se está protegendo. Na AWS, você lida com três grandes tipos de credenciais:
🔑 Senha de console
Usada por pessoas para acessar a interface web da AWS. Deve vir sempre acompanhada de MFA.
🗝️ Chaves de acesso
Par usado por CLI/SDKs. Longo prazo — exigem cuidado redobrado e rotação.
⏱️ Temporárias
Emitidas pelo STS ao assumir uma role. Expiram sozinhas — opção preferencial.
A regra de ouro que atravessa toda a AWS: sempre que possível, prefira as credenciais temporárias. As chaves de acesso de longo prazo devem existir apenas quando não há alternativa viável.
🔐 MFA: sua defesa mais barata e eficaz
A autenticação multifator (MFA) exige, além da senha, um segundo fator — normalmente um código gerado por um aplicativo autenticador (TOTP), uma chave de segurança física (FIDO2/WebAuthn) ou um dispositivo de hardware. A lógica é simples e poderosa: mesmo que sua senha vaze, o atacante não entra sem o segundo fator, que está fisicamente com você.
Entre as opções, as chaves de segurança físicas (como YubiKey) oferecem a proteção mais forte, pois são resistentes a phishing — diferentemente de um código TOTP, que um site falso poderia capturar. Para a maioria dos casos, porém, um aplicativo autenticador já eleva enormemente o nível de segurança.
Ative MFA para todos os acessos humanos, sem exceção. É uma das medidas de maior impacto e menor custo em segurança na nuvem.
A conta root: use quase nunca
Ao criar uma conta AWS, o e-mail de cadastro vira o usuário root — que tem poder absoluto e irrestrito, incluindo ações que nenhuma outra identidade pode fazer (como fechar a conta ou alterar o plano de suporte). Justamente por isso, ele deve ser tratado como o cofre-mestre: usado apenas nas raras tarefas que exigem root, e nunca no dia a dia.
- Ative MFA na conta root imediatamente.
- Não crie chaves de acesso para o root. Se já existirem, remova.
- Crie usuários/roles administrativos individuais para o trabalho cotidiano.
- Guarde as credenciais do root em local seguro e restrito (idealmente um cofre de senhas corporativo).
🛠️ Mão na massa: blindando uma conta nova
Acabou de criar uma conta AWS? Faça este roteiro nos primeiros minutos, antes de qualquer outra coisa:
- Ative MFA na conta root (Segurança → Credenciais de segurança).
- Não gere chaves de acesso para o root; se houver alguma, apague.
- Crie um usuário/role administrativo individual (ou ative o IAM Identity Center) para o seu uso diário.
- Habilite o CloudTrail para registrar todas as ações na conta.
- Gere o IAM Credential Report e revise o que existe.
- Guarde as credenciais do root em um cofre seguro e só volte a elas quando estritamente necessário.
Esse roteiro de poucos minutos elimina a maior parte dos riscos de “conta recém-criada e esquecida” que aparecem em relatórios de incidentes.
✅ Higiene de credenciais: boas práticas
- Nunca coloque chaves em código-fonte, repositórios Git ou imagens de contêiner.
- Prefira roles a chaves permanentes sempre que possível.
- Rotacione e remova chaves antigas ou não utilizadas.
- Use o IAM Credential Report para auditar quais credenciais existem e quando foram usadas pela última vez.
- Monitore atividades com CloudTrail e considere o Access Analyzer para detectar exposições.
💡 Fechamento do Nível Básico
Com estes três posts você já domina os fundamentos: o que é IAM, usuários, grupos, roles, policies, o princípio do menor privilégio e a proteção das credenciais. Essa base é o que sustenta tudo o que vem a seguir.
Por que a conta root é tão sensível
Vale entender por que a AWS trata o root de forma especial. Algumas ações só podem ser executadas por ele: alterar o e-mail ou o nome da conta, mudar o plano de suporte, restaurar permissões de um bucket S3 bloqueado por engano, fechar a conta e configurar certas preferências de faturamento. Como esse poder é irrevogável e não pode ser delegado por completo, um comprometimento do root é praticamente equivalente a perder a conta inteira.
Por isso, além de MFA e da ausência de chaves de acesso, muitas organizações adotam controles extra: alertas no CloudTrail para qualquer login do root, aprovação de duas pessoas para acessá-lo (o cofre com a senha e o dispositivo de MFA guardados separadamente) e revisões periódicas. Tratar o root como um “quebrar o vidro em caso de emergência” é a postura madura.
No próximo post
Entramos no Nível Intermediário, dissecando a anatomia de uma policy JSON: Effect, Action, Resource e Condition. É onde você começa a escrever permissões com precisão. Até lá! 🟡
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.