Die Kartendaten, die Sie nicht speichern dürfen.
Anforderung 3 betrifft den Schutz gespeicherter Kontodaten und zieht eine klare Grenze. Die primäre Kontonummer muss, falls gespeichert, unlesbar gemacht werden. Sensible Authentifizierungsdaten wie der Kartenprüfcode (die drei oder vier Ziffern), die vollständigen Magnetstreifen- oder Chipdaten sowie die PIN dürfen nach der Zahlungsautorisierung nicht gespeichert werden. Für die Zahlungsakzeptanzprozesse, die die meisten Anwendungen implementieren, gilt: Sie speichern diese Daten nicht, selbst nicht verschlüsselt. (Kartenaussteller haben enge, kontrollierte Ausnahmen; die meisten Teams sind keine Aussteller.) Die Entscheidung fällt im Code, in dem, was Ihre Handler speichern.
The shapes the same control failure takes.
Anforderung 3 wird verletzt, wenn eine Änderung Kontodaten speichert, die nicht gespeichert werden dürfen, oder diese im Klartext speichert. Die häufigen Muster:
Sensible Authentifizierungsdaten werden gespeichert
Der Kartenprüfcode, vollständige Track-Daten oder die PIN werden nach der Autorisierung in eine Datenbank, einen Cache oder eine Warteschlange geschrieben, was ein Zahlungsakzeptanzprozess nicht tun darf, selbst nicht verschlüsselt.
Eine PAN wird ohne Unlesbarkeitsmaßnahmen gespeichert
Eine primäre Kontonummer wird ohne Verschlüsselung, Kürzung oder Tokenisierung gespeichert, sodass sie im Ruhezustand lesbar bleibt.
Kontodaten landen in einem neuen Speicher
Kartendaten werden in einem Speicher abgelegt, der nicht für deren Schutz ausgelegt ist (ein Log, ein Analyseereignis, eine Debug-Tabelle), wodurch dieser Speicher in den Geltungsbereich gezogen wird.
Ein Maskierungs- oder Tokenisierungsschritt wird entfernt
Ein Schritt, der die PAN vor dem Speichern gekürzt oder tokenisiert hat, wird entfernt, sodass die vollständige Nummer nun beibehalten wird.
Kartendaten werden länger als nötig gespeichert
Eine Aufbewahrungs- oder Löschregel, die die Speicherdauer von Kontodaten begrenzt hat, wird entfernt, sodass diese über den geschäftlichen Bedarf hinaus akkumuliert werden.
Speichern des Kartenprüfcodes für Wiederholungen.
Eine Zahlung benötigt gelegentlich eine Wiederholung, und es wäre praktisch, die ursprünglichen Details erneut zu übermitteln. Daher speichert eine Änderung die gesamte Zahlungsnutzlast, einschließlich des Kartenprüfcodes, in der Bestelltabelle. Dies erleichtert Wiederholungen, speichert aber Daten, die nach der Autorisierung niemals gespeichert werden dürfen.
- await orders.insert({ id, amount, last4: card.last4 })+ await orders.insert({ id, amount, card }) // full card incl. cvcreturn orderDas Speichern des vollständigen Kartenobjekts speichert den Kartenprüfcode nach der Autorisierung, was Anforderung 3 für einen Zahlungsakzeptanzprozess verbietet, selbst wenn die Spalte verschlüsselt ist. Speichern Sie nur das, was Sie speichern dürfen (hier: die letzten vier Ziffern und ein Token von Ihrem Zahlungsanbieter), nicht den Prüfcode, die vollständigen Track-Daten oder die PIN.
Gespeicherte Kontodaten werden gesucht, nicht nur abgefragt.
Eine PCI-Prüfung untersucht, welche Kontodaten tatsächlich gespeichert werden und wo: Sie überprüft, dass sensible Authentifizierungsdaten nach der Autorisierung nicht beibehalten werden und dass jede gespeicherte PAN unlesbar ist. Eine Änderung, die beginnt, den Prüfcode oder eine unmaskierte PAN zu speichern, ist genau der Befund, der aufgedeckt wird, und zieht den betroffenen Speicher in den Geltungsbereich. Der Diff zum Handler ist der günstigste Ort, um dies zu erkennen.
Eine Überprüfung, kein QSA.
heygrc markiert Änderungen, die Anforderung 3 betreffen, und verweist auf die Anforderung, sodass die Korrektur im Pull Request erfolgt. Es führt keine Prüfung durch und vervollständigt nicht Ihren Selbstbewertungsfragebogen. Es erkennt den Moment, in dem eine Änderung Kontodaten speichert, die nicht gespeichert werden dürfen, direkt im Diff.