De Payment Card Industry Data Security Standard (PCI DSS) vereist dat ondernemingen gegevens van kaarthouders beschermen wanneer ze worden opgeslagen en wanneer ze zich over een netwerk verplaatsen. Dat betekent dat er sterke cryptografie is vereist, evenals een reeks ondersteunende regels voor alles, van de certificaatsterkte tot de generatie, opslag en afschrijving van cryptografische sleutels.

Voldoen aan deze PCI-encryptievereisten heeft meer gevolgen dan alleen voor jouw compliancechecklist. Het kan jouw aanvalsoppervlak verkleinen en de mate van blootstelling van jouw onderneming in het geval van een inbreuk beïnvloeden. De gemiddelde kosten van een datalek bereikten wereldwijd in 2025 $ 4,44 miljoen, wat het belang van de bescherming van gevoelige gegevens benadrukt. Hieronder bespreken we wat PCI DSS daadwerkelijk vereist voor encryptie, welke algoritmen en protocollen tegenwoordig aan die eisen voldoen en hoe encryptie samenwerkt met gerelateerde strategieën, zoals tokenisatie en netwerksegmentatie.

Kernpunten

• PCI DSS vereist sterke cryptografie voor kaartgegevens die in rust en in transit zijn, met de Advanced Encryption Standard (AES) met een 256-bits sleutel en Transport Layer Security (TLS) 1.2 of hoger als geaccepteerde referentiewaarden.

• Aangezien encryptie en tokenisatie verschillende problemen oplossen, kun je de scope van PCI-compliance beperken door point-to-point encryptie (P2PE) te combineren met tokenisatie.

• Zwak sleutelbeheer is een van de meest voorkomende redenen waarom ondernemingen zakken voor een PCI DSS-beoordeling, ondanks degelijke onderliggende cryptografische algoritmen.

Wat zijn PCI-encryptievereisten?

Encryptieregels voor PCI DSS worden gedefinieerd in vereiste 3 in de compliance-checklist, die betrekking heeft op opgeslagen gegevens van kaarthouders, en vereiste 4, die betrekking heeft op gegevens die over netwerken worden verplaatst. PCI-auditors controleren beide gebieden bij het evalueren van hoe kaartinformatie wordt verwerkt.

Volgens vereiste 3 moet je, als je het primaire accountnummer (PAN) opslaat, dit onleesbaar maken waar het ook wordt weergegeven, of dit nu in een database, logbestand of back-up is. Hoewel sterke cryptografie de belangrijkste beschermingsmethode is, behoren afkapping en hashing ook tot de opties, met name voor het maskeren van PAN's op bonnen of schermen die voor klanten zijn bedoeld. Vereiste 4 stelt dat alle kaartgegevens die open, openbare netwerken passeren end-to-end moeten worden versleuteld. Er zijn geen uitzonderingen voor intern gemak of oudere omgevingen die dateren van vóór de standaard.

Gevoelige authenticatiegegevens (SAD) vereisen een andere aanpak die de volledige magneetstrip- of chipgegevens, de kaartverificatiewaarde (CVV) en het PIN-blok omvat. Volgens de PCI DSS mag je niets hiervan opslaan nadat de autorisatie is voltooid, ongeacht de encryptiestatus ervan.

Welke cryptografische standaarden en protocollen keurt de PCI DSS goed voor encryptie?

De PCI DSS vereist 'sterke cryptografie', door de PCI Security Standards Council gedefinieerd als elke methode die ten minste 112 bits effectieve sleutelsterkte biedt. In de praktijk wijst die definitie op een korte lijst met geaccepteerde keuzes:

• Data in rust: AES-256 is de gangbare standaard. Het haalt de sterktedrempel en krijgt brede ondersteuning van cloudaanbieders en betalingsinfrastructuur. Triple DES (3DES) kwalificeert technisch gezien nog steeds in bepaalde configuraties, maar de PCI Security Standards Council heeft het gemarkeerd voor afschrijving en de meeste nieuwe systemen slaan het helemaal over.

• Asymmetrische encryptie: Dit wordt gebruikt voor het uitwisselen van symmetrische sleutels of het ondertekenen van certificaten. Dit betekent over het algemeen Rivest-Shamir-Adleman (RSA) op minimaal 2048 bits of elliptische kromme-cryptografie (ECC) op minimaal 224 bits.

