Skalierbare Windows Patchverwaltung für virtuelle Computer

In diesem Artikel wird der empfohlene Ansatz für die Operationalisierung von Betriebssystemupdates auf Windows virtuellen Computern (VMs) in Ihrer Workload beschrieben. Der empfohlene Prozess bietet eine konsistente, skalierbare und geregelte Patchverwaltungslösung für die Windows VMs in Ihrer Workload. Es ermöglicht Ihnen, Updates in Vorproduktionsumgebungen zu überprüfen, bevor Sie sie für die Produktion bewerben.

Effektive Patchverwaltung erstreckt sich über die Installation von Updates hinaus. Eine Patchverwaltungsstrategie erfordert auch eine konsistente Governance, um sicherzustellen, dass VMs in die Patchverwaltungslösung integriert sind, gemäß Workloadstandards konfiguriert und kontinuierlich auf Compliance überwacht werden.

Azure Update Manager

Der empfohlene Ansatz zum Verwalten von Windows Betriebssystemupdates auf Azure Windows VMs ist die Verwendung von Update Manager. Dieser Dienst bietet zentralisierte Planungs- und Complianceberichte sowie die Möglichkeit, mehrstufige Betriebssystemupdatebereitstellungen für Ihre virtuellen Computer auszuführen. Update-Manager funktioniert über ein Sidecar Azure VM-Erweiterung, die auf jedem virtuellen Computer in Ihrer Workload installiert ist. Der Update-Manager hostet oder verteilt keine Patches selbst. Er steuert und aktiviert den systemeigenen Windows Update Agent (WUA) auf jedem virtuellen Computer.

Der Update-Manager bietet Ihrem Workloadteam eine zentrale Ansicht des Patchstatus von VMs in Ihrer Umgebung. Sie können Ihre Patchziele und -häufigkeiten festlegen und den Rollout von On-Demand-Patches aktivieren.

Azure Ressourcenorganisation

Der Update-Manager ist keine Azure Ressource. Sie stellen sie nicht in den Abonnements Ihrer Workload bereit. Es ist im Azure-Portal verfügbar, und die Erfahrung im Portal ist RBAC-basiert und abonnementunabhängig. Sie verwalten die Wartungskonfigurationen, welche Betriebssystempatches gelten, wenn sie patches sind, und die Zuordnung der Konfigurationen zu den virtuellen Computern Ihrer Workload als Azure Ressourcen.

Jede Wartungskonfiguration kann über einen einzelnen Zeitplan verfügen und eine beliebige Anzahl von Ressourcen über Zuordnungen ausrichten. Wartungskonfigurationen sind regionale Ressourcen. Verwenden Sie eine einzelne Wartungskonfiguration und einen Satz von Zuordnungen, um nur virtuelle Computer in derselben Region und im selben Abonnement einzuschließen. Wenn Sie diesen Ansatz verfolgen, verfügen Sie über separate Wartungskonfigurationsressourcen für alle Umgebungen und potenziell mehr als eine Ressource pro Umgebung, wenn Ihre Workload multiregion ist oder unterschiedliche Aktualisierungszeitpläne für verschiedene Teile der Workload aufweist.

Verwalten Sie Ihre Wartungskonfigurationsressourcen als Teil der IaC Ihrer Workload für diese Umgebung. Mit diesem Ansatz können Sie Änderungskontrollesprozesse und sichere Bereitstellungsmethoden durchführen und erhalten eine Notfallwiederherstellungsoption.

VM-Anforderungen

Die Windows-VMs müssen ein unterstütztes benutzerdefiniertes oder Azure Marketplace Image verwenden. Unabhängig von der Quelle müssen Sie das Betriebssystem so konfigurieren, dass Updates unterstützt werden. Die empfohlene Methode erfolgt über den IaC Ihrer VM, der die erforderlichen Betriebssystemeinstellungen konfiguriert. Stellen Sie insbesondere sicher, dass Ihre virtuellen Computer mindestens die folgenden Einstellungen haben:

windowsConfiguration: {
  provisionVMAgent: true
  enableAutomaticUpdates: true

  patchSettings: {
    patchMode: 'AutomaticByPlatform'  // Turns off automatic updates in the OS; now platform triggers updates
    assessmentMode: 'AutomaticByPlatform' // Scans for missing updates every 24 hours

    automaticByPlatformSettings: {
      bypassPlatformSafetyChecksOnUserSchedule: true  // Allows Azure Update Management to honor defined schedules
      rebootSetting: 'IfRequired'  // Or 'Never' if required in your workload
    }
  }
}

Der Windows-Gast-Agent installiert eine Sidecar-Erweiterung namens Microsoft.CPlat.Core.WindowsPatchExtension. Diese privilegierte Erweiterung wird auf Ihren virtuellen Computern ausgeführt, um die Zeitplan- und Updatekonfiguration abzurufen. Außerdem werden die systemeigenen Windows Betriebssystemupdate-APIs aufgerufen, um die Updates auszuführen. Sie definieren diese Erweiterung nicht als Teil Ihrer VM IaC. Der Update-Manager installiert es automatisch und verwaltet seinen Lebenszyklus.

Die WindowsPatchExtension-Erweiterung überschreibt die Einstellungen für die Updatequelle auf dem Computer nicht. Sie sind weiterhin für die Konfiguration der Updatequelle für Ihre virtuellen Computer verantwortlich:

• Das Windows Update Repository (Windows Betriebssystem und bestimmte Treiber)
• Das Microsoft Update-Repository (Windows Betriebssystem, bestimmte Treiber und bestimmte Microsoft Produkte)
• Wenn Ihre Organisation weiterhin Workloads für die Verwendung benötigt, ist ein Windows Server Update Services (WSUS)-Server (jetzt veraltet)

Ausführliche Informationen zu unterstützten Quellen finden Sie unter Unterstützte Updatequellen, Typen, Microsoft Anwendungsupdates und nicht Microsoft Updates.

Aktivieren Sie automatische Bewertungen, damit Ihre Complianceberichte aktuelle Daten widerspiegeln. Dieses Feature zeigt den Status jeder VM in Bezug auf Ihre Patchbasislinie an und hebt neu offenbarte Expositionen vor der nächsten geplanten Ausführung hervor. Die Bewertung deckt nur die Ausführung von virtuellen Computern ab. Beendete oder abgeglichene VMs werden nicht gescannt.

Durchsetzung von Richtlinien

Ihre Workload sollte auch Azure Policy verwenden, um zu erzwingen, dass Ihre virtuellen Computer für Update Manager ordnungsgemäß konfiguriert bleiben. Wenden Sie die integrierten Azure Update Manager-Richtlinien an, um Konfigurationsabweichungen zu verhindern. Die integrierten Richtlinien unterstützen DINE (deployIfNotExists) und ändern die Durchsetzung, um nicht kompatible VMs automatisch zu beheben.

Einen richtliniengesteuerten Ansatz für die Patchverwaltung finden Sie unter Aktivieren der regelmäßigen Bewertung und geplanten Patching auf Azure virtuellen Computern mithilfe einer Richtlinie. Verwenden Sie diesen Ansatz, wenn Ihre Workload IaC nicht zum Bereitstellen und Konfigurieren Ihrer virtuellen Computer verwendet.

Netzwerkanforderungen

Für Azure-VMs mit direktem ausgehendem Internetzugriff funktioniert Windows Update in der Regel ohne zusätzliche Freischaltungen im Netzwerk, sofern die Updatequelle des Gastbetriebssystems sowie DNS-, Proxy-, TLS-Inspektions- und lokale Richtlinieneinstellungen den Datenverkehr für Windows Update/Microsoft Update zulassen. Die meisten Workloads funktionieren jedoch in gesperrten virtuellen Netzwerken mit eingeschränktem ausgehendem Zugriff. In diesen Fällen müssen Sie den Datenverkehr für Microsoft Updateendpunkte in allen Netzwerksicherheitsgruppen und Firewalls zulassen, die Sie durchlaufen.

