Kaum ein Administrator kommt dauerhaft am Patchmanagement vorbei. Windows-Updates, Linux-Pakete, Hypervisor, Firewalls, Switches, Anwendungen, Datenbanken und Firmware müssen regelmäßig aktualisiert werden.

Gleichzeitig kennt wahrscheinlich jeder aus dem IT-Betrieb Geschichten von Updates, nach denen plötzlich Drucker verschwunden sind, Anwendungen nicht mehr starten, Dienste hängen oder ein Server nach dem Neustart nicht mehr so zurückkommt, wie man es erwartet hat.

Das Risiko eines Updates ist kein Argument gegen Updates. Es ist ein Argument für einen kontrollierten Update-Prozess.

Warum Patchen keine optionale Aufgabe ist

Updates werden gerne auf das Schließen von Sicherheitslücken reduziert. Das ist zwar ein wichtiger Punkt, aber längst nicht der einzige.

Patches können unter anderem:

  • Sicherheitslücken schließen
  • bekannte Softwarefehler beheben
  • Stabilität verbessern
  • Kompatibilitätsprobleme beseitigen
  • Treiber oder Firmware aktualisieren
  • neue Funktionen bereitstellen
  • Voraussetzungen für zukünftige Versionen schaffen
  • den Hersteller-Support aufrechterhalten

Ein dauerhaft ungepatchtes System ist deshalb nicht einfach nur „etwas älter“.

Mit zunehmendem Abstand zum aktuellen Patchstand wächst häufig auch der technische und organisatorische Rückstand.

Patchmanagement bedeutet nicht: Alles sofort auf jedem System installieren. Es bedeutet, verfügbare Updates zu bewerten und kontrolliert damit umzugehen.

Zwei Risiken statt nur eines

Beim Patchen wird oft nur über das Risiko eines fehlerhaften Updates gesprochen. Tatsächlich existieren aber zwei Risiken gleichzeitig:

  1. Das Risiko des Patchens: Ein Update verursacht eine Störung, Inkompatibilität oder einen Ausfall.
  2. Das Risiko des Nicht-Patchens: Eine bekannte Schwachstelle bleibt offen oder ein bereits behobener Fehler besteht weiter.

Gute Administration bedeutet deshalb nicht, eines dieser Risiken komplett auszublenden.

Die Aufgabe besteht darin, beide gegeneinander abzuwägen.

Nicht „Patchen oder nicht patchen?“ ist die eigentliche Frage, sondern: Wann, wie und mit welchem Sicherheitsnetz?

Vor dem Patchday: Wissen, was überhaupt betroffen ist

Ein kontrollierter Patchday beginnt nicht mit dem Klick auf „Updates installieren“.

Er beginnt mit einer wesentlich langweiligeren, aber wichtigeren Frage:

Welche Systeme betreibe ich eigentlich?

Für einen belastbaren Überblick sind beispielsweise relevant:

  • Server und virtuelle Maschinen
  • Clients und Notebooks
  • Hypervisor
  • Firewalls und Netzwerkgeräte
  • NAS- und Storage-Systeme
  • Datenbanken
  • Web- und Applikationsserver
  • Remote-Desktop- und Terminalserver
  • Backup-Systeme
  • Monitoring
  • Authentisierungsdienste
  • kritische Fachanwendungen

Ohne vernünftiges Inventar wird Patchmanagement schnell zum Blindflug.

Nicht nur Systeme betrachten – Abhängigkeiten verstehen

Ein Server existiert selten völlig isoliert.

Hinter einer einfachen Anwendung können beispielsweise mehrere Komponenten stehen: 

Benutzer
   ↓
Reverse Proxy
   ↓
Webserver
   ↓
Applikation
   ↓
Datenbank
   ↓
Storage

Zusätzlich können DNS, Active Directory, Zertifikate, Firewallregeln und externe Schnittstellen beteiligt sein.

Wenn eines dieser Systeme aktualisiert wird, können sich Auswirkungen an einer ganz anderen Stelle zeigen.

