PCI DSS-Konformität für E-Commerce: Leitfaden zur Zahlungssicherheit

Jede E-Commerce-Transaktion, die eine Zahlungskarte beinhaltet, führt zu einer Compliance-Verpflichtung gemäß PCI DSS – dem Payment Card Industry Data Security Standard. Die Nichteinhaltung stellt kein theoretisches Risiko dar: Kartenmarken (Visa, Mastercard, Amex) können von Acquiring-Banken Geldstrafen in Höhe von 5.000 bis 100.000 US-Dollar pro Monat erheben, die die Haftung über ihre Zahlungsabwicklungsvereinbarungen direkt an die Händler weitergeben. Nach einem Verstoß drohen Händlern, die sich nicht an die Vorschriften halten, Geldstrafen in Höhe von 50 bis 90 US-Dollar pro kompromittierter Karte, Kosten für die forensische Untersuchung der Kartenmarke und – in den schwerwiegendsten Fällen – die Kündigung ihres Händlerkontos.

PCI DSS v4.0, veröffentlicht im März 2022 mit verpflichtender Einhaltung ab März 2025, führte zu erheblichen Änderungen an kryptografischen Anforderungen, Authentifizierungsstandards und der Handhabung von Skripten auf Zahlungsseiten. Dieser Leitfaden bietet E-Commerce-Teams eine vollständige Roadmap für die Implementierung.

Wichtige Erkenntnisse

– PCI DSS v4.0 ist ab dem 31. März 2025 obligatorisch – alle E-Commerce-Händler müssen mit der neuen Version kompatibel sein

• Die Festlegung des Scopings ist der wichtigste erste Schritt: Reduzieren Sie Ihre Karteninhaberdatenumgebung (CDE) so weit wie möglich – Die Verwendung der gehosteten Zahlungsseite eines Zahlungsabwicklers (Stripe, Braintree, Adyen) reduziert den Umfang erheblich – SAQ A gilt für die meisten Händler mit gehosteten Zahlungsseiten – jedoch nur, wenn keine Karteninhaberdaten Ihre Server berühren – Zu den neuen v4.0-Anforderungen gehören MFA für den gesamten CDE-Zugriff, Skriptintegritätskontrollen auf Zahlungsseiten und gezielte Risikoanalyse – Web-Skimming (Magecart-Angriffe) wird durch die neue Anforderung 6.4.3 zum Skriptinventar der Zahlungsseite behoben
• Jährliche Penetrationstests und vierteljährliche Schwachstellenscans bleiben obligatorisch
• Bei Nichteinhaltung werden Strafen von Kartenmarken → Acquiring-Banken → Händlern verhängt

---

PCI-DSS-Framework-Grundlagen

PCI DSS wird vom Payment Card Industry Security Standards Council (PCI SSC) verwaltet, einem von American Express, Discover, JCB, Mastercard und Visa gegründeten Gremium. Der aktuelle Standard ist PCI DSS v4.0.

Der Standard ist in 12 Anforderungen mit 6 Zielen unterteilt:

Compliance gilt für alle Unternehmen, die Karteninhaberdaten speichern, verarbeiten oder übertragen – oder die Sicherheit von Karteninhaberdaten beeinträchtigen könnten. Dazu gehören Händler, Zahlungsabwickler, Acquirer, Emittenten und Dienstleister.

---

Schritt 1 – Definieren und reduzieren Sie Ihren Umfang

Die Karteninhaberdatenumgebung (CDE) ist jedes System, das Karteninhaberdaten (CHD) oder sensible Authentifizierungsdaten (SAD) speichert, verarbeitet oder überträgt. Die Minimierung des Umfangs ist der wirkungsvollste Schritt, den Sie unternehmen können.

Karteninhaberdaten vs. sensible Authentifizierungsdaten:

Strategien zur Umfangreduzierung für E-Commerce:

1. Verwenden Sie eine gehostete Zahlungsseite: Leiten Sie Kunden zur gehosteten Zahlungsseite Ihres Zahlungsabwicklers weiter (Stripe Checkout, Braintree Hosted Fields, Adyen Drop-in). Keine Karteninhaberdaten berühren Ihre Server und Sie qualifizieren sich für SAQ A – den einfachsten Fragebogen zur Selbstbewertung.

