Best Practices für das Patch-Management

Als Solution Architect werde ich oft gefragt, was die Best Practices von Red Hat für das Patch-Management sind. In diesem Artikel werde ich mich auf das Wesentliche konzentrieren und auf relevante Arbeiten und Materialien verweisen, um eine gezielte Anleitung dazu zu geben, was genau Best Practices sind und welche Tools Sie als Teil Ihres Patch-Management-Toolkits verwenden können.

Dieser Artikel gibt Ihnen einen Überblick über die Tools und Ansätze, mit denen Sie Patches bereitstellen können – und über die Best Practices zur Definition dieses Prozesses für Ihr Unternehmen.

Die Verwendung des Begriffs „Best Practice“ ist zugegebenermaßen ein wenig anmaßend. Was für das eine Unternehmen das Beste ist, ist für ein anderes vielleicht nicht optimal. Anstatt also einen Ansatz als "den besten" zu bezeichnen, halte ich es für besser, den Prozess im Hinblick auf die beste Lösung für ein bestimmtes Risikoniveau zu diskutieren. Wenn Sie über Patch-Management sprechen, sprechen Sie letztendlich über Risikomanagement oder Change Management.

Jede Organisation braucht eine Strategie für den Umgang mit Risiken. Gleichzeitig benötigt jede Organisation eine ganz individuelle Strategie dafür, wie der Umgang mit Risiken definiert wird, worauf sie sich konzentriert und wie sie verschiedene geschäftliche Beschränkungen, Auswirkungen oder Ergebnisse einschätzt.

Meiner Meinung nach wäre der Begriff „Good Practices“ besser geeignet. Beispielsweise veröffentlicht die Automation Community of Practice das Dokument Automation Good Practices, das auf Erkenntnissen basiert, die bei der Unterstützung von Kunden in diesem Bereich gesammelt wurden.

Was können wir für unser Patch-Management-Toolkit und für unsere Strategie nutzen?

Es gibt Tools und Methoden, mit denen Sie das Patch Management für Ihre Infrastruktur definieren können.

1. Errata-Definitionen

Red Hat unterteilt seine Code- oder Inhaltsänderungen (Errata) in 3 verschiedene Kategorien. Jede Kategorie hat einen anderen Zweck und eine andere Änderungsrate. Je nach den Zielen und der Toleranz Ihrer Organisation gegenüber Veränderungen kann eine Option besser zu einem bestimmten Ziel und einer bestimmten Änderungsrate passen als eine andere.

• Red Hat Security Advisory (RHSA): Zum Schutz Ihrer Systeme wurden dringende Änderungen vorgenommen
• Red Hat Bug Advisory (RHBA): Korrekturen für Bugs, von denen Sie möglicherweise betroffen waren
• Red Hat Enhancement Advisory (RHEA): Neue Funktionen wurden hinzugefügt

Weitere Informationen finden Sie in der Praktik zur Sicherheits-Backportierung von Red Hat und unter Was ist Backportierung und wie wird sie auf RHEL und andere Produkte von Red Hat angewendet?

Mit diesem Prinzip können Sie Errata nach Typ und Risiko isolieren und dann auswählen, welche Patches Sie für erforderlich und welche optional sind. 

Wenn beispielsweise eine Infrastruktur mit Internetverbindung oder eine DMZ (Demilitarized Zone oder entmilitarisierte Zone) mit einem hohen Sicherheitsprofil vorhanden ist, können Sie entscheiden, das Red Hat Security Advisory Errata anzuwenden, sobald es in dieser Umgebung veröffentlicht wird. Dadurch lassen sich die Anforderungen einer Hochrisiko-Infrastruktur erfüllen und die Änderung in kleine, einfach zu verwendende Batches aufteilen. 

Diese Links sind Beispiele dafür, wie nur die Sicherheits-Errata in einem Patch-Prozess angewendet werden können:

• Ist es möglich, yum so einzuschränken, dass nur Sicherheitsupdates aufgelistet oder installiert werden?
• Anwenden von Sicherheits-Errata von Red Hat Satellite