Deshalb gehört für mich zu einer guten Vorbereitung auch die Frage:

  • Welche Dienste hängen von diesem System ab?
  • Welche Systeme greifen darauf zu?
  • Welche Reihenfolge muss beim Neustart eingehalten werden?
  • Wer bemerkt einen Ausfall zuerst?
  • Welche Funktion muss nach dem Update getestet werden?

Vorher lesen statt hinterher googeln

Bevor ein größeres Update auf produktiven Systemen landet, lohnt sich ein Blick in die Informationen des Herstellers.

Interessant sind insbesondere:

  • bekannte Probleme
  • behobene Sicherheitslücken
  • Änderungen an Abhängigkeiten
  • Voraussetzungen
  • notwendige Neustarts
  • bekannte Inkompatibilitäten
  • entfernte oder veraltete Funktionen

Bei kleineren Routineupdates reicht häufig eine kurze Prüfung. Bei großen Versionssprüngen sollte die Vorbereitung entsprechend gründlicher sein.

Faustregel: Je größer die Änderung und je kritischer das System, desto größer sollte auch der Aufwand für Vorbereitung und Test sein.

Backup und Snapshot sind nicht dasselbe

Vor Änderungen fällt häufig ein Satz:

„Kein Problem, ich mache vorher einen Snapshot.“

Snapshots können sehr hilfreich sein. Sie sind aber nicht automatisch ein vollständiges Backup.

Ein Snapshot hängt in vielen Umgebungen weiterhin am gleichen Storage und damit an derselben Infrastruktur wie das Originalsystem.

Fällt beispielsweise das zugrunde liegende Storage aus, kann auch der Snapshot wertlos sein.

Außerdem sind Snapshots nicht bei jeder Anwendung und nicht für jede Aufbewahrungsdauer sinnvoll.

Vor kritischen Änderungen möchte ich deshalb wissen:

  • Existiert ein aktuelles Backup?
  • Ist dieses Backup erfolgreich abgeschlossen worden?
  • Ist die Wiederherstellung bekannt und getestet?
  • Welche Daten würden bei einem Restore verloren gehen?
  • Wie lange würde die Wiederherstellung dauern?
  • Kann zusätzlich ein kurzfristiger Snapshot sinnvoll sein?
Ein Backup, dessen Restore niemand geprüft hat, ist zunächst nur eine Hoffnung.

Nicht überall gleichzeitig anfangen

Einer der einfachsten Wege, das Risiko beim Patchen zu reduzieren, ist ein gestaffelter Rollout.

Statt alle Systeme gleichzeitig zu aktualisieren, kann man mit einer kleinen Testgruppe beginnen.

Ein vereinfachtes Modell könnte so aussehen:

Testsysteme
     ↓
Pilotgruppe
     ↓
unkritische Produktivsysteme
     ↓
kritische Produktivsysteme

Dadurch entsteht Zeit, Fehler zu erkennen, bevor sie die gesamte Umgebung betreffen.

Besonders bei Clients ist eine Pilotgruppe hilfreich, die möglichst verschiedene reale Anwendungsszenarien abdeckt.

  • verschiedene Hardware
  • unterschiedliche Fachanwendungen
  • VPN-Nutzung
  • Drucker und Peripherie
  • Remote-Arbeit
  • besondere Treiber

Das richtige Wartungsfenster

Selbst ein gut getestetes Update kann einen Neustart benötigen oder unerwartet länger dauern.

Deshalb sollte bei wichtigen Systemen klar sein, wann eine Änderung durchgeführt wird.

Vor einem Wartungsfenster prüfe ich beispielsweise:

  • Wer nutzt das System zu diesem Zeitpunkt?
  • Gibt es laufende Jobs oder Backups?
  • Laufen geplante Importe, Exporte oder Batch-Prozesse?
  • Ist jemand für einen möglichen Rollback verfügbar?
  • Wie lange darf der Dienst ausfallen?
  • Wer muss über die Wartung informiert sein?

