PCI-Konformitätsspezifikation

Veröffentlicht: April 2021. Aktualisiert: August 2026. Geprüft vom Compliance Advisory Team von Encryption Consulting.

Dieser Artikel bietet einen detaillierten, technischen Einblick in die Anforderungen des PCI DSS auf der kryptografischen Ebene und im Schlüsselmanagement: Algorithmus- und Protokollauswahl, das Bedrohungsmodell hinter jeder Kontrollmaßnahme, Abhängigkeiten bei der Schlüsselverwaltung und konkrete Bereitstellungsmuster. Benötigt Ihr Team stattdessen den vollständigen Zertifizierungsprozess, Händlerstufen, SAQ-Typen und Programmleitfäden, empfehlen wir Ihnen unseren Begleitartikel „ Ein umfassender Leitfaden zur Erreichung und Aufrechterhaltung der PCI-DSS-Konformität“ , der das gesamte Konformitätsprogramm abdeckt. Dieser Beitrag richtet sich an Sicherheits- und Entwicklungsteams, die bereits wissen, dass sie die Anforderungen erfüllen müssen und nun Systeme entwickeln, die die technische Prüfung durch einen Gutachter bestehen müssen.

Was legt PCI DSS für Kryptografie fest?

PCI DSS schreibt vor, dass alle Karteninhaberdaten, sowohl im Ruhezustand als auch während der Übertragung, durch starke Kryptografie geschützt werden müssen. Der PCI Security Standards Council (PCI SSC) definiert diese als Algorithmen und Schlüssellängen, die umfassend getestet, von der internationalen Kryptografie-Community anerkannt und bei der verwendeten Schlüssellänge frei von bekannten praktischen Sicherheitslücken sind. In der Praxis bedeutet dies eine effektive Schlüssellänge von mindestens 112 Bit. Dadurch scheiden DES, Single-Key-3DES und RC4 aus, und Implementierer sollten AES-256, RSA mit mindestens 2048 Bit und ECC mit mindestens 224 Bit verwenden.

Einige Begriffe tauchen in der Spezifikation und in diesem Artikel immer wieder auf, daher lohnt es sich, jeden einzelnen genau zu definieren, bevor wir fortfahren:

• PCI DSS (Datensicherheitsstandard der Zahlungskartenindustrie): der vom PCI SSC aufrechterhaltene technische und operative Sicherheitsstandard für alle Organisationen, die Zahlungskartendaten speichern, verarbeiten oder übermitteln.
• PAN (Primäre Kontonummer): die Kartennummer selbst, das spezifische Datenelement, das die meisten kryptografischen Kontrollen des PCI DSS schützen sollen.
• CDE (Cardholder Data Environment): die Personen, Prozesse und Technologien, die Karteninhaberdaten speichern, verarbeiten oder übermitteln, sowie alle Systeme, die die Sicherheit dieser Daten beeinträchtigen könnten.
• QSA (Qualifizierter Sicherheitsgutachter): eine vom PCI SSC zertifizierte Person zur Durchführung formaler PCI DSS-Vor-Ort-Bewertungen.
• ROC (Bericht über die Einhaltung der Vorschriften): der detaillierte Bericht, den ein QSA erstellt und in dem dokumentiert wird, wie jede Anforderung getestet und validiert wurde; erforderlich für Händler der Stufe 1 und die meisten Dienstleister.
• SAQ (Selbstbeurteilungsfragebogen): das Selbstauskunfts-Validierungstool, das kleinere Händler anstelle eines vollständigen, von einem QSA durchgeführten Audits verwenden.

Die kryptografischen Anforderungen der Spezifikation lassen sich in drei separate technische Probleme unterteilen: die Unlesbarkeit gespeicherter PAN-Daten (Anforderung 3), den Schutz von Karteninhaberdaten während der Übertragung (Anforderung 4) und die Authentifizierung jedes Benutzers, der die CDE erreicht (Anforderung 8). Jedes dieser Probleme hat sein eigenes Bedrohungsmodell und seinen eigenen Algorithmus oder sein eigenes Protokoll. Die folgenden Abschnitte erläutern die einzelnen Probleme in der Reihenfolge, in der sie typischerweise bei einer Architekturprüfung behandelt werden.

