Was ist der PCI-DSS-Prüfumfang, und warum ist er wichtig?
Der Payment Card Industry Data Security Standard (PCI-DSS) gilt für jede Organisation, die Karteninhaberdaten (CHD) oder sensible Authentifizierungsdaten (SAD) speichert, verarbeitet oder überträgt. Größe und Beschaffenheit Ihrer Karteninhaberdatenumgebung (CDE) bestimmen den Umfang Ihrer PCI-DSS-Prüfung und den damit verbundenen Aufwand.
Die Einhaltung von PCI-DSS erfordert erhebliche Ressourcen. Eine Händlerprüfung nach SAQ D, der umfassendsten Variante, umfasst 12 Anforderungsbereiche, über 250 Unteranforderungen, vierteljährliche Netzwerkscans, jährliche Penetrationstests und eine ausführliche Dokumentation der Richtlinien. Ein kleinerer Prüfumfang senkt unmittelbar den Aufwand und die jährlichen Kosten. Je nach Größe der Organisation liegen diese zwischen mehreren Tausend und mehreren Hunderttausend Dollar.
Grundprinzip: Eine Systemkomponente liegt außerhalb des Prüfumfangs, wenn sie keine Karteninhaberdaten speichert, verarbeitet oder überträgt und nicht mit der CDE verbunden ist. Tokenisierung ist der wichtigste Weg, Systeme aus dem Prüfumfang zu nehmen.
Das Problem der Karteninhaberdatenumgebung (CDE)
Zur CDE gehören alle Systemkomponenten, die Karteninhaberdaten speichern, verarbeiten oder übertragen. In einer typischen E-Commerce-Umgebung ohne Tokenisierung können das sein:
- Webserver, die Kartennummern aus Formularen empfangen
- Anwendungsserver, die Transaktionen verarbeiten
- Datenbankserver, die Transaktionsdaten speichern
- Protokollserver, die Transaktionsprotokolle empfangen
- Analysesysteme, die Transaktionsdaten abfragen
- CRM-Systeme, die den Zahlungsverlauf von Kunden speichern
- Sicherungssysteme, die Transaktionsdaten archivieren
- Jedes Netzwerksegment, das diese Systeme verbindet
Jedes dieser Systeme muss alle jeweils geltenden PCI-DSS-Anforderungen erfüllen. Schon ein falsch konfigurierter Server in der CDE kann dazu führen, dass die Prüfung nicht bestanden wird. Eine sauber segmentierte Tokenisierung kann den Prüfumfang verringern. Der Tresor für die Token, die Tokenisierungssysteme und die Schlüsselverwaltung bleiben jedoch Gegenstand der Prüfung.
Tokenisierung, Verschlüsselung oder Maskierung: Was verringert den Prüfumfang?
| Methode | Umkehrbar | Auswirkung auf den PCI-DSS-Prüfumfang | Anwendungsfall |
|---|---|---|---|
| Tokenisierung | Ja, mit Tresor | Kann den Prüfumfang verringern – Systeme, die ausschließlich Token enthalten, können außerhalb des Prüfumfangs liegen, sobald ein Prüfer die Trennung, die fehlende Rückführbarkeit der Token und das Fehlen einer Verbindung zur CDE bestätigt | Wiederkehrende Abrechnung, CRM, Analysen, Protokolle |
| Verschlüsselung | Ja, mit Schlüssel | Verschlüsselte Karteninhaberdaten bleiben in der Regel im Prüfumfang, es sei denn, die betreffende Organisation hat keinen Zugriff auf die Entschlüsselungsschlüssel (FAQ des PCI SSC) | Daten bei der Übertragung, Sicherungsarchive |
| Maskierung | Nein | Verringert den Prüfumfang für Anzeigesysteme – die Quelldaten bleiben jedoch im Prüfumfang | Anzeigen im Kundendienst, die nur die letzten 4 Ziffern zeigen |
| Kürzung | Nein | Nimmt Systeme aus dem Prüfumfang – der ursprüngliche Wert wird dabei dauerhaft zerstört | Belege und Prüfprotokolle, für die keine vollständige PAN benötigt wird |
Die Leitlinien des PCI Security Standards Council sind eindeutig: Tokenisierung kann den PCI-DSS-Prüfumfang für Systeme verringern, die ausschließlich Token verarbeiten, sofern das Tokenisierungssystem selbst sicher und getrennt ist. Der Token-Tresor bleibt im Prüfumfang. Er wird jedoch zu einem kleinen, besonders abgesicherten System statt einer weit verzweigten CDE.
Wie die Luhn-Prüfsumme Fehler in Kartennummern erkennt
Bevor Sie eine Kartennummer erkennen oder tokenisieren, müssen Sie prüfen, ob es sich um eine tatsächliche Kartennummer und nicht um eine zufällige Ziffernfolge handelt. Der Luhn-Algorithmus (ISO/IEC 7812-1) ist das Standardverfahren zur Prüfung von Zahlungskartennummern.
Dazu verdoppelt der Algorithmus von rechts aus jede zweite Ziffer. Von Ergebnissen über 9 zieht er 9 ab. Dann addiert er alle Ziffern und prüft, ob die Summe durch 10 teilbar ist:
def luhn_valid(card_number: str) -> bool:
"""Prüft eine Kartennummer mit dem Luhn-Algorithmus (ISO/IEC 7812-1)."""
digits = [int(d) for d in card_number.replace(" ", "").replace("-", "")]
checksum = 0
for i, digit in enumerate(reversed(digits)):
if i % 2 == 1:
digit *= 2
if digit > 9:
digit -= 9
checksum += digit
return checksum % 10 == 0
# Beispiele:
luhn_valid("4532015112830366") # True – gültige Visa-Testnummer
luhn_valid("4532015112830367") # False – ungültig (letzte Ziffer geändert)
luhn_valid("1234567890123456") # False – keine echte Kartennummeranonymize.solutions verwendet den integrierten Kartennummernerkenner von Presidio, der eine Luhn-Prüfsumme prüft. Zusätzliche Mustererkenner für die Formate von Visa, Mastercard und American Express prüfen die Prüfsumme nicht. Kontrollieren Sie deren Treffer daher, bevor Sie darauf Entscheidungen über den Prüfumfang stützen.
Die 3 Strategien zur Verringerung des Prüfumfangs
Strategie 1: Punkt-zu-Punkt-Tokenisierung bei der Zahlungsannahme
Ersetzen Sie die Kartennummer möglichst früh in Ihrer Verarbeitungskette durch ein Token. Im Idealfall geschieht das bereits auf der Zahlungsseite, bevor die Nummer Ihre Anwendungsserver erreicht. Nutzen Sie eine validierte Lösung zur Punkt-zu-Punkt-Verschlüsselung (P2PE) oder einen Tokenisierungsdienst auf der JavaScript-Ebene.
Ergebnis: Ihre Anwendungsserver, Ihre Datenbank und alle nachgelagerten Systeme sehen ausschließlich Token. Vorbehaltlich Ihrer Prüfung können sie dadurch aus dem PCI-DSS-Prüfumfang fallen.
Strategie 2: Gespeicherte Daten nachträglich tokenisieren
Durchsuchen Sie vorhandene Datenbanken und Dateien mit dem Analyse-Endpunkt von anonym.legal nach gespeicherten Kartennummern. Ersetzen Sie gefundene Nummern durch Token und speichern Sie die Zuordnung in einem sicheren Tresor. Löschen oder überschreiben Sie die ursprünglichen Kartennummern.
Ergebnis: Altsysteme werden von gespeicherten Kartendaten bereinigt. Der Token-Tresor und die Schlüsselverwaltung bleiben für diese Datensätze im Prüfumfang.
Strategie 3: Protokoll- und Analysedaten bereinigen
Anwendungsprotokolle, Fehlerspuren und Analyseereignisse enthalten häufig versehentlich im Klartext protokollierte Kartennummern. Das ist eine der häufigsten Ursachen für einen größeren PCI-DSS-Prüfumfang. Richten Sie bei der Protokollierung eine Anonymisierung ein, die Kartennummern erkennt und ersetzt, bevor sie in den Protokollspeicher geschrieben werden.
Ergebnis: Protokollsysteme, Systeme für Sicherheitsinformationen und Ereignisverwaltung (SIEM) sowie Analyseplattformen können vorbehaltlich Ihrer Prüfung aus dem PCI-DSS-Prüfumfang genommen werden.
Erkennung von Kartendaten: Was wird erfasst?
Es gibt keine fertigen voreingestellten PCI-DSS-Erkennungsregeln. Sie wählen die Arten personenbezogener Daten in Ihren eigenen voreingestellten Erkennungsregeln aus. Die Erkennung umfasst:
- Primäre Kontonummer (PAN): Kartennummern einschließlich der Formate von Visa, Mastercard und American Express; der integrierte Erkenner von Presidio prüft die Luhn-Prüfsumme
- Name des Karteninhabers: der auf der Karte stehende Name; er wird durch Erkennung benannter Entitäten mittels Sprachverarbeitung (NLP) im Zusammenhang mit Zahlungsdaten erkannt
- Nicht erkannt: Ablaufdaten, CVV-/CVC-/CID-Codes, Daten von Spur 1 und Spur 2 sowie PINs oder PIN-Blöcke
- Bankkonto- und Bankleitzahlen: ACH-Zahlungsdaten, darunter IBAN, BBAN und ABA-Bankleitzahlen
Umsetzung: Beispiel für die REST-API
import requests
API_KEY = "your-api-key"
text = "Payment processed: card 4532-0151-1283-0366, cardholder: John Smith, amount: $299.00"
# Schritt 1: Kartennummern und Namen in einer Protokollzeile erkennen
detect_response = requests.post(
"https://anonym.legal/api/presidio/analyze",
headers={"Authorization": f"Bearer {API_KEY}"},
json={"text": text, "language": "en", "entities": ["CREDIT_CARD", "PERSON"]}
)
analyzer_results = detect_response.json()["results"]
# Jedes Ergebnis enthält einen Datenbereich mit Typ, Bewertung und Positionen
# Schritt 2: Erkannte Werte durch Platzhalter ersetzen
anonymize_response = requests.post(
"https://anonym.legal/api/presidio/anonymize",
headers={"Authorization": f"Bearer {API_KEY}"},
json={
"text": text,
"analyzer_results": analyzer_results,
"operators": {
"CREDIT_CARD": {"type": "replace"}, # Platzhalter wie <CREDIT_CARD>
"PERSON": {"type": "replace"}
}
}
)
safe_log = anonymize_response.json()["text"]
# Kartennummern und Namen werden durch Platzhalter wie <CREDIT_CARD> ersetzt;
# es entstehen keine Token, die das ursprüngliche Format bewahren.
# Hinweis: Der Betrag bleibt erhalten – er ist kein sensibler PCI-DSS-Wert.Grenzen und ehrliche Einschränkungen
Tokenisierung ist leistungsfähig, hat aber Grenzen. Sie verringert den PCI-DSS-Prüfumfang nur, wenn der Token-Tresor und der Dienst zur Rückwandlung von Token selbst sauber getrennt und geprüft werden. Ein unzureichend getrennter Tresor verlagert den Prüfumfang lediglich, statt ihn zu verkleinern. Tokenisierung eignet sich auch nicht für jedes Datenfeld. Daten, mit denen Sie im Klartext rechnen müssen oder die Sie an Verarbeiter weitergeben müssen, die den tatsächlichen Wert benötigen, lassen sich nicht durch Token ersetzen. Betrachten Sie die Verringerung des Prüfumfangs als eine von mehreren Schutzmaßnahmen, nicht als Ersatz für sämtliche PCI-DSS-Anforderungen.