Netzwerksicherheitsgruppen

Standardmäßige Updatequellen, einschließlich Windows Update, sind DNS-basiert und veröffentlichen keine stabilen statischen IP-Listen. Daher muss für internetgehostete Updatequellen eine Netzwerksicherheitsgruppe, die an die NIC des virtuellen Computers oder sein Subnetz angefügt ist, den Internetausgangsdatenverkehr an TCP:443 und TCP:80 unterstützen. Sie sollten den Zugriff innerhalb Ihrer Ausgangsfirewall weiter einschränken. Wenn Ihre Updates aus einem statischen IP-Adressbereich (z. B. einer lokalen Quelle) stammen, sollten Sie dieses ausgehende Ziel explizit in Ihrer Netzwerksicherheitsgruppe definieren.

Ausgangsfirewall

Ihre Firewall für ausgehenden Datenverkehr muss den Datenverkehr zu den FQDNs zulassen, die von Ihrer Updatequelle verwendet werden. Wenn Sie Azure Firewall und eine Microsoft bereitgestellte Updatequelle verwenden, verwenden Sie das WindowsUpdate-FQDN-Tag, um ausgehenden Zugriff auf Windows Update Endpunkte zuzulassen. Informationen zum Konfigurieren anderer Ausgangsfirewalls in Ihrem Netzwerkpfad finden Sie unter Konfigurieren von Firewalls. Sie sollten diesen Datenverkehr nur zulassen, wenn er von Ihren Windows VMs stammt, nicht von nicht verwandten Subnetzen in Ihrer Workload.

Zuordnen von virtuellen Computern zu einer Wartungskonfiguration

Obwohl Sie statische Zuordnungen zwischen einer Wartungskonfiguration und Ihren virtuellen Computern erstellen können, verwenden Sie stattdessen dynamische Bereichsdefinitionen. Dynamische Bereiche bestimmen, welche virtuellen Computer der Wartungskonfiguration basierend auf Attributen wie Ressourcengruppe, Standort und Tags zugeordnet sind. Die Wartungskonfiguration, nicht der dynamische Bereich, definiert, welche Updates installiert sind und wann sie installiert werden. Die dynamische Bereichszuweisung bindet passende neue virtuelle Maschinen ein, ohne dass Sie Konfigurationszuordnungsressourcen pro VM verwalten müssen.

Wenn Sie dynamische Bereichsregeln verwenden, befolgen Sie die folgenden Empfehlungen:

• Verwalten Sie die dynamischen Bereichsregeln in IaC als Teil Ihrer Workload.
• Um umgebungsübergreifende Abhängigkeiten zu vermeiden, schließen Sie nur VMs aus Ihrer Umgebung ein, duplizieren konfiguration und dynamische Bereichsregeln bei Bedarf in allen Umgebungen.
• Verwenden Sie Tags als primären Mechanismus für die Zuordnung und erzwingen Sie ihre Verwendung mithilfe von Azure Policy.

Entwerfen eines mehrstufigen Patchingzeitplans

Ein typischer Patchingzeitplan für eine Workload verwendet mehrstufige Bereitstellungszeitpläne. Wenden Sie nach der monatlichen Microsoft Updateversion zuerst Updates auf Entwicklungs- und Test-VMs an. Nachdem Sie diese Updates überprüft haben, bewerben Sie die gleiche Klassifizierung von Updates für die Vorproduktion und dann die Produktion in separaten Wartungsfenstern.

Erstellen Sie Wartungskonfigurationen, um die Wiederholung, das Wartungsfenster, die Updateklassifizierungen und das Neustartverhalten zu definieren. Erstellen Sie dann Ihre dynamische Bereichszuordnung für VMs in Ihrer Workload, um Ihren Routinepatchingzeitplan auszuführen.