Welche Algorithmen und Protokolle erfordert PCI DSS?

PCI DSS fordert AES-256 oder einen gleichwertigen Algorithmus zum Schutz gespeicherter Kontodaten sowie TLS 1.2 als vorgeschriebene Mindestprotokollversion für Karteninhaberdaten, die über offene, öffentliche Netzwerke übertragen werden. Für neue Implementierungen wird TLS 1.3 empfohlen. Der Standard selbst legt keine bestimmte Protokollversion fest, jedoch schließen die Richtlinien des PCI SSC SSL und frühe TLS-Versionen (TLS 1.0 und 1.1) aus, da diese die Definition starker Kryptografie nicht mehr erfüllen.

Bedrohungsmodell für ruhende und übertragene Daten

Gespeicherte Karteninhaberdaten sind durch Datenbankkompromittierung, Missbrauch durch Insider, Offenlegung von Backups und Protokollen sowie durch laterale Ausbreitung von einem System mit geringerer Sensibilität in den Datenspeicher gefährdet. Daher muss die Kontrolle einem Angreifer standhalten, der bereits Lesezugriff auf die Speicherschicht hat. Daten während der Übertragung sind einem anderen Bedrohungsmodell ausgesetzt: Man-in-the-Middle-Angriffe, Protokoll-Downgrade-Angriffe und Schwachstellen auf Verschlüsselungsebene wie POODLE und BEAST, die speziell SSL und frühe TLS-Versionen angreifen. Eine QSA-Testanforderung 4 prüft, ob ein Listener noch eine veraltete Protokollversion akzeptiert, und bestätigt nicht nur, ob TLS irgendwo im Protokollstapel aktiviert ist.

Leitfaden zur Auswahl von Algorithmen und Protokollen

Für ruhende Daten wird AES-256-GCM bei neuen Implementierungen im Allgemeinen dem CBC-Modus vorgezogen, da es authentifizierte Verschlüsselung bietet, Manipulationen erkennt und die Daten bei vergleichbarer Leistung auf modernen CPUs mit AES-NI-Beschleunigung schützt. Deaktivieren Sie für übertragene Daten SSL 2.0, SSL 3.0, TLS 1.0 und TLS 1.1 auf allen Systemkomponenten, die auf die CDE zugreifen, einschließlich interner Load Balancer und älterer POS-Integrationen. Konfigurieren Sie die Cipher Suite-Präferenz so, dass Forward-Secrecy-Suites (ECDHE-basiert) dem statischen RSA-Schlüsselaustausch vorgezogen werden. Der PCI SSC verweist auf NIST SP 800-52 als Referenz für die Härtung der TLS-Konfiguration.

Abwägungen zwischen Leistung und Interoperabilität

TLS 1.3 beseitigt mehrere veraltete Handshake-Roundtrips und entfernt bekannte schwache Verschlüsselungssuiten, wodurch sowohl die Verbindungslatenz als auch das Risiko von Fehlkonfigurationen reduziert werden. Einige ältere Kassenterminals, Zahlungs-SDKs und eingebettete Geräte verwenden jedoch weiterhin nur TLS 1.2. Daher bleibt TLS 1.2 die praktische Mindestvoraussetzung und nicht TLS 1.3. Ein schrittweiser Upgrade-Pfad, der TLS-1.2-Hardware nach einem festgelegten Zeitplan ersetzt, ist eine realistischere Architekturentscheidung als eine sofortige Umstellung. Auf der Speicherseite verursacht das Authentifizierungs-Tag von AES-256-GCM einen geringen, festen Overhead pro Block, der auf hardwarebeschleunigten Systemen vernachlässigbar ist, aber auf ressourcenbeschränkten eingebetteten Zahlungsterminals relevant sein kann. Dies ist einer der Gründe, warum diese Geräte häufig erst bei der Datenerfassung tokenisieren, anstatt die Daten lokal zu verschlüsseln.