Das eigentliche Update ist häufig schneller erledigt als die saubere organisatorische Vorbereitung.

Windows-Systeme: Patchen ist mehr als „Neustart erforderlich“

Windows-Updates wirken auf den ersten Blick bequem: Updates installieren, neu starten, fertig.

Im professionellen Betrieb möchte ich danach allerdings mehr wissen als nur, ob Windows wieder einen Desktop anzeigt.

Vor und nach dem Update können beispielsweise folgende Informationen interessant sein: 

Get-ComputerInfo

Get-Service

Get-WinEvent -LogName System -MaxEvents 50

Get-HotFix

Je nach Rolle des Systems gehören anschließend konkrete Funktionstests dazu.

Bei einem Server könnten das beispielsweise sein:

  • laufen alle benötigten Dienste?
  • sind Netzwerkverbindungen vorhanden?
  • funktioniert DNS?
  • sind Freigaben erreichbar?
  • antwortet die Webanwendung?
  • funktioniert die Anmeldung?
  • gibt es neue kritische Events?
Wichtig: „Der Server ist wieder hochgefahren“ und „der Dienst funktioniert wieder vollständig“ sind zwei unterschiedliche Aussagen.

Linux-Systeme: Updates mit Blick auf Änderungen

Auch unter Linux sollte ein Update nicht nur aus einem reflexartigen Paketmanager-Befehl bestehen.

Auf Debian- oder Ubuntu-Systemen kann zunächst geprüft werden:

sudo apt update

apt list --upgradable

Dadurch sieht man vor der Installation, welche Pakete überhaupt aktualisiert werden sollen.

Die eigentliche Aktualisierung kann anschließend beispielsweise erfolgen mit:

sudo apt upgrade

Nach dem Update sollte geprüft werden, ob Dienste neu gestartet werden müssen oder ein kompletter Reboot erforderlich ist.

Interessant können beispielsweise sein:

systemctl --failed

systemctl status nginx

journalctl -p err -b

Der konkrete Dienst hängt natürlich vom jeweiligen System ab.

Bei einem Datenbankserver sind andere Prüfungen notwendig als bei einem Reverse Proxy oder einem Docker-Host.

Nach dem Update beginnt die eigentliche Prüfung

Der gefährlichste Satz nach einem Update lautet möglicherweise:

„Sieht gut aus.“

Entscheidend ist nicht, ob die Oberfläche normal aussieht, sondern ob die erwarteten Funktionen tatsächlich vorhanden sind.

Deshalb definiere ich idealerweise bereits vor dem Update, woran ein erfolgreicher Patch erkannt wird.

Beispielsweise:

  • System ist erreichbar
  • alle kritischen Dienste laufen
  • keine neuen kritischen Logeinträge
  • Applikation antwortet
  • Benutzeranmeldung funktioniert
  • Datenbankverbindung funktioniert
  • Monitoring meldet grün
  • Backup-Agent ist aktiv
  • externe Schnittstellen funktionieren
Ein Patch ist für mich erst abgeschlossen, wenn die Funktion nach der Änderung verifiziert wurde.

Monitoring nach dem Patchday

Nicht jeder Fehler tritt unmittelbar nach einem Neustart auf.

Einige Probleme zeigen sich möglicherweise erst, wenn Benutzer am nächsten Morgen arbeiten, ein geplanter Job startet oder eine bestimmte Last entsteht.

Deshalb ist Monitoring nach einem Patchday besonders hilfreich.

Interessant sind beispielsweise:

  • CPU- und RAM-Auslastung
  • Storage-Auslastung
  • Dienste und Prozesse
  • Antwortzeiten
  • Netzwerkfehler
  • Eventlogs und Journals
  • Fehlerraten einer Anwendung
  • Backup-Ergebnisse

Ein gutes Monitoring kann damit nicht nur Ausfälle erkennen, sondern auch Unterschiede vor und nach einer Änderung sichtbar machen.

