Magento-Admin-Hardening: Checkliste für 2026

Angreifer, die in den Magento-Admin gelangen, können einen Skimmer in den Checkout einschleusen, Kundendaten exportieren oder einen versteckten Admin-Benutzer für später anlegen. Die meisten erfolgreichen Angriffe beginnen mit einer Schwachstelle, die eine Checkliste aufgedeckt hätte: ein mehrfach verwendetes Passwort, eine veraltete Extension, ein verpasster Sicherheitspatch oder ein vergessenes Testkonto.

Nutzen Sie die folgende Liste als Audit. Jeder Punkt beschreibt, was zu prüfen ist, und wo es hilft, den genauen Befehl. Führen Sie die Befehle im Magento-Root als Eigentümer des Dateisystems aus und testen Sie zuerst auf Staging.

1. Zwei-Faktor-Authentifizierung für jeden Admin-Benutzer erzwingen

Seit 2.4.0 ist das Modul Magento_TwoFactorAuth standardmäßig aktiviert und verlangt 2FA, bevor sich ein Admin-Benutzer über die Oberfläche oder die Web-API anmelden kann. Zu den unterstützten Anbietern gehören Google Authenticator, Duo Security und U2F-Hardware-Keys wie YubiKey. In 2.4.9 müssen Admin-Benutzer nur einen der aktivierten Anbieter einrichten, um sich anzumelden.

Prüfen Sie, dass das Modul nicht deaktiviert wurde – das passiert oft durch Entwickler bei lokalen Tests:

bin/magento module:status Magento_TwoFactorAuth
bin/magento security:tfa:providers
# Force specific providers (comma-separated codes)
bin/magento config:set twofactorauth/general/force_providers google,u2fkey

Wenn jemand sein Gerät verliert, setzen Sie nur dessen Anbieter zurück, statt das Modul zu deaktivieren:

bin/magento security:tfa:reset <admin_username> google

2. Einen vom Standard abweichenden Admin-Pfad verwenden

Adobe rät ab von admin, backend oder anderen gängigen Wörtern. Ein zufälliger Pfad hält keinen gezielten Angreifer auf, entzieht Sie aber dem Großteil automatisierter Login-Versuche.

bin/magento info:adminuri
bin/magento setup:config:set --backend-frontname="ops_7k2m9x"
bin/magento cache:flush

Die Admin-URI akzeptiert nur Buchstaben, Ziffern und Unterstriche.

3. Admin-Zugriff per IP einschränken

Die Security Best Practices von Adobe empfehlen eine IP-Allowlist. Magento hat keinen eingebauten IP-Filter für den Admin – richten Sie ihn daher am Webserver, Load Balancer, CDN oder an der WAF ein. Ein Nginx-Beispiel:

location ~* ^/(index\.php/)?ops_7k2m9x {
    allow 203.0.113.10;     # office
    allow 198.51.100.0/24;  # VPN range
    deny all;
    try_files $uri $uri/ /index.php$is_args$args;
}

Testen Sie das sorgfältig. Der PHP-Handler-Block in Ihrer Nginx-Konfiguration muss die erlaubten Anfragen weiterhin verarbeiten. Wenn Ihr Team remote arbeitet, leiten Sie den Admin-Zugriff über ein VPN, statt eine lange Liste privater IP-Adressen zu pflegen.

4. Admin-Sicherheitseinstellungen verschärfen

Unter Stores > Configuration > Advanced > Admin > Securityprüfen Sie Sitzungsdauer, Sperrung, Passwort-Gültigkeit und Konto-Sharing. Sie können die Werte per CLI setzen, damit sie in der Versionskontrolle liegen – über config.php oder env.php:

bin/magento config:set admin/security/session_lifetime 900
bin/magento config:set admin/security/lockout_failures 5
bin/magento config:set admin/security/lockout_threshold 30
bin/magento config:set admin/security/password_lifetime 90
bin/magento config:set admin/security/password_is_forced 1
bin/magento config:set admin/security/admin_account_sharing 0
bin/magento config:set admin/security/use_form_key 1

PCI DSS v4.0.1 Anforderung 8.3.6 verlangt Passwörter mit mindestens 12 Zeichen (8, falls das System keine 12 unterstützt). Das historische Admin-Minimum von Magento liegt bei 7. Adobe Commerce 2.4.9 macht die minimale Admin-Passwortlänge im selben Sicherheitsbereich konfigurierbar – ein weiterer Grund, dieses Upgrade einzuplanen.

