Als u betalingsworkloads uitvoert op cloudinfrastructuur en uw QSA (Qualified Security Assessor) is gepland voor 2026, kent u het gevoel al: een spreadsheet vol controles, een stack die nooit is ontworpen met PCI DSS in gedachten, en een deadline die niet verschuift. PCI DSS 4.0.1 werd volledig verplicht in maart 2025, waarmee versie 3.2.1 volledig werd vervangen. De veranderingen zijn niet cosmetisch. Striktere penetratietest-tijdlijnen, een nieuwe 30-dagenregel voor kritieke patches, strengere log-retentievereisten en uitgebreide Web Application Firewall (WAF) verplichtingen hebben meer dan een paar engineeringteams verrast.
Deze gids leidt CTO's, DevSecOps-ingenieurs en IT-managers door elke cloudinfrastructuurcontrole die direct invloed heeft op PCI DSS 4.0.1-naleving: firewalls, WAF-configuratie, netwerksegmentatie, geautomatiseerde back-ups, kwetsbaarheidsscans en de gedeelde-verantwoordelijkheidsgrens tussen u en uw cloudprovider.
Belangrijke Punten
- PCI DSS 4.0.1 is volledig verplicht sinds maart 2025. Versie 3.2.1 wordt niet langer geaccepteerd.
- WAF-implementatie voor alle publiek toegankelijke webapplicaties is nu een expliciete harde eis onder Vereiste 6.4.2.
- Kritieke kwetsbaarheden (CVSS 9.0+) moeten binnen 30 dagen worden gepatcht; hoog-ernstige (CVSS 7.0-8.9) binnen 90 dagen.
- Auditlogs moeten 12 maanden worden bewaard, met ten minste 3 maanden direct opvraagbaar zonder hersteloperatie.
- Netwerksegmentatie is niet verplicht, maar is de meest effectieve manier om de CDE-scope en beoordelingskosten te verminderen.
- Een gedeelde verantwoordelijkheidsmatrix die elke PCI DSS-vereiste aan een benoemde eigenaar koppelt, wordt verwacht door QSAs voordat de beoordeling begint.
Inhoudsopgave
- Waarom PCI DSS 4.0.1 Anders Is: Wat Veranderd Is in 2025 en Wat Het Betekent voor Uw Cloud Stack
- De 12 Vereisten en Welke Direct Uw Cloud Servers, Opslag en Back-ups Beheersen
- Netwerksegmentatie: Hoe Uw Kaartgegevensomgeving te Isoleren met Publieke, Private, DMZ en VPN Zones
- Stateful Firewall en WAF Controles: OWASP Top 10 Dekking Koppelen aan PCI DSS Vereisten 6 en 10
- Geautomatiseerde Back-up en Log Retentie: Voldoen aan het 90-Dagen Minimale Monitoring Venster en RPO/RTO Doelen
- Kwetsbaarheidsscans en Patching: Kwartaal ASV Scans en de Nieuwe 30-Dagen Kritieke Patch Regel
- Gedeelde Verantwoordelijkheid in de Praktijk: Wat Uw Cloudprovider Moet Documenteren vs. Wat U Bezit
- Een Praktische PCI DSS Gereedheidschecklist voor Cloud-gehoste Betalingsworkloads
- Een PCI-Klare Cloud Stack Bouwen Zonder Opnieuw te Beginnen
Waarom PCI DSS 4.0.1 Anders Is: Wat Veranderd Is in 2025 en Wat Het Betekent voor Uw Cloud Stack
Versie 4.0.1 is geen kleine revisie. De Payment Card Industry Security Standards Council (PCI SSC) heeft het uitgebracht om hiaten te dichten die duidelijk werden toen workloads naar cloud-native en gecontaineriseerde omgevingen verhuisden. Drie veranderingen zijn het belangrijkst voor cloud-gehoste betalingssysteem.
Aangepaste implementatie is nu een eersteklas pad. Voorheen voldeden organisaties ofwel aan een gedefinieerde vereiste of niet. Versie 4.0.1 formaliseert een "aangepaste benadering" waarmee u gelijkwaardige beveiliging kunt aantonen via compenserende controles, zolang u het doel documenteert en uw QSA akkoord gaat. Voor cloudteams is dit belangrijk omdat veel hyperscaler-native controles (AWS Security Groups, Azure Network Security Groups, Google Cloud Firewall Rules) niet duidelijk in de traditionele vereisten taal passen.
WAF-dekking is nu expliciet en verplicht. Vereiste 6.4.2 vereist nu dat een WAF (of vergelijkbare technische controle) wordt ingezet voor alle publiek toegankelijke webapplicaties binnen de scope. Voorheen werd een WAF sterk aanbevolen; nu is het een harde eis. Als uw betalingspagina achter een CDN zonder WAF-mogelijkheid zit, is dat een bevinding.
Logretentie en monitoringvensters aangescherpt. Vereiste 10.5.1 verplicht dat auditlogs ten minste 12 maanden worden bewaard, met ten minste 3 maanden direct beschikbaar voor analyse. De "direct beschikbaar" clausule is wat cloudteams in de problemen brengt: logs die in koude opslag zitten voldoen niet aan deze eis tenzij u ze in realtime kunt opvragen.
Naast deze drie, richt de standaard zich nu expliciet op cloudomgevingen op een manier die eerdere versies niet deden. Sysdig's PCI compliance guidance for cloud-native workloads merkt op dat containerorkestratielagen, vluchtige compute en gedeelde huurders allemaal scopevragen creëren waar uw QSA direct naar zal vragen.
De 12 Vereisten en Welke Direct Uw Cloud Servers, Opslag en Back-ups Beheersen
PCI DSS organiseert zijn controles in 12 vereisten. Niet alle 12 raken cloudinfrastructuur evenveel. De vereisten die de meeste bevindingen genereren tijdens cloudbeoordelingen zijn:
- Vereiste 1 (Netwerkbeveiligingscontroles): Firewallregels, standaard-weigerbeleid en documentatie van alle verkeersstromen in en uit de Cardholder Data Environment (CDE).
- Vereiste 2 (Veilige Configuraties): Geen door de leverancier geleverde standaardinstellingen, geharde OS-afbeeldingen, gedocumenteerde configuratiebaselines voor elke server binnen de scope.
- Vereiste 6 (Veilige Systemen en Software): WAF-implementatie, kwetsbaarheidsbeheer en de nieuwe 30-dagenregel voor kritieke patches.
- Vereiste 10 (Logging en Monitoring): Auditloggeneratie, tamper-evidente opslag en het 90-dagen direct-beschikbaarheidvenster.
- Vereiste 11 (Beveiligingstesten): Kwartaal externe kwetsbaarheidsscans door een Goedgekeurde Scanning Vendor (ASV), jaarlijkse penetratietests en interne scans na elke significante wijziging.
- Vereiste 12 (Beleid en Procedures): Gedocumenteerde gedeelde-verantwoordelijkheidsmatrix met uw cloudprovider.
Vereisten 3 en 4 beheersen kaartgegevens in rust en in transit, wat invloed heeft op uw opslag- en versleutelingskeuzes. Vereisten 7, 8 en 9 dekken toegangscontrole, authenticatie en fysieke beveiliging. Fysieke beveiliging wordt afgehandeld door uw cloudprovider voor colocatie-achtige implementaties, maar u moet hun Attestation of Compliance (AOC) of equivalent als bewijs houden.
Voor cloud-gehoste workloads zijn Vereisten 1, 6, 10 en 11 waar de meeste organisaties bevindingen verzamelen. De rest van deze gids richt zich op de infrastructuurcontroles die die vier aanpakken.
Netwerksegmentatie: Hoe Uw Kaartgegevensomgeving te Isoleren met Publieke, Private, DMZ en VPN Zones
Netwerksegmentatie is technisch niet vereist door PCI DSS, maar het is de meest effectieve manier om de scope te verkleinen. Zonder segmentatie is elk systeem op uw netwerk dat kan communiceren met een CDE-component mogelijk binnen de scope. Met de juiste segmentatie kunt u een strakke grens trekken rond de systemen die daadwerkelijk kaartgegevens opslaan, verwerken of verzenden en alleen die beoordelen.
Het standaardmodel voor een cloud-gehoste CDE gebruikt vier netwerkzones:
- Publieke zone: Internet-facing load balancers en WAF-eindpunten. Hier bevinden zich geen kaartgegevens. Verkeer wordt geïnspecteerd voordat het de DMZ oversteekt.
- DMZ: Applicatieservers die betalingsverzoeken ontvangen. Deze systemen verwerken gegevens maar slaan geen Primary Account Numbers (PANs) op. Strikte uitgaande regels voorkomen dat ze uitgaande verbindingen initiëren behalve naar de private zone.
- Private zone: Databases, versleutelingssleutelbeheer en elk systeem dat PANs of gevoelige authenticatiegegevens opslaat. Geen directe inkomende toegang vanuit de publieke zone. Alle toegang verloopt via de DMZ of een speciaal beheernetwerk.
- VPN/Beheer zone: Administratieve toegang voor ingenieurs en monitoringsystemen. Gescheiden van al het datavlakverkeer. Multi-factor authenticatie (MFA) vereist op elk toegangspunt.
In de praktijk implementeert u dit met gescheiden Virtual Private Cloud (VPC) segmenten of gelijkwaardige constructies (AWS VPC, Azure Virtual Network, Google Cloud VPC), met firewallregels die de grenzen afdwingen. Elke regel moet worden gedocumenteerd en elke regel die niet expliciet vereist is, moet worden verwijderd. "Permit any any" regels ergens in de CDE-grens zijn een automatische bevinding.
PlusClouds Networking and Load Balancers biedt precies deze vijf netwerktype, inclusief publiek, privaat, VPN, beheer en DMZ, allemaal configureerbaar vanuit een enkel controlepaneel. Dat maakt de hierboven beschreven segmentatiearchitectuur inzetbaar zonder meerdere producten aan elkaar te naaien of aangepaste routeringslogica te schrijven.
Een praktische opmerking: documenteer uw netwerktopologie vóór uw QSA-engagement, niet tijdens. Een diagram dat elke gegevensstroom tussen zones toont, met firewallregelreferenties gekoppeld aan elke stroom, verkort de beoordelingstijd aanzienlijk en toont het soort controlevolwassenheid dat QSAs zoeken.
Stateful Firewall en WAF Controles: OWASP Top 10 Dekking Koppelen aan PCI DSS Vereisten 6 en 10
Vereiste 1 eist stateful inspectie bij elke CDE-grens. Een stateful firewall volgt de status van actieve verbindingen en staat retourverkeer alleen toe voor sessies die het heeft geïnitieerd. Stateless Access Control Lists (ACLs) voldoen niet aan deze vereiste.
Vereiste 6.4.2 gaat verder: alle publiek toegankelijke webapplicaties binnen de scope moeten worden beschermd door een WAF die is geconfigureerd om aanvallen te detecteren en te blokkeren. De vereiste verwijst specifiek naar de OWASP Top 10 als basislijn. Uw WAF moet minimaal adresseren:
- SQL-injectie (OWASP A03)
- Cross-site scripting, of XSS (OWASP A03)
- Gebroken toegangscontrole (OWASP A01)
- Beveiligingsmisconfiguratie (OWASP A05)
- Injectieaanvallen in het algemeen (OWASP A03)
Vereiste 10 voegt een logverplichting toe bovenop de WAF-controle: elke geblokkeerde en toegestane aanvraag moet een logvermelding genereren, en die logs moeten tamper-evident zijn en 12 maanden worden bewaard met 3 maanden direct opvraagbaar.
Dit is waar veel teams de inspanning onderschatten. Een WAF die aanvallen blokkeert maar geen gestructureerde, opvraagbare logs produceert, faalt Vereiste 10, zelfs als het voldoet aan Vereiste 6. U heeft beide nodig.
PlusClouds Cloud Security combineert een stateful firewall met een WAF die de OWASP Top 10 dekt, plus altijd-aan DDoS-mitigatie bij 1 Tbps en hoger. Het platform heeft ISO 27001, SOC 2 en GDPR-certificeringen, wat de documentatielast vereenvoudigt wanneer uw QSA vraagt om bewijs van de eigen beveiligingshouding van de provider.
Voor logging, leid WAF-evenementen naar een gecentraliseerd Security Information and Event Management (SIEM) systeem met onveranderlijke logopslag. AWS CloudWatch Logs met Object Lock, of een gelijkwaardige onveranderlijke schrijfstoragelaag, voldoet aan de tamper-evidente vereiste. On-premises SIEM-oplossingen werken ook, maar ze voegen operationele overhead toe die cloud-native opties vermijden.
Geautomatiseerde Back-up en Log Retentie: Voldoen aan het 90-Dagen Minimale Monitoring Venster en RPO/RTO Doelen
Er bestaan twee verschillende back-upverplichtingen onder PCI DSS 4.0.1, en teams verwarren ze vaak.
De eerste is gegevensback-up voor hersteldoeleinden, beheerst door Vereiste 12.3.4 en uw bedrijfscontinuïteitsverplichtingen. Uw Recovery Point Objective (RPO) en Recovery Time Objective (RTO) moeten worden gedocumenteerd, getest en haalbaar zijn. Voor betalingssysteem wordt RPO meestal gemeten in uren op zijn hoogst; RTO in enkele uren voor kritieke paden.
De tweede is logback-up voor auditdoeleinden, beheerst door Vereiste 10.5.1. Logs moeten 12 maanden worden bewaard. Ten minste 3 maanden aan logs moeten direct beschikbaar zijn, wat betekent dat ze opvraagbaar zijn zonder een hersteloperatie. Dit is een aparte vereiste van uw applicatiegegevensback-up, en het heeft zijn eigen retentiebeleid en opslaglaag nodig.
Praktische implementatie ziet er als volgt uit:
Applicatiegegevens:
- Dagelijkse incrementele snapshots bewaard voor 30 dagen
- Wekelijkse volledige snapshots bewaard voor 90 dagen
- Maandelijkse archieven bewaard voor 12 maanden
- Offsite of cross-region kopie van alle snapshots
Auditlogs:
- In realtime gestreamd naar onveranderlijke logopslag
- Warme laag: 90 dagen (direct opvraagbaar)
- Koude laag: maanden 4-12 (herstelbaar binnen gedefinieerde SLA)
- Integriteitsverificatie: cryptografische hash op elke logbatchTesten is net zo belangrijk als de back-up zelf. Vereiste 12.3.4 vereist dat u ten minste jaarlijks back-upherstel test. Documenteer de test, het resultaat en de daadwerkelijk behaalde RTO. QSAs vragen om dit bewijs, en "we hebben back-ups" zonder een getest herstel is niet voldoende.
PlusClouds Automated Backup biedt geautomatiseerde back-up en herstel met expliciete RPO/RTO-doelen, SLA-tracking en mogelijkheden voor herstel op afstand. Voor teams die een bredere ransomware-resistente architectuur bouwen, behandelt de 3-2-1-1 back-upregel gids hoe offsite en onveranderlijke kopieën kunnen worden gelaagd om zowel aan PCI DSS als ransomware-herstelvereisten tegelijkertijd te voldoen.
Kwetsbaarheidsscans en Patching: Kwartaal ASV Scans en de Nieuwe 30-Dagen Kritieke Patch Regel
Vereiste 11.3.2 verplicht externe kwetsbaarheidsscans door een door PCI SSC goedgekeurde ASV ten minste eens per drie maanden, en na elke significante wijziging aan de CDE. "Significante wijziging" is breed gedefinieerd: nieuwe systemen, gewijzigde firewallregels, softwareversie-upgrades. Als u continu implementeert, moet u mogelijk vaker scans uitvoeren dan driemaandelijks.
De nieuwe 30-dagenregel voor kritieke patches onder Vereiste 6.3.3 is waar teams die bouwen op snel bewegende cloudinfrastructuur de meeste druk voelen. Kritieke kwetsbaarheden (CVSS-score 9.0 of hoger) moeten binnen een maand na release worden aangepakt. Hoog-ernstige kwetsbaarheden (CVSS 7.0-8.9) moeten binnen drie maanden worden aangepakt. Dit geldt voor elk systeem binnen de CDE-scope, inclusief basis-OS-afbeeldingen, container-runtimes en externe bibliotheken.
In de praktijk betekent dit:
- Geautomatiseerde OS-patching moet zijn ingeschakeld en worden gemonitord voor alle CDE-servers.
- Containerbasisafbeeldingen moeten binnen het patchvenster worden herbouwd en opnieuw worden ingezet, niet alleen in een achterstand worden gemarkeerd.
- Er moet een gedocumenteerd wijzigingsbeheerproces bestaan, zodat noodpatches kunnen worden toegepast zonder een volledige wijzigingsadviesraadcyclus.
PlusClouds Cloud Servers draaien op AMD EPYC-hardware met NVMe-opslag en ondersteunen volledige roottoegang, wat uw team de controle geeft die nodig is om patches toe te passen op uw schema in plaats van te wachten op een onderhoudsvenster van de provider. De 99,98% uptime SLA betekent dat patchen met rollende herstarts geen onderhoudsblackout vereist.
Voor interne scans kunnen tools zoals OpenVAS of Nessus binnen de private zone worden ingezet om CDE-componenten te scannen zonder scanverkeer bloot te stellen aan het publieke internet. Externe ASV-scans moeten komen van een goedgekeurde leverancier. Een lijst van goedgekeurde ASVs wordt onderhouden door de PCI Security Standards Council.
Gedeelde Verantwoordelijkheid in de Praktijk: Wat Uw Cloudprovider Moet Documenteren vs. Wat U Bezit
Het gedeelde-verantwoordelijkheidsmodel is in principe goed begrepen en wordt vaak verkeerd toegepast in de praktijk. Voor PCI DSS is de vraag niet alleen "wie is verantwoordelijk voor wat" maar "wie kan bewijs leveren van wat" wanneer een QSA vraagt.
Uw cloudprovider is verantwoordelijk voor de fysieke beveiliging van het datacenter (Vereiste 9), de integriteit van de hypervisorlaag en de netwerkhardware die uw virtuele infrastructuur ondersteunt. Ze moeten documentatie van hun eigen nalevingshouding verstrekken, meestal in de vorm van een Attestation of Compliance (AOC) of een SOC 2 Type II-rapport.
U bent verantwoordelijk voor alles boven de hypervisor: OS-configuratie, applicatiecode, firewallregels, WAF-beleid, versleutelingssleutelbeheer, toegangscontrole en logretentie. Zelfs als uw cloudprovider een beheerde WAF-dienst aanbiedt, bent u eigenaar van de WAF-configuratie en moet u aantonen dat deze de vereiste OWASP Top 10-categorieën dekt.
De praktische output van deze analyse is een gedeelde-verantwoordelijkheidsmatrix: een document dat elke PCI DSS-vereiste opsomt, welke partij het bezit en welk bewijs er is. Uw QSA zal dit document verwachten. Bouw het vóór de beoordeling, niet tijdens.
Voor teams die isolatiemodellen evalueren, behandelt de multi-tenant cloud vs. single-tenant bare metal guide hoe huurdersarchitectuur uw scopegrens beïnvloedt en welke documentatie elk model van de provider vereist.
PlusClouds opereert Tier 3 datacenters met N+1 redundantie en een 40 Gbps backbone, en heeft ISO 27001-certificering. Die certificering dekt de fysieke en netwerklagen en kan direct worden verwezen in uw gedeelde-verantwoordelijkheidsmatrix om Vereiste 9 en de fysieke beveiligingsdelen van Vereiste 12 te sluiten.
Een Praktische PCI DSS Gereedheidschecklist voor Cloud-gehoste Betalingsworkloads
Gebruik deze checklist als uitgangspunt voor uw pre-assessment gap-analyse. Het is niet uitputtend, maar het dekt de controles die het vaakst als onvoldoende worden bevonden in cloudomgevingen.
Netwerk en Segmentatie
- CDE is geïsoleerd in een toegewijde private netwerkzone zonder directe publieke internettoegang
- DMZ bestaat tussen publiek toegankelijke componenten en de private CDE
- Alle firewallregels zijn gedocumenteerd met zakelijke rechtvaardiging
- Standaard-weiger inkomende en uitgaande regels zijn aanwezig bij elke CDE-grens
- VPN of beheernetwerk is gescheiden van datavlakverkeer
- Netwerktopologiediagram is actueel en komt overeen met werkelijke firewallregelsets
Firewall en WAF
- Stateful firewall is ingezet bij elke CDE-ingangs- en uitgangspunt
- WAF is ingezet voor alle publiek toegankelijke webapplicaties binnen de scope
- WAF-beleid dekt OWASP Top 10-categorieën met blokkeerstand ingeschakeld (niet alleen detectie)
- WAF-logs worden gestreamd naar een gecentraliseerde, tamper-evidente logopslag
- Firewall- en WAF-regels worden ten minste elke zes maanden herzien
Back-up en Log Retentie
- Applicatiegegevensback-upschema is gedocumenteerd met RPO en RTO-doelen
- Back-upherstel wordt ten minste jaarlijks getest met gedocumenteerde resultaten
- Auditlogs worden minimaal 12 maanden bewaard
- Ten minste 90 dagen aan logs zijn direct opvraagbaar zonder een hersteloperatie
- Logintegriteit wordt geverifieerd met cryptografische hashing of equivalent
Kwetsbaarheidsbeheer
- Kwartaal ASV-scans zijn gepland met een goedgekeurde leverancier
- Interne kwetsbaarheidsscans worden uitgevoerd na elke significante wijziging
- Kritieke patches (CVSS 9.0+) worden binnen 30 dagen na release toegepast
- Hoog-ernstige patches (CVSS 7.0-8.9) worden binnen 90 dagen toegepast
- Containerbasisafbeeldingen zijn opgenomen in de patchscope
Gedeelde Verantwoordelijkheid
- Cloudprovider AOC of SOC 2 Type II-rapport is in bezit
- Gedeelde-verantwoordelijkheidsmatrix koppelt elke PCI DSS-vereiste aan een eigenaar
- ISO 27001 of gelijkwaardige certificering van de provider dekt fysieke en netwerklagen
- Penetratietestscope omvat cloud-specifieke aanvalsvlakken (metadata-API's, IAM-misconfiguraties)
Een PCI-Klare Cloud Stack Bouwen Zonder Opnieuw te Beginnen
PCI DSS 4.0.1-naleving op cloudinfrastructuur is haalbaar zonder een complete herarchitectuur, maar het vereist welbewuste keuzes over waar uw CDE-grens zich bevindt, hoe verkeer die grens oversteekt en hoe bewijs wordt verzameld en bewaard. De organisaties die het meest worstelen in beoordelingen zijn niet degenen met de zwakste beveiliging; het zijn degenen met de zwakste documentatie. Controles die bestaan maar niet kunnen worden aangetoond, tellen niet mee.
De infrastructuurcontroles die hier worden behandeld, stateful firewalls, WAF met OWASP Top 10-dekking, vijf-zone netwerksegmentatie, geautomatiseerde back-ups met geteste herstel en kwartaal ASV-scanning, vormen de technische basis. De gedeelde-verantwoordelijkheidsmatrix en de pre-assessment gap-analyse zijn de operationele basis. Beide zijn vereist.
Als u cloudinfrastructuur evalueert voor een betalingsworkload en een provider wilt wiens beveiligingshouding al is gedocumenteerd tegen ISO 27001, SOC 2 en GDPR, de PlusClouds-platform dekt de volledige stack: Cloud Security voor firewall en WAF, Networking and Load Balancers voor segmentatie, Automated Backup voor herstel en logretentie, en Cloud Servers voor de compute-laag. Begin met een scope-reductiegesprek: definieer eerst uw CDE-grens en bouw vervolgens de controles eromheen. Die volgorde van operaties bespaart meer beoordelingstijd dan enig individueel hulpmiddel.
