Sicherheitsstandards für Unternehmens-CMS

#Welche Compliance-Rahmenwerke für Enterprise-CMS gelten

SOC 2 und ISO 27001 bewerten den Betreiber, nicht den Theme-Code. Wer das verwechselt, kauft ein Zertifikat und behält ein offenes xmlrpc.php.

#SOC 2 Type II

SOC 2 ist eine Prüfung nach den Trust Services Criteria der AICPA. Ein Type-1-Bericht bewertet Kontrollen zu einem Stichtag, ein Type-II-Bericht attestiert, dass Kontrollen für Sicherheit, Verfügbarkeit, Vertraulichkeit, Verarbeitungsintegrität und Datenschutz über einen Prüfzeitraum wirksam waren, nicht nur an einem Stichtag. In deutschen CMS-Projekten sitzt das Attest fast immer beim Hosting- oder Cloud-Anbieter. Raidboxes nennt für die Rechenzentren ISO 27001, ISO 22301 und SOC 2 Type 2, das ist ein Standortnachweis, kein Attest über Ihren Plugin-Bestand. Cloudflare stellt SOC 2 und zusätzlich einen C5-Report nach NDA im Dashboard bereit, jährlich von einem externen Prüfer testiert. Hetzner hat im März 2026 ein C5-Testat Typ 2 bekannt gegeben.

Keines dieser Papiere deckt Ihr Plugin custom-checkout-fields ab. Der Scope steht im Bericht. Lesen Sie den Scope, bevor Sie in einer Ausschreibung “SOC2-konforme WordPress-Instanz” schreiben.

#ISO 27001

ISO/IEC 27001 verlangt ein Informationssicherheits-Managementsystem: Asset-Inventar, Risikobehandlung, Lieferantensteuerung, interne Audits, Management Review. Für ein CMS heißt das konkret: Liste der Plugins und ihrer Zulieferer, Patch-Prozess mit Frist, Zugriffskonzept für Redaktion und Agentur, Auftragsverarbeitung mit Hosting und CDN.

ISO 27001 auf dem Rechenzentrum von Raidboxes oder Hetzner erbt die WordPress-Installation nicht. Der ISMS-Schnitt sitzt dort, wo Sie Änderungen freigeben: Git, Staging, Production, wer plugin install darf.

SOC 2 und ISO 27001 sind in DAX- und Public-Sector-Beschaffung übliche Filter. Sie sind nicht gesetzlich vorgeschrieben für jeden Mittelstandsauftritt. Wer sie als magische Eigenschaft von WordPress verkauft, fällt im Vendor-Fragebogen bei der ersten Rückfrage zum Scope durch.

#Was Zero Trust für WordPress und wp-admin bedeutet

Zero Trust für ein CMS bedeutet: keine vertrauenswürdige Quell-IP, jede Admin-Sitzung wird neu bewiesen. Das alte Modell “Büro-VPN gleich Intranet gleich wp-admin” ist der Standardfund in deutschen Agenturnetzen.

#Verbindliche Multi-Faktor-Authentifizierung

Passwort plus E-Mail-Link ist 2026 kein angemessener Schutz für wp-admin. SMS-OTP scheitert an SIM-Swap. Setzen Sie FIDO2: YubiKey, Windows Hello, oder Passkeys. WordPress 7.1 kann Application Passwords für REST und CLI ausstellen. Diese Tokens sind keine zweiten Faktoren, sie sind langlebige Geheimnisse. Rotieren Sie sie, beschränken Sie sie auf den REST-User, und speichern Sie sie nicht in einem öffentlichen Git-Repo der Agentur.

Cloudflare Access (Zero Trust) vor wp-admin und /wp-login.php ersetzt in der Praxis das Firmen-VPN für verteilte Redaktionen. Allowlist nur der Büro-IPs bricht, sobald jemand im Zug arbeitet. Access mit IdP (Entra ID, Google Workspace, Keycloak) hält die Richtlinie zentral.

#Granulares IAM

Redakteure brauchen edit_posts, keine install_plugins. SEO-Rollen brauchen keine manage_options. WooCommerce-Shopmanager brauchen Bestellungen, keine Theme-Datei-Editoren. DISALLOW_FILE_EDIT in wp-config.php bleibt die erste Zeile gegen eine kompromittierte Redaktionskennung.

Für Agenturzugang gilt dasselbe Least-Privilege-Prinzip wie intern. Eine gemeinsame admin-Kennung auf All-Inkl, die fünf Freelancer teilen, macht jedes Audit-Trail wertlos. Pro Person ein Konto, nach Projektende deaktivieren, nicht umbenennen.

