PCI-nalevingsspecificatie

Gepubliceerd: april 2021. Bijgewerkt: augustus 2026. Beoordeeld door het Compliance Advisory-team van Encryption Consulting.

Dit artikel biedt een diepgaande, technische analyse van de vereisten van PCI DSS op het gebied van cryptografie en sleutelbeheer: de selectie van algoritmen en protocollen, het dreigingsmodel achter elke controle, afhankelijkheden van sleutelbeheer en concrete implementatiepatronen. Als uw team behoefte heeft aan het volledige certificeringstraject, informatie over merchantniveaus, SAQ-typen en richtlijnen op programmaniveau, raadpleeg dan ons bijbehorende artikel ' Een uitgebreide gids voor het behalen en behouden van PCI DSS-compliance' , dat het bredere complianceprogramma behandelt. Dit artikel is bedoeld voor de beveiligings- en engineeringteams die al weten dat ze aan de eisen moeten voldoen en nu systemen ontwerpen die een technische beoordeling door een auditor moeten doorstaan.

Wat schrijft PCI DSS voor met betrekking tot cryptografie?

PCI DSS schrijft voor dat alle kaartgegevens van kaarthouders, zowel in rust als tijdens verzending, moeten worden beschermd met behulp van sterke cryptografie. Deze sterke cryptografie wordt door de PCI Security Standards Council (PCI SSC) gedefinieerd als algoritmen en sleutelsterktes die uitgebreid zijn getest, geaccepteerd door de internationale cryptografiegemeenschap en vrij zijn van bekende praktische kwetsbaarheden bij de gebruikte sleutelgrootte. In de praktijk betekent dit een minimale effectieve sleutelsterkte van 112 bits, wat DES, single-key 3DES en RC4 direct uitsluit en implementeerders wijst op AES-256, RSA met 2048 bits of hoger en ECC met 224 bits of hoger.

Een aantal termen komen herhaaldelijk terug in de specificatie en in dit artikel. Het is daarom nuttig om ze elk afzonderlijk te definiëren voordat we verdergaan:

• PCI DSS (Betaalkaart Industry Data Security Standard): de technische en operationele beveiligingsstandaard die door de PCI SSC wordt gehanteerd voor elke organisatie die betaalkaartgegevens opslaat, verwerkt of verzendt.
• PAN (Primair rekeningnummer)Het kaartnummer zelf, het specifieke gegevenselement dat de meeste cryptografische controles van PCI DSS moeten beschermen.
• CDE (Cardholder Data Environment)Dit omvat de mensen, processen en technologie die kaartgegevens opslaan, verwerken of verzenden, plus elk systeem dat de beveiliging van die gegevens kan beïnvloeden.
• QSA (Gekwalificeerd Beveiligingsbeoordelaar): een persoon die door de PCI SSC is gecertificeerd om formele PCI DSS-beoordelingen op locatie uit te voeren.
• ROC (Rapport over naleving): het gedetailleerde rapport dat een QSA opstelt, waarin wordt gedocumenteerd hoe aan elke vereiste is voldaan; dit is vereist voor Level 1-handelaren en de meeste dienstverleners.
• SAQ (Zelfbeoordelingsvragenlijst): het zelfgerapporteerde validatie-instrument dat kleinere ondernemers gebruiken in plaats van een volledige audit onder leiding van een QSA.

De cryptografische vereisten van de specificatie vallen uiteen in drie afzonderlijke technische problemen: het onleesbaar maken van opgeslagen PAN-gegevens (vereiste 3), het beschermen van kaartgegevens tijdens de overdracht (vereiste 4) en het authenticeren van elke gebruiker die de CDE bereikt (vereiste 8). Elk probleem heeft zijn eigen dreigingsmodel en een eigen algoritme of protocolkeuze. De onderstaande paragrafen behandelen elk probleem in de volgorde waarin ze doorgaans tijdens een architectuurbeoordeling aan bod komen.

Welke algoritmen en protocollen vereist PCI DSS?

