Amazon SCS-C02: Vulnerabilidade, Patch e Segurança de Host — Guia de estudos
Faz parte do AWS Security Specialty SCS-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
Amazon Inspector: Escaneamento Aprimorado em EC2, Lambda e ECR
O Amazon Inspector é um serviço de gerenciamento de vulnerabilidades contínuo e suportado por agente que descobre CVEs em instâncias EC2, imagens de contêiner armazenadas no ECR e funções Lambda (tanto o código da aplicação quanto as camadas de dependência). Habilitar o Inspector no nível da conta registra automaticamente os recursos elegíveis — não há um fluxo de adesão (opt-in) por recurso — e as descobertas (findings) são enviadas automaticamente para o AWS Security Hub no formato padronizado ASFF, que é o padrão de integração correto quando um painel central de postura de segurança é necessário.
Para o EC2, o Inspector usa um modelo de escaneamento híbrido. O SSM Agent (com a associação fornecida pela AWS) coleta um inventário de software usado para avaliação de pacotes e de alcançabilidade de rede no estilo sem agente (agentless), enquanto a avaliação profunda do host exige que o agente esteja em execução e que a instância esteja alcançável via SSM. É por isso que a abordagem “somente sem agente” é uma armadilha: sem o caminho do SSM Agent (ou a inspeção profunda baseada em agente do Inspector, quando necessária), você obtém descobertas superficiais — exposição de rede e CVEs derivados de manifestos — mas perde inventários de bibliotecas de tempo de execução, pacotes não gerenciados e configurações. O modo híbrido é o que a maioria dos ambientes de produção precisa.
Para o Lambda, o Inspector realiza dois tipos de escaneamento: padrão (vulnerabilidades de pacotes em camadas e dependências da função) e escaneamento de código (análise estática do código da função para falhas de injeção, segredos codificados (hardcoded) e APIs inseguras). Uma regra de elegibilidade crítica: uma função Lambda deve ter sido invocada pelo menos uma vez nos últimos 90 dias para ser escaneada. Funções ociosas ou arquivadas saem silenciosamente do escopo do Inspector. Equipes que presumem que “o Inspector está habilitado, portanto, toda função está coberta” se dão mal quando os auditores pedem evidências sobre funções raramente executadas. A remediação é invocar as funções em um cronograma (EventBridge) ou aceitar a exclusão e documentá-la.
Para o ECR, o escaneamento aprimorado (powered by Inspector) substitui o escaneamento básico mais antigo, baseado no Clair. O escaneamento aprimorado suporta tanto o escanear no push (scan on push) quanto o escaneamento contínuo de imagens que já estão no registro. Assim, CVEs recém-divulgados em imagens que já sofreram push geram novas descobertas sem a necessidade de um novo push. Habilite o escaneamento aprimorado no nível do registro e configure filtros por repositório (por exemplo, prod/* contínuo, sandbox/* apenas escanear no push) para controlar os custos.
Administração Delegada e Supressão
Em uma configuração multi-contas com o AWS Organizations, designe uma conta de administrador delegado para o Inspector a partir da conta de gerenciamento (management account). O administrador delegado visualiza as descobertas agregadas de todas as contas-membro e controla a configuração de escaneamento para toda a organização. Isso evita a concessão de IAM roles entre contas para a recuperação de descobertas e previne o antipadrão de habilitar o Inspector individualmente por conta.
As regras de supressão permitem que uma equipe de segurança filtre ruídos sem excluir as descobertas. Uma regra faz a correspondência com base em atributos como tag de recurso, severidade, ID do CVE ou repositório ECR. Para manter as descobertas de funções Lambda de dev/test fora do painel de produção, aplique uma regra de supressão baseada na tag Environment=dev — as descobertas ainda existem no armazenamento de dados subjacente para auditoria, mas são excluídas das visualizações padrão e do Security Hub, se configurado. Não faça isso desabilitando o Inspector para contas de dev; você perde a capacidade de detectar a promoção de um artefato vulnerável de dev para prod.
Controle de Acesso (Gating) no CI/CD para Promoção de Imagens
O escaneamento aprimorado do ECR gera descobertas vinculadas a um image digest (e não apenas à tag), que é o que um pipeline deve consultar. O padrão canônico é: construir a imagem → fazer push para o ECR (o que aciona o escaneamento no push) → fazer polling ou aguardar a conclusão do escaneamento → falhar o build se existirem descobertas de nível High ou Critical → caso contrário, atualizar a task/deployment do ECS/EKS.
Um passo mínimo do CodeBuild no buildspec.yml:
post_build:
commands:
DIGEST=$(aws ecr describe-images --repository-name $REPO \
--image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
aws inspector2 list-findings \
--filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
--query 'findings[].findingArn' --output text > findings.txt
- if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi
Deixar de implementar um controle (gate) nesta fase — confiando que “o Inspector nos alertará” — é o erro clássico: os alertas chegam de forma assíncrona e depois que a imagem vulnerável já está em execução. O controle deve ser síncrono com a promoção. Da mesma forma, basear o controle apenas na tag em vez do digest é inseguro porque as tags são mutáveis; dois pushes com a mesma tag irão misturar os resultados dos escaneamentos.
Patch Manager, Baselines e Patch Groups
O SSM Patch Manager opera com base em três primitivos:
- Patch baseline: define regras de aprovação automática, patches aprovados, patches rejeitados e nível de conformidade por severidade/classificação.
- Patch group: uma tag com a chave exatamente
Patch Group, cujo valor registra instâncias em uma baseline específica. - Janela de manutenção (Maintenance window): o cronograma durante o qual o
AWS-RunPatchBaselineexecuta tarefas de Scan ou Install.
Para um ambiente que exige que Dev aprove automaticamente todos os patches de segurança imediatamente, e que Prod aprove automaticamente apenas os patches Críticos/Importantes após um período de maturação (soak) de 7 dias, rejeitando pacotes do kernel, você cria duas baselines. A baseline de Dev usa uma regra de aprovação com ApproveAfterDays: 0 cobrindo todas as classificações de segurança. A baseline de Prod usa ApproveAfterDays: 7, ComplianceLevel: CRITICAL, filtra por Classification=Security e Severity in [Critical, Important], e adiciona kernel* à lista de patches rejeitados com BlockAllPatchesFromRejectedList. As instâncias recebem a tag Patch Group=Dev ou Patch Group=Prod, e cada patch group é registrado na baseline correspondente. A conformidade é consolidada através dos relatórios de Patch Compliance e pode ser exportada para o S3 para auditoria centralizada.
Uma única baseline “com lógica” não consegue expressar as diferenças entre Dev e Prod — as baselines são estáticas por grupo registrado. Não tente usar diferentes Janelas de Manutenção (Maintenance Windows) para simular esse comportamento; a janela controla quando o patching é executado, não quais patches são aprovados.
Pipeline de Notificação em Tempo Real
Para alertar no Slack ou Microsoft Teams sobre novos achados, a cadeia operacionalmente eficiente é:
Inspector emite achados para o EventBridge na origem de evento
aws.inspector2.Regra do EventBridge filtra por severidade (ex:
HIGH,CRITICAL) e direciona para um tópico SNS.Tópico SNS tem uma inscrição (subscription) do AWS Chatbot mapeada para o canal do Slack ou para o workspace do Teams.
O Chatbot se inscreve diretamente no SNS — não coloque um Lambda no meio para reformatar mensagens, pois o Chatbot renderiza nativamente os achados do Inspector. Um padrão de exemplo do EventBridge:
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
Duas armadilhas a serem evitadas aqui: o roteamento via Security Hub adiciona latência e pode perder a granularidade da severidade se os insights personalizados estiverem mal configurados; e usar SES ou um Lambda com webhook personalizado aumenta a sobrecarga operacional sem adicionar uma capacidade que o Chatbot já fornece nativamente.
Problema Prático: Cenário de Caso de Uso
Cenário: A Meridian Financial opera uma organização AWS com múltiplas contas que suporta serviços web voltados para o cliente, análises em lote e processadores de eventos serverless. Seus pipelines de CI/CD enviam imagens de contêiner para o Amazon ECR, eles hospedam frotas de EC2 para cargas de trabalho legadas e usam Lambda para serviços mais novos; uma equipe de segurança central em uma conta de segurança deve gerenciar a visibilidade de vulnerabilidades e a aplicação de patches entre as contas.
Desafio: Uma imagem recente contendo uma biblioteca de alta severidade foi promovida para produção porque as varreduras não foram impostas no CI/CD, e a aplicação de patches em instâncias EC2 é inconsistente entre os ambientes, deixando janelas de exposição e achados ruidosos que sobrecarregam a equipe.
Abordagem Recomendada:
- Habilitar o Amazon Inspector Enhanced Scanning para EC2, Lambda e ECR a partir da conta de segurança, configurando a administração delegada no AWS Organizations para que varreduras, achados e regras de supressão possam ser gerenciados centralmente.
- Configurar a varredura de imagens do ECR no momento do push e integrar portões (gates) de varredura no CodePipeline/CodeBuild: bloquear a promoção da imagem até que os resultados da varredura do Inspector/ECR atendam aos limites de severidade e expor os achados através da etapa de build.
- Implementar o AWS Systems Manager Patch Manager com baselines de patch e grupos de patch definidos por ambiente, agendar Janelas de Manutenção (Maintenance Windows) para uma implementação primeiro em ambientes de não produção e automatizar a aprovação para correções de CVEs críticos usando documentos do SSM Automation.
- Criar um pipeline de notificação em tempo real usando o Amazon EventBridge para capturar achados do Inspector e eventos de conformidade do SSM, roteá-los para o Amazon SNS e um AWS Lambda leve que enriquece, deduplica e posta alertas priorizados no Slack e cria tickets de acompanhamento.
- Automatizar a contenção e a remediação: usar runbooks do SSM Automation ou Lambda acionados pelo EventBridge para isolar as versões de EC2/Lambda impactadas ou acionar a reconstrução de imagens, e aplicar a supressão do Inspector apenas para falsos positivos rastreados através da conta de administrador delegado para reduzir o ruído.
Justificativa: O gerenciamento centralizado do Inspector, os portões de CI/CD, as baselines do Patch Manager e um pipeline orientado pelo EventBridge seguem as melhores práticas da AWS, impondo prevenção automatizada, aplicação de patches consistente e resposta priorizada e auditável, enquanto reduz a fadiga de alertas.
Descoberta de Vulnerabilidades com o Amazon Inspector
O Amazon Inspector é o principal serviço gerenciado de avaliação de vulnerabilidades na AWS e opera em três superfícies relevantes para a segurança de host: instâncias EC2, imagens de contêiner no Amazon ECR e funções Lambda. Quando habilitado no nível da conta ou da Organização (via administrador delegado no console do Inspector), ele realiza varreduras contínuas, sem agente ou baseadas no SSM, em vez de varreduras agendadas em um ponto no tempo. Essa postura contínua é importante porque os feeds de CVEs mudam diariamente; um snapshot da semana passada pode já estar obsoleto.
Para EC2, o Inspector depende do SSM Agent para enumerar os pacotes instalados e as versões do kernel, e então correlaciona-os com os avisos de fornecedores e com a National Vulnerability Database. Os achados incluem o identificador CVE, a pontuação CVSS, o pacote afetado, a versão corrigida e o contexto de alcançabilidade da rede (as regras de alcançabilidade de rede identificam portas expostas à internet via ENIs, security groups, NACLs e tabelas de rotas). Como a varredura depende do SSM, uma instância EC2 que não possui a política gerenciada AmazonSSMManagedInstanceCore em seu instance profile simplesmente não aparecerá nos resultados do Inspector — uma falha silenciosa que vale a pena lembrar.
Para o ECR, o Inspector suporta dois modos de varredura:
Varredura básica: gratuita, usa o motor de código aberto Clair, executa apenas no push ou sob demanda.
Varredura aprimorada: potencializada pelo Inspector, reexamina continuamente as imagens (tanto pacotes de SO quanto pacotes de linguagem de aplicação como Python, Node, Java) à medida que novos CVEs são publicados, mesmo muito tempo após o evento de push.
Uma armadilha comum é tratar a varredura no push do ECR como segurança de host suficiente. Não é. A varredura no push valida a imagem no momento do build, mas o contêiner em execução herda a imagem mais qualquer desvio (drift), e o host EC2 ou Fargate subjacente tem seu próprio kernel e pacotes de SO que devem ser corrigidos independentemente. A varredura aprimorada combinada com a varredura de host EC2 fecha essa lacuna. Todos os achados do Inspector devem ser roteados para o AWS Security Hub, que os normaliza para o formato ASFF e habilita a agregação entre contas, a deduplicação e a automação subsequente via EventBridge.
Patch Manager e Remediação em Toda a Frota
O AWS Systems Manager Patch Manager complementa o Inspector ao remediar de fato o que o Inspector descobre. Enquanto o Inspector responde “quais CVEs me afetam?”, o Patch Manager responde “quais patches estão faltando e como posso instalá-los com segurança?”
O Patch Manager opera por meio de baselines de patch — regras declarativas que definem quais patches são aprovados, com base na classificação (Segurança, Crítico, Correção de Bug), severidade e um atraso para aprovação automática (por exemplo, aprovar patches de Segurança sete dias após o lançamento para permitir a estabilidade do fornecedor). A AWS fornece baselines padrão por sistema operacional (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline, etc.), mas frotas de produção normalmente usam baselines personalizadas vinculadas a grupos de patch por meio da tag Patch Group nas instâncias.
Um fluxo de trabalho típico de varredura e aplicação de patches usa duas operações:
Scan: relata a conformidade sem instalar nada; os resultados aparecem no painel de conformidade do Patch Manager e no Config.
Install: aplica os patches aprovados e, para muitos sistemas operacionais, reinicializa.
Essas operações são normalmente agendadas por meio de janelas de manutenção com um documento AWS-RunPatchBaseline como alvo. Para cenários urgentes de dia zero, o Patch Manager oferece o Patch Now, uma ação sob demanda que ignora o agendamento da janela de manutenção. O padrão recomendado é criar uma baseline de patch restrita que aprove apenas o KB ou pacote específico que corrige a vulnerabilidade, direcionar ao grupo de patch afetado, executar o Patch Now e transmitir a saída da execução para um bucket S3 central e um grupo do CloudWatch Logs. Esse log centralizado se torna seu artefato de auditoria — a prova da remediação para auditores ou para a resposta a incidentes.
Problema Prático: Cenário de Caso de Uso
Cenário: A Meridian Financial opera um ambiente AWS multi-contas com várias centenas de instâncias EC2 (Windows e Amazon Linux) e um pequeno cluster EKS que suporta serviços voltados para o cliente. Eles usam o AWS Organizations, o AWS Systems Manager para ferramentas operacionais e mantêm AMIs em uma conta de imagens compartilhada, mas não possuem varredura de vulnerabilidades automatizada e consistente ou lançamentos de patches coordenados entre as contas.
Desafio: Uma CVE pública afetando o OpenSSL é publicada e o Amazon Inspector relata descobertas de alta gravidade em várias instâncias, mas a aplicação de patches tem sido irregular e um serviço de produção sofreu uma breve tentativa de exploração devido à remediação tardia.
Abordagem Recomendada:
- Habilite o Amazon Inspector em todas as contas e regiões para realizar varreduras de vulnerabilidade tanto em imagens quanto em instâncias em execução, e encaminhe as descobertas de alta severidade para o AWS Security Hub e para um barramento de eventos personalizado do EventBridge.
- Use o AWS Systems Manager Inventory para identificar as instâncias impactadas e etiquetá-las por criticidade; crie uma baseline do Patch Manager que inclua as correções necessárias do OpenSSL e direcione regras para Windows/Linux.
- Crie uma regra do EventBridge que acione um documento do SSM Automation quando as descobertas do Inspector atingirem uma severidade definida, passando a lista de IDs de instância para um runbook de Automação que invoca o Patch Manager ou o Run Command para aplicar patches e reiniciar onde for necessário.
- Para serviços stateful ou de alto risco, orquestre atualizações contínuas (rolling updates) usando o EC2 Image Builder para criar AMIs com patches, atualize os Auto Scaling groups ou os node groups do EKS com uma implantação controlada do tipo blue/green ou rolling, e verifique a saúde do serviço com as verificações de saúde do Route 53/ALB.
- Após a remediação, execute novamente o Amazon Inspector para validar que as descobertas foram resolvidas, atualize os relatórios do SSM Compliance e envie um resumo para a equipe de segurança através do SNS; mantenha o runbook de Automação em uma biblioteca do Systems Manager Automation para uma resposta repetível em toda a frota.
Justificativa: Esta abordagem usa o Amazon Inspector para descoberta contínua, o Systems Manager Patch Manager e o Automation para remediação controlada e automatizada, e reconstruções baseadas em imagem para infraestrutura imutável, alinhando-se com as melhores práticas da AWS para detecção, resposta automatizada e raio de impacto mínimo.
# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: PRODUCT
Values: [AmazonLinux2]
- Key: CVE_ID
Values: [CVE-2024-XXXXX]
ApproveAfterDays: 0
ComplianceLevel: CRITICAL
A conformidade centralizada é habilitada configurando a conta de administrador delegado no Systems Manager Explorer e ativando a sincronização de dados de recursos para agregar o estado de conformidade de patches de cada conta em um único bucket S3, que pode então ser consultado com o Athena ou visualizado no QuickSight.
Session Manager para Administração Auditável
O acesso tradicional baseado em SSH tem três fraquezas estruturais: material de chave de longa duração fica nos laptops dos operadores, a porta 22 deve estar acessível (mesmo que apenas através de um bastion) e a atividade do shell não é registrada centralmente sem ferramentas extras. O Session Manager elimina todas as três.
O Session Manager tunela um shell interativo através da conexão HTTPS de saída do SSM Agent para os endpoints do SSM. Não há porta de entrada, nem par de chaves SSH, nem bastion host. O acesso é autorizado por políticas do IAM (ssm:StartSession com escopo por tag de instância ou ARN), e cada sessão pode ser registrada no CloudWatch Logs ou S3, opcionalmente com criptografia KMS. No Linux, as sessões são executadas como ssm-user por padrão; o comportamento do sudo é controlado pela configuração do sudoers da instância, não pelo IAM.
O padrão de hardening correto para novas frotas é: lançar instâncias sem um par de chaves EC2, anexar um perfil de instância com AmazonSSMManagedInstanceCore, colocar as instâncias em sub-redes privadas com endpoints da VPC para ssm, ssmmessages e ec2messages, e impor o registro de sessão no nível das preferências do Session Manager. Continuar a distribuir chaves SSH junto com o Session Manager é a armadilha: isso preserva a mesma superfície de ataque que o Session Manager foi adotado para eliminar e deixa um canal de acesso não registrado. Remova o provisionamento de authorized_keys do seu processo de criação de AMI.
Telemetria de Host com o Agente do CloudWatch
O agente unificado do CloudWatch coleta métricas no nível do sistema operacional (memória, disco, CPU por processo) e arquivos de log que o hypervisor do EC2 não consegue ver. Ele é configurado por meio de um arquivo JSON, normalmente armazenado no Parameter Store, e então aplicado com amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux.
A falha operacional mais comum com o agente é a falta de permissões do IAM no instance profile. O agente precisa, no mínimo, de:
logs:CreateLogGroup (a menos que o grupo seja pré-criado)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (para métricas personalizadas)
ssm:GetParameter (para buscar a configuração do Parameter Store)
A política gerenciada CloudWatchAgentServerPolicy agrupa essas permissões. Quando as permissões estão ausentes, o agente inicia com sucesso e parece saudável no systemctl status, mas os logs nunca chegam ao CloudWatch — as falhas são visíveis apenas em /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log. Qualquer projeto de segurança de host que pressupõe logs centralizados deve validar a entrega, e não apenas o status do agente.
Juntando Tudo
O ciclo de defesa é: o Inspector descobre CVEs em hosts e imagens de contêiner, os achados (findings) fluem para o Security Hub para agregação, o Patch Manager remedia por meio de janelas de manutenção agendadas ou do Patch Now para emergências, o Session Manager fornece o único caminho de acesso administrativo, e o agente do CloudWatch transmite tanto as evidências de patching quanto os logs de tempo de execução para uma conta centralizada. Cada controle pressupõe os outros: o Inspector sem o Patch Manager produz relatórios sobre os quais ninguém age; o Patch Manager sem logs centralizados não produz trilha de auditoria; o Session Manager sem o IAM adequado deixa acesso excessivo ou insuficiente; e o agente do CloudWatch sem as permissões de log corretas produz a ilusão de visibilidade.
← Governança · Todos os domínios · Segurança de Contêineres e Serverless →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →