PCI DSS: Ebenen und Konformität

1) Was ist PCI DSS und wer braucht es?

• Akzeptieren von Kartenzahlungen (direkt oder über PSP/Gateway),
• Kartendaten (PAN, Deadline, CVV) oder deren verkürzte/verschlüsselte Formen verarbeiten/speichern/übertragen,
• sind Dienstleister für andere Händler (Hosting, Processing, Anti-Fraud, Payment Orchestration etc.), wenn Sie die Sicherheit der Kartendaten beeinflussen können.

Version und Zeitrahmen: Die aktuelle Version ist PCI DSS v4. 0. Anforderungen v3. 2. 1 außer Gebrauch gesetzt; „future-dated“ Klauseln v4. 0 ist jetzt gültig. Neu in v4. 0: verstärkte MFA, „Customized Approach“, gezielte Risikoanalyse der Verfahrenshäufigkeit, Verfeinerungen durch Segmentierung und Verschlüsselung.

2) Konformitätsstufen: Händler und Dienstleister

2. 1 Händler (Händler)

• Level 1:> 6 Millionen Transaktionen/Jahr oder es wurde kompromittiert. Jährlicher ROC (Report on Compliance) von QSA oder interne ISA bei Verhandlung erforderlich, + vierteljährliche ASV-Scans.
• Level 2: ~ 1-6 Millionen/Jahr. In der Regel - SAQ (Selbsteinschätzung) + ASV-Scans; Einige Systeme/Acquirer können ROCs erfordern.
• Level 3: ~ 20k-1 Million E-Commerce/Jahr. In der Regel - SAQ + ASV-Scans.
• Stufe 4: unterhalb der L3-Schwellenwerte. SAQ; Die Anforderungen können je nach übernehmender Bank variieren.

2. 2 Dienstleister (Service Providers)

Normalerweise 2 Ebenen; für Level 1 (großvolumige/kritische Rolle in der Kette) ist der ROC von QSA obligatorisch, für Level 2 der SAQ-D SP (manchmal ROC auf Anforderung von Gegenparteien/Schemata). Bei iGaming sind viele PSPs/Gateways/Hosting-Partner SP Level 1.

3) SAQ vs ROC: wie man wählt

• SAQ A - nur Umleitung/iframe/hosted fields; keine Verarbeitung/Übertragung/Speicherung von Karten bei Ihnen.
• SAQ A-EP ist ein E-Commerce, bei dem Ihre Website die Sicherheit der Zahlungsseite beeinflusst (z. B. Hosting von Skripten), die PAN jedoch in der Anbieterumgebung eingegeben wird.
• SAQ B/B-IP - Terminals/Imprinter ohne elektronische Speicherung; B-IP - angeschlossene Terminals.
• SAQ C-VT/C - virtuelle Terminals/kleine Verarbeitungsumgebung, keine Speicherung.
• SAQ P2PE ist eine PCI-zertifizierte P2PE-Lösung.
• SAQ D (Merchant/Service Provider) ist eine „breite“ Option für jede Verarbeitung/Übertragung/Speicherung, kundenspezifische Integrationen, Orchestratoren usw.

Praxis für iGaming: Der Zielpfad ist SAQ A/A-EP aufgrund von PAN-Safe-Streams, Tokenisierung und Hosted-Feldern. Wenn Sie Ihre eigenen Zahlungsdienste/Valls haben - in der Regel SAQ D oder ROC.

4) Scoping: Was in der CDE enthalten ist und wie man sie eingrenzt

CDE (Cardholder Data Environment) - Systeme, in denen Kartendaten verarbeitet/gespeichert/übertragen werden, und alle verbundenen/einflussreichen Segmente.

• Hosted fields/iframe/TSP: Eingabe einer PAN außerhalb Ihrer Domain.
• Tokenisierung und Netzwerk-Token: Ihre Dienste betreiben Token, keine PANs.
• P2PE: Ende-zu-Ende-Verschlüsselung mit zertifizierter Lösung.
• Netzwerksegmentierung: starre ACLs, Isolierung der CDE vom Rest der Umgebung.
• Obligatorisches DLP und Logmaskierung, Verbot von Dumps mit PAN/CVV.

