PCI-efterlevnadsspecifikation

Publicerad: april 2021. Uppdaterad: augusti 2026. Granskad av Encryption Consultings Compliance Advisory-team.

Den här artikeln är en teknisk djupdykning på specifikationsnivå i vad PCI DSS kräver på kryptografi- och nyckelhanteringslagret: algoritm- och protokollval, hotmodellen bakom varje kontroll, nyckelförvaringsberoenden och konkreta distributionsmönster. Om ditt team istället behöver hela certifieringsvägen, handlarnivåer, SAQ-typer och vägledning på programnivå, se vår kompletterande artikel, En omfattande guide till att uppnå och upprätthålla PCI DSS-efterlevnad , som täcker det bredare efterlevnadsprogrammet. Det här inlägget finns för säkerhets- och teknikteam som redan vet att de behöver följa reglerna och nu utformar de system som måste klara en teknisk granskning av en bedömare.

Vad specificerar PCI DSS för kryptografi?

PCI DSS specificerar att all kortinnehavardata som är i vila eller under överföring måste skyddas med stark kryptografi, definierad av PCI Security Standards Council (PCI SSC) som algoritmer och nyckelstyrkor som är allmänt testade, accepterade av den internationella kryptografigemenskapen och fria från kända praktiska exploateringar vid den nyckelstorlek som används. I praktiken betyder det minst 112 bitars effektiv nyckelstyrka, vilket utesluter DES, single-key 3DES och RC4 helt och hållet, och pekar implementatörer mot AES-256, RSA vid 2048 bitar eller högre, och ECC vid 224 bitar eller högre.

En handfull termer återkommer i specifikationen och den här artikeln, så det är värt att definiera var och en exakt innan man går vidare:

• PCI DSS (Standard för säkerhet för betalningskortsindustri): den tekniska och operativa säkerhetsstandarden som upprätthålls av PCI SSC för alla organisationer som lagrar, bearbetar eller överför betalkortsdata.
• PAN (primärt kontonummer): själva kortnumret, det specifika dataelement som de flesta PCI DSS-kryptografiska kontroller finns för att skydda.
• CDE (Kortinnehavarens datamiljö): de personer, processer och den teknik som lagrar, bearbetar eller överför kortinnehavardata, plus alla system som kan påverka dessa uppgifters säkerhet.
• QSA (Kvalificerad säkerhetsbedömare)en person som är certifierad av PCI SSC för att utföra formella PCI DSS-bedömningar på plats.
• ROC (Rapport om efterlevnad): den detaljerade rapport som en QSA producerar som dokumenterar hur varje krav testades och validerades, krävs för nivå 1-handlare och de flesta tjänsteleverantörer.
• SAQ (självvärderingsformulär): det självrapporterade valideringsverktyg som mindre handlare använder i stället för en fullständig QSA-ledd revision.

Specifikationens kryptografiska krav kan delas in i tre distinkta tekniska problem: att göra lagrade PAN-nummer oläsliga (krav 3), att skydda kortinnehavardata under överföring (krav 4) och att autentisera varje användare som når CDE (krav 8). Var och en har sin egen hotmodell och sitt eget algoritm- eller protokollval, och avsnitten nedan går igenom vart och ett i den ordning en arkitekturgranskning vanligtvis tar itu med dem.

Vilka algoritmer och protokoll kräver PCI DSS?

PCI DSS kräver AES-256 eller en motsvarande algoritm för att skydda lagrade kontodata, och TLS 1.2 som den obligatoriska minimiprotokollversionen för kortinnehavardata som överförs över öppna, publika nätverk, där TLS 1.3 föredras för alla nya implementeringar. Standarden i sig hårdkodar inte en enda protokollversion i sin text, men PCI SSC:s egen vägledning utesluter SSL och tidig TLS (TLS 1.0 och 1.1) eftersom de inte längre uppfyller definitionen av stark kryptografi.

Hotmodell för data i vila och under överföring

Lagrade kortinnehavardata utsätts för databaskompromettering, missbruk av insiders, exponering av säkerhetskopiering och logg, samt lateral förflyttning från ett system med lägre känslighet till datalagret, så kontrollen måste överleva en angripare som redan har läsåtkomst till lagringslagret. Data under överföring står inför en annan hotmodell: man-in-the-middle-avlyssning, protokollnedgraderingsattacker och krypteringsnivåattacker som POODLE och BEAST som specifikt riktar sig mot SSL och tidig TLS. Ett QSA-testkrav 4 kommer att söka efter alla lyssnare som fortfarande accepterar en föråldrad protokollversion, inte bara bekräfta att TLS är aktiverat någonstans i stacken.

