Referência

Checklist do root e da conta

Tudo o que conferir em cada conta nova, em uma lista.

Material complementar · Módulo 2 — Contas como fronteira

Como usar este checklist

Use em toda conta nova e nas revisões periódicas. Os itens vêm da boa prática SEC01-BP02 e da documentação do IAM e do AWS Organizations. Para a conta de gerenciamento e para contas standalone, todos os itens valem. Para contas-membro, alguns são substituídos por controles centrais, como indicado.

No dia da criação

  • ☐ E-mail do root é uma lista de distribuição do domínio corporativo, não uma caixa pessoal.
  • ☐ O domínio e o servidor desse e-mail não dependem da própria conta (sem dependência circular).
  • ☐ Telefone da conta é dedicado, controlado pela organização e não divulgado.
  • ☐ Senha do root forte e guardada fora da conta (contas standalone e de gerenciamento).
  • ☐ MFA no root registrado, de preferência passkey ou security key FIDO.
  • ☐ Um segundo dispositivo MFA de reserva registrado (até 8 por root) e guardado em local separado.
  • ☐ Nenhuma access key criada para o root.
  • ☐ Contas-membro criadas pelo Organizations: decidir entre não guardar credenciais root (usar recuperação a partir da conta de gerenciamento) ou gestão centralizada do root.

Configuração da conta

  • ☐ Contatos alternativos de billing, operations e security preenchidos, com listas de distribuição.
  • ☐ Em organizações, contatos atualizados de forma central (exige trusted access para AWS Account Management).
  • ☐ Acesso do dia a dia pelo IAM Identity Center ou por roles, nunca pelo root.
  • ☐ Contas-membro com SCP ou controle do Control Tower que nega ações como root e nega criação de access keys do root, testados antes na OU Policy Staging.
  • ☐ SCP no root da organização negando organizations:LeaveOrganization e account:CloseAccount sem aprovação central.
  • ☐ Conta de gerenciamento sem workloads, com acesso limitado a quem administra a organização.

Monitoramento

  • ☐ Alerta para todo login ou uso do root (regra do EventBridge sobre eventos do CloudTrail).
  • ☐ Amazon GuardDuty habilitado, com atenção ao achado RootCredentialUsage.
  • ☐ Controles detectivos ligados ao root avaliados: os fortemente recomendados do Control Tower ou o conformance pack do pilar de Segurança no AWS Config.
  • ☐ Caixas de e-mail do root e dos contatos alternativos monitoradas (avisos de segurança e de abuso da AWS).
  • ☐ Procedimento de resposta a incidente para uso indevido do root documentado.

Revisão periódica

  • ☐ Revisar quem tem acesso a e-mail, senha, MFA e telefone do root (mensal ou trimestral para a conta de gerenciamento).
  • ☐ Regra de duas pessoas: ninguém tem sozinho todos os fatores do root.
  • ☐ Recuperação de acesso não depende de uma pessoa específica.
  • ☐ Testar o login do root e o procedimento de emergência antes de precisar dele.
  • ☐ Conferir que e-mails e telefones da conta e dos contatos alternativos funcionam.
  • ☐ Trocar baterias ou substituir dispositivos MFA de hardware quando necessário.
  • ☐ Confirmar que nenhuma access key do root foi criada desde a última revisão.

Onde aprofundar

Voltar para a trilha