In v4. 0 wurde die Flexibilität der Methoden zur Zielerreichung hinzugefügt, aber Leistungsnachweise und gezielte Risikoanalysen sind obligatorisch.

5) „12 Anforderungen“ PCI DSS v4. 0 (semantische Blöcke)

1. Netzwerkschutz und Segmentierung (Firewalls, ACL, CDE-Isolation).
2. Sichere Konfiguration von Hosts/Geräten (Hardning, Baselines).
3. Schutz der Daten der Karteninhaber (PAN-Speicherung nur bei Bedarf, starke Kryptographie).
4. Datenschutz bei der Übertragung (TLS 1. 2 + und Äquivalente).
5. Antivirus/Anti-Malware und Integritätskontrolle.
6. Sichere Entwicklung und Änderung (SDLC, SAST/DAST, Bibliothekskontrolle).
7. Zugang nach Bedarf (least privilege, RBAC).
8. Identifikation und Authentifizierung (MFA für Admin- und Remote-Zugriff, Passwörter nach v4. 0).
9. Physische Sicherheit (Rechenzentren, Büros, Terminals).
10. Logging und Monitoring (Logzentralisierung, Unveränderlichkeit, Alerts).
11. Sicherheitstests (ASV-Scans vierteljährlich, Pentests jährlich und nach Änderungen, Segmentierungstest).
12. Management von Richtlinien und Risiken (Verfahren, Schulungen, Incident-Respons, Risikobewertungen, „Customized Approach“ Dokumente).

6) Obligatorische Aktivitäten und Häufigkeit

ASV-Scans (extern) - vierteljährlich und nach signifikanten Änderungen.
Schwachstellen/Patches - regelmäßige Zyklen (Frequenzen werden durch TRA - Targeted Risk Analysis begründet).
Pentests (intern/extern) jährlich und nach wesentlichen Änderungen; Die Überprüfung der Segmentierung ist obligatorisch.
Logs und Monitoring - kontinuierlich, mit Retention und Schutz vor Modifikationen.
Mitarbeiterschulung - bei Einstellung und darüber hinaus regelmäßig.
MFA - für den gesamten Admin- und Remote-Zugriff auf CDE.
Inventar der Systeme/Datenströme - laufend aktualisieren.

7) SAQ-Auswahlmatrix (kurz)

Nur iframe/redirect, ohne PAN haben Sie → SAQ A.
E-Commerce, Ihre Website beeinflusst die Zahlungsseite → SAQ A-EP.
Terminals/Imprinter → SAQ B/B-IP.
Virtuelles Terminal → SAQ C-VT.
Ein kleines „Karten“ -Netzwerk ohne Speicher → SAQ C.
P2PE-Lösung → SAQ P2PE.
Inoje/sloschnoje/chranenije/obrabotka → SAQ D (oder ROC).

8) Artefakte und Beweise für die Prüfung

• Netzwerk- und Datenflussdiagramme, Anlagenregister, Lieferantenregister, Konto-/Zugriffsregister.
• Richtlinien/Verfahren: sichere Entwicklung, Änderungsmanagement, Protokollierung, Vorfälle, Schwachstellen, Schlüssel/Krypto, Fernzugriff, Backups.
• Berichte: ASV, Pentests (einschließlich Segmentierung), Scans von Schwachstellen, Ergebnisse von Änderungen.
• Protokolle/Alerts: zentralisiertes System, Unveränderlichkeit, Analyse von Vorfällen.
• Kryptomanagement: KMS/HSM-Verfahren, Rotationen, Schlüssel-/Zertifikatsbestand.
• Nachweis des „Customized Approach“ (falls zutreffend): Kontrollziele, Methode, Leistungsmetriken, TRA.
• Haftungskonturen von Dritten: AoC-Partner (PSP, Hosting, CDN, Anti-Fraud), Shared Responsibility Matrix.

9) Projekt Compliance erreichen (Schritt für Schritt)

