Drupal auf Stand halten - Wartung kurz erklärt

Warum muss ein System wie Drupal gewartet werden?

Drupal ist wie jedes Anwenderprogramm oder auch Betriebssystem eine Software, die Funktionen bereitstellt, mittels derer Operationen durchgeführt werden können oder mit welcher interagiert werden kann.

Insbesondere wenn das Set an Funktionen sehr umfangreich ist, steckt viel Programmlogik in einer Software. Damit steigt zum einen das Risiko, dass in dieser Logik Fehler enthalten sind, die unter Umständen auch ein Sicherheitsproblem darstellen. Zum anderen ist es wahrscheinlich, dass sich an der Software regelmäßig Änderungen ergeben, um z.B. neue Funktionen bereitzustellen oder veraltete Komponenten zu entfernen.

Daher erscheinen für jede Software, die aktiv betreut und weiterentwickelt wird, zumindest Sicherheits-Updates, aber oft auch Funktions-Updates, und früher oder später auch neue Versionen. Hier ist Drupal also keine Ausnahme.

Wie ist die Weiterentwicklung bei Drupal grundsätzlich organisiert?

Drupal ist wie eingangs schon beschrieben ein lebendiges System und wird ständig verbessert und weiterentwickelt. Entsprechend ist die Wartung eines Drupal-Systems ein wichtiger Aspekt für seinen erfolgreichen Betrieb. Die Wartungsaufgaben orientieren sich maßgeblich daran, wie Drupal selbst seine Weiterentwicklung organisiert:

1. Drupal Kern

Drupal unterscheidet für den Kern zwischen folgenden drei Release-Arten:

• Major-Release (z.B.: Drupal 9)
  Eine Hauptversion von Drupal. Diese bleibt mehrere Jahre aktuell und wird auch noch mindestens für ein Jahr nach Erscheinen des nächsten Major-Releases von Drupal mit Sicherheits-Updates versorgt. Mit Stand Anfang 2022 ist mit einem Erscheinen von Drupal 10 für Mitte des Jahres zu rechnen. Der Support für Drupal 9 soll planmäßig im November 2023 enden.
• Minor-Release (z.B. Drupal 9.2.0)
  Minor-Releases stellen eine Weiterentwicklung Drupals innerhalb des laufenden Major-Releases dar. In der Regel kommen Minor-Releases mit neuen Funktionen oder bieten Support für neue Techniken, während bestimmte ältere Komponenten zwar noch unterstützt werden, aber als "deprecated" (veraltet) eingestuft werden, und deren Entfernung somit spätestens zum nächsten Major-Release ansteht. Minor-Releases erscheinen ungefähr alle 6 Monate.
• Patch-Releases (z.B. Drupal 9.2.7)
  Patch Releases fixen in der Regel Bugs und erscheinen ungefähr einmal pro Monat

Zusätzlich zu den o.g. geplanten Releases erscheinen je nach Bedarf Security Fixes, um sicherheitskritische Aktualisierungen vorzunehmen. Sicherheitsaktualisierungen werden für das jeweils aktuelle Minor-Release bereitgestellt. Erscheint ein neues Minor-Release, wird das vorherige noch für einen Zeitraum von 6 Monaten ebenfalls mit Sicherheitsaktualisierungen versorgt. Somit haben Webseiten-Betreiber immer maximal ein halbes Jahr Zeit, ihr System auf das jeweils aktuelle Minor-Release zu aktualisieren, bevor der Support endet. In seltenen Fällen und bei hochkritischen Sicherheitslücken wurden mitunter zwar auch noch ältere Minor-Releases mit Patches versorgt. Dies sind jedoch Ausnahmen.

2. Contrib Module

Bei Contrib Modulen ist der Release-Zyklus weniger straff festgelegt als beim Kern. Aber auch hier gilt, dass neue Versionen der Module erscheinen können und der Support älterer Versionen nach einer gewissen Zeit eingestellt wird. Ebenso erhalten auch Module sicherheitskritische Aktualisierungen. Diese werden in der Regel einmal wöchentlich im Rahmen eines Security-Bulletins veröffentlicht.

Umgang mit (Sicherheits-)Updates

Aufgrund der großen und aktiven Community erscheinen für den Drupal-Kern in recht kurzen Abständen Updates, und bei den Modulen ist es auch nicht unüblich, dass bei einem Projekt, welches viele Module nutzt, schon wenige Tage nach einem umfassenden Update bereits wieder Aktualisierungen verfügbar sind. Würde man nun also immer jedes erscheinende Update einzeln und zeitnah einspielen, wäre das insbesondere bei komplexen Projekten schnell ein enormer Wartungsaufwand, der unverhältnismäßig teuer werden würde.

Glücklicherweise muss aber auch nicht jede erscheinende Aktualisierung immer sofort eingespielt werden. Die meisten Updates sind nicht sicherheitskritisch, und auch sicherheitskritische Updates betreffen in manchen Fällen ein Szenario - auch "Angriffsvektor" oder "Angriffsfläche" genannt, welches auf vielen Projekten gar nicht vorkommt und somit keine akute Gefährdung besteht.

Wenn zum Beispiel eine Sicherheitslücke für ein Szenario akut ist, bei der über angemeldete Nutzer mit bestimmten Rechten eine Kompromittierung des Systems denkbar ist, aber auf dem System gar keine Nutzer mit solchen Rechten existieren, existiert auch der Angriffsvektor nicht. Das bedeutet, dass auf diesem System natürlich die potenzielle Sicherheitslücke auch adressiert werden muss - aber es ist eben im konkreten Falle dann keine zeitkritische Angelegenheit.