Beispiel für die Bereitstellung: Ein gängiges Muster ist die TLS-Terminierung an einem Load Balancer oder API-Gateway, das für TLS 1.2 als Minimum und TLS 1.3 bevorzugt konfiguriert ist, mit erneuter Verschlüsselung, nicht im Klartext, auf dem internen Segment zwischen dem Gateway und der Anwendungsschicht, sodass Karteninhaberdaten niemals unverschlüsselt übertragen werden, selbst nicht innerhalb des eigenen Netzwerks der Organisation.

Welche Anforderungen stellen die PCI DSS-Standards 3.5 bis 3.7 an das Schlüsselmanagement?

Die Anforderungen 3.5, 3.6 und 3.7 verlangen, dass gespeicherte PAN-Daten unlesbar gemacht werden, die zugehörigen Schlüssel vor Offenlegung und Missbrauch geschützt sind und ein dokumentierter Lebenszyklus jeden Schlüssel von der Generierung bis zur Vernichtung regelt. Die Stärke einer Verschlüsselung hängt maßgeblich von der zugrunde liegenden Schlüsselverwaltung ab. Genau diese Unteranforderungsgruppe wird in QSAs am häufigsten bei fehlgeschlagenen Bewertungen beanstandet.

• Voraussetzung 3.5 erfordert, dass die PAN überall dort, wo sie gespeichert ist, unlesbar gemacht wird, und zwar durch starke Kryptographie, Kürzung, Indextoken mit einem sicher gespeicherten Pad oder Einweg-Hashing der gesamten PAN.
• Voraussetzung 3.6 erfordert, dass die zum Schutz gespeicherter Kontodaten verwendeten kryptografischen Schlüssel selbst geschützt werden: verschlüsselt mit einem separaten Schlüsselverschlüsselungsschlüssel, gespeichert in einem sicheren kryptografischen Gerät wie einem HSM oder aufgeteilt in Komponenten unter doppelter Kontrolle, wobei der Zugriff auf die geringstmögliche Anzahl notwendiger Verwahrer beschränkt ist.
• Voraussetzung 3.7 Erfordert dokumentierte Verfahren für den gesamten Schlüssellebenszyklus: sichere Schlüsselerzeugung, sichere Verteilung, sichere Speicherung, Rotation nach Ablauf einer definierten Kryptoperiode sowie die Außerbetriebnahme oder Vernichtung kompromittierter oder abgelaufener Schlüssel. Zudem sind geteilte Kenntnisse und Vier-Augen-Prinzipien für manuelle Schlüsselverwaltungsvorgänge sowie eine unterzeichnete Bestätigung der Verantwortlichkeiten durch die Schlüsselverwalter erforderlich.

Abhängigkeit vom Schlüsselmanagement: Eine mit AES-256 verschlüsselte Datenbankspalte, deren Schlüssel in einer Konfigurationsdatei gespeichert ist, bietet praktisch keinen Schutz und ist ein häufiges Problem bei Sicherheitsüberprüfungen. Weder die in Anforderung 3.5 vorgesehene Kontrolle zur Unlesbarkeit noch die in Anforderung 4 vorgesehene TLS-Kontrolle sind ohne die in 3.6 und 3.7 festgelegte Verwahrung und den Lebenszyklus der zugrunde liegenden Schlüssel sinnvoll. Die Zentralisierung dieses Lebenszyklus über eine dedizierte Zertifikats- und Schlüssellebenszyklusplattform wie CertSecure Manager ermöglicht es Unternehmen, verbindliche Rotationspläne einzuhalten, die Verantwortlichkeit der Verwahrer zu klären und revisionssichere Berichte zu erstellen, anstatt die Lebensdauer von Schlüsseln manuell in Tabellenkalkulationen zu erfassen.

Was fordert PCI DSS für die Multi-Faktor-Authentifizierung?

PCI DSS v4.0.1 fordert gemäß Anforderung 8.4.2 (nicht 8.4.3) die Multi-Faktor-Authentifizierung (MFA) für alle Zugriffe auf die Karteninhaberdatenumgebung. Diese Regelung wird seit dem 31. März 2025 vollständig durchgesetzt . Wir haben dies für diesen Artikel direkt überprüft, da zwei andere Beiträge zu diesem Thema unterschiedliche Angaben machen. Die korrekte Angabe ist jedoch für alle, die eine Zugriffskontrollarchitektur gemäß der Spezifikation entwickeln, von entscheidender Bedeutung.

