• Das AWS Systems Manager CloudWatch Dashboard wird nach dem 30. April 2026 nicht mehr verfügbar sein. Kunden können weiterhin die CloudWatch Amazon-Konsole verwenden, um ihre CloudWatch Amazon-Dashboards anzusehen, zu erstellen und zu verwalten, so wie sie es heute tun. Weitere Informationen finden Sie in der [Amazon CloudWatch Dashboard-Dokumentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# So funktionieren Patch Manager-Operationen
<a name="patch-manager-patching-operations"></a>

Dieser Abschnitt enthält technische Details, die erklären, wie Patch Manager, ein Tool in AWS Systems Manager, bestimmt, welche Patches installiert werden und wie er sie auf dem jeweiligen unterstützten Betriebssystem installiert. Für Linux-Betriebssysteme enthält er auch Informationen zur Angabe einer Quell-Repository, in einer benutzerdefinierten Patch-Baseline, für andere Patches als diejenigen, die standardmäßig auf einem verwalteten Knoten konfiguriert sind. Dieser Abschnitt bietet außerdem Informationen darüber, wie Patch-Baseline-Regeln auf verschiedenen Verteilungen des Linux-Betriebssystems funktionieren.

**Anmerkung**  
Die Informationen in den folgenden Themen gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihre Patching-Vorgänge verwenden:  
Eine in Quick Setup konfigurierte Patch-Richtlinie
Eine in Quick Setup konfigurierte Host-Management-Option
Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
Ein On-Demand-**Jetzt patchen**-Vorgang

**Topics**
+ [So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet](patch-manager-release-dates.md)
+ [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md)
+ [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md)
+ [Wie Patches installiert werden](patch-manager-installing-patches.md)
+ [Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen](patch-manager-linux-rules.md)
+ [Unterschiede beim Patchvorgang zwischen Linux und Windows Server](patch-manager-windows-and-linux-differences.md)

# So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet
<a name="patch-manager-release-dates"></a>

**Wichtig**  
Die Informationen auf dieser Seite beziehen sich auf Amazon-Linux-2 und Amazon-Linux-2023-Betriebssysteme (OS) für Amazon Elastic Compute Cloud (Amazon EC2)-Instances. Die Pakete für diese Betriebssystemtypen werden von Amazon Web Services erstellt und verwaltet. Wie die Hersteller anderer Betriebssysteme ihre Pakete und Repositorys verwalten, wirkt sich darauf aus, wie ihre Veröffentlichungs- und Aktualisierungsdaten berechnet werden. OSs Neben Amazon Linux 2 und Amazon Linux 2023 finden Sie in der Dokumentation des Herstellers Informationen darüberRed Hat Enterprise Linux, wie ihre Pakete aktualisiert und gewartet werden.

In den Einstellungen für [benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom), die Sie für die meisten Betriebssystemtypen erstellen, können Sie angeben, dass Patches nach einer bestimmten Anzahl von Tagen automatisch für die Installation genehmigt werden. AWS bietet mehrere vordefinierte Patch-Baselines, die automatische Genehmigungsdaten von 7 Tagen enthalten.

Eine *Verzögerung der automatischen Genehmigung* ist die Anzahl an Tagen, die gewartet werde soll, nachdem die Patch veröffentlicht wurde, bevor der Patch automatisch genehmigt wird. Beispielsweise erstellen Sie eine Regel mit der `CriticalUpdates`-Klassifizierung und konfigurieren sie für eine Verzögerung der automatischen Genehmigung um sieben Tage. Infolgedessen wird ein neuer kritischer Patch mit einem Veröffentlichungsdatum oder dem letzten Aktualisierungsdatum vom 7. Juli automatisch am 14. Juli genehmigt.

Um unerwartete Ergebnisse mit Verzögerungen bei der automatischen Genehmigung auf Amazon Linux 2 und Amazon Linux 2023 zu vermeiden, ist es wichtig zu wissen, wie die Veröffentlichungs- und Aktualisierungsdaten berechnet werden.

**Anmerkung**  
Wenn ein Amazon Linux 2- oder Amazon Linux 2023-Repository keine Informationen zum Veröffentlichungsdatum von Paketen bereitstellt, verwendet Patch Manager die Erstellungszeit des Pakets als Datum zur automatischen Genehmigung der Datumsangaben. Wenn die Erstellungszeit des Pakets nicht bestimmt werden kann, verwendet Patch Manager als Standarddatum den 1. Januar 1970. Dies führt dazu, dass alle Angaben zum Datum der automatischen Genehmigung in Patch-Baselines von Patch Manager umgangen werden, die so konfiguriert sind, dass Patches für jedes Datum nach dem 1. Januar 1970 genehmigt werden.

In den meisten Fällen wird die Wartezeit für die automatische Genehmigung vor der Installation von Patches aus einem `Updated Date`-Wert in `updateinfo.xml` und nicht aus einem `Release Date`-Wert berechnet. Im Folgenden finden Sie wichtige Details zu diesen Datumsberechnungen: 
+ Das `Release Date` ist das Datum, an dem ein *Hinweis* veröffentlicht wird. Dies bedeutet nicht, dass das Paket bereits in den zugehörigen Repositorys verfügbar ist. 
+ Das `Update Date` ist das letzte Datum, an dem der Hinweis aktualisiert wurde. Eine Aktualisierung eines Hinweises kann etwas so Kleines wie eine Text- oder Beschreibungsaktualisierung darstellen. Dies bedeutet nicht, dass das Paket ab diesem Datum veröffentlicht wurde oder notwendigerweise in den zugehörigen Repositorys verfügbar ist. 

  Dies bedeutet, dass ein Paket einen `Update Date`-Wert vom 7. Juli haben kann, aber erst (zum Beispiel) am 13. Juli für die Installation verfügbar sein kann. Angenommen, in diesem Fall wird am 14. Juli in einem `Install`-Vorgang eine Patch-Baseline ausgeführt, die eine 7-tägige automatische Genehmigungsverzögerung angibt. Da der `Update Date`-Wert sieben Tage vor dem Ausführungsdatum liegt, werden die Patches und Updates im Paket am 14. Juli installiert. Die Installation erfolgt, obwohl erst ein Tag vergangen ist, seit das Paket für die eigentliche Installation verfügbar ist.
+ Ein Paket, das Betriebssystem- oder Anwendungs-Patches enthält, kann nach der ersten Veröffentlichung mehrmals aktualisiert werden.
+ Ein Paket kann in den AWS verwalteten Repositorys veröffentlicht, dann aber zurückgesetzt werden, wenn später Probleme damit entdeckt werden.

Bei einigen Patch-Vorgängen sind diese Faktoren möglicherweise nicht wichtig. Wenn beispielsweise eine Patch-Baseline so konfiguriert ist, dass ein Patch mit den Schweregraden `Low` und `Medium` und der Klassifizierung `Recommended` installiert wird, kann jede Verzögerung der automatischen Genehmigung nur geringe Auswirkungen auf Ihren Betrieb haben.

In Fällen, in denen das Timing kritischer Patches oder Patches mit hohem Schweregrad wichtiger ist, sollten Sie möglicherweise mehr Kontrolle darüber haben, wann Patches installiert werden. Die empfohlene Methode hierfür ist die Verwendung alternativer Patch-Quell-Repositorys anstelle der Standard-Repositorys für Patch-Vorgänge auf einem verwalteten Knoten. 

Sie können beim Erstellen einer benutzerdefinierten Patch-Baseline alternative Patch-Quell-Repositorys angeben. Für jede benutzerdefinierte Patch-Baseline können Sie Patch-Quellkonfigurationen für bis zu 20 Versionen eines unterstützten Linux-Betriebssystems angeben. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).

# Wie Sicherheitspatches ausgewählt werden
<a name="patch-manager-selecting-patches"></a>

Das Hauptaugenmerk vonPatch Manager, einem Tool in AWS Systems Manager, liegt auf der Installation sicherheitsrelevanter Betriebssystemupdates auf verwalteten Knoten. Standardmäßig installiert Patch Manager daher nicht alle verfügbaren Patches, sondern eher eine kleinere Reihe von Patches mit Schwerpunkt auf der Sicherheit.

Standardmäßig ersetzt Patch Manager kein Paket, das in einem Paket-Repository mit Ersatzpaketen als veraltet markiert wurde mit Ersatzpaketen mit anderen Namen, es sei denn, dieser Ersatz ist für die Installation eines anderen Paket-Updates erforderlich. Stattdessen meldet und installiert Patch Manager bei Befehlen, die ein Paket aktualisieren, nur fehlende Updates für das Paket, das installiert wird, aber veraltet ist. Dies liegt daran, dass das Ersetzen eines veralteten Pakets normalerweise die Deinstallation eines vorhandenen Pakets und die Installation des Ersatzpakets erfordert. Durch das Ersetzen des veralteten Pakets könnten grundlegende Änderungen oder zusätzliche Funktionen eingeführt werden, die Sie nicht beabsichtigt hatten.

