Pular para o conteúdo
AWS Security9 min de leituraAtualizado em 30 de maio de 2026

GuardDuty, Security Hub e Inspector: como combinar alertas de segurança na AWS

Três serviços com papéis diferentes. Veja como integrá-los, priorizar findings e evitar a fadiga de alertas.

A AWS oferece serviços nativos de segurança que se complementam, mas que muita gente confunde ou ativa sem rotina de tratamento. GuardDuty detecta ameaças e comportamento suspeito, Inspector encontra vulnerabilidades em cargas de trabalho e Security Hub agrega tudo e mede a postura contra padrões reconhecidos. Ativar os três sem um processo de priorização gera o pior dos mundos: muitos alertas e nenhuma ação.

Este guia explica o papel de cada serviço, como integrá-los e, principalmente, como transformar findings em decisões. O objetivo é detectar o que importa e responder rápido, sem afogar a equipe em ruído.

O papel de cada serviço

GuardDuty analisa fontes como CloudTrail, logs de DNS e VPC Flow Logs para detectar comportamento anômalo, como uma credencial usada de um país incomum, comunicação com infraestrutura maliciosa conhecida ou enumeração de recursos. Ele não exige agente e funciona por análise contínua.

Inspector avalia vulnerabilidades em instâncias EC2, imagens de contêiner no ECR e funções Lambda, correlacionando pacotes instalados com CVEs conhecidas. Security Hub consolida os findings desses serviços e de outros, normaliza o formato e avalia a conta contra padrões como o AWS Foundational Security Best Practices.

Integração e priorização

Ative o Security Hub como ponto central de agregação e habilite GuardDuty e Inspector para alimentá-lo. Em ambientes com várias contas, use a configuração de administrador delegado para ter visão consolidada sem precisar entrar conta a conta.

Priorize por exposição e impacto, não só por severidade do finding. Uma vulnerabilidade crítica em uma instância isolada e sem exposição pública pode esperar; uma vulnerabilidade média em um serviço exposto à internet, não. Combine a severidade do serviço com o contexto de rede e a criticidade do ativo.

  • Suprima findings conhecidos e aceitos com justificativa registrada
  • Crie automações para findings repetitivos de baixo valor
  • Direcione findings de alta severidade para um canal com dono claro
  • Revise periodicamente os controles que estão falhando na postura

Rotina operacional

A diferença entre uma conta segura e uma conta cheia de findings ignorados é a rotina. Defina quem revisa os alertas, com que frequência e qual o caminho de tratamento. Sem dono e sem cadência, o painel vira um cemitério de alertas e a equipe deixa de confiar nele, ignorando inclusive o que é grave.

Checklist prático

  • Habilitar GuardDuty em todas as contas e regiões em uso
  • Habilitar Inspector para EC2, ECR e Lambda relevantes
  • Centralizar no Security Hub com administrador delegado
  • Ativar um padrão de postura, como o AWS Foundational Security Best Practices
  • Definir critério de priorização por exposição e criticidade
  • Suprimir findings aceitos com justificativa registrada
  • Automatizar o tratamento de findings repetitivos de baixo valor
  • Encaminhar alta severidade para um canal com dono
  • Definir cadência de revisão dos findings
  • Medir a evolução da postura ao longo do tempo

Boas práticas

  • Use o Security Hub como fonte única de verdade dos findings
  • Priorize por contexto de exposição, não apenas por severidade nominal
  • Atribua dono e prazo aos findings de alto risco
  • Trate supressão como decisão consciente e documentada
  • Conecte os findings ao seu fluxo de tickets ou de resposta
  • Reavalie regularmente quais controles continuam falhando

Erros comuns

  • Ativar os três serviços sem processo de tratamento

    O volume de findings vira ruído e a equipe passa a ignorar tudo.

  • Priorizar só por severidade do finding

    Esforço gasto em itens isolados enquanto exposições reais ficam abertas.

  • Habilitar apenas em algumas regiões

    Atividade maliciosa em regiões não cobertas passa despercebida.

  • Supressão em massa sem justificativa

    Riscos reais somem do radar junto com os falsos positivos.

  • Findings sem dono

    Alertas graves ficam parados e o tempo de resposta cresce.

Quando procurar apoio especializado

Transformar findings nativos em uma rotina de priorização e resposta é o ponto em que muitas equipes travam. A GUARDIASEC apoia isso nos serviços de Segurança AWS e de Monitoramento e Resposta, definindo critérios de priorização e fluxos de tratamento adequados ao seu contexto.

Perguntas frequentes

Preciso dos três serviços ou posso usar só um?

Eles resolvem problemas diferentes. GuardDuty detecta ameaças e comportamento suspeito, Inspector encontra vulnerabilidades nas cargas de trabalho e Security Hub agrega e mede a postura. Usar só um deixa uma lacuna. Em ambientes menores, o conjunto mínimo costuma ser GuardDuty mais Security Hub, somando Inspector conforme a superfície cresce.

GuardDuty substitui um SIEM?

Não. GuardDuty é um serviço de detecção focado no ambiente AWS. Um SIEM correlaciona fontes diversas, incluindo aplicações, rede e endpoints fora da AWS. Eles se complementam: os findings do GuardDuty podem alimentar o SIEM para correlação mais ampla.

Como evito a fadiga de alertas?

Centralize no Security Hub, priorize por exposição e criticidade em vez de só severidade, suprima de forma consciente os findings aceitos, automatize os repetitivos de baixo valor e atribua dono e prazo aos de alto risco. A rotina de revisão é o que mantém o painel confiável.

Esses serviços corrigem os problemas sozinhos?

Não. Eles detectam, avaliam e priorizam, mas a correção depende de ação humana ou de automações que você define. Alguns findings permitem resposta automatizada, porém a maior parte exige decisão e execução pela equipe responsável pelo recurso afetado.

Próximo passo

Vamos avaliar os riscos do seu ambiente?

Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.