Amazon SCS-C02: Incidentrespons en Forensics — 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.

Isolatie van gecompromitteerde EC2 Instances

Het eerste operationele doel wanneer een EC2 instance wordt verdacht van compromittering is inperking zonder vernietiging van bewijsmateriaal. Inperking op AWS is een gelaagde activiteit die betrekking heeft op de netwerkblootstelling van de instance, de levenscycluskoppelingen en de toegankelijkheid voor responders.

De standaard isolatieprocedure begint met het aanscherpen van de security group van de instance. Omdat elke instance idealiter zijn eigen, toegewijde security group heeft, kunt u de ingress- en egress-regels vervangen door een minimale set die alleen het forensisch team (of een speciale diagnostische security group) toestaat om de instance te bereiken. Als de instance zich achter een Application Load Balancer of in een target group bevindt, deregistreer deze dan eerst; als het lid is van een Auto Scaling group, koppel deze dan los met de --should-decrement-desired-capacity vlag, zodat de ASG niet onmiddellijk een vervanging start of, erger nog, de “ongezonde” instance midden in het onderzoek beëindigt.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

Het inschakelen van termination protection is essentieel omdat een goedbedoelende operator, een automatiseringsscript of een ASG scale-in-gebeurtenis anders de volumes die u probeert te bewaren, kan vernietigen. Termination protection is geen vervanging voor het loskoppelen van de ASG — een ASG kan nog steeds beschermde instances beëindigen tijdens een scale-in, tenzij u de instance ook uit de scope van de groep verwijdert.

Voor inperking op subnetniveau wanneer u onmiddellijke afsluiting van uitgaand verkeer nodig heeft (bijvoorbeeld een instance die ‘beaconing’ uitvoert naar bekende kwaadaardige IP’s), kunt u een expliciete ‘deny-all’ uitgaande regel toevoegen aan de network ACL van het subnet als de regel met het laagste nummer. Dit is stateless en wordt onmiddellijk van kracht op alle flows, in tegenstelling tot wijzigingen in security groups die alleen van invloed zijn op nieuwe flows. Zodra uw forensische toegangspad is ingesteld via een diagnostische SG, kan de NACL-deny-regel worden verwijderd zodat het responder-subnet het doel kan bereiken via de SG-allow-list.

Bewaren van vluchtig en niet-vluchtig bewijsmateriaal

Vluchtig bewijsmateriaal — proceslijsten, open netwerksockets, geladen kernelmodules, geheugeninhoud, tmpfs-inhoud — wordt vernietigd op het moment dat de instance stopt. Niet-vluchtig bewijsmateriaal bevindt zich op EBS en overleeft een stop/start, maar kan alsnog verloren gaan als volumes worden losgekoppeld of de instance wordt beëindigd zonder snapshots. De vuistregel voor de volgorde is: verzamel eerst vluchtige artefacten terwijl de instance nog draait, maak daarna snapshots van EBS.

Het verzamelen van vluchtig materiaal moet worden gescript en uitgevoerd via SSM Run Command in plaats van door een mens die in een interactieve shell typt. Run Command legt de aanroep, de parameters, de uitvoerende principal en de output vast in CloudWatch Logs of S3, wat zelf onderdeel wordt van de chain-of-custody-documentatie.

Praktijkprobleem: Use-Case Scenario

Scenario: Meridian Financial draait zijn klantgerichte webapplicaties in één AWS-account verspreid over meerdere VPC’s, met gebruik van Auto Scaling groups achter Application Load Balancers, EC2 instances met EBS, gecentraliseerde CloudTrail- en CloudWatch-logging, GuardDuty en een op S3 gebaseerd logboekarchief dat is versleuteld met KMS. Het security operations team gebruikt AWS Systems Manager voor beheer op afstand en slaat back-ups en snapshots op in een speciaal recovery-account.

Uitdaging: Eén productie-EC2-instance vertoont tekenen van compromittering met verdacht uitgaand verkeer en onverwachte procesactiviteit; het team moet de instance isoleren en zowel vluchtig geheugen- als niet-vluchtig schijfbewijs veiligstellen voor forensische analyse, zonder audittrails te vernietigen.

Aanbevolen aanpak:

