Drupal-Wartung und -Support

Es gibt mehrere Risiken, denen sich ein Website-Betreiber aussetzt, wenn er nicht dafür Sorge trägt, dass seine Projekte regelmäßige Wartung erfahren.

Am naheliegendsten ist dabei der Sicherheitsaspekt. Keine Software ist völlig fehlerfrei, und es besteht somit immer die Möglichkeit, dass solche Fehler sicherheitskritische Lücken eröffnen, die von Angreifern ausgenutzt werden können.

Besonders problematisch kann eine nicht geschlossene Sicherheitslücke dann werden, wenn Dritte auf diesem Weg die Kontrolle über die Website erlangen und vertrauliche Informationen oder personenbezogene Daten abgreifen können. Dann liegt neben dem wirtschaftlichen Schaden und dem Reputationsverlust, ein Datenschutzverstoß vor, der je nach Schwere empfindliche Strafen nach sich ziehen kann.

Aber auch in anderer Hinsicht kann Ihre Webseite und deren Serverumgebung für Angreifer interessant sein, etwa um:

• über Ihre Server-IP-Adresse Spam zu versenden
• Malware auf Ihrem Server zu hinterlegen
• Verlinkungen zu Drittseiten platzieren, die dann vom Suchindex-Ranking Ihres Projekts zu profitieren
• einen Krypto-Miner zu installieren, der die Rechenleistung Ihres Servers ausnutzt

um nur einige mögliche Schadszenarien zu nennen

In seltenen Fällen kann es sogar passieren, dass der Betreiber einer kompromittierten Seite vor der radikal anmutenden Entscheidung steht, das komplette Projekt vom Netz nehmen zu müssen. Ein solches Worst-Case-Szenario kann eintreten, wenn keine Backups vom Zeitpunkt vor der Kompromittierung vorhanden sind, aus denen eine Wiederherstellung des Projekts im Zustand vor der Kompromittierung möglich wäre, und gleichzeitig die online befindliche Version vom Hacker oder einem automatisiert nach Webseiten mit Schwachstellen suchenden Bot mit geheimen Hintertüren ("Backdoors") versehen wurde. Diese würde eine fortgesetzte Kompromittierung selbst dann noch erlauben, wenn der entsprechende Sicherheits-Patch eben verspätet eingespielt wurde.

Um sich diesen Risiken nicht auszusetzen, ist es daher unbedingt geboten, stets im Blick zu behalten, welche sicherheitskritischen Aktualisierungen für das eigene Projekt zur Verfügung stehen und welche Aktualisierungen davon für das eigene Anwendungsszenario relevant und somit obligatorisch sind.

Ein weiteres Problem, welches insbesondere bei lange nicht gewarteten Projekten eintritt, ist der Umstand, dass die eingesetzte Version Drupals aus dem aktiven Support herausfällt und somit keine Weiterentwicklung mehr erfährt oder Sicherheits-Updates erhält.

Dies hängt mit den sogenannten Release-Zyklen zusammen, gemäß denen Drupal seit der Version 8 erscheint. Innerhalb einer Hauptversion (Major Release wie z. B. Drupal 9) erscheinen ungefähr alle 6 Monate sogenannte Zwischenversionen oder Minor-Releases (z.B. Drupal 9.5), die dann jeweils für die Dauer von rund einem Jahr aktiv supported werden.

Somit haben Webseiten-Betreiber immer etwa 6 Monate Zeit, um auf das neue Minor-Release zu wechseln und weiter Support zu erhalten. Wird dies versäumt, rutscht die eingesetzte Version aus dem Support. Wie auch bei Betriebssystemen für Computer erscheinen für unsupportete Drupal-Versionen keine Sicherheits-Updates mehr.

Eine weitere Schwierigkeit ist dann, dass es in jedem Zwischen-Release von Drupal neue Funktionen oder Funktions-Anpassungen gibt. Setzt man mehrere Zwischen-Versionen lang aus, wird das anschließende Upgrade umso zeitaufwendiger, da man dann alle verpassten Zwischenversionen auf einmal nachholen muss.

Somit gibt es also wie bei jeder Software mehr als genug Argumente dafür, die Wartung auch bei einem Drupal-Projekt nicht zu vernachlässigen, sondern sich regelmäßig darum zu kümmern oder diese Aufgabe einem kompetenten Partner anzuvertrauen.

