Patching in einer kleinen Umgebung

In IT-Abteilungen von Großunternehmen ist das Patchen von Systemen ein komplizierter Prozess, der eine große Zahl von Testsystemen umfasst, welche die Produktionssysteme nachbilden, sodass jeder neue Patch, der von Betriebssystem- und Softwareherstellern eintrifft, in einer realitätsnahen Umgebung getestet werden kann, um zu sehen, wie er mit den in der Organisation vorhandenen Hardware- und Softwarekombinationen zusammenwirkt. In einer idealen Welt verfügte jede Abteilung über einen verwalteten Patch-Prozess, der unmittelbar auf neu veröffentlichte Patches reagiert, sie augenblicklich testet und anwendet, sobald der Patch als sicher und relevant eingestuft wurde. Doch die Welt ist nicht ideal, und in der Praxis müssen wir mit begrenzten Ressourcen auskommen: physischen, zeitlichen und finanziellen.

Patches werden im Allgemeinen aus einigen wenigen zentralen Gründen veröffentlicht: aus Gründen der Sicherheit, der Stabilität, der Leistung und gelegentlich zur Bereitstellung neuer Funktionen. Mit Ausnahme der Hinzufügung neuer Funktionen, die normalerweise über einen anderen Veröffentlichungsprozess gehandhabt wird, stellt ein Patch die Behebung eines bekannten Problems dar. Dies ist kein Szenario nach dem Motto „Was nicht kaputt ist, muss man nicht reparieren“, sondern ein Szenario nach dem Motto „Es ist defekt und nur noch nicht vollständig ausgefallen“, das Aufmerksamkeit erfordert – je früher, desto besser. Bei Patches eine abwartende Haltung einzunehmen, ist unklug, denn die Existenz eines neuen Patches bedeutet, dass böswillige Hacker über eine „Behebung“ verfügen, die sie analysieren können; und selbst wenn ein Exploit zuvor nicht existierte, wird er schon sehr bald existieren. Die Veröffentlichung des Patches selbst kann der Auslöser für die unmittelbare Notwendigkeit eben dieses Patches sein.

Dieses Patch-Ökosystem schafft die Notwendigkeit einer Mentalität des „schnellen Patchens“. Patches sollten niemals liegen bleiben; sie müssen häufig angewendet werden, sobald sie veröffentlicht und getestet wurden. Mit dem Patchen zu warten, kann bedeuten, mit kritischen Sicherheitslücken zu arbeiten oder Systeme unnötig unzuverlässig zu halten.

Kleine IT-Abteilungen verfügen selten bis nie über Testumgebungen, sei es für Server, Netzwerkgeräte oder auch nur für Desktops. Das ist nicht ideal, aber realistisch betrachtet hätten selbst dann, wenn solche Umgebungen verfügbar wären, nur wenige kleine Abteilungen die überschüssigen personellen IT-Ressourcen, um diese Tests zeitnah durchzuführen.

Das ist nicht so trostlos, wie es klingt. Die für die meisten Patches durchgeführten Tests überschneiden sich mit den bereits vom Hersteller getesteten Patches. Hersteller können unmöglich jede Hardware- und Software-Wechselwirkung testen, die mit ihren Produkten jemals auftreten könnte, doch sie testen im Allgemeinen eine breite Palette von Kombinationen und betrachten die Bereiche, in denen Wechselwirkungen am wahrscheinlichsten sind. Es kommt selten vor, dass ein großer Hersteller seine eigene Software mit fehlerhaften Patches lahmlegt. Ja, das kommt vor, und gute Backups sowie Rollback-Pläne sind wichtig, doch im Tagesgeschäft ist das Patchen ein verhältnismäßig sicherer Vorgang, den umgehend durchzuführen weitaus wichtiger ist, als auf Gelegenheiten zu warten, die eintreten können oder auch nicht.

Wie jede Systemänderung lassen sich Patches am besten in häufigen, kleinen Dosen anwenden. Werden Patches umgehend angewendet, müssen normalerweise nur ein oder wenige Patches gleichzeitig eingespielt werden. Bei Betriebssystemen müssen Sie unter Umständen dennoch mehrere Patches auf einmal handhaben, insbesondere wenn nur wöchentlich gepatcht wird, doch selten müssen Sie auf diese Weise Dutzende oder Hunderte von Dateien auf einmal patchen. Wird auf diese Weise vorgegangen, ist es weitaus einfacher, Patches auf nachteilige Auswirkungen hin zu bewerten und ein Rollback durchzuführen, falls ein Patch-Vorgang schiefläuft.

Das schlimmste Szenario für ein kleines Unternehmen, dem ein ordentlicher Patch-Test-Workflow fehlt, besteht darin, mit Patches zu warten. Warten bedeutet, dass Systeme über lange Zeiträume hinweg ohne die nötige Pflege bleiben und dass Patches, wenn sie schließlich eingespielt werden, oft in großen, gebündelten Patch-Vorgängen angewendet werden. Das gleichzeitige Einspielen vieler Patches erhöht die Wahrscheinlichkeit, dass etwas schiefgeht, und wenn dies geschieht, kann es weitaus schwieriger sein, zu ermitteln, welcher Patch beziehungsweise welche Patches schuld sind, und einen Weg zur Behebung zu finden.

Verzögertes Patchen ist ein Vorgehen, das weder der IT noch dem Unternehmen einen oder kaum einen Vorteil bringt, jedoch ein erhebliches Risiko für Sicherheit, Stabilität und Leistung birgt. Die bewährte Vorgehensweise für das Patchen in einer kleinen Umgebung besteht entweder darin, Systemen zu erlauben, sich so schnell wie möglich selbst zu patchen, oder einen regelmäßigen Patch-Prozess einzuplanen – vielleicht wöchentlich – zu einem Zeitpunkt, an dem das Unternehmen am besten darauf vorbereitet ist, dass das Patchen fehlschlägt und eine Patch-Behebung erforderlich wird. Ob Sie sich nun für automatisches Patchen entscheiden oder dies einfach regelmäßig in einem manuellen Prozess tun – für beste Ergebnisse patchen Sie häufig und umgehend.