Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Es gibt fünf verschiedene Arten von Patches – traditionelle, virtuelle, Firmware-, Live- und Cloud-/Container-Patches –, von denen jede ihre eigenen Ausfallzeiten, Risiken und Compliance-Anforderungen mit sich bringt.
- Die meisten Teams greifen nach wie vor standardmäßig auf das „Patch-and-Reboot“-Verfahren zurück, wodurch Systeme tagelang oder wochenlang ungeschützt bleiben, während sich die Zeitfenster für Änderungen häufen.
- Durch Live-Patching werden Kernel- und Bibliothekskorrekturen auf laufende Systeme angewendet, ohne dass ein Neustart erforderlich ist, wodurch sich die Behebungszeit von Wochen auf Stunden verkürzt.
- Die richtige Patching-Strategie hängt von Ihren Anforderungen an die Verfügbarkeit, den vertraglich festgelegten SLAs und davon ab, welche Schichten Ihres Stacks tatsächlich in Ihrem Besitz sind.
Es ist Sonntag, 23 Uhr. Jemand aus Ihrem Team überwacht gerade ein Wartungsfenster, weil drei Produktionsserver einen Kernel-CVE-Patch benötigen und die einzige sichere Methode, diesen anzuwenden – laut dem Playbook von 2014 –, ein Neustart ist. Der Patch selbst ist zwei Megabyte groß. Die Ausfallzeit beträgt 40 Minuten pro Host. Multipliziert man das mit einer Flotte von einigen hundert Servern, wird aus der ganzen „schnellen Sicherheitskorrektur“ ein Viertel, das man nicht zurückbekommt.
Deshalb ist es tatsächlich entscheidend, für welche Art von Patches Sie sich entscheiden. Der richtige Ansatz kann das Wartungsfenster von Stunden auf Sekunden verkürzen – oder es ganz überflüssig machen. Der falsche Ansatz setzt Sie wochenlang einer bekannten Sicherheitslücke (CVE) aus, weil Sie keine Genehmigung für einen Neustart erhalten.
Manche sogenannte „Patching“-Methoden sind gar kein echtes Patching. Hier finden Sie einen umfassenden Leitfaden, der Ihnen hilft, die verschiedenen Patching-Angebote auf dem Markt zu verstehen.
Was ist das Patchen von Software?
Das Patchen von Software ist sowohl ein IT-Prozess als auch eine grundlegende Sicherheitsmaßnahme. Im Allgemeinen wird es als der Vorgang beschrieben, bei dem Probleme behoben oder Funktionen zu einem bestimmten System hinzugefügt werden, indem bestehende Komponenten durch aktualisierte ersetzt werden. Dies kann auf vielen verschiedenen Ebenen erfolgen, beispielsweise durch die Aktualisierung von Code auf der Ebene von Subsystemen, Abhängigkeiten oder Kernfunktionen. Ebenso können Sie bestimmte Anwendungen, Betriebssysteme, Treiber oder andere Komponenten patchen.
Zwar ist es stets das Ziel, eine aktuellere Version des zu patchenden Systems zu haben, doch der Unterschied zwischen den verschiedenen Patching-Ansätzen liegt darin, wie dies erreicht wird – und wenn man sie alle als eine einzige Kategorie betrachtet, führt dies dazu, dass Teams monatelang ungepatchte Sicherheitslücken in der Produktionsumgebung haben.
Wie andere Begriffe aus der IT, beispielsweise „Debugging“, leitet sich auch „Patching“ von einem physischen Vorgang ab. Ursprünglich bezog sich der Begriff auf das tatsächliche Abdecken von Löchern in Lochkarten, d. h., man „flickte“ einen Abschnitt des Codes. Da dieser Begriff mittlerweile aus der Mode gekommen zu sein scheint, werden wir uns stattdessen mit den moderneren Ansätzen befassen.
Der Unterschied zwischen einem Patch, einem Update und einer vollständigen Version
Bevor wir uns mit den verschiedenen Arten von Patches befassen, sollten wir zunächst ein terminologisches Problem klären, das in der Praxis für erhebliche Verwirrung sorgt. Die Begriffe „Patch“, „Update“ und „vollständige Version“ werden oft synonym verwendet – manchmal sogar von derselben Person im selben Gespräch –, doch sie bezeichnen deutlich unterschiedliche Dinge, insbesondere wenn es darum geht, den Arbeitsumfang festzulegen oder mit einem Compliance-Prüfer zu sprechen.
|
Aufnäher |
Aktualisierung |
Vollständige Pressemitteilung |
|
|
Definition |
Gezielte Behebung eines bestimmten Fehlers, einer CVE oder einer Regression |
Paket mit Patches und kleineren Verbesserungen |
Neue Hauptversion mit Änderungen an der Architektur oder den Funktionen |
|
Umfang |
Eingrenzt – oft eine einzelne Binärdatei oder ein Kernelmodul |
Mäßig – mehrere Komponenten |
Umfangreich – gesamtes Produkt, manchmal neue Abhängigkeiten |
|
Auswirkungen von Ausfallzeiten |
Kaum bis gar keine (bei Live-Patching: null) |
In der Regel ist ein Neustart oder ein Neustart des Dienstes erforderlich |
Erheblich – erfordert möglicherweise einen Migrationsplan |
|
Typischer Auslöser |
Offenlegung von CVE-Schwachstellen, Hotfix, Regressionsbericht |
Monatlich oder vierteljährlich |
Meilenstein im Fahrplan, Ende des Lebenszyklus der Vorgängerversion |
Eine sinnvolle Faustregel: Wenn man die Änderung in einem Satz beschreiben kann, handelt es sich um einen Patch. Wenn die Begleitinformationen länger als ein Absatz sind, ist es ein Update. Wenn eine Migrationsanleitung beiliegt, ist es eine vollständige Version.
Was die Tabelle jedoch nicht widerspiegelt: Anbieter bezeichnen Dinge manchmal falsch, um sie weniger einschneidend klingen zu lassen. Ein „kleines Update“, bei dem stillschweigend der zugrunde liegende Datenbanktreiber ausgetauscht wird, kommt funktional eher einer vollständigen Version nahe. Lesen Sie das Changelog, bevor Sie der Bezeichnung Glauben schenken.
Die wichtigsten Arten von Patches: Eine umfassende Übersicht
Die folgenden Typen decken den Großteil dessen ab, womit die meisten Sicherheits- und DevOps-Teams konfrontiert werden. Es gibt einige Überschneidungen – ein Firmware-Patch ist gleichzeitig auch ein Sicherheitspatch, und Live-Patching gilt sowohl für herkömmliche Linux-Server als auch für containerisierte Workloads. Die Kategorien schließen sich nicht gegenseitig aus, beschreiben jedoch jeweils einen eigenständigen Bereitstellungsmechanismus mit einem eigenen Betriebsprofil.
Traditionelles Patching
Dies ist den meisten Menschen als Patching bekannt. Es besteht darin, aktualisierte Versionen einer bestimmten Software herunterzuladen und dann die entsprechenden Dateien auf der Festplatte durch die neuen Versionen zu ersetzen.
Die Umsetzung ist relativ einfach und leicht zu verstehen: Man verfügt über eine alte Version einer bestimmten Software, die ganz oder teilweise durch eine neue Version ersetzt wird. Man muss die Anwendung neu starten oder das System neu booten, um die neue Version zu nutzen, aber darüber hinaus gibt es keine weiteren Schritte. Darin liegt natürlich auch der größte Nachteil – das Neustarten von Anwendungen oder das Neustarten ganzer Systeme ist ein langsamer Vorgang, der erhebliche Störungen bei den laufenden Arbeitslasten verursacht. Aus diesem Grund ist dies kein Vorgang, der ad hoc durchgeführt werden kann, sodass er in der Regel in einem sogenannten „Wartungsfenster“ stattfindet – einem vorab genehmigten Zeitraum, in dem mit Verfügbarkeits- oder Leistungsproblemen der Systeme gerechnet wird.
Die Einrichtung dauert lange, und bei Problemen wird die veranschlagte Zeit oft überschritten. Laut einem von TuxCare gesponserten Bericht des Ponemon Institute benötigen 56 % der Unternehmen zwischen fünf Wochen und einem Jahr, um kritische oder hochprioritäre Schwachstellen zu beheben – und über 55 % gaben an, einen Cybersicherheitsvorfall erlebt zu haben, der durch einen bereits verfügbaren, aber noch nicht installierten Patch verursacht wurde. Diese Verzögerung ist überwiegend auf die Planung der Installationsfenster zurückzuführen, nicht auf die Installation selbst.
Verwenden Sie diese Methode, wenn Sie über ein ausreichendes Wartungsfenster und eine stabile Testumgebung verfügen und keine Compliance-Vorgaben eine schnellere Fehlerbehebung erfordern. Verlassen Sie sich nicht ausschließlich darauf, wenn Sie Anwendungen ausführen, die keinen regulären Neustart vertragen.
Virtuelles Patchen
Es handelt sich hierbei um eine Lösung, die zwar das Wort „Patching“ im Namen trägt und auf den ersten Blick Patching-Ergebnisse zu liefern scheint, tatsächlich jedoch auf einer ganz anderen Ebene funktioniert. Beim virtuellen Patching findet kein tatsächlicher Austausch oder keine Korrektur des Codes statt. Es besteht darin, eine Bedrohungserkennung auf Firewall-Ebene zu implementieren und bekannte Angriffsmuster zu blockieren. Aus Sicht des Angreifers schlägt der Angriff fehl, sodass dieser möglicherweise annimmt, das System sei gepatcht, obwohl dies in Wirklichkeit nicht der Fall ist.
Diese Methode des „Patchens“ hat mehrere Nachteile: Es wird zu keinem Zeitpunkt tatsächlich korrigierter Code in die Systeme übernommen, der Schutz deckt nur bekannte Angriffsmuster ab – wodurch Probleme, die ausschließlich lokal auftreten, sofort außer Acht gelassen werden – und er kann durch Änderungen im Netzwerkverkehr, die einer bestimmten Bedrohung entsprechen, umgangen werden.
Sofern die Nachteile diesen Ansatz nicht von vornherein ausschließen, zählen zu den Vorteilen die Tatsache, dass es zu keinen Betriebsunterbrechungen kommt (da innerhalb eines Systems eigentlich nichts geschieht), die Möglichkeit, mit einer einzigen Bereitstellung mehrere Systeme abzudecken, sowie der sofortige Schutz vor neuen, ausschließlich aus der Ferne ausgehenden Bedrohungen, sobald diese hinzukommen.
Betrachten Sie virtuelles Patching als Notlösung und nicht als Endziel. Wenn eine schwerwiegende Sicherheitslücke bekannt wird und Ihr Team Tage statt Wochen benötigt, um die eigentliche Lösung zu implementieren, verschafft ein virtueller Patch wertvolle Atempause. Wenn dieser jedoch sechs Monate nach Bekanntwerden der Sicherheitslücke immer noch aktiv ist, haben Sie das Patching aufgegeben und beginnen, ein Risiko einzugehen.
Verwenden Sie diese Funktion, wenn Sie eine CVE schneller entschärfen müssen, als Sie den eigentlichen Fix anwenden können, oder wenn Sie Software am Ende ihres Lebenszyklus einsetzen, für die keine Hersteller-Patches mehr bereitgestellt werden.
Firmware-Patching
Das Aktualisieren von Firmware ist ein Sonderfall des herkömmlichen Patchens, mit dem zusätzlichen Unterschied, dass man Code auf Speichermedien patcht, die in der Regel schwer zu aktualisieren sind – direkt in EPROM-Chips (Erasable Programmable Read-Only Memory). Dies war früher bei frühen Smart-Geräten und IoT-Geräten der ersten Generation die Norm. Die Software wurde werkseitig geladen und erhielt selten – wenn überhaupt – Updates. Dies lag zum Teil daran, dass Aktualisierungen und Sicherheit damals noch nicht so im Vordergrund standen wie heute, aber auch daran, dass die Art und Weise, wie die Software gespeichert war, eine Aktualisierung erschwerte. Bei neueren Geräten ist der Code ganz oder teilweise auf standardmäßigere Speichermedien wie SSDs, SD-Karten oder Ähnliches geschrieben, die viel einfacher zu modifizieren sind.
Als Code noch auf Chips lief, die an spezielle Schreibhardware mit proprietären Softwareanforderungen und Kabeln angeschlossen werden mussten, führte dies zu einer zusätzlichen Komplexitätsebene, die den gesamten Prozess für die meisten IT-Teams sehr unattraktiv machte. Infolgedessen erhielten diese Geräte während ihrer gesamten Lebensdauer schlichtweg nie ein Update. Leider sind viele davon noch immer im Einsatz – Druckserver, IP-Kameras und Sensoren in Rechenzentren sind allesamt gute Beispiele für Geräte, die auf diese Weise funktionieren.
Das Patchen von Firmware ist zudem die Art von Update, die die größten betrieblichen Risiken birgt. Ein verpfuschter BIOS-Flash macht den Rechner unbrauchbar, und wenn es um das Zurücksetzen auf die vorherige Version geht, lautet die Antwort oft: „Das geht nicht.“ Die Hersteller sind uneinheitlich, was die Häufigkeit der Firmware-Updates und die Zuverlässigkeit ihrer Tests angeht – Serverhersteller sind in der Regel zuverlässig, aber bei IoT- und Consumer-Hardware sieht die Sache anders aus.
Für IoT- und Embedded-Geräte unter Linux gibt es eine interessante Zwischenlösung, die man kennen sollte. KernelCare IoT von TuxCare ermöglicht das Patchen des Kernels ohne Neustart für ARM64-Geräte – es unterstützt Raspberry Pi, Ubuntu und Yocto-basierte Distributionen auf verschiedenen Chipsätzen wie Arm Neoverse, NXP und AWS Graviton und bietet eine Integration mit Microsoft Azure IoT Hub für das Flottenmanagement –, wodurch das herkömmliche Problem der Firmware-Aktualisierung auf der Kernel-Ebene vollständig umgangen wird.
Wenden Sie dies in in festgelegten Abständen – vierteljährlich ist für die meisten Flotten angemessen –, immer nach Tests auf repräsentativer Hardware, und überspringen Sie niemals den Verifizierungsschritt nach dem Flash-Vorgang.
Live-Patching
Unter „Live-Patching“ versteht man den Vorgang, bei dem laufender Code geändert und bekanntermaßen fehlerhafte Abschnitte oder Funktionen durch korrigierte Versionen derselben Abschnitte ersetzt werden. Dies geschieht vollständig im Arbeitsspeicher, sodass die Anwendung nicht neu gestartet werden muss, damit die Änderungen wirksam werden. In einem Moment enthält die Software noch einen Fehler in einer Funktion, im nächsten wird stattdessen eine korrigierte Version dieser Funktion verwendet.
Es gibt keine Neustarts, keine Systemneustarts und keine Betriebsunterbrechungen. Aus diesem Grund können Patches sofort bereitgestellt werden – der Vorgang erfordert kein Wartungsfenster, was eine schnellere Reaktion auf aufkommende Bedrohungen ermöglicht. Anstatt wie beim herkömmlichen Patching Wochen oder Monate auf die Bereitstellung eines Patches zu warten, kann dies nun innerhalb von Stunden oder sogar Minuten nach Verfügbarkeit des Patches erfolgen.
Die zusätzliche Komplexität des Live-Patchings entsteht bereits bei der Erstellung des Patches. Der Patch muss so erstellt werden, dass er unter Verwendung derselben Variablengrößen und Ausrichtungen wie der Originalcode in den richtigen Speicherbereich geladen werden kann. Diese Komplexität bleibt den Nutzern einer Live-Patching-Lösung verborgen – sie ist nur für den Anbieter des Live-Patches sichtbar.
Ein Live-Patching-Subsystem ist bereits seit über 10 Jahren in der Lage, Patches im Linux-Kernel zu installieren, und es wurden zahlreiche verschiedene Lösungen entwickelt. KernelCare von TuxCare ist eine solche Lösung, die das Live-Patching des Linux-Kernels für alle gängigen Distributionen ermöglicht. LibCare erweitert dies auf kritische User-Space-Bibliotheken – darunter OpenSSL und glibc, die die Verschlüsselung und zentrale Systemaufrufe in praktisch jeder Linux-Workload unterstützen –, ohne dass ein Neustart des Dienstes erforderlich ist. Zusammen decken sie die Angriffsfläche mit dem höchsten Risiko auf einem Linux-Server ab, ohne ein Wartungsfenster in Anspruch zu nehmen.
Es gibt zudem zahlreiche Varianten des Live-Patchings, darunter temporäre und permanente Ansätze, je nachdem, ob der Live-Patching-Prozess als Übergangslösung oder als dauerhaftere Alternative zum herkömmlichen Patching eingesetzt wird.
Verwenden Sie es, wenn Sie Linux in nennenswertem Umfang betreiben, regulierte Workloads mit strengen SLAs für die Fehlerbehebung ausführen oder Stakeholder haben, die jeden ungeplanten Neustart als kritischen Vorfall betrachten.
Patches für Cloud- und Container-Umgebungen
Cloud- und Container-Workloads verändern das Modell in einer Weise, die es wert ist, genau verstanden zu werden, da die für herkömmliche Server geltenden Annahmen nicht ohne Weiteres übertragen werden können.
Container werden in der Regel durch das Neuerstellen des Images und das Ausrollen einer neuen Bereitstellung gepatcht – der alte Container wird durch einen neuen ersetzt, der die Korrektur enthält. In den meisten Arbeitsabläufen wird bewusst auf Änderungen an einem laufenden Container verzichtet; Unveränderlichkeit ist das zugrunde liegende Prinzip, und das ist ein solides Prinzip. Das bedeutet jedoch, dass ein anfälliges Basis-Image unbemerkt in vielen laufenden Containern weiterbestehen kann, wenn der Prozess des Neuerstellens nicht gut gesteuert wird.
In Cloud-Umgebungen wird die Verantwortung nach dem Modell der geteilten Verantwortung aufgeteilt. Bei IaaS übernimmt der Anbieter die Patches für den Hypervisor und die physischen Hosts; Sie sind für das Gastbetriebssystem, die Laufzeitumgebung und die Anwendungsschicht verantwortlich. Bei PaaS kümmert sich der Anbieter um einen größeren Teil des Stacks. Bei SaaS beschäftigen Sie sich hauptsächlich mit Agenten und Integrationen. Genau zu wissen, für welche Schicht Sie verantwortlich sind, ist schon die halbe Miete – Teams haben schon bittere Erfahrungen gemacht, weil sie davon ausgegangen sind, dass „die Cloud das schon regelt“, obwohl der Anbieter dies ausdrücklich nicht abdeckt.
Was sich durch das Container-Modell nicht ändert: Der Linux-Kernel, der der Container-Laufzeitumgebung zugrunde liegt, muss weiterhin gepatcht werden. Es handelt sich um echte Systeme, auf denen echte Kernel mit echten CVEs laufen, und Live-Patching gilt für sie genauso wie für jeden anderen Linux-Host.
Verwenden Sie diese Funktion, wenn Sie Kubernetes, ECS oder eine beliebige Container-Orchestrierungsplattform einsetzen. Kombinieren Sie Image-Neuerstellungen mit Live-Patching oder herkömmlichem Patching für das zugrunde liegende Host-Betriebssystem – die Container-Abstraktion macht den darunter liegenden Kernel nicht auf magische Weise sicher.
So wählen Sie die richtige Patching-Strategie
Es gibt viele verschiedene Ansätze für das Patchen, und keine einzelne Methode deckt alle Situationen ab. Die richtige Wahl hängt von einer Kombination verschiedener Faktoren ab – teils technischer, teils organisatorischer Art –, die zusammen genommen dazu führen, dass man sich für den einen oder anderen Ansatz entscheidet.
Einige der wichtigsten Faktoren:
Anforderungen an die Verfügbarkeit: Wenn ein 5-minütiger Neustart kein Problem darstellt, decken herkömmliche Patches die meisten Fälle ab. Wenn ungeplante Ausfallzeiten ein kritischer Vorfall sind, verändert Live-Patching die Situation erheblich.
SLAs für die Fehlerbehebung: Rahmenwerke wie PCI DSS und HIPAA legen fest, wie schnell kritische Patches installiert werden müssen. Wenn Ihr SLA 30 Tage beträgt und Ihre Änderungsfenster monatlich sind, haben Sie keinen Spielraum für Fehler.
Stack-Zusammensetzung: Flotten mit überwiegend Linux-basierten Systemen profitieren am meisten von Live-Patching. Windows-Flotten setzen auf traditionelles Patching, wobei virtuelles Patching als Notlösung dient. Embedded- und IoT-Geräte benötigen Firmware-Patches, in die die meisten Teams chronisch zu wenig investieren.
Betriebliche Reife: Automatisierte Testumgebungen und solide Rollback-Verfahren verändern die Frage, welche Strategien realisierbar sind. Ohne sie birgt jeder Patch-Typ ein höheres Risiko, als es sein sollte.
Ein praktischer Rahmen für typische Situationen:
- Unverzichtbare Verfügbarkeit, Linux-Flotte → Live-Patching für den Kernel und kritische gemeinsam genutzte Bibliotheken, traditionelles Patching für alles andere in einem entspannten Rhythmus
- Akzeptable Wartungsfenster, homogene Umgebung → Herkömmliches Patching mit starker Automatisierung deckt die meisten Anforderungen ab
- Sie sitzen auf Software fest, deren Lebenszyklus abgelaufen ist und die Sie noch nicht ersetzen können → Virtuelles Patching in Verbindung mit intensiver Überwachung ist die einzig sinnvolle Übergangslösung
- Die Infrastruktur umfasst physische Server, Netzwerkgeräte oder IoT-Geräte → Budget für Firmware-Patches als eigenständiges Programm, getrennt von OS-Patches
Für jedes Unternehmen, dem die Sicherheit seiner Systeme, Daten und Nutzer auch nur im Geringsten am Herzen liegt, ist das Patchen eine der grundlegenden Aufgaben, die auf strategischer und operativer Ebene angegangen werden muss. Jede Umgebung hat ihre eigenen Besonderheiten – achten Sie darauf, den für Ihre spezifische Situation geeigneten Prozess zu wählen.
Immer noch Neustart für Updates? Es gibt eine bessere Lösung.
Wenn Ihr derzeitiger Arbeitsablauf so aussieht: „Neustart planen, hoffen, dass nichts kaputtgeht, nächsten Monat wiederholen“, verursachen Sie mehr Aufwand als nötig und akzeptieren ein längeres Sicherheitsrisiko, als Sie sollten. Live-Patching gibt es, weil das Modell des „Neustarts als Notwendigkeit“ kein physikalisches Gesetz ist – es ist eine Gewohnheit, die aus einer Zeit stammt, in der es keine Alternative gab.
KernelCare und LibCare von TuxCare bieten Live-Patching für Linux-Kernel und kritische gemeinsam genutzte Bibliotheken – darunter OpenSSL und glibc – für alle gängigen Distributionen. Gleiche Server, keine Neustarts, keine Wartungsfenster für Sicherheitspatches erforderlich. Und falls Ihre Geräteflotte IoT- oder Embedded-Geräte umfasst, erweitert KernelCare IoT dieses Patching ohne Neustart auf ARM64-Geräte, auf denen Raspberry Pi-, Ubuntu- und Yocto-basierte Distributionen laufen.
FAQs
Ja. Patches sind Code, und Code enthält Fehler. Regressionen – also Fälle, in denen eine Korrektur etwas unbrauchbar macht, das zuvor funktioniert hat, oder einen neuen Fehler verursacht – sind ein bekanntes und dokumentiertes Risiko. Aus diesem Grund ist eine Testumgebung, die die Produktionsumgebung widerspiegelt, unverzichtbar, und deshalb sind schrittweise Einführungen einer flächendeckenden, gleichzeitigen Bereitstellung vorzuziehen.
In der Regel teilen sich der IT-Betrieb, die Sicherheitsabteilung und die Anwendungsteams, die für bestimmte Workloads verantwortlich sind, diese Aufgabe. Die Sicherheitsabteilung legt das SLA fest und priorisiert die Maßnahmen nach dem Schweregrad der CVE. Der Betrieb kümmert sich um die Bereitstellung. Die Anwendungsverantwortlichen überprüfen, ob alles ordnungsgemäß funktioniert. In kleineren Unternehmen übernimmt eine Person alle drei Aufgaben.
Kritische Sicherheitspatches: so schnell, wie es Ihr SLA zulässt, idealerweise innerhalb von 7 bis 14 Tagen nach Veröffentlichung durch den Anbieter. Routinemäßige Updates: Einmal im Monat ist ein üblicher Rhythmus. Firmware: vierteljährlich für die meisten Flotten. Je schneller Patches ohne Funktionsstörungen installiert werden können, desto kürzer ist das Sicherheitsrisiko – und Live-Patching ist die wichtigste Methode, um diesen Zeitrahmen zu verkürzen, ohne dabei Abstriche bei der Testgenauigkeit zu machen.
Durch das Installieren von Patches werden bestimmte bekannte Sicherheitslücken behoben, indem vom Hersteller veröffentlichte Codeänderungen übernommen werden. Die Systemhärtung verringert die Angriffsfläche insgesamt durch entsprechende Konfigurationen – indem nicht genutzte Dienste deaktiviert, das Prinzip der geringsten Berechtigungen durchgesetzt und die Firewall-Regeln verschärft werden. Patches schließen bekannte Sicherheitslücken; die Systemhärtung erschwert die Ausnutzung unbekannter Schwachstellen. Beides ist notwendig.
Ja. Container übernehmen Sicherheitslücken von ihren Basis-Images, und das Host-Betriebssystem unterhalb der Container-Laufzeitumgebung ist nach wie vor ein Linux-System, das Kernel-Patches benötigt. Das Modell ändert sich – man erstellt das Image neu, anstatt den laufenden Container zu modifizieren –, aber die Verpflichtung bleibt bestehen. Das Modell der geteilten Verantwortung verteilt die Verantwortung für das Patchen; es beseitigt sie nicht.
