Kartendaten stellen für Unternehmen ein bekanntes Haftungsrisiko dar. Die weltweiten durchschnittlichen Kosten einer Datenschutzverletzung beliefen sich im Jahr 2025 auf 4,44 Millionen $. Jeder Server, jede Protokolldatei und jedes Backup, die eine primäre Kontonummer (Primary Account Number, PAN) speichern, werden Teil dessen, was der Payment Card Industry Data Security Standard (PCI DSS) als Karteninhaberdaten-Umgebung (Cardholder Data Environment, CDE) bezeichnet, und jeder Aspekt dieser Umgebung unterliegt Compliance-Anforderungen.
Die Tokenisierung ändert, was sich tatsächlich in dieser Umgebung befindet, indem die PAN durch einen Ersatzwert ausgetauscht wird, der für sich genommen keinen verwertbaren Nutzen hat. Wenn Sie die Tokenisierung richtig implementieren, können Sie Ihre Compliance-Verpflichtungen auf einen Bruchteil dessen reduzieren, was sie andernfalls wären. Im Folgenden behandeln wir, wie die Tokenisierung zur PCI-Konformität funktioniert, welche Grenzen ihr Schutz hat, wo andere Sicherheitskontrollen implementiert werden müssen und was das PCI Security Standards Council von einem konformen Token-System verlangt.
Wichtigste Erkenntnisse
Die Tokenisierung kann ganze Systeme aus dem Compliance-Geltungsbereich des Payment Card Industry Data Security Standard (PCI DSS) entfernen, jedoch nur, wenn die Token-Generierung, die Sicherheit des Token-Tresors und die Kontrollen zur Enttokenisierung bestimmte technische Standards erfüllen.
Verschlüsselung und Tokenisierung schützen Kartendaten im Rahmen des PCI DSS auf unterschiedliche Weise, und viele konforme Architekturen stützen sich auf beides, anstatt sich für eine der beiden Optionen zu entscheiden.
Die Qualifizierung für den einfachsten Selbstbeurteilungs-Fragebogen zur PCI-Konformität hängt davon ab, wie Kartendaten durch eine Integration fließen, und nicht einfach davon, ob irgendwo im System eine Tokenisierung vorhanden ist.
Was bedeutet PCI DSS-Compliance?
PCI-DSS-Konformität bedeutet, die vom PCI Security Standards Council festgelegten Sicherheitsanforderungen für jedes Unternehmen zu erfüllen, das Karteninhaberdaten speichert, verarbeitet oder überträgt. Der Standard umfasst 12 Kernanforderungen in den Bereichen Netzwerksicherheit, Zugriffskontrolle, Verschlüsselung und Überwachung. Er gilt unabhängig davon, ob Sie ein einzelnes Zahlungs-Terminal betreiben oder Millionen von Transaktionen pro Jahr abwickeln.
Was der PCI DSS über die Tokenisierung sagt
Die PCI-DSS-Richtlinien zur Tokenisierung besagen, dass Umgebungen, in denen sich das Token befindet, nicht so bewertet werden müssen, als ob sie echte Kartendaten enthielten, wenn ein Token außerhalb des Systems, das es erstellt hat, keinen Wert hat und dieses System ordnungsgemäß isoliert und gesichert ist. Jede PAN existiert immer noch irgendwo, normalerweise in einem verschlüsselten Tresor, aber die Tokenisierung bedeutet, dass sie nur an diesem einzigen Ort existiert und nicht über Systeme verteilt ist.
Wie die Tokenisierung den Umfang der PCI-Konformität verringert
Die Tokenisierung verringert den Umfang der PCI-Konformität, indem sie die Anzahl der Orte begrenzt, an denen lesbare Kartendaten gespeichert oder übertragen werden. Dies gilt, solange die Token von niemandem außerhalb des Tokenisierungssystems wieder in die ursprüngliche PAN umgewandelt werden können. Wenn jemand die PAN mithilfe bekannter Logik aus dem Token berechnen kann, verringert das Token den Umfang nicht.
PCI-DSS-Richtlinien zur Tokenisierung und Anforderungen zur Verringerung des Umfangs
Die Richtlinien des PCI Security Standards Council enthalten spezifische technische Erwartungen an jedes System, das eine Verringerung des Umfangs beansprucht. Diese fallen in zwei Hauptkategorien: Tokengenerierung und Tokentresore.
Tokengenerierung:
Die Tokengenerierung muss Reverse Engineering widerstehen. Formaterhaltende Token, die die Länge und Struktur einer bestimmten Kartennummer nachahmen, sind sicher, solange die Ersetzung selbst unvorhersehbar ist und nicht durch eine umkehrbare Formel abgeleitet wird.
Token, die durch einen Einwegprozess erstellt wurden, sodass es keine mathematische Umkehrfunktion gibt, qualifizieren sich zuverlässiger für eine Verringerung des Umfangs als Token, die durch Verschlüsselung mit einem wiederherstellbaren Schlüssel generiert wurden. Verschlüsselte Werte gelten gemäß den PCI-DSS-Definitionen weiterhin als Karteninhaberdaten, selbst wenn sie so formatiert sind, dass sie wie Token aussehen. Wie Token generiert werden, bestimmt, wie ein Prüfer Ihr System klassifiziert. Die PCI-DSS-Richtlinien befassen sich auch mit der Brute-Force-Resistenz. Wenn der Tokenisierungsalgorithmus erraten oder durch wiederholte Versuche umgekehrt werden kann, qualifiziert sich das Token nicht für eine Verringerung des Umfangs, unabhängig davon, wie es generiert wurde.
Tokentresore
Das System zum Speichern von Token wird als Tresor bezeichnet. Der Tokentresor muss sich in einer segmentierten Netzwerkzone befinden, eine strenge rollenbasierte Zugriffskontrolle auf Daten anwenden, die Token wieder der ursprünglichen PAN zuordnen, und jedes Detokenisierungsereignis detailliert genug protokollieren, um eine forensische Prüfung zu unterstützen. PCI-DSS-Prüfer halten sich im Allgemeinen an den Standard, dass Detokenisierung selten, bewusst und prüfbar sein sollte. Die Richtlinien verlangen auch, dass sich der Tokenisierungsanbieter, unabhängig davon, ob es sich um ein internes Team oder einen Drittanbieter handelt, einer eigenen PCI-DSS-Bewertung unterzieht. Ein kompromittierter Tresor macht den Zweck der Tokenisierung zunichte.
Die Dokumentation muss Prüfern den Anspruch auf Verringerung des Umfangs belegen und sollte ein Datenflussdiagramm enthalten, das genau zeigt, wo PANs im Klartext vorhanden sind (d. h. lesbare Daten, die nicht verschlüsselt sind), wo die Tokenisierung stattfindet und wo Token die Kontrolle über Ihre Systeme übernehmen. Das Diagramm muss aktualisiert werden, wann immer ein neues System in den Zahlungspfad eintritt; andernfalls entspricht der Anspruch auf Verringerung des Umfangs nicht mehr der Realität, selbst wenn sich nichts anderes geändert hat.
Wie sich die Tokenisierung von der Verschlüsselung im Rahmen des PCI DSS unterscheidet
Sowohl die Tokenisierung als auch die Verschlüsselung schützen dieselben zugrunde liegenden Daten, aber der PCI DSS behandelt sie in Bezug auf den Anwendungsbereich sehr unterschiedlich. Eine verschlüsselte PAN bleibt im Allgemeinen im Anwendungsbereich, es sei denn, das speichernde System hat keinen Zugriff auf die Entschlüsselungsschlüssel, die zum Lesen des Chiffretextes (des verschlüsselten Formats) erforderlich sind. Das System, das den Chiffretext enthält, muss dieselben Anforderungen an die Zugriffskontrolle, die Aktivitätsprotokollierung und das Schwachstellenmanagement erfüllen wie ein System, das die PAN im Klartext speichert, auch wenn das praktische Risiko geringer ist.
Bei der Tokenisierung gibt es keinen Schlüssel zu schützen. Wenn ein Token durch einen ordnungsgemäß implementierten Einwegprozess generiert wird, kann er mathematisch nicht umgekehrt werden, was bedeutet, dass sich die Systeme, die ihn enthalten, außerhalb der CDE befinden.
In der Praxis verwenden viele PCI-konforme Architekturen sowohl Verschlüsselung als auch Tokenisierung, da jede unterschiedliche Sicherheitsvorkehrungen hinzufügt. Die Verschlüsselung schützt die PAN im Tresor für die Autorisierung und die Zahlungsabwicklung, während die Tokenisierung die PAN überall sonst schützt, z. B. in den Systemen, die auf eine Transaktion verweisen, eine Rückerstattung ausstellen oder einem Endkunden/einer Endkundin die letzten vier Ziffern anzeigen müssen, ohne jemals die tatsächliche Nummer zu benötigen. Letztendlich schützt die Verschlüsselung nutzbare Daten, und die Tokenisierung entfernt sie vollständig aus einem System.
Wer ist für die Aufrechterhaltung der Tokenisierungs-Compliance nach der Implementierung verantwortlich?
Die PCI-DSS-Konformität erfordert eine fortlaufende Validierung, und die Tokenisierung fügt zusätzlich zum üblichen Patching- (d. h. Anwenden von Sicherheitsupdates) und Überwachungszyklus des Standards eine eigene Wartung hinzu. Wenn Sie einen externen Tokenisierungsanbieter verwenden, sind Sie weiterhin dafür verantwortlich, zu bestätigen, dass der Anbieter seine eigene PCI-DSS-Validierung aufrechterhält, und seine Attestation of Compliance jedes Jahr zu überprüfen. Eine abgelaufene Zertifizierung aufseiten des Anbieters gefährdet Ihren eigenen Anspruch auf Verringerung des Umfangs, selbst wenn sich auf Ihrer Seite nichts geändert hat.
Intern muss jemand das Datenflussdiagramm verantworten und es aktualisieren, wenn ein neues System in den Zahlungspfad eintritt. Die Verringerung des Umfangs kann unbemerkt schwinden, wenn beispielsweise ein neues Analysetool verbunden wird oder ein Support-Team Transaktionsdaten zur Fehlerbehebung in eine Tabelle exportiert und eine Klartext-PAN findet, die bei der letzten Bewertung von niemandem berücksichtigt wurde. Tresorzugriffsprotokolle müssen ebenfalls regelmäßig überprüft werden, um Detokenisierungsanfragen zu erfassen, die nicht den erwarteten Geschäftsprozessen entsprechen.
In vielen mittelständischen Unternehmen liegt dies in der Verantwortung der Person, die die Zahlungsinfrastruktur verwaltet (häufig jemand im Finanzwesen oder in der Technik), die während des jährlichen Bewertungszyklus mit einem Qualified Security Assessor (QSA) zusammenarbeitet. Kleinere Unternehmen, die einen Zahlungsanbieter nutzen, der die Tokenisierung durchgängig abwickelt, haben es leichter, müssen aber dennoch bestätigen, dass sie keine PANs über Exporte, Screenshots oder Kundenservice-Workflows, die außerhalb der ursprünglichen Verringerung des Umfangs lagen, wieder in ihre eigenen Systeme eingeführt haben.
Reicht die Tokenisierung aus, um die PCI-DSS-Konformität allein zu gewährleisten?
Die Tokenisierung verringert den Umfang, beseitigt jedoch nicht die Compliance-Verpflichtungen für die Systeme, die im Umfang verbleiben. Der Tresor benötigt weiterhin volle Compliance: Die Generierungslogik, die Token-zu-PAN-Zuordnungsdaten und die Detokenisierungskontrollen müssen alle die vollständigen PCI-DSS-Standards erfüllen.
Kontaktpunkte vor der Tokenisierung müssen ebenfalls im Umfang bleiben. Jedes System, das eine PAN verarbeitet, bevor sie tokenisiert wird, wie z. B. eine Bezahlvorgangsseite oder ein Point-of-Sale-Terminal (POS-Terminal), benötigt Verschlüsselung bei der Übertragung, Netzwerksegmentierung und Schwachstellen-Scans.
Die Lücke bei der Berechtigung für den Selbstbeurteilungs-Fragebogen (SAQ)
Viele Unternehmen gehen davon aus, dass jede Tokenisierungslösung sie zur Verwendung des Self-Assessment Questionnaire A (SAQ A), des einfachsten Selbstbeurteilungs-Fragebogens, berechtigt. Dies gilt jedoch nur, wenn das Tokenisierungssystem verhindert, dass das Unternehmen jemals PANs verarbeitet, überträgt oder speichert, typischerweise über eine gehostete Zahlungsseite oder eine eingebettete Komponente, bei der Kartendaten direkt vom Browser des Kunden/der Kundin an den Zahlungsanbieter gesendet werden. Ein Tokenisierungsansatz, bei dem unverschlüsselte Kartendaten weiterhin, wenn auch nur kurzzeitig, den eigenen Server des Unternehmens durchlaufen, bevor sie tokenisiert werden, hält diesen Server in einem breiteren Anwendungsbereich, unabhängig davon, wie stark die Tokenisierung ab diesem Punkt ist.
So kann Stripe Payments Sie unterstützen
Stripe Payments bietet eine einheitliche, globale Zahlungslösung, mit der jedes Unternehmen – von Start-ups bis hin zu globalen Konzernen – Zahlungen online, vor Ort und weltweit akzeptieren kann.
Mit Stripe Payments können Sie Folgendes umsetzen:
Optimieren Sie Ihr Bezahlvorgangserlebnis: Schaffen Sie ein reibungsloses Kundenerlebnis und sparen Sie Entwicklungszeit mit vorgefertigten Zahlungs-UIs, Zugang zu mehr als 125 Zahlungsmethoden und Link, einem von Stripe entwickelten Wallet.
Neue Märkte schneller erschließen: Erreichen Sie Kundinnen und Kunden weltweit und reduzieren Sie die Komplexität und Kosten der Verwaltung mehrerer Währungen mit grenzüberschreitenden Zahlungsoptionen, die in 195 Ländern und über 135 Währungen verfügbar sind.
Online- und Vor-Ort-Zahlungen vereinheitlichen: Schaffen Sie Unified Commerce übergreifend über Online- und Vor-Ort-Kanäle, um Interaktionen zu personalisieren, Treue zu belohnen und Ihren Umsatz zu steigern.
Zahlungs-Performance verbessern: Steigern Sie Ihren Umsatz mit einer Reihe anpassbarer, einfach zu konfigurierender Zahlungstools, darunter No-Code-Betrugsvorbeugung und erweiterte Funktionen zur Verbesserung der Autorisierungsquoten.
Schnelleres Wachstum dank einer flexiblen, zuverlässigen Plattform: Bauen Sie auf einer Plattform auf, die mit Ihnen mitwächst, mit einer sensationellen Erreichbarkeit von 99,999 % und branchenführender Zuverlässigkeit.
Erfahren Sie mehr darüber, wie Stripe Payments Sie bei Online- und Vor-Ort-Zahlungen unterstützen kann oder starten Sie noch heute.
Der Inhalt dieses Artikels dient nur zu allgemeinen Informations- und Bildungszwecken und sollte nicht als Rechts- oder Steuerberatung interpretiert werden. Stripe übernimmt keine Gewähr oder Garantie für die Richtigkeit, Vollständigkeit, Angemessenheit oder Aktualität der Informationen in diesem Artikel. Sie sollten den Rat eines in Ihrem steuerlichen Zuständigkeitsbereich zugelassenen kompetenten Rechtsbeistands oder von einer Steuerberatungsstelle einholen und sich hinsichtlich Ihrer speziellen Situation beraten lassen.