Drei zusammenhängende Unteranforderungen unter Anforderung 8.4 können leicht verwechselt werden, daher ist es sinnvoll, sie genau zu unterscheiden:

• Voraussetzung 8.4.1: Multi-Faktor-Authentifizierung (MFA) für alle administrativen Zugriffe auf die CDE (Common Data Environment) außerhalb der Konsole. Übernommen aus PCI DSS v3.2.1 und jahrelang vor v4.0 in Kraft.
• Voraussetzung 8.4.2: MFA für alle Der Zugriff auf die CDE ist für jede Rolle und von jedem Standort aus möglich, nicht nur für Administratoren. Dies ist die wichtigste Neuerung in Version 4.0 und wird seit dem 31. März 2025 verpflichtend.
• Voraussetzung 8.4.3Die Multi-Faktor-Authentifizierung (MFA) ist für alle Fernzugriffe von außerhalb des Unternehmensnetzwerks erforderlich, die das zentrale Endgerät (CDE) erreichen können. Dies gilt gleichermaßen für Mitarbeiter sowie für Fernzugriffe von Drittanbietern oder Lieferanten. Diese Anforderung bestand bereits vor Version 4.0 und wurde lediglich präzisiert, nicht neu eingeführt.

Anforderung 8.5.1 ergänzt 8.4.2 und ist seit dem 31. März 2025 ebenfalls verpflichtend: MFA-Implementierungen müssen Umgehungsversuche verhindern, außer durch ein dokumentiertes, risikobewertetes Ausnahmeverfahren. Sie müssen mindestens zwei unabhängige Faktoren erfordern, die erfolgreiche Überprüfung aller Faktoren vor der Zugriffsgewährung bestätigen und Replay-Angriffen widerstehen. Für die meisten Organisationen besteht die praktische Umsetzung darin, die MFA von den bereits unter 8.4.1 abgedeckten Administratoren auf alle Anwendungsnutzer, Auftragnehmer und Drittanbieterintegrationen auszuweiten, die mit der CDE interagieren. Anschließend müssen die Maßnahmen zur Verhinderung von Umgehungen dokumentiert werden, deren Nachweis ein Prüfer explizit verlangen wird.

Wie schützt die Tokenisierung die PAN gemäß PCI DSS?

Die Tokenisierung schützt die PAN, indem sie diese bei der Erfassung durch einen Ersatzwert, ein Token, ersetzt und die eigentliche PAN ausschließlich in einem separaten, streng geschützten Token-Tresor speichert. Dadurch wird sichergestellt, dass kein nachgelagertes System, das auf das Token zugreift, jemals die tatsächliche Kartennummer berührt. Die formatbewahrende Verschlüsselung (FPE) ist die Technik, die die meisten Tokenisierungsverfahren verwenden, um die Länge und den Zeichensatz des Tokens an die der ursprünglichen PAN anzupassen. So müssen ältere Datenbanken, Protokollformate und nachgelagerte Anwendungen keine Schemaänderungen vornehmen, um das Token zu akzeptieren.

Während die Verschlüsselung den Wert der PAN (Permanent Account Number) erhält – was wichtig ist, wenn nachgelagerte Systeme wie die Abrechnung wiederkehrender Zahlungen oder die Bearbeitung von Rückbuchungen die ursprüngliche Nummer benötigen –, entfernt die Tokenisierung die echte PAN vollständig aus der Umgebung. Dadurch wird der Umfang der PCI-DSS-Prüfung reduziert. Allerdings entsteht dadurch die Abhängigkeit, dass der Token-Speicher für jedes System, das eine Detokenisierung durchführen muss, erreichbar und verfügbar sein muss. Zudem führt die formatbewahrende Tokenisierung zu einem zusätzlichen Netzwerk-Roundtrip pro Detokenisierungsaufruf, was bei hohem Transaktionsvolumen relevant ist.

