Drupal absichern — das System hilft, wenn man es lässt.

Das Sicherheitsmodell.

Drupal hat ein eigenes Sicherheitsteam, das Meldungen entgegennimmt, mit den Betreuern koordiniert und zu festgelegten Zeitpunkten veröffentlicht. Meldungen sind dabei nach Schwere eingestuft, mit nachvollziehbarer Begründung.

Das hat zwei Folgen. Erstens: Du bekommst verlässliche, strukturierte Informationen und kannst planen. Zweitens: Diese Informationen sind öffentlich — und damit auch für Angreifer eine Landkarte. Die Reaktionszeit nach einer Veröffentlichung entscheidet.

Für den Betrieb heißt das: Was innerhalb weniger Tage eingespielt wird, ist kein Problem. Was Wochen offen bleibt, wird eines (Versionsfristen).

Die Abdeckungsregel.

Ein Punkt, der zu wenig bekannt ist und bei der Modulauswahl entscheidend sein sollte: Nicht jedes beigesteuerte Modul wird vom Sicherheitsteam betreut.

Die Abdeckung setzt voraus, dass es eine stabile Fassung gibt und bestimmte Qualitätsanforderungen erfüllt sind. Module ohne Abdeckung sind nicht automatisch schlecht — aber bei ihnen gibt es keine koordinierten Meldungen, und eine Lücke wird nicht zentral kommuniziert.

Praktisch: Prüf bei jedem beigesteuerten Modul, ob es abgedeckt ist. Das steht auf der Projektseite. Für öffentliche Stellen und alles, was personenbezogene Daten verarbeitet, würde ich nicht abgedeckte Module nur mit sehr guter Begründung einsetzen (Module bewerten).

Dasselbe gilt für Entwicklungsfassungen: Sie sind grundsätzlich nicht abgedeckt und gehören nicht in den Produktivbetrieb.

Meldungen lesen.

Zeile drei und vier zusammen bestimmen die Dringlichkeit. Eine Lücke, die nur ein angemeldeter Redakteur ausnutzen kann, ist in einem geschlossenen Redaktionsteam weniger dringend als eine, die jeder von außen ausnutzen kann — das ändert nichts daran, dass sie geschlossen gehört, aber es hilft bei der Priorisierung.

Die Meldungen lassen sich abonnieren. Das ist der günstigste Teil der Betreuung: Es kostet nichts außer Aufmerksamkeit.

Updates.

1. Sicherheitsupdates sofort — Kern und Module.
2. Nebenversionen zeitnah.
3. Über die Abhängigkeitsverwaltung, nicht per Dateiaustausch.
4. Datenbankaktualisierung nicht vergessen.
5. Zwischenspeicher leeren (Cache).
6. Sicherung vorher, immer.

Drupal meldet verfügbare Updates im Statusbericht und auf Wunsch per Mail. Diese Benachrichtigung einzuschalten ist eine Minute Arbeit und der wirksamste Einzelschritt überhaupt.

Ein Hinweis zu Punkt drei: Updates per Dateiaustausch führen bei Drupal zuverlässig zu widersprüchlichen Zuständen, weil die Abhängigkeitsverwaltung davon nichts weiß.

Rechte und Rollen.

Drupals Rechtesystem ist fein genug, um echte Trennung abzubilden — und genau deshalb wird es oft zu grob genutzt. Jede Berechtigung ist einzeln vergebbar, und es gibt viele.

Was dabei zu beachten ist:

• Der erste Benutzer hat alle Rechte unabhängig von Rollen. Dieses Konto gehört nicht für die tägliche Arbeit verwendet.
• Administrationsrechte für einzelne Bereiche sind getrennt vergebbar — nutz das statt einer Allzweckrolle.
• Bestimmte Berechtigungen sind als sicherheitskritisch gekennzeichnet, etwa das Verwalten von Rollen, das Ausführen von Code oder das Verwalten von Textformaten. Die gehören nur an wenige.
• Textformate steuern, welches HTML ein Benutzer schreiben darf. Ein zu großzügiges Format für Redakteure ist ein unterschätztes Risiko.
• Anonyme Benutzer haben auch Rechte — prüf, welche.

Punkt vier verdient eine Betonung: Wer Redakteuren ein Format mit unbeschränktem HTML gibt, erlaubt ihnen damit faktisch das Einfügen von Skripten. Das ist in vielen Installationen so eingerichtet, ohne dass jemand die Tragweite kennt.

Dateiuploads.

Ein klassischer Angriffsweg bei jedem System. Bei Drupal zu prüfen:

• Erlaubte Dateiendungen je Feld — eng halten.
• Private Dateien für alles, was nicht öffentlich sein soll; sie werden über Drupal ausgeliefert und unterliegen den Zugriffsrechten.
• Ausführung im Upload-Verzeichnis serverseitig unterbinden.
• Das private Verzeichnis außerhalb des öffentlichen Bereichs anlegen.

Punkt drei und vier zusammen schließen den Weg praktisch vollständig. Drupal liefert dafür Vorgaben mit, aber sie müssen auf dem Server auch wirksam sein — bei manchen Konfigurationen sind sie es nicht. Prüf das, indem du versuchst, eine harmlose Testdatei im Upload-Verzeichnis über ihre Adresse auszuführen.

Härtung.

