Wartungsfenster: Warum geplante Unterbrechungen billiger sind als ungeplante

Updates gelten als lästig, weil sie kurzfristig stören. Ihr Ausbleiben stört langfristig deutlich mehr: Ungepatchte Systeme gehören zu den häufigsten Einstiegspunkten für Angriffe, und ungewartete Software fällt irgendwann von selbst aus – nur eben ohne Terminabsprache. Die eigentliche Frage lautet also nicht, ob ein Server unterbrochen wird, sondern ob das zu einem selbst gewählten Zeitpunkt geschieht.

Ein konstruiertes, aber alltagsnahes Szenario macht den Unterschied greifbar: Ein geplantes Fenster von 90 Minuten an einem Dienstagabend betrifft niemanden, der gerade arbeitet. Die Sicherung ist geprüft, der Ansprechpartner des Softwareherstellers weiß Bescheid, und falls etwas klemmt, bleibt die Nacht als Puffer. Derselbe Neustart, ungeplant um zehn Uhr vormittags ausgelöst durch einen Fehler oder einen Angriff, trifft alle Arbeitsplätze gleichzeitig – ohne vorbereitete Sicherung, ohne Rückweg und ohne verfügbaren Ansprechpartner. Die Technik ist in beiden Fällen dieselbe, der Schaden nicht.

Ein Rhythmus, der funktioniert

Bewährt hat sich ein fester monatlicher Turnus mit klarer Reihenfolge: zuerst Testsysteme, dann unkritische Server, zuletzt die Kernsysteme. Microsoft veröffentlicht seine regulären Sicherheitsupdates am zweiten Dienstag eines Monats, und auch andere Hersteller arbeiten mit festen Terminen. Ein Wartungsfenster einige Tage danach lässt Zeit, Berichte über fehlerhafte Updates abzuwarten und die Testsysteme zu beobachten, ohne die Lücke unnötig lange offen zu lassen.

Die Testreihenfolge setzt voraus, dass es überhaupt ein Testsystem gibt. Im Mittelstand fehlt oft eine vollständige Testumgebung; dann übernimmt ein weniger kritischer Server gleicher Bauart diese Rolle, oder die Fachanwendung wird als Kopie in einer abgeschotteten Umgebung vorab aktualisiert. Entscheidend ist, dass zwischen den Stufen genug Zeit liegt, damit Fehler auffallen, bevor sie das Kernsystem erreichen – ein oder zwei Arbeitstage genügen meist.

Sicherheitskritische Notfall-Patches durchbrechen diesen Rhythmus bewusst. Wird eine Lücke bereits aktiv ausgenutzt oder betrifft sie ein System, das direkt aus dem Internet erreichbar ist, wartet niemand auf den nächsten Monat. Dafür braucht es eine vorab vereinbarte Regel, wer einen Notfall-Patch freigibt und wer informiert wird, damit im Ernstfall keine Zeit mit Abstimmung verloren geht. Die Warnmeldungen des BSI und die Sicherheitshinweise der Hersteller sind dafür die naheliegenden Quellen – jemand muss sie allerdings verlässlich lesen, auch in der Urlaubszeit.

Mehr als das Betriebssystem

Patch-Management wird oft mit Windows-Updates gleichgesetzt. Die Angriffsfläche eines Servers ist jedoch breiter, und gerade die Komponenten abseits des Betriebssystems bleiben häufig jahrelang unberührt, weil sich niemand zuständig fühlt:

Für jede dieser Gruppen sollte festgelegt sein, wer sie im Blick hat und in welchem Turnus sie aktualisiert wird. Das IT-Grundschutz-Kompendium des BSI beschreibt die Anforderungen dazu im Baustein OPS.1.1.3 „Patch- und Änderungsmanagement“ – eine brauchbare Vorlage auch für Unternehmen, die keine Zertifizierung anstreben. Kernaussage des Bausteins: Patches sind nach Erscheinen zeitnah zu bewerten und zu priorisieren, und für jede Änderung muss eine Rückfalllösung bereitstehen.

Der Ablauf eines Fensters

Vor jedem Fenster gilt dieselbe Reihenfolge: aktuelle Sicherung prüfen, Rückwegplan festlegen, dann patchen. Geprüft heißt dabei nicht, dass die Sicherungssoftware einen grünen Haken zeigt, sondern dass die letzte Sicherung vollständig ist und sich im Zweifel zurückspielen lässt. Bei virtuellen Servern kommt ein kurzfristiger Snapshot hinzu, der nach erfolgreicher Prüfung wieder entfernt wird, damit er nicht unbemerkt wächst.

Nach dem Einspielen folgt ein kurzer Funktionstest der wichtigsten Anwendungen, bevor das Fenster geschlossen wird: Anmeldung, ein Blick in die Warenwirtschaft, ein Testdruck. Dazu gehört eine knappe Notiz, was auf welchem System eingespielt wurde. Diese Dokumentation ist beim nächsten Fehlerbild oft die schnellste Spur, denn die erste Frage lautet fast immer, was sich seit gestern geändert hat.

Kommunikation macht den Unterschied

Ein angekündigtes Fenster am Dienstagabend erzeugt kaum Widerspruch; eine überraschende Unterbrechung am Dienstagvormittag kostet Vertrauen. Wer Wartungszeiten frühzeitig, verlässlich und immer im selben Rahmen ankündigt, gewöhnt die Organisation daran – und gewinnt den Spielraum, den ein sicherer Betrieb braucht. Die Ankündigung sollte dabei in der Sprache der Nutzer formuliert sein: nicht, welche Updates eingespielt werden, sondern welche Programme ab wann und bis wann nicht zur Verfügung stehen.

Hilfreich ist, das Fenster einmal verbindlich festzulegen und von der Geschäftsführung bestätigen zu lassen, etwa als fester Abend im Monat. Dann muss nicht jedes Update neu verhandelt werden, und Ausnahmen – ein Messetermin, der Jahresabschluss, eine Produktionsspitze – werden bewusst entschieden statt stillschweigend hingenommen. Verschobene Updates gehören auf eine Liste mit neuem Termin; sonst wird aus der Ausnahme unbemerkt die Regel.

Ob das Verfahren trägt, zeigen drei Angaben, die in keinem monatlichen Betriebsbericht fehlen sollten: Wie viele Systeme sind auf aktuellem Stand, welche nicht, und aus welchem Grund? Ein Server, der seit Monaten ohne Begründung ungepatcht bleibt, ist kein technisches Detail, sondern eine Risikoentscheidung, die niemand bewusst getroffen hat.

Verwandte Themen: Wer hier weiterdenkt, liest bei Windows Update, SLA und Servermigration weiter.