Eine weitere Strategie ist das Patchen von Teilmengen von Paketen, um das Änderungsrisiko noch weiter zu reduzieren. Dies ermöglicht auch die Flexibilität eines Rollbacks, falls Sie feststellen sollten, dass der Patch auf unerwartete Weise mit Ihrem System interagiert. Wie bei jeder Vorgehensweise müssen Sie sich der Kompromisse bewusst sein und diese auch verwalten. Dies mag für einige zu detailliert sein, während es bei anderen vielleicht besser zur Toleranz gegenüber Veränderungen passt.

2. In 10 Schritten zur Entwicklung einer Standardbetriebsumgebung (Standard Operating Environment, SOE)

Dieser Artikel enthält eine ausführliche Anleitung zur Verwendung von Red Hat Satellite beim Aktivieren und Verwalten einer Standardbetriebsumgebung. Jedes Thema wird sehr ausführlich behandelt und dient als Referenz für die Beantwortung der häufigsten Fragen zu Best Practices. Obwohl dieser Inhalt bereits vor einigen Jahren erstellt wurde, als Red Hat Satellite 6 eingeführt wurde, gelten seine grundlegenden Konzepte auch heute noch.

Content Management und Content Staging sind für den Patching-Prozess von größter Bedeutung. Diese Richtlinien bilden die Grundlage dafür, wie Patch-Inhalte der Infrastruktur präsentiert werden, und spielen im Patch-Prozess eine wichtige Rolle bei der Risikoverwaltung und -reduzierung.

Konzentrieren Sie sich besonders auf die Lifecycle-Umgebungen und Inhaltsansichten von Satellite. Dies sind wichtige Konzepte für das Staging von Inhalten und ihr Hochstufen (oder Rollback) in der Infrastruktur.

Konzentrieren Sie sich außerdem auf Organisationen, Speicherorte und Host-Gruppen, um Infrastruktur und Inventar zu klassifizieren. Viel zu oft sehe ich, dass bei Lifecycle-Umgebungen oder Inhaltsansichten zu detailliert vorgegangen wird und dabei versucht wird, diese Strukturen zur Klassifizierung von geografischen Standorten, Cloud-Umgebungen, ähnlichen Infrastrukturen oder verschiedenen Teams innerhalb einer Organisation zu verwenden.

3. Live Kernel-Patching

Live Kernel-Patching ist seit mehreren Jahren verfügbar und Teil mehrerer großer RHEL-Releases. Sie können einen Kernel ohne Neustart live patchen, um eine Schwachstelle sehr schnell zu beheben. Dies gibt Administratoren die Möglichkeit, Risiken sofort zu beheben, und die Gelegenheit, ein geeigneteres Wartungsfenster zu planen, in dem ein Neustart durchgeführt werden kann. 

Auch dies kann mit Red Hat Satellite orchestriert werden.

4. Identifizieren von Paketen, die nach einem Update einen Systemneustart erfordern

Je nach Update und Errata-Inhalt gibt es nach einem Patch möglicherweise keinen Grund für einen Neustart. Manchmal kann es ausreichend sein, einen Service nach einem Update neu zu starten, damit die aktualisierte Binärdatei verwendet werden kann. 

Ab RHEL 7 enthält yum-utils ein Plugin namens needs-restarting. Dieses Dienstprogramm meldet, ob nach der Anwendung von Patches ein Neustart erforderlich ist. Dies kann Ihnen dabei helfen, die Notwendigkeit von Änderungen in einem System zu verstehen und die Notwendigkeit, beim Patchen Neustarts durchzuführen, zu reduzieren.

Satellite verfügt außerdem über eine Funktion namens Tracer. Tracer erreicht dasselbe aus der Satellite-Perspektive, indem Administrationsteams Anwendungen identifizieren, die neu gestartet werden müssen, nachdem ein System gepatcht wurde.

5. Erwägen Sie, proaktiv ein Red Hat Support-Ticket zu öffnen