PCI DSS vereist AES-256 of een algoritme met een gelijkwaardige sterkte voor de bescherming van opgeslagen accountgegevens, en TLS 1.2 als de verplichte minimale protocolversie voor kaartgegevens die via openbare netwerken worden verzonden, waarbij TLS 1.3 de voorkeur heeft voor nieuwe implementaties. De standaard zelf schrijft geen specifieke protocolversie voor, maar de richtlijnen van de PCI SSC sluiten SSL en eerdere TLS-versies (TLS 1.0 en 1.1) uit omdat deze niet langer voldoen aan de definitie van sterke cryptografie.

Dreigingsmodel voor data in rust en tijdens transport

Opgeslagen kaartgegevens zijn kwetsbaar voor aanvallen via datalekken, misbruik door medewerkers, blootstelling van back-ups en logbestanden, en laterale verplaatsing van een minder gevoelig systeem naar de gegevensopslag. De beveiliging moet daarom bestand zijn tegen een aanvaller die al leesrechten heeft op de opslaglaag. Gegevens die onderweg zijn, worden geconfronteerd met een ander dreigingsmodel: man-in-the-middle-aanvallen, protocol-downgrade-aanvallen en exploits op cipher-niveau zoals POODLE en BEAST, die specifiek gericht zijn op SSL en vroege TLS-versies. Een QSA-testvereiste 4 scant op elke listener die nog steeds een verouderde protocolversie accepteert, en bevestigt niet alleen dat TLS ergens in de stack is ingeschakeld.

Richtlijnen voor de selectie van algoritmen en protocollen

Voor data in rust heeft AES-256-GCM over het algemeen de voorkeur boven CBC-modus voor nieuwe implementaties, omdat het geauthenticeerde encryptie biedt, manipulatie detecteert en de data verbergt, met vergelijkbare prestaties op moderne CPU's met AES-NI-acceleratie. Voor data in transit dient u SSL 2.0, SSL 3.0, TLS 1.0 en TLS 1.1 uit te schakelen op alle systeemcomponenten die de CDE gebruiken, inclusief interne loadbalancers en legacy point-of-sale-integraties, en de voorkeur voor cipher suites te configureren om forward-secrecy suites (op ECDHE gebaseerd) te verkiezen boven statische RSA-sleuteluitwisseling. De PCI SSC verwijst naar NIST SP 800-52 als referentie voor het versterken van de TLS-configuratie.

Afweging tussen prestaties en interoperabiliteit

TLS 1.3 elimineert een aantal verouderde handshake-rondes en laat bekende zwakke cipher suites achterwege, waardoor zowel de verbindingslatentie als het risico op configuratiefouten wordt verminderd. Sommige oudere kassaterminals, betaal-SDK's en embedded apparaten onderhandelen echter nog steeds alleen via TLS 1.2. Daarom blijft TLS 1.2 de praktische minimale basislijn in plaats van TLS 1.3 direct; een gefaseerd upgradepad waarbij TLS 1.2-hardware volgens een vast schema wordt uitgefaseerd, is een realistischer architectuurkeuze dan een onmiddellijke overstap. Wat de opslag betreft, voegt de authenticatietag van AES-256-GCM een kleine, vaste overhead per blok toe die verwaarloosbaar is op hardwareversnelde systemen, maar van belang kan zijn op embedded betaalterminals met beperkte resources. Dit is een van de redenen waarom deze apparaten vaak getokeniseerd worden op het moment van vastlegging in plaats van lokaal versleuteld.

Implementatievoorbeeld: een veelvoorkomend patroon is TLS-terminatie bij een load balancer of API gateway die is geconfigureerd voor minimaal TLS 1.2 en bij voorkeur TLS 1.3, met herversleuteling (niet in platte tekst) op het interne segment tussen de gateway en de applicatielaag, zodat kaartgegevens nooit onversleuteld worden verzonden, zelfs niet binnen het eigen netwerk van de organisatie.

Wat vereisen de PCI DSS-vereisten 3.5 tot en met 3.7 voor sleutelbeheer?

Vereisten 3.5, 3.6 en 3.7 vereisen respectievelijk dat opgeslagen PAN onleesbaar wordt gemaakt, dat de sleutels die deze beschermen beveiligd zijn tegen openbaarmaking en misbruik, en dat elke sleutel van generatie tot vernietiging een gedocumenteerde levenscyclus heeft. Versleuteling is slechts zo sterk als het sleutelbeheer erachter, en dit is de subvereiste die QSA's het vaakst afkeuren bij mislukte beoordelingen.