1. Gebruik de Auto Scaling- en ELB-API’s om de instance los te koppelen van target groups en Auto Scaling-processen op te schorten. Pas vervolgens een restrictieve Security Group toe (deny all inbound/outbound) en update de Network ACL-regels van de instance om de netwerktoegang te isoleren, met behoud van beheer via AWS Systems Manager Session Manager.
2. Gebruik AWS Systems Manager Run Command om een in-guest geheugencapture (bijv. LiME) uit te voeren die de RAM-dump wegschrijft naar een aangekoppeld, versleuteld EBS-volume of rechtstreeks naar een S3-bucket die is versleuteld met SSE-KMS en waarvoor S3 Object Lock is ingeschakeld voor retentie.
3. Gebruik EC2 CreateSnapshot (of CreateImage) om point-in-time EBS-snapshots van alle aangekoppelde volumes vast te leggen. Kopieer deze snapshots vervolgens naar een apart AWS-account of een andere regio om de chain-of-custody te waarborgen en manipulatie te voorkomen.
4. Schakel VPC Traffic Mirroring in of haal deze op voor de ENI van de instance om packet captures te verzamelen naar een speciale monitoring EC2. Exporteer tegelijkertijd VPC Flow Logs, ELB access logs, CloudTrail, CloudWatch Logs en GuardDuty-bevindingen naar het beveiligde S3-archief.
5. Tag en inventariseer alle verzamelde artefacten in AWS Security Hub of een ticketingsysteem, zorg ervoor dat S3-objecten versleuteld zijn en Object Lock is ingesteld, en beperk de IAM-toegang tot een klein forensisch team, terwijl alle toegang wordt gelogd via CloudTrail.

Redenering: Het isoleren van de netwerktoegang voordat images worden gemaakt, voorkomt verdere besmetting, terwijl het gebruik van SSM het openen van nieuwe netwerkvectoren vermijdt. Het eerst vastleggen van vluchtig geheugen en het creëren van onveranderlijke EBS-snapshots en beveiligde S3-archieven waarborgt de integriteit van het bewijsmateriaal en de chain-of-custody, in lijn met de best practices voor incident response van AWS.

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

Maak onmiddellijk na het vastleggen van de vluchtige data een snapshot van elk aangekoppeld EBS-volume. Tag de snapshots met de incident-ID zodat ze ondubbelzinnig aan de zaak gekoppeld zijn.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

Tag de instance zelf met hetzelfde incidentticket, de naam van de onderzoeker en een statuslabel zoals Quarantine. Consistente metadatatagging is het AWS-native mechanisme voor chain-of-custody — het is opvraagbaar, onveranderlijk te maken via IAM condition keys en verschijnt in elke CloudTrail-gebeurtenis die betrekking heeft op de resource.

Live Response met Session Manager en Run Command

Een subtiel maar voor het examen cruciaal punt: bestaande SSH-sessies overleven het verwijderen van security group-regels. Security groups zijn stateful en evalueren regels bij het opzetten van de verbinding; een reeds tot stand gebrachte TCP-sessie blijft doorlopen, zelfs nadat de ingress-regel die deze toestond, is verwijderd. Als een responder een instance isoleert door SG-regels te verwijderen terwijl hij voor toegang afhankelijk is van zijn eigen SSH-sessie, werkt die sessie — totdat deze wegvalt, waarna hij buitengesloten is en elke hernieuwde toegang via een bastion of met een key onmogelijk is.

Het correcte patroon is om het forensische team toegang te verlenen via SSM Session Manager, waarvoor geen enkele inkomende poort open hoeft te staan. Session Manager werkt via de uitgaande verbinding van de SSM Agent naar de SSM-, EC2 Messages- en SSM Messages-endpoints (idealiter via VPC interface endpoints, zodat de geïsoleerde instance geen internetroute nodig heeft). Koppel een instance profile dat ssm:UpdateInstanceInformation en de messages-API’s toestaat, en geef responders ssm:StartSession met een scope op basis van een tag voor de in quarantaine geplaatste instance.

Omdat Session Manager-sessies worden bemiddeld door het SSM-control plane, worden ze niet verstoord door het aanscherpen of volledig leegmaken van de ingress van de security group. Elke toetsaanslag kan worden gelogd naar S3 of CloudWatch Logs — een auditeerbare interactieve sessie, geen black box.

Cross-Account Herstel van Versleutelde Snapshots