2. Tokenisierung: Ersetzen Sie Kartennummern sofort nach der Autorisierung durch vom Prozessor generierte Token. Speichern Sie nur das Token, das für Angreifer ohne Zugriff auf den Tokenisierungs-Tresor des Prozessors nutzlos ist.

3. iFrame-basierte Zahlungsformulare: Betten Sie das per JavaScript gerenderte Formular des Zahlungsabwicklers in Ihre Checkout-Seite ein. Kartendaten werden direkt in ein Formular eingegeben, das auf der Domain des Prozessors gehostet wird, nicht auf Ihrer.

4. Netzwerksegmentierung: Isolieren Sie CDE-Systeme (Zahlungsverarbeitungsserver, Datenbanken) mithilfe von Firewalls von Systemen außerhalb des Geltungsbereichs. Richtig segmentierte Netzwerke reduzieren den Prüfumfang erheblich.

---

Schritt 2 – Identifizieren Sie Ihren SAQ-Typ

Der Self-Assessment Questionnaire (SAQ) ist ein Validierungstool für Händler und Dienstleister, die keine Vor-Ort-Bewertung durch einen Qualified Security Assessor (QSA) benötigen. Der SAQ-Typ hängt davon ab, wie Sie Zahlungen akzeptieren:

SAQ A – Gilt für Händler ohne Karte (E-Commerce), die die Zahlungsabwicklung vollständig an einen PCI DSS-konformen Dritten auslagern. In Ihren Systemen oder Räumlichkeiten werden keine elektronischen Karteninhaberdaten gespeichert, verarbeitet oder übertragen. Ihre Zahlungsseite wird vollständig von Ihrem Zahlungsabwickler bereitgestellt. Ungefähr 22 Anforderungen.

SAQ A-EP – Für E-Commerce-Händler, die die Zahlungsabwicklung teilweise auslagern, aber dennoch eine auf ihrem eigenen Server gehostete Zahlungsseite haben, die einen Zahlungs-Iframe eines Drittanbieters einbettet. Ihr Webserver hat indirekt Einfluss auf die Sicherheit der Zahlungsabwicklung. Mehr Anforderungen als SAQ A. Kritisch betroffen von der neuen v4.0-Anforderung 6.4.3.

SAQ D – Für Händler, die die Kriterien für keinen anderen SAQ-Typ erfüllen oder Karteninhaberdaten speichern. Deckt alle 12 Anforderungen ab. Erforderlich für Händler, die ihre eigene Zahlungsabwicklungsinfrastruktur betreiben. In der Regel mehr als 300 Unteranforderungen.

Stufenstufen (Mastercard/Visa-Standard):

---

Schritt 3 – Wichtige Änderungen von PCI DSS v4.0 für E-Commerce

Mit PCI DSS v4.0 wurden mehrere Anforderungen eingeführt, die sich speziell auf E-Commerce-Händler auswirken. Alle waren ab dem 31. März 2025 verpflichtend.

Anforderung 6.4.3 – Skriptverwaltung für Zahlungsseiten

Diese Anforderung zielt direkt auf Magecart-/Web-Skimming-Angriffe ab, bei denen Angreifer bösartiges JavaScript in E-Commerce-Zahlungsseiten einschleusen, um Karteninhaberdaten in Echtzeit zu stehlen. Gemäß 6.4.3 müssen Händler, die SAQ A-EP oder höher verwenden:

• Führen Sie eine Bestandsaufnahme aller Skripte, die zur Ausführung auf Zahlungsseiten berechtigt sind
• Begründen Sie die geschäftliche oder technische Notwendigkeit jedes Skripts
• Implementieren Sie eine Methode zur Bestätigung der Integrität jedes Skripts (Subresource-Integritäts-Hashes für Skripts von Drittanbietern oder Anweisungen zur Inhaltssicherheitsrichtlinie).

Für SAQ A-Händler mit einer vollständig ausgelagerten Zahlungsseite gilt diese Anforderung für die Seiten Ihres Zahlungsabwicklers – sie müssen die Einhaltung in Ihrem Namen nachweisen.