Vägledning för val av algoritm och protokoll

För vilande data är AES-256-GCM generellt att föredra framför CBC-läge för nya implementeringar eftersom det tillhandahåller autentiserad kryptering, som upptäcker manipulering samt döljer data, med jämförbar prestanda på moderna processorer med AES-NI-acceleration. För data under överföring, inaktivera SSL 2.0, SSL 3.0, TLS 1.0 och TLS 1.1 på varje systemkomponent som berör CDE, inklusive interna lastbalanserare och äldre kassaintegrationer, och konfigurera preferenser för chiffersviter för att gynna forward-secrecy-sviter (ECDHE-baserade) framför statiskt RSA-nyckelutbyte. PCI SSC pekar på NIST SP 800-52 som referens för TLS-konfigurationshärdning.

Avvägningar mellan prestanda och interoperabilitet

TLS 1.3 tar bort flera äldre handskaknings-rundturer och slopar kända svaga krypteringssviter, vilket minskar både anslutningslatens och risken för felkonfiguration, men vissa äldre kassaterminaler, betalnings-SDK:er och inbyggda enheter förhandlar fortfarande bara med TLS 1.2. Det är därför TLS 1.2 fortfarande är den praktiska minimibaslinjen snarare än TLS 1.3 direkt; en fasvis uppgraderingsväg som pensionerar TLS 1.2-hårdvara enligt ett definierat schema är ett mer realistiskt arkitekturbeslut än en omedelbar övergång. På lagringssidan lägger AES-256-GCM:s autentiseringstagg till en liten, fast overhead per block som är försumbar på hårdvaruaccelererade system men kan ha betydelse för begränsade inbyggda betalningsterminaler, vilket är en anledning till att dessa enheter ofta tokeniseras vid insamlingstillfället istället för att krypteras lokalt.

Implementeringsexempel: ett vanligt mönster är TLS-avslutning vid en lastbalanserare eller API-gateway konfigurerad för TLS 1.2 som minimum och TLS 1.3 att föredra, med omkryptering, inte klartext, på det interna segmentet mellan gatewayen och applikationsnivån, så att kortinnehavardata aldrig överförs oskadat ens inom organisationens eget nätverk.

Vad kräver PCI DSS-kraven 3.5 till 3.7 för nyckelhantering?

Krav 3.5, 3.6 respektive 3.7 kräver att lagrade PAN-kod (Personal Account Address) görs oläsliga, att nycklarna som skyddar den är säkrade mot avslöjande och missbruk, och att en dokumenterad livscykel styr varje nyckel från generering till förstörelse. Kryptering är bara så stark som nyckelhanteringen bakom den, och detta är den delkravsfamilj som QSA:er oftast flaggar i misslyckade bedömningar.

• Krav 3.5 kräver att PAN-numret görs oläsligt var det än lagras, med hjälp av stark kryptografi, trunkering, indextokens med en säkert lagrad pad eller envägshashing av hela PAN-numret.
• Krav 3.6 kräver att kryptografiska nycklar som används för att skydda lagrade kontodata själva är skyddade: krypterade med en separat nyckelkrypteringsnyckel, lagrade i en säker kryptografisk enhet såsom en HSM, eller uppdelade i komponenter under dubbel kontroll, med åtkomst begränsad till så få nödvändiga förvaltare.
• Krav 3.7 kräver dokumenterade procedurer över hela nyckellivscykeln: stark nyckelgenerering, säker distribution, säker lagring, rotation i slutet av en definierad kryptoperiod och pensionering eller förstöring av komprometterade eller utgångna nycklar. Det kräver också delad kunskap och dubbel kontroll för manuell nyckelhantering, och undertecknad bekräftelse från förvaltare av deras ansvar.

