Amazon SCS-C02: Container en Serverless-beveiliging — Studiegids

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Onderdeel van de AWS Security Specialty SCS-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

ECS Exec en Runtime Inspectie Zonder SSH

ECS Exec biedt een interactieve shell naar een draaiende container — inclusief Fargate-taken — zonder SSH, bastion hosts of publieke IP’s bloot te stellen. Het werkt door gebruik te maken van de SSM-agent die AWS injecteert in de sidecar-uitvoeringsomgeving van de taak. Omdat er geen SSH-daemon, geen sleutelmateriaal en geen inkomend netwerkpad is om te beveiligen, is de operationele overhead minimaal en is elke sessie auditeerbaar via CloudTrail en (optioneel) gelogd naar S3 of CloudWatch Logs.

Aan drie vereisten moet worden voldaan om ECS Exec te laten werken:

Machtigingen voor de task role: de task role (niet de execution role) heeft ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel, ssmmessages:OpenControlChannel en ssmmessages:OpenDataChannel nodig. De execution role haalt alleen images op en schrijft logs; runtime SSM-verkeer loopt via de task role omdat dat de identiteit is die het containerproces aanneemt.
Configuratie van service of taak: de service moet worden aangemaakt of bijgewerkt met --enable-execute-command. Deze vlag zet enableExecuteCommand aan voor nieuwe taken; bestaande taken moeten worden vervangen.
Ondersteuning door de container image: de container heeft een shell (/bin/sh of /bin/bash) nodig in de image.

Een typische inspectieflow ziet er als volgt uit:

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

Vanuit die shell kan een engineer logs naar S3 kopiëren, een heap dump triggeren of /proc lezen voor forensisch onderzoek. Het alternatief — proberen de container via SSH te bereiken of de taak herstarten om een debug-agent in te schakelen — mislukt op Fargate of vernietigt het bewijsmateriaal dat je probeerde te verzamelen.

IMDS-toegang Blokkeren vanaf Containers op EC2

Een veelvoorkomend misverstand is dat de IMDSv2 hop-limit-instellingen op de EC2-instance de containers op die instance beschermen. Dat doen ze niet, althans niet standaard in bridge- of host-netwerkmodus: containers delen de netwerk-namespace van de host of een NAT-bridge en kunnen 169.254.169.254 bereiken en de instance profile-credentials ophalen, die doorgaans veel meer privileges hebben dan de task role. Dat ondermijnt het ’least privilege’-principe volledig.

De oplossing, wanneer migratie naar Fargate niet mogelijk is, bestaat uit twee delen:

Gebruik de awsvpc-netwerkmodus voor taken. Elke taak krijgt zijn eigen ENI en netwerk-namespace. IMDS-verkeer bereikt niet langer transparant het link-local-eindpunt van de host.
Stel ECS_AWSVPC_BLOCK_IMDS=true in in /etc/ecs/ecs.config op de container-instance. Dit instrueert de ECS-agent om een iptables-regel te installeren die pakketten van awsvpc-taken met bestemming 169.254.169.254 weggooit.

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

Combineer dat met een minimaal instance profile (in wezen alleen wat de ECS-agent nodig heeft: AmazonEC2ContainerServiceforEC2Role) en per-taak IAM-rollen voor applicatiemachtigingen. Het instellen van de IMDS hop limit van de instance op 1 met IMDSv2 vereist is een nuttige ‘defense-in-depth’-maatregel, maar is geen vervanging — containers in bridge-modus kunnen IMDS nog steeds bereiken op hop 1 omdat het verzoek afkomstig is van de host.

GuardDuty Runtime Monitoring, EKS Protection en Control Plane Logs

GuardDuty biedt gelaagde containerdetectie:

EKS Protection analyseert EKS audit logs om verdachte Kubernetes API-activiteit te detecteren — anonieme toegang, het aanmaken van geprivilegieerde pods, exec naar systeempods.
Runtime Monitoring implementeert een op eBPF gebaseerde sensor (als een beheerde add-on voor EKS, of een door SSM beheerde agent voor ECS/Fargate) die proces-, bestands- en netwerkactiviteit binnen containers observeert. Het brengt bevindingen aan het licht zoals reverse shells, cryptomining-binaries en de exfiltratie van credentials vanuit een Pod of taak.

