Gestão centralizada do acesso root

Na lição 8 você protegeu o usuário root de uma conta: MFA, sem chaves de acesso, contatos alternativos, uso raro. Agora multiplique por 200 contas-membro. São 200 senhas, 200 dispositivos MFA e 200 caixas de e-mail capazes de recuperar a senha — cada uma é um caminho de ataque.

Em novembro de 2024 o IAM lançou o gerenciamento centralizado do acesso root para contas-membro do AWS Organizations. A ideia: em vez de proteger 200 credenciais root, você remove essas credenciais e executa as poucas tarefas que exigem root a partir de uma conta central, com sessões curtas e escopo limitado.

No console do IAM, em Root access management, há duas capacidades:

• Root credentials management: permite à conta de gerenciamento e ao administrador delegado do IAM apagar credenciais root das contas-membro.
• Privileged root actions in member accounts: permite a essas mesmas contas executar certas tarefas que exigem root. É necessária também para permitir que uma conta recupere a credencial root depois de apagada.

Pré-requisitos: contas gerenciadas pelo Organizations e trusted access do IAM habilitado na organização. Opcionalmente, registre um administrador delegado — a documentação recomenda uma conta voltada a segurança ou gestão, e a SRA usa a Security Tooling (lição 17).

1
2
3
4
5
6
7
8
9
10

aws organizations enable-aws-service-access \
  --service-principal iam.amazonaws.com
 
aws iam enable-organizations-root-credentials-management
aws iam enable-organizations-root-sessions
 
# Opcional: delegar à conta de Security Tooling
aws organizations register-delegated-administrator \
  --service-principal iam.amazonaws.com \
  --account-id 111111111111

Depois de habilitado, você pode remover de cada conta-membro a senha root, as chaves de acesso, os certificados de assinatura e desativar o MFA. E contas novas criadas pelo Organizations já nascem sem credenciais root.

Uma tarefa privilegiada começa com sts:AssumeRoot, chamado por um usuário ou papel IAM da conta de gerenciamento ou do administrador delegado (nunca com credencial root). A sessão:

• dura no máximo 900 segundos (15 minutos);
• exige uma task policy gerenciada pela AWS que limita o que pode ser feito;
• precisa ir para um endpoint regional do STS — o endpoint global não é suportado.

1
2
3
4
5
6
7
8

aws sts assume-root \
  --region us-east-1 \
  --target-principal 222222222222 \
  --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy \
  --duration-seconds 900
 
# Com as credenciais retornadas (AccessKeyId, SecretAccessKey, SessionToken):
aws s3api delete-bucket-policy --bucket bucket-travado-exemplo

Para limitar quais tarefas cada papel pode iniciar, use a chave de condição sts:TaskPolicyArn na política que concede sts:AssumeRoot.

• SCPs restringem o root das contas-membro. Muitas organizações já têm SCPs que negam ações ao root; elas continuam úteis como camada extra.
• No CloudTrail da conta-membro, as ações da sessão aparecem com identidade do tipo Root. Uma SCP que nega tudo para arn:aws:iam::*:root também bloqueia as sessões de AssumeRoot. Por isso o controle AWS-GR_RESTRICT_ROOT_USER do Control Tower tem o parâmetro ExemptAssumeRoot, que acrescenta a condição "Null": "aws:AssumedRoot": "true": o deny passa a valer só quando a chave aws:AssumedRoot está ausente, ou seja, para o root "de verdade". Nas suas SCPs próprias, use a mesma condição e teste numa conta isolada antes.
• Para rastrear: localize o evento AssumeRoot na conta que iniciou a sessão (ele traz targetPrincipal e a task policy) e procure o accessKeyId da sessão no CloudTrail da conta-alvo.
• Crie alertas para qualquer AssumeRoot: deve ser raro, e cada ocorrência precisa de um motivo registrado.

• Nem toda tarefa de root está coberta. Algumas ainda exigem entrar como root. Nesse caso, use "Allow password recovery", faça a tarefa e apague as credenciais de novo.
• A conta que faz AssumeRoot vira crítica. Poucos papéis com sts:AssumeRoot, MFA na federação, escopo por sts:TaskPolicyArn e monitoramento.
• O e-mail root continua importante. A recuperação habilitada é feita por quem tem acesso à caixa de e-mail do root da conta-membro.

Com o acesso root centralizado, contas-membro deixam de ter credenciais root de longo prazo, e as tarefas raras que exigem root viram sessões de até 15 minutos, com escopo por task policy e rastro no CloudTrail. O root da conta de gerenciamento continua sob sua guarda.

Esta é a última lição do Foundations do Zero. Você passou pelas oito boas práticas do SEC01: contas como fronteira, root, objetivos de controle, ameaças, escopo, automação, modelagem de ameaças e evolução contínua — até a arquitetura de referência e a operação em escala. O próximo passo é aplicar essa base nas outras áreas do pilar: veja o mapa em epics.dennisasilva.com.

Esta lição estende a SEC01-BP02 Secure account root user and properties, que pede limitar o uso do root às tarefas que realmente o exigem, usar MFA e ter controles detectivos que alertem quando o root é usado. Para MFA em profundidade, veja MFA no IAM do Zero.

• Centralize root access for member accounts
• Perform a privileged task on an AWS Organizations member account
• AssumeRoot — AWS STS API Reference
• Track privileged tasks in AWS CloudTrail
• What's New — Centrally manage root access in IAM (nov/2024)