Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Beim „Rebootless Patching“ des Linux-Kernels werden Sicherheitskorrekturen auf einen laufenden Kernel angewendet, sodass die Behebung von Sicherheitslücken nicht mehr auf einen Neustart warten muss.
- In diesem Blogbeitrag befassen wir uns mit einem fünfköpfigen Team, das rund 10.000 kritische Handelssysteme betreut, ohne dass auch nur ein einziger Neustart nach der Installation eines Patches erforderlich ist.
- Die Intervalle zwischen den Neustarts haben sich verdoppelt – von etwa sechs Monaten auf etwa ein Jahr – und sind nun optionale Wartungsmaßnahmen.
- Durch den Wegfall der Notwendigkeit eines Neustarts wurde die teamübergreifende Koordination eingeschränkt, und die PCI-DSS-Korrekturmaßnahmen wurden nicht in den Wartungsplan aufgenommen.
Eine Handelsplattform kann viele schlechte Tage überstehen. Ein Neustart des Kernels mitten während der Auftragsausführung gehört jedoch nicht dazu.
Es besteht eine Lücke zwischen dem Vorliegen eines Kernel-Patches und dem tatsächlichen Schutz eines Produktionssystems. Das Update wird bereitgestellt, doch dann muss jemand einen geeigneten Zeitpunkt finden, die Genehmigung für die Änderung einholen, die Anwendungsverantwortlichen zusammenbringen und den Rechner neu starten. Das rebootless patching des Linux-Kernels schließt diese Lücke, indem geeignete Sicherheitspatches auf den laufenden Kernel angewendet werden, sodass der Schutz nicht mehr vom Neustart abhängt.
Betrachten wir das Problem nun im größeren Maßstab. Fünf Ingenieure. Rund 10.000 kritische Systeme in mehreren Rechenzentren, die überwiegend auf RHEL basieren und größtenteils unter AlmaLinux laufen. Hinzu kommen PCI DSS sowie weitere Sicherheits- und Auditstandards, die verlangen, dass bekannte Schwachstellen in einem Zeitrahmen behoben werden, der deutlich kürzer ist als ein geologischer Zeitrahmen.
So sah die Situation bei einem globalen Finanzdienstleister aus, bei dem sich die Verfügbarkeit direkt auf den Umsatz auswirkt und selbst geringfügige Störungen bei der Auftragsabwicklung sich negativ auf die Bilanz auswirken.
Wenn das Patchen des Kernels zu einem operativen Projekt wird
Patches, die einen Neustart erforderten, wurden etwa alle sechs Monate durchgeführt. Nicht, weil irgendjemand der Meinung war, dass ein halbes Jahr Sicherheitsrisiko akzeptabel sei, sondern weil dies der Rhythmus war, den die Koordination tatsächlich bewältigen konnte. Die Planung eines einzigen Zyklus konnte Tage der Zeit des Teamleiters in Anspruch nehmen, noch bevor das gesamte Unternehmen überhaupt einbezogen wurde, und jeder App-Verantwortliche und jeder, der Änderungen genehmigen musste, hatte eine andere Meinung darüber, wann ein System außer Betrieb genommen werden konnte.
Sechs Monate, und es reichte immer noch nicht aus. Die Sicherheits- und Compliance-Teams wollten eine schnellere Behebung der Probleme. Das Entwicklerteam war bei diesem Tempo bereits überlastet. Beides traf gleichzeitig zu, was in der Regel ein Zeichen dafür ist, dass der Prozess nicht funktioniert und nicht die Menschen, die ihn durchführen.
Der Großteil dieser Kosten taucht nie in einer Ticket-Warteschlange auf. Er fließt in die Planung von Anrufen, die Rollback-Planung und die Überprüfung von Abhängigkeiten. Nichts davon dient dazu, auch nur eine einzige zusätzliche CVE zu beheben.
Die Berechnung des Wartungsfensters hat nie funktioniert
Der Teamleiter hat das Planungsproblem wie folgt beschrieben:
„Diese Systeme sind unverzichtbar; man kann sie nicht einfach abschalten. Wenn überhaupt, dann nur während bestimmter Wartungsfenster. Diese Zeitfenster einzuhalten war praktisch unmöglich, weil sie zu kurz sind, und man bräuchte etwa 100 Leute, um alles neu zu starten.“
Das ist die Rechnung, mit der jedes Unternehmen, das auf Hochverfügbarkeit setzt, früher oder später konfrontiert wird. Die Zeitfenster werden immer enger, je mehr das Geschäft global wird, die Fahrzeugflotte wächst weiter, während die Mitarbeiterzahl stagniert.
Bei ein paar hundert Hosts kann man sich mit roher Gewalt durch ein Neustart-Wochenende kämpfen und das dann als Plan bezeichnen. Bei 10.000 kritischen Systemen und fünf Mitarbeitern ist rohe Gewalt keine Option mehr, und der Patch-Rückstand wird zu einem festen Bestandteil der Umgebung. Für jede Kernel-CVE 100 Mitarbeiter einzustellen, ist keine Strategie.
Wenn Ihre Kapazitäten für Neustarts mit Ihrer Flotte wachsen, können geplante Zeitfenster weiterhin funktionieren. Ist dies nicht der Fall, besteht die einzige wirkliche Lösung darin, die Behebung von Sicherheitslücken überhaupt nicht mehr an Neustarts zu knüpfen.
Was sich durch das Patchen ohne Neustart für ein fünfköpfiges Team geändert hat
Nach der Prüfung verschiedener Optionen entschied sich die Organisation für „KernelCare“ von TuxCare und setzte die Lösung auf rund 10.000 ihrer wichtigsten Systeme ein. Tests zeigten eine zuverlässige und konsistente Bereitstellung von Patches, und die Einführung wurde zentral über das ePortal verwaltet, sodass fünf Mitarbeiter den Überblick über den gesamten Prozess behalten konnten.
Die Anzahl der durch obligatorische Patches bedingten Neustarts sank auf null. Neustarts finden zwar weiterhin statt, doch das Intervall zwischen ihnen verlängerte sich von etwa sechs Monaten auf etwa ein Jahr, und ihr Zweck änderte sich im Laufe der Zeit. Sie wurden zu optionalen Wartungsmaßnahmen statt zu Voraussetzungen für die Behebung von Kernel-Sicherheitslücken. Die teamübergreifende Koordination bei Kernel-Patches verschwand fast vollständig, ebenso wie die Planungsphase, die früher dem Patch vorausging.
Auch die Bereitstellung von Patches hat sich verändert. Anstatt dass angesammelte Korrekturen in einem einzigen, zeitlich begrenzten Fenster bereitgestellt werden, werden Patches nun kontinuierlich angewendet, sodass sich bei langfristig betriebenen Systemen keine Risiken mehr anhäufen.
Warum dies für PCI DSS und die Nachweisdokumentation von Bedeutung ist
Compliance-Rahmenwerke messen die verstrichene Zeit. Der Aufwand spielt dabei keine Rolle. PCI DSS erwartet, dass Sicherheitspatches für kritische und risikoreiche Schwachstellen innerhalb eines festgelegten Zeitfensters nach ihrer Veröffentlichung installiert werden, und ein Prüfer verlangt den Nachweis, dass die Frist eingehalten wurde, anstatt eine Erklärung dafür, warum sich das Wartungsfenster verzögert hat.
Ein sechsmonatiger Zyklus gewährleistet, dass zwischen der Verfügbarkeit eines Patches und dessen Installation ein zeitlicher Abstand besteht. Bei 10.000 Systemen wird dieser Abstand in jedem Scan-Bericht dokumentiert – Quartal für Quartal. Durch den Wegfall des Neustarts wird diese Lücke geschlossen, ohne dass ein zusätzliches Zeitfenster in den Kalender aufgenommen werden muss.
Für wen ist dieser Text gedacht?
Jeder, der ein hochverfügbares Linux-System unter Audit-Druck mit einem Team betreibt, das kleiner ist als die Flotte, die es wohl verdient hätte. Handelsplattformen sind das naheliegendste Beispiel, aber dieselbe Rechnung gilt auch für Datenbanken, Cluster-Workloads, Telekommunikation, Zahlungsabwicklung und jeden kundenorientierten Dienst, bei dem „einfach neu starten“ keine Sicherheitsstrategie ist.
Die Fallstudie beleuchtet, warum der sechsmonatige Zyklus nicht mehr tragbar war, worauf das Team bei der Bewertung von Patches ohne Neustart geachtet hat und wie sich die Situation hinsichtlich der Compliance und der täglichen Arbeitsbelastung danach verändert hat – größtenteils in den eigenen Worten des Unternehmens. Der Text ist kurz und konzentriert sich eher auf Zahlen als auf Beschreibungen.
Lesen Sie die vollständige Fallstudie:
Sicherheit für globale Handelssysteme gewährleisten, ohne die Verfügbarkeit zu beeinträchtigen →