1. Scoping und GAP-Analyse: Definieren Sie CDEs, angrenzende Segmente, aktuelle Unterbrechungen.
2. Schnelle Gewinne: PAN-Safe-Stream (Iframe/Hosted Fields), Tokenisierung, PAN-Verbot in Logs, schließen „externe“ Kreta-Schwachstellen.
3. Segmentierung und Netzwerk: CDE, mTLS, Firewall-ACL, Zugriffe nach least-privilege, MFA isolieren.
4. Beobachtbarkeit: zentrale Protokollierung, Retention/Konservierungskette, Warnungen.
5. Schwachstellen- und Code-Management: SAST/DAST, Patches, SBOM, Abhängigkeitskontrolle.
6. Tests: ASV-Scans, interne/externe Pentests, Überprüfung der Segmentierung.
7. Dokumente und Schulungen: Verfahren, IR-Playbooks, Schulungen, Schulungsaufzeichnungen.
8. Wahl der Bescheinigungsform: SAQ (Typ) oder ROC; mit Acquirer/Marken abzustimmen.
9. Jahreszyklus: Unterstützung, Evidenz, Risiko-/Frequenzrevision, Re-Engineering.

10) Integration mit der iGaming-Architektur

Der Bezahl-Orchestrator arbeitet nur mit Token; Die PAN sieht nicht.
Multi-PSP: health-checks, smart-routing, idempotency, ретраи; AoC von jedem PSP.
Ereignisgesteuerter Bus/DWH: keine PAN/CVV; Maskierung der letzten 4 Ziffern; DLP-Gates in CI/CD.
Schecks per 3DS/SCA: Speichern Sie nur die notwendigen Artefakte (Transaktions-IDs), ohne sensible Daten.

11) Häufige Fehler

PAN/CVV-Logging und nicht-valide Masken.
„Temporäre“ PAN-Verlegung über interne APIs/Busse.
Kein Segmentierungstest bei Pentest.
Unangemessene Häufigkeit der Verfahren (keine TRA zu v4. 0).
Abhängigkeit von einem PSP ohne AoC und ohne Fallback.
Nicht gemeldete „einflussreiche“ Segmente (Admin-Jump-Hosts, Monitoring, Backups).

12) Schnellstart-Checkliste (iGaming)

• Gehe zu hosted fields/iframe; Entfernen Sie die PAN-Eingabe von Ihren Formularen.
• Tokenisierung/Netzwerk-Token aktivieren; PAN aus Ereignissen/Protokollen ausschließen.
• Durchführung von CDE-Scoping und Segmentisolierung (MFA, RBAC, mTLS).
• Richten Sie zentrale Protokolle und Alerts ein (Unveränderlichkeit, Retention).
• ASV-Scans ausführen, kritische/hohe Scans eliminieren.
• Durchführung von Pentests (intern/extern.) + Segmentierungstest.
• Vorbereitung von Richtlinien/Verfahren und Nachweis der Umsetzung.
• Abstimmung des Bescheinigungsformulars mit dem Acquirer (SAQ Typ/ROC).
• Erhalten und speichern Sie die AoC aller Kreta-Lieferanten.
• PCI-Kontrollen in den Releasezyklus einbetten (SDLC, IaC-Hardning, DLP in CI/CD).

13) FAQ kurz

Brauche ich eine QSA? Für ROC ja. Für SAQ ist oft eine Selbstzertifizierung ausreichend, aber viele Acquirer/Marken benötigen möglicherweise einen QSA/ASV-Partner.
Wenn wir die PAN nicht speichern? Sie fallen immer noch unter PCI DSS, wenn Sie Karten akzeptieren. Versuchen Sie, SAQ A/A-EP zu erreichen.
Löst 3DS PCI? Nein. 3DS - über die Authentifizierung; Bei PCI geht es um Datenschutz.
Reicht TLS? Nein. Sie benötigen alle relevanten v4-Anforderungen. 0, einschließlich Prozesse und Beweise.

14) Zusammenfassung

Für iGaming besteht die optimale Strategie darin, Scopes (PAN-Safe, Tokenisierung, Hosted Fields, P2PE wo möglich) zu minimieren, CDEs starr zu segmentieren, Logging/Schwachstellen/Pentests zu automatisieren, ein vollständiges Paket von Artefakten zusammenzustellen und das richtige Bestätigungsformular (SAQ oder ROC) für Ihr Niveau auszuwählen. Dies reduziert das Risiko, beschleunigt die PSP-Integrationen und unterstützt eine stabile Konvertierung und Monetarisierung, während gleichzeitig die Anforderungen der Kartenmarken erfüllt werden.