• Data in transit: TLS 1.2 is de ondergrens, waarbij TLS 1.3 in toenemende mate wordt beschouwd als de praktische standaard. SSL in elke versie, evenals vroege TLS-versies (1.0 en 1.1), zijn expliciet niet toegestaan.

• Cipher suites: Kwalificerende suites mogen geen bekende kwetsbaarheden hebben. Hiermee is RC4 (Rivest Cipher 4) uitgesloten, evenals alle exportklare ciphers die overgebleven zijn van oudere configuraties.

• Certificaatsterkte: Voor openbare certificaten is 2048-bits RSA of sterker nodig. Ook moeten ze beschikken over actuele vervaldata en moet de uitgifte plaatsvinden door een vertrouwde certificeringsinstantie.

• Protocolonderhandeling: Servers moeten verbindingspogingen weigeren die terugvallen op niet-toegestane protocolversies in plaats van deze stilletjes toe te staan.

Hoe vermindert encryptie de scope van PCI-compliance?

De compliancescope in PCI DSS-termen betekent elk systeem dat gegevens van kaarthouders opslaat, verwerkt of doorstuurt, plus alles wat is verbonden met die middelen en wat de beveiliging ervan in gevaar kan brengen. Dit wordt gezamenlijk de gegevensomgeving van de kaarthouder (CDE) genoemd.

Als een systeem omgaat met versleutelde gegevens van kaarthouders zonder toegang tot de middelen om deze te ontsleutelen, beschouwt de PCI Security Standards Council het systeem als buiten het toepassingsgebied, of op zijn minst in een categorie met een beperkt toepassingsgebied. Dit is waar P2PE om de hoek komt kijken. Een door PCI vermelde P2PE-oplossing versleutelt kaartgegevens op het interactiepunt, binnen gevalideerde hardware. Decryptie is beperkt tot de beveiligde omgeving van de P2PE-aanbieder in plaats van de eigen infrastructuur van de onderneming.

Een gevalideerde P2PE-oplossing komt doorgaans in aanmerking voor een P2PE Self-Assessment Questionnaire (SAQ), een van de kortere PCI SAQ's, aangezien P2PE het beoordelingsgebied aanzienlijk verkleint. Segmentatie verkleint het verder. Wanneer kaartgegevenssystemen zijn geïsoleerd op hun eigen netwerksegment, gescheiden van algemene bedrijfssystemen, kunnen systemen die nooit gegevens van kaarthouders zien, volledig buiten de beoordeling worden gehouden.

Encryptie of tokenisatie: welke strategie voldoet het beste aan de PCI-encryptiebehoeften?

Encryptie transformeert het PAN in onleesbare cijfertekst, maar het originele nummer bestaat nog steeds ergens. Iedereen met de juiste sleutel kan het proces terugboeken. Tokenisatie verwijdert het PAN volledig uit de omgeving van de onderneming en vervangt het door een token dat geen wiskundige relatie heeft met het originele nummer en geen waarde heeft als het wordt gestolen.

Wanneer er behoefte is om na de initiële transactie naar de betaalmethode van een klant te verwijzen, zoals bij abonnementen, opgeslagen betaalmethoden of afrekenen met één klik, maakt tokenisatie een verschil. Als een versleuteld PAN intern is opgeslagen, beheer je nog steeds een volledig creditcardnummer en alles wat daarbij hoort, inclusief taken voor sleutelbeheer, uitgebreide auditscope en blootstelling als de bijbehorende sleutel in gevaar komt. Maar als je in plaats daarvan een token opslaat, een token dat is gegenereerd en wordt beheerd door een betalingsprovider zoals Stripe, dan raakt de gevoelige waarde je systemen helemaal niet. Veel opstellingen combineren de twee, waarbij tokenisatie wordt gebruikt voor alles wat op lange termijn is opgeslagen en encryptie wordt gebruikt voor alles wat zich over een netwerk verplaatst.

Waarom is sleutelbeheer een over het hoofd gezien onderdeel van PCI-encryptie?

Encryptie is afhankelijk van hoe goed de sleutels worden beschermd en deze praktijken worden vaak over het hoofd gezien. Houd rekening met het volgende:

• Gedeelde kennis en dubbele controle: Een volledige cryptografische sleutel hoeft niet toegankelijk te zijn voor één persoon. Het opsplitsen van belangrijke componenten over meerdere personen en de vereiste dat meer dan één persoon een sleutel kan reconstrueren, voorkomt dat één individu in zijn eentje de omgeving in gevaar kan brengen.

