Patch-Management-Checkliste
Patch-Management-Checkliste für den monatlichen Patchzyklus auf Linux- und Windows-Servern: Bewertung, Snapshots, Pilotgruppe, Neustarts, Prüfung und Bericht.
- Typischer Rhythmus monatlich
- Die Checkliste 4 Abschnitte, 19 Punkte
- Variablen
{{month}}
Diese Checkliste ist für den regelmäßigen Patchzyklus gedacht, meist einmal im Monat. Viele Teams richten ihn am monatlichen Patchday von Microsoft am zweiten Dienstag aus. Sie passt für Linux- und Windows-Server und für kleine Serverlandschaften, die von Hand oder mit einfachen Werkzeugen gepatcht werden (etwa unattended-upgrades, WSUS, Ansible, Azure Update Manager). Außerplanmäßige Patches für aktiv ausgenutzte Schwachstellen folgen denselben Schritten, nur schneller.
Wer verantwortlich ist
Für jeden monatlichen Durchlauf ist eine Person verantwortlich. Sie bewertet die verfügbaren Updates, plant die Wartungsfenster und bestätigt, dass jeder betroffene Server gepatcht ist oder eine dokumentierte Ausnahme hat. Die Verantwortlichen der Anwendungen bestätigen, dass ihre Dienste nach dem Neustart funktionieren.
Typische Fehler
- Gepatcht, aber nicht neu gestartet. Ein Kernel- oder Bibliotheks-Update wirkt erst nach dem Neustart des Servers oder Dienstes. Auf ausstehende Neustarts prüfen, nicht nur auf installierte Pakete.
- Alles auf einmal patchen. Zuerst eine Test- oder Pilotgruppe patchen und einen Tag warten. Ein fehlerhaftes Update trifft dann einen Server, nicht alle.
- Vergessene Server. Appliances, alte VMs und der Rechner unter dem Schreibtisch fallen aus dem Blick. Den Patchbericht jeden Monat mit dem Inventar abgleichen.
- Stille Ausnahmen. Ein Server, der „nicht gepatcht werden kann“, braucht eine verantwortliche Person, eine Begründung und ein Prüfdatum, sonst bleibt er für immer ungepatcht.
Planen Sie den Durchlauf in Runbook jeden Monat am selben Tag ein. So wartet die Checkliste schon auf Sie, und die Historie zeigt, welche Monate abgeschlossen wurden.
Die Checkliste: Patchzyklus Server {{month}}
Vorbereitung
-
Verfügbare Updates gesichtet und Sicherheitsupdates priorisiert
Herstellerhinweise und Listen aktiv ausgenutzter Schwachstellen auf Dringendes prüfen.
-
Bekannte Probleme der Updates dieses Monats in den Release Notes der Hersteller geprüft
-
Betroffene Server aus dem Inventar gelistet und in Pilot- und Hauptwelle eingeteilt
-
Wartungsfenster gebucht und Verantwortliche der Anwendungen informiert
-
Aktuelle Backups oder Snapshots für jeden betroffenen Server bestätigt
Ein VM-Snapshot ist der schnellste Rückweg. Nach einigen Tagen wieder löschen, damit er nicht anwächst.
Pilotwelle
-
Updates auf der Test- oder Pilotgruppe installiert
-
Pilotserver neu gestartet und wieder erreichbar
-
Anwendungen auf den Pilotservern von den Verantwortlichen getestet
-
Pilotgruppe während der vereinbarten Beobachtungszeit ohne neue Fehler gelaufen
Hauptwelle
-
Server hinter Load Balancern oder im Cluster Knoten für Knoten gepatcht
Jeden Knoten vorher aus dem Betrieb nehmen (drain), damit Nutzer den Neustart nicht bemerken.
-
Übrige Server in ihren Wartungsfenstern gepatcht
-
Alle Server bei Bedarf neu gestartet, kein Neustart mehr ausstehend
Linux: /var/run/reboot-required oder needs-restarting prüfen. Windows: den Pending-Reboot-Status prüfen.
-
Dienste und geplante Tasks auf jedem gepatchten Server wieder aktiv
Prüfen und berichten
-
Monitoring zeigt alle gepatchten Server ohne neue Alarme
-
Patchstand aller betroffenen Server mit dem Inventar abgeglichen
-
Fehlgeschlagene Updates untersucht und wiederholt oder als Ticket erfasst
-
Ausnahmen mit verantwortlicher Person, Begründung und Prüfdatum dokumentiert
-
Alte Snapshots nach der vereinbarten Frist gelöscht optional
-
Zusammenfassung des Patchzyklus
{{month}}mit dem Team geteilt
Checkliste als Markdown
Häufige Fragen
Wie oft sollte man Server patchen?
Die meisten Teams arbeiten mit einem festen monatlichen Zyklus und spielen kritische, aktiv ausgenutzte Schwachstellen außerplanmäßig ein, so schnell es sicher möglich ist. Eigenes Risiko, Verträge und Standards wie ISO 27001 oder SOC 2 können strengere Fristen vorgeben. Die gewählte Regel schriftlich festhalten und einhalten.
Was ist der Unterschied zwischen Patch-Management und Schwachstellenmanagement?
Patch-Management ist der Routineprozess, Updates der Hersteller einzuspielen. Schwachstellenmanagement geht weiter: Es findet Schwachstellen über Scans und Sicherheitshinweise, bewertet sie und behebt sie durch Patches, Konfigurationsänderungen oder zusätzliche Schutzmaßnahmen. Patchen ist die häufigste Maßnahme, aber nicht die einzige.
Sollte man das Patchen automatisieren statt eine Checkliste zu nutzen?
Die Installation so weit wie möglich automatisieren, zum Beispiel mit unattended-upgrades oder dem eigenen Konfigurationsmanagement. Die Checkliste deckt dann ab, was die Automatisierung nicht leistet: Bewertung, Ergebnisse der Pilotgruppe, ausstehende Neustarts, Ausnahmen und einen monatlichen Nachweis, dass der Zyklus stattgefunden hat.
Aktualisiert