Es gibt zwar bereits eine strategische Initiative, die sich damit befasst, für bestimmte Updates in Drupal eine Automatisierungs-Routine zu schaffen.

Jedoch zielt diese nicht auf „Enterprise-Kunden“ ab:

"Automatic updates are generally not intended for use by large enterprise organizations that already have their own build workflows and pipelines. Instead, the intent is to support small-to-medium site owners who have a 'set-it-and-forget-it' attitude towards their Drupal installations."

Außerdem beschränkt sich die Initiative rein auf den Drupal-Kern und zielt nicht auf Zusatzmodule, und bei den Core-Updates auch nur auf Sicherheits-Aktualisierungen, und nicht etwa neue Zwischen- oder Hauptversionen.

Mit anderen Worten: komplexere Drupal-Installationen, die zum einen eine bedeutende Menge an Zusatzmodulen verwenden und zum anderen unter Verwendung professionalisierter Implementierungs- und Bereitstellungsprozesse stetig aktiv weiterentwickelt werden, sind derzeit keine Zielgruppe für diese Initiative.

Sie benötigen somit auch für die absehbare Zukunft eine passende Wartungsstrategie, wie sie beispielsweise erdfisch anbieten kann.

Auf den ersten Blick erscheint es eine interessante und vor allem kostengünstige Variante: wieso nicht einfach mit dem Dienstleister eine "On-Demand"-Regelung vereinbaren, anstelle einer Wartungspauschale?

Die Idee dahinter: der Dienstleister soll immer nur punktuell tätig werden, wenn Updates oder Aktualisierungen anstehen. Gibt es keine Updates, entstehen auch keine Kosten.

In der Praxis hätte dieses Modell aber zwei gravierende Nachteile, weswegen es unüblich ist und auch von erdfisch in dieser Form nicht angeboten wird:

a) fehlende Planbarkeit

Drupal Agenturen wie erdfisch planen ihre verfügbaren Kapazitäten langfristig und verteilen diese dabei zum einen auf die Projektentwicklung und zum anderen auf die Bestandskundenbetreuung, in welcher Produktwartung ein wichtiger Bestandteil ist.

Für die Produktwartung werden also ebenfalls Kapazitäten reserviert, um zum einen die regulären Drupal-Aktualisierungen durchzuführen, aber auch, um im Ernstfall bei kritischen Sicherheit-Updates zeitnah zur Stelle zu sein.

Um Produktwartung einplanen zu können, müssen dafür also bestimmte Kontingente reserviert sein. Bei einer "On-Demand"-Regelung wäre das nicht möglich. Somit käme der zweite Nachteil zum Tragen:

b) fehlende Verlässlichkeit

Sind für die Produktwartung keine Kapazitäten eingeplant, müsste dafür seitens des Anbieters „im Ernstfall“ erst Platz geschaffen werden – was unter Umständen zeitnah gar nicht möglich ist.

Entsprechend könnte der Kunde mit der "On-Demand"-Vereinbarung dann nicht zeitnah bedient werden und müsste warten, bis wieder Kapazitäten frei werden. Gerade bei sicherheitskritischen Themen ist dies aber ein No-Go.

Daher ist eine Wartungs- und Betreuungsvereinbarung mit einer dem mittleren Wartungsaufwand des Projekts entsprechenden Zeitpauschale, welche dann vom Dienstleister fix eingeplant wird, für eine zuverlässige Produktwartung unumgänglich.

Ja. Diese beschränken sich allerdings darauf, nach einem Wartungszyklus die Endkontrolle durchzuführen, dass insbesondere geschäftskritische Funktionen auch nach einem Update oder Upgrade noch wie gewohnt fehlerfrei funktionieren.

Eine solche Endkontrolle ist vor allem bei umfangreicheren Drupal-Aktualisierungen, die auch Funktions-Updates enthalten, sehr anzuraten.

Eine mögliche Entlastung in diesem Bereich können Test-Routinen sein, die vorab definierte Funktionen oder Prozesslogik innerhalb des Kundenprojekts automatisiert vertesten. Insbesondere dann, wenn ein Projekt nicht nur Wartung, sondern auch kontinuierliche Weiterentwicklung erfährt sind automatisierte Tests sowohl für den Endkunden als auch für den Dienstleister selbst eine große Hilfe, den Umfang manueller Tests zu reduzieren und damit auf lange Sicht sowohl viel Zeit als auch Geld zu sparen.