Nyckelhanteringsberoende: en AES-256-databaskolumn krypterad med en nyckel lagrad i en konfigurationsfil bredvid ger i princip inget riktigt skydd och är ett rutinmässigt fynd vid misslyckade utvärderingar. Varken krav 3.5:s renderings-oläslighetskontroll eller krav 4:s TLS-kontroll är meningsfull utan den förvarings- och livscykeldisciplin som 3.6 och 3.7 påför nycklarna under dem. Att centralisera den livscykeln genom en dedikerad certifikat- och nyckellivscykelplattform som CertSecure Manager ger en organisation påtvingade rotationsscheman, förvaringsansvarighet och revisionsklar rapportering istället för ett kalkylblad som manuellt spårar nyckelålder.

Vad kräver PCI DSS för flerfaktorsautentisering?

PCI DSS v4.0.1 kräver MFA för all åtkomst till kortinnehavarens datamiljö enligt krav 8.4.2 , inte krav 8.4.3, och denna kontroll har tillämpats fullt ut sedan den 31 mars 2025. Vi verifierade detta direkt för den här artikeln eftersom två andra inlägg om detta ämne inte håller med om siffran, och att få det rätt är viktigt för alla som bygger en åtkomstkontrollarkitektur mot specifikationen.

Tre relaterade delkrav under krav 8.4 är lätta att slå ihop, så det är värt att särskilja dem exakt:

• Krav 8.4.1MFA för all icke-konsoladministrativ åtkomst till CDE. Överförd från PCI DSS v3.2.1 och gällde i åratal före v4.0.
• Krav 8.4.2: Utrikesministerium för Alla Produkter åtkomst till CDE, för varje roll, från vilken plats som helst, inte bara administrativ åtkomst. Detta är den viktigaste nya kontrollen som introducerades i v4.0 och blev obligatorisk den 31 mars 2025.
• Krav 8.4.3MFA för all fjärråtkomst till nätverk som kommer från enheter utanför deras nätverk och som kan nå CDE:n, vilket omfattar både personal och fjärråtkomst från tredje part eller leverantörer. Detta krav fanns före v4.0 och förtydligades snarare än introducerades nyligen.

Krav 8.5.1 fungerar parallellt med 8.4.2 och blev även obligatoriskt den 31 mars 2025: MFA-implementeringar måste motstå kringgåning förutom genom en dokumenterad, riskbedömd undantagsprocess, kräva minst två oberoende faktorer, bekräfta att alla faktorer lyckas innan åtkomst beviljas och motstå replay-attacker. För de flesta organisationer handlar det praktiska arbetet om att utöka MFA från administratörspopulationen som redan täcks av 8.4.1 till varje applikationsanvändare, entreprenör och tredjepartsintegration som berör CDE:n, och sedan dokumentera de anti-bypass-kontroller som en bedömare specifikt kommer att be om att se bevis på.

Hur skyddar tokenisering PAN under PCI DSS?

Tokenisering skyddar PAN-numret genom att ersätta det med ett surrogatvärde, en token, vid insamlingstillfället och lagra det verkliga PAN-numret endast i ett separat, tätt avgränsat tokenvalv, så att varje nedströmssystem som vidrör token aldrig vidrör det faktiska kortnumret. Formatbevarande kryptering (FPE) är den teknik som de flesta tokeniseringsscheman använder för att hålla token med samma längd och teckenuppsättning som det ursprungliga PAN-numret, så äldre databaser, loggformat och nedströmsapplikationer behöver inte schemaändringar för att acceptera det.

Där kryptering håller PAN:ets återvinningsbara värde på plats, vilket är viktigt när nedströmssystem som återkommande fakturering eller återbetalningsbehandling fortfarande behöver det ursprungliga numret, tar tokenisering bort det verkliga PAN:et helt från miljön. Det är det som faktiskt minskar PCI DSS-bedömningens omfattning, men det introducerar ett beroende av att tokenvalvet är nåbart och tillgängligt för varje system som behöver avtokeniseras, och formatbevarande tokenisering lägger till en nätverksrundresa per avtokeniseringsanrop som är viktig vid hög transaktionsvolym.

Implementeringsexempel: en betalningsgateway tokeniserar vanligtvis PAN-numret vid insamlingstillfället och lagrar endast token i sin egen databas, vilket behåller själva tokenvalvet som det enda systemet i full PCI DSS-omfattning. Ett äldre lokalt faktureringssystem som måste behålla det riktiga PAN-numret för återkommande avgifter förlitar sig oftare på kolumnnivå- eller transparent datakryptering med AES-256, backad upp av en HSM-skyddad nyckel, eftersom att ersätta PAN-numret med en token skulle förstöra dess faktureringslogik.