Ein am Patch dienstags ausgerichteter Zeitplan ermöglicht in der Regel ein paar Tage vor der Produktionsbereitstellung eine Überprüfung. Da Microsoft monatlichen Sicherheitsupdates im Allgemeinen am zweiten Dienstag jedes Monats veröffentlicht werden, kann ein vorgeschlagener Ansatz wie folgt aussehen. In diesem Beispiel werden die Ziel-VMs über eine dynamische Bereichsdefinitionsregel verwaltet, die Tags verwendet.

Gleichzeitigkeit von Aktualisierungen behandeln

Eine Wartungskonfiguration startet Updates für alle zugehörigen virtuellen Computer gleichzeitig. Azure serialisiert Neustarts nach Updatedomäne nur für VMs in einem allgemeinen Verfügbarkeitssatz. Die Backend- und Frontend-Wellen in diesem Beispiel staffeln den Zeitplan nach Tier, nicht nach redundanter Kapazität, sodass alle Instanzen in einem Tier gleichzeitig neu gestartet werden könnten und dieses Tier dadurch unter die erforderliche Kapazität fallen könnte.

Teilen Sie innerhalb jeder Produktionsebene Patching in Kapazitätsaufbewahrungswellen auf, die an Ihren Verfügbarkeitszonen, Aktualisierungsdomänen oder workloaddefinierte Instanzengruppen ausgerichtet sind. Verwenden Sie pro Welle einen separaten Tag-Wert und eine separate Wartungskonfiguration.

Berücksichtigen Sie die Konsistenz beim Rollout

Der Update-Manager führt bei jedem Durchlauf eine erneute Überprüfung durch. Klassifizierungsbasierte Zeitpläne können daher Updatepakete auswählen, die einem anderen Knowledge Base -Artikel (KB) in späteren Wellen zugeordnet sind. Wenn jede Welle den genau validierten Updatesatz installieren muss, konfigurieren Sie explizite KB-Einschlüsse, anstatt sich nur auf Klassifizierungen zu verlassen.

Sie können diese Konfiguration automatisieren, indem Sie die Update Manager-REST-API verwenden, um die Bewertungsergebnisse aus der ersten Welle abzufragen und dann die Wartungskonfiguration für nachfolgende Wellen zu aktualisieren.

Der Kompromiss, den Sie machen, um eine vollständige Wellenkonsistenz zu erzielen, ist eine erhebliche Orchestrierungskomplexität. Wenn Ihre Workload das Risiko einer späteren Welle bei der Installation eines anderen Updatepakets als die erste Welle tolerieren kann, verwenden Sie den klassifizierungsbasierten Zeitplan.

Reduzieren Sie Neustarts mit Hotpatching

Neustarts sind häufig der störendste Teil eines Patching-Zeitplans. Sie bestimmen die Wartungsfenstergrößen und das Neustartverhalten in der vorherigen Tabelle. Bei unterstützten Images installiert Hotpatching Windows Sicherheitsupdates, indem der Speichercode der ausgeführten Prozesse gepatcht wird, sodass Updates für die meisten Monate ohne Neustart gelten. Hotpatch ist eine Erweiterung von Windows Update, sodass Update Manager Hotpatches mithilfe der gleichen Wartungskonfigurationen und dynamischen Bereichsdefinitionen installiert, die Sie für Ihre anderen virtuellen Computer verwenden.

Wenn Ihre Workload empfindlich gegenüber Neustarts ist, verwenden Sie eine Betriebssystem-SKU und ein Design, die Hotpatching unterstützen:

• Hotpatch ist nur für bestimmte Windows Bilder verfügbar. Sie können hotpatch für ein beliebiges benutzerdefiniertes Bild nicht aktivieren.
• Nur Windows-Sicherheitsupdates werden per Hotpatch aktualisiert. Nicht sicherheitsrelevante Updates, .NET Updates und Treiber- oder Firmwareupdates erfordern in den Monaten, in denen sie veröffentlicht werden, weiterhin einen Neustart. Vierteljährliche Hotpatch-Baselineupdates und alle ungeplanten Baselineupdates, die Microsoft für einen Zero-Day-Fix herausgibt, erfordern ebenfalls einen Neustart. Behalten Sie ein Wartungsfenster bei, das einen Neustart aufnehmen kann.

