PCI-DSS-Datenflussdiagramm: Karteninhaberdaten abbilden und den Scope verkleinern

Eine PCI-DSS-Prüfung beginnt meistens mit derselben Bitte: Zeigt uns, wohin Kartendaten fließen. Das Diagramm in eurem Wiki zeigt Services und Pfeile, aber nicht, welche Pfeile eine Kartennummer tragen, welche nur ein Token oder warum das Analytics-Warehouse außerhalb des Scopes liegt. Ohne das wird jedes System zur Scoping-Diskussion.

Dieser Beitrag behandelt, was PCI DSS v4.0.1 verlangt, die Scope-Kategorien, einen durchgespielten Checkout mit gehosteten Zahlungsfeldern, Tokens, Segmentierung, SAQ-Typen und die Pflege des Diagramms. Er ist keine Rechts- oder Compliance-Beratung: Euer Acquirer oder Assessor entscheidet, was gilt, und die offiziellen Texte stehen in der PCI SSC Document Library.

Was PCI DSS v4.0.1 verlangt

PCI DSS v4.0.1, veröffentlicht im Juni 2024, ist zum Zeitpunkt des Schreibens (November 2026) die aktuelle Version. Die zukunftsdatierten Anforderungen wurden am 31. März 2025 verbindlich. Drei Anforderungen prägen deine Diagramme:

Kontodaten umfassen Karteninhaberdaten (PAN, Name des Karteninhabers, Ablaufdatum, Servicecode) und sensitive Authentifizierungsdaten (vollständige Trackdaten, Kartenprüfcode, PINs und PIN-Blöcke). Die PAN ist das entscheidende Element: Speicherst, verarbeitest oder überträgst du sie, hast du eine Karteninhaberdaten-Umgebung (CDE).

SAQ A enthält weder Anforderung 1 noch 12.5.2, SAQ A-EP enthält 1.2.3 und 1.2.4, und SAQ D sowie vollständige Assessments enthalten alle drei. Auch unter SAQ A ist das Diagramm dein klarster Nachweis der Berechtigung.

Drei Arten von Systemen

Abschnitt 4 wendet die Anforderungen auf die CDE und auf alles an, was „die Sicherheit von Karteninhaberdaten und/oder sensitiven Authentifizierungsdaten beeinträchtigen könnte“, eine Formulierung, die v4.0.1 anstelle von „die Sicherheit der CDE“ eingeführt hat. Das Beispiel des Standards selbst ist „ein Webserver, der die Erzeugung eines Zahlungsformulars oder einer Zahlungsseite steuert“. Der Scoping-Leitfaden des PCI SSC ordnet Systeme drei Kategorien zu, die von oben nach unten geprüft werden:

Ein System gehört zur höchsten Kategorie, die auf es zutrifft. Segmentierung ist optional, aber ohne sie liegt das gesamte „flache Netzwerk“ im Scope, und Verschlüsselung allein nimmt Kartendaten in der Regel nicht aus dem Scope.

Das Beispiel: ein Checkout mit gehosteten Zahlungsfeldern

Eine Shop-Web-App liefert die Checkout-Seite aus; ihre Kartenfelder sind ein iframe des Zahlungsanbieters, oft Hosted Fields genannt. Ein Order-Service bucht Zahlungen ab, Postgres speichert Bestellungen, ein nächtlicher Job füttert ein Warehouse, und CI/CD deployt den Shop:

1. Der Browser lädt die Checkout-Seite; das Skript des Anbieters rendert die Kartenfelder in einem eigenen iframe.
2. Der Kunde tippt PAN, Ablaufdatum und CVC ein, und der Browser sendet sie per TLS direkt an den Anbieter. Die Same-Origin-Policy hält die Skripte der Händlerseite aus dem iframe heraus.
3. Der Anbieter speichert die PAN in seinem Vault und gibt ein Token zurück.
4. Die Seite sendet Bestellung und Token an den Order-Service.
5. Der Order-Service belastet das Token über die API des Anbieters mit einem Secret Key, und der Anbieter fordert die Autorisierung über das Kartennetzwerk an.
6. Ein Webhook bestätigt das Ergebnis. Der Order-Service speichert die Token-ID, die Kartenmarke und die letzten vier Ziffern.

Kein Händlersystem speichert, verarbeitet oder überträgt die PAN, also hat der Händler keine CDE; du verwaltest den Anbieter, der ein eigenes Assessment hat, nach Anforderung 12.8. Das Diagramm zur Payment-Gateway-Integration zeigt denselben Checkout als Sequenz, und das Diagramm der E-Commerce-Plattform ordnet ihn zwischen Katalog-, Warenkorb- und Bestellservices ein.