Vilka HSM-krav gäller för nyckelförvaring?

En hårdvarusäkerhetsmodul (HSM) är det praktiska sättet som de flesta kompatibla organisationer uppfyller krav 3.6:s språk för "säkra kryptografiska enheter": en manipulationssäker, dedikerad apparat som genererar, lagrar och använder kryptografiska nycklar utan att någonsin exponera dem i klartext för värdapplikationen eller operativsystemet. FIPS 140-3 är den nuvarande valideringsstandarden som HSM:er bedöms mot, och säkerhetsansvariga förväntar sig i allt högre grad FIPS-validerad nyckellagring snarare än programvarubaserade nyckelvalv för miljöer med högt värde.

Organisationer väljer generellt mellan lokala HSM:er, som erbjuder maximal kontroll och är vanliga där kontraktskrav kräver det, och molnbaserad HSM-as-a-Service , som eliminerar kapitalkostnaderna och kostnaden för fysiska nyckelceremonier samtidigt som den levererar FIPS-validerad nyckellagring. Implementeringsexempel: en betalningsleverantörs tokeniseringsvalv lagrar sin huvudkrypteringsnyckel i ett HSM-kluster, och varje tokengenerering eller avtokeniseringsanrop signeras eller dekrypteras inom HSM-gränsen, så själva nyckeln lämnar aldrig validerad hårdvara.

Vilka PCI DSS-krav styr kryptografi och nyckelhantering?

Tabellen nedan mappar varje krypto- och nyckelhanteringsrelevant kravnummer till vad det täcker och den tekniska kontroll som vanligtvis uppfyller det, vilket är användbart som en snabb referens vid en arkitekturgranskning.

Krav	Vad det täcker	Typisk teknisk kontroll
3.5	Gör lagrat PAN oläsligt	AES-256-kryptering, tokenisering eller trunkering
3.6	Skydda nycklar som används för att säkra lagrade kontodata	HSM-baserad nyckellagring, nyckelkrypterande nycklar, dubbel kontroll
3.7	Dokumentera och tillämpa hela nyckellivscykeln	Definierade kryptoperioder, automatiserad rotation, förvaltargodkännande
4.2.1	Skydda kortinnehavarens data vid överföring över offentliga nätverk	TLS 1.2 minimum, TLS 1.3 föredras, ingen SSL eller tidig TLS
8.4.1	MFA för icke-konsoladministrativ åtkomst till CDE	MFA på alla administratörskonsoler och Jump Hosts
8.4.2	MFA för all åtkomst till CDE, vilken roll som helst, vilken plats som helst	MFA tillämpas vid varje CDE-autentiseringspunkt
8.4.3	MFA för fjärråtkomst som härrör från enhetens nätverk	VPN eller fjärråtkomstgateway MFA, inklusive åtkomst från tredje part

Vad är PCI DSS-efterlevnadsvalideringsprocessen?

PCI DSS-validering följer samma tekniska bedömningssekvens oavsett handlarnivå, även om testdjupet i varje steg skiljer sig åt beroende på transaktionsvolym och valideringsväg (QSA-ledd ROC kontra självutvärderad SAQ).

1. Bekräfta CDE-omfattning. Kartlägg varje system, process och nätverkssegment som lagrar, bearbetar eller överför kortinnehavardata, eller som kan påverka dess säkerhet. Segmentering är det enskilt mest effektiva sättet att minska denna omfattning.
2. Inventera kryptografiska tillgångar. Skapa en noggrann lista över varje algoritm, protokoll, certifikat och nyckel i CDE:n innan du beslutar om åtgärd; du kan inte skydda det du inte kan se.
3. Testa kryptografiska kontroller och nyckelhanteringskontroller specifikt mot krav 3, 4 och 8. Verifiera PAN-rendering, TLS-konfiguration, nyckelförvaring och MFA-täckning mot specifikationen, inte mot vad som känns säkert.
4. Åtgärda de allvarligaste bristerna först. Okrypterad lagrad PAN, föråldrade TLS-versioner och saknad MFA vid CDE-åtkomst är genomgående de allvarligaste bedömningsresultaten.
5. Fullständig formell validering. Handlare med lägre volymer fyller i tillämplig SAQ; handlare på nivå 1 och de flesta tjänsteleverantörer genomgår en QSA-ledd bedömning på plats som producerar en rapport om efterlevnad (ROC).
6. Skicka in intyget om överensstämmelse (AOC) till den förvärvande banken, med stöd av SAQ eller ROC.
7. Upprätthåll kontinuerlig validering. Kvartalsvisa ASV-skanningar, årliga penetrationstester och en årlig bekräftelse av omfattning förhindrar att kryptografiska kontroller tyst glider mellan formella bedömningar.