Volwassen omgevingen routeren forensische snapshots naar een speciaal forensisch account, dat geïsoleerd is van het gecompromitteerde workload-account. Het delen van snapshots tussen accounts vereist twee dingen: de snapshot moet worden gedeeld met het doelaccount (modify-snapshot-attribute --create-volume-permission), en als de snapshot is versleuteld met een customer-managed KMS key, moet de KMS key policy de principals van het forensische account de permissies kms:Decrypt, kms:CreateGrant en kms:DescribeKey verlenen. Snapshots die zijn versleuteld met de door AWS beheerde aws/ebs-key kunnen niet cross-account worden gedeeld — je moet ze eerst opnieuw versleutelen met een CMK via een kopieeractie. Kopieer in het forensische account de gedeelde snapshot en versleutel deze opnieuw met een lokale forensische CMK, zodat het aanmaken van volumes daarna niet afhankelijk is van het bronaccount.

Playbook-ontwerp en Minimaliseren van Overhead

Codificeer de containment-stappen als een SSM Automation-document of een Step Functions-workflow die wordt getriggerd door bevindingen van GuardDuty of Security Hub via EventBridge. Eén enkele automatisering moet: (1) vluchtige data vastleggen via Run Command, (2) volumes snapshotten met incident-tags, (3) termination protection inschakelen, (4) loskoppelen van de ASG en uitschrijven bij ELB-targets, (5) de SG vervangen door de quarantaine-SG, en (6) de instance taggen met het ticket-ID. Door de instance draaiende te houden, blijft live bewijsmateriaal bewaard en is interactief onderzoek via Session Manager mogelijk. Uitschakelen moet een bewuste latere stap zijn, geen onderdeel van automatische containment, omdat een shutdown vluchtig bewijsmateriaal wist en opruimlogica in malware kan triggeren.

De valkuilen om te onthouden: het verwijderen van SG-regels terwijl je vertrouwt op een bestaande SSH-sessie maakt de responder blind en geeft een vals gevoel van isolatie; het uitvoeren van in-place herstel voordat er een snapshot is gemaakt, vernietigt de artefacten die antwoord geven op hoe de inbraak heeft plaatsgevonden; en het in de ASG of target group laten van de instance lokt geautomatiseerde terminatie uit of, erger nog, een stille vervanging die de omvang van het incident verbergt.

Onmiddellijke Containment

Wanneer een workload wordt verdacht van compromittering, is de eerste beslissing of deze ter plaatse moet worden geïsoleerd of buiten gebruik moet worden gesteld. Het buiten gebruik stellen — stoppen of termineren — vernietigt vluchtig bewijsmateriaal zoals RAM-inhoud, actieve processen, open sockets en malware die alleen in het geheugen leeft. Containment ter plaatse is bijna altijd de juiste eerste stap, en het moet snel genoeg gebeuren zodat een aanvaller geen extra data kan exfiltreren of lateraal kan bewegen voordat de maatregelen effect hebben.

Twee AWS-native controls werken op verschillende lagen, en het onderscheid is belangrijk. Security groups zijn stateful en gekoppeld aan elastic network interfaces (ENI’s); network ACL’s (NACL’s) zijn stateless en gekoppeld aan subnets. Het vervangen van de security groups van een instance door een afgesloten ‘quarantaine’-SG is de chirurgische aanpak — het isoleert één ENI zonder andere workloads in hetzelfde subnet te storen en behoudt de runtime-status van de instance. Wijzigingen in security groups hebben echter alleen invloed op nieuwe datastromen die de ENI bereiken. Als de gecompromitteerde instance al langdurige uitgaande verbindingen heeft, kan de bestaande status blijven bestaan. NACL deny-regels worden onmiddellijk van kracht op de subnetgrens en kunnen het verkeer nog sneller stilleggen wanneer snelheid belangrijker is dan chirurgische precisie — bijvoorbeeld wanneer meerdere instances in hetzelfde subnet betrokken zijn, of wanneer de actieve sessie van een aanvaller onmiddellijk moet worden verbroken. NACL’s zijn ook nuttig wanneer beleid het direct aanpassen van een instance verhindert.

De canonieke quarantaine-SG staat geen inkomend verkeer toe en uitgaand verkeer alleen naar VPC interface endpoints voor com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages en com.amazonaws.<region>.ec2messages. Dit behoudt de toegang via Systems Manager Session Manager, terwijl C2-kanalen, data-exfiltratie en laterale bewegingen worden geblokkeerd.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

Volgorde voor bewijsbehoud

De forensische waarde neemt af van meest naar minst vluchtig, dus de volgorde van handelingen is vast en niet-onderhandelbaar:

• Schakel eerst termination protection in. Het instellen van DisableApiTermination=true voorkomt dat een Auto Scaling-gebeurtenis, een fout van een operator of een geplande actie de instance vernietigt tijdens het onderzoek. Koppel de instance ook los van zijn Auto Scaling-groep, zodat ASG health checks deze niet kunnen vervangen.