• Eis 3.5 Dit vereist dat het PAN onleesbaar wordt gemaakt, waar het ook wordt opgeslagen, door gebruik te maken van sterke cryptografie, afkapping, indextokens met een veilig opgeslagen pad, of eenrichtingshashing van het volledige PAN.
• Eis 3.6 Dit vereist dat cryptografische sleutels die worden gebruikt om opgeslagen accountgegevens te beschermen, zelf ook beschermd zijn: versleuteld met een aparte sleutel voor sleutelversleuteling, opgeslagen in een beveiligd cryptografisch apparaat zoals een HSM, of opgesplitst in componenten onder dubbele controle, waarbij de toegang beperkt is tot het minimaal noodzakelijke aantal beheerders.
• Eis 3.7 Dit vereist gedocumenteerde procedures voor de volledige sleutellevenscyclus: het genereren van sterke sleutels, veilige distributie, veilige opslag, rotatie aan het einde van een vastgestelde cryptoperiode en het buiten gebruik stellen of vernietigen van gecompromitteerde of verlopen sleutels. Het vereist tevens gedeelde kennis en dubbele controle voor handmatige sleutelbeheerhandelingen, en een ondertekende verklaring van de beheerders waarin zij hun verantwoordelijkheden erkennen.

Afhankelijkheid van sleutelbeheer: een AES-256-databasekolom die is versleuteld met een sleutel die is opgeslagen in een configuratiebestand ernaast, biedt in feite geen echte bescherming en is een veelvoorkomende bevinding bij mislukte beoordelingen. Noch de controle op het onleesbaar maken van gegevens volgens vereiste 3.5, noch de TLS-controle volgens vereiste 4 is zinvol zonder de discipline op het gebied van beheer en levenscyclusbeheer die vereisten 3.6 en 3.7 opleggen aan de onderliggende sleutels. Door die levenscyclus te centraliseren via een speciaal platform voor certificaat- en sleutelbeheer zoals CertSecure Manager krijgt een organisatie afgedwongen rotatieschema's, verantwoordingsplicht voor de beheerder en rapportagemogelijkheden die geschikt zijn voor audits, in plaats van een spreadsheet waarin de leeftijd van sleutels handmatig wordt bijgehouden.

Wat stelt PCI DSS aan de eisen voor multifactorauthenticatie?

PCI DSS v4.0.1 vereist MFA voor alle toegang tot de omgeving met kaartgegevens onder vereiste 8.4.2 , niet onder vereiste 8.4.3, en deze controle is volledig afgedwongen sinds 31 maart 2025. We hebben dit rechtstreeks voor dit artikel geverifieerd, omdat twee andere berichten over dit onderwerp het niet eens zijn over het aantal, en het correct weergeven ervan is belangrijk voor iedereen die een toegangscontrolearchitectuur bouwt volgens de specificatie.

Drie verwante subvereisten onder vereiste 8.4 worden gemakkelijk door elkaar gehaald, daarom is het belangrijk ze nauwkeurig te onderscheiden:

• Eis 8.4.1: MFA voor alle niet-console-administratieve toegang tot de CDE. Overgenomen van PCI DSS v3.2.1 en al jaren van kracht vóór v4.0.
• Eis 8.4.2: MFA voor allen Toegang tot de CDE voor elke rol, vanaf elke locatie, niet alleen beheerdersrechten. Dit is de belangrijkste nieuwe beveiligingsmaatregel die is geïntroduceerd in versie 4.0 en die vanaf 31 maart 2025 verplicht is.
• Eis 8.4.3: MFA voor alle externe netwerktoegang afkomstig van buiten het netwerk van de entiteit die de CDE zou kunnen bereiken, inclusief toegang op afstand door personeel en externe partijen of leveranciers. Deze vereiste bestond al vóór versie 4.0 en is verduidelijkt in plaats van nieuw geïntroduceerd.

Vereiste 8.5.1 werkt samen met 8.4.2 en is eveneens verplicht gesteld op 31 maart 2025: MFA-implementaties moeten bestand zijn tegen omzeiling, behalve via een gedocumenteerd, risico-geanalyseerd uitzonderingsproces, moeten ten minste twee onafhankelijke factoren vereisen, moeten bevestigen dat alle factoren succesvol zijn voordat toegang wordt verleend, en moeten bestand zijn tegen replay-aanvallen. Voor de meeste organisaties betekent dit in de praktijk het uitbreiden van MFA van de beheerders die al onder 8.4.1 vallen naar elke applicatiegebruiker, aannemer en integratie van derden die de CDE gebruikt, en vervolgens het documenteren van de anti-omzeilingsmaatregelen waarvan een beoordelaar specifiek bewijs zal willen zien.

