PCI DSS 4.0.1: Neue Pflichten für Shopbetreiber

Seit April 2025 ist es offiziell: Die neue Version des Payment Card Industry Data Security Standards (PCI DSS 4.0.1) ist in Kraft – und bringt für Betreiber von Onlineshops spürbare Änderungen mit sich.
In diesem Artikel fassen wir die wichtigsten Erkenntnisse aus unserem Webinar mit den Magento-Experten von basecom kompakt zusammen. Mit dabei: praxisnahe Beispiele, hilfreiche Tools und klare To-dos. Du erfährst, welche Maßnahmen du jetzt ergreifen solltest, um dein Shopsystem PCI-konform und zukunftssicher aufzustellen.
Tipp vorab: Du willst erst mal verstehen, worum es bei PCI DSS grundsätzlich geht? Dann schau dir unseren Grundlagenartikel an: PCI DSS: Das müssen E-Commerce-Händler wissen.
Was ist PCI DSS 4.0.1 – und warum betrifft es Shopbetreiber?
PCI DSS steht für Payment Card Industry Data Security Standard. Der Standard existiert seit 2004 und definiert Sicherheitsanforderungen für alle, die Kreditkartendaten speichern, verarbeiten oder übertragen – also auch für viele E-Commerce-Händler.
Mit Version 4.0.1 verschärft sich der Fokus auf technische Sicherheit, Nachvollziehbarkeit und klare Prozesse. Und: Auch wenn du keine Kreditkartendaten direkt speicherst, kann dein Shop betroffen sein.
Wichtig: Bereits die Integration eines Zahlungsdienstleisters per iFrame oder Script im Check-out reicht aus, um unter den Anwendungsbereich zu fallen.
Ziel von PCI DSS 4.0.1:
- Kreditkartendaten und personenbezogene Informationen noch besser schützen
- Sicherheitslücken und Missbrauch verhindern
- Bußgelder und rechtliche Folgen vermeiden
Viele Anforderungen, die bisher nur empfohlen wurden, sind ab April 2025 verpflichtend – darunter zum Beispiel:
- Zwei-Faktor-Authentifizierung (2FA) für Admins
- Stärkere Passwortrichtlinien
- Regelmäßige Security-Scans durch zertifizierte Anbieter
- Der Einsatz einer Content Security Policy (CSP) im Check-out
Was ändert sich konkret mit PCI DSS 4.0.1?
PCI DSS 4.0.1 bringt nicht nur ein Update, sondern einen echten Paradigmenwechsel: Viele technische und organisatorische Maßnahmen, die bisher nur als „Best Practice“ galten, sind ab April 2025 verpflichtend – und damit Teil des Audits bzw. der SAQ (Self-Assessment Questionnaires).
Damit du den Überblick behältst, haben wir die wichtigsten Neuerungen für dich zusammengefasst – mit Fokus auf Magento und typische Set-ups im E-Commerce.
Zwei-Faktor-Authentifizierung (2FA) wird Pflicht
Alle Zugriffe auf das Admin-Backend müssen ab sofort mit 2FA abgesichert sein. Das bedeutet: Ein einfaches Login mit Benutzername und Passwort reicht nicht mehr.
Magento bietet diese Funktion bereits im Core – viele Shopbetreiber hatten sie jedoch deaktiviert oder nur bei ausgewählten Accounts im Einsatz.
Wichtig für dich:
- Aktiviere 2FA für alle Admin-Zugänge
- Entferne ggf. ältere Extensions, die ein Umgehen ermöglichen
- Dokumentiere deine 2FA-Richtlinie im Sicherheitskonzept
Stärkere Passwort-Richtlinien
Auch bei Passwörtern gelten nun klare Vorgaben. Für Admin-Accounts gilt:
- Mindestens 12 Zeichen
- Regelmäßige Änderung (Rotation z. B. alle 90 Tage – sofern kein 2FA)
- Keine Wiederverwendung früherer Passwörte
Magento selbst erfüllt diese Anforderungen noch nicht im Standard – ein Pull Request ist aber bereits eingereicht. Bis dahin hilft ein eigenes Modul oder individuelle Konfiguration.
Praxis-Tipp aus dem Webinar: Wer 2FA konsequent einsetzt, kann auf die regelmäßige Passwortänderung verzichten – was die Usability verbessert und trotzdem sicher bleibt.
Sicherheitsscans: Jetzt verpflichtend
Ob ein regelmäßiger Schwachstellenscan verpflichtend ist, hängt vom jeweiligen SAQ-Level ab.
Bei SAQ A-EP oder komplexeren Zahlungssetups sind diese Scans verpflichtend – mindestens alle 90 Tage.
Bei einem vollständigen Redirect (z. B. SAQ A) sind sie nicht zwingend vorgeschrieben, aber dennoch dringend empfohlen, um potenzielle Sicherheitslücken frühzeitig zu erkennen und zu beheben.
Eine Übersicht:
SAQ-Typ | Beispiel | Scans verpflichtend? |
---|---|---|
SAQ A | Vollständiger Redirect zu einem PSP (z. B. PayPal, Stripe) | Nicht verpflichtend, aber empfohlen |
SAQ A-EP | Eingebettete Zahlungsformulare mit iFrame oder JS | Verpflichtend alle 90 Tage |
SAQ B / B-IP / B-SP | Terminal-/App-basierte Zahlung (E-Commerce eher selten) | Ja, je nach Setup |
In Deutschland sind aktuell folgende Anbieter als Approved Scanning Vendors (ASV) zertifiziert:
Klare Verantwortlichkeiten
Wer darf was im System? Wer ist für Sicherheit zuständig? PCI DSS 4.0.1 fordert eine klare Rollenverteilung und Dokumentation aller sicherheitsrelevanten Zuständigkeiten – vom Deployment bis zur Reaktion im Notfall.
Das bedeutet konkret:
- Definierte Prozesse für Zugriffsrechte, Deployments und Updates
- Klare Eskalationswege bei Vorfällen
- Regelmäßige Überprüfung und Protokollierung aller sicherheitskritischen Aktionen
Keine Speicherung von Kreditkartendaten
Auch wenn es banal klingt: Kreditkartendaten dürfen im Shop niemals gespeichert werden – weder bewusst noch versehentlich.
Wer hier auf externe Zahlungsanbieter wie PayPal, Stripe oder Klarna setzt und komplett per Redirect oder iFrame abwickelt, reduziert nicht nur das Risiko, sondern auch den eigenen PCI-DSS-Aufwand deutlich.
Content Security Policy (CSP): Schutzschild im Check-out
Gerade der Check-out ist ein sensibler Bereich im Onlineshop – hier fließen Kundendaten, Zahlungsinformationen und Tracking-Skripte zusammen. Ein beliebter Angriffsvektor für E-Skimming oder Cross-Site-Scripting (XSS). Deshalb rückt mit PCI DSS 4.0.1 ein Sicherheitsmechanismus in den Fokus, der oft unterschätzt wird: die Content Security Policy (CSP).
Was ist eine CSP überhaupt?
Die Content Security Policy ist ein HTTP-Header, der dem Browser genau vorgibt:
- Welche Skripte und Ressourcen geladen werden dürfen
- Von welchen Domains sie stammen müssen
- Wie mit Inline-Skripten, Styles und iframes umgegangen wird
Kurz gesagt: CSP wirkt wie ein Sicherheitsfilter auf Browser-Ebene – und blockiert alles, was nicht explizit erlaubt wurde. Damit lassen sich viele typische Angriffe effektiv verhindern, bevor sie überhaupt stattfinden.
CSP in Magento – das ist bereits integriert
Magento bringt seit Version 2.3.5 ein solides CSP-Framework mit. Das bietet dir:
- Ein regelbasiertes System direkt im Code (nicht im Adminbereich – bewusst zur Absicherung)
- Einen Report-Only-Modus für alle Seiten außer dem Checkout
- Unterstützung für Subresource Integrity (SRI) bei lokal eingebundenen Dateien
Wichtig: Im Checkout-Bereich muss die CSP im „Enforced“-Modus laufen – sonst ist dein Setup nicht PCI-konform.
So funktioniert die Umsetzung in der Praxis
CSP-Regeln müssen individuell auf deinen Shop abgestimmt werden – je nachdem, welche Skripte, Fonts, Tools oder Pixel du einsetzt. Es gibt zwei bewährte Wege, wie du deine Whitelist pflegen kannst:
Variante 1: Manuell mit Browser-Extension
- Mit Tools wie dem Magento CSP Whitelist Generator kannst du dich durch den Check-out klicken
- Das Tool generiert dir eine .xml-Datei für deine Whitelist
- Diese Datei musst du dann ins Projekt deployen
Nachteil: Änderungen an Skripten oder externen Quellen erfordern jedes Mal ein neues Deployment.
Variante 2: Automatisiertes CSP-Monitoring
- Tools wie Sansec Watch, Sentry oder das CSP-Modul von IntegerNet
- Verstöße werden automatisch erkannt und als Report aufbereitet
- Whitelist kann direkt über eine Web-UI gepflegt und bei Bedarf übernommen werden
- Synchronisation mit Magento erfolgt automatisiert
Best Practice: Kombiniere Sansec Watch mit dem CSP-Modul von integer_net für eine komfortable und auditsichere Lösung – ganz ohne manuelle Deployments.
Typische Stolperfallen & Lösungen
Problem | Erklärung | Lösung |
---|---|---|
CSP-Header zu groß (>8 KB) | Apache kann nur Header bis 8 KB verarbeiten | Header aufsplitten (z. B. mit Open-Source-Modul) |
Nonces & Caching | z. B. Probleme bei Varnish oder Full Page Cache | Auf Hash-basierte Freigabe umstellen |
GTM lädt externe Skripte | Diese werden standardmäßig geblockt | Manuell freigeben über CSP-Modul |
Unsafe-inline im Check-out | Sicherheitslücke bei kompromittierten Admins | Secure Renderer + Hash-basierte Freigabe verwenden |
Technische Maßnahmen: So setzt du PCI DSS 4.0.1 im Magento-Shop um
Viele der neuen PCI DSS 4.0.1 -Vorgaben betreffen ganz konkret den technischen Betrieb deines Shops. Gute Nachrichten: Magento bringt viele Voraussetzungen bereits mit – du musst sie nur aktiv nutzen und richtig konfigurieren. Hier kommen die wichtigsten Punkte, die du jetzt prüfen (und ggf. anpassen) solltest.
Zwei-Faktor-Authentifizierung (2FA) aktivieren
Zugriffe auf das Magento-Admin-Panel müssen künftig zwingend durch eine Zwei-Faktor-Authentifizierung abgesichert sein. Das war bisher nur „Best Practice“ – jetzt ist es Pflicht.
- Magento unterstützt 2FA bereits out of the box
- Achtung: Die Deaktivierung ist nicht mehr erlaubt
- Prüfe bestehende Admin-User – und vergib nur notwendige Rollen!
Verwende keine Erweiterungen mehr, die 2FA abschalten oder umgehen. Diese sind nicht PCI-konform und ein Sicherheitsrisiko.
Passwort-Policy & Session-Timeout anpassen
PCI DSS 4.0.1 verlangt stärkere Passwortregeln für Admin-Zugänge:
- Mindestens 12 Zeichen
- Keine Wiederverwendung (History)
- Regelmäßige Änderung – alle 90 Tage (wenn kein 2FA aktiviert ist)
Magento erlaubt aktuell nur 7 Zeichen – Basecom hat bereits einen Pull Request bei Adobe eingereicht. Bis dahin kannst du:
- eigene Passwortvorgaben im Code oder per Modul umsetzen
- auf ein eigenes Security-Modul zurückgreifen
Ebenso Pflicht: ein automatischer Session-Timeout nach 15 Minuten Inaktivität. Das kannst du in den Magento-Konfigurationen direkt einstellen.
Zugriffskontrolle mit ACL
Magento bietet ein fein granular steuerbares Access Control List (ACL)-System. Nutze es, um:
- Rollen und Rechte exakt zu vergeben
- Shared Accounts zu vermeiden
- Zugriffsrechte regelmäßig zu prüfen
- Dokumentation zu pflegen: Wer darf was – und warum?
Ein regelmäßiger Rechte-Check gehört zur PCI-Dokumentation und kann im Audit abgefragt werden.
Angriffspunkte schließen: Deaktiviere, was du nicht brauchst
„Reduce your attack surface“ – ein zentraler Gedanke bei PCI DSS. Deaktiviere alles, was nicht zwingend notwendig ist:
- SOAP / GraphQL APIs, wenn nicht genutzt
- Default-Accounts & ungenutzte Extensions
- Alte Module ohne Sicherheitsupdates
- Beispiel: Entferne alte Development-Tools aus dem Live-System
Auch Systempasswörter (z. B. API-Keys) sollten regelmäßig automatisch rotiert werden – idealerweise über CI/CD-Prozesse.
Security Scans & Monitoring
Ob regelmäßige Sicherheitsscans verpflichtend sind, richtet sich nach dem verwendeten SAQ-Typ. Für SAQ A-EP und ähnliche Set-ups sind sie Pflicht – in anderen Fällen werden sie dringend empfohlen. Diese Tools sind besonders hilfreich:
- Magento Security Scan von Adobe
- Sansec eComscan
- Approved Scanning Vendors (ASV) wie SRC GmbH oder USD AG
Außerdem sinnvoll:
- Logging von Admin-Logins, Fehlversuchen & Zugriffen
- Dokumentation aller installierten Erweiterungen
- Protokolle zu Updates und Systemveränderungen
Sicheres Deployment & Update-Management
Ein sicheres Shopsystem endet nicht bei der Einrichtung – auch der Betrieb muss gewissen Standards genügen.
Best Practices fürs Deployment:
- Trennung von Dev, Staging und Produktivsystem
- Keine direkten Änderungen am Live-System
- Verwendung von Deployment-Tools wie Deployer, GitLab CI oder GitHub Actions
- Logging & Rollback-Möglichkeiten
Update-Zeiten laut PCI DSS 4.0.1:
Update-Typ | Zeitrahmen |
---|---|
Kritische Sicherheitslücken | binnen 72 Stunden |
Mittlere Lücken | binnen 14 Tagen |
Allgemeine sicherheitsrelevante Updates | binnen 30 Tagen |
Sonstige Updates | spätestens nach 90 Tagen |
Tipp: Aktiviere Watchlists, um über neue Magento-Releases und Third-Party-Updates rechtzeitig informiert zu werden.
Penetrationstests, SAQs & Notfallpläne: Vorbereitung auf den Ernstfall
PCI DSS 4.0.1 bringt nicht nur technische Anforderungen mit sich, sondern auch formale und organisatorische Pflichten. Ein sicheres Shopsystem umfasst neben sauberem Code und abgesicherten Zugängen auch klar dokumentierte Prozesse – für Audits, Sicherheitsvorfälle und Selbstprüfungen.
Self-Assessment Questionnaires (SAQs)
Welche Sicherheitsanforderungen für deinen Shop gelten, hängt davon ab, wie du Kreditkartenzahlungen abwickelst.
Die wichtigsten SAQ-Typen:
- SAQ A: Du leitest komplett an einen Payment Provider via iFrame oder Redirect weiter (z. B. Stripe Check-out).
- SAQ A-EP: Es gibt eigene Skripte im Check-out, aber die Zahlungsdaten laufen trotzdem über den PSP.
- SAQ B/IP/B-SP: Für Terminal- oder App-basierte Zahlungen (im E-Commerce selten).
Wichtig: Auch wenn du keine Kartendaten selbst speicherst, musst du SAQs ausfüllen – und ggf. jährlich vorlegen. Die Anforderungen aus PCI DSS 4.0.1 gelten auch für iframe-basierte Setups!
Was du dafür brauchst:
- Nachweis über regelmäßige Schwachstellenscans
- Dokumentierte CSP-Regeln im Checkout
- Absicherung der Admin-Zugänge (z. B. via 2FA)
- Übersicht über alle eingesetzten Erweiterungen
- Klar definierte Rollen- und Rechteverteilung im Team
Penetrationstests – sinnvoll & teilweise Pflicht
Bei komplexeren Zahlungswegen (z. B. SAQ A-EP) oder eigener Payment-Integration kann ein Penetrationstest verpflichtend sein.
Das Ziel: Herausfinden, ob sich über bekannte Sicherheitslücken Zugang zum System oder zu Kartendaten verschaffen lässt.
Wann sinnvoll?
- Bei customisierten Magento-Checkouts
- Nach größeren Updates oder Deployment-Wechseln
- Bei Nutzung von eigenen Zahlungsmodulen
Tipp: Viele Approved Scanning Vendors bieten kombinierte Pakete aus ASV-Scan & Penetrationstest an – ideal für den Jahrescheck.
Notfallplan: Was tun, wenn’s brennt?
Ein Datenleck, ein kompromittierter Zugang oder ein manipuliertes Skript im Check-out – im Ernstfall zählt jede Minute. Deshalb fordert PCI DSS 4.0.1 einen konkreten Incident-Response-Plan, inklusive:
- Benennung eines verantwortlichen Teams oder Ansprechpartners
- Übersicht, wie & wann das Team erreichbar ist (auch außerhalb der Bürozeiten)
- Checkliste für Sofortmaßnahmen (z. B. Admins sperren, Backups prüfen, Logs analysieren)
- Kommunikationsplan für Kunden, Partner und – falls nötig – die Aufsichtsbehörde (DSGVO!)
Protokolliere Sicherheitsvorfälle – auch wenn nichts passiert ist. Das zeigt: Du nimmst deine Pflichten ernst.
Fazit
PCI DSS 4.0.1 bringt klare und verbindliche Sicherheitsanforderungen für Onlineshops – besonders im Umgang mit Kreditkartendaten. Wer Magento nutzt, hat viele Tools bereits an Bord, muss sie aber aktiv konfigurieren und pflegen. Jetzt ist der richtige Zeitpunkt, um Prozesse, Zugriffe und Schutzmechanismen wie CSP oder 2FA systematisch umzusetzen – für mehr Sicherheit, weniger Risiko und langfristige Compliance.
Die komplette Webinar-Aufzeichnung findest du hier: https://maxcluster.de/events/pci-dss – mit vielen Praxisbeispielen und Empfehlungen direkt von unseren Partnern bei basecom.
Veröffentlicht am 24.04.2025 | PCI DSS 4.0.1: Neue Pflichten für Shopbetreiber | KS