Rollback muss vorher geklärt sein

Ein Rollback-Plan sollte nicht erst entstehen, wenn das Update bereits schiefgegangen ist.

Vor der Änderung sollte klar sein, wie der vorherige Zustand wiederhergestellt werden kann.

Je nach System kann das beispielsweise bedeuten:

  • Snapshot zurückrollen
  • Backup wiederherstellen
  • Paketversion zurücksetzen
  • Konfigurationsdatei wiederherstellen
  • Firmware-Downgrade durchführen
  • VM oder Container aus Backup starten
  • Traffic auf einen zweiten Knoten umleiten

Wichtig ist außerdem ein Entscheidungspunkt:

Wie lange versuche ich, das neue System zu reparieren, bevor ich zurückrolle?

Ohne diese Entscheidung verliert man im Fehlerfall schnell Zeit, weil immer noch „eine Sache ausprobiert“ wird.

Wenn ein Patch nicht bis zum nächsten Wartungsfenster warten kann

Nicht jede Schwachstelle lässt sich gemütlich bis zum nächsten regulären Patchday verschieben.

Bei akut ausgenutzten oder besonders kritischen Sicherheitslücken kann ein beschleunigter Prozess notwendig sein.

Das bedeutet aber nicht, dass in solchen Situationen alle Kontrollen entfallen sollten.

Stattdessen kann der Prozess verdichtet werden:

  1. Betroffenheit feststellen
  2. Risiko bewerten
  3. Herstellerinformationen prüfen
  4. Backup und Rollback sicherstellen
  5. möglichst kurz testen
  6. Patch priorisiert ausrollen
  7. Funktion und Logs beobachten
Schnell patchen und blind patchen sind nicht dasselbe.

Wenn das Update fehlschlägt

Trotz guter Vorbereitung kann ein Update scheitern.

Genau dann zahlt sich ein strukturierter Prozess aus.

Statt sofort mehrere Dinge gleichzeitig zu ändern, versuche ich zunächst festzustellen:

  • Was funktioniert konkret nicht?
  • Was funktioniert weiterhin?
  • Welche Änderung wurde tatsächlich durchgeführt?
  • Welche Fehlermeldung existiert?
  • Welche Logs haben sich verändert?
  • Ist nur ein System oder eine ganze Gruppe betroffen?
  • Kann die Änderung sauber zurückgenommen werden?

Das verhindert, dass aus einem fehlerhaften Update zusätzlich fünf unkontrollierte Reparaturversuche werden.

Dokumentation: Morgen weiß niemand mehr alles

Ein Patchday liefert wertvolle Informationen für den nächsten Durchlauf.

Deshalb dokumentiere ich idealerweise nicht nur, dass etwas aktualisiert wurde.

Sinnvoll sind beispielsweise:

  • Datum und Wartungsfenster
  • betroffene Systeme
  • Ausgangsversion
  • Zielversion
  • installierte Updates
  • besondere Vorbereitung
  • durchgeführte Funktionstests
  • aufgetretene Probleme
  • Rollback oder Workaround
  • offene Nacharbeiten

Beim nächsten Patchday muss dadurch nicht wieder bei null angefangen werden.

Mein Patchday-Workflow

Für einen normalen Wartungslauf lässt sich der Ablauf auf wenige, aber klare Schritte reduzieren:

  1. Updates erfassen: Welche Updates stehen für welche Systeme bereit?
  2. Relevanz prüfen: Was wird behoben und gibt es bekannte Probleme?
  3. Abhängigkeiten betrachten: Welche Dienste und Benutzer sind betroffen?
  4. Backup prüfen: Existiert ein funktionierender Wiederherstellungsweg?
  5. Rollback festlegen: Wie komme ich zum vorherigen Zustand zurück?
  6. Testgruppe patchen: Nicht sofort überall gleichzeitig beginnen.
  7. Funktion prüfen: Dienste, Logs, Anwendung und Monitoring kontrollieren.
  8. Rollout erweitern: Weitere Systeme schrittweise aktualisieren.
  9. Nachkontrolle: Systeme auch nach dem eigentlichen Wartungsfenster beobachten.
  10. Dokumentieren: Patchstand, Auffälligkeiten und offene Punkte festhalten.