Anforderung 11.6.1 – Änderungs- und Manipulationserkennung für Zahlungsseiten

Händler müssen einen Mechanismus (z. B. Content Security Policy, Skriptüberwachungsdienst) bereitstellen, um unbefugte Änderungen an HTTP-Headern und Skriptinhalten auf Zahlungsseiten zu erkennen. Benachrichtigungen müssen innerhalb von 7 Tagen nach nicht genehmigten Änderungen generiert werden.

Anforderung 8.4.2 – MFA für den gesamten Zugriff auf das CDE

Eine Multi-Faktor-Authentifizierung ist jetzt für alle Benutzerkonten mit Zugriff auf das CDE erforderlich – nicht nur für den Fernzugriff. Dazu gehört auch der Zugriff interner Benutzer auf Produktionszahlungssysteme innerhalb des Unternehmensnetzwerks.

Anforderung 3.3.1.1 – SAD kann nach der Genehmigung nicht mehr aufbewahrt werden

Verbietet ausdrücklich die Speicherung sensibler Authentifizierungsdaten (vollständige Trackdaten, CVV, PIN) nach der Autorisierung. Dies war schon immer verboten, wurde aber jetzt präziser formuliert, um Lücken in der Art und Weise zu schließen, wie einige Systeme SAD in Debug-/Diagnoseausgaben protokollierten.

Gezielte Risikoanalyse (TRA)

v4.0 führt das Konzept der gezielten Risikoanalyse ein – Händler können alternative Ansätze für einige Anforderungen aufzeigen, wenn sie eine dokumentierte Risikoanalyse durchführen, die einen gleichwertigen Schutz belegt. Dies bietet Flexibilität für größere, komplexere Umgebungen.

---

Schritt 4 – Netzwerksicherheitsarchitektur

Für Händler mit Systemen, die über SAQ A hinausgehen, ist die Netzwerksicherheit ein zentraler Compliance-Bereich.

Anforderung 1 – Netzwerksicherheitskontrollen installieren und aufrechterhalten:

• Implementieren Sie eine Firewall zwischen nicht vertrauenswürdigen Netzwerken (Internet) und dem CDE
• Implementierung einer Firewall zwischen CDE und anderen internen Netzwerken (Segmentierung)
• Dokumentieren Sie alle Firewall-Regeln mit geschäftlicher Begründung
• Überprüfen Sie die Firewall-Regeln mindestens alle 6 Monate – Den gesamten Datenverkehr verweigern, der nicht ausdrücklich erforderlich ist (Standardeinstellung: Verweigern)
• Für E-Commerce: WAF (Web Application Firewall) vor Webservern implementieren

Netzwerksegmentierungstests:

Ein häufiges Missverständnis besteht darin, dass die Netzwerksegmentierung den Umfang automatisch verringert. Bei PCI SSC müssen Sie testen, ob die Segmentierung effektiv ist. Penetrationstests müssen Versuche umfassen, die Segmentierungsgrenze zu überschreiten. Wenn ein Penetrationstester CDE-Systeme aus Netzwerken außerhalb des Geltungsbereichs erreichen kann, ist die Segmentierung nicht effektiv und die breitere Umgebung gerät in den Geltungsbereich.

DMZ-Architektur für E-Commerce:

Internet → WAF/Load Balancer → DMZ (Web Servers) → Internal Firewall → CDE (Payment Servers, DB) → Internal Network

Webserver in der DMZ bedienen Ihre Storefront. Nur spezifischer, dokumentierter Datenverkehr (HTTPS zur Zahlungs-API, SQL an einem bestimmten Port zu einer bestimmten Datenbank) gelangt von der DMZ zur CDE. Der gesamte andere Verkehr wird blockiert.

---

Schritt 5 – Anwendungssicherheitsanforderungen

Anforderung 6 – Entwicklung und Wartung sicherer Systeme und Software:

• Führen Sie ein Inventar aller im Umfang enthaltenen benutzerdefinierten Software und Software von Drittanbietern
• Beheben Sie Schwachstellen im Rahmen eines formellen Schwachstellenmanagementprozesses
• Schützen Sie webbasierte Anwendungen vor bekannten Angriffen (OWASP Top 10)
• Führen Sie Sicherheitscodeüberprüfungen oder Anwendungspenetrationstests durch, bevor Sie wesentliche Änderungen in der Produktion bereitstellen
• Verwenden Sie nur Software von seriösen Anbietern mit engagierten Sicherheitspatch-Prozessen

Web Application Firewall (WAF) – Anforderung 6.3.2 und 6.4.2:

WAF ist für alle öffentlich zugänglichen Webanwendungen obligatorisch und so konfiguriert, dass es entweder Angriffe blockiert oder innerhalb einer Stunde Warnungen und Überprüfungen generiert. Für E-Commerce muss WAF Folgendes abdecken:

• Verhinderung von SQL-Injection
• Schutz vor Cross-Site-Scripting (XSS).
• Schutz vor Cross-Site-Request-Forgery (CSRF).
• Erkennung bösartiger Bots
• Ratenbegrenzung zur Brute-Force-Prävention

Abhängigkeits- und Softwareverwaltung von Drittanbietern:

E-Commerce-Plattformen (WooCommerce, Magento, Shopify-Anpassungen) sind stark auf Plugins und Erweiterungen angewiesen. Jedes Plugin im Geltungsbereich muss auf Sicherheit überprüft werden. Führen Sie einen Bestand und wenden Sie Patches im Rahmen Ihres Patching-SLA an (kritisch: 7 Tage ab Veröffentlichung des Anbieter-Patches).

---

Schritt 6 – Zugriffskontrolle und Authentifizierung

Anforderung 7 – Zugriff auf Systemkomponenten und Karteninhaberdaten beschränken:

• Implementieren Sie eine rollenbasierte Zugriffskontrolle basierend auf der geringsten Berechtigung
• Standardmäßiger Zugriff auf „Alle verweigern“ mit dokumentierter expliziter Gewährung
• Überprüfen Sie die Benutzerzugriffsrechte mindestens alle 6 Monate

Anforderung 8 – Benutzer identifizieren und Zugriff authentifizieren:

• Weisen Sie jeder Person mit Zugriff auf das CDE eine eindeutige ID zu
• Passwörter müssen mindestens 12 Zeichen lang sein (in Version 4.0 mehr als 7 in Version 3.2.1), Anforderungen an die Komplexität
• Konten nach maximal 10 ungültigen Versuchen sperren (v4.0-Standard oder pro TRA) – Sitzungs-Timeout nach maximal 15 Minuten Inaktivität für CDE-Sitzungen – MFA für den gesamten CDE-Zugriff erforderlich (v4.0-Erweiterung von nur Remote)
• Dienstkonten und Systemkonten müssen getrennt von Benutzerkonten verwaltet werden

---

Schritt 7 – Schwachstellenmanagement und -tests

Anforderung 11 – Testsicherheit von Systemen und Netzwerken:

Vierteljährliche interne Schwachstellenscans: Scannen Sie alle betroffenen Systeme. Beheben Sie alle schwerwiegenden und kritischen Schwachstellen vor dem nächsten Scan. Scans können von internen Mitarbeitern mit zugelassenen Tools (Nessus, Qualys, OpenVAS) durchgeführt werden.

Vierteljährliche externe Schwachstellenscans durch einen zugelassenen Scan-Anbieter (ASV): Externe Scans aller extern zugänglichen Systeme müssen von einem vom PCI SSC zugelassenen ASV durchgeführt werden. Der Scan muss bestanden werden (keine offenen hohen/kritischen Schwachstellen), bevor Sie die Konformität bestätigen können.

Jährlicher Penetrationstest: Wird von einer qualifizierten internen Ressource oder einem seriösen externen Unternehmen durchgeführt. Muss Folgendes abdecken:

• Alle im Umfang enthaltenen Systeme und Netzwerke
• Segmentierungskontrollen (überprüfen Sie, ob CDE ordnungsgemäß isoliert ist)
• OWASP Top 10 für webbasierte Anwendungen
• Social Engineering (für Umgebungen mit höherem Risiko)

Beheben Sie alle Ergebnisse des Penetrationstests und führen Sie Verifizierungstests durch, um die Behebung zu bestätigen.

Dateiintegritätsüberwachung (FIM): Stellen Sie FIM für alle kritischen Systemdateien, Konfigurationsdateien und Inhaltsdateien bereit. Benachrichtigung innerhalb einer Stunde (Version 4.0) über alle nicht autorisierten Änderungen.

---

PCI-DSS-Compliance-Checkliste für E-Commerce

• Umfang der Zahlungsabwicklung definiert und reduziert (wo möglich gehostete Zahlungsseite oder Tokenisierung verwendet)
• SAQ-Typ basierend auf der Zahlungsakzeptanzmethode identifiziert
• Netzwerksegmentierung implementiert und dokumentiert
• Bestandsaufnahme der Karteninhaberdaten abgeschlossen – nirgendwo SAD gespeichert
• Die gesamte Speicherung der Karteninhaberdaten ist verschlüsselt (AES-256 oder gleichwertig)
• TLS 1.2+ wird für die gesamte Zahlungsdatenübertragung erzwungen
• Skriptbestand der Zahlungsseite dokumentiert (Anforderung 6.4.3)
• Änderungs-/Manipulationserkennung auf Zahlungsseiten bereitgestellt (Anforderung 11.6.1)
• WAF wird vor allen öffentlich zugänglichen Webanwendungen bereitgestellt
• MFA für den gesamten CDE-Zugriff erzwungen (Anforderung 8.4.2)
• Eindeutige Benutzer-IDs, sichere Passwörter, Kontosperrung konfiguriert
• Vierteljährliche Schwachstellenscans (intern + ASV extern) abgeschlossen
• Jährlicher Penetrationstest abgeschlossen, Feststellungen behoben
• Dateiintegritätsüberwachung, bereitgestellt auf CDE-Systemen
• Firewall-Regeln innerhalb der letzten 6 Monate überprüft
• Sicherheitsbewusstseinsschulung für alle mit CDE in Berührung kommenden Mitarbeiter abgeschlossen
• Der Incident-Response-Plan deckt Szenarien von Verstößen gegen Zahlungskarten ab
• PCI-DSS-Konformität des Anbieters/Dienstanbieters überprüft

---

Häufig gestellte Fragen

Wir nutzen Shopify für unseren Shop – benötigen wir weiterhin PCI DSS-Konformität?

Shopify ist ein nach PCI DSS Level 1 zertifizierter Dienstleister. Wenn Sie die Standard-Zahlungsabwicklung von Shopify nutzen (Shopify Payments oder von Shopify gehosteter Checkout), wird Ihr Compliance-Umfang drastisch reduziert. Sie haben weiterhin Verpflichtungen – hauptsächlich SAQ A – bezüglich Ihrer Nutzung der Dienste von Shopify. Wenn Sie Ihrem Shopify-Checkout benutzerdefiniertes JavaScript hinzufügen oder Zahlungs-Apps von Drittanbietern verwenden, die Kartendaten außerhalb der Shopify-Umgebung verarbeiten, erweitert sich der Umfang.

Was ist der Unterschied zwischen PCI-DSS-Konformität und PCI-DSS-Zertifizierung?

Es gibt keine formelle „PCI DSS-Zertifizierung“ für Händler. Händler bescheinigen die Einhaltung durch Selbstbewertungsfragebögen oder (Händler der Stufe 1) durch einen von einem QSA erstellten Compliance-Bericht (Report on Compliance, RoC). Dienstleister können im globalen Register der Dienstleister von Visa aufgeführt werden. Die Begriffe „zertifiziert“ und „konform“ werden in der Marktkommunikation oft synonym verwendet, aber technisch gesehen bescheinigen Händler die Konformität selbst oder verfügen über eine QSA-zertifizierte Konformität.

Welche Strafen drohen Händlern bei Nichteinhaltung?

Strafen kommen nicht direkt vom PCI SSC, sondern von Kartenmarken über Acquiring-Banken. Die monatlichen Bußgelder liegen in der Regel zwischen 5.000 und 100.000 US-Dollar, je nach Händlerstufe und Dauer der Nichteinhaltung. Nach einem Verstoß können Kartenmarken Bußgelder pro Karte (50–90 US-Dollar pro Visa-Karte, ähnlich für Mastercard), forensische Untersuchungskosten (20.000–200.000 US-Dollar und mehr) und obligatorische Kosten für die Neuausstellung der Karte verhängen. In schwerwiegenden Fällen verlieren Händler ihre Fähigkeit, Kartenzahlungen vollständig zu akzeptieren. Wiederholungstäter oder Händler mit großen Verstößen müssen mit den höchsten Strafen rechnen.

Was ist ein Magecart-Angriff und wie geht PCI DSS v4.0 damit um?

Magecart bezieht sich auf Angriffe, bei denen bösartiges JavaScript in E-Commerce-Checkout-Seiten eingeschleust wird, um Karteninhaberdaten in Echtzeit abzufangen, während Kunden diese eingeben. Diese Angriffe nutzen Skripte von Drittanbietern (Analysen, Chat-Widgets, Tag-Manager) aus, die Händler auf Zahlungsseiten einbinden. Die PCI DSS v4.0-Anforderungen 6.4.3 und 11.6.1 befassen sich direkt damit: Händler müssen eine Bestandsaufnahme aller Skripte auf Zahlungsseiten durchführen und deren Integrität überprüfen sowie eine Überwachung einsetzen, um unbefugte Änderungen am Code der Zahlungsseite zu erkennen.

Wie gehen wir mit PCI DSS für eine Headless-E-Commerce-Architektur um?

Headless eCommerce trennt die Frontend-Präsentationsschicht von der Backend-Commerce-Engine. Für PCI DSS-Zwecke kommt es darauf an, wohin die Karteninhaberdaten fließen. Wenn Ihr Headless-Frontend Stripe Elements oder eine ähnliche iFrame-basierte Lösung verwendet, werden Kartendaten direkt vom Browser an den Zahlungsabwickler übertragen, ohne Ihre Frontend-Server zu berühren – das ist SAQ A-Gebiet. Wenn Ihre Headless-Architektur eine benutzerdefinierte serverseitige Zahlungsabwicklung umfasst, erweitert sich der Umfang erheblich und Sie sollten einen QSA mit der Beratung zur Festlegung des Umfangs beauftragen.

Benötigen wir eine QSA für unsere PCI DSS-Bewertung?

Nur Händler der Stufe 1 (über 6 Millionen Transaktionen/Jahr für Visa/Mastercard) müssen einen QSA für einen jährlichen Compliance-Bericht (RoC) beauftragen. Händler der Stufen 2–4 können sich per SAQ selbst bestätigen. Viele Händler beauftragen jedoch freiwillig einen QSA oder ein Qualified Security Assessor Company (QSAC) mit der Beratung, auch wenn dies nicht erforderlich ist, insbesondere wenn sie sich über ihren Umfang nicht sicher sind oder über eine komplexe Infrastruktur verfügen.

---

Nächste Schritte

Die PCI-DSS-Konformität schützt die Zahlungsdaten Ihrer Kunden, begrenzt Ihr Haftungsrisiko und ist eine Voraussetzung für die Aufrechterhaltung der Kartenakzeptanz. Für E-Commerce-Unternehmen auf Shopify oder benutzerdefinierten Plattformen besteht der erste Schritt immer in der Reduzierung des Umfangs. Der schnellste und kostengünstigste Weg ist es, SAQ A durch die ordnungsgemäße Nutzung gehosteter Zahlungsseiten zu erreichen.

Das E-Commerce-Implementierungsteam von ECOSIRE verfügt über umfassende Erfahrung beim Aufbau von PCI-DSS-konformen Shopify-Shops und benutzerdefinierten Handelsplattformen, wobei die Zahlungsarchitektur von Grund auf so konzipiert ist, dass der CDE-Umfang minimiert wird.

Erste Schritte: ECOSIRE Shopify Services

Haftungsausschluss: Dieser Leitfaden dient ausschließlich Informationszwecken und stellt keine Rechts- oder Compliance-Beratung dar. Die PCI DSS-Anforderungen können sich je nach Kartenmarke und Acquirer ändern und variieren. Beauftragen Sie einen QSA mit der definitiven Compliance-Anleitung speziell für Ihre Umgebung.