#Wie Sie die Server-Ebene für WordPress härten

Ein CMS ist so sicher wie PHP-FPM, der Dateibaum und der Weg in die Datenbank. Hosting-Marketingtexte ersetzen keine sshd_config.

Immutable Infrastructure ist auf Kubernetes- oder Image-basierten Hetzner-Cloud-Instanzen umsetzbar: neues Image, Rolling Replace, kein SSH-Handwerk auf Production. Auf All-Inkl-KAS und vielen Managed-WP-Tarifen existiert dieses Muster nicht. Dort ersetzen Sie Drift durch: keine manuellen Plugin-Uploads, Staging gleich Production, Deploy nur aus Git.

WAF und DDoS. Raidboxes liefert einen Security Shield plus DDoS-Schutz auf der Box. Cloudflare WAF sitzt davor und filtert Credential Stuffing gegen wp-login.php, bekannte Plugin-Paths und XML-RPC. All-Inkl stellt TLS und ein Panel bereit, die WAF bauen Sie selbst oder Sie legen Cloudflare davor. “KI-Firewall” ohne benannten Produktnamen und ohne Regelset ist kein Kontrollziel.

Backend nicht öffentlich. In Hochsicherheitsumgebungen hat wp-admin keinen öffentlichen A-Record. Zugriff läuft über Cloudflare Tunnel oder ein WireGuard-VPN auf Hetzner. Der Origin spricht nur mit dem Tunnel, nicht mit dem Internet. Das ist der Punkt, an dem Headless und gehärteter Monolith sich treffen: die PHP-Fläche verschwindet aus den Shodan-Treffern.

PHP und Core. WordPress 7.1 auf PHP 8.4. Alte 8.1-Images auf einem Root-Server in Falkenstein sind ein Patch-Problem, kein Feature. xmlrpc.php blocken (Nginx return 403 oder WAF), außer ein legitimes System braucht ihn nachweislich. REST für unauthentisierte Nutzer auf das einschränken, was das Frontend wirklich liest.

Deutsche Hosting-Wahl in der Praxis:

#BSI IT-Grundschutz für WordPress- und WooCommerce-Stacks

Im deutschen Beschaffungsprozess entscheidet das Modell, nicht das CMS-Logo. Für WordPress und WooCommerce binden vor allem APP.3.1 Webanwendungen und APP.3.2 Webserver. Wer nur SYS.1.1 auf den Hetzner-Server legt und PHP ignoriert, hat den Stack nicht modelliert.

#APP.3.1 Webanwendungen

APP.3.1 gilt für jede HTTP-Anwendung, die dynamische Inhalte und geschützte Ressourcen anbietet. WordPress ist genau das: Sessions, Cookies, Authentisierung, Dateiupload, REST. Basisanforderung APP.3.1.A1 verlangt Authentisierung, bevor geschützte Ressourcen erreichbar sind. wp-admin und die WooCommerce-REST-API (/wp-json/wc/v3) sind geschützte Ressourcen. Ein öffentlicher Warenkorb ist es nicht, ein Application-Password-Endpunkt ist es.

Weitere APP.3.1-Themen, in WordPress-Sprache:

• Eingaben validieren und ausgeben escapen (Core macht das in den APIs, Custom-Checkout-Felder oft nicht).
• Session-Cookies: secure, httponly, strikte Idle-Timeouts für Shopmanager.
• Fehlerseiten ohne Stacktraces. WP_DEBUG_DISPLAY auf Production bleibt aus.
• Dateiupload nur in kontrollierte Pfade, kein PHP in uploads.
• Protokollierung von Admin- und Gateway-Ereignissen, nicht von jeder Katalogansicht.

WooCommerce erweitert APP.3.1 um Bestell- und Zahlungsflüsse. Jedes Checkout-Plugin ist eine weitere Webanwendung im Sinne des Bausteins, auch wenn es als plugin.php daherkommt.

#APP.3.2 Webserver

APP.3.2 schützt den Dienst, der HTTP entgegennimmt: Nginx oder Apache, TLS, Module, PHP-FPM als vorgeschalteter Interpreter. Ziel des Bausteins ist der Schutz des Webservers und der darüber ausgelieferten Informationen, nicht das Redaktionskonzept.

APP.3.2.A1 (sichere Konfiguration) übersetzt sich so:

• Nur nötige Module. Kein mod_status öffentlich, kein Directory Listing auf /wp-content.
• TLS 1.2/1.3, aktuelle Cipher, HSTS. Let’s Encrypt auf Raidboxes reicht technisch, das Zertifikatsmanagement muss trotzdem im Konzept stehen.
• Getrennte vHosts für Origin und ggf. Staging. Staging nicht über dasselbe Zertifikat und denselben Admin-User wie Production erreichbar aus dem Internet.
• PHP-FPM-Pool nicht als root, open_basedir bzw. systemd-Isolation auf Hetzner-Boxen.

