Security Hub passa a priorizar exposições pela criticidade do recurso

A AWS lançou em 14 de outubro de 2026 um recurso que muda a forma como o AWS Security Hub ordena as exposições que ele encontra: agora o serviço leva em conta o quanto o recurso afetado importa para o negócio, não só a gravidade técnica do achado. A ideia é simples de enunciar e difícil de resolver sem automação: duas exposições podem ter a mesma severidade, mas uma está num bucket S3 de teste e a outra num banco de produção que processa pagamentos.

O problema que a criticidade resolve

Exposure findings são os achados que o Security Hub gera ao priorizar exposições de recursos. Até aqui, times centrais de segurança tinham que abrir cada exposição e descobrir manualmente se o recurso por trás dela era algo descartável ou algo que, se comprometido, derrubaria um sistema crítico. Com inventários de milhares de recursos espalhados por múltiplas contas, essa etapa manual é o gargalo real da triagem, não a detecção em si.

A AWS resolve isso adicionando uma dimensão nova ao ranqueamento: a criticidade do recurso passa a ser cruzada com a exposição, e o resultado entra na priorização ao lado da severidade técnica. Na prática, uma exposição de severidade média num recurso marcado como Very High pode subir na fila à frente de uma exposição de severidade alta num recurso irrelevante.

Três formas de definir a criticidade de um recurso

O Security Hub oferece caminhos diferentes para chegar ao mesmo valor, e eles coexistem:

• Regra de automação manual: o time de segurança cria uma automation rule que marca criticidade para um conjunto de recursos, por exemplo classificando todo recurso de computação de uma conta específica como Very High. A regra vale tanto para o que já está no inventário quanto para recursos novos, assim que o Security Hub os descobre.
• Inferência automática por tag: se o recurso já carrega uma tag que indique importância (o tipo de convenção que muitos times já usam para cobrança ou ambiente), o Security Hub lê esse sinal sem nenhuma configuração prévia.
• Inferência automática por nome: na ausência de tag, o serviço também tenta inferir a criticidade pelo nome do recurso.

Em qualquer um dos três casos, o Security Hub registra qual foi a fonte que determinou o valor, isto é, se a criticidade veio de uma regra manual, de uma tag ou do nome do recurso. Isso importa porque dá rastreabilidade: quem está olhando o painel sabe se aquele Very High foi uma decisão deliberada do time ou um palpite automático que talvez precise de revisão.

Onde a criticidade aparece no console

A criticidade vira uma coluna na página Resources, o inventário de recursos do Security Hub, disponível para ordenar, filtrar e agrupar junto com os demais atributos já existentes. Isso permite, por exemplo, listar só os recursos Very High de uma conta para auditar manualmente se a classificação está correta.

No nível do achado, a criticidade entra na aba Impact assessment de uma exposure finding. É ali que o analista vê, no mesmo lugar, a gravidade técnica do problema e o quanto o recurso afetado pesa para o negócio, sem precisar abrir outra tela ou cruzar planilhas para entender a prioridade real do caso.

Custo e ativação

Em resumo: não há nada para habilitar nem pagar a mais. O recurso de criticidade está incluído no Security Hub Essentials sem custo adicional e fica sempre ativo para todos os clientes, sem exigir nenhuma configuração nova. Quem já usa o Security Hub Essentials vê a coluna de criticidade e a inferência automática funcionando a partir de agora, mesmo sem ter criado nenhuma automation rule.

Isso muda o cálculo de adoção: times que hesitariam em testar um recurso pago agora podem simplesmente abrir a página Resources e conferir o que o Security Hub já inferiu a partir das tags e nomes existentes, antes de decidir se vale a pena investir tempo em regras manuais mais precisas.

O que muda para quem opera no Brasil

Para equipes centrais de segurança que lidam com múltiplas contas e milhares de achados por semana, a criticidade do recurso é o filtro que faltava entre "tudo é urgente" e "nada é urgente". Times que já organizam contas por ambiente (produção, homologação, sandbox) ou que já taggeiam recursos por criticidade de negócio tendem a ver a inferência automática funcionar bem de imediato, já que o Security Hub lê exatamente esses padrões.

Quem ainda não tem uma convenção de tags consistente, por outro lado, vai depender mais da inferência por nome, que é menos confiável, ou vai precisar investir em automation rules para cobrir as contas e recursos que realmente importam. Vale conferir a aba Impact assessment logo nas primeiras exposições abertas depois do lançamento para entender se a fonte da criticidade (regra, tag ou nome) está batendo com a realidade do ambiente antes de confiar cegamente na nova ordenação.

A AWS não detalhou no anúncio a lista de regiões onde o recurso já está disponível além de remeter à tabela de regiões do Security Hub; quem opera a partir de São Paulo (sa-east-1) deve checar essa tabela e o AWS Security Hub User Guide antes de assumir que a funcionalidade já está ativa na região.

Fonte: AWS What's New