Begränsningar

Specifikationen är exakt, men den täcker inte allt som en verklig implementering behöver. Några begränsningar som är värda att flagga direkt:

• Att klara en bedömning är ett intyg vid en viss tidpunkt. En konfigurationsavvikelse eller ett nytt system utan omfattning efter att ROC eller AOC har signerats kan omedelbart försätta en organisation i att sluta följa reglerna igen.
• Att kryptera PAN-adressen tar inte bort den från omfånget i sig. Ett system som fortfarande lagrar krypterade kontodata förblir vanligtvis inom räckvidden; endast tokenisering som helt tar bort det verkliga PAN-numret tenderar att minska räckvidden.
• Kompenserande kontroller kräver dokumenterad noggrannhet, inte bekvämlighet. Var och en behöver en formell riskanalys och QSA-godkännande, och löst använda blir de ett sätt att undvika att åtgärda det underliggande gapet.
• Standarden utvecklas. Den här artikeln återspeglar PCI DSS v4.0.1 från och med augusti 2026. En framtida v5.0-revision kan omnumrera krav eller förskjuta tidslinjer, så verifiera mot den nuvarande publicerade standarden innan du fattar arkitekturbeslut.
• Tolkningen av QSA kan variera för frågor som ligger på gränsen till omfattning. Att engagera din QSA tidigt i ett arkitekturbeslut undviker omarbete senare.

Vad skulle krypteringskonsulter rekommendera?

Vår ståndpunkt, efter att ha stöttat granskningar av kryptografisk arkitektur för organisationer från regionala handlare till nationella banker, är att de flesta PCI DSS-kryptoprogram misslyckas med en bedömning inte för att en kontroll saknas, utan för att den har boltats på snarare än utformats mot specifikationen från början. Här är vad vi faktiskt skulle göra, i ordning.

Börja med en riktig kryptografisk inventering. Innan du väljer mellan kryptering och tokenisering eller granskning av TLS-konfigurationen, bygg en noggrann inventering av varje krypteringssvit, protokoll, certifikat och nyckel som berör CDE:n.

Centralisera hanteringen av nycklar och certifikats livscykel. Vi driftsätter CertSecure Manager för att ge organisationer obligatoriska rotationsscheman, ansvarsskyldighet för förvaltare och centraliserad insyn, vilket direkt adresserar de fynd i krav 3.6 och 3.7 som oftast dyker upp i misslyckade bedömningar. För huvudnycklar som skyddar tokeniseringsvalv eller bulkkryptering rekommenderar vi generellt FIPS 140-3-validerad lagring via lokala HSM:er eller HSM-as-a-Service , beroende på operativ mognad och befintlig infrastruktur.

Utöka MFA avsiktligt, inte bara tekniskt. Att uppfylla krav 8.4.2:s bokstav är enkelt; att uppfylla krav 8.5.1:s avsikt att förhindra kringgåning kräver mer disciplin. Vi hjälper kunder att dokumentera varje legitimt MFA-undantag, koppla det till en kompenserande kontroll och ta bort informella kringgåningar som ackumuleras över tid.

Hantera molnlagrad kortinnehavardata med samma förvaringsdisciplin som lokala data. Våra Cloud Data Protection-tjänster utökar HSM-baserad nyckelförvaring och krypteringsarkitektur till moln- och hybridmiljöer, så att tokeniseringsvalv eller krypterade datalager som lagras i molnet uppfyller samma krav för nyckelhantering som en lokal driftsättning.