Ja. Wir übernehmen grundsätzlich auch die Wartung von Web-Projekten, die wir initial nicht selbst erstellt haben. Es müssen dabei jedoch einige Voraussetzungen erfüllt sein:

• das Setup muss auf der Drupal-Version 9 oder neuer laufen
• wir müssen die Möglichkeit erhalten, im Rahmen eines Kurzgutachtens eine Analyse des Projekts durchführen zu können um festzustellen, ob das Projekt sich in einem wartbaren Zustand befindet
• die Codebase des Projekts muss sich in einer Git-Versionsverwaltung befinden oder dorthin umgezogen werden und das Projekt selbst muss auf die kubernetes-basierte Container-Betriebsumgebung von erdfisch umgestellt werden - entweder auf den Servern des Kunden oder nach Umzug auf das erdfisch-eigene Hosting

Weitere Details zu den Voraussetzungen finden Sie im Absatz "In drei einfachen Schritten zur Wartungs- und Support-Vereinbarung bei erdfisch"

Innerhalb einer Hauptversion Drupals (z. B. Drupal 10) kümmern wir uns um das Einspielen der folgenden von der Drupal-Community bereitgestellten Aktualisierungen sowohl für den Drupal-Kern als auch die vorhandenen Contrib-Module:

• Security Releases - Aktualisierungen, die akute oder potenzielle Sicherheitsprobleme im System beheben
• Patch Releases - Aktualisierungen, durch die Programmfehler behoben oder Fehlfunktionen behoben werden
• Minor Releases - Aktualisierungen auf eine neue Zwischenversion Drupals, die meist auch neue Funktionen behalten oder in denen alte Funktionen abgekündigt werden

Weiterhin überprüfen wir stichprobenartig die Funktionalität des Systems nach den Aktualisierungen, erstellen vor und nach der Aktualisierung ein Datenbank-Backup und stellen die Aktualisierung zur Endkontrolle für den Kunden auf einer Test- und Abnahmeumgebung bereit.

Detaillierte Informationen zu unserer Vorgehensweise insbesondere bei sicherheitskritischen Aktualisierungen finden Sie im Blogbeitrag "Drupal auf Stand halten - Wartung kurz erklärt".

Grundsätzlich ja. Unsere containerbasierte Betriebsumgebung ermöglicht es, dass das Drupal-Setup gekapselt in einem dedizierten Container läuft.

Soll eine Aktualisierung auf das Produktivsystem ausgespielt werden, muss dieser Drupal-Container neu gestartet werden.

Dieser Neustart benötigt nur einige wenige Sekunden Zeit, sodass es praktisch keine Downtime gibt.

Eine seltene Ausnahme besteht, wenn extrem sicherheitskritische Updates ausstehen, bei denen eine Kompromittierung der Seite unmittelbar nach Veröffentlichung der Sicherheitslücke und des zugehörigen Patches zu befürchten ist.

Solche hochkritischen Patches werden mindestens mit einer Woche Vorlauf angekündigt und zum angekündigten Datum in den frühen Abendstunden europäischer Zeit veröffentlicht.

In diesem Fall ist unser Team in Abendbereitschaft und versetzt das zu aktualisierende Projekt kurz vor Erscheinen des Patches in einen speziellen Wartungsmodus, der Angreifern von außen keine Zugriffsmöglichkeit bietet.

Sobald der Patch eingespielt wurde, wird das System wieder online geschaltet.

Absolute Sicherheit wird es nie geben – auch nicht bei einer Wartungsvereinbarung mit einem erfahrenen und kompetenten Drupal-Anbieter wie erdfisch.

Jedoch kann das Risiko durch ein regelmäßig gewartetes und instand gehaltenes System sehr weitreichend minimiert werden, sodass dieses mit sehr hoher Wahrscheinlichkeit über viele Jahre hinweg erfolgreich betrieben und weiterentwickelt werden kann.

