WordPress-Staging-Sites müssen ebenfalls gesichert werden
WordPress-Staging-Sites sind keine Wegwerfkopien. Eine Staging-Site ist eine private Testkopie Ihrer Live-(Produktions-)WordPress-Website. Sie ermöglicht es Ihnen, Core-Updates, Plugin- und Theme-Updates, Designänderungen, neue Plugins, PHP-Upgrades, Formulare und Checkout sowie Fehlerbehebungen zu testen, bevor sie Besucher beeinträchtigen. Aber wenn Sie eine Live-Site auf Staging klonen, kopieren Sie auch WordPress-Benutzerkonten, Kundendatensätze, Formularübermittlungen, Datenbank-Zugangsdaten, API-Schlüssel, Plugin- und Theme-Schwachstellen und private Inhalte. Da Staging-Sites oft als vorübergehend behandelt werden, erhalten sie weniger Aufmerksamkeit und werden zu einem unnötigen Sicherheitsrisiko.
Der einfachste Weg für einen Anfänger, eine Staging-Site zu erstellen, ist die Verwendung des integrierten Staging-Tools eines Hosting-Anbieters. Der typische Arbeitsablauf ist: Melden Sie sich beim Hosting-Dashboard an, wählen Sie die Live-Site, suchen Sie die Option Staging, Klonen oder Site kopieren, erstellen Sie eine Kopie der Dateien und der Datenbank, beschränken Sie den Zugriff auf die Staging-Umgebung und bestätigen Sie, dass die kopierte Site funktioniert. Erstellen Sie immer ein aktuelles WordPress-Backup, bevor Sie Änderungen klonen oder bereitstellen. Wenn Sie Staging manuell erstellen, benötigen Sie eine separate Subdomain, separate WordPress-Dateien, eine separate Datenbank, aktualisierte Datenbank-Zugangsdaten, aktualisierte Site-URLs und Zugriffsbeschränkungen. Manuelle Einrichtungen bieten mehr Kontrolle, schaffen aber mehr Möglichkeiten, die falsche Datenbank zu verbinden oder Konfigurationsdetails offenzulegen. Wenn Sie sich mit Datenbanken und wp-config.php nicht auskennen, verwenden Sie ein Hosting-Tool oder arbeiten Sie mit einem erfahrenen Administrator zusammen.
Sobald Staging existiert, behandeln Sie es als echte Website mit einem begrenzten Zweck. Beschränken Sie den Zugriff, damit es nicht offen erreichbar ist. Übliche Kontrollen umfassen HTTP-Passwortschutz, IP-Allowlisting (nur bestimmte Internetadressen zulassen), private Netzwerke oder VPNs und Zugriffskontrollen auf Hosting-Ebene. Verlassen Sie sich nicht allein auf die WordPress-Anmeldeseite, da öffentliche Seiten, Dateien, APIs und Plugin-Endpunkte weiterhin zugänglich sein können. Gehen Sie außerdem in WordPress zu Einstellungen > Lesen und aktivieren Sie "Suchmaschinen davon abhalten, diese Site zu indizieren". Dies verringert die Wahrscheinlichkeit, dass unfertige Staging-Inhalte in Suchergebnissen erscheinen, ist aber keine Sicherheitskontrolle und hält Menschen oder bösartige Bots nicht auf.
Markieren Sie die Kopie als Staging, indem Sie die Zeile `define( 'WP_ENVIRONMENT_TYPE', 'staging' );` zu wp-config.php hinzufügen, oberhalb des Kommentars `/* Das ist alles, Schluss mit dem Bearbeiten! Viel Spaß beim Veröffentlichen. */`. Dies hilft WordPress und kompatibler Software, die Umgebung zu erkennen, schützt die Site aber nicht von selbst. Wichtiger ist, Produktions-Zugangsdaten nicht wiederzuverwenden. Verwenden Sie separate WordPress-Administratorpasswörter, Datenbank-Zugangsdaten, SFTP- oder SSH-Konten, API-Schlüssel, Zahlungszugangsdaten, E-Mail-Zugangsdaten und Webhooks. Überprüfen Sie nach dem Klonen wp-config.php, Plugin-Einstellungen und Umgebungsvariablen auf Produktionsgeheimnisse, die die Staging-Site nicht benötigt. Entfernen Sie unnötige Kundendaten wie Namen, E-Mail-Adressen, Telefonnummern, Adressen, Bestellungen, Formularübermittlungen, Mitgliedschaftsdatensätze und Authentifizierungstokens. Für eine E-Commerce-Site reichen ein paar Testbestellungen; für eine Mitgliedschafts-Site erstellen Sie Testkonten, anstatt echte Kundendatensätze zu kopieren.
Eine geklonte Site kann weiterhin mit Produktionsdiensten kommunizieren. Prüfen Sie, ob Staging Kunden-E-Mails senden, Zahlungen verarbeiten, Inventar aktualisieren, Marketing-Workflows auslösen, SMS-Nachrichten senden oder Produktions-Webhooks zustellen kann. Verwenden Sie Test- oder Sandbox-Zahlungszugangsdaten, leiten Sie ausgehende E-Mails um oder blockieren Sie sie und ersetzen Sie Produktions-API-Schlüssel und Webhook-Ziele. Tun Sie dies frühzeitig, da geplante Aufgaben möglicherweise sofort nach Erstellung der Staging-Kopie ausgeführt werden. Verschlüsseln Sie den Staging-Verkehr mit HTTPS und einem gültigen TLS-Zertifikat; es schützt Zugangsdaten und Testdaten während der Übertragung, ersetzt aber keine Authentifizierung, Updates oder Überwachung. Halten Sie WordPress-Core, Plugins, Themes, PHP und Serversoftware auf dem neuesten Stand und entfernen Sie Plugins und Themes, die nicht mehr benötigt werden, da inaktive Software weiterhin Dateien enthalten kann, die über das Web zugänglich sind.
Geben Sie jeder Person nur den Zugriff, der für ihre Aufgabe erforderlich ist. Ein Inhaltsprüfer benötigt möglicherweise nur Editor-Berechtigungen; ein Auftragnehmer, der ein Formular testet, benötigt möglicherweise keinen Hosting-Zugriff. Überprüfen Sie auch geklonte Benutzerkonten, da alte Agentur-, Auftragnehmer- oder Mitarbeiterkonten möglicherweise noch in der kopierten Datenbank vorhanden sind. Sucuris Leitfaden zu WordPress-Benutzerrollen und geringsten Rechten erklärt, wie unnötige Kontoberechtigungen reduziert werden können. Fügen Sie Staging zu Ihrem Website-Inventar hinzu und achten Sie auf unerwartete Dateiänderungen, neue Administratorkonten, fehlgeschlagene Anmeldungen, Malware-Indikatoren und unerwarteten öffentlichen Zugriff. Sucuri bietet Website-Überwachung und Malware-Scans, und sein SiteCheck-Scanner kann öffentlich zugängliche Seiten auf bekannte Malware-Indikatoren und bestimmte Sicherheitsprobleme untersuchen. Internetzugängliche Staging-Umgebungen können auch von einer Website-Firewall profitieren, um bösartigen Datenverkehr zu filtern, bevor er WordPress erreicht.
Ein sicherer Staging-Workflow hat drei Phasen. Vor dem Testen: Erstellen und verifizieren Sie ein Produktions-Backup, beschränken Sie den Zugriff auf Staging, verhindern Sie die Suchmaschinen-Indizierung, entfernen Sie unnötige Kundendaten, ersetzen Sie Produktions-Zugangsdaten und -Integrationen und deaktivieren Sie echte Zahlungen und E-Mails. Während des Testens: Ändern Sie jeweils eine Hauptkomponente, testen Sie Anmeldung, Formulare, Suche, Navigation und Checkout, überprüfen Sie Desktop- und Mobil-Layouts, prüfen Sie Fehler und Protokolle und bestätigen Sie, dass keine echten Kundenkommunikationen gesendet wurden. Vor der Bereitstellung: Erstellen Sie ein weiteres Produktions-Backup, identifizieren Sie genau, was kopiert wird, überprüfen Sie Unterschiede zwischen Staging und Produktion, dokumentieren Sie einen Rollback-Prozess, wenden Sie die genehmigten Änderungen an und testen Sie kritische Funktionen in Produktion.
Eines der größten Staging-Risiken ist das Überschreiben neuerer Produktionsdaten beim Pushen von Staging auf Produktion. Stellen Sie sich eine E-Commerce-Website vor, die am Montag auf Staging kopiert wurde. Kunden geben während der Woche weiterhin Bestellungen auf der Live-Site auf. Am Freitag pusht jemand die gesamte Montags-Staging-Datenbank zurück auf Produktion, und diese neueren Bestellungen gehen verloren. Das gleiche Problem kann Kundenkonten, Formularübermittlungen, Kommentare, Reservierungen, Inventar und Mitgliedschaftsaktivitäten betreffen. Bevor Sie ein Push-to-Production-Tool verwenden, verstehen Sie, ob es Dateien, Datenbanktabellen oder die gesamte Website ersetzen wird. Bei kleinen Designänderungen ist es möglicherweise sicherer, nur die erforderlichen Dateien zu verschieben oder die Einstellung in Produktion neu zu erstellen.
Löschen Sie eine Staging-Site, wenn sie keinen klaren Zweck mehr hat. Vor dem Löschen: Bestätigen Sie, dass genehmigte Änderungen die Produktion erreicht haben, speichern Sie erforderlichen Code oder Dokumentation, löschen Sie Staging-Dateien und -Datenbanken, entfernen Sie den DNS-Eintrag, widerrufen Sie Staging-Zugangsdaten und API-Schlüssel, entfernen Sie temporäre Benutzer und bestätigen Sie, dass die Staging-URL keine Inhalte mehr offenlegt. Wenn Staging dauerhaft ist, beziehen Sie es in Ihre normalen Patch-, Zugriffsüberprüfungs-, Überwachungs-, Backup- und Incident-Response-Prozesse ein. Eine Staging-Site kann absolut gehackt werden: Eine öffentlich erreichbare Staging-Site ist immer noch eine Website, und anfällige Software, schwache Zugangsdaten oder offengelegte Dateien können missbraucht werden, unabhängig davon, ob sie als Staging oder Produktion gekennzeichnet ist. Staging sollte normalerweise nicht in Google erscheinen, da es unfertige Seiten oder doppelte Inhalte offenlegen kann. Sichern Sie alles auf Staging, was schwer wiederherzustellen wäre, aber sichern Sie immer die Produktion, bevor Sie klonen, bereitstellen oder deren Datenbank ändern.
Eine WordPress-Staging-Site ermöglicht es Ihnen, Updates und Änderungen zu testen, ohne an der Live-Website zu experimentieren. Eine sichere Staging-Umgebung sollte von der Produktion getrennt, vor öffentlichem Zugriff geschützt, von unnötigen sensiblen Daten befreit, von Live-Diensten getrennt, überwacht und entfernt werden, wenn sie nicht mehr benötigt wird. Kombinieren Sie einen kontrollierten Staging-Workflow mit Website-Backups, Sicherheitsüberwachung und einer Website-Firewall für stärkeren Schutz. Für Leser, die die Staging-Sicherheit lieber nicht manuell verwalten möchten, bieten verwaltete WordPress-Hosts wie AEU Hosting Staging-Umgebungen, automatische Backups, SSL-Zertifikate und Sicherheits-Härtung als Teil der Plattform, was mehrere der oben beschriebenen manuellen Schritte überflüssig macht.