• Veilige sleutelopslag: Sleutels moeten apart worden opgeslagen van de gegevens die ze beschermen, meestal in een Hardware Security Module (HSM) of een vergelijkbaar sleutelbeheersysteem; ze mogen niet in dezelfde database of hetzelfde bestandssysteem worden opgeslagen als de versleutelde waarden.

• Gedefinieerde cryptoperiodes: Elke sleutel heeft een gedocumenteerde levensduur waarna deze buiten gebruik wordt gesteld en vervangen, op basis van factoren zoals hoeveel gegevens de sleutel beschermt en hoe vaak deze wordt gebruikt.

• Gedocumenteerde verantwoordelijkheden van de sleutelbeheerder: Schriftelijke procedures moeten bepalen wie er verantwoordelijk is voor taken op het gebied van sleutelbeheer; deze beheerders moeten deze verantwoordelijkheid formeel erkennen.

Onder PCI DSS 4.0 moeten ondernemingen hun cryptografische architectuur ten minste eenmaal per 12 maanden beoordelen om te bevestigen dat de gebruikte algoritmen, protocollen en sleutellengtes nog steeds aan de huidige standaarden voldoen en niet zijn verouderd.

Wat gebeurt er als jouw onderneming niet voldoet aan de PCI-encryptievereisten?

Niet voldoen aan de PCI DSS-encryptievereisten verandert wat er gebeurt voor en na een inbreuk. Vóór een incident komt niet-naleving naar voren in het jaarlijkse beoordelingsproces. Acquiring banken en kaartnetwerken kunnen een onderneming markeren als niet-compliant, wat van invloed is op het vermogen om kaartbetalingen te blijven verwerken en aanleiding geeft tot nauwlettender toezicht of aanvullende beoordelingsvereisten in de toekomst.

De gevolgen stapelen zich op als er een inbreuk plaatsvindt en uit een onderzoek blijkt dat niet aan die controles werd voldaan. Een forensisch onderzoek is over het algemeen vereist na een bevestigde inbreuk waarbij gegevens van kaarthouders betrokken zijn. Hierbij wordt specifiek onderzocht of het PAN correct was versleuteld bij opslag en verzending. Als dit niet het geval was, wordt de aansprakelijkheid niet gedeeld met de betalingsprovider of de acquiring bank, maar verschuift deze zwaarder naar de onderneming.

Het kan moeilijk zijn om het vertrouwen in een acquiring bank of een betalingsprovider te herstellen na een dergelijke bevinding. Aangezien cryptografische fouten ook andere zwakke plekken in de interne gegevensverwerking aan het licht brengen, zal een bank waarschijnlijk niet tevreden zijn met de correctie van één enkele controle als zij lacunes in andere controles heeft gevonden.

Hoe Stripe Payments kan helpen

Stripe Payments biedt een gebundelde, wereldwijde betaaloplossing die elke onderneming, van groeiende start-ups tot wereldwijde ondernemingen, helpt om online, fysiek en wereldwijd betalingen te ontvangen.

Stripe Payments kan je helpen:

• Optimaliseer het afrekenproces: Creëer een probleemloze klantervaring en bespaar technische tijd met vooraf gebouwde betaal-UI's, toegang tot 125+ betaalmethoden en Link, een wallet ontwikkeld door Stripe.

• Sneller uit te breiden naar nieuwe markten: bereik klanten over de hele wereld en verminder de complexiteit en kosten van multivalutabeheer met grensoverschrijdende betaalopties, beschikbaar in 195 landen in 135+ valuta.

• Fysieke en online betalingen samen te voegen: bouw een unified commerce-ervaring op via online en fysieke kanalen om interacties te personaliseren, loyaliteit te belonen en inkomsten te laten groeien.

• De betaalprestaties te verbeteren: verhoog inkomsten met een reeks aanpasbare, eenvoudig te configureren betaaltools, waaronder no code-fraudebescherming en geavanceerde mogelijkheden om autorisatiepercentages te verbeteren.

• Sneller te werken met een flexibel, betrouwbaar platform voor groei: bouw voort op een platform dat is ontworpen om met jou mee te groeien, met een historische uptime van 99,999% en toonaangevende betrouwbaarheid.

Lees meer over hoe Stripe Payments je online en fysieke betalingen kan ondersteunen of ga vandaag nog aan de slag.