Beispiel für die Implementierung: Ein Zahlungsgateway tokenisiert die PAN typischerweise bei der Erfassung und speichert nur das Token in seiner eigenen Datenbank. Der Token-Tresor selbst ist somit das einzige System, das vollständig dem PCI-DSS-Standard unterliegt. Ein älteres, lokal installiertes Abrechnungssystem, das die echte PAN für wiederkehrende Gebühren benötigt, verwendet häufiger eine spaltenbasierte oder transparente Datenverschlüsselung mit AES-256, abgesichert durch einen HSM-geschützten Schlüssel. Der Grund dafür ist, dass das Ersetzen der PAN durch ein Token die Abrechnungslogik beeinträchtigen würde.

Welche HSM-Anforderungen gelten für die Schlüsselverwahrung?

Ein Hardware-Sicherheitsmodul (HSM) ist die gängigste Methode, mit der die meisten konformen Organisationen die Anforderungen von Requirement 3.6 hinsichtlich „sicherer kryptografischer Geräte“ erfüllen: ein manipulationssicheres, dediziertes Gerät, das kryptografische Schlüssel generiert, speichert und verwendet, ohne sie jemals im Klartext an die Host-Anwendung oder das Betriebssystem weiterzugeben. FIPS 140-3 ist der aktuelle Validierungsstandard, anhand dessen HSMs bewertet werden, und QSAs erwarten zunehmend FIPS-validierte Schlüsselspeicher anstelle von softwarebasierten Schlüsselspeichern für sensible Umgebungen.

Unternehmen entscheiden sich in der Regel zwischen lokalen HSMs, die maximale Kontrolle bieten und dort üblich sind, wo vertragliche Anforderungen dies erfordern, und Cloud-basierten HSM-as-a-Services . Letztere eliminieren die Investitionskosten und den Aufwand für die physische Schlüsselverwaltung und bieten dennoch FIPS-konforme Schlüsselspeicherung. Beispiel: Der Tokenisierungs-Vault eines Zahlungsabwicklers speichert seinen Master-Verschlüsselungsschlüssel in einem HSM-Cluster. Jeder Aufruf zur Token-Generierung oder -Detokenisierung wird innerhalb des HSM signiert bzw. entschlüsselt, sodass der Schlüssel selbst niemals validierte Hardware verlässt.

Welche PCI-DSS-Anforderungen regeln Kryptografie und Schlüsselmanagement?

Die nachstehende Tabelle ordnet jeder Anforderungsnummer im Bereich Kryptografie und Schlüsselverwaltung den jeweiligen Inhalten und den technischen Kontrollmaßnahmen zu, die diese Anforderungen typischerweise erfüllen. Sie dient als schnelle Referenz bei einer Architekturprüfung.

Anforderung	Was es abdeckt	Typische technische Kontrolle
3.5	Gespeicherte PAN-Dateien unlesbar machen	AES-256-Verschlüsselung, Tokenisierung oder Kürzung
3.6	Schützen Sie die Schlüssel, die zum Sichern gespeicherter Kontodaten verwendet werden.	HSM-gestützter Schlüsselspeicher, Schlüsselverschlüsselungsschlüssel, Vier-Augen-Prinzip
3.7	Den gesamten Schlüssellebenszyklus dokumentieren und durchsetzen	Definierte Kryptoperioden, automatische Rotation, Verwahrersignatur
4.2.1	Schutz von Karteninhaberdaten bei der Übertragung über öffentliche Netzwerke	Mindestens TLS 1.2, TLS 1.3 bevorzugt, kein SSL oder ältere TLS-Versionen.
8.4.1	MFA für den administrativen Zugriff auf die CDE außerhalb der Konsole.	MFA auf allen Admin-Konsolen und Jump-Hosts
8.4.2	Multi-Faktor-Authentifizierung für alle Zugriffe auf die CDE, jede Rolle, jeder Standort	MFA wird an jedem CDE-Authentifizierungspunkt erzwungen
8.4.3	MFA für Fernzugriffe von außerhalb des Netzwerks der Organisation	VPN- oder Remote-Access-Gateway-MFA, einschließlich Zugriff von Drittanbietern

Was ist der PCI-DSS-Konformitätsvalidierungsprozess?

Die PCI-DSS-Validierung folgt unabhängig vom Händlerlevel der gleichen technischen Bewertungssequenz, wobei sich der Umfang der Tests in jeder Phase je nach Transaktionsvolumen und Validierungspfad (QSA-geführte ROC versus selbstbewertete SAQ) unterscheidet.