EKS Protection is waardeloos tenzij de auditlog van het EKS-control plane daadwerkelijk naar CloudWatch Logs wordt verzonden. Schakel ten minste de logtypes audit en authenticator in op het cluster:

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Zonder dat heeft GuardDuty geen datavlak om te inspecteren voor EKS Protection-bevindingen — een valkuil die vaak voorkomt omdat operators de GuardDuty-functie inschakelen maar de loggingconfiguratie van het cluster uit laten staan, en zich vervolgens afvragen waarom er geen Kubernetes-bevindingen verschijnen.

Image Scannen met ECR Enhanced Scanning

ECR Enhanced Scanning wordt aangedreven door Amazon Inspector en biedt continue scanning van container-images voor CVE’s in het besturingssysteem en taal-packages (Python, Node, Java, Go, Ruby). Basic scanning is eenmalig op het moment van pushen en dekt alleen OS-packages; enhanced is continu en omvat ook applicatie-afhankelijkheden, waar de meeste moderne kwetsbaarheden zich bevinden.

Bevindingen stromen automatisch naar Security Hub wanneer beide services zijn ingeschakeld, wat een ‘single pane of glass’ voor compliance biedt en je in staat stelt om EventBridge-regels te schrijven die CI/CD-builds laten mislukken. Een typisch handhavingspatroon:

Praktijkprobleem: Gebruiksscenario

Scenario: NovaTech Corp draait klantgerichte microservices in een gemengde compute-omgeving: verschillende ECS-clusters op EC2, een EKS-cluster voor dataverwerking en serverless Lambdas voor event-afhandeling. Images worden opgeslagen in ECR, voor operations wordt SSM gebruikt voor host-toegang, en GuardDuty/CloudWatch zijn ingeschakeld, maar de zichtbaarheid is ongelijk verdeeld over containers en control plane-componenten.

Uitdaging: Een productiecontainer vertoonde verdachte uitgaande verbindingen en een engineer ontdekte dat een pod de EC2 instance metadata service kon bereiken, wat het risico op exfiltratie van credentials met zich meebrengt. Kwetsbaarheden in images en onvoldoende logging van het control plane verbergen mogelijk de hoofdoorzaak.

Aanbevolen Aanpak:

Schakel ECS Exec in voor tasks en vereis AWS Systems Manager Session Manager voor inspectie van de host en container runtime (ECS Exec + SSM), waardoor SSH overbodig wordt en wordt gegarandeerd dat sessie-activiteit wordt gelogd naar CloudTrail en CloudWatch Logs.
Dwing IMDSv2 af op EC2 instances (Instance Metadata Service HttpTokens=required, hop limit=1) en pas netwerkregels op host-niveau toe om 169.254.169.254 te blokkeren vanuit de container network namespaces, zodat containers de instance metadata niet kunnen opvragen.
Activeer Amazon GuardDuty runtime monitoring en Malware Protection voor containers en Lambda, stuur bevindingen door naar Security Hub en EventBridge voor geautomatiseerde containment playbooks.
Verhard EKS door control plane logs (audit, authenticator, controllerManager, scheduler) in te schakelen naar CloudWatch Logs, gebruik IAM Roles for Service Accounts (IRSA) en dwing admission controls af (Pod Security of OPA Gatekeeper) om riskante capabilities te beperken.
Activeer Amazon ECR enhanced image scanning (Inspector/ECR scanning) met scan-on-push en integreer de bevindingen in de CI om images te blokkeren of in quarantaine te plaatsen via EventBridge + Lambda voor handhaving.
Centraliseer telemetrie: stuur CloudTrail, GuardDuty-bevindingen, EKS control plane logs en ECR-scanresultaten naar een gecentraliseerde S3/Lambda/Security Hub pipeline en voed AWS Config rules voor continue compliance.

Rationale: Deze aanpak verwijdert op SSH gebaseerde toegang, voorkomt diefstal van metadata credentials, biedt runtime detectie en geautomatiseerde respons, dwingt image-hygiëne af en levert zichtbaarheid op het control plane — in lijn met de AWS best practices van least privilege, defense in depth en gecentraliseerde observability.

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

Integratie in de pipeline is wat scannen transformeert van een dashboard-oefening naar een daadwerkelijk controlemechanisme.

Lambda: Authorizers, Secrets en Execution Roles

