WordPress-Sicherheitsinventar: Welche Komponenten du kennen solltest

Eine Sicherheitsmeldung wird erst dann handhabbar, wenn feststeht, welche Software auf deiner Website eingesetzt wird. Ein WordPress-Inventar beantwortet diese Frage geordnet: Es verbindet Core, Plugins, Themes und die technische Umgebung mit Versionen und Verantwortlichen. Für kleine Teams reicht zunächst eine überschaubare Liste, die tatsächlich gepflegt wird.

Vier Ebenen getrennt erfassen

Beginne mit WordPress selbst. Notiere den im Verwaltungsbereich angezeigten Stand und das Datum deiner Prüfung. Ergänze danach die regulären Plugins. Halte nicht nur den sichtbaren Namen fest, sondern auch den Verzeichnisnamen, den Anbieter und die installierte Version. Ein ähnlicher Produktname ist noch kein Beleg dafür, dass eine Sicherheitsmeldung dieselbe Erweiterung meint.

Für die Gestaltung gehören aktives Theme und gegebenenfalls übergeordnetes Theme in die Liste. Ein individuelles Theme kann zusätzlich Funktionen enthalten, die jemand warten muss. Ergänze schließlich die Hosting-Ebene: Wer betreut PHP, Webserver, Datenbank und Zertifikate? Hier brauchst du als Betreiber nicht jedes Systempaket selbst auszulesen. Du solltest aber wissen, wen eine entsprechende Warnung erreicht und welche Informationen dieser Kontakt benötigt.

Die WordPress-Dokumentation behandelt Härtung ausdrücklich als mehrere zusammenwirkende Maßnahmen. Darunter fallen vertrauenswürdige Softwarequellen, begrenzte Zugriffe, Updates, Sicherungen und Beobachtung. Ein Inventar ersetzt diese Maßnahmen nicht; es schafft eine gemeinsame Grundlage für ihre Zuordnung. Quelle: WordPress-Härtung.

Beobachtung und bestätigten Bestand unterscheiden

Eine externe Prüfung sieht die Website aus Besuchersicht. Sie kann Hinweise in HTML, Ressourcenpfaden und Metadaten finden. Diese Beobachtung ist hilfreich, aber sie hat einen anderen Umfang als eine Liste aus der eigenen Verwaltung. Markiere deshalb, wie ein Eintrag zustande kam: öffentlich beobachtet, intern nachgesehen oder vom zuständigen Dienstleister bestätigt.

Stelle dir einen kleinen Verein mit einem Kontaktformular vor. Öffentlich erscheint eine JavaScript-Datei des Formularplugins. Daraus lässt sich ein Produkt ableiten. Ob zusätzlich ein serverseitiger Export läuft oder ein altes Plugin noch im Dateisystem liegt, beantwortet diese Datei nicht. Eine fehlende Beobachtung darf deshalb nicht als bestätigte Abwesenheit in die Bestandsliste übernommen werden.

Das Datum ist genauso wichtig wie die Version. Ein vor drei Monaten geprüfter Eintrag kann inzwischen überholt sein. Gib jedem Datensatz einen Prüfzeitpunkt und einen sinnvollen Anlass für die nächste Kontrolle: beispielsweise nach einem Update, einem Agenturwechsel oder einer neuen Erweiterung. Dadurch fällt auf, welche Bestandsaussagen noch belastbar sind.

Eine brauchbare Inventarzeile

Eine gute Zeile bleibt auch für jemanden verständlich, der die Website nicht eingerichtet hat. Schreibe beispielsweise: Kontaktformular, Produkt und Verzeichnisname, intern bestätigte Version, zuständige Agentur, letzter Prüfzeitpunkt, vorhandene Updateberechtigung. Ergänze bei kostenpflichtigen Erweiterungen, wer den Lizenzzugang verwaltet. Ein Sicherheitsupdate hilft wenig, wenn niemand das passende Paket beziehen kann.

Bewahre keine Passwörter, Lizenzschlüssel oder privaten Downloadlinks in dieser Liste auf. Verweise stattdessen auf den vorgesehenen Passwortmanager oder die zuständige Person. Auch Supportzugänge sollten nicht beiläufig in einem frei geteilten Dokument landen. Der Bestand muss für die Wartung zugänglich sein, ohne selbst eine Sammlung von Zugangsdaten zu werden.

Für eigene Erweiterungen lohnt ein zusätzlicher Vermerk: Quellrepository, verantwortlicher Kontakt und letzter bereitgestellter Stand. Eine interne Versionsnummer ist nur dann nützlich, wenn sich ihr eine konkrete Auslieferung zuordnen lässt. Fehlt diese Zuordnung, dokumentiere die Lücke offen und plane ihre Klärung ein.

Aus der Liste einen Wartungsablauf machen

