Amazon Inspector unifica varredura de vulnerabilidades em EC2, ECR e Lambda

Amazon Inspector unifica varredura de vulnerabilidades em EC2, ECR e Lambda

Amazon Inspector unifica varredura de vulnerabilidades em EC2, ECR e Lambda

Nota da redação: este artigo compara o Amazon Inspector ao Amazon GuardDuty como par de detecção de vulnerabilidade e detecção de ameaça. Essa comparação não consta na documentação oficial consultada para esta matéria; é uma interpretação do autor sobre os papéis dos dois serviços, não uma afirmação documentada pela AWS. Leve isso em conta antes de usar essa comparação como referência técnica.

A documentação do Amazon Inspector detalha como o serviço descobre instâncias EC2, imagens no Amazon ECR e funções Lambda sozinho e as rescaneia sempre que algo muda, sem agenda fixa.

O que entra no radar: EC2, imagens no ECR e funções Lambda

O Amazon Inspector é o serviço de gestão de vulnerabilidades da AWS: ele descobre sozinho os recursos elegíveis da conta e os varre continuamente, sem que alguém precise agendar um scan. Segundo a documentação oficial, o escopo cobre três tipos de workload: instâncias Amazon EC2, imagens de container armazenadas no Amazon ECR e funções AWS Lambda. Cada vulnerabilidade ou exposição de rede não intencional vira um finding, um relatório detalhado que fica disponível no console ou via API.

Para quem já vive dentro do console de segurança cuidando de GuardDuty, essa separação de papéis importa. O Inspector não observa tráfego nem comportamento em tempo real: ele olha para o que está instalado, empacotado ou publicado, e aponta onde existe uma falha conhecida antes que alguém a explore. É o par de vulnerabilidade do par de detecção de ameaça que o GuardDuty já entrega.

Varredura contínua: o gatilho é a mudança, não o calendário

A documentação é explícita: não existe janela de scan para configurar. O Inspector dispara uma nova varredura sempre que algo no ambiente pode introduzir uma vulnerabilidade nova, como a instalação de um pacote numa instância EC2, a aplicação de um patch ou a publicação de um CVE novo que afeta um recurso já coberto. Isso muda o modelo mental de quem vem de scanner tradicional: o scan não é um evento agendado, é uma reação a um evento do seu próprio ambiente.

Esse modelo tem uma consequência prática direta: um finding fica aberto até o recurso deixar de ser vulnerável, e quando isso acontece, o Inspector fecha o finding sozinho. Não há passo manual de "marcar como resolvido": o fechamento é automático assim que a remediação é detectada na próxima varredura.

O Inspector Risk Score: o CVSS que entende seu ambiente

Um CVE crítico numa instância sem rota de saída para a internet não tem o mesmo risco real que o mesmo CVE numa instância exposta publicamente. O Inspector reconhece isso: ele parte do score base do National Vulnerability Database (NVD) e o ajusta conforme o ambiente de computação onde o recurso vive, produzindo um score próprio em formato CVSS.

Na prática, isso quer dizer que a nota que aparece no finding pode ser mais baixa do que a nota pública do CVE, justamente porque o Inspector enxergou que não existe caminho de rede explorável a partir daquele recurso específico. É um filtro de ruído: em vez de triar centenas de CVEs críticos pelo score genérico do NVD, o time de segurança prioriza pelo score que já considera a exposição real.

Do finding ao playbook: dashboard, supressões e relatórios

O painel do Inspector concentra uma visão de alto nível de tudo que foi encontrado, com um recurso específico chamado risk-based remediation panel: ele agrupa os findings que afetam o maior número de instâncias e imagens ao mesmo tempo, para que a correção de maior impacto apareça primeiro em vez de se perder entre dezenas de findings isolados.

Além do dashboard, a tela de Findings do console permite:

• Agrupar resultados por categoria ou tipo de vulnerabilidade
• Aplicar filtros para refinar a lista por severidade, recurso ou outros critérios
• Criar regras de supressão que escondem findings indesejados das visões padrão
• Gerar relatórios em CSV ou JSON a partir de qualquer filtro ou seleção aplicada

Esse último ponto resolve um problema recorrente em auditoria: em vez de exportar tudo e filtrar depois, o relatório já sai recortado pelo critério que interessa para aquele ciclo de compliance.

Integração com EventBridge e Security Hub CSPM

O Inspector publica cada finding como evento no Amazon EventBridge, o que abre a porta para automação: uma função Lambda pode processar o evento e abrir um ticket, um tópico do Amazon SNS pode notificar o time de plantão, ou uma regra pode disparar uma remediação automática. Isso tira o Inspector do modelo "alguém precisa entrar no console para ver" e coloca ele dentro do fluxo de trabalho que já existe.

Se a conta tiver o AWS Security Hub CSPM ativado, o Inspector também publica os findings lá. Isso coloca a vulnerabilidade dentro de uma visão mais ampla da postura de segurança da conta, que o Security Hub CSPM consolida e confronta com padrões e boas práticas da indústria, o que facilita monitorar e processar findings como parte de uma análise mais abrangente do ambiente, em vez de depender só do console do Inspector isolado.

Organização inteira, um console: delegated administrator

Para ambientes com múltiplas contas via AWS Organizations, a documentação descreve a ativação do Inspector com um único clique para toda a organização, incluindo a opção de habilitar automaticamente o serviço para contas que entrarem depois. Uma conta é designada delegated administrator e passa a enxergar findings agregados de todos os membros, além de poder ativar ou desativar a varredura conta a conta.

Isso elimina o cenário comum de segurança fragmentada entre contas de dev, staging e produção geridas por times diferentes: o delegated administrator revisa a cobertura de recursos escaneados da organização inteira num só lugar, sem depender de cada dono de conta lembrar de ativar o serviço.

Antes de ligar: o que checar

Amazon Inspector está disponível na maioria das Regiões AWS, mas a lista exata vive no documento de endpoints e quotas do serviço, vale conferir se a região São Paulo (sa-east-1) está nela antes de assumir cobertura automática para workloads brasileiros. A documentação também deixa claro que o serviço só varre recursos que classifica como elegíveis: nem todo tipo de instância, imagem ou função entra automaticamente, e isso é o primeiro ponto a validar num piloto, antes de prometer cobertura total para auditoria ou LGPD.

Fonte: Documentação do Amazon Inspector