1. Verwaltungsbereich beschränken auf bekannte Adressen oder mit zusätzlichem Zugangsschutz.
2. Zwei-Faktor-Anmeldung für Konten mit weitreichenden Rechten.
3. Anmeldeversuche begrenzen — Drupal bringt das mit, prüf die Einstellung.
4. Starke, einzelne Passwörter.
5. Dateirechte eng setzen, besonders für die Einstellungsdatei.
6. Entwicklungs- und Diagnosemodule im Produktivbetrieb entfernen.
7. Fehleranzeige aus im Produktivbetrieb.
8. Verzeichnisauflistung auf Serverebene abschalten.

Punkt fünf ist bei Drupal besonders wichtig: Die Einstellungsdatei enthält die Datenbankzugangsdaten und einen Schlüssel, aus dem Sitzungen abgeleitet werden. Sie gehört schreibgeschützt und darf vom Server nicht ausgeliefert werden (Dateirechte).

Punkt sechs wird regelmäßig vergessen: Diagnosemodule geben im Produktivbetrieb Informationen über Konfiguration, Abfragen und Dateipfade preis.

PHP und Server.

Eine veraltete PHP-Fassung ist eine Sicherheitslücke, unabhängig von Drupal. Die Anforderungen steigen mit jeder Hauptversion — das ist kein Schikane, sondern folgt den Fristen der Sprache selbst.

Dazu die üblichen Serverthemen: verschlüsselte Verbindungen überall, aktuelle Software, getrennte Datenbankbenutzer je Projekt, keine weit offenen Verzeichnisrechte (SSL, Hosting).

Bei geteiltem Webspace kommt ein Punkt dazu, über den selten gesprochen wird: Wenn die Trennung zwischen Kunden schlecht ist, kann ein befallener Nachbar zum Problem werden. Bei Installationen mit sensiblen Daten ist das ein Argument für eine andere Hosting-Art.

Anzeichen für einen Einbruch.

• Unbekannte Benutzerkonten, besonders mit weitreichenden Rechten.
• Veränderte Dateien mit unerwartetem Änderungsdatum.
• Fremde Inhalte oder Weiterleitungen.
• Warnung in Suchergebnissen.
• Hoster meldet Spamversand oder sperrt.
• Ungewöhnliche Einträge im Drupal-Protokoll.
• Neue Berechtigungen bei anonymen Benutzern.

Der letzte Punkt ist ein feines Signal, das nur bei Drupal so sichtbar ist: Wenn anonyme Benutzer plötzlich Rechte haben, die niemand vergeben hat, ist das eindeutig. Ein Blick auf die Rechteübersicht dauert zehn Sekunden.

Nach einem Einbruch.

1. Nicht sofort löschen — erst Protokolle und Dateistand sichern.
2. Alle Zugänge sperren und Passwörter ändern, auch Datenbank und Hosting.
3. Einfallstor finden über Protokolle und Dateiänderungsdaten.
4. Klären, ob personenbezogene Daten betroffen sind — 72-Stunden-Frist.
5. Sauber neu aufbauen: Kern und Module frisch aus den Originalquellen.
6. Datenbank prüfen auf fremde Benutzer, Rechte und eingeschleusten Inhalt.
7. Einfallstor schließen, bevor es online geht.

Punkt fünf ist bei Drupal einfacher als bei vielen anderen Systemen, wenn die Konfiguration exportiert in der Versionsverwaltung liegt: Dann lässt sich der Zustand reproduzieren, statt ihn zu rekonstruieren. Das ist ein handfester Grund, diese Arbeitsweise zu nutzen.

Zur Frist: Sie läuft ab dem Bekanntwerden, nicht ab dem Ende der Bereinigung. Die Bewertung macht dein Datenschutzbeauftragter oder Anwalt (DSGVO).

Prüfliste.

1. Statusbericht — ausstehende Sicherheitsupdates?
2. Update-Benachrichtigung eingeschaltet?
3. Module: alle vom Sicherheitsteam abgedeckt?
4. Benutzerliste — nur bekannte Konten?
5. Rechte: Wer hat sicherheitskritische Berechtigungen?
6. Textformate: Wer darf unbeschränktes HTML?
7. Anonyme Rechte geprüft?
8. Upload-Verzeichnis: Ausführung unterbunden?
9. Einstellungsdatei nicht abrufbar und schreibgeschützt?
10. Entwicklungsmodule entfernt?

Die Punkte fünf bis sieben dauern zusammen zehn Minuten und finden in gewachsenen Installationen regelmäßig etwas — meist Rechte, die vor Jahren für einen Zweck vergeben und nie zurückgenommen wurden (Wartung).

Wenn du nicht weiterkommst.

Wenn du wissen willst, wie es um deine Installation steht, oder nach einem Vorfall Hilfe brauchst. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Bei einem laufenden Ausfall hilft der Notfall-Support, dauerhaft begleitet die Drupal-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management-Systeme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme nicht nur aus der Anwendung, sondern von innen: Datenmodell, Rechtekonzept, Templating, Modularchitektur, Caching, Betrieb.

Bei Drupal zahlt sich das besonders aus, weil das System konsequenter durchkonstruiert ist als die meisten anderen: Alles ist Entität, alles hat Felder, alles läuft über definierte Schnittstellen. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo eine Installation gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob deine Installation weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.