Het belang van HSM's begrijpen bij het bereiken van PCI DSS-naleving

PCI DSS (Payment Card Industry Data Security Standard) v4.0 vereist beveiligingsmaatregelen voor cryptografische sleutels waaraan alleen hardwarematig gevalideerde oplossingen volledig kunnen voldoen. Hardware Security Modules (HSM's) voldoen direct aan de eisen voor sleutelbeheer van PCI DSS-vereiste 3 door encryptiesleutels voor kaartgegevens en betaalverwerkingssleutels te genereren, op te slaan en te gebruiken binnen een FIPS-gevalideerde, fraudebestendige omgeving. Niet-naleving van PCI DSS kan leiden tot boetes van $ 5,000 tot $ 100,000 per maand en het verlies van toegangsrechten voor kaartverwerking. De aanbevolen actie: implementeer FIPS 140-2 Level 3 of PCI HSM-gevalideerde hardware voor alle betaalsleutelbewerkingen, implementeer M-van-N-quorumcontroles die voldoen aan de vereisten voor gedeelde kennis en dubbele controle, en voer continue compliance-monitoring uit.

Kort antwoord: Waarom zijn HSM's essentieel voor PCI DSS-naleving?

PCI DSS-vereiste 3.7 (cryptografisch sleutelbeheer voor de bescherming van kaartgegevens) vereist gesplitste kennis en dubbele controle voor handmatige sleutelbewerkingen, veilige sleutelgeneratie, versleutelde sleutelopslag en gedocumenteerde sleutelbeheerprocedures. HSM's voldoen aan deze vereisten door middel van hardwarematig afgedwongen M-van-N-quorumauthenticatie (gesplitste kennis en dubbele controle), sleutelgeneratie in een FIPS-gevalideerde hardwarematige TRNG en opslag binnen een fraudebestendige grens waaruit sleutels nooit in platte tekst tevoorschijn komen. Softwarematig sleutelbeheer kan niet voldoen aan de hardwarematige beveiligingsvereisten voor de meest gevoelige betaalsleutels. Zie ons artikel over HSM's in PKI voor gerelateerd PKI-sleutelbeheer.

Wat is PCI DSS?

PCI DSS is een reeks wereldwijd erkende beveiligingsvereisten voor elke organisatie die betaalkaartgegevens verwerkt, opslaat of verzendt . Het werd in 2004 ontwikkeld door American Express, MasterCard, Discover Financial Services en JCB International en wordt beheerd door de PCI Security Standards Council (PCI SSC). PCI DSS is in de meeste rechtsgebieden geen wettelijke verplichting, maar is contractueel vereist door kaartmerken voor alle handelaars en dienstverleners die kaartgegevens verwerken.

PCI DSS v4.0, uitgebracht in maart 2022, werd op 31 maart 2024 de enige actieve versie (v3.2.1 werd buiten gebruik gesteld). Organisaties hebben tot 31 maart 2025 de tijd om te voldoen aan de best practices van PCI DSS v4.0 , die voorheen een toekomstige ingangsdatum hadden. Niet-naleving van de PCI DSS-normen kan leiden tot datalekken , reputatieschade, financiële boetes en het verlies van toegang tot kaartverwerkingsrechten.

Geschiedenis van PCI DSS

1. Creditcardfraude nam in de jaren negentig toe als gevolg van de groei van online handel; Cybersource rapporteerde een winst van 1.5 miljard dollar door online fraude; Mastercard en Visa rapporteerden verliezen van meer dan 750 miljoen dollar door online diefstal tussen 1988 en 1999.
2. Visa introduceerde het Cardholder Information Security Program (CISP) begin jaren 2000; andere merken ontwikkelden afzonderlijke programma's, wat leidde tot gefragmenteerde nalevingsvereisten voor winkeliers.
3. PCI DSS v1.0 werd gelanceerd op 15 december 2004 en verenigde de eisen van de belangrijkste merken in één enkele standaard.
4. PCI DSS v2.0 (2010) verbeterde de flexibiliteit en het inzicht van de handelaar; v3.0 (2013) richtte zich op kwetsbaarheidsanalyse en dagelijkse zakelijke gegevenspraktijken.
5. PCI DSS v4.0 (maart 2022) voegde normen voor multifactorauthenticatie, e-commerce en phishing toe, actualiseerde de wachtwoordvereisten en versterkte de vereisten voor cryptografisch sleutelbeheer onder vereiste 3.7.

PCI DSS-vereisten en hun relevantie voor HSM's

PCI DSS verdeelt zijn vereisten in 12 gebieden, verdeeld over zes categorieën. De vereisten die het meest direct worden aangepakt door de implementatie van HSM zijn:

PCI DSS-vereiste	Beschrijving	Hoe HSM's daaraan voldoen
Vereiste 3.5: bescherm opgeslagen accountgegevens	Primaire rekeningnummers (PAN's) moeten worden beschermd met behulp van sterke cryptografie en bijbehorend sleutelbeheer.	HSM's beschermen de encryptiesleutels die worden gebruikt om opgeslagen PAN's te versleutelen; de sleutel verlaat de hardwaregrens nooit in onversleutelde vorm.
Vereiste 3.7.1: beleid voor sleutelgeneratie	Cryptografische sleutels moeten worden gegenereerd met behulp van geaccepteerde methoden met een geschikte sleutelsterkte.	HSM's gebruiken hardwarematige TRNG's die voldoen aan NIST SP 800-90A voor sleutelgeneratie; RSA-2048+, ECC P-256+, AES-256 zijn goedgekeurde algoritmen.
Vereiste 3.7.3: veilige sleutelopslag	Sleutels moeten op zo min mogelijk locaties en in een zo veilig mogelijke vorm worden bewaard.	HSM's slaan sleutels op binnen de FIPS-gecertificeerde hardwaregrenzen; sleutels in rust zijn AES-256-versleuteld; onversleutelde sleutels bestaan ​​alleen in het beveiligde hardwaregeheugen tijdens actief gebruik.
Vereiste 3.7.6: gesplitste kennis en dubbele controle	Bij handmatig sleutelbeheer is het noodzakelijk om gebruik te maken van gedeelde kennis (geen enkele persoon heeft volledige toegang tot de sleutel) en dubbele controle (minimaal twee personen vereist).	HSM M-of-N quorum-authenticatie dwingt gedeelde kennis en dubbele controle af op hardwareniveau; de HSM zal gevoelige bewerkingen niet voltooien zonder het vereiste aantal fysieke authenticatiehouders.
Vereiste 3.7.4: sleutelwijzigingen aan het einde van de cryptoperiode	Cryptografische sleutels moeten worden gewijzigd wanneer hun gedefinieerde cryptoperiode afloopt.	HSM's ondersteunen gecontroleerde sleutelrotatie, waarbij de nieuwe sleutel binnen de beveiligingsgrens wordt gegenereerd; oude sleutels worden buiten gebruik gesteld en verwijderd met controlebewijs.
Vereiste 4.2: versleuteling tijdens transport	Accountgegevens moeten tijdens de overdracht via openbare netwerken worden versleuteld met behulp van sterke cryptografie.	De privésleutels voor TLS-betalingstransacties moeten worden opgeslagen in HSM's; de HSM voert de TLS-handshake uit, waardoor de privésleutel nooit in het geheugen van de webserver terechtkomt.

HSM-typen voor PCI DSS-omgevingen

Afhankelijk van uw vereisten vallen HSM's voor PCI DSS-omgevingen in twee categorieën:

Algemene HSM's ondersteunen niet-betalingsspecifieke functies: digitale handtekeningen, sleutelbeheer voor PKI, bescherming van TLS-privésleutels, codeondertekening, softwarelicenties en beheer van database-encryptiesleutels. In een PCI DSS-omgeving beschermen algemene HSM's de CA-privésleutels die TLS-certificaten ondertekenen die worden gebruikt voor veilige betalingsoverdracht, en de sleutelversleutelingssleutels (KEK's) die de opgeslagen PAN-encryptiesleutels omvatten.

Transactie- en betalings-HSM's worden gevalideerd volgens de PCI HSM-standaard en FIPS 140, en zijn specifiek ontworpen voor de activiteiten in de betaalsector: PIN-blokversleuteling en -verificatie, EMV-cryptogramgeneratie en -verificatie (Europay, MasterCard, Visa), kaartgegevensverificatie (CVV/CVV2) en het laden en beheren van betaalsleutels. Voorbeelden zijn PIN-verwerking bij geldautomaten, sleutelinjectie bij POS-terminals, authenticatie van online betalingen en cryptografie voor mobiele betalingen.

FIPS-grens en PCI HSM-validatie

De FIPS 140-grens is de fysieke en logische perimeter waarbinnen cryptografische bewerkingen plaatsvinden. Voor PCI DSS-conformiteit zorgt deze grens ervoor dat betaalsleutels (PAN-encryptiesleutels, PIN-encryptiesleutels, EMV-sleutels) worden gegenereerd en gebruikt binnen fraudebestendige hardware en nooit in onversleutelde vorm daarbuiten worden blootgesteld. FIPS 140-2 Niveau 3 is het minimum voor de meeste PCI-workloads binnen bedrijven; de PCI HSM-standaard voegt betalingsspecifieke vereisten toe bovenop de FIPS-validatie voor PIN-verwerking en andere zeer gevoelige betalingsbewerkingen.

Sleutelceremonie voor PCI DSS-sleutelbeheer

PCI DSS-vereiste 3.7.6 vereist gedeelde kennis en dubbele controle voor handmatige sleutelbeheerprocessen. Een sleutelceremonie voor betalings-HSM's is het gecontroleerde proces dat aan deze vereiste voldoet:

1. Identificatie van de beheerder: Identificeer de bevoegde sleutelbeheerders; selecteer M en N voor het quorum (minimaal 2 van de 3 voor dubbele controle); documenteer de rollen en verantwoordelijkheden van de beheerders.
2. HSM-validatieverificatie: Controleer of het FIPS 140- en/of PCI HSM-validatiecertificaat van de HSM van toepassing is op het specifieke hardwareapparaat dat in gebruik is; documenteer het certificaatnummer als bewijsmateriaal voor auditdoeleinden.
3. HSM-initialisatie: Initialiseer de HSM onder gecontroleerde omstandigheden; creëer inloggegevens voor de beveiligingsfunctionaris (SO) als M-van-N-quorum; distribueer de inloggegevens naar afzonderlijke beheerders die geen componenten delen.
4. Sleutelgeneratie: De betalingssleutels worden binnen de hardwaregrenzen gegenereerd met behulp van de TRNG van de HSM; het privésleutelmateriaal verlaat de grenzen nooit in platte tekst; het publieke sleutelmateriaal wordt geëxporteerd voor de juiste distributie.
5. Versleutelde sleutelback-up: Maak versleutelde sleutelback-ups met behulp van het back-upmechanisme van de HSM; verdeel de back-upautorisatie over de beheerders met behulp van geheimdeling; sla het back-upmateriaal op een fysiek gescheiden, beveiligde locatie op.
6. Auditdocumentatie: Stel een ondertekend ceremonieverslag op waarin alle stappen, deelnemers, HSM-serienummer, firmwareversie en sleutelidentificaties worden gedocumenteerd; bewaar dit verslag voor controledoeleinden.

Integratie- en HSM-vereisten voor PCI DSS

1. Fysieke beveiligingsvereisten

• HSM's moeten beschikken over fraudebestendige detectie- en responsmechanismen die al het opgeslagen sleutelmateriaal onmiddellijk wissen zodra er een poging tot manipulatie wordt gedetecteerd.
• De werking onder wisselende omgevingsomstandigheden (temperatuur, stroom) mag de veiligheid of functionaliteit van het apparaat niet in gevaar brengen.
• Gevoelige informatie moet binnen het beveiligde gedeelte van het HSM worden bewaard en mag niet zonder toestemming worden gewijzigd of vervangen.
• Bescherming tegen side-channel-aanvallen: het extraheren van gevoelige informatie via analyse van stroomverbruik, elektromagnetische emissie of timing moet worden voorkomen.

2. Beleid en procedures

• Duidelijke, op rollen gebaseerde toegang met specifieke geautoriseerde functies voor elke rol; beveiligingsprotocollen die ongeautoriseerde wijzigingen voorkomen.
• Het beveiligingsbeleid voor HSM moet gedocumenteerd en toegankelijk zijn; de belangrijkste beheersverantwoordelijkheden, administratieve procedures, apparaatfunctionaliteit en identificatierichtlijnen moeten worden gedefinieerd.
• Firmware-updates moeten via veilige, geautoriseerde processen verlopen; ongeautoriseerde wijzigingen aan de firmware moeten onmogelijk zijn.

3. Logische beveiligingsvereisten

• Grondige zelftests om de integriteit van de firmware en de gezondheid van het apparaat te controleren.
• Een soepele en veilige afhandeling van onverwachte invoer, opdrachten of fouten, zonder gevoelige informatie prijs te geven.
• Hoogwaardige willekeurige getallengeneratie (hardware TRNG conform NIST SP 800-90A) voor alle sleutelgeneratieprocessen.
• Beveiligde logboekregistratiemogelijkheden ter ondersteuning van audit- en compliancevereisten.

4. Cryptografische sleutelbewerkingen

• Privé- en geheime sleutels mogen nooit in platte tekst worden weergegeven tijdens het genereren, opslaan of gebruiken ervan.
• Sleutels die voor extern gebruik zijn gegenereerd, moeten na overdracht op een veilige manier van de HSM worden verwijderd.
• Strikte scheiding tussen beveiligingsdomeinen; sleutels mogen niet migreren van gebieden met een hogere beveiliging naar gebieden met een lagere beveiliging.
• Het wijzigen van de functionaliteit van het apparaat zonder de opgeslagen sleutels automatisch te wissen, moet onhaalbaar zijn.

Implementatievoorbeeld: HSM in een PCI DSS-compatibele betaalomgeving

1. Hiërarchie van betalingssleutels: De HSM genereert een hoofdsleutel (Zone Master Key of Key Encryption Key) binnen de zone; deze sleutel omvat alle andere betaalsleutels; de hoofdsleutel wordt onder M-of-N-beheer bewaard en extern opgeslagen.
2. PAN-codering: De PAN-gegevens van de kaarthouder die bij het afrekenen worden ingevoerd, worden versleuteld met een gegevensversleutelingssleutel (DEK). De DEK wordt opgeslagen in de HSM en gebruikt door de betaalapplicatie via PKCS#11 of de betaalinterface van de HSM. De PAN-gegevens worden nooit in platte tekst verzonden.
3. PIN-verwerking: De betaal-HSM versleutelt pincodes die worden ingevoerd bij geldautomaten of POS-terminals; de HSM voert de vorming, versleuteling en verificatie van de pincode uit met behulp van EMV-sleutels; de pincode verschijnt nooit in onversleutelde vorm buiten de HSM.
4. TLS-certificaatbeheer: De TLS-privésleutel die de betaalwebserver beschermt, wordt opgeslagen in de HSM; de TLS-handshake-ondertekeningsbewerkingen vinden plaats binnen de beveiligingsgrenzen; de privésleutel komt nooit in het geheugen van de webserver terecht. Zie CertSecure Manager voor geautomatiseerd beheer van de levenscyclus van TLS-certificaten.
5. Audittraject: De HSM registreert alle belangrijke bewerkingen met tijdstempels en operator-identificaties; de logs worden geëxporteerd naar een gecentraliseerd SIEM-systeem voor monitoring en bewaard voor auditdoeleinden conform PCI DSS-vereiste 10.

Richtlijnen voor storingsmodi

• Storing in HSM-apparaat zonder cluster: Alle bewerkingen met betaalsleutels mislukken; PIN-verwerking, PAN-versleuteling en TLS-ondertekening stoppen. Oplossing: implementeer minimaal twee HSM's in een cluster met gesynchroniseerd sleutelmateriaal; test failover vóór de productie.
• Quorumreferenties kwijtgeraakt: Als M-van-N beheerders niet beschikbaar zijn, kunnen administratieve handelingen waarvoor een quorum vereist is, niet worden uitgevoerd. Oplossing: wijs reservebeheerders aan; bewaar een complete set dubbele sleutels op een aparte, beveiligde locatie buiten het bedrijfsterrein; test jaarlijks het herstel van het quorum.
• Verlopen TLS-certificaten op betaalservers: De HSM-sleutel blijft geldig, maar het TLS-certificaat verloopt, wat leidt tot verbindingsproblemen bij betalingssessies. Oplossing: automatiseer de vernieuwing van het TLS-certificaat met behulp van CertSecure Manager.
• Bij de audit zijn afwijkingen geconstateerd: PCI DSS-auditors kunnen belangrijke beheerslacunes vaststellen (ontbrekende ceremoniedocumentatie, ontoereikende quorumcontroles, onbeveiligde back-up van sleutels). Oplossing: bewaar ceremoniedocumentatie; voer jaarlijkse interne PCI DSS-audits van het sleutelbeheer uit vóór de formele beoordeling.

Gevolgen van niet-naleving van PCI DSS-normen

Het niet naleven van de PCI DSS-normen kan leiden tot aanzienlijke maandelijkse boetes totdat de bedrijfsvoering aan de normen voldoet. Hoewel PCI DSS in de meeste rechtsgebieden geen wettelijke verplichting is, eisen kaartmerken contractueel naleving en kunnen ze via acquirerende banken sancties opleggen. De hoogte van de boetes hangt af van het transactievolume, de omvang van het bedrijf en de duur van de niet-naleving.

Periode van niet-naleving	Verwachte PCI-boetes op basis van transactievolume
1-3 maand	Laag volume: $5,000/maand; Hoog volume: $10,000/maand
4-6 maand	Laag volume: $25,000/maand; Hoog volume: $50,000/maand
7 + maanden	Laag volume: $50,000/maand; Hoog volume: $100,000/maand

Niet-naleving van de regels stelt consumenten ook bloot aan financieel verlies en identiteitsdiefstal en creëert aansprakelijkheid voor de organisatie in geval van een datalek. Bijkomende zakelijke gevolgen zijn onder meer het verlies van bevoegdheden voor de verwerking van kaarttransacties, een verhoogde kans op succesvolle aanvallen op de niet-conforme infrastructuur en reputatieschade door openbaarmaking van het datalek. De Magecart-aanval op Warner Music Group in 2020, die drie maanden duurde en creditcardnummers, CVV-codes en vervaldatums in gevaar bracht, illustreert de reputatie- en operationele kosten van ontoereikende bescherming van betaalgegevens.

Hoe encryptieconsultancy u kan helpen PCI DSS-conformiteit te bereiken met behulp van HSM's

Encryption Consulting biedt uitgebreide HSM-beoordelings- en ontwerpdiensten om organisaties te helpen bij het behalen en behouden van PCI DSS-conformiteit. Onze beoordeling evalueert de huidige HSM-omgeving aan de hand van PCI DSS-vereiste 3 en PCI HSM-standaarden, identificeert tekortkomingen in sleutelbeheerpraktijken en biedt prioriteitsgerichte herstelmaatregelen.

1. Huidige situatiebeoordeling: Evalueer hoe de organisatie momenteel HSM's gebruikt in relatie tot de PCI DSS-vereisten; identificeer hiaten in de documentatie van sleutelceremonies, quorumcontroles, back-upprocedures en auditregistratie.
2. Benchmarking aan de hand van PCI-standaarden: Vergelijk de HSM-configuratie met PCI DSS-vereiste 3.7 en de PCI HSM-validatievereisten; lever een analyse van de tekortkomingen met prioriteiten voor herstelmaatregelen.
3. Aanbevelingen van experts: Aanbevelingen doen voor HSM-hardware, implementatietopologie en configuratiewijzigingen om te voldoen aan de PCI-compliancevereisten; adviseren over de keuze tussen een algemene HSM en een betalings-HSM voor specifieke workloads.

Met onze adviesdiensten op het gebied van encryptie kunnen organisaties gebruikmaken van encryptieconsultancy voor een complete encryptiestrategie, auditondersteuning en de ontwikkeling van PCI DSS-sleutelbeheerbeleid. Ons team heeft ervaring met HSM-implementaties in de betaalkaartindustrie en kan het PCI-compliancetraject vereenvoudigen voor organisaties in elke fase van HSM-volwassenheid.

Conclusie

HSM's zijn cruciaal voor het behalen van PCI DSS-compliance in betaalomgevingen. PCI DSS-vereiste 3 vereist sleutelbeheercontroles waaraan alleen hardwarematig gevalideerde oplossingen volledig kunnen voldoen: gesplitste kennis en dubbele controle afgedwongen op hardwareniveau, sleutelgeneratie met behulp van gecertificeerde hardware-entropie en sleutelopslag binnen een fraudebestendige barrière waaruit sleutels nooit in platte tekst tevoorschijn komen. De gevolgen van niet-compliance, zoals maandelijkse boetes, verlies van kaartverwerkingsrechten en aansprakelijkheid voor datalekken, maken de implementatie van HSM's een zakelijke noodzaak in plaats van een technische voorkeur. Zie de gerelateerde berichten over HSM's en sleutelbeheer , HSM's in PKI en ons HSM as a Service- aanbod.

Veelgestelde Vragen / FAQ

Wat is PCI DSS en waarom is het belangrijk?

PCI DSS is een reeks wereldwijd erkende beveiligingsvereisten voor elke organisatie die betaalkaartgegevens verwerkt, opslaat of verzendt. De standaard wordt beheerd door de PCI SSC en versie 4.0 is de huidige actieve versie (sinds 31 maart 2024). Niet-naleving kan leiden tot boetes van $ 5,000 tot $ 100,000 per maand, verlies van de bevoegdheid om betalingen met betaalkaarten te verwerken en aansprakelijkheid voor fraudeverliezen na een datalek.

Welke PCI DSS-vereisten schrijven specifiek HSM's voor?

PCI DSS v4.0-vereiste 3.7 regelt het beheer van cryptografische sleutels voor de bescherming van kaartgegevens. Belangrijke subvereisten die relevant zijn voor HSM's zijn: 3.7.1 (sleutelgeneratie), 3.7.3 (veilige sleutelopslag, direct voldaan door de hardwaregrens van de HSM), 3.7.6 (gedeelde kennis en dubbele controle, voldaan door het M-van-N-quorum van de HSM) en 3.7.7 (voorkomen van ongeautoriseerde sleutelvervanging). PCI HSM is de aparte standaard voor betaal-HSM-apparaten die worden gebruikt voor PIN-verwerking en EMV-transacties.

Wat is het verschil tussen een algemene HSM en een betalings-HSM?

Algemene HSM's ondersteunen standaard cryptografische bewerkingen (sleutelbeheer, PKI, TLS, codeondertekening). Betaal-HSM's zijn gevalideerd volgens de PCI HSM-standaard en geoptimaliseerd voor betalingsspecifieke bewerkingen: PIN-blokversleuteling, EMV-cryptogramgeneratie en kaartgegevensverificatie. Algemene HSM's zijn geschikt voor CA- en TLS-sleutelbeheer in betaalomgevingen; betaal-HSM's zijn vereist voor PIN-, EMV- en kaartverificatiefuncties.

Hoe voldoen HSM's aan PCI DSS-vereiste 3.7.6 (gesplitste kennis en dubbele controle)?

Bij M-van-N-quorumauthenticatie worden de HSM-referenties verdeeld over N fysieke smartcards; M kaarten moeten gelijktijdig worden aangeboden om gevoelige bewerkingen te autoriseren. Niemand beschikt over alle referenties of kan gevoelige sleutelbewerkingen alleen uitvoeren. Het quorum wordt afgedwongen door de HSM-hardware en kan niet worden omzeild door het hostbesturingssysteem of geprivilegieerde software.

Wat zijn de gevolgen van het niet naleven van de PCI DSS-normen?

Maandelijkse boetes van $5,000 tot $100,000, afhankelijk van het transactievolume en de duur van de niet-naleving; verlies van de bevoegdheid om kaartbetalingen te verwerken; aansprakelijkheid voor fraudeverliezen; verplichte kosten voor forensisch onderzoek na een datalek; reputatieschade. Een duur van 7 maanden of langer leidt doorgaans tot de hoogste boetecategorie.

Hoe helpt Encryption Consulting bij het voldoen aan de PCI DSS-normen met behulp van HSM's?

EC biedt HSM-beoordelingen aan op basis van PCI DSS-vereiste 3 en PCI HSM-standaarden; gap-analyse en prioriteiten voor herstel; HSM-hardwareselectie en topologieontwerp voor implementatie; ontwerp van sleutelceremonieprocedures die voldoen aan vereiste 3.7.6; PKCS#11- en betalingsinterface-integratie; en adviesdiensten op het gebied van encryptie voor een volledige encryptieaudit en strategische ondersteuning.