PCI DSS Testdaten sind der Punkt, an dem eine technische Bequemlichkeit auf eine Aufsichtsregel trifft. Die Regel folgt den Daten und nicht dem Etikett einer Umgebung, und genau das überrascht Entwicklungsteams: Eine Kopie der Produktionsdatenbank in einer Staging-Umgebung ist keine Staging-Datenbank, sondern eine Produktionsdatenbank an einem anderen Ort.
Dieser Beitrag erklärt, was der Standard verlangt, was als sensible Authentifizierungsdaten gilt, welche drei Verfahren es für Testdaten gibt und warum eine erzeugte Kartennummer einer maskierten echten Nummer in fast jeder Hinsicht überlegen ist.
Die Regel, die Entwicklungsteams überrascht
Die verbreitete Annahme lautet, dass Sicherheitsanforderungen nur die Produktion betreffen. Manche Anforderungen tun das tatsächlich, weil sie auf den Umgang mit echten Kundendaten zielen. Der Geltungsbereich des Standards wird jedoch nicht durch den Namen einer Umgebung bestimmt, sondern durch die Frage, ob in ihr echte Kartendaten verarbeitet, gespeichert oder weitergegeben werden.
Daraus folgt eine unangenehme Konsequenz. Wird eine Produktionstabelle in eine Testumgebung kopiert und enthält diese Tabelle Kartennummern, dann ist die Testumgebung ab diesem Moment im Geltungsbereich. Alle Anforderungen an Speicherung, Verschlüsselung, Zugriffskontrolle und Protokollierung gelten dort ebenfalls, obwohl die Umgebung niemand als Produktion bezeichnet.
Die umgekehrte Konsequenz ist die gute Nachricht. Eine Umgebung, in der ausschließlich synthetische Werte liegen, verarbeitet keine echten Kartendaten und fällt damit aus dem Geltungsbereich. Genau darin liegt der Wert erzeugter Testdaten: Sie machen aus einer Compliance-Aufgabe eine Nichtaufgabe.
Gilt PCI DSS auch für Testumgebungen?
Ja, sobald dort echte Kartendaten liegen. Nein, solange dort ausschließlich Werte liegen, die niemals ausgegeben wurden. Die Frage ist nicht der Name der Umgebung, sondern der Inhalt der Datenbanken, Sicherungen, Protokolle und Zwischenspeicher.
Das ist praktisch bedeutsamer, als es klingt, weil Protokolle und Zwischenspeicher häufig vergessen werden. Ein Testsystem, dessen Anwendungsprotokoll vollständige Anfrageinhalte mitschreibt, verarbeitet echte Kartendaten, auch wenn in der Datenbank nur Attrappen stehen. Ein Warteschlangensystem, das fehlgeschlagene Zahlungen für einen erneuten Versuch aufbewahrt, tut dasselbe. Für den Geltungsbereich zählt jeder Ort, an dem ein Wert landet.
Die Faustregel lautet deshalb: Nicht die Umgebung bestimmt den Geltungsbereich, sondern die Frage, ob irgendwo ein Wert liegt, der eine echte Zahlung repräsentiert.
Was als sensible Authentifizierungsdaten zählt
Der Standard unterscheidet zwei Gruppen von Daten, und die Unterscheidung ist der Kern aller praktischen Regeln.
Die erste Gruppe sind die Kontodaten. Dazu gehören die Kartennummer selbst, der Name des Karteninhabers, das Ablaufdatum und der Servicocode. Diese Werte dürfen gespeichert werden, allerdings nur mit Schutz. Bei der Anzeige müssen sie maskiert werden, und die übliche Konvention ist, die ersten sechs und die letzten vier Ziffern zu zeigen; die ersten sechs, weil sie den Herausgeber identifizieren.
Die zweite Gruppe sind die sensiblen Authentifizierungsdaten. Dazu gehören der Sicherheitscode, der vollständige Inhalt des Magnetstreifens und die entsprechenden Daten im Chip. Diese Werte dürfen zur Autorisierung verwendet werden, aber nach der Autorisierung dürfen sie nicht mehr aufbewahrt werden, in keiner Form und an keinem Ort.
| Datum | Speicherung | Anzeige |
|---|---|---|
| Kartennummer | erlaubt, mit Schutz | maskiert, üblicherweise erste sechs und letzte vier |
| Name und Ablaufdatum | erlaubt, mit Schutz | maskiert oder eingeschränkt |
| Sicherheitscode | nicht erlaubt | darf nicht gespeichert werden |
| Vollständige Magnetstreifen- oder Chipdaten | nicht erlaubt | darf nicht gespeichert werden |
Die einfache Merkregel: Die Kontodaten brauchen Schutz, die Authentifizierungsdaten brauchen Abwesenheit. Wer verstehen möchte, warum der Sicherheitscode in die zweite Gruppe fällt, findet die Begründung im Beitrag zum Sicherheitscode.
Maskierung, Tokenisierung und synthetische Daten
Es gibt drei Verfahren, um mit Testdaten umzugehen, und sie leisten sehr unterschiedliche Dinge.
Die Maskierung verbirgt einen Teil eines echten Werts. Sie zeigt etwa die ersten sechs und die letzten vier Ziffern und ersetzt den Rest. Entscheidend ist, dass der zugrunde liegende Wert weiterhin im System liegt. Die Maskierung ist eine Anzeigeregel und keine Schutzmaßnahme für den Speicher.
Die Tokenisierung ersetzt den echten Wert durch ein beliebiges Kennzeichen, das nur im eigenen System Bedeutung hat. Damit verschwindet die Kartennummer aus der Anwendung vollständig, und der Bezug zum echten Wert liegt beim Dienstleister. Sie ist das einzige Verfahren, mit dem sich wiederkehrende Zahlungen abwickeln lassen, ohne dass die eigene Anwendung eine Kartennummer hält.
Die dritte Möglichkeit sind synthetische Daten. Werte, die nach denselben öffentlichen Regeln gebildet sind wie echte Nummern, aber zu keinem Konto gehören. Ihre Einschränkung ist die Wirklichkeitstreue: Mit ihnen lässt sich nicht bezahlen, nichts abfragen und kein kundenspezifischer Fehler nachstellen, der auf einem konkreten Kontozustand beruht. Für Formulartests, Lasttests und Befüllung von Oberflächen sind sie dagegen vollständig ausreichend.
Warum ist eine erzeugte Nummer sicherer als eine maskierte echte?
Weil eine maskierte echte Nummer weiterhin ein echtes Kennzeichen ist. Solange der vollständige Wert irgendwo existiert, ist die maskierte Fassung ein Wegweiser dorthin, und in vielen Datenbanken steht der vollständige Wert eben doch, einen Verbindungsschritt entfernt.
Hinzu kommt ein praktisches Argument. Eine maskierte Nummer behält Präfix, Länge und Prüfsumme eines echten Kontos. Sie verhält sich im Test also nicht anders als der Produktionswert, was einerseits nützlich ist und andererseits bedeutet, dass eine versehentlich gegen ein echtes Gateway gesendete Anfrage eine echte Zahlungsreferenz verwendet.
Eine erzeugte Nummer löst dagegen in jedem System nirgends etwas auf. Sie ist strukturell korrekt und inhaltlich leer. Diese Kombination ist genau das, was Testdaten leisten sollen, und der Kartennummern-Generator liefert sie für jedes unterstützte Netzwerk.
Synthetische Werte tragen eine Bedingung: Sie müssen als synthetisch erkennbar sein. Steht in einer Datenbank eine erzeugte Nummer ohne Kennzeichnung, wird sie früher oder später für einen echten Datensatz gehalten, und jemand baut darauf eine Prüfung, die nicht funktionieren kann.
Für Entwickler: Test und Produktion trennen
Die Trennung ist eine Konfigurationsaufgabe, und sie scheitert fast immer an denselben Stellen.
Erstens: In Testsystemen dürfen ausschließlich Testschlüssel stehen. Ein Produktivschlüssel in einer Entwicklungskonfiguration verwandelt jeden versehentlichen Testlauf in einen Zahlungsversuch. Diese Prüfung gehört in die Startsequenz der Anwendung, damit ein Fehlstart sofort sichtbar wird.
Zweitens: Die häufigste Leckstelle ist die Wiederherstellung einer Produktionssicherung in einer Testumgebung. Wenn das aus betrieblichen Gründen unvermeidbar ist, müssen die Werte ersetzt werden, bevor irgendjemand die Umgebung erreichen kann. Der Ersetzungsschritt gehört als Skript ins Repository, damit er wiederholbar ist und nicht zu einer einmaligen Handarbeit wird, die beim nächsten Mal vergessen wird.
Drittens: Prüfen Sie, was die Testumgebung selbst schreibt. Protokolle, Überwachungsnutzlasten, Fehlerberichte und Warteschlangen sind Speicherorte. Ein Fehlerbericht, der die Anfrage eines Zahlungsformulars mitsamt Sicherheitscode enthält, ist ein Compliance-Problem, das in keinem Datenbankschema auftaucht.
Viertens: Auch die Ausgabe nach außen zählt. Eine Supportoberfläche, die eine vollständige Kartennummer anzeigt, weil das für die Fehlersuche praktisch war, ist in seinem Zweck verständlich und trotzdem eine Maskierungsanforderung. Wie diese Punkte in eine Abnahme münden, beschreibt die Checkliste für Zahlungsformulare.
Konforme Testdaten beschaffen
Der Weg zu konformen Testdaten ist kürzer, als die Regelwerke vermuten lassen. Er besteht aus drei Entscheidungen.
Entscheiden Sie zuerst, welche Daten überhaupt echt sein müssen. In den meisten Testfällen ist die Antwort: keine. Bestellungen, Adressen, Namen und Zahlungsdaten lassen sich vollständig erzeugen.
Erzeugen Sie zweitens Zahlungsdaten synthetisch statt sie zu kopieren. Ein Paket aus Nummer, Ablaufdatum und Sicherheitscode lässt sich in Sekunden herstellen und deckt mehrere Netzwerke ab.
Halten Sie drittens in der Dokumentation fest, dass die Werte synthetisch sind, und benennen Sie die Umgebung so, dass niemand sie für produktiv hält. Der Standard selbst ist beim PCI Security Standards Council veröffentlicht und dort in der jeweils gültigen Fassung einsehbar.
Nächste Schritte
Prüfen Sie als Erstes, welcher Datenbestand heute tatsächlich in Ihrer Testumgebung liegt. Diese Frage zu beantworten ist der einzige Schritt, der sich nicht delegieren lässt, und ihr Ergebnis entscheidet, ob der Rest dieser Seite für Sie eine Aufgabe oder eine Bestätigung ist.