Hoe beschermt tokenisatie het PAN onder PCI DSS?

Tokenisatie beschermt het PAN (Primary Account Number) door het te vervangen door een vervangende waarde, een token, op het moment van vastlegging. Het echte PAN wordt alleen opgeslagen in een aparte, strikt afgebakende tokenkluis, zodat geen enkel systeem dat het token gebruikt, ooit het daadwerkelijke kaartnummer te zien krijgt. Formaatbehoudende encryptie (Format-preserving encryption, FPE) is de techniek die de meeste tokenisatieschema's gebruiken om ervoor te zorgen dat het token dezelfde lengte en tekenset behoudt als het originele PAN. Hierdoor hoeven bestaande databases, logformaten en applicaties die het token gebruiken, geen schemawijzigingen door te voeren om het te accepteren.

Waar encryptie de waarde van het PAN-nummer herstelbaar houdt, wat belangrijk is wanneer downstream-systemen zoals terugkerende facturering of chargeback-verwerking het oorspronkelijke nummer nog nodig hebben, verwijdert tokenisatie het echte PAN-nummer volledig uit de omgeving. Dat is wat de reikwijdte van de PCI DSS-beoordeling daadwerkelijk verkleint, maar het introduceert een afhankelijkheid van de bereikbaarheid en beschikbaarheid van de tokenkluis voor elk systeem dat moet detokeniseren. Bovendien voegt formaatbehoudende tokenisatie een extra netwerkronde per detokenisatieoproep toe, wat van belang is bij een hoog transactievolume.

Implementatievoorbeeld: een betalingsgateway tokeniseert het PAN (Primary Account Number) doorgaans op het moment van vastlegging en slaat alleen het token op in zijn eigen database. De tokenkluis zelf is het enige systeem dat volledig onder de PCI DSS-regelgeving valt. Een traditioneel on-premises facturatiesysteem dat het echte PAN moet bewaren voor terugkerende kosten, maakt vaker gebruik van kolomniveau- of transparante dataversleuteling met AES-256, ondersteund door een HSM-beveiligde sleutel, omdat het vervangen van het PAN door een token de facturatielogica zou verstoren.

Welke HSM-vereisten gelden voor sleutelbeheer?

Een hardwarebeveiligingsmodule (HSM) is de praktische manier waarop de meeste organisaties die aan de vereisten voldoen, voldoen aan de formulering "beveiligd cryptografisch apparaat" van vereiste 3.6: een fraudebestendig, speciaal apparaat dat cryptografische sleutels genereert, opslaat en gebruikt zonder deze ooit in platte tekst aan de hostapplicatie of het besturingssysteem bloot te stellen. FIPS 140-3 is de huidige validatiestandaard waaraan HSM's worden getoetst, en QSA's verwachten steeds vaker FIPS-gevalideerde sleutelopslag in plaats van softwarematige sleutelkluizen voor omgevingen met hoge waarde.

Organisaties kiezen over het algemeen tussen on-premises HSM's, die maximale controle bieden en vaak worden gebruikt wanneer contractuele vereisten dit vereisen, en cloudgebaseerde HSM-as-a-Service , die de investeringskosten en de overhead van fysieke sleutelceremonies wegneemt, terwijl toch FIPS-gevalideerde sleutelopslag wordt geboden. Implementatievoorbeeld: de tokenisatiekluis van een betalingsverwerker slaat de hoofdsleutel voor encryptie op in een HSM-cluster, en elke aanroep voor het genereren of ontsleutelen van tokens wordt binnen de HSM-omgeving ondertekend of ontsleuteld, zodat de sleutel zelf nooit de gevalideerde hardware verlaat.

Welke PCI DSS-vereisten zijn van toepassing op cryptografie en sleutelbeheer?