Bei Übernahme eines Projektes in die aktive Wartung etablieren wir unterschiedliche Kommunikationskanäle mit dem Kunden, über die Kommunikation im allgemeinen und Support im besonderen stattfinden kann.

Für die Projekt-Kommunikation werden Systeme zur kollaborativen Arbeit am Projekt (Ticketsystem) und zur asynchronen Kommunikation (Web-Chat) bereitgestellt - entweder von erdfisch, wenn er Kunde keine Systeme dieser Art bereits betreibt, oder es wird vereinbart, dass das Support-Team von erdfisch entsprechende Zugänge für die Kommunikations-Tools des Kunden erhält.

Sind die Kommunikationskanäle etabliert, kann auch technischer Support gegeben werden.

An unseren technischen Support können Sie sich wenden, wenn es im Rahmen der Systemwartung zu Schwierigkeiten kommt - also beispielsweise nach einem Update Teile des Drupal-Projekts nicht mehr oder anders funktionieren als bisher gewohnt, und dies nicht schon während der internen Qualitätskontrolle oder bei der Endkontrolle durch den Kunden bemerkt und behoben wurde.

Ebenso können Sie mit dem Support Termine abstimmen sowie fachliche Themen oder Verständnisfragen klären.

Ja. Jedes Projekt, das wir betreuen, bekommt einen sogenannten „administrativen Projektmanager“ und einen „operativen Projektmanager“ zugewiesen.

Während der administrative Projektmanager sich dabei um übergeordnete Themen wie Verträge, Budgetkontrolle und Customer-Success-Management kümmert, ist der operative Projektmanager Ihr persönlicher Ansprechpartner für konkrete Themen rund um das zu betreuende Projekt selbst. Er hat die zu erledigenden Aufgaben im Blick, steht bei Fragen oder Problemen zur Verfügung und achtet darauf, dass nichts „liegen bleibt“.

Bei Projekten mit kleinerem Umfang übernimmt meistens ein Mitarbeitender bei erdfisch beide Funktionen gleichermaßen.

Neben der asynchronen Kommunikation via Web-Chat oder E-Mail, die jederzeit gestartet werden kann, stehen wir von Montag bis Donnerstag zwischen 10 und 17 Uhr auch für geplante Termine via Video-Call zur Verfügung oder können telefonisch erreicht werden.

Ist ein Notfall-Support vereinbart, erhalten unsere Kunden zudem eine spezielle Notfall-Rufnummer, an welche sie sich im Ernstfall wenden können.

Ja. erdfisch betreut Drupal-Projekte anhand eines standardisierten Entwicklungs-Workflows und verfügt für diese über eine container-basierte Betriebsumgebung auf der Grundlage von Kubernetes. Um durch erdfisch gewartet und betreut zu werden, muss das fragliche Projekt in diese Entwicklungs-Workflows eingebunden und auf den Kubernetes-Webstack umgestellt werden. Dies ist ein einmalig anfallender Aufwand, der vor der Übernahme des Projekts in die Betreuung durch erdfisch durchgeführt werden muss.

Ja. Gemeinsam mit unserem Hosting-Partner bietet erdfisch ein leistungsfähiges und zuverlässiges Gesamtpaket sowohl für das Hosting als auch für den Betrieb Ihrer Drupal-Webseite an. Dieses lässt sich je nach den Anforderungen Ihres Projektes im Hinblick auf Traffic, Speicherplatzbedarf und Nutzerzahlen einfach und bequem skalieren lässt.

Dann setzt erdfisch diese um. Im Vorfeld führen wir eine Anforderungsanalyse durch, klären Rückfragen, erarbeiten ein technisches Konzept und schätzen den Implementierungsaufwand sowie Begleitaufwände ein.

Dies ist jedoch dann nicht mehr Teil der Wartungs- und Support-Vereinbarung, sondern kann z.B. im Kontext einer separat abgeschlossenen Weiterentwicklungs-Vereinbarung über ein bestimmtes einmaliges oder monatlich wiederkehrendes Personentage-Kontingent erfolgen.

Auch punktuelle Weiterentwicklungs-Aufträge über das Einholen einzelner Angebote sind denkbar, oder das Modell des agilen Festpreises.

Weitere Informationen zu unserem Leistungsspektrum rund um die Konzeption und (Weiter-)Entwicklung von Drupal-Projekten finden Sie hier.