Ziehe die reale Zahlungs‑Boundary
Zeichne den Käuferpfad von der Produktseite bis zur Bestätigung auf. Markiere Karteneingabe, Redirects, Frames, Skripte, APIs, Plugins, Tag‑Manager, Content‑Delivery‑Netzwerke und Administrator‑Accounts, die ihn beeinflussen können. Beziehe zugehörige Logs, Support‑Tools und Analytics mit ein. Das ist ein Anfangs‑Dokument für deinen Provider oder Prüfer, keine abschließende Compliance‑Entscheidung.
Halte die Domain fest, die jedes Element der Zahlungsseite liefert. PCI SSC besagt, dass SAQ‑A‑Anspruch voraussetzt, dass alle Elemente der Zahlungsseite ausschließlich von PCI‑DSS‑konformen Dienstleistern stammen und keines von der Händlerseite. Für SAQ A‑EP darf jedes Element entweder vom Händler oder von einem solchen Dienstleister stammen, jedoch nicht von einer anderen Quelle. Alle weiteren Kriterien bleiben weiterhin anwendbar.
Ein Repository kann Tag‑Manager‑Injektionen und Plattform‑Einstellungen übersehen. Überprüfe Skripte, Frames, Domains und Header in einer normalen Checkout‑Browser‑Sitzung.
Untersuche Logs, Analytics und Support‑Workflows auf Zahlungsfelder. Verwende niemals echte Kartendaten in Test‑Tickets oder gemeinsam genutzten Nachweisen.
Reduziere die Angriffsfläche mit einem erklärbaren Zahlungsmodell
Wenn möglich, nutze eine Integration, bei der ein PCI‑DSS‑konformer Anbieter Kartendaten erfasst, anstatt dass deine Anwendung sie empfängt oder speichert. Ein vollständig provider‑gehosteter Redirect ist oft einfacher als ein eigenes Formular, aber eingebettete Felder und iFrames können trotzdem Einfluss von deiner Seite auf die Zahlung zulassen. Dokumentiere die tatsächliche Integration, statt dich auf ein ‚gehostet‘‑Etikett zu verlassen.
Vermeide das Vorhalten von Primary Account Numbers, Sicherheitscodes, Screenshots von Checkout‑Fehlern oder kopierten Zahlungsdetails, es sei denn, ein genehmigtes Design verlangt es. Verschlüsselung schützt Daten, aber PCI SSC mahnt, dass Verschlüsselung allein meist nicht ausreicht, um eine Umgebung aus dem Scope zu nehmen. Kläre Token‑, Key‑, Webhook‑, Refund‑ und Verantwortlichkeits‑Handhabungen mit dem Provider und qualifizierten Gutachtern.
Bewahre das Integrationshandbuch, Verantwortlichkeitsangaben, relevante Compliance‑Dokumentation und das Change‑Notification‑Verfahren zusammen mit deinem Architektur‑Dokument auf.
Füge keine Marketing‑Experimente, Replay‑Tools, Chat‑Widgets oder optionale Bibliotheken ohne benannten Owner und Review dessen, worauf sie Zugriff haben können, hinzu.
Steuere Skripte, Tags und Header
Drittanbieter‑Browsercode kann unkontrollierte Änderungen, beliebige Codeausführung und Offenlegung an andere Parteien einführen. Führe ein Checkout‑Inventar mit Domain, Zweck, Owner, Genehmigung und Ladeort für jedes Skript. Beziehe Tag‑Manager‑Regeln und vendor‑geladene Codes ein, nicht nur Dateien im Source‑Tree.
PCI SSC konzentriert sich auf autorisierte Skripte, Integrität, Manipulationsüberwachung und sicherheitsrelevante HTTP‑Header. Lege eine Baseline fest, beschränke Änderungen, detektiere Abweichungen und untersuche diese. Eine Content Security Policy (CSP) kann Quellen von Ressourcen einschränken. Teste sie, wo geeignet, zunächst im report‑only‑Modus vor der Erzwungeneinstellung. CSP ist eine Defense‑in‑Depth‑Maßnahme, kein Ersatz für sichere Programmierung oder Review.
Subresource Integrity (SRI) kann ein verändertes externes Skript ablehnen, benötigt aber kompatible Cross‑Origin‑Konfiguration und kann nach Anbieter‑Updates brechen.
Begrenze Publishing‑Rollen, fordere starke Authentifizierung, prüfe Custom‑Code‑Fähigkeiten und halte eine Prüfspur (Audit Trail) vor.
Beschränke Zugriffe und mache Checkout‑Änderungen wiederherstellbar
Trenne routinemäßiges Content‑Publishing von Checkout‑Code, Zahlungsprovider‑Administration, Hosting, DNS und Tag‑Management. Verwende benannte Accounts, Least‑Privilege und Multi‑Factor‑Authentication, wo unterstützt. Überprüfe Zugriffe nach Rollenumstellungen und entferne ehemalige Mitarbeitende, Dienstleister und Agenturen. Die konkrete PCI‑DSS‑Anwendbarkeit hängt von der Umgebung ab, aber weniger geteilte und dauerhafte Privilegien reduzieren das Risiko.
Nutze einen Release‑Prozess für den Checkout: benannter Owner, Review, wo möglich Tests, Rollback‑Methode und Post‑Release‑Browser‑Check. Teste Erfolgs‑ und Fehlerpfade, Redirects und Mobilverhalten. Status Is UP unterstützt proaktive Launch‑Readiness, Performance‑Optimierung und Rollback‑Planung rund um Releases; es bestimmt nicht die PCI‑DSS‑Konformität.
Bewahre Zugangsdaten, Backup‑Codes und Rollback‑Anweisungen in genehmigten, zugangskontrollierten Systemen auf, nie in Tickets, Screenshots oder öffentlichen Repositories.
Vergleiche nach einem Release browser‑sichtbare Skripte, Domains und Header mit dem genehmigten Inventar.
Aktualisiere den Stack und verifiziere das Ergebnis
Führe ein Inventar der Commerce‑Plattform, Plugins, Themes, Serverkomponenten, Bibliotheken, Payment‑SDKs, Tag‑Templates und Dienste, die den Checkout beeinflussen. Abonniere kritische Vendor‑Benachrichtigungen. NIST beschreibt Patch‑Management als Identifizieren, Priorisieren, Beschaffen, Installieren und Verifizieren von Updates. Dokumentiere die Änderung, teste die Payment‑Journey und bestätige, was deployed wurde.
Lege einen Notfallpfad für hochriskante Probleme und ein Wartungsfenster für Routineänderungen fest. Priorisiere exponierte Checkout‑Komponenten, aber patche die Produktion nicht blind und zerstöre Zahlungen. Nutze einen getesteten Rollback‑Ansatz und Provider‑Release‑Guidance. Ein unbekannter Owner für eine veraltete Komponente ist ein zu lösender Risikofaktor.
Bewahre Advisory, Risikoentscheidung, Testergebnis, Deployment‑Protokoll und abschließende Verifikation zusammen auf.
Bewahre Nachweise und ziehe qualifizierte Hilfe hinzu
Bewahre Diagramme, Provider‑Verantwortlichkeitsinformationen, SAQ‑Anspruchsbegründungen, Skript‑ und Header‑Inventare, Zugriffsprüfungen, Genehmigungen, Testergebnisse, Änderungen und Vendor‑Kontakte an einem kontrollierten Ort auf. Aktualisiere sie, wenn Architektur, Ownership, Skripte oder Provider sich ändern. Nachweise sollten einem autorisierten Prüfer helfen, ohne Kartendaten, Secrets oder Kundendatensätze offenzulegen.
Dein Acquirer oder die Zahlungsmarke legt anwendbare Validierungserwartungen fest. PCI SSC nennt Qualified Security Assessors als unabhängige Organisationen, die berechtigt sind, PCI‑DSS‑Assessments durchzuführen, und Approved Scanning Vendors als qualifizierte externe Scanning‑Anbieter unter den anwendbaren Anforderungen. Ziehe qualifizierte Hilfe für benutzerdefinierte Checkouts, unklare Scope‑Fragen, vermutete Kompromittierung oder SAQ‑Auswahl hinzu.
Bewahre das Checkout‑Modell, technische Owner, Eskalationskontakte, letztes Prüfdatum und Nachweis‑Links zusammen auf.