De onderstaande tabel koppelt elk crypto- en sleutelbeheerrelevant vereistenummer aan wat het omvat en de technische controle die er doorgaans aan voldoet. Dit is handig als snel naslagwerk tijdens een architectuurbeoordeling.

eis	Wat het omvat	Typische technische controle
3.5	Maak de opgeslagen PAN-gegevens onleesbaar.	AES-256-encryptie, tokenisatie of truncatie
3.6	Bescherm de sleutels die worden gebruikt om opgeslagen accountgegevens te beveiligen.	HSM-ondersteunde sleutelopslag, sleutelversleutelingssleutels, dubbele besturing
3.7	Documenteer en handhaaf de volledige sleutellevenscyclus.	Gedefinieerde cryptoperioden, geautomatiseerde rotatie, goedkeuring door de beheerder
4.2.1	Bescherm kaartgegevens tijdens overdracht via openbare netwerken.	Minimaal TLS 1.2, bij voorkeur TLS 1.3, geen SSL of oudere TLS-versies.
8.4.1	MFA voor niet-console-beheertoegang tot de CDE	MFA op alle beheerdersconsoles en jump hosts.
8.4.2	MFA voor alle toegang tot de CDE, ongeacht de rol of locatie.	MFA wordt afgedwongen bij elk CDE-authenticatiepunt.
8.4.3	MFA voor toegang op afstand die afkomstig is van buiten het netwerk van de entiteit.	VPN of gateway voor toegang op afstand MFA, inclusief toegang door derden

Wat is het validatieproces voor PCI DSS-naleving?

De PCI DSS-validatie volgt dezelfde technische beoordelingsprocedure, ongeacht het niveau van de handelaar, hoewel de diepte van de tests in elke fase verschilt afhankelijk van het transactievolume en het validatiepad (door QSA geleide ROC versus zelfbeoordeling via SAQ).

1. Bevestig de reikwijdte van CDE. Breng elk systeem, proces en netwerksegment in kaart dat kaartgegevens opslaat, verwerkt of verzendt, of dat de beveiliging ervan kan beïnvloeden. Segmentatie is de meest effectieve manier om dit bereik te verkleinen.
2. Inventariseer cryptografische activa. Stel een nauwkeurige lijst samen van elk algoritme, protocol, certificaat en sleutel in de CDE voordat u besluit tot herstelmaatregelen; u kunt immers niet beschermen wat u niet kunt zien.
3. Test de cryptografische en sleutelbeheercontroles specifiek aan de hand van vereisten 3, 4 en 8. Controleer de PAN-weergave, TLS-configuratie, sleutelbeheer en MFA-dekking aan de hand van de specificatie, niet aan de hand van wat veilig aanvoelt.
4. Pak eerst de ernstigste tekortkomingen aan. Ongecodeerde opgeslagen PAN, verouderde TLS-versies en ontbrekende MFA bij CDE-toegang zijn steevast de ernstigste bevindingen bij de beoordelingen.
5. Volledige formele validatie. Winkels met een lager volume vullen de toepasselijke SAQ in; Level 1-winkeliers en de meeste dienstverleners ondergaan een QSA-beoordeling op locatie, die resulteert in een nalevingsrapport (Report on Compliance, ROC).
6. Dien de Verklaring van Naleving (AOC) in. aan de overnemende bank, gesteund door de SAQ of ROC.
7. Zorg voor continue validatie. Regelmatige ASV-scans (Automatic Security Vessel) per kwartaal, jaarlijkse penetratietests en een jaarlijkse evaluatie van de reikwijdte zorgen ervoor dat cryptografische beveiligingsmaatregelen niet ongemerkt veranderen tussen formele beoordelingen.

Beperkingen

De specificatie is nauwkeurig, maar dekt niet alles wat een daadwerkelijke implementatie vereist. Enkele beperkingen die het vermelden waard zijn:

• Het behalen van een voldoende resultaat voor een toets is een momentopname. Een configuratieafwijking of een nieuw systeem dat niet binnen het toepassingsgebied valt nadat de ROC of AOC is ondertekend, kan ertoe leiden dat een organisatie onmiddellijk weer niet aan de regelgeving voldoet.
• Het versleutelen van het PAN-nummer zorgt er op zich niet voor dat het buiten het bereik van gegevens valt. Een systeem dat nog steeds versleutelde accountgegevens opslaat, valt doorgaans binnen het toepassingsgebied; alleen tokenisatie waarbij het echte PAN-nummer volledig wordt verwijderd, verkleint het toepassingsgebied.
• Compensatiemaatregelen vereisen gedocumenteerde nauwkeurigheid, geen gemakzucht. Voor elk van deze methoden is een formele risicoanalyse en goedkeuring door een QSA vereist. Bij losjes gebruik worden ze een manier om de onderliggende tekortkoming niet aan te pakken.
• De standaard evolueert. Dit artikel is gebaseerd op PCI DSS v4.0.1 zoals die gold in augustus 2026. Een toekomstige versie 5.0 kan de vereisten hernummeren of de tijdlijnen verschuiven. Controleer daarom de actuele gepubliceerde standaard voordat u architectuurbeslissingen neemt.
• De interpretatie van QSA kan variëren bij vragen die zich op het randje van de afbakening bevinden. Door uw QSA vroegtijdig bij een architectuurbeslissing te betrekken, voorkomt u herwerk achteraf.

Wat zou Encryption Consulting aanbevelen?

Na het uitvoeren van beoordelingen van cryptografische architecturen voor organisaties variërend van regionale winkeliers tot nationale banken, zijn wij van mening dat de meeste PCI DSS-cryptografieprogramma's niet slagen voor een beoordeling, niet omdat er een controle ontbreekt, maar omdat deze achteraf is toegevoegd in plaats van vanaf het begin volgens de specificaties te zijn ontworpen. Hieronder leggen we uit wat we concreet zouden doen.

Begin met een gedegen cryptografische inventarisatie. Voordat u kiest tussen encryptie en tokenisatie of de TLS-configuratie controleert, stelt u een nauwkeurige inventarisatie samen van elke cipher suite, elk protocol, elk certificaat en elke sleutel die met de CDE te maken heeft.

Centraliseer het beheer van de levenscyclus van sleutels en certificaten. We implementeren CertSecure Manager om organisaties te voorzien van afgedwongen rotatieschema's, verantwoordingsplicht voor de beheerder en gecentraliseerd inzicht. Dit pakt direct de bevindingen van vereisten 3.6 en 3.7 aan, die het vaakst naar voren komen bij mislukte beoordelingen. Voor hoofdsleutels die tokenisatiekluizen of bulkversleuteling beschermen, adviseren we over het algemeen FIPS 140-3 gevalideerde opslag via on-premises HSM's of HSM-as-a-Service , afhankelijk van de operationele volwassenheid en de bestaande infrastructuur.

Breid MFA doelbewust uit, niet alleen technisch. Voldoen aan de letter van vereiste 8.4.2 is eenvoudig; voldoen aan de anti-omzeilingsintentie van vereiste 8.5.1 vereist meer discipline. Wij helpen klanten elke legitieme MFA-uitzondering te documenteren, deze te koppelen aan een compenserende maatregel en informele omzeilingen die zich in de loop der tijd ophopen, te verwijderen.

Behandel in de cloud opgeslagen kaartgegevens met dezelfde zorgvuldigheid als gegevens die lokaal worden opgeslagen. Onze Cloud Data Protection-services breiden de door HSM ondersteunde architectuur voor sleutelbeheer en -versleuteling uit naar cloud- en hybride omgevingen, zodat tokenisatiekluizen of versleutelde gegevensopslag in de cloud aan dezelfde eisen voor sleutelbeheer voldoen als een lokale implementatie.

Beschouw validatie als een continu proces, niet als een jaarlijks proces. Onze Compliance Advisory-diensten combineren PCI DSS-werk met het bredere regelgevingslandschap waarmee veel klanten te maken hebben, waaronder DORA en NIS2. Hierdoor dienen cryptografische controles die voor PCI DSS zijn ontwikkeld, overlappende mandaten in plaats van dat ze voor elk mandaat opnieuw moeten worden opgebouwd. Als u zich nog in een vroeg stadium van dit proces bevindt, is de meest effectieve eerste stap een gap-analyse ten opzichte van vereisten 3, 4 en 8, aangezien de kosten van fouten daar het hoogst zijn.

Conclusie