Wenn Sie über umfassende Kenntnisse zu einer bestimmten Wartungsaktivität verfügen und die Möglichkeit haben, im Voraus Informationen und Daten zu erfassen, können Sie Ausfallzeiten und Risiken im Zusammenhang mit dem Patching reduzieren.

Das proaktive Öffnen eines Support Cases kann die Fehlerbehebungszeit, die für die Wiederherstellung eines Services erforderlich ist, erheblich verkürzen und die Möglichkeit bieten, alle Verfahren oder Vorgehensweisen im Voraus zu überprüfen. Dies kann einen messbaren Einfluss auf die Reduzierung von Ausfällen und MTTR-Metriken (Mean Time to Recovery) haben.

6. Automatisieren!

Es ist kein Geheimnis, dass das Ersetzen manueller Schritte durch einen automatisierten Ansatz menschliche Fehler reduzieren, die Zuverlässigkeit erhöhen und den Patching-Prozess beschleunigen kann. Die Automatisierung ist ein wichtiges Unterscheidungsmerkmal bei der Einführung der für Ihre Organisation geeigneten Best Practices.

Red Hat Satellite kann die Remote-Ausführung mit Ansible nutzen. Red Hat Satellite kann Ansible Playbooks und Rollen über sein RHEL Inventory ausführen und Patching-Aktivitäten problemlos automatisieren und planen.

Mit der offiziellen Ansible-Collection redhat.satellite, die in Red Hat Ansible Automation Platform bereitgestellt wird, können Sie das gesamte Content Management von Satellite automatisieren und orchestrieren. Außerdem können Sie anschließend Patch-Inhalte nach dem Staging anwenden.

Um noch einen Schritt weiter zu gehen, gibt es Ansible-Module, mit denen Sie funktionale Tests für Webservices oder Serviceüberprüfungen durchführen können, nachdem Sie einen Patch angewendet haben.

Zusammenfassung

Red Hat hat das Dokument "Ein offener Ansatz zum Management von Schwachstellen" veröffentlicht, eine prägnante, aber umfassende Methodik, wie wir als Unternehmen mit dem Thema Schwachstellenmanagement umgehen. Risikomanagement ist eine Entscheidung, die Sie treffen müssen, nachdem Sie geschäftliche Einschränkungen, Auswirkungen und Ergebnisse berücksichtigt und abgewogen haben.

Die Frage ist: Sind alle Schwachstellen wirklich wichtig? Dieser Artikel beleuchtet einige der Realitäten und Kompromisse, die mit der Bewertung von Beschränkungen, Auswirkungen und Ergebnissen einhergehen. Dies ist ein gutes Beispiel für die Abwägung des Wunsches nach Ergebnissen gegen die Kosten und den Nutzen ihrer Erreichung. Zwar sollten sämtliche Risiken berücksichtigt werden, doch sollten nicht alle Risiken gleich bewertet werden. Außerdem verfügt niemand über unbegrenzte Ressourcen, um auf jedes Risiko eingehen zu können. In diesem Beispiel geht es darum, die wichtigsten Prioritäten zu setzen und über eine Strategie zu verfügen, um Risiken, deren Minderung sich lohnt, und Risiken, mit denen man bequem leben kann, entsprechend zu klassifizieren.

Einfach gesagt: Sie brauchen Iteration und Commitment. Keines der Beispiele in diesem Artikel war der erste Versuch einer Strategie. Die Strategien wurden immer wieder überprüft und weiterentwickelt, bis wir eine Balance beim Risikomanagement gefunden haben, die Red Hat gerecht wird. Außerdem werden diese Methoden ständig verfeinert, da wir Neues lernen und sich die Branchenlandschaft verändert. Es ist genauso wichtig, weiterhin die Risikotoleranz und -lage zu bewerten, wie von Anfang an über eine definierte Strategie zu verfügen. Es sind kontinuierliche Anpassung und Verbesserung, die die besten Strategien in Best Practices umwandeln.