1. CDE-Bereich bestätigen. Erfassen Sie jedes System, jeden Prozess und jedes Netzwerksegment, das Karteninhaberdaten speichert, verarbeitet oder überträgt oder deren Sicherheit beeinträchtigen könnte. Segmentierung ist der mit Abstand effektivste Weg, diesen Umfang einzugrenzen.
2. Inventarisierung kryptografischer Vermögenswerte. Erstellen Sie eine genaue Liste aller Algorithmen, Protokolle, Zertifikate und Schlüssel in der CDE, bevor Sie über Abhilfemaßnahmen entscheiden; man kann nicht schützen, was man nicht sieht.
3. Prüfen Sie die kryptografischen und Schlüsselverwaltungskontrollen insbesondere anhand der Anforderungen 3, 4 und 8. Überprüfen Sie die PAN-Wiedergabe, die TLS-Konfiguration, die Schlüsselverwaltung und die MFA-Abdeckung anhand der Spezifikation und nicht anhand dessen, was sich sicher anfühlt.
4. Beheben Sie zuerst die gravierendsten Mängel. Unverschlüsselte gespeicherte PAN-Nummern, veraltete TLS-Versionen und fehlende MFA beim CDE-Zugriff sind durchweg die schwerwiegendsten Feststellungen bei der Bewertung.
5. Vollständige formale Validierung. Händler mit geringerem Umsatzvolumen füllen den entsprechenden SAQ aus; Händler der Stufe 1 und die meisten Dienstleister unterziehen sich einer von einem QSA geleiteten Vor-Ort-Bewertung, die einen Bericht über die Einhaltung der Vorschriften (Report on Compliance, ROC) erstellt.
6. Reichen Sie die Konformitätsbescheinigung (AOC) ein. an die erwerbende Bank, abgesichert durch die SAQ oder ROC.
7. Kontinuierliche Validierung sicherstellen. Vierteljährliche ASV-Scans, jährliche Penetrationstests und eine jährliche Überprüfung des Geltungsbereichs verhindern, dass kryptografische Kontrollen zwischen formalen Bewertungen unbemerkt vernachlässigt werden.

Einschränkungen

Die Spezifikation ist präzise, ​​deckt aber nicht alle Anforderungen einer realen Implementierung ab. Einige Einschränkungen sollten ausdrücklich erwähnt werden:

• Das Bestehen einer Prüfung ist eine Bestätigung zu einem bestimmten Zeitpunkt. Eine Abweichung von der Konfiguration oder ein nicht im Leistungsumfang enthaltenes neues System nach Unterzeichnung des ROC oder AOC kann dazu führen, dass eine Organisation sofort wieder die Compliance-Vorgaben nicht mehr erfüllt.
• Die Verschlüsselung der PAN entfernt diese nicht automatisch aus dem Geltungsbereich. Ein System, das weiterhin verschlüsselte Kontodaten speichert, bleibt im Allgemeinen im Geltungsbereich; nur die Tokenisierung, die die eigentliche PAN vollständig entfernt, reduziert tendenziell den Geltungsbereich.
• Kompensierende Kontrollen erfordern dokumentierte Strenge, nicht Bequemlichkeit. Für jede dieser Maßnahmen ist eine formale Risikoanalyse und die Genehmigung durch einen Qualitätssicherungsbeauftragten erforderlich; werden sie zu ungenau angewendet, dient dies dazu, die eigentliche Lücke nicht schließen zu müssen.
• Der Standard entwickelt sich weiter. Dieser Artikel spiegelt den Stand von PCI DSS v4.0.1 (August 2026) wider. Eine zukünftige Revision v5.0 kann die Anforderungen neu nummerieren oder die Zeitpläne verschieben. Prüfen Sie daher vor Architekturentscheidungen den aktuell veröffentlichten Standard.
• Die Auslegung von QSA kann bei Grenzfragen zur Abgrenzung variieren. Die frühzeitige Einbindung Ihres QSA in eine Architekturentscheidung vermeidet spätere Nacharbeiten.

Was würde Encryption Consulting empfehlen?