Dieses Verhalten entspricht dem `update-minimal`-Befehl von YUM und DNF, der sich eher auf Sicherheitsupdates als auf Feature-Updates konzentriert. Weitere Informationen finden Sie unter [Wie Patches installiert werden](patch-manager-installing-patches.md).

**Anmerkung**  
Wenn Sie den `ApproveUntilDate` Parameter oder `ApproveAfterDays` Parameter in einer Patch-Baseline-Regel verwenden, werden die Veröffentlichungsdaten von Patches anhand der koordinierten Weltzeit (UTC) Patch Manager ausgewertet.   
Wenn Sie beispielsweise ein Datum angeben`ApproveUntilDate`, werden Patches`2025-11-16`, die zwischen `2025-11-16T00:00:00Z` und veröffentlicht wurden`2025-11-16T23:59:59Z`, genehmigt.   
Beachten Sie, dass die Veröffentlichungsdaten von Patches, die von systemeigenen Paketmanagern auf Ihren verwalteten Knoten angezeigt werden, je nach der lokalen Zeitzone Ihres Systems unterschiedliche Zeiten anzeigen können. Für Genehmigungsberechnungen wird jedoch Patch Manager immer die UTC-Datum/Uhrzeit verwendet. Dadurch wird die Konsistenz mit den auf offiziellen Websites mit Sicherheitshinweisen veröffentlichten Patch-Veröffentlichungsdaten gewährleistet.

Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches melden, verwendet Patch Manager den vom Softwareherausgeber gemeldeten Schweregrad für den Update-Hinweis oder den einzelnen Patch. Patch Manager leitet keinen Schweregrad aus Drittquellen wie dem [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) oder aus Metriken ab, die von der [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD) veröffentlicht werden.

**Anmerkung**  
Auf allen Linux-basierten Systemen, die von Patch Manager unterstützt werden, können Sie ein anderes für den verwalteten Knoten konfiguriertes Quell-Repository auswählen, typischerweise zur Installation von nicht-sicherheitsrelevanten Updates. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).

Wählen Sie aus den folgenden Registerkarten, um zu erfahren, wie Patch Manager sicherheitsrelevante Patches für Ihr Betriebssystem auswählt.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

Vorkonfigurierte Repositorys werden auf Amazon Linux 2 anders behandelt als auf Amazon Linux 2023.

Auf Amazon Linux 2 verwendet der Patch-Baseline-Server des Systems Managers vorkonfigurierte Repositorys auf dem verwalteten Knoten. Es gibt in der Regel zwei vorkonfigurierte Repositorys (Repos) auf einem Knoten:

**Auf Amazon Linux 2**
+ **Repo-ID**: `amzn2-core/2/architecture`

  **Repo-Name**: `Amazon Linux 2 core repository`
+ **Repo-ID**: `amzn2extra-docker/2/architecture`

  **Repo-Name**: `Amazon Extras repo for docker`

**Anmerkung**  
*architecture*kann x86\$164 oder (für Graviton-Prozessoren) aarch64 sein.

Wenn Sie eine Amazon Linux 2023 (AL2023) -Instance erstellen, enthält sie die Updates, die in der von AMI Ihnen ausgewählten Version AL2023 und spezifischen Version verfügbar waren. Ihre AL2023 Instance erhält beim Start nicht automatisch zusätzliche kritische und wichtige Sicherheitsupdates. Stattdessen können Sie mit der Unterstützung der Funktion *deterministische Upgrades durch versionierte Repositorys* AL2023, die standardmäßig aktiviert ist, Updates nach einem Zeitplan anwenden, der Ihren spezifischen Anforderungen entspricht. Weitere Informationen finden Sie unter [Deterministische Upgrades durch versionierte Repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) im *Benutzerhandbuch von Amazon Linux 2023*. 

Bei aktivierter AL2023 Option sieht das vorkonfigurierte Repository wie folgt aus:
+ **Repo-ID**: `amazonlinux`

  **Repository-Name**: Amazon-Linux-2023-Repository

Bei Amazon Linux 2023 (Vorschauversion) sind die vorkonfigurierten Repositories an *gesperrte Versionen* von Paket-Updates gebunden. Wenn new Amazon Machine Images (AMIs) für veröffentlicht AL2023 werden, sind sie an eine bestimmte Version gebunden. Bei Patch-Aktualisierungen ruft Patch Manager die letzte gesperrte Version des Patch-Aktualisierungs-Repositorys ab und aktualisiert dann die Pakete auf dem verwalteten Knoten basierend auf dem Inhalt dieser gesperrten Version.

**Paket-Manager**  
Amazon Linux 2 verwaltete Knoten verwenden YUM als Paket-Manager. Amazon Linux 2023 verwendet DNF als Paket-Manager. 

Beide Paket-Manager verwenden das Konzept einer *Aktualisierungsbenachrichtigung* in Form einer Datei mit dem Namen `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Alle Pakete in einem Update-Hinweis werden von Patch Manager als sicherheitsrelevant betrachtet. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Daher weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu.

**Anmerkung**  
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.  
Weitere Informationen zur Option **Nicht sicherheitsrelevante Updates einbeziehen** finden Sie unter [Wie Patches installiert werden](patch-manager-installing-patches.md) und [Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen](patch-manager-linux-rules.md).

------
#### [  CentOS Stream ]

Der Patch-Baseline-Service des Systems Managers auf CentOS Stream verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Die folgende Liste enthält Beispiele für ein fiktives CentOS 9.2 Amazon Machine Image (AMI):
+ **Repo-ID**: `example-centos-9.2-base`

  **Repo-Name**: `Example CentOS-9.2 - Base`
+ **Repo-ID**: `example-centos-9.2-extras` 

  **Repo-Name**: `Example CentOS-9.2 - Extras`
+ **Repo-ID**: `example-centos-9.2-updates`

  **Repo-Name**: `Example CentOS-9.2 - Updates`
+ **Repo-ID**: `example-centos-9.x-examplerepo`

  **Repo-Name**: `Example CentOS-9.x – Example Repo Packages`

**Anmerkung**  
Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.

CentOS Stream-Knoten verwenden DNF als Paket-Manager. Der Paket-Manager verwenden das Konzept eines Update-Hinweises. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. 

Standard-Repos von CentOS Stream werden jedoch nicht mit einem Update-Hinweis konfiguriert. Das bedeutet, dass Patch Manager Pakete auf einem Standard-CentOS Stream-Repos nicht erkennt. Um Patch Manager für die Verarbeitung von Paketen, die nicht in einem Update-Hinweis enthalten sind, zu aktivieren, müssen Sie die `EnableNonSecurity`-Markierung in den Patch-Baseline-Regeln aktivieren.

**Anmerkung**  
CentOS Stream-Update-Hinweise werden unterstützt. Repos mit Update-Hinweisen können nach dem Start heruntergeladen werden.

------
#### [ Debian Server ]

Der Systems Manager-Patch-Baseline-Service auf Debian Server verwendet vorkonfigurierte Repositorys (Repos) auf der Instance. Diese vorkonfigurierten Repos werden verwendet, um eine aktualisierte Liste der verfügbaren Paket-Upgrades abzurufen. Dazu führt Systems Manager das Äquivalent eines `sudo apt-get update`-Befehls durch. 

Pakete werden dann aus `debian-security codename`-Repos gefiltert. Das bedeutet, dass für jede Version von Debian Server, Patch Manager nur Upgrades identifiziert, die Teil des zugehörigen Repositorys für diese Version sind, und zwar wie folgt:
+  Debian Server11: `debian-security bullseye`
+ Debian Server12: `debian-security bookworm`

------
#### [ Oracle Linux ]

Der Patch-Baseline-Service des Systems Managers auf Oracle Linux verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Es gibt in der Regel zwei vorkonfigurierte Repositorys (Repos) auf einem Knoten.

**Oracle Linux 7**:
+ **Repo-ID**: `ol7_UEKR5/x86_64`

  **Repo-Name**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **Repo-ID**: `ol7_latest/x86_64`

  **Repo-Name**: `Oracle Linux 7Server Latest (x86_64)` 

**Oracle Linux 8**:
+ **Repo-ID**: `ol8_baseos_latest` 

  **Repo-Name**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **Repo-ID**: `ol8_appstream`

  **Repo-Name**: `Oracle Linux 8 Application Stream (x86_64)` 
+ **Repo-ID**: `ol8_UEKR6`

  **Repo-Name**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`