Aktivieren Sie außerdem reCAPTCHA für das Admin-Login und das Formular „Passwort vergessen“ unter Stores > Configuration > Security > Google reCAPTCHA Admin Panel.

5. Minimale Rechte für Rollen und Integrationen

• Geben Sie jeder Person ein eigenes Konto. Keine gemeinsamen „Marketing“- oder „Agentur“-Logins.
• Legen Sie Rollen an unter System > Permissions > User Roles , die nur die Ressourcen abdecken, die das jeweilige Team braucht. Content-Redakteure benötigen keinen Zugriff auf System oder Stores > Configuration.
• Entfernen oder deaktivieren Sie Konten ehemaliger Mitarbeiter und Agenturen am Tag, an dem der Zugriff endet.
• Beschränken Sie API-Integrationen auf die minimal nötigen Ressourcen und rotieren Sie deren Tokens.

Prüfen Sie Admin-Benutzer jedes Quartal. Eine kurze Abfrage hilft, Konten zu finden, die niemand kennt:

SELECT user_id, username, email, is_active, created, logdate
FROM admin_user
ORDER BY created DESC;

Ein unbekanntes, kürzlich angelegtes Konto ist ein starkes Anzeichen für eine Kompromittierung. Behandeln Sie es als Sicherheitsvorfall und starten Sie Ihren Notfallplan.

6. Content Security Policy auf Zahlungsseiten erzwingen

Seit 2.4.7 konfiguriert Adobe CSP für Zahlungsseiten standardmäßig im Restrict-Modus – sowohl im Storefront als auch im Admin – und überall sonst im Report-Only-Modus. Adobe hat diese Änderung zusammen mit der Unterstützung für Subresource Integrity eingeführt, um Händlern bei den Anforderungen von PCI DSS 4.0 zu helfen. Anforderung 6.4.3 verlangt ein Inventar, eine Autorisierung und eine Integritätsprüfung für jedes Skript auf Zahlungsseiten, Anforderung 11.6.1 eine Erkennung von Änderungen und Manipulationen auf Zahlungsseiten. Beide gelten seit dem 31. März 2025.

Der häufigste Fehler: Der Checkout wird wieder auf Report-Only gestellt, weil das Inline-Skript einer Extension nicht mehr funktionierte. Korrigieren Sie stattdessen das Skript, indem Sie es auf die Allowlist setzen – mit SecureHtmlRenderer oder einer Nonce aus CspNonceProvider. Prüfen Sie, dass kein Modul die Standardeinstellung überschrieben hat:

grep -rn "report_only" app/code vendor/*/*/etc/config.xml | grep -v "vendor/magento"

Zur Orientierung: So sieht der Restrict-Modus für den Storefront-Checkout in einem Modul aus, in der Datei config.xml:

<csp>
  <mode>
    <storefront_checkout_index_index>
      <report_only>0</report_only>
    </storefront_checkout_index_index>
  </mode>
</csp>

7. Patches in festem Rhythmus einspielen

Adobe veröffentlicht regelmäßig Sicherheitsreleases (2.4.8 erhielt zum Beispiel zwischen Juni 2025 und Mai 2026 die Patches -p1 bis -p5) und bei Bedarf isolierte Sicherheitspatches außerhalb des Zeitplans. Im September 2026 veröffentlichte Adobe APSB26-146, einen kritischen Fix für eine Schwachstelle, die laut Adobe bereits aktiv ausgenutzt wurde, und riet Händlern, zusätzlich zum Hotfix ihre Zugangsdaten zu rotieren.

Eine praxistaugliche Routine:

• Abonnieren Sie die Adobe Security Bulletins und die Benachrichtigungen des Commerce Security Scan.
• Spielen Sie kritische Fixes innerhalb weniger Tage ein.
• Prüfen Sie mit dem Quality Patches Tool, welche Patches installiert sind:

vendor/bin/magento-patches status
composer audit

Bleiben Sie auf einer unterstützten Release-Linie. Laut Adobes Lifecycle-Policy endete der Standard-Support für 2.4.6 am 11. August 2026.

8. Produktionscode schreibgeschützt machen

Betreiben Sie den Shop im Production-Modus und entziehen Sie den Code-Verzeichnissen die Schreibrechte, damit ein Exploit auf Web-Ebene nicht einfach Dateien ablegen kann. Adobes dokumentierter Befehl für ein Setup mit zwei Benutzern:

bin/magento deploy:mode:show
find app/code lib pub/static app/etc generated/code generated/metadata var/view_preprocessed \
  \( -type d -or -type f \) -exec chmod g-w {} + && chmod o-rwx app/etc/env.php