Unsere Position, nachdem wir kryptografische Architekturprüfungen für Organisationen vom regionalen Handel bis zur nationalen Bank unterstützt haben, ist, dass die meisten PCI-DSS-Kryptografieprogramme nicht aufgrund fehlender Kontrollen scheitern, sondern weil sie nachträglich hinzugefügt und nicht von Anfang an gemäß der Spezifikation konzipiert wurden. Im Folgenden beschreiben wir unsere Vorgehensweise.

Beginnen Sie mit einem vollständigen kryptografischen Inventar. Bevor Sie sich zwischen Verschlüsselung und Tokenisierung entscheiden oder die TLS-Konfiguration überprüfen, erstellen Sie ein genaues Inventar aller Cipher Suites, Protokolle, Zertifikate und Schlüssel, die mit der CDE in Berührung kommen.

Zentralisieren Sie das Schlüssel- und Zertifikatslebenszyklusmanagement. Wir setzen CertSecure Manager ein , um Unternehmen verbindliche Rotationspläne, Verantwortlichkeit der Verwahrer und zentrale Transparenz zu bieten und so die Anforderungen 3.6 und 3.7, die am häufigsten bei fehlgeschlagenen Bewertungen auftreten, direkt zu erfüllen. Für Masterkeys zum Schutz von Tokenisierungs-Vaults oder Massenverschlüsselung empfehlen wir in der Regel FIPS 140-3-konforme Speicherung über lokale HSMs oder HSM-as-a-Service , abhängig von der betrieblichen Reife und der vorhandenen Infrastruktur.

Erweitern Sie die Multi-Faktor-Authentifizierung (MFA) bewusst, nicht nur technisch. Die formale Erfüllung von Anforderung 8.4.2 ist unkompliziert; die Umsetzung der Umgehungsschutz-Intention von Anforderung 8.5.1 erfordert mehr Disziplin. Wir unterstützen unsere Mandanten dabei, jede legitime Ausnahme von der MFA zu dokumentieren, sie mit einer kompensierenden Kontrollmaßnahme zu verknüpfen und informelle Umgehungen, die sich im Laufe der Zeit ansammeln, zu beseitigen.

Behandeln Sie in der Cloud gespeicherte Karteninhaberdaten mit denselben strengen Sicherheitsvorkehrungen wie lokal gespeicherte Daten. Unsere Cloud-Datenschutzdienste erweitern die HSM-gestützte Architektur für Schlüsselverwaltung und Verschlüsselung auf Cloud- und Hybridumgebungen, sodass Tokenisierungs-Vaults oder verschlüsselte Datenspeicher in der Cloud denselben Anforderungen an das Schlüsselmanagement genügen wie eine lokale Bereitstellung.

Behandeln Sie die Validierung als kontinuierlich, nicht als jährlich. Unsere Compliance-Beratungsleistungen verknüpfen die Arbeit mit PCI DSS mit dem breiteren regulatorischen Umfeld, dem viele unserer Kunden gegenüberstehen, einschließlich DORA und NIS2. So erfüllen kryptografische Kontrollen, die für PCI DSS entwickelt wurden, sich überschneidende Anforderungen, anstatt für jede einzelne neu entwickelt werden zu müssen. Wenn Sie sich noch am Anfang dieses Prozesses befinden, ist der wirkungsvollste erste Schritt eine Gap-Analyse speziell der Anforderungen 3, 4 und 8, da hier die Kosten von Fehlern am höchsten sind.

Fazit

Die kryptografische Spezifikation von PCI DSS ist präziser und genauer, als die zwölf Anforderungen des Standards vermuten lassen: starke Algorithmen und TLS 12+ für die Datenübertragung, ein dokumentierter Schlüsselverwaltungszyklus gemäß den Anforderungen 3.6 und 3.7, Multi-Faktor-Authentifizierung (MFA) für alle CDE-Zugriffe gemäß Anforderung 8.4.2 sowie die bewusste Wahl zwischen Verschlüsselung und Tokenisierung für gespeicherte PAN-Nummern. Werden diese vier Anforderungen erfüllt und durch HSM-geschützte Schlüsselverwaltung abgesichert, ist ein Großteil der technischen Anforderungen einer QSA-Prüfung erfüllt.

