Protegendo o usuário root

Quando uma conta AWS é criada, ela começa com uma única identidade: o usuário root, que entra com o e-mail e a senha usados no cadastro. Ele tem acesso completo a todos os serviços e recursos da conta e, em alguns casos, não pode ser limitado por políticas. Por isso a regra é: proteger muito bem e usar só para o que exige root. O dia a dia (inclusive tarefas administrativas) é feito com identidades do IAM Identity Center ou roles.

Há outra porta além da senha: os fluxos de recuperação de conta usam o e-mail e o telefone cadastrados. Quem controla essa caixa de e-mail e esse telefone pode, na prática, chegar ao root. E-mail, DNS e telefonia fazem parte do perímetro crítico.

A lista oficial é curta. Alguns exemplos:

• Em contas standalone: alterar o e-mail da conta, a senha do root e as access keys do root, e fechar a conta. Em contas de uma organização, várias dessas tarefas podem ser feitas de forma central pela conta de gerenciamento ou por um administrador delegado.
• Reabrir uma conta standalone fechada, dentro do período pós-fechamento.
• Restaurar permissões quando o único administrador IAM removeu as próprias permissões.
• Ativar o acesso IAM ao console de Billing and Cost Management e algumas outras tarefas de cobrança.
• Remover uma bucket policy do S3 ou uma policy de fila do SQS que nega acesso a todos os principais.

Mudar nome da conta, contatos, contatos alternativos ou regiões não exige root. Confira sempre a lista completa em Tasks that require root user credentials.

Contas criadas pelo AWS Organizations nascem com senha do root aleatória e não exposta. Em vez de guardar credenciais de cada uma, você pode restringir o root das contas-membro com uma SCP. O Control Tower oferece isso como controles fortemente recomendados (impedir ações como root e impedir a criação de access keys do root). Um exemplo simplificado, para adaptar e testar antes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NegarAcoesComoRoot",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

SCPs não afetam a conta de gerenciamento, então o root dela precisa dos controles da seção anterior. Hoje também é possível gerenciar o acesso root de forma centralizada: remover as credenciais root das contas-membro e executar as tarefas privilegiadas a partir da conta de gerenciamento. Esse é o tema da lição 20. Se adotar esse recurso, lembre que uma SCP como a acima também bloqueia essas sessões privilegiadas; o controle equivalente do Control Tower tem um parâmetro para isentá-las.

• Alerte em todo uso do root: uma regra do Amazon EventBridge sobre eventos do CloudTrail, e o achado RootCredentialUsage do Amazon GuardDuty para uso de credenciais root em chamadas de API.
• Teste o acesso periodicamente, para descobrir problemas antes de uma emergência.
• Confira e-mails e telefones da conta e dos contatos alternativos, e monitore essas caixas.
• Tenha um procedimento de resposta para uso indevido do root.

O root tem acesso total e pouca coisa exige usá-lo. Proteja com MFA forte (de preferência passkey ou security key, com dispositivo de reserva), sem access keys, com e-mail de lista e telefone controlados pela empresa e contatos alternativos cadastrados. Restrinja o root das contas-membro, alerte em todo uso e teste o acesso antes de precisar dele.

SEC01-BP02 Secure account root user and properties — nível de risco se não for adotada: alto. Para MFA em geral, veja MFA na trilha de IAM.

• AWS account root user e tarefas que exigem root
• Multi-factor authentication for AWS account root user
• Update the alternate contacts for your AWS account
• Control Tower — controles preventivos fortemente recomendados