CloudTrail mostra qual identidade AWS agiu, mas não quem estava por trás dela

CloudTrail mostra qual identidade AWS agiu, mas não quem estava por trás dela

Um caso real de uso da conta root expôs um limite conhecido do CloudTrail: o serviço registra a credencial, não o humano. Entender onde esse rastro se perde (e como fechá-lo) é trabalho de quem desenha IAM.

Um caso real de uso da conta root expôs um limite conhecido do CloudTrail: o serviço registra a credencial, não o humano. Entender onde esse rastro se perde (e como fechá-lo) é trabalho de quem desenha IAM.

Nota da redação: este artigo descreve comportamentos técnicos específicos de produtos da AWS (como o campo userIdentity do CloudTrail se comporta para eventos de root, usuário IAM, role assumida e federados; a ausência de userName associado à conta root; a mecânica de propagação de sts:SourceIdentity através de múltiplos saltos de role; e o comportamento do sessionContext no IAM Identity Center) que não puderam ser confirmados contra documentação oficial da AWS nem constam no post-fonte usado nesta reportagem. Trate essas descrições como explicação de contexto, não como referência técnica definitiva, e confira a documentação oficial da AWS antes de tomar decisões de arquitetura com base nelas.

O evento que não fechava a conta

Ofir Be, que está construindo uma ferramenta de investigação de segurança chamada Kultarr, publicou no DEV Community um relato direto sobre um evento real de CloudTrail: a conta root de um ambiente AWS foi usada para chamar a API ListAccessKeys. O log tinha tudo que o CloudTrail promete entregar: o principal, o IP de origem, o timestamp, os detalhes da requisição.

Só faltava uma coisa: quem apertou o teclado.

We know the request was made using the root identity. Do we actually know who was sitting behind the keyboard? Not necessarily.

We know the request was made using the root identity. Do we actually know who was sitting behind the keyboard? Not necessarily.Ofir Be, criador do Kultarr

Para quem desenha estratégia de IAM e multi-conta, essa constatação não é novidade teórica. É o tipo de lacuna que vira dor de cabeça real no meio de uma resposta a incidente, quando alguém pergunta "quem fez isso" e a resposta honesta é "a conta root, mas não sabemos quem a operava naquele minuto".

O que o campo userIdentity realmente grava

Todo evento do CloudTrail carrega um bloco userIdentity que descreve a credencial usada, não a pessoa. Pela experiência de quem trabalha com investigação nesse tipo de log, o tipo desse bloco muda o que dá para inferir depois: eventos de root tendem a não trazer nome de usuário nenhum, apenas a conta; eventos de usuário IAM trazem a identidade daquela credencial específica, mas não distinguem quem a usou se ela for compartilhada; eventos de role assumida trazem a identidade da role, não necessariamente de quem a disparou; e eventos federados dependem do que o provedor de identidade decide enviar na sessão.

Na prática, quanto mais a arquitetura depende de roles assumidas em cadeia (CI/CD, troca entre contas de Organizations, automações), mais o que sobra no log é a identidade da role, não de quem a disparou.

Root é o pior caso possível

A conta root nunca tem userName associado: ela é a conta, não uma pessoa. Reduzir esse risco passa por práticas de segurança já conhecidas, como MFA de hardware e eliminação de credenciais de longa duração, mas isso resolve autenticação, não atribuição: mesmo com MFA, o log continua dizendo apenas "root", nunca "fulano de tal".

A prática recomendada de arquitetura segue sendo a mesma há anos: remover qualquer access key de longa duração do root, exigir MFA de hardware, e tratar o uso do root como procedimento de break-glass documentado, com aprovação e revisão posterior. Se o root aparece num CloudTrail fora desse processo, isso já é sinal de alerta por si só, antes mesmo de saber quem estava logado.

sts:SourceIdentity fecha metade do buraco

Nota da redação: os trechos técnicos desta seção (mecânica detalhada do recurso e exemplo de política) não foram confirmados contra documentação oficial da AWS nem testados em ambiente real. Valide antes de usar em produção.

Para os casos de AssumedRole, a AWS oferece um recurso chamado sts:SourceIdentity, voltado a ajudar a preservar a identidade de quem iniciou uma cadeia de assume-role. A ideia geral, que vale confirmar na documentação oficial antes de implementar, é condicionar a trust policy da role a exigir esse parâmetro:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringLike": { "sts:SourceIdentity": "*" }
  }
}

Quando configurado dessa forma, a proposta é que cada evento subsequente carregue userIdentity.sessionContext.sourceIdentity, preservando o rastro mesmo depois de múltiplos saltos de role. O trade-off prático é disciplina: um assume-role feito sem passar o parâmetro de identidade de origem interrompe esse rastro, e vale checar na documentação da AWS até que ponto esse comportamento é retroativo ou não.

IAM Identity Center é onde a pessoa vira sessão

Em ambientes com AWS Organizations e múltiplas contas, o ponto mais confiável de atribuição humana não é o CloudTrail isolado: é o IAM Identity Center (antigo AWS SSO). O login federado via Okta, Entra ID ou outro IdP gera, por trás, um assume-role, e, dependendo da configuração da federação, o sessionContext pode carregar informações do usuário que originou a sessão.

Numa estratégia de multi-conta com Control Tower, isso pode reduzir a necessidade de correlacionar logs do IdP com logs do CloudTrail manualmente para cada investigação, quando a federação estiver bem configurada. Quem desenha a camada de IAM deveria tratar migrar o acesso humano para Identity Center como prioridade maior do que ajustar política IAM granular: sem federação centralizada, toda investigação de atividade de console vira trabalho de detetive.

O que monitorar hoje, sem esperar ferramenta nova

Parte do trabalho de fechar esse gap não depende de nenhum produto novo chegando ao mercado. Dá pra agir agora:

• Remover access keys do root em todas as contas, inclusive na management account da organização
• Habilitar uma trilha organizacional de CloudTrail centralizada numa conta de log dedicada
• Migrar acesso humano para IAM Identity Center federado, desligando IAM users individuais sempre que possível
• Exigir sts:SourceIdentity em toda trust policy de role assumida, tanto por pessoas quanto por pipelines de automação (conferindo a documentação oficial da AWS sobre o recurso)
• Monitorar os findings do GuardDuty relacionados a uso de credenciais root e alertar em tempo real, não em revisão semanal
• Explorar as capacidades de consulta do CloudTrail Lake como possível apoio em investigações que precisem reconstruir uma cadeia de assume-role, conferindo na documentação da AWS o que exatamente é suportado

Nenhum desses itens substitui os outros: eles se somam. Um ambiente que só tem GuardDuty ligado mas ainda usa IAM users compartilhados continua com o mesmo buraco de atribuição que o post de Ofir Be descreve.

Severidade não é risco contextual, e isso também é problema de arquitetura

O post da Kultarr levanta outro ponto que vale notar: nas capturas de tela da ferramenta, o mesmo evento aparece com rótulo de severidade "Critical" ao lado de uma pontuação de risco contextual de 9 em 100, vinda de um modelo de scoring anterior. São duas métricas diferentes medindo coisas diferentes, e o autor reconhece que, sem essa distinção explicada na interface, o resultado confunde quem investiga.

Isso serve de lembrete para quem avalia qualquer ferramenta de SIEM ou SOAR, própria ou de terceiro: severidade de evento e risco contextual raramente são a mesma coisa, e um painel que mistura as duas sem dizer isso faz o analista perder tempo discutindo o número errado.

O limite que nenhuma ferramenta resolve sozinha

Mesmo com sourceIdentity, Identity Center e GuardDuty configurados, sobra um conjunto de casos onde a atribuição humana continua incerta: contas legadas com IAM users compartilhados entre squads há anos, chaves de acesso de longa duração nunca rotacionadas, pipelines que assumem role sem propagar identidade de origem, ou um IdP cujo log de autenticação não fica retido pelo mesmo prazo do trail.

É exatamente esse gap que ferramentas de investigação como a Kultarr tentam preencher, correlacionando evidências disponíveis em vez de só exibir o evento bruto. Mas o próprio autor é claro sobre o limite: no caso que ele descreve, "o principal AWS é conhecido, mas o humano por trás da atividade não foi identificado de forma independente", e a plataforma ainda não tinha sido lançada até a publicação do post, continuando em fase final antes do lançamento.

Para quem desenha IAM e multi-conta, o recado prático é o mesmo independente de qual ferramenta de investigação acabar entrando no ambiente: nenhuma correlação automática substitui a decisão arquitetural de nunca deixar uma credencial sem dono rastreável circulando em produção.

Fonte: Ofir Be, "CloudTrail Told Me Which AWS Identity Was Used. But Not Who Was Behind It.", DEV Community (https://dev.to/ofirbe/cloudtrail-told-me-which-aws-identity-was-used-but-not-who-was-behind-it-2j5k).

Fonte: DEV Community — #aws