Stellen Sie Schreibrechte nur während Deployments wieder her und sperren Sie sie danach erneut.

9. Deaktivieren Sie, was Sie nicht nutzen

Jedes aktive Modul und jeder Endpunkt ist Angriffsfläche. Listen Sie auf, was aktiv ist, und deaktivieren Sie ungenutzte Module, nachdem Sie die Abhängigkeiten geprüft haben:

bin/magento module:status --enabled
bin/magento module:disable Vendor_UnusedModule
bin/magento setup:upgrade && bin/magento setup:di:compile

Stellen Sie außerdem sicher, dass der anonyme Zugriff auf REST-Ressourcen deaktiviert bleibt:

bin/magento config:show webapi/webapisecurity/allow_insecure   # expect 0 or empty

Entfernen Sie ungenutzte Drittanbieter-Extensions mit Composer, statt sie nur zu deaktivieren. Deaktivierter Code wird weiterhin mit Ihrem Release ausgeliefert und muss weiterhin gepatcht werden.

10. Überwachen, protokollieren und sichern

• Malware- und Integritätsscans. Adobes kostenloser Commerce Security Scan prüft Websites auf bekannte Risiken und Malware. Serverseitige Scanner wie Sansec eComscan suchen in Dateien und Datenbank nach Malware, verwundbaren Extensions und nicht autorisierten Admin-Konten.
• Admin-Aktivität. Adobe Commerce enthält das Admin Action Log. Unter Magento Open Source leiten Sie Webserver- und var/log -Logs an ein zentrales System weiter und lassen sich bei Admin-Logins von neuen IPs alarmieren.
• Änderungserkennung. Lassen Sie sich bei Änderungen an Checkout-Templates, CMS-Blöcken und core_config_data -Einträgen mit Skripten alarmieren.
• Backups. Bewahren Sie verschlüsselte Datenbank- und Medien-Backups außerhalb des Servers auf, legen Sie app/etc/env.php (sie enthält Ihren Verschlüsselungsschlüssel) in einem separaten sicheren Tresor ab und testen Sie mindestens einmal pro Quartal eine vollständige Wiederherstellung.

Checkliste zum schnellen Nachschlagen

Häufig gestellte Fragen

Kann ich 2FA für Entwickler auf Staging deaktivieren?

Viele Teams tun das auf lokalen Rechnern, aber lassen Sie 2FA in jeder aus dem Internet erreichbaren Umgebung aktiv. Staging enthält oft eine Kopie der Produktionsdaten und dieselben Admin-Benutzernamen – und ist damit ein attraktives Ziel.

Reicht eine individuelle Admin-URL als Schutz?

Nein. Sie reduziert automatisierte Angriffe. Kombinieren Sie sie mit 2FA, einer IP-Allowlist oder einem VPN, Sperreinstellungen und Monitoring.

Macht CSP allein meinen Checkout PCI-konform?

Nein. CSP-Restrict-Modus und SRI helfen bei der Autorisierung und Integrität von Skripten auf Zahlungsseiten, aber PCI DSS umfasst viel mehr, und Ihr Scope hängt davon ab, wie Sie Zahlungen abwickeln. Klären Sie Ihre Pflichten mit Ihrem Acquirer oder QSA.

Wie schnell sollten wir Adobe-Sicherheitspatches einspielen?

Bei kritischen Bulletins, vor allem solchen, die Adobe als aktiv ausgenutzt kennzeichnet, sollten Sie innerhalb weniger Tage handeln. Reguläre Sicherheitsreleases können Ihrem normalen Test- und Deployment-Zyklus folgen, sofern dieser mindestens monatlich läuft.

Quellen

• Adobe Experience League: Secure your Commerce site and infrastructure
• Adobe Experience League: Two-factor authentication
• Adobe Experience League: Display or change the Admin URI
• Adobe Experience League: Configure Admin security
• Adobe Developer: Content Security Policies
• Adobe Commerce 2.4.7 Release Notes
• Adobe Commerce 2.4.9 Release Notes
• Adobe Experience League: Released versions
• Adobe Experience League: Software lifecycle policy
• Adobe: Kritisches Sicherheitsupdate APSB26-146
• Adobe Experience League: File system access permissions
• PCI SSC: Payment page security and preventing e-skimming (6.4.3 and 11.6.1)
• SecurityMetrics: Password requirements in PCI DSS 4.0.1
• Sansec eComscan