• Koppel los of bescherm tegen Auto Scaling. Gebruik EnterStandby of koppel de instance los, zodat de ASG deze niet als ‘unhealthy’ beëindigt.

• Maak een snapshot van elk gekoppeld EBS-volume. CreateSnapshot (of CreateSnapshots voor een atomaire vastlegging van meerdere volumes) produceert een onveranderlijk, versleuteld forensisch artefact. Tag snapshots met de incident-ID, de ID van de bron-instance, een timestamp en de analist. Kopieer snapshots naar een speciaal forensisch account dat eigendom is van het securityteam, zodat ze een compromittering van het account overleven.

• Leg het geheugen vast. Gebruik een SSM RunCommand-document om een tool voor geheugenacquisitie aan te roepen (LiME, AVML op Linux; WinPMEM op Windows) en stream de image naar een forensische S3-bucket met Object Lock in compliance mode. Het geheugen moet worden vastgelegd terwijl de instance nog draait — een gestopte instance heeft geen RAM om vast te leggen.

• Verzamel metadata. Noteer de instance-ID, AMI, IAM instance profile, VPC/subnet, ENI-ID’s, tags, de lijst met draaiende processen, netstat-output en de inhoud van de IMDS. Tag de instance met Status=Quarantined en IncidentId=<id>, zodat downstream automatisering en menselijke operators de status ervan herkennen.

• Stop de instance pas daarna als het onderzoek offline schijfanalyse vereist. Stoppen wist het geheugen, dus dit is altijd de laatste stap.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

Geautomatiseerde IR-workflows

Bevindingen van GuardDuty moeten binnen seconden, niet uren, leiden tot isolatie (containment). De canonieke pipeline is EventBridge → Lambda → SSM Automation, met SNS voor notificaties.

Een EventBridge-regel matcht op source: aws.guardduty met een detail-type GuardDuty Finding en een patroon dat filtert op EC2-relevante bevindingstypes zoals UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/* en CryptoCurrency:EC2/*.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

De Lambda-target extraheert de instance-ID uit detail.resource.instanceDetails.instanceId en roept vervolgens een SSM Automation-document aan (of roept direct de SDK aan) om: termination protection in te schakelen, de ENI security groups te vervangen door de quarantaine-SG via ModifyNetworkInterfaceAttribute, snapshots te maken van alle gekoppelde volumes, de instance te taggen en een SNS-bericht te publiceren naar het SOC-kanaal. Het gebruik van SSM Automation in plaats van rechtstreekse SDK-aanroepen zorgt voor stapsgewijze audittrails in de uitvoeringsgeschiedenis van Automation.

Logging voor analyse van exfiltratie en C2

Isolatie zonder telemetrie is giswerk. VPC Flow Logs moeten zijn ingeschakeld op VPC- of subnetniveau, met het verkeerstype ingesteld op ALL (zowel ACCEPT als REJECT). REJECT-records onthullen scans, geblokkeerde exfiltratiepogingen en C2-beacons die proberen bekende kwaadaardige IP’s te bereiken; ACCEPT-records tonen welke flows wel zijn geslaagd. Stuur flow logs door naar CloudWatch Logs voor real-time query’s en naar S3 voor langetermijnbewaring met Object Lock. CloudTrail met data events op de forensische S3-bucket en KMS levert de audit trail voor de bewijsketen (chain of custody). Combineer dit met DNS query logging (Route 53 Resolver) om DGA en DNS-tunneling te detecteren, die met alleen flow logs gemist zouden worden.

Gecontroleerde forensische toegang via Session Manager

Session Manager elimineert de noodzaak voor SSH-sleutels, bastion hosts of een open poort 22/3389, wat precies de reden is waarom de quarantaine-SG alle traditionele toegang kan blokkeren. Schakel sessielogging in naar een S3-bucket met SSE-KMS en naar CloudWatch Logs; dwing EnforceEncryption=true af in de sessievoorkeuren, zodat geen enkele sessie zonder TLS en logversleuteling wordt uitgevoerd. IAM-policies voor ssm:StartSession moeten worden beperkt tot instances met de tag Status=Quarantined en alleen worden toegekend aan de incident response-rol.

Veelvoorkomende valkuilen en waarom ze mislukken

• Eerst stoppen of beëindigen. Stoppen geeft geheugen vrij, verbreekt actieve verbindingen en elimineert de mogelijkheid om vluchtige artefacten vast te leggen. Beëindigen geeft bovendien het root-volume vrij, tenzij DeleteOnTermination=false is ingesteld, en zelfs dan verlies je de runtime-status. Isoleer altijd ter plaatse voordat je de stroomstatus wijzigt.

• Alleen vertrouwen op security groups terwijl NACL’s sneller zijn. SG-wijzigingen zijn chirurgisch, maar hebben alleen invloed op de ENI waaraan ze zijn gekoppeld en regelen alleen nieuwe datastromen. Wanneer meerdere instances in een subnet betrokken zijn, of wanneer een bestaande uitgaande sessie van een aanvaller onmiddellijk moet worden verbroken, sluit een NACL deny-regel op subnetniveau de deur sneller, omdat NACL’s stateless zijn en elk pakket blokkeren, ongeacht de eerdere status.

• Herstellen voordat er een snapshot wordt gemaakt. Het opnieuw imagen, patchen of vervangen van de instance voordat EBS-snapshots worden gemaakt, vernietigt het bewijsmateriaal op de schijf - malware-binaries, persistentie-mechanismen, logs, timestamps. Snapshots zijn goedkoop en onveranderlijk (immutable); maak ze voordat je herstelacties uitvoert en kopieer ze naar een speciaal forensisch account, zodat een gecompromitteerd productieaccount ze niet kan verwijderen.

Praktijkprobleem: Use-Case Scenario

Scenario: Meridian Financial beheert een multi-account AWS-omgeving met productieworkloads in een speciaal account: EC2- en EKS-services die klantgegevens hosten, S3-buckets voor archieven, gecentraliseerde logging in een security-account met CloudTrail, GuardDuty, Security Hub en Config ingeschakeld, en een CI/CD-pipeline voor implementaties. Hun operations-team gebruikt Systems Manager voor patching en onderhoud en Route 53/ALB’s voor publieke endpoints.

Uitdaging: Een GuardDuty-bevinding en onverwachte pieken in uitgaand verkeer duiden op een waarschijnlijk gecompromitteerde EC2-instance die zich bezighoudt met data-exfiltratie en verdachte IAM API-aanroepen. Dit vereist onmiddellijke isolatie (containment) met behoud van forensisch bewijsmateriaal en het waarborgen van auditeerbare toegang voor onderzoekers.

Aanbevolen aanpak:

1. Activeer onmiddellijke isolatie via EventBridge op basis van de GuardDuty-bevinding om een Step Functions-workflow aan te roepen die een Lambda/SSM Automation gebruikt om een quarantaine-security group te koppelen, publieke IP’s te verwijderen of de ENI los te koppelen, en de betrokken IAM-credentials in te trekken/te rouleren via IAM.
2. Behoud vluchtig en persistent bewijsmateriaal door een SSM Automation-document uit te voeren om een EBS-snapshot en AMI van de instance te maken, snapshots te kopiëren naar een speciaal forensisch AWS-account en geëxporteerde artefacten op te slaan in een S3-bucket met S3 Object Lock (compliance-modus) en KMS-encryptie.
3. Leg logging vast voor analyse van exfiltratie en C2 door ervoor te zorgen dat CloudTrail management- en data-events (S3, Lambda) zijn ingeschakeld, VPC Flow Logs, ALB/NGINX access logs en Route 53 query logs door te sturen naar het centrale security-account, en de bevinding te escaleren naar Amazon Detective voor tijdlijncorrelatie.
4. Automatiseer de orkestratie en meldingen met behulp van EventBridge -> Step Functions -> Lambda om de isolatie, het kopiëren van bewijsmateriaal, SNS-meldingen naar incident-eigenaren en het aanmaken van tickets in het bestaande ITSM-systeem te coördineren.
5. Bied gecontroleerde forensische toegang door AWS Systems Manager Session Manager te vereisen voor live onderzoekssessies, met sessielogging naar CloudWatch Logs en de forensische S3-bucket. Toegang is alleen toegestaan voor een specifieke forensische IAM-rol met MFA en tijdelijke credentials.

Rationale: Deze aanpak isoleert de dreiging snel, bewaart onveranderlijke (immutable) artefacten en gecentraliseerde logs voor analyse, automatiseert herhaalbare responsstappen om de ’time-to-contain’ te verkorten, en dwingt auditeerbare, least-privilege forensische toegang af via Session Manager volgens de best practices van AWS.

← Container en Serverless-beveiliging · Alle domeinen

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Amazon →