Headless verschiebt APP.3.2: der öffentliche Edge liefert statisches HTML ohne Interpreter. Der Origin bleibt ein Webserver mit PHP und fällt weiter unter APP.3.2, nur nicht mehr öffentlich. Details zur Architektur stehen im TCO-Leitfaden Headless vs. Monolith.

#Weitere IT-Grundschutz-Bausteine für WordPress

#BSI C5 bei der Hosting-Wahl

Der C5-Katalog (Cloud Computing Compliance Criteria Catalogue) testiert Cloud-Dienste. Das BSI hat den Katalog 2025/26 grundlegend überarbeitet und führt C5:2026 und C5:2020 nebeneinander. Ein Testat Typ 2 prüft Wirksamkeit über einen Zeitraum.

Mapping, das in Ausschreibungen standhält:

• Hetzner IaaS. C5 Typ 2 deckt Rechenzentrum, Virtualisierung, Provider-API ab. Nginx, Redis, MariaDB, WordPress bleiben Ihre Controls. Wer “wir hosten C5-konform, also ist der Shop C5” schreibt, verfehlt den Scope.
• Cloudflare. Der C5-Report gilt für Cloudflare-Dienste im Berichtsscope (typisch WAF, CDN, DNS, Access). Es gilt nicht für PHP auf dem Origin und nicht für Mollie-Webhooks.
• Raidboxes (Managed WP). Plattform mit ISO 27001, ISO 22301 und SOC 2 Type 2 laut Anbieterangabe, Rechenzentrum in Deutschland. Das ist ein starker Hosting-Nachweis. Es ist kein C5-Testat für Ihren Checkout. Plugin-Updates, die Sie verzögern, fallen aus dem Plattform-ISMS heraus.
• All-Inkl. Geeignet für kleine Auftritte. Für eine C5- oder Public-Sector-Ausschreibung fehlt der Cloud-Katalog-Nachweis. Dann entweder Origin auf Hetzner legen oder den Managed-WP-Anbieter mit testierter Plattform wählen.

C5 ersetzt APP.3.1 nicht. C5 spricht über den Cloud-Anbieter. APP.3.1 spricht über Ihre Anwendung.

#BSI TR-03183 und SBOM für WordPress

Die BSI TR-03183 ist die Technische Richtlinie zu Cyber-Resilienz-Anforderungen, als Einstiegshilfe in den Cyber Resilience Act (Verordnung (EU) 2024/2847). Sie ist weder verbindlich noch eine Konformitätsvermutung. Teil 2 beschreibt die Software Bill of Materials (SBOM), aktuell in Version 2.1.0, mit Zuordnung zu SPDX und CycloneDX. Teil 1 liegt in Version 1.0.0 vor. Der CRA gilt vollständig ab 11. Dezember 2027, die Meldepflicht für aktiv ausgenutzte Schwachstellen (Art. 14) gilt bereits seit dem 11. September 2026.

TR-03183 installiert man nicht als WordPress-Plugin. Man erzeugt aus Core, Themes, Plugins, Composer- und npm-Lockfiles eine maschinenlesbare Stückliste. Ein Shop mit Germanized, Stripe, Mollie, DHL und drei Must-Use-Plugins hat entsprechend viele Zulieferer. Genau das prüft Beschaffung 2026, nicht ein grünes “Security”-Icon im Plugin-Verzeichnis.

#Was NIS2 vom WordPress-Betrieb verlangt

Das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (BGBl. 2025 I Nr. 301) ist am 6. Dezember 2025 in Kraft getreten und setzt die Richtlinie (EU) 2022/2555 in das BSI-Gesetz um. Die Richtlinie selbst sah die Umsetzung bis 17. Oktober 2024 vor (Art. 41), Deutschland lag also gut ein Jahr dahinter. Nach Angaben des BSI fallen rund 29.500 Einrichtungen unter die neue Aufsicht, mit Registrierungs- und Meldepflicht (BSI-FAQ). Wichtige und besonders wichtige Einrichtungen melden erhebliche Vorfälle gestuft an das BSI: Frühwarnung in 24 Stunden, aktualisierte Meldung in 72 Stunden, Abschlussbericht in einem Monat (NIS-2-Richtlinie Art. 23).

