Sicherheitsupdates und Patch-Management
Sicherheitsupdates mit festem Ablauf.
Wird eine kritische Lücke bekannt, kommt es zuerst auf eine Frage an: Welche deiner Systeme sind betroffen? Ich prüfe dafür jede Nacht alle Server und Container und arbeite bei einer Lücke einen festen Ablauf ab, vom Erkennen bis zur Kontrolle nach dem Update.
01 / Ablauf
Von der Meldung bis zur Kontrolle.
Sicherheitsupdates des Betriebssystems laufen automatisch jeden Tag. Für alles andere, also Anwendungen, Container und größere Updates mit Neustart, gehe ich in festen Schritten vor.
So läuft es bei mir
- ErkennenJede Nacht erfasse ich alle Server und Container und prüfe ihre Versionen gegen bekannte Sicherheitslücken. Dabei fallen auch Systeme am Ende ihrer Unterstützung (End of Life) und ausstehende Betriebssystem-Updates auf.
- Betroffene Systeme auflistenFür jedes betroffene System halte ich fest: welche Version läuft, ob es von außen erreichbar ist und auf welchem Weg es aktualisiert wird. Von außen erreichbare Systeme kommen zuerst.
- Vorläufig schützenGibt es noch kein Update oder muss ein Kunde erst freigeben, schütze ich das System vorläufig und sage das offen.
- Aktualisieren mit RückwegVor jedem Rollout sichere ich die Datenbank, behalte das alte Image unter eigenem Namen und die alte Konfiguration. Riskante Updates teste ich vorher in einer Testkopie mit Datenbankabzug.
- Kontrolle danachNach dem Update prüfe ich, ob die neue Version wirklich läuft, ob die Dienste arbeiten und ob sie erreichbar sind. Bei Runden mit Neustart geht es erst danach zum nächsten Server.
Abgrenzung: Diese Seite behandelt Sicherheitsupdates. Neue Versionen deiner eigenen Anwendung und geplante Releases laufen über einen eigenen Lieferweg, beschrieben unter Bereitstellung & Updates.
Was wir vorab klären: Welche Systeme dazugehören, wer Updates freigibt, wann gewartet werden darf und wie du bei dringenden Lücken erreicht wirst. Eine Rund-um-die-Uhr-Bereitschaft gehört nicht automatisch dazu.
02 / Beispiel
Die PHP-Lücken im Oktober 2026.
Im Oktober 2026 wurden zwei kritische Lücken im PHP-Kern bekannt. Angreifer konnten darüber Code auf dem Server ausführen. PHP steckt unter vielen Shops, Websites und Geschäftsanwendungen.
Was ich gemacht habe
- Vor der VeröffentlichungDas Update war angekündigt. Bevor es erschien, lag mir eine Liste aller betroffenen PHP-Systeme vor, mit Version, Erreichbarkeit von außen und Update-Weg.
- SofortschutzNoch vor den Patches habe ich überall einen Sofortschutz gesetzt.
- PatchesDie ersten Patches liefen rund 4 Stunden nach der Veröffentlichung.
Mein Ziel bei kritischen Lücken: Bei kritischen Sicherheitslücken ist mein Ziel: gepatcht innerhalb eines Tages für alles, wofür es einen Fix gibt. Bei der PHP-Lücke im Oktober waren die meisten Systeme am selben Abend dran, die letzten nach wenigen Tagen. Wo es keinen Fix gibt oder ein Kunde freigeben muss, schütze ich vorläufig und sage das dem Kunden offen.
Zusammenarbeit
Updates als Teil der Betreuung.
Patch-Management funktioniert nur, wenn klar ist, welche Systeme dazugehören. Deshalb gehört es zur laufenden Server-Betreuung und beginnt mit einer Bestandsaufnahme.
Umfang, Aufwand und Kosten stimmen wir vor der Umsetzung mit dir ab.
- Systeme erfassen. Server, Container und Anwendungen in die nächtliche Prüfung aufnehmen.
- Regeln festlegen. Freigaben, Wartungsfenster und den Weg bei dringenden Lücken vereinbaren.
- Laufend pflegen. Updates einspielen, kontrollieren und dokumentieren.
Dein fester Ansprechpartner bin ich. Für die Vertretung stehen projektkundige Kollegen aus dem Freelancernetzwerk bereit.
Mehr zur ZusammenarbeitDer nächste Schritt
Weißt du, wie aktuell deine Systeme sind?
Erzähl kurz, welche Server und Anwendungen du betreibst und wer sie bisher aktualisiert. Wir klären gemeinsam den nächsten Schritt.