Detecção de Ameaças e Operações Integradas de Segurança com GuardDuty, Security Hub e Detective na AWS
_Category: Threat Detection_
No exame SCS-C03, o ponto central do domínio de detecção de ameaças é compreender como os três serviços trabalham juntos. O GuardDuty é o sistema de alarme contra invasões que opera 24 horas por dia, 7 dias por semana. O Security Hub é o painel de controle do centro de operações de segurança. E o Detective é a ferramenta de investigação que rastreia câmeras de segurança e registros de acesso. Cada um tem seu papel específico — e o exame cobra exatamente essas diferenças.
---
O Fluxo da Detecção de Ameaças: Coleta → Detecção → Priorização → Investigação → Resposta
Entender o fluxo de detecção de ameaças em cinco etapas deixa o papel de cada serviço muito mais claro.
A primeira etapa é a coleta de dados. CloudTrail, VPC Flow Logs, DNS Logs, registros de chamadas de API do S3, EKS Audit Logs, tráfego de rede do Lambda e outros logs são as fontes de dados originais. O GuardDuty é um serviço que consome esses dados — ele não exige que você configure pipelines de envio de logs nem instale agentes.
A segunda etapa é a detecção. O GuardDuty utiliza machine learning e inteligência de ameaças para identificar comportamentos anômalos e gerar Findings.
A terceira etapa é a priorização. Os Findings do GuardDuty são classificados por severidade (Low, Medium, High) e encaminhados ao Security Hub. O Security Hub não agrega apenas Findings do GuardDuty — ele também consolida resultados do Macie, Inspector, Firewall Manager, IAM Access Analyzer e outros serviços, normalizando tudo no formato ASFF (Amazon Security Finding Format).
A quarta etapa é a investigação. A partir de um Finding no Security Hub, você pode acessar o Amazon Detective para uma análise aprofundada. O Detective utiliza um banco de dados em grafos para visualizar as relações entre entidades — permitindo rastrear desde quando determinado endereço IP acessou uma conta.
A quinta etapa é a resposta. Os Findings do GuardDuty são automaticamente publicados no EventBridge, onde podem acionar Lambda, SNS, Step Functions e outros serviços. As Automation Rules do Security Hub permitem automatizar respostas a padrões específicos de Findings.
---
Amazon GuardDuty: Como Funciona a Detecção Automática de Ameaças e suas Fontes de Dados
O GuardDuty é um serviço gerenciado de detecção de ameaças que monitora automaticamente o ambiente AWS em busca de comportamentos anômalos, 24 horas por dia. A detecção começa simplesmente ao ativar o GuardDuty — sem necessidade de instalar agentes ou configurar pipelines de envio de logs.
As fontes de dados do GuardDuty são organizadas por funcionalidade:
| Fonte de Dados / Funcionalidade | O que é Detectado | Ativo por Padrão? | |---|---|---| | CloudTrail Management Events | Uso anômalo de credenciais IAM, logins suspeitos no console | Incluso por padrão | | VPC Flow Logs | Varredura de portas, conexões de saída anômalas, comunicação C2 | Incluso por padrão | | DNS Logs | Tunelamento DNS, consultas a domínios maliciosos conhecidos | Incluso por padrão (via Route 53 Resolver) | | S3 Protection | Acesso anômalo a buckets S3, exclusões ou downloads em massa | Ativação separada | | EKS Audit Logs | Uso indevido de permissões em contêineres, padrões anômalos de kubectl | Ativação separada | | Malware Protection | Varredura de malware em EC2/ECS (análise de volumes EBS) | Ativação separada | | RDS Login Events | Padrões anômalos de login em bancos Aurora | Ativação separada | | Lambda Network Activity | Comunicação de rede anômala de funções Lambda | Ativação separada |
A detecção de DNS do GuardDuty analisa apenas as consultas que passam pelo Route 53 Resolver dentro da VPC. Se uma instância EC2 utiliza um servidor DNS personalizado — como um forwarder externo ou on-premises — essas consultas ficam fora do escopo de detecção do GuardDuty. Ativar os query logs do Route 53 Resolver separadamente não compartilha os dados com o GuardDuty.
Em ambientes multi-conta, é possível integrar com AWS Organizations e gerenciar centralmente o GuardDuty de toda a organização a partir de uma conta Delegated Administrator.
---
Categorias de Findings do GuardDuty e Cenários Mais Frequentes no Exame
Os Findings do GuardDuty são organizados por um sistema de prefixos que indica a natureza da ameaça detectada.
Reconnaissance detecta atividades de exploração do ambiente pelo atacante — um exemplo representativo é Recon:EC2/PortProbeUnprotectedPort. UnauthorizedAccess identifica uso anômalo de credenciais, incluindo logins bem-sucedidos no console a partir de localizações incomuns, como em UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B. CryptoCurrency detecta mineração de criptomoedas (CryptoCurrency:EC2/BitcoinTool.B), e Backdoor identifica comunicação com servidores de comando e controle (Backdoor:EC2/C&CActivity.B). Behavior captura padrões anômalos de comportamento de credenciais IAM, e Pentest é gerado quando ferramentas de teste de invasão são detectadas.
No tratamento de falsos positivos, há dois conceitos que aparecem frequentemente no exame. O Trusted IP List suprime todos os Findings originados de um IP específico. A Suppression Rule combina tipo de Finding + condições de IP + tags de recursos, entre outras condições, para arquivar seletivamente apenas os Findings que correspondem a critérios específicos. Findings arquivados ficam ocultos no console, mas são retidos por 90 dias.
Se o cenário descreve Findings de InstanceCredentialExfiltration sendo gerados repetidamente por tráfego legítimo passando por um gateway NAT on-premises, a resposta correta é a Suppression Rule. Usar o Trusted IP List suprimiria também as ameaças reais originadas daquele IP.
---
AWS Security Hub: Consolidação de Findings e Security Standards
O Security Hub é o serviço responsável por agregar Findings de múltiplos serviços de segurança da AWS e ferramentas de terceiros em um único lugar, avaliando continuamente o estado de conformidade com padrões de segurança.
O ASFF (Amazon Security Finding Format) é o formato padrão que normaliza todos os Findings em um mesmo esquema JSON. Independentemente da origem — GuardDuty, Macie, Inspector — tudo é convertido para ASFF, viabilizando buscas e filtragens integradas.
| Security Standard | Foco | Principal Caso de Uso | |---|---|---| | AWS Foundational Security Best Practices (FSBP) | Boas práticas de segurança por serviço AWS | Baseline geral de segurança AWS | | CIS AWS Foundations Benchmark | Recomendações do CIS (Center for Internet Security) | Hardening conforme padrão da indústria | | PCI DSS | Padrão de segurança da indústria de cartões de pagamento | Ambientes de processamento de pagamentos | | NIST SP 800-53 | Segurança de sistemas de informação do governo federal dos EUA | Órgãos públicos e ambientes com compliance rigoroso |
Insights é a funcionalidade que agrupa Findings com padrões comuns em coleções. As Automation Rules modificam atributos de Findings automaticamente ou disparam respostas quando um Finding é recebido pelo Security Hub, com base em condições configuradas. Com a integração do Organizations e a designação de um Delegated Administrator, o Security Hub é ativado automaticamente nas novas contas da organização e os Findings dos membros são centralizados.
---
Amazon Detective: Investigação Profunda Baseada em Grafos
Quando um Finding do GuardDuty ou do Security Hub surge, o Detective é a ferramenta que responde às perguntas: esse Finding é realmente grave? Existem outros comportamentos anômalos relacionados? Assim como investigadores analisam imagens de câmeras de segurança e registros de entrada em uma cena de crime, o Detective usa um banco de dados em grafos para visualizar as relações entre entidades e padrões de comportamento.
O Detective analisa CloudTrail logs, VPC Flow Logs e GuardDuty Findings. Ao visualizar um Finding no GuardDuty ou no Security Hub e clicar em Investigate in Detective, você é direcionado ao console do Detective. A partir daí, o Detective apresenta uma linha do tempo com os endereços IP, contas e histórico de chamadas de API relacionados ao Finding, comparando o comportamento atual com o padrão de referência (Baseline) para visualizar o quanto aquela atividade é anômala.
O Detective exige que o GuardDuty esteja ativo como pré-requisito. Por ser uma ferramenta de investigação manual, não é adequado para automações via EventBridge nem para alertas em tempo real. A distinção é simples: se você quer consolidar Findings de múltiplos serviços em um único painel, use o Security Hub. Se você quer analisar profundamente um Finding específico, use o Detective.
---
Comparativo dos Três Serviços e Automação com EventBridge
Veja a comparação dos três serviços de forma resumida:
| Critério | GuardDuty | Security Hub | Detective | |---|---|---|---| | Papel Principal | Detecção automática de ameaças | Consolidação de Findings e avaliação de conformidade | Investigação profunda e análise de causa raiz | | Analogia | Sistema de alarme 24/7 | Painel do centro de operações de segurança | Ferramenta de investigação e câmeras de segurança | | Entrada | CloudTrail, VPC Flow Logs, DNS, S3, EKS, etc. | GuardDuty, Macie, Inspector, terceiros, etc. | GuardDuty Findings, CloudTrail, VPC Flow Logs | | Saída | Findings (resultados de detecção) | Findings consolidados, pontuação de conformidade | Visualização em grafos, análise de linha do tempo | | Automação | Publicação de eventos no EventBridge | Automation Rules, integração com EventBridge | Investigação manual (sem suporte a automação) | | Dependência do GuardDuty | Independente | Independente (funciona sem GuardDuty) | Requer GuardDuty ativo |
A arquitetura de resposta automática com EventBridge é um tópico muito recorrente no SCS-C03. O GuardDuty publica automaticamente um evento no EventBridge a cada Finding gerado. Uma regra no EventBridge pode filtra