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, os planos de proteção que ampliam a cobertura do GuardDuty, como integrá-los, como automatizar a resposta 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.
Planos de proteção do GuardDuty
O GuardDuty base analisa CloudTrail, logs de DNS e VPC Flow Logs, mas evoluiu para planos adicionais que estendem a cobertura conforme a sua superfície. Vale ativar o que corresponde ao que você de fato opera, em vez de ligar tudo sem critério.
- S3 Protection analisa eventos de dados do S3 em busca de acesso anômalo
- Malware Protection varre volumes ligados a instâncias com finding suspeito
- Runtime Monitoring observa comportamento em EKS, ECS e EC2 com um agente leve
- Proteção para RDS detecta tentativas anômalas de login em bancos gerenciados
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.
A automação sustenta essa rotina. Os findings do Security Hub e do GuardDuty geram eventos no EventBridge, que você encaminha para notificação em um canal com dono ou para uma função que executa uma resposta padrão, como isolar uma instância ou revogar uma sessão suspeita. Automatize primeiro o que é repetitivo e de baixo risco de erro, e mantenha decisão humana para o que tem impacto amplo. O objetivo é reduzir o tempo entre detectar e agir, sem tirar o julgamento de onde ele importa.
Checklist prático
- Habilitar GuardDuty em todas as contas e regiões em uso
- Ativar os planos de proteção do GuardDuty que correspondem à sua superfície
- 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
- Encaminhar findings via EventBridge para notificação e resposta automatizada
- 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.
O GuardDuty tem custo alto?
O custo varia com o volume de eventos analisados e com quais planos de proteção você ativa. O GuardDuty base costuma ter custo modesto frente ao ganho de detecção; os planos adicionais, como análise de eventos de dados do S3 e monitoramento em tempo de execução, elevam o valor conforme o volume. O caminho sensato é começar pelo base em todas as contas e ativar cada plano onde a superfície justifica, acompanhando o custo pelo período de avaliação.
Como automatizo a resposta a um finding do GuardDuty?
Os findings viram eventos no EventBridge, que você roteia para um destino de notificação ou para uma função que executa uma ação. Respostas comuns incluem avisar um canal com dono, abrir um ticket, isolar uma instância por security group ou revogar credenciais suspeitas. Comece automatizando o repetitivo e de baixo risco de erro, e mantenha aprovação humana para ações de impacto amplo.
Guias relacionados
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.