**Oracle Linux 9**:
+ **Repo-ID**: `ol9_baseos_latest` 

  **Repo-Name**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **Repo-ID**: `ol9_appstream`

  **Repo-Name**: `Oracle Linux 9 Application Stream Packages(x86_64)` 
+ **Repo-ID**: `ol9_UEKR7`

  **Repo-Name**: `Oracle Linux UEK Release 7 (x86_64)`

**Anmerkung**  
Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.

Von Oracle Linux verwaltete Knoten verwenden Yum als Paketmanager und Yum verwendet das Konzept eines Update-Hinweises in Form einer Datei namens `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Aus diesem Grund weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu und installiert Pakete basierend auf den Klassifizierungsfiltern, die in der Patch-Baseline angegeben sind.

**Anmerkung**  
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

Ein AlmaLinuxRed Hat Enterprise Linux, und Rocky Linux der Systems Manager Patch Baseline Service verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Es gibt in der Regel drei vorkonfigurierte Repositorys (Repos) auf einem Knoten.

Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.

**Anmerkung**  
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.

Red Hat Enterprise Linux7 verwaltete Knoten verwenden Yum als Paketmanager. AlmaLinux, Red Hat Enterprise Linux 8, und Rocky Linux verwaltete Knoten verwenden DNF als Paketmanager. Beide Paketmanager verwenden das Konzept eines Update-Hinweises als Datei namens `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Aus diesem Grund weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu und installiert Pakete basierend auf den Klassifizierungsfiltern, die in der Patch-Baseline angegeben sind.