De cryptografische specificatie van PCI DSS is nauwer en preciezer dan de twaalf volledige vereisten van de standaard doen vermoeden: sterke algoritmen en TLS 12+ voor data die wordt overgedragen, een gedocumenteerde levenscyclus voor sleutelbeheer volgens vereisten 3.6 en 3.7, MFA voor alle CDE-toegang volgens vereiste 8.4.2, en een weloverwogen keuze tussen encryptie en tokenisatie voor opgeslagen PAN. Als aan deze vier vereisten wordt voldaan, aangevuld met HSM-beveiligde sleutelbewaring, valt het grootste deel van wat een QSA op technisch niveau test, vanzelf op zijn plaats.

Niets daarvan vervangt gedisciplineerde validatie: driemaandelijkse scans, jaarlijkse penetratietests en de gewoonte om de cryptografische laag te beschouwen als een levende architectuur in plaats van een eenmalige implementatie. Als u wilt dat een tweede paar ogen kijkt naar hoe uw cryptografische beveiligingsmaatregelen voldoen aan de specificaties, kunnen onze Encryption Advisory-diensten u helpen de tekortkomingen in kaart te brengen en prioriteiten te stellen voor herstelmaatregelen.

Veelgestelde Vragen / FAQ

Is de PCI DSS MFA-voor-alle-CDE-toegangsverplichting vereiste 8.4.2 of 8.4.3? Het is vereiste 8.4.2. Vereiste 8.4.2 schrijft MFA voor voor alle toegang tot de omgeving met kaartgegevens, voor elke rol en vanaf elke locatie, en is van kracht sinds 31 maart 2025. Vereiste 8.4.3 is een aparte, beperktere controle die MFA specifiek verplicht stelt voor toegang op afstand tot het netwerk, afkomstig van buiten het netwerk van de entiteit.

Vereist PCI DSS een specifiek encryptiealgoritme? PCI DSS noemt geen specifiek verplicht algoritme in de tekst, maar vereist wel sterke cryptografie met een effectieve sleutelsterkte van ten minste 112 bits. AES-256 is de de facto standaard voor opgeslagen accountgegevens, omdat het expliciet wordt erkend als sterke cryptografie en goed presteert in hardware.

Is tokenisatie vereist, of is encryptie voldoende? Geen van beide is afzonderlijk verplicht; PCI DSS-vereiste 3.5 accepteert encryptie, tokenisatie, truncatie of eenrichtingshashing om het PAN onleesbaar te maken. Tokenisatie heeft over het algemeen de voorkeur wanneer het doel is om de reikwijdte te beperken, omdat het verwijderen van het echte PAN uit een systeem ervoor kan zorgen dat dat systeem buiten de beoordelingsscope valt, terwijl versleutelde opslag dat over het algemeen niet doet.

Moeten PCI DSS-sleutels in een HSM worden opgeslagen? Vereiste 3.6 noemt HSM's niet specifiek, maar vereist wel dat sleutels worden beschermd in een van een beperkt aantal vormen, waaronder opslag "in een beveiligd cryptografisch apparaat". Een HSM die is gevalideerd volgens FIPS 140-3 is de meest gebruikelijke manier waarop organisaties aan deze eis voldoen, en QSA's verwachten steeds vaker FIPS-gecertificeerde hardware voor de bewaring van waardevolle sleutels in plaats van softwarematige sleutelkluizen.

Waarin verschilt dit artikel van de algemene PCI DSS-nalevingshandleiding van EC? Dit artikel is een diepgaande analyse op specificatieniveau van cryptografie en sleutelbeheer, bedoeld voor beveiligings- en engineeringteams die systemen ontwerpen volgens de standaard. Onze bijbehorende handleiding, ' Een uitgebreide gids voor het behalen en behouden van PCI DSS-naleving' , behandelt het volledige certificeringsprogramma: niveaus voor handelaren, SAQ-typen en het volledige traject naar een AOC.

Referenties

• PCI DSS v4.0.1 standaarddocument, PCI Security Standards Council
• Nu is het moment om de toekomstgerichte vereisten van PCI DSS v4.x te implementeren, aldus de PCI SSC-blog.
• PCI DSS 4.0 MFA-vereisten: Wat u moet weten, Schellman
• PCI DSS versie 4.0 Multifactorauthenticatie, BDO
• Migreren van SSL en vroege TLS, PCI SSC-informatiesupplement
• PCI SSC-documentenbibliotheek