Nichts davon ersetzt die konsequente Validierung: vierteljährliche Scans, jährliche Penetrationstests und die konsequente Praxis, die Kryptoschicht als dynamische Architektur und nicht als einmaliges Projekt zu betrachten. Wenn Sie eine zweite Meinung dazu einholen möchten, wie Ihre kryptografischen Kontrollen den Spezifikationen entsprechen, helfen Ihnen unsere Beratungsleistungen im Bereich Verschlüsselung dabei, Schwachstellen zu identifizieren und die Behebung zu priorisieren.

Häufig gestellte Fragen

Handelt es sich bei der PCI-DSS-Vorschrift zur Multi-Faktor-Authentifizierung (MFA) für alle Zugriffe auf Karteninhaberdaten (CDE) um Anforderung 8.4.2 oder 8.4.3? Es handelt sich um Anforderung 8.4.2. Diese schreibt die MFA für jeden Zugriff auf die Karteninhaberdatenumgebung vor, unabhängig von Rolle und Standort, und ist seit dem 31. März 2025 in Kraft. Anforderung 8.4.3 ist eine separate, enger gefasste Regelung, die die MFA speziell für den Fernzugriff auf das Netzwerk von außerhalb des Unternehmensnetzwerks vorschreibt.

Ist für PCI DSS ein bestimmter Verschlüsselungsalgorithmus erforderlich? PCI DSS legt keinen bestimmten Algorithmus fest, fordert aber eine starke Kryptografie mit einer effektiven Schlüssellänge von mindestens 112 Bit. AES-256 ist der De-facto-Standard für gespeicherte Kontodaten, da es explizit als starke Kryptografie anerkannt ist und sich in Hardware bewährt hat.

Ist Tokenisierung erforderlich oder reicht Verschlüsselung aus? Beides ist nicht zwingend vorgeschrieben; PCI DSS-Anforderung 3.5 akzeptiert Verschlüsselung, Tokenisierung, Kürzung oder Einweg-Hashing, um die PAN unlesbar zu machen. Tokenisierung ist im Allgemeinen vorzuziehen, wenn die Reduzierung des Prüfumfangs das Ziel ist, da das Entfernen der echten PAN aus einem System dieses System aus dem Prüfumfang herausnehmen kann, während verschlüsselte Speicherung dies in der Regel nicht tut.

Müssen PCI-DSS-Schlüssel in einem HSM gespeichert werden? Anforderung 3.6 nennt HSMs nicht explizit, verlangt aber, dass Schlüssel in einer von wenigen Formen geschützt werden, darunter die Speicherung „in einem sicheren kryptografischen Gerät“. Ein nach FIPS 140-3 validiertes HSM ist die gängigste Methode, mit der Unternehmen diese Anforderung erfüllen, und QSAs erwarten zunehmend FIPS-validierte Hardware für die sichere Aufbewahrung wichtiger Schlüssel anstelle von softwarebasierten Schlüsselspeichern.

Worin unterscheidet sich dieser Artikel von ECs allgemeinem Leitfaden zur PCI-DSS-Konformität? Dieser Artikel bietet einen detaillierten Einblick in die Spezifikationen, Kryptografie und Schlüsselverwaltung und richtet sich an Sicherheits- und Entwicklungsteams, die Systeme gemäß dem Standard entwerfen. Unser Begleitleitfaden „ Umfassender Leitfaden zur Erreichung und Aufrechterhaltung der PCI-DSS-Konformität “ behandelt das gesamte Zertifizierungsprogramm: Händlerstufen, SAQ-Typen und den vollständigen Weg zur AOC-Zertifizierung.

Referenzen

• PCI DSS v4.0.1 Standarddokument, PCI Security Standards Council
• Jetzt ist es an der Zeit, die zukunftsorientierten Anforderungen von PCI DSS v4.x zu erfüllen (PCI SSC Blog).
• PCI DSS 4.0 MFA-Anforderungen: Was Sie wissen müssen, Schellman
• PCI DSS Version 4.0 Multi-Faktor-Authentifizierung, BDO
• Migration von SSL und frühen TLS-Systemen, PCI SSC Informationsergänzung
• PCI SSC-Dokumentenbibliothek