Patchmanagement ist kein einzelner Klick. Es ist ein wiederholbarer Betriebsprozess.

Praxisbeispiel: Ein kleiner Webserver

Nehmen wir einen Linux-Webserver mit Nginx.

Vor dem Update prüfe ich zunächst, ob der Dienst aktuell sauber läuft: 

systemctl status nginx

systemctl --failed

Danach kontrolliere ich die verfügbaren Updates: 

sudo apt update

apt list --upgradable

Vor einer Änderung sollte zusätzlich geklärt sein, ob ein aktuelles Backup vorhanden ist und wie der Dienst im Fehlerfall wiederhergestellt werden kann.

Nach dem Update:

systemctl status nginx

systemctl --failed

journalctl -p err -b

Anschließend reicht es nicht, nur den Dienststatus zu betrachten.

Die eigentliche Webseite sollte ebenfalls getestet werden. 

curl -I https://example.com

Jetzt besitzt die Aussage:

„Der Webserver funktioniert nach dem Update.“

wesentlich mehr Substanz als:

„Die VM ist wieder an.“

Typische Fehler beim Patchmanagement

Viele Probleme entstehen nicht durch das Update selbst, sondern durch den Prozess darum herum.

Typische Fehler sind für mich:

  • alle Systeme gleichzeitig aktualisieren
  • keine Testgruppe verwenden
  • Backups nicht kontrollieren
  • Snapshots mit vollständigen Backups verwechseln
  • keinen Rollback-Plan besitzen
  • keine Herstellerhinweise lesen
  • nach dem Neustart keine Funktionstests durchführen
  • Abhängigkeiten ignorieren
  • Updates monatelang ohne Bewertung verschieben
  • keine Dokumentation führen

Keine dieser Maßnahmen ist besonders spektakulär.

Genau das ist der Punkt.

Gute Administration sieht im Idealfall langweilig aus, weil die interessanten Katastrophen gar nicht erst entstehen.

Meine kompakte Patchday-Checkliste

Vorher

  • Updates und Änderungen prüfen
  • bekannte Probleme lesen
  • betroffene Systeme bestimmen
  • Abhängigkeiten prüfen
  • Backup kontrollieren
  • Rollback festlegen
  • Wartungsfenster prüfen
  • Benutzer oder Verantwortliche informieren

Währenddessen

  • mit Test- oder Pilotsystem beginnen
  • Änderungen nachvollziehbar durchführen
  • Fehler nicht mit weiteren Änderungen überdecken
  • Neustarts kontrolliert durchführen

Danach

  • Dienste kontrollieren
  • Logs prüfen
  • Funktionstest durchführen
  • Monitoring beobachten
  • Backup-Funktion erneut kontrollieren
  • Patchstand dokumentieren
  • offene Probleme festhalten

Fazit

Updates gehören zu einem gesunden IT-Betrieb. Trotzdem muss kein Administrator jeden Patch blind und sofort auf jedes produktive System werfen.

Genauso wenig ist es sinnvoll, aus Angst vor möglichen Problemen über Monate gar nicht zu patchen.

Der vernünftige Weg liegt dazwischen:

Risiken bewerten, Backups prüfen, klein anfangen, Funktionen testen, Monitoring beobachten und einen Rückweg offenhalten.

Dann wird aus dem Patchday keine monatliche Mutprobe, sondern ein normaler Bestandteil des Betriebs.

Für mich ist ein guter Patchday deshalb nicht der, an dem möglichst schnell überall „aktuell“ steht.

Ein guter Patchday ist der, nach dem die Systeme aktueller sind und der Betrieb trotzdem genauso zuverlässig weiterläuft wie vorher.

← Zurück zu allen Artikeln