Generell sind nicht alle Sicherheits-Updates im selben Maße (zeit-)kritisch: vielmehr wird jedes von Drupal.org veröffentlichte Sicherheits-Update mit einer Risikobewertung versehen, die sich an der Bewertungsskala des US-amerikanischen National Institute of Standards and Technology (NIST) orientiert.

Die Risikobewertungen sind:

• 0-4 Punkte - "not critical"
• 5-9 Punkte - "less critical"
• 10-14 Punkte - "moderately critical"
• 15-19 Punkte - "critical"
• 20-25 Punkte - "highly critical"

Bestehen Sicherheitslücken der höchsten Bewertungsstufe "highly critical", wird das Erscheinen eines Patches für diese Lücke einige Tage vorab auf drupal.org angekündigt, damit Webseiten-Betreiber bzw. deren Dienstleister bei dessen Erscheinen in Bereitschaft sein können, um das Update umgehend vorzunehmen.

Wie geht erdfisch bei der Wartung von Drupal-Projekten vor?

Bei der Wartung von Projekten verfolgt erdfisch eine dreistufige Strategie, um

• die Wartungsaufwände zu minimieren und diese für Kunden somit einerseits möglichst kosteneffizient anbieten zu können,
• aber andererseits auch sicherzustellen, dass akut bestehende Sicherheitsrisiken bestmöglich minimiert werden

Wir verlassen uns hierbei einerseits natürlich auf die Risikobewertung von drupal.org.  Zudem vertrauen wir auf die langjährige Erfahrung unseres Entwicklerteams, welches Risiken und Bedrohungsszenarien für die von uns betreuten Projekte anhand der auf drupal.org veröffentlichen Informationen zu den jeweiligen Sicherheitsupdates und anhand des Quellcodes der veröffentlichten Patches schnell und verlässlich bewerten kann.

1. Updates der Kategorie "Highly Critical"

Diese werden immer sofort nach Erscheinen und unter Umgehung eines etwaigen Test- und Abnahme-Workflows direkt auf dem Produktivsystem des Kunden eingespielt, da anzunehmen ist, dass der Schaden durch eine mögliche Kompromittierung des Systems größer ist als ggf. durch den Fix auftretende Seiteneffekte.

2. Updates der Kategorie "Critical"

Diese werden bei Erscheinen durch die Entwickler bei erdfisch gesichtet und geprüft, ob das Bedrohungsszenario für das betroffene Projekt zutrifft. Ist dies der Fall, wird das Update sofort und unter Umgehung eines etwaigen Test- und Abnahme-Workflows direkt auf dem Produktivsystem des Kunden eingespielt, da anzunehmen ist, dass der Schaden durch eine mögliche Kompromittierung des Systems größer ist als ggf. durch den Fix auftretende Seiteneffekte.
Ist das beschriebene Bedrohungsszenario auf dem Projekt nicht gegeben, wird das Update im Rahmen der nächsten planmäßigen Wartung durchgeführt.
erdfisch überprüft zudem regelmäßig die vom Drupal Security Team veröffentlichten „Security News“ und sichtet dort angekündigte Sicherheits-Updates für Contrib-Module, ob diese für die von erdfisch betreuten Projekte kurzfristig relevant sind.

3. Sicherheitsupdates mit geringerer Risikobewertung sowie Patch- oder Funktions-Updates

Diese führt erdfisch kumuliert einmal pro Quartal durch. Insbesondere dann, wenn in den Updates neue Versionen von Modulen erschienen sind oder ein neues Minor Release von Drupal enthalten ist, kann das Auftreten von Seiteneffekten nicht ausgeschlossen werden. Das Update-Paket wird daher zunächst auf der Test- und Abnahmeumgebung des Kunden bereitgestellt, damit dieser dort Funktionstests durchführen kann.

Um sicherzustellen, dass die Updates in einer definierten Zeit in jedem Fall auf das Produktivsystem kommen, setzen wir in unseren Wartungsvereinbarungen bestimmte Fristen, bis zu deren Ablauf die Abnahme entweder zu erfolgen hat, oder nach deren Ablauf ohne Abnahme oder bewusstem Verzicht der Abnahme durch den Kunden die Updates dennoch auf das Produktivsystem ausgespielt werden.

Vorgehen bei außergewöhnlich kritischen Sicherheits-Updates

In sehr seltenen Fällen kann auch die Situation eintreten, dass ein sicherheitsrelevantes Update so kritisch ist, dass es sofort nach Erscheinen eingespielt werden muss, da ansonsten eine unmittelbare Kompromittierung der Webseite droht. Dies war beispielsweise vor einigen Jahren bei der berüchtigten "Drupalgeddon-Sicherheitslücke" der Fall.
Der Veröffentlichungstermin von Updates erfolgt im Regelfall am frühen Abend deutscher Ortszeit, da dies der für die weltweite Koordination der Updates sowohl für Nordamerika als auch Europa der günstigste Zeitpunkt ist. Da solch schwerwiegende Sicherheits-Updates allerdings wie bereits erwähnt mit einigen Tagen Vorlauf angekündigt werden, kann der Dienstleister sich darauf einstellen und abendlichen Bereitschaftsdienst leisten.
Um das Angriffsrisiko so gering wie möglich zu halten, versetzt erdfisch in solchen Ausnahmefällen das gewartete Projekt kurz vor dem erwarteten Erscheinungstermin des Updates in einen speziellen Wartungsmodus, der Zugriffe von außen auf das Drupal-Setup nicht mehr möglich macht. Dann wird das Update eingespielt, und die Webseite erst dann wieder online gebracht.