Lege fest, wann Änderungen in den Bestand eingetragen werden. Praktikabel ist ein kurzer Schritt im bestehenden Änderungsprozess: Wer ein Plugin installiert, ersetzt oder entfernt, aktualisiert die zugehörige Zeile. Wer ein Update ausrollt, hält den danach tatsächlich kontrollierten Stand fest. So entsteht keine zweite, schnell veraltende Parallelwelt.

Verbinde Sicherheitsmeldungen mit den passenden Inventarzeilen. Erst dann prüfst du den betroffenen Versionsbereich und die konkrete Nutzung. Eine Meldung für ein nicht eingesetztes Produkt braucht eine andere Behandlung als ein passender Treffer. Ein unbekannter Stand bleibt eine offene Aufgabe; er wird weder vorsorglich grün noch automatisch als erfolgreicher Angriff dargestellt.

Für kleine Teams empfiehlt sich eine benannte Hauptverantwortung mit Vertretung. Die Person muss nicht jede technische Änderung selbst durchführen. Sie sorgt dafür, dass Fragen bei der zuständigen Stelle ankommen und Entscheidungen dokumentiert werden. Dies verhindert, dass mehrere Beteiligte dieselbe Warnung lesen und jeweils auf die anderen warten.

Umfang bewusst klein halten

Beginne mit den Komponenten, die den Betrieb deiner Website tragen. Du musst nicht am ersten Tag eine perfekte Lieferkette abbilden. Besser ist ein verlässlicher Grundbestand mit klar benannten Lücken. Ergänze tieferliegende Abhängigkeiten dort, wo der Wartungsdienstleister oder eine konkrete Meldung sie relevant macht.

Erstelle für mehrere Websites getrennte Zuordnungen. Zwei Installationen können dasselbe Produkt in unterschiedlichen Versionen nutzen. Eine gemeinsame Produktliste ohne Websitebezug lässt nicht erkennen, wo ein Update noch fehlt. Ein zentraler Produktkatalog mit einzelnen Installationszeilen kann dagegen Übersicht schaffen, solange der tatsächliche Stand je Website sichtbar bleibt.

Prüfe außerdem, welche Teile du wirklich weiter benötigst. Ein vergessenes Zusatzmodul ist nicht nur ein Listenproblem. Es verursacht Prüf- und Wartungsaufwand. Entferne Software allerdings erst nach fachlicher Klärung und Sicherung, damit wichtige Daten oder versteckte Abläufe erhalten bleiben. Plane diesen Übergang mit Blick auf Daten, Abhängigkeiten und eine kontrollierte Nachprüfung.

Wenn eine Website den Besitzer wechselt

Bei einer Übergabe sollte der Bestand mit übergeben werden. Bitte die bisherige Agentur nicht nur um eine Sammlung von ZIP-Dateien, sondern um eine verständliche Zuordnung von Funktion, Produkt und Wartungsweg. Prüfe, welche Updates an ein fremdes Kundenkonto gebunden sind und welche Eigenentwicklungen ohne Betreuung zurückbleiben würden.

Übernimm dabei keine unbelegten Aussagen ungeprüft. Ein Eintrag „wird automatisch aktualisiert“ ist ein Anlass, den tatsächlichen Ablauf und seine Fehlerbenachrichtigungen zeigen zu lassen. Dokumentiere, wer künftig eingreifen kann, wenn ein automatischer Vorgang ausbleibt. So wird aus einer einmaligen Übergabeliste ein nutzbares Betriebsdokument für die nächste verantwortliche Person.

Ein konkreter Start für diese Woche

Reserviere einen kurzen Termin mit der Person, die administrativen Zugang und Wartungswissen besitzt. Geht Core, Erweiterungen, Themes und Hosting gemeinsam durch. Kennzeichnet Unbekanntes ausdrücklich. Wählt danach die drei wichtigsten offenen Fragen und gebt jeder einen Verantwortlichen und einen Termin. Ein solches Ergebnis ist im Alltag wertvoller als eine umfangreiche Tabelle ohne nächste Schritte.

Bewahre einen nachvollziehbaren Änderungsverlauf auf. Wenn ein Scan später einen abweichenden Stand zeigt, könnt ihr prüfen, ob ein Update fehlt, ein Cache alte Dateien ausliefert oder die Erkennung ungenau war. Für diese Unterscheidung helfen die Hinweise zu Cache und CDN und zur eindeutigen Produktzuordnung.

Ein gepflegtes Inventar verspricht keine vollständige Sicherheit. Es sorgt dafür, dass eine neue Meldung nicht bei der Grundfrage hängen bleibt, welche Software überhaupt betroffen sein könnte. Genau diese Zuordnung macht aus einer allgemeinen Warnung einen prüfbaren Arbeitsauftrag.