Amazon SCS-C02: Vulnerabilità, patch e sicurezza degli host — Guida allo studio
Fa parte della AWS Security Specialty SCS-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Amazon Inspector: Scansione Avanzata per EC2, Lambda ed ECR
Amazon Inspector è un servizio di gestione delle vulnerabilità continuo e supportato da agent che rileva le CVE in istanze EC2, immagini di container archiviate in ECR e funzioni Lambda (sia il codice dell’applicazione che i layer di dipendenze). L’abilitazione di Inspector a livello di account registra automaticamente le risorse idonee — non esiste un flusso di lavoro di adesione per singola risorsa — e i risultati (finding) vengono inviati automaticamente ad AWS Security Hub nel formato standardizzato ASFF, che è il pattern di integrazione corretto quando è richiesta una dashboard centralizzata della postura di sicurezza.
Per EC2, Inspector utilizza un modello di scansione ibrido. L’SSM Agent (con l’associazione fornita da AWS) raccoglie un inventario del software utilizzato per la valutazione della raggiungibilità di rete e dei pacchetti in stile agentless, mentre la valutazione approfondita dell’host (deep host assessment) richiede che l’agent sia in esecuzione e che l’istanza sia raggiungibile tramite SSM. Questo è il motivo per cui l’approccio “solo agentless” è una trappola: senza il percorso dell’SSM Agent (o l’ispezione approfondita basata su agent di Inspector dove necessario), si ottengono solo risultati superficiali (shallow finding) — esposizione di rete e CVE derivate dal manifest — ma si perdono gli inventari delle librerie a runtime, i pacchetti non gestiti e le configurazioni. La modalità ibrida è ciò di cui la maggior parte degli ambienti di produzione ha bisogno.
Per Lambda, Inspector esegue due tipi di scansione: standard (vulnerabilità dei pacchetti nei layer e nelle dipendenze della funzione) e scansione del codice (analisi statica del codice della funzione per individuare injection flaw, segreti hardcoded e API non sicure). Una regola di idoneità critica: una funzione Lambda deve essere stata invocata almeno una volta negli ultimi 90 giorni per essere scansionata. Le funzioni inattive o archiviate escono silenziosamente dall’ambito di Inspector. I team che presumono “Inspector è abilitato, quindi ogni funzione è coperta” si trovano in difficoltà quando gli auditor chiedono prove su funzioni eseguite raramente. La soluzione consiste nell’invocare le funzioni secondo una pianificazione (EventBridge) oppure accettare l’esclusione e documentarla.
Per ECR, la scansione avanzata (enhanced scanning, basata su Inspector) sostituisce la vecchia scansione di base (basic scanning) basata su Clair. La scansione avanzata supporta sia la scansione al push (scan on push) sia la scansione continua (continuous scanning) delle immagini già presenti nel registro, così le CVE appena divulgate relative a immagini caricate in precedenza generano nuovi risultati senza la necessità di un nuovo push. Abilita la scansione avanzata a livello di registro e configura filtri per repository (ad esempio, prod/* scansione continua, sandbox/* solo scansione al push) per controllare i costi.
Amministrazione Delegata e Regole di Soppressione
In una configurazione multi-account con AWS Organizations, designa un account amministratore delegato (delegated administrator) per Inspector dall’account di gestione (management account). L’amministratore delegato visualizza i risultati aggregati di tutti gli account membri e controlla la configurazione delle scansioni a livello di organizzazione. Questo evita di dover concedere ruoli IAM cross-account per il recupero dei risultati e previene l’anti-pattern di abilitare Inspector frammentariamente, account per account.
Le regole di soppressione (suppression rules) consentono a un team di sicurezza di filtrare il “rumore” senza eliminare i risultati. Una regola effettua una corrispondenza su attributi come tag della risorsa, gravità, ID della CVE o repository ECR. Per escludere i risultati delle Lambda di dev/test dalla dashboard di produzione, applica una regola di soppressione basata sul tag Environment=dev — i risultati esistono ancora nel data store sottostante per scopi di audit, ma vengono esclusi dalle viste predefinite e da Security Hub, se configurato. Non ottenere questo risultato disabilitando Inspector per gli account di sviluppo; perderesti la capacità di intercettare la promozione da dev a prod di un artefatto vulnerabile.
Gating nella CI/CD per la Promozione delle Immagini
La scansione avanzata di ECR genera risultati legati a un digest dell’immagine (non solo al tag), che è l’elemento che una pipeline deve interrogare. Il pattern canonico è: build dell’immagine → push su ECR (attiva la scansione al push) → polling o attesa del completamento della scansione → fallimento della build se esistono risultati di gravità Alta o Critica → altrimenti, aggiornamento del task/deployment ECS/EKS.
Uno step minimo di CodeBuild in 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
Non implementare un blocco (gate) in questa fase — fidandosi del fatto che “Inspector ci avviserà” — è l’errore classico: gli avvisi arrivano in modo asincrono e dopo che l’immagine vulnerabile è già in esecuzione. Il gate deve essere sincrono con la promozione. Allo stesso modo, basare il gating solo sul tag anziché sul digest non è sicuro perché i tag sono mutabili; due push con lo stesso tag confonderanno i risultati della scansione.
Patch Manager, Baseline e Patch Group
SSM Patch Manager opera su tre elementi primitivi:
Patch baseline: definisce le regole di approvazione automatica, le patch approvate, le patch rifiutate e il livello di conformità per gravità/classificazione.
Patch group: un tag con chiave esattamente
Patch Groupil cui valore registra le istanze a una specifica baseline.Finestra di manutenzione (Maintenance window): la pianificazione durante la quale
AWS-RunPatchBaselineesegue i task di Scansione (Scan) o Installazione (Install).
Per un ambiente che richiede che Dev approvi automaticamente e immediatamente tutte le patch di sicurezza, e che Prod approvi automaticamente solo quelle Critiche/Importanti dopo un periodo di “soak” di 7 giorni, rifiutando i pacchetti del kernel, si creano due baseline. La baseline di Dev utilizza una regola di approvazione con ApproveAfterDays: 0 che copre tutte le classificazioni di sicurezza. La baseline di Prod utilizza ApproveAfterDays: 7, ComplianceLevel: CRITICAL, filtri Classification=Security e Severity in [Critical, Important], e aggiunge kernel* alla lista delle patch rifiutate con BlockAllPatchesFromRejectedList. Le istanze vengono taggate con Patch Group=Dev o Patch Group=Prod, e ogni patch group viene registrato alla baseline corrispondente. La conformità viene aggregata tramite i report di conformità delle patch (Patch Compliance reports) e può essere esportata su S3 per un audit centralizzato.
Una singola baseline “con logica” non può esprimere le differenze tra Dev e Prod — le baseline sono statiche per ogni gruppo registrato. Non tentare di utilizzare diverse Finestre di Manutenzione per simulare questo comportamento; la finestra controlla quando viene eseguito il patching, non quali patch vengono approvate.
Pipeline di Notifica in Tempo Reale
Per gli avvisi su Slack o Microsoft Teams relativi a nuovi finding, la catena operativamente più efficiente è:
Inspector invia i finding a EventBridge sulla sorgente di eventi
aws.inspector2.Una regola di EventBridge filtra per gravità (es.
HIGH,CRITICAL) e indirizza a un topic SNS.Il topic SNS ha una sottoscrizione di AWS Chatbot mappata al canale Slack o all’area di lavoro di Teams.
Chatbot si sottoscrive direttamente a SNS — non inserire una funzione Lambda intermedia per riformattare i messaggi, poiché Chatbot renderizza nativamente i finding di Inspector. Un esempio di pattern per EventBridge:
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
Due trappole da evitare qui: l’instradamento tramite Security Hub aggiunge latenza e può far perdere la granularità della gravità se gli insight personalizzati sono configurati male; inoltre, l’uso di SES o di una Lambda con webhook personalizzato aumenta l’overhead operativo senza aggiungere funzionalità che Chatbot fornisce già nativamente.
Problema Pratico: Scenario d’Uso
Scenario: Meridian Financial gestisce un’organizzazione AWS multi-account che supporta servizi web rivolti ai clienti, analisi batch e processori di eventi serverless. Le loro pipeline CI/CD inviano immagini container ad Amazon ECR, ospitano flotte di EC2 per carichi di lavoro legacy e utilizzano Lambda per i servizi più recenti; un team di sicurezza centrale, in un account di sicurezza, deve gestire la visibilità delle vulnerabilità e l’applicazione delle patch tra i vari account.
Sfida: Una recente immagine contenente una libreria con una vulnerabilità ad alta gravità è stata promossa in produzione perché le scansioni non erano obbligatorie nella CI/CD, e l’applicazione delle patch alle istanze EC2 è incoerente tra i vari ambienti, lasciando finestre di esposizione e una quantità di finding superflui (“noisy”) che sovraccaricano il team.
Approccio Raccomandato:
- Abilitare Amazon Inspector Enhanced Scanning su EC2, Lambda ed ECR dall’account di sicurezza, configurando l’amministrazione delegata in AWS Organizations in modo che scansioni, finding e regole di soppressione possano essere gestiti centralmente.
- Configurare la scansione delle immagini ECR “on push” e integrare dei “scan gate” in CodePipeline/CodeBuild: bloccare la promozione dell’immagine finché i risultati della scansione di Inspector/ECR non soddisfano le soglie di gravità e far emergere i finding durante la fase di build.
- Implementare AWS Systems Manager Patch Manager con baseline di patch e gruppi di patch definiti per ogni ambiente, pianificare Maintenance Windows per un rollout che parta dagli ambienti non di produzione e automatizzare l’approvazione per le correzioni di CVE critiche utilizzando i documenti di SSM Automation.
- Creare una pipeline di notifica in tempo reale utilizzando Amazon EventBridge per catturare i finding di Inspector e gli eventi di conformità di SSM, instradarli ad Amazon SNS e a una funzione AWS Lambda leggera che arricchisce, deduplica e pubblica avvisi prioritari su Slack, creando anche i relativi ticket di tracciamento.
- Automatizzare il contenimento e la remediation: utilizzare runbook di SSM Automation o Lambda attivati da EventBridge per isolare le versioni di EC2/Lambda impattate o per avviare la ricostruzione delle immagini, e applicare la soppressione di Inspector solo per i falsi positivi tracciati tramite l’account di amministratore delegato per ridurre il “rumore”.
Motivazione: La gestione centralizzata di Inspector, i gate nella CI/CD, le baseline di Patch Manager e una pipeline guidata da EventBridge seguono le best practice di AWS, imponendo prevenzione automatizzata, patching coerente e una risposta prioritizzata e verificabile, riducendo al contempo l’affaticamento da avvisi (alert fatigue).
Rilevamento delle Vulnerabilità con Amazon Inspector
Amazon Inspector è il principale servizio gestito di valutazione delle vulnerabilità su AWS e opera su tre superfici rilevanti per la sicurezza degli host: istanze EC2, immagini container in Amazon ECR e funzioni Lambda. Quando abilitato a livello di account o di Organizations (tramite amministratore delegato nella console di Inspector), esegue scansioni continue, senza agent o basate su SSM, anziché scansioni pianificate a un preciso istante (point-in-time). Questa postura continua è importante perché i feed CVE cambiano quotidianamente; un’istantanea della settimana scorsa potrebbe essere già obsoleta.
Per EC2, Inspector si affida all’SSM Agent per enumerare i pacchetti installati e le versioni del kernel, per poi correlarli con gli avvisi dei fornitori e il National Vulnerability Database. I finding includono l’identificatore CVE, il punteggio CVSS, il pacchetto interessato, la versione corretta e il contesto di raggiungibilità di rete (le regole di “network-reachability” identificano le porte esposte a Internet tramite ENI, security group, NACL e tabelle di instradamento). Poiché la scansione dipende da SSM, un’istanza EC2 che non ha la policy gestita AmazonSSMManagedInstanceCore nel suo profilo di istanza semplicemente non apparirà nei risultati di Inspector — un fallimento silenzioso che vale la pena ricordare.
Per ECR, Inspector supporta due modalità di scansione:
Scansione di base (Basic scanning): gratuita, utilizza il motore open-source Clair, viene eseguita solo “on push” o su richiesta.
Scansione avanzata (Enhanced scanning): basata su Inspector, riesegue continuamente la scansione delle immagini (sia pacchetti del sistema operativo che pacchetti di linguaggi applicativi come Python, Node, Java) man mano che vengono pubblicati nuovi CVE, anche molto tempo dopo l’evento di push.
Una trappola comune è considerare la scansione “on-push” di ECR come una misura di sicurezza sufficiente per l’host. Non lo è. La scansione “on-push” convalida l’immagine al momento della build, ma il container in esecuzione eredita l’immagine più eventuali deviazioni (drift), e l’host EC2 o Fargate sottostante ha il proprio kernel e i propri pacchetti OS che devono essere aggiornati indipendentemente. La scansione avanzata, combinata con la scansione degli host EC2, colma questa lacuna. Tutti i finding di Inspector dovrebbero essere instradati verso AWS Security Hub, che li normalizza nel formato ASFF e abilita l’aggregazione cross-account, la deduplicazione e l’automazione a valle tramite EventBridge.
Patch Manager e Risoluzione a Livello di Flotta
AWS Systems Manager Patch Manager completa Inspector rimediando effettivamente a ciò che Inspector rileva. Mentre Inspector risponde alla domanda “quali CVE mi riguardano?”, Patch Manager risponde a “quali patch mancano e come posso installarle in sicurezza?”.
Patch Manager opera tramite baseline di patch: regole dichiarative che definiscono quali patch sono approvate, in base alla classificazione (Security, Critical, Bugfix), alla gravità e a un ritardo di approvazione automatica (ad esempio, approvare le patch di sicurezza sette giorni dopo il rilascio per garantire la stabilità del fornitore). AWS fornisce baseline predefinite per ogni sistema operativo (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline, ecc.), ma le flotte di produzione utilizzano tipicamente baseline personalizzate associate a gruppi di patch tramite il tag Patch Group sulle istanze.
Un tipico flusso di lavoro di scansione e patching utilizza due operazioni:
Scan: segnala la conformità senza installare nulla; i risultati appaiono nella dashboard di conformità di Patch Manager e in Config.
Install: applica le patch approvate e, per molti sistemi operativi, esegue un riavvio.
Queste operazioni sono tipicamente pianificate tramite finestre di manutenzione con un documento AWS-RunPatchBaseline come target. Per scenari urgenti di tipo zero-day, Patch Manager offre Patch Now, un’azione on-demand che ignora la pianificazione delle finestre di manutenzione. Il pattern raccomandato è creare una baseline di patch ristretta che approvi solo il KB o il pacchetto specifico che corregge la vulnerabilità, definire come target il gruppo di patch interessato, eseguire Patch Now e inviare in streaming l’output dell’esecuzione a un bucket S3 centralizzato e a un gruppo di CloudWatch Logs. Quel log centralizzato diventa il tuo artefatto di audit, la prova della risoluzione per auditor o per l’incident response.
Problema Pratico: Scenario d’Uso
Scenario: Meridian Financial gestisce un ambiente AWS multi-account con diverse centinaia di istanze EC2 (Windows e Amazon Linux) e un piccolo cluster EKS a supporto dei servizi rivolti ai clienti. Utilizzano AWS Organizations, AWS Systems Manager per gli strumenti operativi e mantengono le AMI in un account di immagini condiviso, ma non dispongono di scansioni di vulnerabilità automatizzate e coerenti né di rollout di patch coordinati tra gli account.
Sfida: Viene pubblicata una CVE che riguarda OpenSSL e Amazon Inspector segnala risultati di gravità elevata su più istanze, ma l’applicazione delle patch è stata disomogenea e un servizio di produzione ha subito un breve tentativo di exploit a causa di una risoluzione tardiva.
Approccio Raccomandato:
- Abilitare Amazon Inspector in tutti gli account e le regioni per eseguire scansioni di vulnerabilità sia sulle immagini che sulle istanze in esecuzione, e inoltrare i risultati di alta gravità ad AWS Security Hub e a un bus di eventi personalizzato di EventBridge.
- Usare AWS Systems Manager Inventory per identificare le istanze interessate e taggarle per criticità; creare una baseline di Patch Manager che includa le correzioni OpenSSL necessarie e definire regole target per Windows/Linux.
- Creare una regola EventBridge che attivi un documento SSM Automation quando i risultati di Inspector raggiungono una gravità definita, passando l’elenco degli ID delle istanze a un runbook di Automation che invoca Patch Manager o Run Command per applicare le patch ed eseguire il riavvio dove necessario.
- Per i servizi stateful o ad alto rischio, orchestrare aggiornamenti continui (rolling update) utilizzando EC2 Image Builder per creare AMI con le patch applicate, aggiornare i gruppi di Auto Scaling o i gruppi di nodi EKS con un deployment controllato di tipo blue/green o rolling, e verificare l’integrità del servizio con i controlli di integrità di Route 53/ALB.
- Dopo la risoluzione, eseguire nuovamente Amazon Inspector per convalidare che i risultati siano stati risolti, aggiornare i report di SSM Compliance e inviare un riepilogo al team di sicurezza tramite SNS; conservare il runbook di Automation in una libreria di Systems Manager Automation per una risposta ripetibile a livello di flotta.
Motivazione: Questo approccio utilizza Amazon Inspector per il rilevamento continuo, Systems Manager Patch Manager e Automation per una risoluzione controllata e automatizzata, e la ricostruzione basata su immagini per un’infrastruttura immutabile, allineandosi con le best practice di AWS per il rilevamento, la risposta automatizzata e un raggio d’impatto minimo.
# 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
La conformità centralizzata si abilita configurando l’account amministratore delegato in Systems Manager Explorer e attivando la sincronizzazione dei dati delle risorse (resource data sync) per aggregare lo stato di conformità delle patch da ogni account in un unico bucket S3, che può poi essere interrogato con Athena o visualizzato in QuickSight.
Session Manager per un’Amministrazione Verificabile
L’accesso tradizionale basato su SSH ha tre debolezze strutturali: il materiale crittografico a lunga durata risiede sui laptop degli operatori, la porta 22 deve essere raggiungibile (anche se solo tramite un bastion host) e l’attività della shell non viene registrata centralmente senza strumenti aggiuntivi. Session Manager le elimina tutte e tre.
Session Manager crea un tunnel per una shell interattiva attraverso la connessione HTTPS in uscita dell’SSM Agent verso gli endpoint SSM. Non c’è nessuna porta in entrata, nessuna coppia di chiavi SSH e nessun bastion host. L’accesso è autorizzato da policy IAM (ssm:StartSession con ambito limitato per tag o ARN dell’istanza), e ogni sessione può essere registrata su CloudWatch Logs o S3, opzionalmente con crittografia KMS. Su Linux, le sessioni vengono eseguite di default come utente ssm-user; il comportamento di sudo è controllato dalla configurazione sudoers dell’istanza, non da IAM.
Il corretto pattern di hardening per le nuove flotte è: avviare le istanze senza una coppia di chiavi EC2, associare un profilo di istanza con AmazonSSMManagedInstanceCore, posizionare le istanze in sottoreti private con endpoint VPC per ssm, ssmmessages e ec2messages, e imporre la registrazione delle sessioni a livello delle preferenze di Session Manager. Continuare a distribuire chiavi SSH insieme a Session Manager è la trappola: preserva la stessa superficie di attacco che Session Manager è stato adottato per eliminare e lascia un canale di accesso non registrato. Rimuovete il provisioning di authorized_keys dal vostro processo di creazione delle AMI.
Telemetria dell’host con l’agente CloudWatch
L’agente unificato CloudWatch raccoglie metriche a livello di sistema operativo (memoria, disco, CPU per processo) e file di log che l’hypervisor di EC2 non può vedere. Viene configurato tramite un file JSON, tipicamente archiviato in Parameter Store, e poi applicato con amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux.
Il problema operativo più comune con l’agente è la mancanza dei permessi IAM sul profilo dell’istanza. L’agente richiede, come minimo:
logs:CreateLogGroup (a meno che il gruppo non sia pre-creato)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (per le metriche personalizzate)
ssm:GetParameter (per recuperare la configurazione da Parameter Store)
La policy gestita CloudWatchAgentServerPolicy raggruppa questi permessi. Quando i permessi mancano, l’agente si avvia con successo e appare in stato integro (healthy) in systemctl status, ma i log non arrivano mai in CloudWatch — gli errori sono visibili solo in /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log. Qualsiasi progetto di sicurezza a livello di host che si basa su log centralizzati deve convalidare la consegna dei dati, non solo lo stato dell’agente.
Mettere tutto insieme
Il ciclo difensivo è il seguente: Inspector rileva le CVE su host e immagini di container, i risultati (findings) confluiscono in Security Hub per l’aggregazione, Patch Manager esegue la remediation tramite finestre di manutenzione pianificate o con Patch Now per le emergenze, Session Manager fornisce l’unico percorso di accesso amministrativo, e l’agente CloudWatch invia in streaming sia le prove delle patch applicate (patching evidence) sia i log di runtime a un account centralizzato. Ogni controllo presuppone l’esistenza degli altri: Inspector senza Patch Manager produce report che nessuno prende in considerazione; Patch Manager senza una registrazione centralizzata dei log non produce alcuna traccia di audit (audit trail); Session Manager senza i permessi IAM corretti lascia un accesso o troppo ampio o troppo limitato; e l’agente CloudWatch senza i permessi corretti per i log produce solo l’illusione della visibilità.
← Governance · Tutti i domini · Sicurezza dei container e serverless →
Esercitati su queste domande → · Pratica cronometrata su 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.
Supera l'esame →