Das macht einen WooCommerce-Shop nicht zur kritischen Infrastruktur. KRITIS bleibt an Betreibertypen gebunden (Energie, Wasser, Gesundheit, Finanzen in den dafür vorgesehenen Regimen). Ein Händler mit 800 SKUs ist deshalb nicht KRITIS. NIS2 greift, wenn Ihre Organisation in den Kreis der wichtigen oder besonders wichtigen Einrichtungen fällt, oder wenn Sie IKT-Dienstleister einer solchen Einrichtung sind. Dann verlangt der Kunde Nachweise in der Lieferkette.

Was das am WordPress-Stack konkret heißt:

• Logging. Admin-Logins, Rollenänderungen, Plugin-Installationen, Gateway-Webhooks, fehlgeschlagene MFA. Ziel außerhalb der WordPress-Instanz (Syslog auf Hetzner, oder eine SIEM-Strecke). Aufbewahrung so, dass ein Vorfall von letzter Woche noch rekonstruierbar ist.
• Patch-SLA. Kritische Core- und Gateway-CVEs in einer dokumentierten Frist, nicht “wenn der Freelancer Zeit hat”. Raidboxes-Auto-Updates erfüllen das nur, wenn Sie Ausnahmen (Germanized, PAYONE) ebenfalls fristen.
• Incident Reporting. Ein Runbook mit Erreichbarkeit, Verantwortlichen, und dem 24/72-Stunden-Pfad. Ohne das ist jede NIS2-Klausel im AVV leere Prosa.

Artikel 21 Absatz 2 der Richtlinie zählt die Mindestmaßnahmen auf. Jede hat am WordPress-Stack ein direktes Gegenstück:

Absatz 3 verlangt, bei der Lieferkette die Schwachstellen jedes direkten Lieferanten und die Qualität seiner Produkte und Entwicklungspraxis zu berücksichtigen. Direkte Lieferanten eines CMS sind Hoster, Agentur und jeder kommerzielle Plugin-Anbieter. Artikel 20 verpflichtet die Geschäftsleitung, die Maßnahmen zu billigen, ihre Umsetzung zu überwachen und für Verstöße einzustehen, und schreibt Schulungen für ihre Mitglieder vor. Artikel 34 setzt die Bußgeldobergrenzen bei Verstößen gegen Art. 21 oder 23 auf mindestens 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes für besonders wichtige und mindestens 7 Mio. Euro oder 1,4 % für wichtige Einrichtungen, jeweils der höhere Betrag.

DORA (seit 17. Januar 2025) gilt für Finanzunternehmen und ihre IKT-Drittdienstleister, nicht für jeden Shop. Wer WooCommerce für ein beaufsichtigtes Institut betreibt, landet in Vertrags- und Ausstiegsanforderungen der BaFin-Welt. Die Readiness-Strecke dafür liegt unter NIS2- und DORA-Readiness.

#Stand der NIS2-Umsetzung in anderen Ländern 2026

Wer Standorte oder Kunden in mehreren Ländern hat, braucht das jeweilige nationale Gesetz, nicht nur die Richtlinie. Stand nach amtlichen Quellen am 12. Oktober 2026:

Praktisch heißt das: eine CMS-Sicherheitsbasis auf Grundlage von Art. 21, und je Land ein Melde-Runbook mit der richtigen Behörde und dem richtigen Formular.

#Was der Cyber Resilience Act für WordPress-Plugins und Themes bedeutet

Der Cyber Resilience Act wurde am 20. November 2024 im Amtsblatt veröffentlicht. Seit dem 11. September 2026 gilt Artikel 14: Ein Hersteller, der von einer aktiv ausgenutzten Schwachstelle in seinem Produkt erfährt, meldet sie binnen 24 Stunden als Frühwarnung und binnen 72 Stunden als Schwachstellenmeldung über die einheitliche Meldeplattform an das koordinierende CSIRT und die ENISA.

Der CRA bindet Hersteller von Produkten mit digitalen Elementen, nicht den Betreiber einer Website. Im WordPress-Ökosystem ergibt das drei Rollen:

• Kommerzielle Plugin- und Theme-Anbieter, die Software im Rahmen einer Geschäftstätigkeit in der EU bereitstellen, sind Hersteller. Ihre Meldepflicht läuft bereits.
• Freie und Open-Source-Software fällt nur dann unter die Verordnung, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird (Erwägungsgrund 18). Für juristische Personen, die solche Software für den kommerziellen Einsatz dauerhaft unterstützen, schafft der CRA die Rolle des Open-Source-Software-Verwalters mit einer dokumentierten Cybersicherheitsstrategie (Art. 24).
• Der Shop- oder Site-Betreiber ist Nutzer. Seine NIS2- oder Vertragspflichten bleiben, aber er hat jetzt die richtigen Fragen an den Anbieter.

Drei Fragen gehören in jeden Plugin-Einkauf: Wer nimmt Ihre Schwachstellenmeldungen an, in welcher Frist liefern Sie Fixes, und können Sie für die eingesetzte Version eine SBOM liefern. Die Verordnung definiert die SBOM als formale Aufzeichnung der Komponenten und ihrer Lieferkettenbeziehungen (Art. 3 Nr. 39), TR-03183 Teil 2 beschreibt das Format.

#Angriffsfläche von Headless-WordPress und Monolith

Headless reduziert die öffentliche PHP-Fläche. Es löscht nicht die Anwendung im Sinne von APP.3.1.

Monolith. Jede Seite rendert PHP gegen MariaDB. Plugins hängen in init. Angreifer scannen /wp-content/plugins/ auf bekannte Pfade. WAF und Auto-Updates werden zur Überlebensausrüstung, nicht zum Extra.

Headless (Astro 7 vor WordPress). Das CDN liefert HTML, CSS, Assets. Kein PHP-Interpreter am Edge, keine öffentliche Datenbank. wp-admin hängt im privaten Netz oder hinter Cloudflare Access. Die Restfläche sitzt auf dem Origin: REST, Webhooks, Cron, Anwendungs-Passwörter. Ein geleaktes Application Password gegen /wp-json/ ist weiterhin ein Vorfall.

Für Enterprise-Beschaffung ist Headless oft leichter zu argumentieren, weil APP.3.2 am öffentlichen Rand ohne Interpreter auskommt. Der Origin bleibt prüfpflichtig. Eine ehrliche TCO- und Zonenrechnung steht im Headless-vs-Monolith-Leitfaden.

#OWASP Top 10:2025 am WordPress-Stack

Die OWASP Top 10:2025 ist die Liste, auf die Ausschreibungen verweisen, wenn sie “sichere Entwicklung” schreiben. Am WordPress-Stack landen die Kategorien an konkreten Stellen:

A03 ist in dieser Ausgabe neu und passt genau auf WordPress: Das Plugin-Verzeichnis ist die Lieferkette.

#OWASP ASVS 5.0 als Prüfstandard in CMS-Ausschreibungen

Die Top 10 sind eine Awareness-Liste. Für prüfbare Anforderungen im Vertrag gibt es den OWASP Application Security Verification Standard. Version 5.0.0 erschien am 30. Mai 2025 und gliedert sich in 17 Kapitel, darunter V6 Authentication, V7 Session Management, V8 Authorization, V13 Configuration und V16 Security Logging and Error Handling.

ASVS kennt drei Stufen. Level 1 umfasst rund 20 % der Anforderungen, die erste Verteidigungslinie. Level 2 ist laut OWASP das Ziel für die meisten Anwendungen und bedeutet, rund 70 % aller Anforderungen umzusetzen (alle aus L1 und L2). Level 3 ergänzt die restlichen rund 30 % für Anwendungen mit höchstem Schutzbedarf.

Für ein Unternehmens-CMS folgen daraus zwei Regeln. In den Vertrag gehört “ASVS 5.0 Level 2 für eigene Plugins und Schnittstellen”, nicht “sicher nach OWASP”. Und ein Siegel “ASVS-zertifiziert” verdient Skepsis: OWASP zertifiziert nach eigener Aussage weder Anbieter noch Prüfer noch Software.

#Wie das WordPress-Projekt Core-Sicherheit organisiert

Das WordPress Security Team besteht aus mehr als 50 vertrauenswürdigen Fachleuten, darunter Lead Developer und Sicherheitsforscher, plus gesponserten Mitgliedern (wordpress.org/about/security). Schwachstellen gehen über das HackerOne-Programm von WordPress ein. Offiziell unterstützt wird nur die aktuelle Version, Fixes werden aber aus Kulanz auf ältere Zweige zurückportiert, damit ältere Installationen kritische Korrekturen per Auto-Update erhalten. Mit großen Hostern und Sicherheitsanbietern koordiniert das Team Rollouts und WAF-Regeln.

Das WordPress Security White Paper, zuletzt aktualisiert im September 2025, beschreibt die Mechanismen, nach denen Prüfer typischerweise fragen:

• automatische Hintergrund-Updates für alle Minor-Releases, über die Sicherheitsfixes ohne Zutun des Admins ankommen;
• Passwort-Hashing mit bcrypt, mit SHA-384-Vorhashing wegen der 72-Byte-Grenze von bcrypt;
• Application Passwords, Reset-Keys und andere Tokens mit BLAKE2b über Sodium;
• Nonces gegen CSRF sowie APIs wie wpdb::prepare(), wp_kses() und die sanitize_*()-Funktionen.

Das deckt den Core ab. Dasselbe White Paper hält fest, dass die rund 50.000 Plugins und 4.500 Themes im Verzeichnis vor der Aufnahme von Freiwilligen geprüft werden, ohne Garantie auf Schwachstellenfreiheit. In Unternehmensprojekten sitzt das Risiko in dieser Schicht.

#Wie Sie Code- und Plugin-Governance für WordPress steuern

Der häufigste Enterprise-Fund in WordPress ist nicht eine Zero-Day in Core 7.1, sondern ein Plugin ohne Maintainer, das eval auf einem Transient ausführt.

Inventar vor Installation. Kein Plugin ohne benannten Maintainer, ohne Update-Pfad, ohne Verzeichnis in der SBOM. WooCommerce-Checkout, Germanized, PAYONE, Unzer, DHL: jedes Paket ist Zulieferer. “Einmal schnell Custom Fields” ist ein zweiter Checkout.

Manual Code Review für alles, was nicht vom Hersteller über einen signierten Update-Kanal kommt. Must-Use-Plugins und Agentur-mu-plugins gehören in Git, nicht nur auf den Server.

Vulnerability Tracking. Patchstack, WPScan oder die Advisory-Mails der Gateway-Hersteller. CVE-Listen ohne Patch-SLA sind Dekoration. OPS.1.1.3 verlangt den Änderungsprozess: wer darf Production anfassen, welches Staging, welches Rollback.

Composer und npm. Themes mit Build-Step schleppen Lockfiles ein. Die Lockfile-Versionen gehören in dieselbe SBOM wie die PHP-Plugins. TR-03183 Teil 2 erwartet maschinenlesbare Komponentenkennung, nicht eine Excel-Liste “Plugin XY, aktuell”.

ERP-Anbindung. Sobald Bestände und Preise aus SAP Business One, Microsoft Dynamics, JTL oder plentyONE kommen, ist das Plugin ein zweites IAM. API-Keys nicht in wp_options im Klartext, nicht im Frontend-HTML, Rotation nach Personenwechsel. Architektur und Schnittstellen: WooCommerce-ERP-Integration.

Die Konfigurationsebene (Dateirechte, wp-config.php-Konstanten, Serverregeln) beschreibt Schritt für Schritt der Leitfaden zum erweiterten WordPress-Hardening.

#Backups und Datenintegrität im Enterprise-CMS

Ein Sicherheitskonzept ohne getestete Wiederherstellung ist ein PDF.

3-2-1 in der deutschen Hosting-Realität. Raidboxes-Backup ist Kopie 1, oft auf derselben Plattform. Kopie 2 auf eine Hetzner Storage Box in einem anderen Standort (Falkenstein vs. Nürnberg) oder IONOS HiDrive. Kopie 3 offline oder in einem anderen Account, den die Production-Credentials nicht löschen können. Ransomware, die wp-config.php und das Panel-Passwort hat, löscht gern auch das “offizielle” Backup.

RPO für WooCommerce. Tagesbackup reicht für eine Broschüren-Site. Ein Shop mit Tagesumsatz im vierstelligen Bereich verliert bei RPO 24 Stunden Bestellungen, die bereits an DATEV oder das ERP gegangen sein können. Dann brauchen Sie mindestens stündliche DB-Dumps plus Binlog, oder den Managed-Backup-Rhythmus des Hosters plus asynchrone Replikation.

PITR. Point-in-Time Recovery auf MariaDB (Hetzner, eigene VM) oder das Backup-Produkt des Managed-Hosters. Vorher einmal im Quartal restore auf Staging, Stoppuhr, Protokoll. NIS2- und DORA-Fragebögen fragen genau dieses Protokoll, nicht die Marketing-SLA.

Geographie. Frankfurt plus Amsterdam klingt nach Enterprise. Für DSGVO und C5 ist der Satz “EU, AVV liegt vor, Subprozessorliste ist aktuell” relevanter als der Stadtname. Cloudflare als CDN liefert am Edge, Origin und Backup bleiben in der dokumentierten Region.

#Social Engineering gegen WordPress-Admins

Die meisten wp-admin-Übernahmen in Agenturprojekten beginnen mit einer Mail, nicht mit einem Exploit.

Redaktion und Buchhaltung sind das Ziel, weil sie Bestellungen, Rechnungen und PDF-Plugins sehen. Eine Mail “DATEV-Export fehlerhaft, bitte hier anmelden” gegen eine gefälschte Login-Seite zieht, wenn MFA fehlt. Awareness-Training ohne Phishing-Simulation bleibt Folie. Eine Simulation pro Quartal, mit der echten Login-URL als Lehrinhalt, wirkt mehr als ein Jahrestraining.

Audit Trails. Jede Plugin-Installation, jede Rollenänderung, jeder Gateway-Key-Wechsel: User, Zeit, IP, Objekt. WP Activity Log oder das Audit-Log des Hosters, ausgeleitet, nicht nur in wp_posts. Das menschliche Risiko sinkt nicht durch Moral, sondern durch die Gewissheit, dass die Aktion nachvollziehbar ist.

Agentur-Seitenwechsel: wenn der Freelancer das Projekt verlässt, fliegt der Account am selben Tag. Gemeinsame 1Password-Tresore mit einem wp-admin-Passwort für alle sind das Gegenteil von ORP.4.

#Angriffsfläche von Checkout-Plugins und Zahlungs-Gateways

Der Katalog darf am Edge cachen. Checkout, wc-ajax, PayPal-Webhooks und Mollie-Returns dürfen das nicht. Genau dort hängt die Angriffsfläche, die ein Performance-Leitfaden nicht abdeckt.

Rechtliche Checkout-Plugins (DE). Germanized (Vendidero) und German Market (MarketPress) hängen Widerruf, AGB, USt-IdNr., Kleinunternehmer und PDF-Rechnung in den Checkout. Jedes zusätzliche Feld ist APP.3.1: Speicherung, Validierung, Ausgabe. Die USt-IdNr. ist Steueridentifikationsdatum, kein Marketing-Feld. Sie gehört nicht in ein öffentliches debug.log und nicht in ein HTML-Fragment, das Query Monitor auf Production ausgibt.

Versand. DHL for WooCommerce, Packstation, Postnummer. Packstation-Nummer plus Postnummer ist personenbezogen. Das Plugin spricht Versand-APIs, oft mit einem Token in wp_options. Token-Rechte auf das Minimum (Label, Tracking), nicht auf das gesamte Geschäftskundenkonto.

Gateways, die deutsche Shops wirklich nutzen. WooCommerce PayPal Payments, Stripe, Mollie (Klarna, Sofort, Karte), Amazon Pay, PAYONE, Unzer. Jedes Gateway öffnet:

1. einen Redirect oder ein iframe/hosted field,
2. einen Webhook-Endpunkt unter /wc-api/ oder /wp-json/,
3. oft einen Status-Cron.

Ohne Signaturprüfung am Webhook bucht ein Angreifer Bestellungen auf “bezahlt”. Stripe und PayPal liefern Signaturen. Eigenbau-”Payment complete if GET secret=” ist der klassische Fund.

PCI-adjacent, ohne den Shop zum Acquirer zu machen. Wenn Kartenfelder beim PSP liegen (Stripe Elements, PayPal Hosted Fields, Mollie Components), bleibt der Händler typischerweise bei SAQ A nach PCI DSS. Sobald ein Plugin PAN oder CVC in wp_postmeta schreibt, ist diese Annahme tot. Prüfen Sie die Postmeta-Keys nach einer Testbestellung. Speichert das Plugin card_last4 plus Token, ist das üblich. Speichert es die volle Nummer, ist das Gateway sofort auszubauen.

REST und Application Passwords. wc/v3/orders mit einem zu weit berechtigten Key ist voller Zugriff auf Kundendaten. Keys pro System (ERP, DATEV-Bridge, Versand), read-only wo möglich, IP-Allowlist am Origin.

HPOS (High Performance Order Storage) gehört in den Performance-Stack, nicht hierher. Sicherheitsrelevant ist nur: Bestelltabellen erben dieselben Grants wie wp_posts. Ein SQL-User für WordPress mit GRANT ALL auf den ganzen Cluster bleibt ein Fehler, HPOS hin oder her.

#Object-Cache und Logging in PCI-nahen WooCommerce-Shops

Redis beschleunigt Objekt-Lookups. Ungefiltert speichert es auch Sessions, Transients und gelegentlich Gateway-Antworten. Das ist der Punkt, an dem Performance-Tuning zum PCI- und GoBD-Problem wird.

Was nicht in Redis darf. Rohantworten von Stripe/PayPal mit Token im Klartext über die Cache-TTL hinaus, Warenkorb-Sessions mit Zahlungsdaten, Query-Monitor-Output, WP_DEBUG-Dumps. Object-Cache-Keys von WooCommerce (wc_, product_, Session-Keys) vor einem Dump nach Staging prüfen. Ein redis-cli monitor auf Production, das in eine Ticket-Datei wandert, ist ein Datenabfluss.

debug.log und Query Monitor. WP_DEBUG_LOG nach wp-content/debug.log plus ein per Verzeichnis listbares uploads ist ein öffentliches Protokoll. USt-IdNr., E-Mail, Adresse, Packstation landen dort, sobald ein Gateway eine Exception wirft. Log-Ziel: außerhalb von DocumentRoot, Rotation, Zugriff nur für Ops.

DATEV ist die Buchhaltungssenke, kein Syslog. Deutsche Shops exportieren Buchungsstapel nach DATEV (Rechnungswesen, Unternehmen online). GoBD verlangt Nachvollziehbarkeit der Buchung, nicht das Ablegen von Kartennummern im Buchungsjournal. Getrennte Pfade:

• Security-Log (Logins, Webhooks, Deploys) auf Syslog oder SIEM.
• Bestell- und Rechnungsjournal in WooCommerce, unveränderbar nach GoBD-Logik (Germanized-Revisions, DATEV-Export).
• Kein Copy-Paste von debug.log in das DATEV-Paket.

Wer “wir loggen alles nach DATEV” schreibt, vermischt zwei Kontrollziele und fällt im PCI-Fragebogen und im Steuer-Audit gleichzeitig auf.

Cache vs. Warenkorb. Full-Page-Cache (Cloudflare, Raidboxes Advanced Cache) nur auf Katalog und Content. Cookie woocommerce_items_in_cart oder die Session darf die Cache-Bypass-Regel auslösen. Ein gecachter Mini-Cart fremder Kunden ist ein Vertraulichkeitsvorfall, kein Performance-Gewinn. Die Performance-Seite dieses Stacks (HPOS, Redis-Hitrate, Cart Fragments) liegt in einem eigenen Leitfaden. Hier zählt nur: Cache-Keys und Logs dürfen keine Zahlungs- oder Session-Fremddaten tragen.

#Enterprise-Security für WordPress mit WPPoland

WPPoland härtet WordPress- und WooCommerce-Stacks gegen die Standards, die deutsche Beschaffung tatsächlich prüft: SOC 2- und C5-Scope des Hosters, APP.3.1/APP.3.2, Zero Trust auf wp-admin, SBOM nach TR-03183, Checkout- und Gateway-Fläche. WPPoland selbst hält weder ein SOC-2-Attest noch ein ISO-Zertifikat, die Nachweise sind betrieblicher Art.

1. Security-first im Code. OWASP Top 10:2025 als Prüfgrid und ASVS 5.0 als Anforderungsliste, wo der Vertrag eine verlangt. Custom-Checkout und ERP-Mapper gehen durch Review, bevor sie auf Production liegen.
2. Monitoring plus Review. Scanner (CVE, File Integrity) laufen dauerhaft. Menschliche Review sitzt auf Gateway-Updates, Rollenänderungen und Restore-Tests.
3. Nachweise, keine Sprüche. Patch-SLA, Restore-Protokoll, Subprozessorliste, Runbook mit 24/72-Stunden-Pfad. Das ist das Lieferobjekt in NIS2- und DORA-Fragebögen.

Der Einstieg ist ein WordPress-Sicherheitsaudit. Für regulierte Lieferketten ergänzt das die Strecke NIS2- und DORA-Readiness.

#Zusammenfassung der Sicherheitsstandards für Unternehmens-CMS

Ein Unternehmens-CMS 2026 besteht die Prüfung, wenn Hosting-Nachweis, Anwendungsmodell und Betrieb zusammenpassen. SOC 2 und ISO 27001 filtern den Anbieter. APP.3.1 und APP.3.2 modellieren WordPress und den Webserver. C5 hängt an Hetzner, Cloudflare oder der Managed-WP-Plattform, nicht am Theme. NIS2 verlangt Logs, Patch-Fristen und eine Meldekette, sobald die Organisation oder der Auftraggeber im Scope ist. KRITIS ist ein Betreibertyp, kein Shop-Feature.

TR-03183 liefert die SBOM-Sprache für den CRA, kein Plugin. Am Checkout entscheiden Signaturprüfung, SAQ-A-Grenze und das, was Redis und debug.log nicht enthalten dürfen. DATEV bekommt Buchungen, das SIEM bekommt Admin- und Webhook-Ereignisse.

Sicherheit bleibt ein Zyklus: inventarisieren, härten, überwachen, wiederherstellen, nachweisen. Wenn dieser Zyklus fehlt, ändert kein Zertifikat des Hosters den nächsten Vorfall.

Entspricht Ihr CMS den aktuellen Sicherheitsstandards? Der nächste Schritt ist ein Sicherheitsaudit.