Behandla validering som kontinuerlig, inte årlig. Våra Compliance Advisory-tjänster kombinerar PCI DSS med det bredare regelverk som många kunder står inför, inklusive DORA och NIS2, så kryptografiska kontroller som byggts för PCI DSS tjänar överlappande mandat istället för att byggas om för varje enskilt krav. Om du är tidigt i den här processen är det första steget med högst hävstångseffekt en gapbedömning mot krav 3, 4 och 8 specifikt, eftersom det är där kostnaden för att göra fel är högst.

Slutsats

PCI DSS kryptografiska specifikation är snävare och mer precis än vad standardens fullständiga 12 krav kan antyda: starka algoritmer och TLS 1.2+ för data i rörelse, en dokumenterad nyckelhanteringslivscykel enligt krav 3.6 och 3.7, MFA för all CDE-åtkomst enligt krav 8.4.2, och ett medvetet val mellan kryptering och tokenisering för lagrade PAN. Få de fyra rätt, backa upp dem med HSM-skyddad nyckelförvaring, och det mesta av vad en QSA testar på det tekniska lagret faller på plats.

Inget av detta ersätter disciplinerad validering: kvartalsvisa skanningar, årliga penetrationstester och en genuin vana att behandla kryptolagret som en levande arkitektur snarare än en engångskonstruktion. Om du vill ha en andra uppfattning om hur dina kryptografiska kontroller håller sig mot specifikationen kan våra krypteringsrådgivningstjänster hjälpa till att avgränsa gapet och prioritera åtgärdande åtgärder.

Vanliga frågor om partihandel med mat och dryck

Är PCI DSS MFA-för-all-CDE-åtkomstmandatet Krav 8.4.2 eller 8.4.3? Det är Krav 8.4.2. Krav 8.4.2 föreskriver MFA för all åtkomst till kortinnehavarens datamiljö, för varje roll och från vilken plats som helst, och har tillämpats sedan den 31 mars 2025. Krav 8.4.3 är en separat, snävare kontroll som föreskriver MFA specifikt för fjärrnätverksåtkomst som kommer från en plats utanför enhetens nätverk.

Kräver PCI DSS en specifik krypteringsalgoritm? PCI DSS nämner inte en obligatorisk algoritm i sin text, men kräver stark kryptografi med minst 112 bitars effektiv nyckelstyrka. AES-256 är de facto-standarden för lagrad kontodata eftersom den uttryckligen erkänns som stark kryptografi och fungerar bra i hårdvara.

Krävs tokenisering, eller räcker kryptering? Ingetdera är individuellt obligatoriskt; PCI DSS-krav 3.5 accepterar kryptering, tokenisering, trunkering eller envägshashing för att göra PAN-adressen oläslig. Tokenisering föredras generellt när målet är att minska omfattningen, eftersom borttagning av den verkliga PAN-adressen från ett system kan ta bort systemet från bedömningsomfattningen, medan krypterad lagring generellt inte gör det.

Måste PCI DSS-nycklar lagras i en HSM? Krav 3.6 nämner inte HSM:er specifikt, men det kräver att nycklar skyddas i en av en liten uppsättning former, inklusive lagring "inom en säker kryptografisk enhet". En HSM validerad enligt FIPS 140-3 är det vanligaste sättet som organisationer uppfyller det språket, och QSA:er förväntar sig i allt högre grad FIPS-validerad hårdvara för högvärdig nyckelförvaring snarare än programvarubaserade nyckelvalv.

Hur skiljer sig den här artikeln från EU:s allmänna guide till PCI DSS-efterlevnad? Den här artikeln är en djupdykning på specifikationsnivå, kryptografi och nyckelhantering, avsedd för säkerhets- och teknikteam som utformar system mot standarden. Vår kompletterande guide, En omfattande guide till att uppnå och upprätthålla PCI DSS-efterlevnad , täcker hela certifieringsprogrammet: handlarnivåer, SAQ-typer och hela vägen till ett AOC.

Referensprojekt

• PCI DSS v4.0.1 standarddokument, PCI Security Standards Council
• Nu är det dags att anta de framtidsinriktade kraven i PCI DSS v4.x, PCI SSC-bloggen
• PCI DSS 4.0 MFA-krav: Vad du behöver veta, Schellman
• PCI DSS version 4.0 flerfaktorsautentisering, BDO
• Migrering från SSL och tidig TLS, PCI SSC-informationstillägg
• PCI SSC-dokumentbibliotek