RHEL 7  
Das folgende Repo ist mit IDs RHUI 2 verknüpft. RHUI 3 wurde im Dezember 2019 veröffentlicht und führte ein anderes Benennungsschema für das Yum-Repository ein. IDs Abhängig von dem RHEL-7-AMI, aus dem Sie Ihre verwalteten Knoten erstellen, müssen Sie möglicherweise Ihre Befehle aktualisieren. Weitere Informationen finden Sie unter [Repository IDs for RHEL 7 in Have AWS Changed](https://access.redhat.com/articles/4599971) im *Red Hat* Customer Portal.
+ **Repo-ID**: `rhui-REGION-client-config-server-7/x86_64`

  **Repo-Name**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **Repo-ID**: `rhui-REGION-rhel-server-releases/7Server/x86_64`

  **Repo-Name**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **Repo-ID**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`

  **Repo-Name**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`

AlmaLinux, 8, RHEL 8 und Rocky Linux 8  
+ **Repo-ID**: `rhel-8-appstream-rhui-rpms`

  **Repo-Name**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **Repo-ID**: `rhel-8-baseos-rhui-rpms`

  **Repo-Name**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **Repo-ID**: `rhui-client-config-server-8`

  **Repo-Name**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`

AlmaLinux 9, RHEL 9 und Rocky Linux 9  
+ **Repo-ID**: `rhel-9-appstream-rhui-rpms`

  **Repo-Name**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **Repo-ID**: `rhel-9-baseos-rhui-rpms`

  **Repo-Name**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **Repo-ID**: `rhui-client-config-server-9`

  **Repo-Name**: `Red Hat Enterprise Linux 9 Client Configuration`

------
#### [ SLES ]

Auf von SUSE Linux Enterprise Server (SLES) verwalteten Knoten erhält die ZYPP-Bibliothek die Liste der verfügbaren Patches (eine Sammlung von Paketen) von den folgenden Standorten:
+ Liste der Repositorys: `etc/zypp/repos.d/*`
+ Paketinformationen: `/var/cache/zypp/raw/*`

Von SLES verwaltete Knoten verwenden Zypper als Paketmanager und Zypper verwendet das Konzept eines Patches. Ein Patch ist einfach eine Sammlung von Paketen, die ein bestimmtes Problem beheben. Patch Manager behandelt alle Pakete, auf die in einem Patch verwiesen wird, als sicherheitsbezogen. Da einzelnen Paketen weder Klassifizierungen noch Schweregrade zugewiesen werden, weist Patch Manager den Paketen die Attribute des Patches zu, dem sie angehören.

------
#### [ Ubuntu Server ]

Der Patch-Baseline-Service des Systems Managers auf Ubuntu Server verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Diese vorkonfigurierten Repos werden verwendet, um eine aktualisierte Liste der verfügbaren Paket-Upgrades abzurufen. Dazu führt Systems Manager das Äquivalent eines `sudo apt-get update`-Befehls durch. 

Pakete werden dann aus `codename-security`-Repos gefiltert, wobei der Codename für die Release-Version eindeutig ist, z. B. `trusty` für Ubuntu Server 14. Patch Manager identifiziert nur Upgrades, die Teil dieser Repos sind: 
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)

------
#### [ Windows Server ]

Unter Microsoft Windows-Betriebssystemen ruft Patch Manager eine Liste der verfügbaren, von Microsoft über Microsoft Update veröffentlichten und automatisch auf Windows Server Update Services (WSUS) verfügbaren Updates ab.

**Anmerkung**  
Patch Manager stellt nur dann Patches für Windows Server-Betriebssystemversionen bereit, wenn diese für Patch Manager unterstützt werden. Beispiel: Patch Manager kann nicht zum Patchen von Windows RT verwendet werden.

Patch Manager überwacht kontinuierlich neue Updates in allen AWS-Region. Die Liste der verfügbaren Updates wird in jeder Region mindestens einmal pro Tag aktualisiert. Wenn die Patch-Informationen von Microsoft verarbeitet werden, entfernt Patch Manager Updates, die durch spätere Updates ersetzt wurden, aus der Patch-Liste. Daher werden nur die neuesten Updates angezeigt und zur Installation zur Verfügung gestellt. Beispiel: Wenn `KB4012214` `KB3135456` ersetzt, steht nur `KB4012214` als Update in Patch Manager zur Verfügung.

Ebenso kann Patch Manager nur Patches installieren, die zum Zeitpunkt des Patchvorgangs auf dem verwalteten Knoten verfügbar sind. Standardmäßig entfernen Windows Server 2019 und Windows Server 2022 Updates, die durch spätere Updates ersetzt werden. Wenn Sie den `ApproveUntilDate`-Parameter in einer Windows Server-Patch-Baseline verwenden, das im `ApproveUntilDate`-Parameter ausgewählte Datum jedoch *vor dem* Datum des letzten Patches liegt, tritt das folgende Szenario ein:
+ Der ersetzte Patch wurde vom Knoten entfernt und kann daher nicht mit Patch Manager installiert werden.
+ Der neueste Ersatz-Patch ist auf dem Knoten vorhanden, wurde aber zum angegebenen Datum noch nicht für die `ApproveUntilDate`-Installation freigegeben. 

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 in `ApproveAfterDays` verstrichen ist. Beachten Sie, dass dieses Systemverhalten nicht zutrifft, wenn Sie Ihre Einstellungen für das Windows-Gruppenrichtlinienobjekt (GPO) so geändert haben, dass der abgelöste Patch auf Ihren verwalteten Knoten verfügbar ist.

**Anmerkung**  
In einigen Fällen veröffentlicht Microsoft Patches für Anwendungen, die kein aktualisiertes Datum und keine aktualisierte Uhrzeit angeben. In diesen Fällen wird ein aktualisiertes Datum und eine Uhrzeit von `01/01/1970` standardmäßig angegeben.

------

# So geben Sie ein alternatives Patch-Quell-Repository an (Linux)
<a name="patch-manager-alternative-source-repository"></a>

Wenn Sie die auf einem verwalteten Knoten konfigurierten Standardrepositorys für Patch-Operationen verwenden Patch Manager AWS Systems Manager, sucht ein Tool in nach sicherheitsrelevanten Patches oder installiert diese. Dies ist das Standardverhalten für Patch Manager. Ausführliche Informationen darüber, wie Patch Manager Sicherheits-Patches auswählt und installiert, finden Sie unter [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md).

Sie können auf Linux-Systemen jedoch auch mithilfe von Patch Manager Patches installieren, die nicht auf Sicherheit bezogen sind oder die sich in einem anderen als dem Standard-Quell-Repository befinden, das in dem verwalteten Knoten konfiguriert ist. Sie können beim Erstellen einer benutzerdefinierten Patch-Baseline alternative Patch-Quell-Repositorys angeben. Für jede benutzerdefinierte Patch-Baseline können Sie Patch-Quellkonfigurationen für bis zu 20 Versionen eines unterstützten Linux-Betriebssystems angeben. 

Angenommen, Ihre Ubuntu Server-Flotte beinhaltet Ubuntu Server 25.04-verwaltete Knoten. In diesem Fall können Sie alternative Repositorys für jede Version in derselben benutzerdefinierten Patch-Baseline angeben. Geben Sie für jede Version einen Namen, die Version und den Typ des Betriebssystems (Produkt) und eine Repository-Konfiguration an. Sie können auch ein einziges alternatives Quell-Repository angeben, das für alle Versionen eines unterstützten Betriebssystems gilt.

**Anmerkung**  
Wenn Sie eine benutzerdefinierte Patch-Baseline ausführen, die alternative Patch-Repositorys für einen verwalteten Knoten angeben, werden diese Repositorys dadurch nicht zum neuen Standard-Repository auf dem Betriebssystem. Nach Abschluss der Patching-Operation bleiben die zuvor definierten Standard-Repositorys für das Betriebssystem des Knoten als Standard erhalten.

Eine Liste mit Beispielszenarien zur Verwendung dieser Option finden Sie weiter [Anwendungsbeispiele für alternative Patch-Quell-Repositorys](#patch-manager-alternative-source-repository-examples) unten in diesem Thema.

Weitere Informationen zu Standard- und benutzerdefinierten Patch-Baselines finden Sie unter [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md).

**Beispiel: Verwenden der Konsole**  
Um alternative Patch-Quell-Repositorys anzugeben, wenn Sie in der Systems Manager-Konsole arbeiten, verwenden Sie den Abschnitt **Patch sources** auf der Seite **Create patch baseline**. Weitere Informationen zur Verwendung der Optionen in **Patch sources (Patch-Quellen)** finden Sie unter [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md).

**Beispiel: Verwendung des AWS CLI**  
Ein Beispiel für die Verwendung der Option `--sources` mit der AWS Command Line Interface (AWS CLI) finden Sie in [Erstellen einer Patch-Baseline mit benutzerdefinierten Repositorys für verschiedene Betriebssystemversionen](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).

**Topics**
+ [Wichtige Überlegungen für alternative Repositorys](#alt-source-repository-important)
+ [Anwendungsbeispiele für alternative Patch-Quell-Repositorys](#patch-manager-alternative-source-repository-examples)

## Wichtige Überlegungen für alternative Repositorys
<a name="alt-source-repository-important"></a>

Beachten Sie die folgenden Punkte, wenn Sie planen, in Ihrer Patching-Strategie alternative Patch-Repositorys zu verwenden.

**Erzwingen Sie Überprüfungen von Repo-Updates (YUM und DNF)**  
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution kann so eingestellt sein, dass ein nicht erreichbares Paket-Repository übersprungen wird, wenn keine Verbindung zum Repository hergestellt werden kann. Um die Überprüfung des Repository-Updates `skip_if_unavailable=False` zu erzwingen, fügen Sie es der Repository-Konfiguration hinzu.

Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).

**Nur angegebene Repositorys werden für das Einspielen von Patches verwendet.**  
Angeben von alternativen Repositorys bedeutet nicht das Angeben *zusätzlicher* Repositorys. Sie können wählen, andere Repositorys als die auf einem verwalteten Knoten als Standardwerte konfigurierten festzulegen. Sie müssen jedoch auch die Standard-Repositorys als Teil der alternativen Patch-Quell-Konfiguration angeben, wenn Sie möchten, dass deren Updates übernommen werden.

Beispielsweise sind die Standard-Repositorys auf von Amazon Linux 2 verwalteten Knoten `amzn2-core` und `amzn2extra-docker`. Wenn Sie das Repository "Extra Packages for Enterprise Linux (EPEL)" in Ihre Patching-Operationen einschließen möchten, müssen Sie alle drei Repositorys als alternative Repositorys angeben.

**Anmerkung**  
Wenn Sie eine benutzerdefinierte Patch-Baseline ausführen, die alternative Patch-Repositorys für einen verwalteten Knoten angeben, werden diese Repositorys dadurch nicht zum neuen Standard-Repository auf dem Betriebssystem. Nach Abschluss der Patching-Operation bleiben die zuvor definierten Standard-Repositorys für das Betriebssystem des Knoten als Standard erhalten.

**Das Patching-Verhalten für YUM-basierte Distributionen hängt vom updateinfo.xml-Manifest ab**  
Wenn Sie alternative Patch-Repositorys für YUM-basierte Distributionen festlegen, z. B. Amazon Linux 2 oder Red Hat Enterprise Linux, hängt das Patching-Verhalten davon ab, ob das Repository ein Update-Manifest in Form einer vollständig und korrekt formatierten `updateinfo.xml`-Datei enthält. Diese Datei gibt das Release-Datum, Klassifizierungen und Schweregrade der verschiedenen Pakete an. Jede der folgenden Optionen wirkt sich auf das Patching-Verhalten aus:
+ Wenn Sie nach **Klassifizierung** und **Schweregrad** filtern, diese aber nicht in `updateinfo.xml` angegeben sind, wird das Paket nicht in Filter aufgenommen. Dies bedeutet auch, dass Pakete ohne eine `updateinfo.xml`-Datei werden nicht in das Patching eingeschlossen werden.
+ Wenn Sie nach filtern **ApprovalAfterDays**, aber das Veröffentlichungsdatum des Pakets nicht im Format Unix Epoch ist (oder kein Veröffentlichungsdatum angegeben ist), wird das Paket nicht in den Filter aufgenommen.
+ Eine Ausnahme besteht, wenn Sie das Kontrollkästchen **Genehmigte Patches umfassen nicht sicherheitsrelevante Updates** auf der Seite **Patch-Baseline erstellen** aktivieren. In diesem Fall *werden* Pakete ohne eine `updateinfo.xml`-Datei (oder die diese Datei ohne ordnungsgemäß formatierte Werte für **Klassifizierung**, **Schweregrad** und **Datum** enthalten) in die vorgefilterte Liste der Patches aufgenommen. (Diese müssen nach wie vor die übrigen Anforderungen Patch-Baseline Regel erfüllen, damit sie installiert werden.)

## Anwendungsbeispiele für alternative Patch-Quell-Repositorys
<a name="patch-manager-alternative-source-repository-examples"></a>

**Beispiel 1: Nicht sicherheitsrelevante Updates für Ubuntu Server**  
Sie verwenden bereitsPatch Manager, um Sicherheitspatches auf einer Flotte von Ubuntu Server verwalteten Knoten mithilfe der von AWS Ihnen bereitgestellten vordefinierten Patch-Baseline zu installieren. `AWS-UbuntuDefaultPatchBaseline` Sie können eine neue Patch-Baseline erstellen, die auf diesem Standard basiert, aber in den Genehmigungsregeln angeben, dass nicht auf die Sicherheit bezogene Updates, die Teil der Standardverteilung sind, ebenfalls installiert werden sollen. Wenn diese Patch-Baseline für Ihre Knoten ausgeführt wird, werden sowohl sicherheitsbezogene als auch nicht-sicherheitsbezogene Patches angewendet. Sie können auch auswählen, dass nicht sicherheitsbezogene Patches in den Patch-Ausnahmen, die Sie für eine Baseline angeben, genehmigt werden.

**Beispiel 2: Personal Package Archives (PPA) für Ubuntu Server**  
Auf Ihren von Ubuntu Server verwalteten Knoten wird Software ausgeführt, die über ein [Personal Package Archives (PPA) für Ubuntu](https://launchpad.net/ubuntu/+ppas) verteilt wird. In diesem Fall erstellen Sie eine Patch-Baseline, die ein PPA-Repository angibt, das Sie auf dem verwalteten Knoten als das Quell-Repository für die Patch-Operation konfiguriert haben. Führen Sie anschließend mithilfe von Run Command das Patch-Baseline-Dokument auf den Knoten aus.

**Beispiel 3: Interne Firmenanwendungen in unterstützten Amazon-Linux-Versionen**  
Sie müssen auf Ihren von Amazon Linux verwalteten Knoten einige Anwendungen ausführen, die für die Compliance gesetzlicher Vorschriften und Branchenstandards erforderlich sind. Sie können ein Repository für diese Anwendungen auf den Knoten konfigurieren, mit YUM die Anwendungen erstmals installieren und eine neue Patch-Baseline aktualisieren oder erstellen, um dieses neue Unternehmens-Repository hinzuzufügen. Anschließend können Sie mit Run Command das Dokument `AWS-RunPatchBaseline` mit der Option `Scan` ausführen, um zu prüfen, ob das Unternehmenspaket unter den installierten Paketen aufgelistet und auf dem verwalteten Knoten aktuell ist. Wenn es nicht aktuell ist, können Sie das Dokument mithilfe der Option `Install` erneut ausführen, um die Anwendungen zu aktualisieren. 

# Wie Patches installiert werden
<a name="patch-manager-installing-patches"></a>

Patch Manager, ein Tool in AWS Systems Manager, verwendet den im Betriebssystem integrierten Paketmanager, um Updates auf verwalteten Knoten zu installieren. Beispielsweise verwendet es die Windows Update API `DNF` auf Windows Server und unter Amazon Linux 2023. Patch Manager berücksichtigt bestehende Paketmanager- und Repository-Konfigurationen auf den Knoten, einschließlich Einstellungen wie Repository-Status URLs, Spiegelung, GPG-Überprüfung und Optionen wie`skip_if_unavailable`.

Patch Manager installiert kein neues Paket, das ein veraltetes Paket ersetzt, das derzeit installiert ist. (Ausnahmen: Das neue Paket hängt davon ab, ob ein anderes Paket-Update installiert wird, oder das neue Paket hat denselben Namen wie das veraltete Paket.) Stattdessen meldet und installiert Patch Manager verfügbare Updates für installierte Pakete. Dieser Ansatz trägt dazu bei, unerwartete Änderungen an der Systemfunktionalität zu verhindern, die auftreten können, wenn ein Paket ein anderes ersetzt.

Wenn Sie ein veraltetes Paket deinstallieren und dessen Ersatz installieren müssen, müssen Sie möglicherweise ein benutzerdefiniertes Skript verwenden oder Paket-Manager-Befehle außerhalb der Standardvorgänge von Patch Manager verwenden.

Wählen Sie aus den folgenden Registerkarten, um zu erfahren, wie Patch Manager Patches auf einem Betriebssystem installiert.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

Auf von Amazon Linux 2 und Amazon Linux 2023 verwalteten Knoten sieht der Workflow der Patch-Installation wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Die YUM-Aktualisierungs-API (Amazon Linux 2) oder die DNF-Aktualisierungs-API (Amazon Linux 2023) wird wie folgt auf genehmigte Patches angewendet:
   + Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, werden nur die in `updateinfo.xml` angegebenen Patches angewendet (nur Sicherheitsupdates). Dies liegt daran, dass das Kontrollkästchen **Funktionsupdates einschließen** nicht aktiviert ist. Die vordefinierten Baselines entsprechen einer benutzerdefinierten Baseline mit folgenden Eigenschaften:
     + Das Kontrollkästchen **Funktionsupdates einschließen** ist nicht aktiviert
     + Eine Liste des SCHWEREGRADE von `[Critical, Important]`
     + Eine Liste der KLASSIFIZIERUNGEN von `[Security, Bugfix]`

     Für Amazon Linux 2 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt:

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     Für Amazon Linux 2023 lautet der entsprechende DNF-Befehl für diesen Workflow wie folgt:

     ```
     sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```

     Wenn das Kontrollkästchen **Funktionsupdates einschließen** aktiviert ist, werden alle Patches angewendet (Sicherheits- und Funktionsupdates), die in `updateinfo.xml` und nicht in `updateinfo.xml` sind.

     Für Amazon Linux 2, wenn eine Baseline mit **Funktionsupdates einschließen** ausgewählt ist, und die eine SCHWEREGRAD-Liste von `[Critical, Important]` und eine KLASSIFIKATION-Liste von `[Security, Bugfix]` hat, lautet der entsprechende YUM-Befehl:

     ```
     sudo yum update --security --sec-severity=Critical,Important --bugfix -y
     ```

     Für Amazon Linux 2023 lautet der entsprechende DNF-Befehl wie folgt:

     ```
     sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```
**Anmerkung**  
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.

**Zusätzliche Patchdetails für Amazon Linux 2023**  
Support für den Schweregrad „Keine“  
Amazon Linux 2023 unterstützt auch den Patch-Schweregrad `None`, der vom DNF-Paket-Manager erkannt wird.   
Support für den Schweregrad „Mittel“  
Für Amazon Linux 2023 entspricht ein Patch-Schweregrad von `Medium` einem Schweregrad von `Moderate`, der möglicherweise in einigen externen Repositorys definiert ist. Wenn Sie Patches mit dem `Medium`-Schweregrad in die Patch-Baseline aufnehmen, werden auch Patches mit dem `Moderate`-Schweregrad von externen Patches auf den Instances installiert.  
Wenn Sie Konformitätsdaten mit der API-Aktion [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) abfragen, werden beim Filtern nach dem Schweregrad `Medium` Patches mit den Schweregraden `Medium` und `Moderate` gemeldet.  
Transitive Abhängigkeitsbehandlung für Amazon Linux 2023  
Für Amazon Linux 2023 installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).   
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die ** neuesten verfügbaren Versionen derselben transitiven Abhängigkeiten.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**Anmerkung**  
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution könnte so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.  
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).

------
#### [ CentOS Stream ]

Auf von CentOS Stream verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

   Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Das DNF-Update auf CentOS Stream wird auf genehmigte Patches angewendet.
**Anmerkung**  
Für CentOS Stream installiert Patch Manager möglicherweise andere Versionen transitiver Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).   
`dnf upgrade-minimal ‐‐security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Debian Server ]

Auf Debian Server-Instances sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren. 
**Anmerkung**  
Da es nicht möglich ist, die Veröffentlichungstermine von Update-Paketen für Debian Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
**Anmerkung**  
Für Debian Server sind Patch-Kandidaten-Versionen auf Patches beschränkt, die in `debian-security` enthalten sind.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Die APT-Bibliothek wird verwendet, um Upgrades für Pakete durchzuführen.
**Anmerkung**  
Patch Manager unterstützt nicht die Verwendung der `Pin-Priority`-APT-Option, um Paketen Prioritäten zuzuweisen. Patch Manager aggregiert verfügbare Updates aus allen aktivierten Repositorys und wählt das neueste Update aus, das der Baseline für jedes installierte Paket entspricht.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ macOS ]

Auf von macOS verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Die `/Library/Receipts/InstallHistory.plist`-Eigenschaft ist ein Datensatz der Software, die mit den `softwareupdate`- und `installer`-Paketmanagern installiert und aktualisiert wurde. Unter Verwendung der`pkgutil`-Befehlszeilen-Tool (für `installer`) und des `softwareupdate`-Paketmanagers werden CLI-Befehle ausgeführt, um diese Liste zu analysieren. 

   Für `installer` umfasst die Antwort auf die CLI-Befehle Details zu `package name`, `version`, `volume`, `location` und `install-time`, aber nur der `package name` und die `version` werden von Patch Manager verwendet.

   Für `softwareupdate` umfasst die Antwort auf die CLI-Befehle den Paketnamen (`display name`),`version` und`date`, aber nur der Paketname und die Version werden vom Patch Manager verwendet.

   Für Brew and Brew Cask unterstützt Homebrew seine Befehle, die unter dem Root-Benutzer ausgeführt werden, nicht. Darum fragt Patch Manager entweder als Eigentümer des Homebrew-Verzeichnisses oder als gültiger Benutzer,der zur Eigentümergruppe des Homebrew-Verzeichnisses gehört, Homebrew–Befehle ab und führt sie aus. Die Befehle sind ähnlich wie `softwareupdate` und `installer` und werden durch einen Python-Subprozess ausgeführt, um Paketdaten zu sammeln. Die Ausgabe wird dann analysiert, um Paketnamen und -versionen zu identifizieren.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Ruft die entsprechende Paket-CLI auf dem verwalteten Knoten auf, um genehmigte Patches wie folgt zu verarbeiten:
**Anmerkung**  
`installer` fehlt die Funktion, um nach Updates zu suchen und sie zu installieren. Daher meldet Patch Manager für `installer` nur, welche Pakete installiert sind. Das Ergebnis: `installer`-Pakete werden nie als `Missing` gemeldet.
   + Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, und für benutzerdefinierte Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *nicht* ausgewählt wurde, werden nur Sicherheitsupdates angewendet.
   + Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Sicherheits- als auch Funktionsupdates angewendet.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Oracle Linux ]

Auf von Oracle Linux verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Auf von Version 7 verwalteten Knoten wird die YUM-Update-API wie folgt auf genehmigte Patches angewendet:
   + Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, und für benutzerdefinierte Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *nicht* ausgewählt wurde, werden nur Patches, die in `updateinfo.xml` angegeben sind (nur Sicherheitsupdates), angewendet.

     Der entsprechende Yum-Befehl für diesen Workflow lautet:

     ```
     sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
     ```
   + Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Patches aus der Datei `updateinfo.xml` als auch solche, die nicht in `updateinfo.xml` enthalten sind, angewendet (sowohl Sicherheits- als auch Funktionsupdates).

     Der entsprechende Yum-Befehl für diesen Workflow lautet:

     ```
     sudo yum update --security --bugfix -y
     ```

     Auf von Version 8 und 9 verwalteten Knoten wird die DNF-Update-API wie folgt auf genehmigte Patches angewendet:
     + Für vordefinierte Standard-Patch-Baselines, die von bereitgestellt werden AWS, und für benutzerdefinierte Patch-Baselines, bei denen das Kontrollkästchen **Nicht sicherheitsrelevante Updates einbeziehen** *nicht* aktiviert ist, `updateinfo.xml` werden nur die in angegebenen Patches angewendet (nur Sicherheitsupdates).

       Der entsprechende Yum-Befehl für diesen Workflow lautet:

       ```
       sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
       ```
**Anmerkung**  
Für Oracle Linux installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).   
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.
     + Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Patches aus der Datei `updateinfo.xml` als auch solche, die nicht in `updateinfo.xml` enthalten sind, angewendet (sowohl Sicherheits- als auch Funktionsupdates).

       Der entsprechende Yum-Befehl für diesen Workflow lautet:

       ```
       sudo dnf upgrade --security --bugfix
       ```
**Anmerkung**  
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**Anmerkung**  
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution kann so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.  
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

Auf AlmaLinuxRed Hat Enterprise Linux, und Rocky Linux verwalteten Knoten sieht der Arbeitsablauf für die Patch-Installation wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Die YUM-Update-API (auf RHEL 7) oder die DNF-Update-API (auf AlmaLinux 8 und 9, RHEL 8, 9 und 10 sowie Rocky Linux 8 und 9) wird gemäß den folgenden Regeln auf genehmigte Patches angewendet:

    

**Szenario 1: Nicht sicherheitsrelevante Updates ausgeschlossen**
   + **Gilt für**: Vordefinierte Standard-Patch-Baselines, die von bereitgestellt werden, AWS und benutzerdefinierte Patch-Baselines.
   + Das Kontrollkästchen **Funktionsupdates einschließen** ist *nicht* aktiviert
   + **Angewendete Patches**: Die unter `updateinfo.xml` (nur Sicherheitsupdates) angegebenen Patches werden *nur* angewendet, wenn sie beide der Patch-Baseline-Konfiguration entsprechen und sich in den konfigurierten Repositorys befinden.

     In einigen Fällen ist ein in `updateinfo.xml` spezifizierter Patch möglicherweise nicht mehr in einem konfigurierten Repository verfügbar. Konfigurierte Repositorys verfügen normalerweise nur über die neueste Version eines Patches, bei dem es sich um einen kumulativen Rollup aller vorherigen Updates handelt. Die neueste Version entspricht jedoch möglicherweise nicht den Patch-Baseline-Regeln und wird beim Patchen nicht berücksichtigt.
   + **Befehle**: Für RHEL 7 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt: 

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     Für AlmaLinux, RHEL 8 undRocky Linux, lauten die entsprechenden dnf-Befehle für diesen Workflow:

     ```
     sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
     sudo dnf update-minimal --sec-severity=Important --bugfix -y
     ```
**Anmerkung**  
For AlmaLinuxRHEL, und Rocky Linux Rocky Linux installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf` Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).   
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.

**Szenario 2: Nicht sicherheitsrelevante Updates enthalten**
   + **Gilt für**: Benutzerdefinierte Patch-Baselines.
   + Das Kontrollkästchen **Funktionsupdates einschließen** ist aktiviert.
   + **Angewendete Patches**: Patches in `updateinfo.xml` *und* nicht in `updateinfo.xml` werden angewendet (Sicherheits- und andere Updates).
   + **Befehle**: Für RHEL 7 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt:

     ```
     sudo yum update --security --bugfix -y
     ```

     Für AlmaLinux 8 und 9, RHEL 8 und 9 sowie Rocky Linux 8 und 9 lautet der entsprechende dnf-Befehl für diesen Workflow:

     ```
     sudo dnf update --security --bugfix -y
     ```
**Anmerkung**  
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**Anmerkung**  
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution könnte so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.  
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).

------
#### [ SLES ]

Auf von SUSE Linux Enterprise Server (SLES) verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Die Zypper-Update-API wird auf genehmigte Patches angewendet.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Ubuntu Server ]

Auf von Ubuntu Server verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren. 
**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.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
**Anmerkung**  
Für jede Version von Ubuntu Server sind die Patchkandidatenversionen wie folgt auf Patches beschränkt, die Teil des zugehörigen Repositorys für diese Version sind:  
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS): `focal-security`
Ubuntu Server 22.04 LTS: `jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Die APT-Bibliothek wird verwendet, um Upgrades für Pakete durchzuführen.
**Anmerkung**  
Patch Manager unterstützt nicht die Verwendung der `Pin-Priority`-APT-Option, um Paketen Prioritäten zuzuweisen. Patch Manager aggregiert verfügbare Updates aus allen aktivierten Repositorys und wählt das neueste Update aus, das der Baseline für jedes installierte Paket entspricht.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Windows Server ]

Wenn eine Patch-Operation auf einem von Windows Server verwalteten Knoten durchgeführt wird, fordert die Instance einen Snapshot der entsprechenden Patch-Baseline von Systems Manager an. Dieser Snapshot enthält die Liste aller in der Patch-Baseline verfügbaren Updates, die für die Bereitstellung genehmigt wurden. Diese Liste der Updates wird an die Windows-Update-API gesendet, die festlegt, welche Updates für den verwalteten Knoten zutreffen, und diese bei Bedarf installiert. Windows erlaubt nur die Installation der neuesten verfügbaren Version einer KB. Patch Manager installiert die neueste Version einer KB, wenn sie oder eine frühere Version der KB mit der angewendeten Patch-Baseline übereinstimmt. Wenn Updates installiert sind, wird der verwaltete Knoten danach so oft wie nötig neu gestartet, bis alle erforderlichen Patches abgeschlossen sind. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).) Die Zusammenfassung des Patch-Vorgangs finden Sie in der Ausgabe der Run Command-Anfrage. Zusätzliche Protokolle finden Sie auf dem verwalteten Knoten im `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`-Ordner.

Da die Windows Update-API zum Herunterladen und Installieren verwendet wird KBs, werden alle Gruppenrichtlinieneinstellungen für Windows Update berücksichtigt. Für die Verwendung von Patch Manager sind keine Gruppenrichtlinien-Einstellungen erforderlich. Allerdings werden alle definierten Einstellungen angewendet, wie etwa die Weiterleitung von verwalteten Knoten an einen Windows Server Update Services (WSUS)-Server.

**Anmerkung**  
Standardmäßig lädt Windows alles KBs von der Windows Update-Website von Microsoft herunter, da die Windows Update-API Patch Manager verwendet wird, um den Download und die Installation von voranzutreiben KBs. Der verwaltete Knoten muss daher die Website von Microsoft Windows Update erreichen können. Andernfalls tritt ein Fehler bei der Patch-Operation auf. Alternativ können Sie einen WSUS-Server als KB-Repository konfigurieren und Ihre verwalteten Knoten so konfigurieren, dass sie den WSUS-Server anvisieren, anstatt Gruppenrichtlinien zu verwenden.  
Patch Managerverweist möglicherweise auf KB, IDs wenn benutzerdefinierte Patch-Baselines für erstellt werdenWindows Server, z. B. wenn eine Liste **zulässiger Patches** oder **abgelehnter Patches** in der Basiskonfiguration enthalten ist. Nur Updates, denen in Microsoft Windows Update oder einem WSUS-Server eine KB-ID zugewiesen wurde, werden von Patch Manager installiert. Updates, denen eine KB-ID fehlt, sind nicht in den Patchvorgängen enthalten.   
Informationen zum Erstellen benutzerdefinierter Patch-Baselines finden Sie in den folgenden Themen:  
 [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
 [Erstellen einer Patch-Baseline (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Paketnamen-Formate für Windows-Betriebssysteme](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)

------

# Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen
<a name="patch-manager-linux-rules"></a>

Die Regeln in einer Patch-Baseline für Linux-Verteilungen funktionieren je nach Verteilungstyp unterschiedlich. Im Gegensatz zu Patch-Updates auf Windows Server verwalteten Knoten werden Regeln auf jedem Knoten ausgewertet, um die konfigurierten Repos auf der Instanz zu berücksichtigen. Patch Manager, ein Tool in AWS Systems Manager, verwendet den systemeigenen Paketmanager, um die Installation von Patches voranzutreiben, die von der Patch-Baseline genehmigt wurden.

Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches melden, verwendet Patch Manager den vom Software-Publisher gemeldeten Schweregrad für den Update-Hinweis oder den einzelnen Patch. Patch Manager leitet keinen Schweregrad aus Drittquellen wie dem [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) oder aus Metriken ab, die von der [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD) veröffentlicht werden.

**Topics**
+ [Funktionsweise von Patch-Baseline-Regeln unter Amazon Linux 2 und Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Funktionsweise von Patch-Baseline-Regeln auf CentOS Stream](#linux-rules-centos)
+ [Funktionsweise von Patch-Baseline-Regeln auf Debian Server](#linux-rules-debian)
+ [Funktionsweise von Patch-Baseline-Regeln auf macOS](#linux-rules-macos)
+ [Funktionsweise von Patch-Baseline-Regeln auf Oracle Linux](#linux-rules-oracle)
+ [So funktionieren Patch-Basisregeln für AlmaLinuxRHEL, und Rocky Linux](#linux-rules-rhel)
+ [Funktionsweise von Patch-Baseline-Regeln auf SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Funktionsweise von Patch-Baseline-Regeln auf Ubuntu Server](#linux-rules-ubuntu)

## Funktionsweise von Patch-Baseline-Regeln unter Amazon Linux 2 und Amazon Linux 2023
<a name="linux-rules-amazon-linux"></a>

**Anmerkung**  
Amazon Linux 2023 (AL2023) verwendet versionierte Repositorys, die über eine oder mehrere Systemeinstellungen für eine bestimmte Version gesperrt werden können. Für alle Patching-Vorgänge auf AL2023 EC2-Instances verwendet Patch Manager unabhängig von der Systemkonfiguration die neuesten Repository-Versionen. Weitere Informationen finden Sie unter [Deterministische Upgrades durch versionierte Repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) im *Benutzerhandbuch von Amazon Linux 2023*.

Unter Amazon Linux 2 und Amazon Linux 2023 erfolgt die Patch-Auswahl folgendermaßen:

1. Auf dem verwalteten Knoten greift die YUM-Bibliothek (Amazon Linux 2) oder die DNF-Bibliothek (Amazon Linux 2023) auf die `updateinfo.xml`-Datei für jedes konfigurierte Repository zu. 

   Wenn keine `updateinfo.xml`-Datei gefunden wird, hängt es von den Einstellungen für **Funktionsupdates einschließen** und **Automatische Genehmigung** ab, ob Patches installiert werden. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.

1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.  
**Update-Hinweis-Attribute**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf CentOS Stream
<a name="linux-rules-centos"></a>

Die CentOS Stream-Standard-Repositorys enthalten keine `updateinfo.xml`-Datei. Benutzerdefinierte Repositorys, die Sie erstellen oder verwenden, können diese Datei jedoch enthalten. In diesem Thema beziehen sich Verweise nur `updateinfo.xml` auf diese benutzerdefinierten Repositorys.

In CentOS Stream erfolgt die Patch-Auswahl folgendermaßen:

1. Auf dem verwalteten Knoten ruft die DNF-Bibliothek die `updateinfo.xml`-Datei für jedes konfigurierte Repository auf, sofern diese in einem benutzerdefinierten Repository vorhanden ist.

   Wenn kein `updateinfo.xml` gefunden wird (was immer die Standard-Repos einschließt), hängt die Installation von Patches von den Einstellungen für **Nicht sicherheitsrelevante Updates einschließen** und **Automatische Genehmigung** ab. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.

1. Wenn `updateinfo.xml` vorhanden ist, enthält jede Aktualisierungsmitteilung in der Datei mehrere Attribute, die die Eigenschaften der Pakete in der Mitteilung bezeichnen, wie in der folgenden Tabelle beschrieben.  
**Update-Hinweis-Attribute**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

1. Das Produkt des verwalteten Knotens wird in allen Fällen durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf Debian Server
<a name="linux-rules-debian"></a>

Auf Debian Server bietet der Patch-Baseline-Service Filter in den Feldern *Priorität* und *Abschnitt*. Diese Felder sind normalerweise für alle Debian Server-Pakete vorhanden. Um zu bestimmen, ob ein Patch von der Patch-Baseline ausgewählt wird, geht Patch Manager folgendermaßen vor:

1. Auf Debian Server-Systemen wird das Äquivalent von `sudo apt-get update` ausgeführt, um die Liste der verfügbaren Pakete zu aktualisieren. Repos sind nicht konfiguriert und die Daten werden aus Repos abgerufen, die in einer `sources`-Liste konfiguriert sind.

1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)

1. Als Nächstes werden die Listen [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) und [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) angewendet.
**Anmerkung**  
Da es nicht möglich ist, die Veröffentlichungstermine von Update-Paketen für Debian Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. Für Debian Server sind Patch-Kandidaten-Versionen in diesem Fall auf Patches beschränkt, die in den folgenden Repos enthalten sind:

   Diese Repos werden wie folgt benannt:
   + Debian Server11: `debian-security bullseye`
   + Debian Server12: `debian-security bookworm`

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

Zum Anzeigen der Inhalte der Felder *Priorität* und *Abschnitt* führen Sie den folgenden `aptitude`-Befehl aus: 

**Anmerkung**  
Möglicherweise müssen Sie zuerst Aptitude auf Debian Server-Systemen installieren.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

In der Antwort auf diesen Befehl werden alle Pakete, für die ein Upgrade durchgeführt werden kann, in diesem Format gemeldet: 

```
name, priority, section, archive, candidate version
```

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf macOS
<a name="linux-rules-macos"></a>

In macOS erfolgt die Patch-Auswahl folgendermaßen:

1. Auf dem verwalteten Knoten greift Patch Manager auf den geparsten Inhalt der `InstallHistory.plist`-Datei zu und identifiziert Paketnamen und -versionen. 

   Details zum Parsing-Prozess finden Sie unter der Registerkarte **macOS** in [Wie Patches installiert werden](patch-manager-installing-patches.md).

1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf Oracle Linux
<a name="linux-rules-oracle"></a>

In Oracle Linux erfolgt die Patch-Auswahl folgendermaßen:

1. Auf dem verwalteten Knoten ruft die YUM-Bibliothek die `updateinfo.xml`-Datei für jedes konfigurierte Repo auf.
**Anmerkung**  
Die `updateinfo.xml`-Datei ist möglicherweise nicht verfügbar, wenn das Repo nicht von Oracle verwaltet wird. Wenn keine `updateinfo.xml`-Datei gefunden wird, hängt es von den Einstellungen für **Funktionsupdates einschließen** und **Automatische Genehmigung** ab, ob Patches installiert werden. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.

1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.  
**Update-Hinweis-Attribute**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## So funktionieren Patch-Basisregeln für AlmaLinuxRHEL, und Rocky Linux
<a name="linux-rules-rhel"></a>

Bei AlmaLinux, Red Hat Enterprise Linux (RHEL) und Rocky Linux erfolgt die Patch-Auswahl wie folgt:

1. Auf dem verwalteten Knoten greift die YUM-Bibliothek (RHEL7) oder die DNF-Bibliothek (AlmaLinux 8 und 9, RHEL 8, 9 und 10 sowie Rocky Linux 8 und 9) auf die `updateinfo.xml` Datei für jedes konfigurierte Repository zu.
**Anmerkung**  
Die `updateinfo.xml`-Datei ist möglicherweise nicht verfügbar, wenn das Repo nicht von Red Hat verwaltet wird. Falls keine `updateinfo.xml` gefunden werden, wird kein Patch angewendet.

1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.  
**Update-Hinweis-Attribute**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf SUSE Linux Enterprise Server
<a name="linux-rules-sles"></a>

Auf SLES enthält jeder Patch die folgenden Attribute, mit denen die Eigenschaften der Pakete im Patch gekennzeichnet werden:
+ **Category**: Entspricht dem Wert des **Klassifizierungs**-Schlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline. Kennzeichnet den Typ des im Update-Hinweis enthaltenen Patches.

  Sie können die Liste der unterstützten Werte mithilfe des AWS CLI Befehls **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** oder der API-Operation **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** anzeigen. Sie können die Liste auch im Bereich **Genehmigungsregeln** der Seite **Erstellen einer Patch-Baseline** der Seite **Patch-Baseline bearbeiten** in der Systems Manager-Konsole anzeigen.
+ **Schweregrad**: Entspricht dem Wert des **Schweregrads**-Schlüsselattributs in dem [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline. Kennzeichnet den Schweregrad der Patches.

  Sie können die Liste der unterstützten Werte mithilfe des AWS CLI Befehls **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** oder der API-Operation anzeigen**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. Sie können die Liste auch im Bereich **Genehmigungsregeln** der Seite **Erstellen einer Patch-Baseline** der Seite **Patch-Baseline bearbeiten** in der Systems Manager-Konsole anzeigen.

Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des **Produkt**-Schlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline. 

Für jeden Patch wird die Patch-Baseline als Filter verwendet, der nur den qualifizierten Paketen die Aufnahme in das Update erlaubt. Wenn mehrere Pakete zutreffen, wird die aktuelle Version nach Anwenden der Patch-Baseline-Definition verwendet. 

Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

## Funktionsweise von Patch-Baseline-Regeln auf Ubuntu Server
<a name="linux-rules-ubuntu"></a>

Auf Ubuntu Server bietet der Patch-Baseline-Service Filter in den Feldern *Priorität* und *Abschnitt*. Diese Felder sind normalerweise für alle Ubuntu Server-Pakete vorhanden. Um zu bestimmen, ob ein Patch von der Patch-Baseline ausgewählt wird, geht Patch Manager folgendermaßen vor:

1. Auf Ubuntu Server-Systemen wird das Äquivalent von `sudo apt-get update` ausgeführt, um die Liste der verfügbaren Pakete zu aktualisieren. Repos sind nicht konfiguriert und die Daten werden aus Repos abgerufen, die in einer `sources`-Liste konfiguriert sind.

1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)

1. Als Nächstes werden die Listen [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) und [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) angewendet.
**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.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. Für Ubuntu Server sind Patch-Kandidaten-Versionen in diesem Fall auf Patches beschränkt, die in den folgenden Repos enthalten sind:
   + Ubuntu Server 16.04 LTS: `xenial-security`
   + Ubuntu Server 18.04 LTS: `bionic-security`
   + Ubuntu Server 20.04 LTS: `focal-security`
   + Ubuntu Server 22.04 LTS (`jammy-security`)
   + Ubuntu Server 24.04 LTS (`noble-security`)
   + Ubuntu Server 25.04 (`plucky-security`)

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

Zum Anzeigen der Inhalte der Felder *Priorität* und *Abschnitt* führen Sie den folgenden `aptitude`-Befehl aus: 

**Anmerkung**  
Möglicherweise müssen Sie zuerst Aptitude auf Ubuntu Server 16-Systemen installieren.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

In der Antwort auf diesen Befehl werden alle Pakete, für die ein Upgrade durchgeführt werden kann, in diesem Format gemeldet: 

```
name, priority, section, archive, candidate version
```

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

# Unterschiede beim Patchvorgang zwischen Linux und Windows Server
<a name="patch-manager-windows-and-linux-differences"></a>

In diesem Thema werden wichtige Unterschiede zwischen Linux- und Windows Server-Patching in Patch Manager, einem Tool in AWS Systems Manager, beschrieben.

**Anmerkung**  
Um von Linux verwaltete Knoten zu patchen, müssen Ihre Knoten SSM Agent der Version 2.0.834.0 oder höher ausführen.  
Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](ssm-agent-automatic-updates.md). Abonnieren Sie die [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.

## Unterschied 1: Patch-Bewertung
<a name="patch-evaluation_diff"></a>

Patch Manager verwendet auf Windows-verwalteten Knoten und Linux-verwalteten Knoten jeweils andere Prozesse, um zu ermitteln, welche Patches installiert sein sollten. 

**Linux**  
Bei Linux-Patches wertet Systems Manager auf *jedem* verwalteten Knoten einzeln zuerst die Patch-Baseline-Regeln und dann die Liste der genehmigten bzw. abgelehnten Patches aus. Systems Manager muss die Patches auf jedem Knoten gesondert auswerten, weil der Service die Liste der bekannten Patches und Updates von den Repositorys abruft, die auf dem verwalteten Knoten konfiguriert sind.

**Windows**  
Für Windows-Patches wertet Systems Manager *direkt im Service* zuerst die Patch-Baseline-Regeln und dann die Liste der genehmigten bzw. abgelehnten Patches aus. Dies ist möglich, weil Windows-Patches aus einem einzigen Repository (Windows Update) abgerufen werden.

## Unterschied 2: `Not Applicable`-Patches
<a name="not-applicable-diff"></a>

Aufgrund der großen Anzahl der verfügbaren Pakete für Linux-Betriebssysteme, meldet Systems Manager keine Details zu Patches mit dem Status *Nicht anwendbar*. Ein `Not Applicable`-Patch ist beispielsweise ein Patch für Apache-Software, wenn auf der Instance Apache nicht installiert ist. Systems Manager meldet zwar die Anzahl der `Not Applicable` Patches in der Zusammenfassung, aber wenn Sie die [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html)API für einen verwalteten Knoten aufrufen, enthalten die zurückgegebenen Daten keine Patches mit dem Status von`Not Applicable`. Dieses Verhalten unterscheidet sich von dem bei Windows.

## Unterschied 3: Unterstützung von SSM-Dokumenten
<a name="document-support-diff"></a>

Das Systems-Manager-Dokument (SSM-Dokument) `AWS-ApplyPatchBaseline` unterstützt keine Linux-verwalteten Knoten. Um Patch-Baselines auf Linux-, macOS- und Windows Server-verwalteten Knoten anzuwenden, wird das SSM-Dokument `AWS-RunPatchBaseline` empfohlen. Weitere Informationen erhalten Sie unter [SSM-Befehlsdokumente zum Patchen verwalteter Knoten](patch-manager-ssm-documents.md) und [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

## Unterschied 4: Anwendungspatches
<a name="application-patches-diff"></a>

Der Hauptfokus von Patch Manager liegt auf dem Patchen von Betriebssystemen. Sie können mit Patch Manager jedoch auch Patches für bestimmte Anwendungen auf Ihren verwalteten Knoten anwenden.

**Linux**  
Auf Linux-Betriebssystemen verwendet Patch Manager die konfigurierten Repositorys für Updates und unterscheidet dabei nicht zwischen Betriebssystem- und Anwendungs-Patches. Sie können mit Patch Manager festlegen, aus welchen Repositorys Updates abgerufen werden. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).

**Windows**  
Auf von Windows Server verwaltete Knoten können Sie für Microsoft-Anwendungen wie Microsoft Word 2016 und Microsoft Exchange Server 2016 Genehmigungsregeln sowie die Patch-Ausnahmen *Approved* (Freigegeben) und *Rejected* (Abgelehnt) anwenden. Weitere Informationen finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).

## Unterschied 5: Optionen für abgelehnte Patch-Listen in benutzerdefinierten Patch-Baselines
<a name="rejected-patches-diff"></a>

Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für eine Liste Abgelehnte Patches einen oder **mehrere Patches** angeben. Bei verwalteten Linux-Knoten können Sie auch festlegen, dass sie installiert werden dürfen, wenn es sich um Abhängigkeiten für einen anderen Patch handelt, der laut Baseline zulässig ist.

Windows Server unterstützt jedoch das Konzept der Patch-Abhängigkeiten nicht. Sie können einen Patch zur Liste der **abgelehnten Patches** in einer benutzerdefinierten Baseline für Windows Server hinzufügen. Das Ergebnis hängt jedoch davon ab, (1) ob der abgelehnte Patch bereits auf einem verwalteten Knoten installiert ist oder nicht, und (2) welche Option Sie für die **Aktion Abgelehnte Patches** wählen.

In der folgenden Tabelle finden Sie Einzelheiten zu den Optionen für abgelehnte Patches in Windows Server.


| Status der installation | Option: „Als Abhängigkeit zulassen“ | Option: „Blockieren“ | 
| --- | --- | --- | 
| Der Patch ist bereits installiert | Gemeldeter Status: INSTALLED\$1OTHER | Gemeldeter Status: INSTALLED\$1REJECTED | 
| Der Patch ist noch nicht installiert | Patch übersprungen | Patch übersprungen | 

Jeder von Microsoft veröffentlichte Patch für Windows Server enthält normalerweise alle Informationen, die für eine erfolgreiche Installation erforderlich sind. Gelegentlich kann jedoch ein Paket erforderlich sein, das Sie manuell installieren müssen. Patch Manager meldet keine Informationen zu diesen Voraussetzungen. Weitere Informationen finden Sie auf der Microsoft-Website unter [Problembehandlung bei Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting).