Vordefinierte und benutzerdefinierte Patch-Baselines
Patch Manager, eine Funktion von AWS Systems Manager, stellt vordefinierte Patch-Baselines für jedes der von Patch Manager unterstützten Betriebssysteme bereit. Sie können diese Baselines in ihrer aktuellen Konfiguration verwenden (eine Anpassung ist nicht möglich) oder eigene benutzerdefinierte Patch-Baselines erstellen. Benutzerdefinierte Patch-Baselines ermöglichen Ihnen eine bessere Kontrolle darüber, welche Patches für Ihre Umgebung genehmigt oder abgelehnt werden. Außerdem weisen die vordefinierten Baselines allen Patches, die mit diesen Baselines installiert wurden, die Compliance-Ebene Unspecified zu. Für die Zuweisung von Compliance-Werten können Sie eine Kopie einer vordefinierten Baseline erstellen und die Compliance-Werte angeben, die Patches zugewiesen werden sollen. Weitere Informationen erhalten Sie unter Benutzerdefinierte Baselines und Arbeiten mit benutzerdefinierten Patch-Baselines.
Anmerkung
Die Informationen in diesem Thema gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihren Patching-Vorgang verwenden:
-
Eine in Quick Setup konfigurierte Patch-Richtlinie
-
Eine in Quick Setup konfigurierte Host-Management-Option
-
Ein Wartungsfenster zum Ausführen eines Patch-
Scanoder einerInstall-Aufgabe -
Ein On-Demand-Jetzt patchen-Vorgang
Vordefinierte Baselines
Die folgende Tabelle beschreibt die mit Patch Manager bereitgestellten vordefinierten Patch-Baselines.
Informationen dazu, welche Versionen der einzelnen Betriebssysteme von Patch Manager unterstützt werden, finden Sie unter Patch Manager-Voraussetzungen.
| Name | Unterstütztes Betriebssystem | Details |
|---|---|---|
|
|
Alma/Linux |
Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
|
|
Amazon Linux 1 |
Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem automatisch alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
AWS-AmazonLinux2DefaultPatchBaseline |
Amazon Linux 2 | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden automatisch sieben Tage nach der Veröffentlichung genehmigt.¹ |
AWS-AmazonLinux2022DefaultPatchBaseline |
Amazon Linux 2022 |
Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Patches werden automatisch sieben Tage nach der Veröffentlichung genehmigt. Genehmigt außerdem alle Patches mit einer Klassifizierung „Bugfix“ sieben Tage nach der Veröffentlichung. |
AWS-AmazonLinux2023DefaultPatchBaseline |
Amazon Linux 2023 |
Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Patches werden automatisch sieben Tage nach der Veröffentlichung genehmigt. Genehmigt außerdem alle Patches mit einer Klassifizierung „Bugfix“ sieben Tage nach der Veröffentlichung. |
AWS-CentOSDefaultPatchBaseline |
CentOS und CentOS Stream | Genehmigt alle Aktualisierungen sieben Tage nach ihrer Verfügbarkeit, einschließlich nicht sicherheitsrelevanter Aktualisierungen. |
AWS-DebianDefaultPatchBaseline |
Debian Server | Genehmigt sofort alle sicherheitsrelevanten Patches für Betriebssysteme mit der Priorität „Required“, „Important“, „Standard“, „Optional“ oder „Extra“. Die Genehmigung erfolgt unverzüglich, weil in den Repositorys keine zuverlässigen Datumsangaben zur Veröffentlichung verfügbar sind. |
AWS-MacOSDefaultPatchBaseline |
macOS | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“. Genehmigt auch alle Pakete mit einem aktuellen Update. |
AWS-OracleLinuxDefaultPatchBaseline |
Oracle Linux | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Important“ oder „Moderate“. Genehmigt außerdem alle als „Bugfix“ eingestuften Patches 7 Tage nach Veröffentlichung. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
AWS-DefaultRaspbianPatchBaseline |
Raspberry Pi OS | Genehmigt sofort alle sicherheitsrelevanten Patches für Betriebssysteme mit der Priorität „Required“, „Important“, „Standard“, „Optional“ oder „Extra“. Die Genehmigung erfolgt unverzüglich, weil in den Repositorys keine zuverlässigen Datumsangaben zur Veröffentlichung verfügbar sind. |
|
|
Red Hat Enterprise Linux (RHEL) |
Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
|
|
Rocky Linux |
Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
AWS-SuseDefaultPatchBaseline |
SUSE Linux Enterprise Server (SLES) | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
|
|
Ubuntu Server |
Genehmigt sofort alle sicherheitsrelevanten Patches für Betriebssysteme mit der Priorität „Required“, „Important“, „Standard“, „Optional“ oder „Extra“. Die Genehmigung erfolgt unverzüglich, weil in den Repositorys keine zuverlässigen Datumsangaben zur Veröffentlichung verfügbar sind. |
AWS-DefaultPatchBaseline |
Windows Server |
Genehmigt alle Windows Server-Betriebssystem-Patches mit der Klassifizierung „CriticalUpdates“ oder „SecurityUpdates“ und dem MSRC-Schweregrad „Critical“ oder „Important“. Patches werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.² |
AWS-WindowsPredefinedPatchBaseline-OS |
Windows Server |
Genehmigt alle Windows Server-Betriebssystem-Patches mit der Klassifizierung „CriticalUpdates“ oder „SecurityUpdates“ und dem MSRC-Schweregrad „Critical“ oder „Important“. Patches werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.² |
AWS-WindowsPredefinedPatchBaseline-OS-Applications |
Windows Server | Genehmigt alle Windows Server-Betriebssystem-Patches mit der Klassifizierung „CriticalUpdates“ oder „SecurityUpdates“ und dem MSRC-Schweregrad „Critical“ oder „Important“. Genehmigt für von Microsoft veröffentlichte Anwendungen alle Patches. Patches für Betriebssysteme und Anwendungen werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.² |
¹ Für Amazon Linux 1 und Amazon Linux 2 wird die 7-Tage-Wartezeit, bevor Patches automatisch genehmigt werden, aus einem Updated Date-Wert in updateinfo.xml und nicht aus einem Release Date-Wert berechnet. Verschiedene Faktoren können den Updated Date-Wert beeinflussen. Andere Betriebssysteme behandeln Veröffentlichungs- und Aktualisierungsdaten unterschiedlich. Informationen dazu, wie Sie unerwartete Ergebnisse durch Verzögerungen bei der automatischen Genehmigung vermeiden können, finden Sie unter So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet.
² Für Windows Server enthalten die Standard-Baselines eine Verzögerung von 7 Tagen für die automatische Genehmigung. Um einen Patch innerhalb von 7 Tagen nach der Veröffentlichung zu installieren, müssen Sie eine benutzerdefinierte Baseline erstellen.
Benutzerdefinierte Baselines
Mithilfe der folgenden Informationen können Sie benutzerdefinierte Patch-Baselines erstellen, um Ihre Patching-Ziele zu erreichen.
Themen
Automatische Genehmigungen in benutzerdefinierten Baselines verwenden
Wenn Sie eine eigene Patch-Baseline herstellen, können Sie die Patches wahlweise automatisch genehmigen, indem Sie die folgenden Kategorien verwenden.
-
Betriebssystem: Windows Server, Amazon Linux, Ubuntu Server usw.
-
Produktname (für Betriebssysteme): Beispielsweise RHEL 6.5, Amazon Linux 2014.09, Windows Server 2012, Windows Server 2012 R2 usw.
-
Produktname (nur für von Microsoft auf Windows Server veröffentlichte Anwendungen): Beispielsweise Word 2016, BizTalk Server usw.
-
Klassifizierung: Beispielsweise kritische Updates, Sicherheitsupdates usw.
-
Schweregrad: Beispielsweise kritisch, wichtig usw.
Für jede von Ihnen erstellte Genehmigungsregel können Sie eine Verzögerung für die automatische Genehmigung oder ein Stichdatum für die Patch-Genehmigung angeben.
Anmerkung
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.
Eine Verzögerung der automatischen Genehmigung ist die Anzahl an Tagen, die gewartet werde soll, nachdem die Patch veröffentlicht oder zuletzt aktualisiert wurde, bevor der Patch automatisch genehmigt wird. Wenn Sie beispielsweise eine Regel mit der CriticalUpdates-Klassifizierung erstellen und für sie für eine Verzögerung der automatischen Genehmigung von sieben Tagen konfigurieren, wird ein neuer kritischer Patch, der am 7. Juli veröffentlicht wird, am 14. Juli automatisch genehmigt.
Wenn ein Linux-Repository keine Informationen zum Veröffentlichungsdatum von Paketen bereitstellt, verwendet Systems Manager die den Buildzeitpunkt des Pakets für Festlegung der Verzögerung bis zur automatischen Genehmigung für Amazon Linux 1, Amazon Linux 2, RHEL und CentOS. Wenn das System nicht in der Lage ist, den Buildzeitpunkt des Pakets zu ermitteln, verwendet Systems Manager für die Festlegung der Verzögerung bis zur automatischen Genehmigung den Wert Null.
Wenn Sie ein Stichdatum für die automatische Genehmigung angeben, wendet Patch Manager automatisch alle Patches an, die an oder vor diesem Datum veröffentlicht oder zuletzt aktualisiert wurden. Wenn Sie beispielsweise den 07. Juli 2023 als Stichtag angeben, werden keine Patches automatisch installiert, die an oder nach dem 08. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden.
Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für Patches, die von dieser Patch-Baseline genehmigt wurden, einen Schweregrad für die Konformität angeben, beispielsweise Critical oder High. Wenn der Patch-Status eines genehmigten Patches als Missing gemeldet wird, dann ist der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline der von Ihnen angegebene Schweregrad.
Zusätzliche Informationen zum Erstellen von Patch-Baselines
Beachten Sie bei der Erstellung einer Patch-Baseline Folgendes:
-
Patch Manager stellt eine vordefinierte Patch-Baseline für jedes unterstützte Betriebssystem bereit. Diese vordefinierten Patch-Baselines werden als Standard-Patch-Baselines für alle Betriebssystemtypen verwendet, wenn Sie nicht eigene Patch-Baselines erstellen und diese als Standard für den jeweiligen Betriebssystemtyp festlegen.
Anmerkung
Für Windows Server werden drei vordefinierte Patch-Baselines bereitgestellt. Die Patch-Baselines
AWS-DefaultPatchBaselineundAWS-WindowsPredefinedPatchBaseline-OSunterstützen nur Betriebssystemupdates auf dem Windows-Betriebssystem selbst.AWS-DefaultPatchBaselinewird als Standard-Patch-Baseline für von Windows Server verwalteten Knoten verwendet, es sei denn, Sie geben eine andere Patch-Baseline an. Die Konfigurationseinstellungen in diesen beiden Patch-Baselines sind identisch. Die neuere der beiden,AWS-WindowsPredefinedPatchBaseline-OS, wurde erstellt, um sie von der dritten vordefinierten Patch-Baseline für Windows Server zu unterscheiden. Diese Patch-Baseline,AWS-WindowsPredefinedPatchBaseline-OS-Applications, kann verwendet werden, um Patches sowohl auf das Windows Server-Betriebssystem als auch auf unterstützte Anwendungen, die von Microsoft veröffentlicht wurden, anzuwenden. -
Standardmäßig entfernen Windows Server 2019 und Windows Server 2022 Updates, die durch spätere Updates ersetzt werden. Wenn Sie also den
ApproveUntilDate-Parameter in einer Windows Server-Patch-Baseline verwenden, das imApproveUntilDate-Parameter ausgewählte Datum jedoch vor dem Datum des neuesten Patches liegt, wird der neue Patch nicht installiert, wenn der Patching-Vorgang ausgeführt wird. Weitere Informationen zu Windows Server-Patching-Regeln, finden Sie in der Registerkarte Windows Server in Wie Sicherheitspatches ausgewählt werden.Das bedeutet, dass der verwaltete Knoten die Anforderungen des Systems-Manager-Betriebs erfüllt, auch wenn ein kritischer Patch aus dem Vormonat möglicherweise nicht installiert wurde. Das gleiche Szenario kann bei Verwendung des
ApproveAfterDays-Parameters auftreten. Aufgrund des Verhaltens von Microsoft bei abgelösten Patches ist es möglich, eine Zahl (im Allgemeinen größer als 30 Tage) festzulegen, sodass Patches für Windows Server nie installiert werden, wenn der neueste verfügbare Patch von Microsoft veröffentlicht wird, bevor die Anzahl der Tage inApproveAfterDaysverstrichen ist. -
Bei On-Premises-Servern und virtuellen Maschinen (VMs) versucht Patch Manager, Ihre benutzerdefinierte Standard-Patch-Baseline zu verwenden. Wenn keine benutzerdefinierte Standard-Patch-Baseline vorhanden ist, verwendet das System die vordefinierte Patch-Baseline für das entsprechende Betriebssystem.
-
Wenn ein Patch sowohl als genehmigt als auch als abgelehnt aufgelistet ist, wird der Patch abgelehnt.
-
Für einen verwalteten Knoten kann nur eine einzige Patch-Baseline definiert werden.
-
Die Formate der Paketnamen, die Sie zu den Listen der genehmigten und abgelehnten Patches für eine Patch-Baseline hinzufügen können, hängen von der Art des Betriebssystems ab, das gepatcht wird.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen.
Wenn Sie eine Patch-Richtlinienkonfiguration in Quick Setup verwenden, werden Aktualisierungen, die Sie an benutzerdefinierten Patch-Baselines vornehmen, einmal pro Stunde mit Quick Setup synchronisiert.
Wenn eine benutzerdefinierte Patch-Baseline gelöscht wird, auf die in einer Patch-Richtlinie verwiesen wurde, wird auf der Seite mit den Quick Setup-Konfigurationsdetails ein Banner für Ihre Patch-Richtlinie angezeigt. Das Banner informiert Sie darüber, dass die Patch-Richtlinie auf eine nicht mehr vorhandene Patch-Baseline verweist und nachfolgende Patching-Vorgänge fehlschlagen werden. Kehren Sie in diesem Fall zur Seite Quick Setup-Konfigurationen zurück, wählen Sie die Patch Manager-Konfiguration aus und wählen Sie Aktionen, Konfiguration bearbeiten. Der Name der gelöschten Patch-Baseline wird hervorgehoben, und Sie müssen eine neue Patch-Baseline für das betroffene Betriebssystem auswählen.
Informationen zum Erstellen einer Patch-Baseline finden Sie unter Arbeiten mit benutzerdefinierten Patch-Baselines und Anleitung: Patchen einer Serverumgebung mithilfe der AWS CLI.
