Remediation plans no Security Hub: remediação por causa raiz, dissecada

Durante anos o modelo operacional de segurança na AWS foi o finding individual: cada controle do CSPM, cada CVE do Inspector, cada detecção do GuardDuty vira um item na fila, e o time mede o que a fila deixa medir, findings fechados por semana. O padrão que a AWS publicou em janeiro de 2020, resposta automatizada via custom actions, EventBridge e Lambda, automatizou exatamente isso: uma função por tipo de finding, mais de 20 remediações do CIS Benchmark, cada uma tratando um sintoma. Funciona, e a fila volta a crescer na segunda seguinte, porque a causa continua lá.

A matemática joga contra o modelo por sintoma. Uma policy IAM que permite kms:Decrypt com Resource: "*" não é um problema: é um trait que aparece em cada exposure finding de cada principal que a carrega. Trocar a policy é uma mudança; fechar os findings um a um são dezenas de tickets que descrevem a mesma mudança com palavras diferentes.

Os exposure findings, que o Security Hub já gerava antes deste anúncio, faziam metade do caminho: correlacionam sinais de GuardDuty, Inspector, Security Hub CSPM e Macie num finding por recurso, um recurso é primário em no máximo um exposure finding, com attack path e blast radius visualizados. Os remediation plans fecham a outra metade: invertem o índice. Em vez de indexar o trabalho pelo que foi detectado, indexam pelo que você precisa consertar. É a diferença entre uma lista de sintomas e um diagnóstico.

Cada remediation plan carrega quatro coisas: a prioridade (Critical, High, Medium ou Low), uma avaliação de impacto da mudança, o conjunto de exposições que ele resolve ou rebaixa, e instruções passo a passo em cinco formatos: AWS CLI, Terraform, CloudFormation, Python e CDK. O Security Hub ordena os planos automaticamente: o que reduz mais risco aparece primeiro. E o dado que muda o desenho de automação: agentes de IA podem consumir os planos programaticamente via API.

Por baixo, a matéria-prima são os traits dos exposure findings. Traits de misconfiguração são os conhecidos: usuário IAM sem MFA, access keys sem rotação há mais de 90 dias, kms:Decrypt irrestrito. Traits de impacto são o catálogo de caminhos de escalação que o Security Hub calcula sobre as permissões efetivas: trust policy hijack path, credential minting path, data ransomware path, disable audit trail path. Traits contextuais vêm do IAM Access Analyzer: a documentação usa o exemplo de uma instância EC2 vulnerável cuja role tem 47 permissões não usadas em 5 serviços, é o blast radius dizendo que aquele CVE vale mais do que o CVSS sugere.

Programaticamente, os recursos de um finding saem via GetFindingsV2. Custo: os planos entram sem cobrança adicional no plano Essentials, que é pay-as-you-go por unidade de recurso, uma instância EC2 vale 1 unidade, uma função Lambda 1/12, um recurso IAM 1/125, com trial de 30 dias por conta e região.

Use remediação por causa raiz quando: você opera dezenas de contas com estado gerenciado por IaC, o backlog de findings cresce mais rápido do que o time fecha, e existe processo formal de mudança: PCI-DSS, BACEN 4.893, que torna cada correção cara o bastante para valer o agrupamento. Nesse cenário o plano vira a unidade natural de trabalho: um ticket, um PR, uma janela, N exposições a menos.

A armadilha do passo a passo: o plano traz instruções de console e CLI, e é aí que mora o drift. Se o recurso é gerenciado por Terraform e alguém aplica o fix pelo console, o próximo terraform apply reverte a correção em silêncio, a exposição volta sem ninguém tocar em nada. Dos cinco formatos que o plano oferece, o único que vale para recurso gerenciado é o que entra no seu pipeline: Terraform, CloudFormation ou CDK, via PR.

Não use como substituto do padrão por finding em tudo. Correções estreitas, reversíveis e urgentes, bloquear acesso público num bucket S3, por exemplo, continuam melhores no modelo 2020: EventBridge, Lambda, segundos de latência. E se o seu acervo é pequeno, meia dúzia de contas sem IaC consistente, o custo de montar a esteira de consumo supera o ganho: nesse caso a lista priorizada do console, lida por um humano toda semana, já entrega a maior parte do valor.

O anúncio diz, de passagem, que agentes de IA podem consumir os planos via API para automatizar correções. Lido junto com o Well-Architected Agent em preview, o movimento é claro: a AWS está transformando orientação operacional em artefato legível por máquina. Para quem desenha plataformas, isso é bom, plano estruturado com impacto estimado é um contrato muito melhor para um agente do que texto de runbook.

Mas o agente que aplica remediação é, por definição, um principal privilegiado que modifica IAM, KMS e rede. O catálogo de impact traits do próprio Security Hub: credential minting path, disable audit trail path, remove restriction path, lê-se como a lista do que um agente de remediação comprometido ou apenas confuso conseguiria fazer. O custo aqui não é o de construir a automação, é o de manter, auditar e conter um principal poderoso por anos.

Minha regra para ambiente financeiro: o agente propõe, o pipeline dispõe. O agente lê o plano via API, gera o PR com o snippet Terraform e a avaliação de impacto no corpo, e para ali. A role dele leva permission boundary sem iam:* nem kms:PutKeyPolicy, e toda ação sai com rastro em CloudTrail num trilho que ele não pode desligar. Aplicação automática sem humano no circuito, só para a classe de mudança que você já aprovou por categoria, e nunca para mudança de policy IAM.