Leitfaden zur Datenanonymisierung nach PCI-DSS
Ein praktischer Leitfaden für Organisationen, die Zahlungskartendaten verarbeiten. Er behandelt Arten von Karteninhaberdaten, die Luhn-Prüfung, Tokenisierung und Verschlüsselung sowie die Verringerung des PCI-Prüfumfangs durch Anonymisierung.
Was ist PCI-DSS?
Der Payment Card Industry Data Security Standard (PCI-DSS) umfasst Sicherheitsanforderungen des PCI Security Standards Council. Dieser wurde von Visa, Mastercard, American Express, Discover und JCB gegründet. Version 3.2.1 wurde am 31. März 2024 zurückgezogen. Danach galt v4.0 als aktiver Standard. Dessen Anforderungen mit späterem Geltungsbeginn wurden am 31. März 2025 verbindlich. Die derzeit veröffentlichte Version ist v4.0.1.
Was PCI-DSS schützt
PCI-DSS schützt Karteninhaberdaten (CHD) und sensible Authentifizierungsdaten (SAD). Entscheidend ist die primäre Kontonummer (PAN): Wenn ein System eine PAN speichert, verarbeitet oder überträgt, gelten dafür die PCI-DSS-Anforderungen.
Für wen PCI-DSS gilt
PCI-DSS gilt für jede Organisation, die Karteninhaberdaten speichert, verarbeitet oder überträgt: Händler, Zahlungsabwickler, Acquirer (Händlerbanken), Kartenherausgeber und Dienstleister. Die Compliance-Stufe hängt vom jährlichen Transaktionsvolumen ab (Stufe 1: über 6 Millionen; Stufe 4: unter 20.000).
Prüfumfang verringern
Das Anonymisieren oder Tokenisieren von Karteninhaberdaten kann den PCI-Prüfumfang verringern, wenn Architektur und Segmentierung validiert sind. Wenn ein System die PAN nie speichert, verarbeitet oder überträgt, gelten die PCI-DSS-Anforderungen für dieses System nicht. Das senkt Aufwand und Kosten der Prüfung erheblich.
Karteninhaberdaten und sensible Authentifizierungsdaten
PCI-DSS unterscheidet zwei Kategorien geschützter Daten. Für ihre Speicherung, ihren Schutz und ihre Anonymisierung gelten unterschiedliche Regeln.
Karteninhaberdaten (CHD)
Diese Daten dürfen gespeichert werden, wenn sie gemäß PCI-DSS geschützt sind:
- Primäre Kontonummer (PAN) — Die 13- bis 19-stellige Kartennummer. Bei Speicherung muss sie unlesbar gemacht werden, etwa durch Verschlüsselung, Kürzung, Tokenisierung oder Bildung eines Hashwerts.
- Name des Karteninhabers — Der Name, wie er auf der Karte steht. Bei gemeinsamer Speicherung mit der PAN muss er geschützt werden.
- Ablaufdatum — Monat und Jahr. Bei gemeinsamer Speicherung mit der PAN muss es geschützt werden.
- Servicecode — Ein 3- oder 4-stelliger Wert vom Magnetstreifen. Bei gemeinsamer Speicherung mit der PAN muss er geschützt werden.
Sensible Authentifizierungsdaten (SAD)
Nach der Autorisierung dürfen sie NIEMALS gespeichert werden, auch nicht verschlüsselt:
- Vollständige Spurdaten — Sämtliche Magnetstreifen- oder Chipdaten. Sie enthalten PAN, Ablaufdatum, Servicecode und herstellerspezifische Daten.
- CAV2/CVC2/CVV2/CID — Der aufgedruckte 3- oder 4-stellige Prüfcode der Karte. Er wird bei Transaktionen ohne Vorlage der Karte verwendet.
- PIN/PIN-Block — Die persönliche Identifikationsnummer. Sie dient der Prüfung des Karteninhabers an Kassenterminals.
Die PAN ist das entscheidende Merkmal. Ihr Vorhandensein löst die PCI-DSS-Anforderungen aus. Werden Name, Ablaufdatum oder Servicecode ohne PAN gespeichert, unterliegen sie nicht PCI-DSS. Andere Vorschriften wie die Datenschutz-Grundverordnung (DSGVO) können dennoch gelten.
Luhn-Prüfsumme zur Erkennung von Kreditkartennummern
Der Luhn-Algorithmus (Modulo 10) ist die branchenübliche Prüfsumme zur Validierung von Kreditkartennummern. Er erkennt versehentliche Übertragungsfehler. Für eine genaue Erkennung personenbezogener Daten ist er unverzichtbar: Zahlenfolgen, die wie Kartennummern aussehen, aber die Prüfsumme nicht bestehen, werden verworfen. Das verringert Fehlalarme.
So funktioniert der Luhn-Algorithmus
- Gehen Sie von der rechten Ziffer, der Prüfziffer, nach links und verdoppeln Sie jede zweite Ziffer.
- Ist das Ergebnis der Verdopplung größer als 9, ziehen Sie 9 davon ab.
- Addieren Sie alle Ziffern, sowohl die veränderten als auch die unveränderten.
- Ist die Summe modulo 10 gleich null, ist die Nummer gültig.
Beispiel: 4532 0151 2345 6789
Der Luhn-Algorithmus prüft diese Nummer Ziffer für Ziffer. Eine gültige Prüfsumme bestätigt, dass die Nummer dem mathematischen Muster der Kartenherausgeber folgt. Eine ungültige Prüfsumme bedeutet, dass die Folge keine echte Kartennummer ist. Damit entfällt ein Fehlalarm.
Warum die Luhn-Prüfung für die Erkennung personenbezogener Daten wichtig ist
Ohne Luhn-Prüfung könnte jede 13- bis 19-stellige Zahlenfolge als Kreditkarte markiert werden. Seriennummern, Referenzkennungen, Zeitstempel und andere Daten ohne Personenbezug würden Fehlalarme auslösen. Die Mustererkennung von anonymize.solutions führt die Luhn-Prüfung automatisch aus, sodass nur mathematisch gültige Kartennummern erkannt werden. Das ist der Unterschied zwischen einer Erkennung, die Fehlalarme erzeugt, und einer, die verwertbare Ergebnisse liefert.
Tokenisierung und Verschlüsselung nach PCI-DSS
PCI-DSS-Anforderung 3 verlangt, dass gespeicherte PANs unlesbar gemacht werden. Dafür gibt es zwei wesentliche Ansätze: Tokenisierung und Verschlüsselung. Sie unterscheiden sich in ihren Folgen für den PCI-Prüfumfang, die Nutzbarkeit der Daten und den Betriebsaufwand.
| Merkmal | Tokenisierung | Verschlüsselung |
|---|---|---|
| Verfahren | PAN durch einen Ersatzwert ohne mathematischen Bezug ersetzen | PAN mit einem kryptografischen Verfahren und einem Schlüssel umwandeln |
| Umkehrbarkeit | Über eine Abfrage im Token-Tresor umkehrbar | Mit dem Entschlüsselungsschlüssel umkehrbar |
| Einfluss auf den PCI-Prüfumfang | Kann den Prüfumfang verringern, wenn eine prüfende Person bestätigt, dass das Token-System isoliert und nicht rückführbar ist | Bleibt im Allgemeinen im Prüfumfang, es sei denn, die betreffende Stelle hat keinen Zugriff auf die Entschlüsselungsschlüssel |
| Schlüsselverwaltung | Verwaltung des Token-Tresors erforderlich | Verwaltung des gesamten Lebenszyklus kryptografischer Schlüssel erforderlich |
| Nutzbarkeit der Daten | Formaterhaltende Token möglich, etwa mit gleicher Länge und sichtbaren letzten 4 Ziffern | Der Geheimtext verändert das Datenformat, es sei denn, es wird formaterhaltende Verschlüsselung (FPE) eingesetzt |
| Am besten geeignet für | Die Verringerung des PCI-Prüfumfangs in Systemen, die die echte PAN nicht benötigen | Den Schutz gespeicherter PANs in Systemen, die einen umkehrbaren Zugriff benötigen |
Weitere nach PCI zugelassene Methoden
PCI-DSS erlaubt außerdem die Kürzung der PAN auf einen Teil ihrer Ziffern, etwa die ersten 6 und die letzten 4, sowie die kryptografische Bildung eines Hashwerts mit Schlüssel. PCI DSS v4.0 verlangt für Hashwerte einen Schlüssel. Keine dieser Methoden nimmt ein System automatisch aus dem PCI-Prüfumfang; maßgeblich ist Ihre validierte Architektur. Auch gekürzte PANs mit den ersten 6 und letzten 4 Ziffern können je nach Zusammenhang Schutz erfordern.
Der Ansatz von anonymize.solutions
Unsere fünf Schutzmethoden: Durch Platzhalter ersetzen (eine Kennzeichnung wie <CREDIT_CARD>, kein Token-Tresor), Entfernen (dauerhaft), Maskieren (kürzen, sodass nur die letzten 4 Ziffern sichtbar bleiben), Hashwert bilden (einfaches SHA-256 ohne Schlüssel, also nicht der von PCI DSS v4.0 verlangte Hashwert mit Schlüssel) und Verschlüsseln (umkehrbar mit AES). Wählen Sie die Methode je Art personenbezogener Daten oder je Arbeitsablauf.
Prüfliste zur Umsetzung der Anonymisierung nach PCI-DSS
Dieser Plan führt Sie Schritt für Schritt durch die Verringerung des PCI-Prüfumfangs und den Schutz von Karteninhaberdaten durch Anonymisierung.
Datenflüsse von Karteninhaberdaten erfassen
Ermitteln Sie alle Systeme, die PANs speichern, verarbeiten oder übertragen: Zahlungs-Gateways, Kassenterminals, Onlinehandelsplattformen, Datenbanken, Protokolle, Sicherungen und externe Dienstleister.
Möglichkeiten zur Verringerung des Prüfumfangs ermitteln
Prüfen Sie, welche Systeme die vollständige PAN tatsächlich benötigen und welche mit tokenisierten, gekürzten oder gehashten Werten arbeiten können. Jedes System, das aus dem PCI-Prüfumfang herausfällt, verringert Aufwand und Kosten der Prüfung.
Automatische Erkennung von Kartennummern einführen
Setzen Sie die Mustererkennung mit Luhn-Prüfsummenprüfung ein. Durchsuchen Sie Datenbanken, Protokolle, E-Mails, Dokumente und Sicherungen nach offengelegten PANs. Erkennen Sie alle großen Kartenmarken: Visa, Mastercard, Amex, Discover, JCB und UnionPay.
Schutzmethode je System wählen
Ersetzen Sie PANs in Analysesystemen durch Platzhalter. Maskieren Sie sie in Anzeigen für Kunden, sodass nur die letzten 4 Ziffern sichtbar sind. Verschlüsseln Sie PANs in Systemen, die umkehrbaren Zugriff benötigen. Entfernen Sie sie aus Protokollen und Sicherungen.
Sicherstellen, dass sensible Authentifizierungsdaten nie gespeichert werden
Prüfen Sie, dass sensible Authentifizierungsdaten wie CVV, vollständige Spurdaten und PINs nach der Autorisierung niemals gespeichert werden. Richten Sie Erkennungsregeln ein, um solche Daten in Protokollen, Datenbanken und Dokumenten zu finden und zu entfernen.
Schlüsselverwaltung einführen
Richten Sie für verschlüsselte PANs eine PCI-konforme Schlüsselverwaltung ein. Dazu gehören Erzeugung, Verteilung, Speicherung, Wechsel und Vernichtung der Schlüssel. anonymize.solutions verwendet AES mit Schlüsseln je Dateneinheit; bei der Anmeldung werden Schlüssel mit Argon2id abgeleitet.
Laufende Überwachung einrichten
Planen Sie regelmäßige Prüfungen aller Systeme auf offengelegte PANs. Neue PANs können an unerwarteten Stellen auftauchen: in Supportanfragen, Chatprotokollen, Fehlermeldungen und E-Mail-Anhängen. Die automatische Erkennung findet sie, bevor daraus Compliance-Verstöße werden.
Dokumentieren und auf die Prüfung vorbereiten
Führen Sie Prüfprotokolle über alle Maßnahmen zum Schutz von Kartendaten. Dokumentieren Sie, wie die Anonymisierung den Prüfumfang verringert. Bereiten Sie Nachweise für die Prüfung durch einen Qualified Security Assessor (QSA) oder anhand eines Self-Assessment Questionnaire (SAQ) vor.
Wie anonymize.solutions bei PCI-DSS hilft
Die Erkennung und der Schutz sind auf Zahlungskartendaten ausgerichtet. Kartennummern werden anhand von Mustern erkannt. Der integrierte Kartenerkenner von Presidio ergänzt eine Luhn-Prüfsummenprüfung.
Erkennung mit Luhn-Prüfung
Kartennummern werden mit den Formaten von Visa, Mastercard und American Express abgeglichen. Der integrierte Kartenerkenner von Presidio ergänzt eine Luhn-Prüfsummenprüfung. Wir veröffentlichen keine Vergleichsmessung zu Genauigkeit oder Geschwindigkeit.
Ihre eigenen voreingestellten Erkennungsregeln
Das Produkt enthält keine voreingestellten Erkennungsregeln für PCI-DSS. Stellen Sie die Regeln aus den benötigten Arten personenbezogener Daten selbst zusammen, etwa für Kartennummern und Namen von Karteninhabern. Ablaufdaten, Servicecodes und CVV-Codes werden nicht als eigene Datenarten erkannt.
Prüfumfang verringern
Anonymisieren Sie PANs, bevor sie nachgelagerte Systeme erreichen. Analyse-, Protokoll-, Sicherungs- und Berichtssysteme, die entfernte oder maskierte Daten erhalten, können aus dem PCI-Prüfumfang herausfallen, sobald Ihre Prüfung dies bestätigt.
Verarbeitung im Arbeitsspeicher
Der Erkennungsdienst muss den zu prüfenden Text lesen. Er verarbeitet ihn im Arbeitsspeicher auf Hetzner-Servern in Falkenstein, Deutschland. Der Text wird nur dann verschlüsselt gespeichert, wenn Sie den Verlauf einschalten, oder als Token-Zuordnung für eine umkehrbare Anonymisierung. Diese Zuordnung bleibt standardmäßig 24 Stunden erhalten, bei gewählter dauerhafter Speicherung bis zu 30 Tage.
Finanzkennungen
Über Kreditkarten hinaus erkennt die Mustererkennung IBANs mit MOD-97-Prüfung, Bankkontonummern, Bankleitzahlen und weitere Finanzkennungen, die für PCI-DSS-Umgebungen relevant sind.
Stapelverarbeitung
Die Größe eines Stapels hängt von Ihrem Tarif ab. Das ist ideal für Datenbankexporte, Protokolldateien und Abläufe zur stapelweisen Zahlungsverarbeitung, in denen Karteninhaberdaten in größerem Umfang bereinigt werden müssen.
Was Anonymisierung nicht abdeckt
Die Anonymisierung personenbezogener Daten ist ein wirksames Mittel, um den PCI-DSS-Prüfumfang zu verringern. Sie ersetzt jedoch nicht alle Compliance-Maßnahmen. Hier eine ehrliche Einschätzung ihrer Grenzen.
Systeme zur Transaktionsverarbeitung
Anonymisierung lässt sich auf gespeicherte Daten und auf Daten anwenden, die an KI- oder Analysesysteme übertragen werden. Für die laufende Zahlungsabwicklung, bei der die echte PAN zur Autorisierung benötigt wird, kann sie nicht eingesetzt werden. Dort ist Tokenisierung auf Ebene des Zahlungs-Gateways die geeignete Maßnahme.
Keine eigenständige Compliance-Lösung
Anonymisierung verringert den Prüfumfang. PCI-DSS-Compliance erfordert außerdem Firewalls, Zugriffskontrollen, Verschlüsselung gespeicherter Daten, Prüfungen auf Schwachstellen und Penetrationstests. Anonymisierung mindert das Risiko einer Offenlegung von Daten, deckt aber nicht den gesamten Maßnahmenkatalog ab.
Abwägung bei der Nichtumkehrbarkeit
Echte Anonymisierung ist per Definition nicht umkehrbar. Wenn ein nachgelagerter Prozess die ursprüngliche PAN später wiederherstellen muss, etwa für Rückbelastungen, Streitfälle oder den Abgleich, benötigen Sie eine umkehrbare Pseudonymisierung statt vollständiger Anonymisierung. Der Nachteil: Pseudonymisierte Daten können weiterhin regulatorischen Anforderungen unterliegen.
Gilt das für Ihre Organisation?
Dieser Leitfaden ist allgemein; Ihre Pflichten sind es nicht. Nennen Sie uns Ihre Branche und sagen Sie uns, wohin Ihre Daten gelangen dürfen. Wir sagen Ihnen, was für Sie gilt.
PCI-DSS-Compliance selbst ausprobieren
Sehen Sie die Kartenerkennung mit Luhn-Prüfung und die Verringerung des Prüfumfangs im Einsatz:
Auf Servern in Deutschland — anonym.legal
Unsere Server stehen in Deutschland. 267 Arten personenbezogener Daten, 48 Sprachen. Kostenloser Tarif, danach ab 3 € im Monat.
anonym.legal öffnen ↗Auf Ihrem Rechner — anonym.plus
Ein lokal arbeitendes Desktop-Programm. Der Text verlässt den Rechner nie. 317 eigene Mustererkenner. Für einen Rechner kostenlos, danach eine einmalig bezahlte Lizenz ab 149 €.
anonym.plus öffnen ↗