Amazon SCS-C02: Kwetsbaarheden, Patch en Host-beveiliging — Studiegids
Onderdeel van de AWS Security Specialty SCS-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.
Amazon Inspector: Enhanced Scanning voor EC2, Lambda en ECR
Amazon Inspector is een continue, door een agent ondersteunde dienst voor kwetsbaarhedenbeheer die CVE’s ontdekt in EC2-instances, container-images opgeslagen in ECR, en Lambda-functies (zowel applicatiecode als dependency-lagen). Het inschakelen van Inspector op accountniveau schrijft automatisch in aanmerking komende resources in — er is geen opt-in workflow per resource — en bevindingen worden automatisch naar AWS Security Hub gepusht in het gestandaardiseerde ASFF-formaat, wat het correcte integratiepatroon is wanneer een centraal dashboard voor de security-status vereist is.
Voor EC2 gebruikt Inspector een hybride scanmodel. De SSM Agent (met de door AWS geleverde association) verzamelt een software-inventaris die wordt gebruikt voor agentless-stijl netwerkbereikbaarheid en package-evaluatie, terwijl voor een diepgaande host-evaluatie de agent moet draaien en de instance bereikbaar moet zijn via SSM. Dit is waarom de “alleen agentless”-aanpak een valkuil is: zonder het SSM Agent-pad (of Inspector’s agent-gebaseerde diepe inspectie waar nodig), krijg je oppervlakkige bevindingen — netwerkblootstelling en van manifesten afgeleide CVE’s — maar mis je inventarissen van runtime-bibliotheken, niet-beheerde packages en configuraties. De hybride modus is wat de meeste productieomgevingen nodig hebben.
Voor Lambda voert Inspector twee soorten scans uit: standaard (kwetsbaarheden in packages in lagen en functie-dependencies) en code scanning (statische analyse van functiecode op injectiefouten, hardgecodeerde secrets en onveilige API’s). Een cruciale voorwaarde: een Lambda-functie moet minstens één keer in de afgelopen 90 dagen zijn aangeroepen om gescand te worden. Inactieve of gearchiveerde functies vallen stilzwijgend buiten het bereik van Inspector. Teams die aannemen “Inspector is ingeschakeld, dus elke functie is gedekt” komen in de problemen wanneer auditors bewijs vragen voor zelden uitgevoerde functies. De oplossing is om functies op een schema aan te roepen (EventBridge) of de uitsluiting te accepteren en te documenteren.
Voor ECR vervangt enhanced scanning (aangedreven door Inspector) de oudere ‘basic scanning’ die gebaseerd is op Clair. Enhanced scanning ondersteunt zowel scan on push als continuous scanning van images die al in de registry staan, zodat nieuw onthulde CVE’s voor eerder gepushte images nieuwe bevindingen genereren zonder een nieuwe push. Schakel enhanced scanning in op registry-niveau en configureer filters per repository (bijvoorbeeld prod/* continuous, sandbox/* alleen scan-on-push) om de kosten te beheersen.
Delegated Administration en Suppression
Wijs in een multi-account AWS Organizations-setup een delegated administrator-account voor Inspector aan vanuit het management account. De delegated admin ziet geaggregeerde bevindingen van alle member accounts en beheert de scanconfiguratie voor de hele organisatie. Dit voorkomt het toekennen van cross-account IAM-rollen voor het ophalen van bevindingen en vermijdt het antipattern om Inspector per account stuksgewijs in te schakelen.
Suppression rules stellen een securityteam in staat om ruis te filteren zonder bevindingen te verwijderen. Een regel matcht op attributen zoals resource-tag, severity, CVE ID of ECR-repository. Om bevindingen van dev/test Lambda’s van het productiedashboard te weren, pas je een suppression rule toe op basis van de tag Environment=dev — de bevindingen blijven bestaan in de onderliggende datastore voor audit, maar worden uitgesloten van de standaardweergaven en, indien geconfigureerd, van Security Hub. Bereik dit niet door Inspector uit te schakelen voor dev-accounts; je verliest dan de mogelijkheid om een promotie van een kwetsbaar artefact van dev naar prod te detecteren.
CI/CD Gating voor Image-promotie
Enhanced ECR scanning genereert bevindingen die gekoppeld zijn aan een image digest (niet alleen de tag), en dat is wat een pipeline moet opvragen. Het canonieke patroon is: bouw image → push naar ECR (triggert scan on push) → poll of wacht op voltooiing van de scan → laat de build mislukken als er High of Critical bevindingen zijn → update anders de ECS/EKS-task/deployment.
Een minimale CodeBuild-stap 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
Het nalaten van een ‘gate’ in deze fase — vertrouwen op “Inspector zal ons wel waarschuwen” — is de klassieke fout: meldingen komen asynchroon binnen en nadat de kwetsbare image al draait. De ‘gate’ moet synchroon zijn met de promotie. Evenzo is het onveilig om alleen op de tag te ‘gaten’ in plaats van op de digest, omdat tags veranderlijk (mutable) zijn; twee pushes met dezelfde tag zullen scanresultaten door elkaar halen.
Patch Manager, Baselines en Patch Groups
SSM Patch Manager werkt met drie primitieven:
- Patch baseline: definieert regels voor automatische goedkeuring, goedgekeurde patches, afgewezen patches en het compliance-niveau per severity/classificatie.
- Patch group: een tag met exact de key
Patch Groupwaarvan de waarde instances registreert bij een specifieke baseline. - Maintenance window: het schema waarin
AWS-RunPatchBaselineScan- of Install-taken uitvoert.
Voor een omgeving waar Dev alle security-patches onmiddellijk automatisch moet goedkeuren, en Prod alleen Critical/Important patches na een testperiode van 7 dagen automatisch goedkeurt terwijl kernel-packages worden afgewezen, maak je twee baselines. De Dev-baseline gebruikt een goedkeuringsregel met ApproveAfterDays: 0 die alle security-classificaties dekt. De Prod-baseline gebruikt ApproveAfterDays: 7, ComplianceLevel: CRITICAL, filtert op Classification=Security en Severity in [Critical, Important], en voegt kernel* toe aan de lijst met afgewezen patches met BlockAllPatchesFromRejectedList. Instances worden getagd met Patch Group=Dev of Patch Group=Prod, en elke patch group wordt geregistreerd bij de corresponderende baseline. Compliance wordt geaggregeerd via Patch Compliance reports en kan naar S3 worden geëxporteerd voor centrale audit.
Een enkele baseline “met logica” kan geen Dev-versus-Prod-verschillen uitdrukken — baselines zijn statisch per geregistreerde groep. Probeer dit gedrag niet na te bootsen met verschillende Maintenance Windows; het window bepaalt wanneer het patchen wordt uitgevoerd, niet welke patches worden goedgekeurd.
Realtime Notificatiepijplijn
Voor Slack- of Microsoft Teams-meldingen over nieuwe bevindingen is de operationeel efficiënte keten:
Inspector stuurt bevindingen naar EventBridge via de
aws.inspector2event source.EventBridge-regel filtert op ernstgraad (bijv.
HIGH,CRITICAL) en richt zich op een SNS-topic.SNS-topic heeft een AWS Chatbot-abonnement dat is gekoppeld aan het Slack-kanaal of de Teams-werkruimte.
Chatbot abonneert zich rechtstreeks op SNS — plaats er geen Lambda tussen om berichten opnieuw te formatteren, aangezien Chatbot Inspector-bevindingen native rendert. Een voorbeeld van een EventBridge-patroon:
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
Twee valkuilen die hier vermeden moeten worden: routering via Security Hub voegt latentie toe en kan de granulariteit van de ernstgraad verliezen als aangepaste inzichten verkeerd zijn geconfigureerd; en het gebruik van SES of een aangepaste webhook Lambda verhoogt de operationele overhead zonder functionaliteit toe te voegen die Chatbot al native biedt.
Praktijkprobleem: Gebruikersscenario
Scenario: Meridian Financial beheert een multi-account AWS-organisatie die klantgerichte webdiensten, batch-analyses en serverless event processors ondersteunt. Hun CI/CD-pijplijnen pushen container-images naar Amazon ECR, ze hosten EC2-vloten voor legacy workloads en gebruiken Lambda voor nieuwere diensten; een centraal securityteam in een security-account moet de zichtbaarheid van kwetsbaarheden en het patchen over alle accounts beheren.
Uitdaging: Een recente image met een bibliotheek met een hoge ernstgraad werd gepromoveerd naar productie omdat scans niet werden afgedwongen in CI/CD, en het patchen van EC2-instances is inconsistent tussen omgevingen, wat leidt tot blootstellingsvensters en ruisende bevindingen die het team overweldigen.
Aanbevolen Aanpak:
- Schakel Amazon Inspector Enhanced Scanning in voor EC2, Lambda en ECR vanuit het security-account door gedelegeerd beheer (delegated administration) in AWS Organizations te configureren, zodat scans, bevindingen en onderdrukkingsregels centraal kunnen worden beheerd.
- Configureer ECR-imagescans bij het pushen en integreer scan-gates in CodePipeline/CodeBuild: blokkeer de promotie van images totdat de scanresultaten van Inspector/ECR voldoen aan de drempelwaarden voor ernstgraad en breng bevindingen naar boven via de build-stap.
- Implementeer AWS Systems Manager Patch Manager met gedefinieerde patch-baselines en patch-groepen per omgeving, plan Maintenance Windows voor een uitrol die eerst in niet-productie plaatsvindt, en automatiseer de goedkeuring voor kritieke CVE-fixes met behulp van SSM Automation-documenten.
- Creëer een realtime notificatiepijplijn met Amazon EventBridge om Inspector-bevindingen en SSM-compliancegebeurtenissen vast te leggen, routeer ze naar Amazon SNS en een lichtgewicht AWS Lambda die geprioriteerde waarschuwingen verrijkt, dedupliceert, naar Slack post en tracking-tickets aanmaakt.
- Automatiseer indamming en herstel: gebruik door EventBridge getriggerde SSM Automation- of Lambda-runbooks om getroffen EC2/Lambda-versies te isoleren of image-rebuilds te triggeren, en pas Inspector-onderdrukking alleen toe voor bijgehouden false positives via de gedelegeerde beheerdersaccount om ruis te verminderen.
Redenering: Gecentraliseerd Inspector-beheer, CI/CD-gating, Patch Manager-baselines en een door EventBridge aangestuurde pijplijn volgen de best practices van AWS door het afdwingen van geautomatiseerde preventie, consistent patchen en een geprioriteerde, auditeerbare respons, terwijl alert-moeheid wordt verminderd.
Kwetsbaarheden Ontdekken met Amazon Inspector
Amazon Inspector is de primaire beheerde service voor kwetsbaarheidsbeoordeling op AWS en opereert op drie vlakken die relevant zijn voor hostbeveiliging: EC2-instances, container-images in Amazon ECR en Lambda-functies. Wanneer ingeschakeld op account- of organisatieniveau (via een gedelegeerde beheerder in de Inspector-console), voert het continue, agentless of op SSM gebaseerde scanning uit in plaats van geplande point-in-time scans. Deze continue houding is belangrijk omdat CVE-feeds dagelijks veranderen; een momentopname van vorige week kan al verouderd zijn.
Voor EC2 vertrouwt Inspector op de SSM Agent om geïnstalleerde pakketten en kernelversies op te sommen en correleert deze vervolgens met adviezen van leveranciers en de National Vulnerability Database. Bevindingen omvatten de CVE-identifier, CVSS-score, het betreffende pakket, de gefixte versie en context over netwerkbereikbaarheid (de regels voor netwerkbereikbaarheid identificeren poorten die via ENI’s, security groups, NACL’s en route tables aan het internet zijn blootgesteld). Omdat de scanning afhankelijk is van SSM, zal een EC2-instance die het AmazonSSMManagedInstanceCore beheerde beleid op zijn instance profile mist, simpelweg niet verschijnen in de resultaten van Inspector — een stille fout die het onthouden waard is.
Voor ECR ondersteunt Inspector twee scanmodi:
Basic scanning: gratis, gebruikt de open-source Clair-engine, draait alleen bij een push of op aanvraag.
Enhanced scanning: aangedreven door Inspector, herscant images continu (zowel OS-pakketten als pakketten voor applicatietalen zoals Python, Node, Java) naarmate nieuwe CVE’s worden gepubliceerd, zelfs lang na de push-gebeurtenis.
Een veelvoorkomende valkuil is om ECR scan-on-push te beschouwen als voldoende hostbeveiliging. Dat is het niet. Scan-on-push valideert de image op het moment van de build, maar de draaiende container erft de image plus eventuele afwijkingen (drift), en de onderliggende EC2- of Fargate-host heeft zijn eigen kernel en OS-pakketten die onafhankelijk moeten worden gepatcht. Enhanced scanning in combinatie met EC2-hostscanning dicht dat gat. Alle Inspector-bevindingen moeten worden doorgestuurd naar AWS Security Hub, dat ze normaliseert naar het ASFF-formaat en cross-account aggregatie, deduplicatie en downstream automatisering via EventBridge mogelijk maakt.
Patch Manager en Vlootbreed Herstel
AWS Systems Manager Patch Manager vult Inspector aan door daadwerkelijk te herstellen wat Inspector ontdekt. Waar Inspector de vraag “welke CVE’s hebben invloed op mij?” beantwoordt, geeft Patch Manager antwoord op “welke patches ontbreken, en hoe installeer ik ze veilig?”
Patch Manager werkt via patch baselines — declaratieve regels die definiëren welke patches zijn goedgekeurd, gebaseerd op classificatie (Security, Critical, Bugfix), ernst (severity) en een vertraging voor automatische goedkeuring (bijvoorbeeld, keur Security-patches zeven dagen na release goed om de stabiliteit van de leverancier te waarborgen). AWS levert standaard baselines per OS (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline, etc.), maar productievloten gebruiken doorgaans aangepaste baselines die gekoppeld zijn aan patch groups via de Patch Group-tag op instances.
Een typische workflow voor scannen en patchen gebruikt twee operaties:
Scan: rapporteert compliance zonder iets te installeren; resultaten verschijnen op het Patch Manager compliance-dashboard en in Config.
Install: past goedgekeurde patches toe en, voor veel besturingssystemen, herstart de machine.
Deze operaties worden doorgaans ingepland via maintenance windows met een AWS-RunPatchBaseline-document als doel (target). Voor urgente zero-day-scenario’s biedt Patch Manager Patch Now, een on-demand actie die het schema van het maintenance window omzeilt. Het aanbevolen patroon is om een beperkte patch baseline te creëren die alleen de specifieke KB of het pakket goedkeurt dat de kwetsbaarheid verhelpt, de betreffende patch group te targeten, Patch Now uit te voeren en de uitvoer van de executie te streamen naar een centrale S3-bucket en CloudWatch Logs-groep. Dat gecentraliseerde log wordt je audit-artefact — bewijs van herstel voor auditors of incident response.
Praktijkprobleem: Use-Case Scenario
Scenario: Meridian Financial beheert een multi-account AWS-omgeving met enkele honderden EC2 instances (Windows en Amazon Linux) en een klein EKS-cluster dat klantgerichte diensten ondersteunt. Ze gebruiken AWS Organizations, AWS Systems Manager voor operationele tooling en onderhouden AMI’s in een gedeeld image-account, maar hebben geen consistente geautomatiseerde vulnerability scanning of gecoördineerde patch-rollouts over de accounts heen.
Uitdaging: Een openbare CVE die OpenSSL treft, wordt gepubliceerd en Amazon Inspector rapporteert bevindingen met een verhoogde ernst (elevated findings) op meerdere instances. Het patchen is echter ongelijkmatig uitgevoerd en één productiedienst heeft een korte poging tot misbruik (exploitation) ervaren door vertraagd herstel.
Aanbevolen Aanpak:
- Schakel Amazon Inspector in voor alle accounts en regio’s om zowel image- als actieve instance-vulnerabilityscans uit te voeren, en stuur bevindingen met een hoge ernst (high-severity) door naar AWS Security Hub en een aangepaste EventBridge event bus.
- Gebruik AWS Systems Manager Inventory om de getroffen instances te identificeren en ze te taggen op basis van kriticiteit; creëer een Patch Manager-baseline die de vereiste OpenSSL-fixes bevat en richt je op Windows/Linux-regels.
- Creëer een EventBridge-regel die een SSM Automation-document activeert wanneer Inspector-bevindingen een gedefinieerde ernst bereiken, waarbij de lijst met instance-ID’s wordt doorgegeven aan een Automation runbook dat Patch Manager of Run Command aanroept om patches toe te passen en waar nodig te herstarten.
- Voor stateful of risicovolle diensten, orkestreer rolling updates met behulp van EC2 Image Builder om gepatchte AMI’s te ‘bakken’, update Auto Scaling groups of EKS node groups met een gecontroleerde blue/green of rolling deployment, en verifieer de service health met Route 53/ALB health checks.
- Voer na het herstel Amazon Inspector opnieuw uit om te valideren dat de bevindingen zijn opgelost, update de SSM Compliance-rapportage en stuur een samenvatting naar het securityteam via SNS; bewaar het Automation runbook in een Systems Manager Automation-bibliotheek voor herhaalbare, vlootbrede respons.
Rationale: Deze aanpak gebruikt Amazon Inspector voor continue ontdekking, Systems Manager Patch Manager en Automation voor gecontroleerd, geautomatiseerd herstel, en op images gebaseerde rebuilds voor immutable infrastructure, wat in lijn is met de best practices van AWS voor detectie, geautomatiseerde respons en een minimale ‘blast radius’.
# 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
Gecentraliseerde compliance wordt mogelijk gemaakt door het configureren van het delegated administrator-account in Systems Manager Explorer en het inschakelen van resource data sync om de patch-compliancestatus van elk account te aggregeren in één enkele S3-bucket, die vervolgens kan worden doorzocht met Athena of gevisualiseerd in QuickSight.
Session Manager voor Auditeerbaar Beheer
Traditionele op SSH gebaseerde toegang heeft drie structurele zwaktes: langlevend sleutelmateriaal staat op de laptops van beheerders, poort 22 moet bereikbaar zijn (ook al is het alleen via een bastion), en shell-activiteit wordt niet centraal vastgelegd zonder extra tooling. Session Manager elimineert alle drie.
Session Manager tunnelt een interactieve shell via de uitgaande HTTPS-verbinding van de SSM Agent naar de SSM-eindpunten. Er is geen inkomende poort, geen SSH-sleutelpaar en geen bastion host. Toegang wordt geautoriseerd door IAM-policies (ssm:StartSession gescoped op instance-tag of ARN), en elke sessie kan worden gelogd naar CloudWatch Logs of S3, optioneel met KMS-encryptie. Op Linux draaien sessies standaard als ssm-user; het sudo-gedrag wordt beheerd door de sudoers-configuratie van de instance, niet door IAM.
Het correcte ‘hardening’-patroon voor nieuwe vloten is: start instances zonder een EC2-sleutelpaar, koppel een instance profile met AmazonSSMManagedInstanceCore, plaats instances in private subnets met VPC-eindpunten voor ssm, ssmmessages en ec2messages, en dwing sessielogging af op het niveau van de Session Manager-voorkeuren. Het blijven distribueren van SSH-sleutels naast Session Manager is de valkuil: het behoudt precies het aanvalsoppervlak dat Session Manager juist moest elimineren, en het laat een niet-gelogd toegangskanaal open. Verwijder het provisionen van authorized_keys uit je AMI ‘bake’-proces.
Host Telemetry met de CloudWatch Agent
De unified CloudWatch agent verzamelt metrics op OS-niveau (geheugen, schijf, CPU per proces) en logbestanden die de EC2 hypervisor niet kan zien. De agent wordt geconfigureerd via een JSON-bestand dat doorgaans wordt opgeslagen in Parameter Store en vervolgens wordt toegepast met amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux.
De meest voorkomende operationele fout bij de agent is het ontbreken van IAM-permissies op het instance profile. De agent heeft minimaal het volgende nodig:
logs:CreateLogGroup (tenzij de groep vooraf is aangemaakt)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (voor custom metrics)
ssm:GetParameter (om de configuratie op te halen uit Parameter Store)
De managed policy CloudWatchAgentServerPolicy bundelt deze permissies. Wanneer permissies ontbreken, start de agent succesvol op en lijkt hij in orde in systemctl status, maar de logs komen nooit aan in CloudWatch — de fouten zijn alleen zichtbaar in /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log. Elk host-securityontwerp dat uitgaat van gecentraliseerde logs moet de aflevering valideren, niet alleen de status van de agent.
Het Totaalplaatje
De defensieve lus is als volgt: Inspector ontdekt CVE’s op hosts en container images, de bevindingen stromen naar Security Hub voor aggregatie, Patch Manager voert herstelacties uit via geplande maintenance windows of ‘Patch Now’ voor noodgevallen, Session Manager biedt de enige administratieve toegangsweg, en de CloudWatch agent streamt zowel het bewijs van patching als de runtime logs naar een gecentraliseerd account. Elke controlemaatregel veronderstelt de andere: Inspector zonder Patch Manager produceert rapporten waar niemand iets mee doet; Patch Manager zonder gecentraliseerde logging produceert geen audit trail; Session Manager zonder de juiste IAM-instellingen laat ofwel te veel ofwel te weinig toegang toe; en de CloudWatch agent zonder de correcte logpermissies creëert de illusie van zichtbaarheid.
← Governance · Alle domeinen · Container en Serverless-beveiliging →
Oefen deze vragen → · Getimede oefening op 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.
Slaag voor je examen →