Behandeln von "Before"- und "After"-Bedenken

Update-Manager bewertet und installiert Betriebssystemupdates, aber ein erfolgreicher Patchvorgang kann Aktivitäten vor und nach dem Wartungsfenster umfassen, um erforderliche Neustarts oder anwendungsspezifische Bedenken ordnungsgemäß zu behandeln. Der Update-Manager stellt Vorabereignisse und Ereignisse bereit , die Sie in der Automatisierung Ihrer Workload verwenden können. Sie fügen der Architektur Ihrer Workload einen Ereignishandler wie eine Azure-Funktion hinzu. Der Ereignishandler reagiert auf Azure Event Grid Benachrichtigungen vor und nach der geplanten Patchausführung.

Verwenden Sie update Manager-Vorpatchingaktivitäten, um Aufgaben wie die folgenden auszuführen:

• Starten Sie eine gestoppte oder freigegebene VM. Beendete oder deallocierte VMs können nicht gepatcht werden und werden übersprungen.
• Stellen Sie sicher, dass Sicherungswiederherstellungspunkte verfügbar sind.
• Überprüfen sie den Virtuellen Computer und den Anwendungsstatus.
• Unterdrücken Sie vorübergehend Überwachungswarnungen, um falsch positive Ergebnisse während des Wartungsfensters zu verhindern.

Verwenden Sie nach der Installation von Updates Aktivitäten nach dem Patchen, um Aufgaben wie die folgenden auszuführen:

• Überwachung wiederherstellen.
• Führen Sie Anwendungs- und Dienstintegritätsprüfungen aus.
• Posten Sie eine Benachrichtigung an einen Microsoft Teams Kanal.

Behandeln Sie das Ereignisraster und den Ereignishandler als Arbeitsauslastungsressourcen. Stellen Sie sie mit IaC bereit, und isolieren Sie sie zwischen Umgebungen.

Vorbereiten von On-Demand-Updates

Update Manager unterstützt die On-Demand-Patchinstallation außerhalb eines geplanten Wartungsfensters. Dieses Feature eignet sich für das Anwenden von Notfallpatches oder kritischen Out-of-Cycle-Fixes oder zum Überprüfen des Patchverhaltens auf einer einzelnen VM vor einem größeren geplanten Rollout. Sie können On-Demand-Updates direkt über das Azure-Portal oder die Update-Manager-REST-API für mindestens einen virtuellen Computer gleichzeitig auslösen. Das Workloadteam sollte Richtlinien festlegen, wann ein Out-of-Band-Update durchgeführt wird und wie dieser Prozess in Ihrer Workload koordiniert wird.

Updates zurücksetzen

Update-Manager stellt kein Betriebssystempatchrollback bereit. Nachdem Sie Patches angewendet haben, gibt es keinen integrierten Mechanismus, um sie direkt über den Update-Manager zu deinstallieren.

Wenn Ihre Arbeitsauslastung einen "letzten als gut bekannten" Zustand unterstützen muss, erstellen Sie eine Momentaufnahme oder einen Wiederherstellungspunkt, bevor eine Wartungsausführung ausgeführt wird. Automatisieren Sie die Erstellung von Snapshots, sodass sie vor jedem Patch-Zeitfenster ausgeführt wird, damit vor dem Anwenden von Patches immer ein Wiederherstellungspunkt vorhanden ist. Alternativ können Sie den virtuellen Computer ohne Patch erneut bereitstellen, den problematischen KB-Patch aus der Bereitstellung ausschließen und die Updates erneut anwenden.

Compliance-Berichterstattung