Beveiliging op het niveau van een Lambda-functie heeft drie vlakken die vaak door elkaar worden gehaald:

Resource policy (function policy): bepaalt welke principals (API Gateway, EventBridge, andere accounts) de functie kunnen aanroepen. Lambda Authorizers op API Gateway zijn de identiteitspoort voor HTTP-callers — ze retourneren een IAM-policy die API Gateway cachet en afdwingt voordat de backend-functie wordt aangeroepen.
Execution role: de identiteit die de functiecode tijdens runtime aanneemt. De trust policy moet lambda.amazonaws.com bevatten, en het moet logs:CreateLogGroup, logs:CreateLogStream en logs:PutLogEvents toekennen om CloudWatch Logs te laten werken. Als logs ontbreken, is de oplossing bijna altijd de execution role — niet de Lambda-console, die slechts weergeeft welke logs CloudWatch heeft ontvangen. Alleen vertrouwen op ‘console logs’ is een diagnostische valkuil: geen permissie in de execution role betekent geen log stream, en de console toont niets.
Ophalen van secrets: bak nooit credentials in platte tekst in omgevingsvariabelen. Sla ze op in Secrets Manager of SSM Parameter Store SecureString en haal ze op bij een cold start:

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

De execution role heeft ssm:GetParameter en kms:Decrypt nodig op de CMK. Cache in de module scope zodat warme aanroepen de API-call vermijden; gebruik de Secrets Manager Lambda-extensie voor automatische, rotatie-bewuste caching in functies met een hogere doorvoer.

ECR Encryptie en Repository-bescherming

Amazon ECR versleutelt standaard alle images at rest met AES-256 met een door AWS beheerde sleutel, maar gereguleerde workloads vereisen doorgaans een door de klant beheerde KMS-sleutel (customer-managed KMS key), zodat sleutelrotatie, key policies en auditeerbaarheid via CloudTrail onder de controle van de klant vallen. KMS-encryptie wordt alleen geconfigureerd op het moment dat de repository wordt aangemaakt; een bestaande ECR-repository kan achteraf niet worden omgezet van AES-256 naar KMS. Migratie vereist daarom het aanmaken van een nieuwe, met KMS versleutelde repository, het repliceren of opnieuw pushen van de images, het bijwerken van downstream consumers en het verwijderen van de oude repository. Cross-account consumers die pullen vanuit een met KMS versleutelde repository moeten, naast ECR-leesrechten, ook kms:Decrypt-rechten krijgen op de CMK, anders zal de pull mislukken met een KMS-toegangsfout, zelfs als de repository policy de principal toestaat.

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

Immutable tags voorkomen tag-hijack-aanvallen waarbij een gevalideerde v1.2.3-tag na het scannen stilzwijgend wordt overschreven door een kwaadaardige image.

Image Scanning: Basic, Enhanced en Inspector

ECR biedt twee scanmodi. Basic scanning maakt gebruik van de open-source Clair CVE-database, wordt alleen uitgevoerd bij een push (of handmatige aanroep) en retourneert bevindingen in de ECR-console. Het is gratis, maar voert geen continue herscans uit, dekt niet tegelijkertijd OS- en programmeertaalpakketten, en heeft geen native integratie met Security Hub. Enhanced scanning wordt aangedreven door Amazon Inspector en dekt zowel pakketten van het besturingssysteem als van applicatietalen (Python, Java, Node.js, Go, Ruby, .NET). Inspector monitort gepushte images continu aan de hand van bijgewerkte kwetsbaarheidsinformatie, zodat een CVE die een week na het pushen van de image wordt onthuld, nog steeds een bevinding oplevert zonder een nieuwe build.