Die Web-App bleibt im Scope: Ein Angreifer, der sie oder ein von ihr geladenes Skript ändert, kann das iframe durch ein gefälschtes Formular ersetzen. Dieser Angriff, E-Skimming, ist der Grund, warum v4.0 die Anforderungen 6.4.3 (Skripte auf Zahlungsseiten autorisieren, auf Integrität prüfen und inventarisieren) und 11.6.1 (Änderungen an Zahlungsseiten erkennen) ergänzt hat. CI/CD liegt ebenfalls im Scope, da der Standard Deployment-Tools zu den Systemkomponenten zählt.

Tokens und was sie im Scope lassen

Die Tokenisierungs-Richtlinien des PCI SSC ordnen das Tokenisierungssystem, einschließlich De-Tokenisierung und PAN-Speicherung, der CDE zu. Systeme, die nur Tokens halten, können außerhalb des Scopes liegen, wenn sich die PAN nicht aus den Tokens rekonstruieren lässt, sie keine De-Tokenisierung anfordern oder den Vault nicht erreichen können und sie von der CDE segmentiert sind.

Der Anbieter besitzt den Vault, daher können Order-Service und Datenbank sich qualifizieren, mit einem Haken: Ein wiederverwendbares Token plus der geheime API-Schlüssel kann Abbuchungen auslösen. Der Leitfaden sagt, Tokens, die eine Transaktion starten können, „könnten im Scope von PCI DSS liegen“, und rät Händlern, ihren Acquirer zu fragen. Schütze den Schlüssel wie jedes Produktions-Secret.

Segmentierung und wie sie getestet wird

Segmentierung bedeutet meist Firewall-Regeln, Security Groups oder getrennte Cloud-Konten. Wenn sie eine CDE isoliert, verlangt Anforderung 11.4.5 Penetrationstests dieser Kontrollen mindestens alle 12 Monate und nach Änderungen (alle sechs Monate bei Service Providern) durch einen qualifizierten, unabhängigen Tester. Zeichne im Netzwerkdiagramm nach 1.2.3 jedes Segment und die Kontrollen dazwischen ein, wie in einer logischen Netzwerktopologie.

Ohne Händler-CDE verläuft die entscheidende Grenze um alles, was die Checkout-Seite ändern kann: Order-Service, Warehouse und ihre Zugangsdaten dürfen nicht in den Shop deployen können.

Architekturentscheidungen und SAQ-Typen

Dein Checkout-Design bestimmt weitgehend den Selbstbeurteilungsfragebogen (SAQ); dein Acquirer bestätigt ihn:

Die SAQ-A-Überarbeitung vom Januar 2025 hat 6.4.3 und 11.6.1 aus dem Fragebogen entfernt und ein Berechtigungskriterium ergänzt: Der Händler bestätigt, „dass seine Website nicht anfällig für Angriffe durch Skripte ist, die die E-Commerce-Systeme des Händlers beeinträchtigen könnten“. FAQ 1588 erlaubt zwei Wege: die eigene Seite mit Techniken wie in 6.4.3 und 11.6.1 schützen oder vom Anbieter bestätigen lassen, dass seine Lösung das tut, wenn sie wie vorgegeben umgesetzt wird. Das Kriterium gilt für eingebettete iframes, nicht für Weiterleitungen, und beide brauchen weiterhin vierteljährliche Scans durch einen Approved Scanning Vendor (FAQ 1604). Ein einziges Kartenfeld, das deine eigene Seite rendert, schließt SAQ A aus.

Das Diagramm aktuell halten

Der Standard zählt „alle Änderungen im Fluss oder in der Speicherung von Kontodaten“ als potenziell wesentlich. Aktualisiere das Diagramm, wenn du eine Zahlungsmethode, einen Anbieter oder Kanal, ein Checkout-Skript oder einen Export, eine Log-Pipeline oder ein Support-Tool hinzufügst, das Zahlungsdaten berührt.

Achte auf Kartennummern in Support-Tickets und Chats: Für einen solchen unbeabsichtigten Kanal sagt v4.0.1, ihn in die CDE aufzunehmen oder die Daten sicher zu löschen und zu verhindern, dass der Kanal dafür genutzt wird. Trage Datum, Autor und Freigeber ins Diagramm ein; der Living-Docs-Workflow behandelt Verantwortliche und Update-Auslöser.

Das Datenflussdiagramm für Karteninhaberdaten

So liest du es:

• Drei Zonen. Rot ist die CDE des Anbieters, Gelb enthält Händlersysteme, die die Checkout-Seite ändern können, und Türkis enthält Systeme, die nur Tokens verarbeiten.
• Farben folgen den Daten: Rot für Kartendaten, Türkis für Tokens, Grau für keins von beiden; gestrichelt heißt asynchron.
• Nummern folgen einem Kauf. Der rote Pfad betritt nie einen Händler-Rahmen.
• Zwei Notizen markieren die verbleibenden Risiken: Seitenskripte und wiederverwendbare Tokens.
• Die Legende fasst Datenklassen und Scope zusammen.

PCI-DSS-Datenflussdiagramme klar zeichnen

Beschrifte jeden Fluss und jeden Speicher:

• Zeichne den Scope als Rahmen und schattiere Out-of-Scope-Bereiche, wie es der Leitfaden zu 1.2.3 vorschlägt.
• Zeichne ein Diagramm pro Kanal: E-Commerce, Telefon und Terminals unterscheiden sich.
• Nimm die stillen Pfade auf: Erstattungen, Chargebacks, Backups, Logs und Support-Tools.
• Passe es an das Netzwerkdiagramm an, das das Datenflussdiagramm ergänzen soll.
• Lass weg: Aufrufe ohne Kontodaten oder Tokens.

Ein häufiger Fehler ist eine PAN-Linie durch Systeme, die nur Tokens halten; das zieht sie auf dem Papier in den Scope. Siehe die Datenflussdiagramm-Beispiele für die Notation, die Threat-Modeling-Anleitung für Vertrauensgrenzen und die GDPR-Datenlandkarte für ein ähnliches Inventar.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und erstelle ein Diagramm.
2. Füge für den Browser des Kunden eine Person aus dem Paket C4-Modell hinzu.
3. Füge drei Rahmen-Nodes aus dem Paket Basis hinzu: für den Anbieter (rot), den Händler im Scope (gelb) und den Händler außerhalb des Scopes (türkis).
4. Füge im Anbieter-Rahmen zwei Externes System-Nodes aus dem Paket C4-Modell für die Hosted Fields und die Payment-API hinzu, dazu einen Tresor aus dem Paket Sicherheit. Setze ein Externes System für die Kartennetzwerke unter den Rahmen.
5. Füge im gelben Rahmen einen Container aus dem Paket C4-Modell für die Web-App und eine CI/CD-Pipeline aus dem Paket DevOps hinzu.
6. Füge im türkisen Rahmen einen Container für den Order-Service sowie Postgres- und Datenlager-Nodes aus dem Paket Daten hinzu.
7. Zeichne beschriftete Kanten: rot für Kartendaten, türkis für Tokens, sonst grau, gestrichelt für den Webhook und den Export.
8. Füge eine Markdown-Legende aus dem Paket Basis und zwei Text-Notizen aus dem Paket Basis hinzu.

Für das Netzwerkdiagramm nach 1.2.3 liefert dir der Terraform-Konverter einen ersten Entwurf aus deinen .tf-Dateien; die Seite Payment-Flow-Diagramm zeigt Sequenzansichten.

Das Beispiel nutzt 14 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Verlangt PCI DSS ein Datenflussdiagramm? Ja. Anforderung 1.2.4 in v4.0.1 verlangt ein korrektes Datenflussdiagramm aller Kontodatenflüsse, das aktuell gehalten wird. SAQ A lässt es weg; SAQ A-EP, SAQ D und vollständige Assessments enthalten es.

Was ist der Unterschied zwischen dem PCI-Netzwerkdiagramm und dem Datenflussdiagramm? Das Netzwerkdiagramm (1.2.3) zeigt Verbindungen zwischen der CDE und anderen Netzwerken. Das Datenflussdiagramm (1.2.4) zeigt, wohin Kontodaten wandern und wo sie gespeichert werden. Beide sollten übereinstimmen.

Nimmt ein iframe oder eine gehostete Zahlungsseite meine Website aus dem PCI-Scope? Nein. Es hält Kartendaten von deinen Systemen fern, aber die Seite, die das iframe einbettet, kann weiterhin angegriffen werden; deshalb verlangt SAQ A vierteljährliche ASV-Scans und bei iframes Schutz vor Skriptangriffen.

Liegen Systeme, die nur Tokens speichern, außerhalb des PCI-DSS-Scopes? Sie können es, wenn sich die PAN nicht aus den Tokens rekonstruieren lässt und die Systeme vom Tokenisierungssystem segmentiert sind. Tokens, die eine Transaktion starten können, können weiterhin im Scope liegen.

Wie oft müssen PCI-Scope und Diagramme überprüft werden? Aktualisiere das Datenflussdiagramm, wann immer sich Kontodatenflüsse ändern, und bestätige den Scope mindestens alle 12 Monate und nach wesentlichen Änderungen (12.5.2), bei Service Providern alle sechs Monate.

Kostenlos starten — ein Seat, keine Kreditkarte.