Update Manager verschiebt sowohl Bewertungs- als auch Patchinstallationsergebnisse an Azure Resource Graph, wodurch ausstehende Updates für 7 Tage und Installationsergebnisse für 30 Tage gespeichert werden. Der Update-Manager enthält integrierte Complianceberichts- und Verwaltungsansichten, die Einen Einblick in den Updatestatus in Ihrer gesamten Umgebung bieten. Diese Dashboards ermöglichen Es Administratoren, die Patchcompliance zu überwachen, Computer zu identifizieren, die Aufmerksamkeit erfordern, und den Updatebereitstellungsfortschritt von einem zentralen Standort aus nachzuverfolgen.

Die vordefinierten Arbeitsmappen enthalten wichtige Informationen über Ihre Arbeitsauslastung:

• Eine allgemeine Zusammenfassung des Computerstatus und der Konfiguration
• Eine Aufschlüsselung ausstehender Updates nach Schweregrad und Klassifizierung
• Eine Zusammenfassung der Zeitpläne, Wartungskonfigurationen und der computer, die jedem Zeitplan zugeordnet sind
• Eine historische Ansicht früherer Installationsausführungen, einschließlich Erfolgsraten und Fehlern

Viele Organisationen benötigen ihre Anwendungsteams, um Complianceberichte bereitzustellen. Im Idealfall verwendet Ihre Organisation den Update-Manager bereits für diese Nachverfolgung, da die Update-Manager-Portaloberfläche und Arbeitsmappen über Abonnementgrenzen hinweg funktionieren können, und Sie müssen keine benutzerdefinierten Patchstatusberichte in Ihrer Workload bereitstellen.

Wenn Sie oder Ihre Organisation benutzerdefinierte Berichte über die vordefinierten Ansichten hinaus benötigen, können Sie Arbeitsmappen anpassen. Fügen Sie angepasste Arbeitsmappen in die IaC-Dateien Ihrer Workload ein, um einen Änderungskontrollesprozess anzuwenden und eine Notfallwiederherstellungsoption bereitzustellen. Eine Alternative besteht darin, die erforderlichen Complianceberichtsdaten über Resource Graph-Abfragen bereitzustellen.

Wenn Ihre Arbeitsauslastung den Patchverlauf länger aufbewahren muss, als Resource Graph sie beibehält, erstellen Sie einen Prozess zum Exportieren der Daten in einen von Ihnen gesteuerten Speicher.

Alternativer Ansatz

Wenn Sie den geplanten, mehrstufigen Update-Manager-Ansatz für Ihre Workload nicht übernehmen möchten, bewerten Sie die automatische VM-Gastpatching , bevor Sie eine benutzerdefinierte Lösung entwerfen. Wenn Sie diese Option verwenden, Azure das Patchen für Sie koordiniert. Wenn Sie diesen Ansatz verwenden, geben Sie jedoch die folgenden Vorteile auf:

• Gestaffelte Einführung. Updates durchlaufen keine Entwicklungs-, Test- und Produktionsphasen, sodass Validierungskontrollen entfallen.
• Steuerung des Wartungsfensters. Azure bestimmt, wann Patching außerhalb der Spitzenzeiten in der Zeitzone jeder VM ausgeführt wird.
• Klassifizierungssteuerung aktualisieren. Es werden nur kritische und Sicherheitsupdates angewendet. Andere Updates werden nicht automatisch installiert.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• Tedman Lee | Senior Solution Engineer

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Erfahren Sie, wie Der Update-Manager funktioniert.
• Grenzwerte für Wartungskonfigurationen: Überprüfen Sie die Grenzwerte für Zeitpläne, Ressourcenzuordnungen und dynamische Bereiche.
• Planen Sie die Ausführungsreihenfolge mit Vor- und Nachereignissen: Verstehen Sie die Anzeigedauerfenster und das Abbruchverhalten für Vorereignisse und Ereignisse, sodass Sie genügend Vorlaufzeit für jedes Wartungsfenster zulassen.