Enhanced scanning wordt ingeschakeld op registry-niveau (per regio), met inclusiefilters per repository die wildcard-patronen gebruiken zoals prod-* of team-a/*. Dit is de juiste controle voor de veelvoorkomende eis om “de meeste repositories te scannen maar sandbox/experimentele repositories uit te sluiten” — je definieert positieve filters die aangeven wat gescand moet worden in plaats van negatieve uitsluitingen op individuele repo’s.

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Inspector-integratie en Security Hub-aggregatie

Amazon Inspector moet worden ingeschakeld in elke account en regio waar scannen vereist is. In een AWS Organizations-setup wordt de security tooling-account aangewezen als de gedelegeerde beheerder voor Inspector, wat het mogelijk maakt om scannen in te schakelen, auto-enroll in te stellen voor nieuwe member-accounts en geaggregeerde bevindingen te bekijken. Het vergeten te delegeren — of het vergeten om auto-enroll in te schakelen — is een subtiele faalmodus: nieuwe accounts die lid worden van de organisatie, leveren stilzwijgend containers aan ECR die nooit worden gescand, waardoor de dekkingsgaranties worden geschonden zonder dat er een foutmelding verschijnt.

Bevindingen van Inspector stromen automatisch naar AWS Security Hub wanneer beide services zijn ingeschakeld en de Inspector-integratie van Security Hub is aangezet. Security Hub normaliseert vervolgens de bevindingen naar het AWS Security Finding Format (ASFF), correleert ze met bevindingen van GuardDuty, Macie en Config, en presenteert — in combinatie met een gedelegeerde Security Hub-beheerder plus cross-region aggregatie — een ‘single pane of glass’. EventBridge-regels op Security Hub-bevindingen kunnen kritieke CVE’s doorsturen naar Lambda voor het geautomatiseerd aanmaken van tickets, de betreffende image taggen met een quarantine=true-label, of de implementatie blokkeren via een pipeline-gate.

Gecentraliseerd scannen en cross-account CI/CD

Het aanbevolen patroon voor container-workloads in meerdere accounts plaatst een verharde centrale registry-account in de kern:

Centrale account: host KMS-versleutelde ECR-repositories met enhanced scanning, onveranderlijke (immutable) tags en image signing (via Notation/Sigstore geïntegreerd met AWS Signer).
Build-accounts: voeren CodeBuild/CodePipeline-jobs uit die bouwen, pushen naar de centrale ECR, wachten op Inspector-bevindingen en de doorgang blokkeren op basis van drempelwaarden voor de ernst (severity).
Workload-accounts (dev/stage/prod): pullen images uit de centrale registry via cross-account permissies.

Voor cross-account leestoegang zijn twee lagen vereist: een IAM-policy in de consumerende account die ecr:GetDownloadUrlForLayer, ecr:BatchGetImage en ecr:GetAuthorizationToken toekent, plus een repository policy op de ECR-repo in de centrale account die de specifieke consumer-account of -rol toestaat.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

Omdat ECR repository policies resource-based zijn, bepaalt de doorsnede van de identity- en resource-policy de toegang — het weglaten van een van beide lagen leidt tot een AccessDeniedException. Wanneer KMS wordt gebruikt, moet de KMS key policy ook kms:Decrypt toekennen aan de cross-account principal.

EKS Control Plane Logging en Observability

Bij EKS is de managed control plane niet direct toegankelijk, dus beveiligingsrelevante Kubernetes-events worden alleen beschikbaar gesteld wanneer control plane logging expliciet is ingeschakeld. Er zijn vijf logtypes beschikbaar: api, audit, authenticator, controllerManager en scheduler. Het audit-log is het meest waardevolle beveiligingsartefact — het registreert elke API-aanroep naar het cluster, waarbij de identiteit van de aanroeper wordt achterhaald via de IAM-authenticator — en authenticator registreert de beslissingen over de mapping van IAM naar Kubernetes RBAC. Alle types streamen naar CloudWatch Logs in een /aws/eks/<cluster>/cluster log-groep, van waaruit ze kunnen worden geabonneerd op Kinesis Data Firehose, doorgestuurd naar S3, of verzonden naar een SIEM.

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

Vul de control plane-logs aan met GuardDuty EKS Protection (runtime threat detection op nodes), en gebruik IRSA (IAM Roles for Service Accounts) in plaats van node instance profiles, zodat audit-logs AWS API-activiteit toeschrijven aan specifieke pods.

Veelvoorkomende Valkuilen

Alleen vertrouwen op scan-on-push: Basis scan-on-push detecteert kwetsbaarheden die bekend zijn op het moment van pushen, maar doet niets aan CVE’s die later worden onthuld voor images die al in de registry staan. Audit-frameworks zoals PCI DSS en FedRAMP vereisen een doorlopende kwetsbaarheidsbeoordeling, wat ’enhanced scanning’ met een CONTINUOUS_SCAN-frequentie plus Security Hub-aggregatie verplicht stelt. Een momentopname per push voldoet niet aan deze controle.

KMS overslaan op ECR wanneer encryptie-at-rest vereist is: De standaard AES-256-encryptie is echte encryptie, maar compliance-regimes die door de klant beheerde sleutels (customer-managed keys), registraties van sleutelrotatie en audittrails per principal voor kms:Decrypt vereisen, kunnen niet worden vervuld met door AWS beheerde sleutels (AWS-owned keys). Omdat het encryptietype onveranderlijk is per repository, moet dit bij het aanmaken worden ingesteld; “we zetten het later wel aan” is onmogelijk zonder de repository opnieuw aan te maken.

Vergeten van Inspector delegated admin of auto-enroll: Zonder een delegated administrator voor Inspector moet elke accounteigenaar onafhankelijk het scannen inschakelen en bevindingen doorsturen, wat operationeel onhaalbaar is en leidt tot hiaten in de dekking. Zonder auto-enable voor nieuwe member accounts start elk nieuw account dat via Control Tower of Organizations wordt aangemaakt met Inspector uitgeschakeld, waardoor de ECR-images ervan niet worden gescand, ook al toont Security Hub in het centrale account geen bevindingen — een stille ‘false-negative’ in plaats van een duidelijke fout.

Praktijkprobleem: Use-Case Scenario

Scenario: Meridian Financial beheert een multi-account AWS-omgeving met productie EKS-clusters, ECS-services en meerdere ECR-registries verspreid over prod-, dev- en een speciaal security-account. Hun engineeringteams pushen container-images via CI/CD-pipelines naar ECR en deployen naar EKS/ECS, terwijl security een gecentraliseerd account onderhoudt voor monitoring en compliance.

Uitdaging: Een recente deployment leverde een container op met een kwetsbaarheid met een hoge ernstigheidsgraad die niet vóór productie werd gedetecteerd. Onderzoekers vonden beperkte EKS control plane-logs en gefragmenteerde scanresultaten verspreid over accounts, wat de herstelacties vertraagde.

Aanbevolen Aanpak:

Activeer beveiligingen op ECR-repositoryniveau: dwing onveranderlijkheid van image-tags (immutability) af, pas repository-beleid toe dat push/pull beperkt tot specifieke IAM-rollen, en versleutel repositories-at-rest met een speciale AWS KMS customer managed key (CMK).
Schakel image scanning on push (basic) in en activeer Amazon Inspector enhanced image scanning voor ECR om kwetsbaarheidsbevindingen te genereren; integreer Inspector met AWS Security Hub voor gecentraliseerde aggregatie van ernstigheidsgraden over alle accounts.
Implementeer gecentraliseerd cross-account scannen: configureer ECR-replicatie of geef een CodeBuild/CodePipeline-rol in het security-account cross-account pull-permissies, zodat het security-account elke image scant met Inspector en eventuele extra SCA/DAST-tools. Sla de artefacten op in een gecentraliseerde S3-bucket die is versleuteld met de CMK van het security-account.
Dwing CI/CD-gating af: voeg een scan-stap toe aan de pipeline (CodeBuild/CodePipeline of GitHub Actions met STS assume-role) die de bevindingen van Inspector/Security Hub opvraagt en images met hoge/kritieke bevindingen automatisch blokkeert of goedkeuring vereist.
Verbeter de EKS-observeerbaarheid: schakel EKS control plane-logs (API, Audit, Authenticator, ControllerManager, Scheduler) in naar CloudWatch Logs in een gecentraliseerd logging-account, activeer CloudTrail voor EKS API-events en gebruik Container Insights en GuardDuty voor runtime monitoring.

Rationale: Deze aanpak past ‘defense-in-depth’ toe: het versleutelen en beveiligen van registries, het automatiseren van enhanced scanning met Inspector, het centraliseren van bevindingen in Security Hub voor consistente beleidshandhaving, het toepassen van gating op deployments in CI/CD, en het inschakelen van EKS control plane-logs voor snelle detectie en forensisch onderzoek. Dit sluit aan bij de AWS best practices voor ’least-privilege’ en gecentraliseerde monitoring.

← Kwetsbaarheden · Alle domeinen · Incidentrespons en Forensics →

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 →

Blader door Amazon →