• 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 erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte Patch-Baseline für Linux-verwaltete Knoten in Patch Manager, einem Tool in AWS Systems Manager, zu erstellen. Informationen zum Erstellen einer Patch-Baseline für macOS-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für macOS](patch-manager-create-a-patch-baseline-for-macos.md). Informationen zum Erstellen einer Patch-Baseline für Windows-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md). **So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux-verwaltete Knoten** 1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. Wählen Sie im Navigationsbereich **Patch Manager** aus. 1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus. –oder– Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wechseln Sie zur Registerkarte **Patch-Baselines** und wählen Sie dann **Patch-Baseline** erstellen. 1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MyRHELPatchBaseline`. 1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein. 1. Wählen Sie unter **Operating system (Betriebssystem)** ein Betriebssystem aus, z. B. `Red Hat Enterprise Linux`. 1. Wenn Sie diese Patch-Baseline sofort nach der Erstellung als Standard für das ausgewählte Betriebssystem verwenden möchten, aktivieren Sie das Kontrollkästchen neben **Diese Patch-Baseline als Standard-Patch-Baseline für *operating system name* Instances festlegen**. **Anmerkung** Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben. Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md). 1. Erstellen Sie im Abschnitt **Genehmigungsregeln für Betriebssysteme** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln. + **Produkte**: Die Version der Betriebssysteme, auf die sich die Genehmigungsregel bezieht, z. B. `RedhatEnterpriseLinux7.4`. Die Standardauswahl ist `All`. + **Classification (Klassifizierung)**: Der Typ der Patches, auf die sich die Genehmigungsregel bezieht, z. B. `Security` oder `Enhancement`. Die Standardauswahl ist `All`. **Tipp** Sie können eine Patch-Baseline konfigurieren, um zu steuern, ob Nebenversions-Upgrades für Linux installiert werden, z. B. RHEL 7.8. Nebenversionsupgrades können vom Patch Manager automatisch installiert werden, wenn das Update im entsprechenden Repository verfügbar ist. Im Fall von Linux-Betriebssystemen werden Nebenversionsupgrades nicht konsistent klassifiziert. Sie können als Fehlerbehebungen oder Sicherheitsupdates klassifiziert (oder nicht klassifiziert) werden, selbst innerhalb derselben Kernel-Version. Im Folgenden werden einige Optionen aufgelistet, mit denen Sie steuern können, ob sie von einer Patch-Baseline installiert werden. **Option 1**: Die umfassendste Genehmigungsregel, die sicherzustellt, dass Nebenversionsupgrades installiert werden, wenn verfügbar, besteht in der Angabe von **Classification (Klassifizierung)** als `All` (\$1) und der Auswahl der Option **Include nonsecurity updates (Auch andere Updates als Sicherheitsupdates einschließen)**. **Option 2**: Um die Installation von Patches für eine Betriebssystemversion sicherzustellen, können Sie ein Platzhalterzeichen (\$1) verwenden, um das Kernel-Format im Abschnitt **Patch exceptions (Patch-Ausnahmen)** der Baseline anzugeben. Zum Beispiel ist das Kernel-Format für RHEL 7.\$1 `kernel-3.10.0-*.el7.x86_64`. Geben Sie `kernel-3.10.0-*.el7.x86_64` in der Liste **Approved patches** (Genehmigte Patches) in Ihrer Patch-Baseline ein, um die Anwendung aller Patches einschließlich Nebenversionsupgrades auf Ihren von RHEL 7.\$1 verwalteten Knoten sicherzustellen. (Wenn Sie den genauen Paketnamen eines Nebenversionspatches kennen, können Sie diesen stattdessen eingeben.) **Option 3**: Mithilfe des [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)Parameters im `AWS-RunPatchBaseline` Dokument haben Sie die größtmögliche Kontrolle darüber, welche Patches auf Ihre verwalteten Knoten angewendet werden, einschließlich kleinerer Versions-Upgrades. Weitere Informationen finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md). + **Schweregrad**: Der Schweregradwert von Patches, auf den die Regel anzuwenden ist, z. B. `Critical`. Die Standardauswahl ist `All`. + **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung. **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. + **Approve patches after a specified number of days** (Patches nach einer bestimmten Anzahl von Tagen genehmigen): Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder zuletzt aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten. + **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 7. Juli 2023 angeben, werden Patches, die am oder nach dem 8. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert. + (Optional) **Konformitätsbericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `Critical` oder `High`). **Anmerkung** Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad. + **Include non-security updates (Nicht sicherheitsrelevante Updates einbeziehen)**: Aktivieren Sie das Kontrollkästchen zum Installieren von nicht sicherheitsrelevanten Linux-Betriebssystem-Patches, die im Quell-Repository verfügbar gemacht wurden, zusätzlich zu den sicherheitsrelevanten Patches. Weitere Informationen zum Arbeiten mit Genehmigungsregeln in einer benutzerdefinierten Patch-Baseline finden Sie unter [Benutzerdefinierte Baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom). 1. Wenn Sie zusätzlich zu den Patches, die Ihren Genehmigungsregeln entsprechen, alle Patches ausdrücklich genehmigen möchten, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor: + Geben Sie im Feld **Genehmigte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie genehmigen möchten. 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). + (Optional) Weisen Sie in der Liste **Compliance-Stufe genehmigter Patches** den Patches in der Liste eine Compliance-Stufe zu. + Wenn genehmigte Patches, die Sie angeben, nicht sicherheitsbezogen sind, wählen Sie das Kästchen **Genehmigte Patches umfassen nicht sicherheitsrelevante Updates** aus, damit diese Patches ebenfalls auf Ihrem Linux-Betriebssystem installiert werden. 1. Wenn Sie Patches ablehnen möchten, die ansonsten Ihren Genehmigungsregeln entsprechen, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor: + Geben Sie im Feld **Abgelehnte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie ablehnen möchten. 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). + Wählen Sie in der Liste **Aktion für abgelehnte Patches** die Aktion aus, die Patch Manager für Patches in der Liste **Abgelehnte Patches** ausführen soll. + **Als Abhängigkeit zulassen**: Ein Paket in der Liste **Abgelehnte Patches** wird nur installiert, wenn es sich um eine Abhängigkeit eines anderen Pakets handelt. Es gilt als konform mit der Patch-Baseline und sein Status wird als gemeldet *InstalledOther*. Dies ist die Standardaktion, wenn keine Option ausgewählt ist. + **Blockieren**: Pakete in der Liste **Abgelehnte Patches** und Pakete, die diese als Abhängigkeiten enthalten, werden unter keinen Umständen von Patch Manager installiert. Wenn ein Paket installiert wurde, bevor es zur Liste der **abgelehnten Patches** hinzugefügt wurde, oder danach außerhalb von Patch Manager installiert wird, gilt es als nicht konform mit der Patch-Baseline und sein Status wird als *InstalledRejected* gemeldet. **Anmerkung** Patch Manager sucht rekursiv nach Patch-Abhängigkeiten. 1. **(Optional) Wenn Sie alternative Patch-Repositorys für verschiedene Versionen eines Betriebssystems angeben möchten, z. B. *AmazonLinux2016.03 und *AmazonLinux2017.09**, gehen Sie für jedes Produkt im Abschnitt Patch-Quellen wie folgt vor:** + Geben Sie in **Name (Name)** einen Namen ein, um Sie bei der Identifizierung der Quellkonfiguration zu unterstützen. + Wählen Sie unter **Product (Produkt)** die Version der Betriebssysteme aus, für die das Patch-Quell-Repository bestimmt ist, z. B. `RedhatEnterpriseLinux7.4`. + Geben Sie unter **Konfiguration** den Wert der zu verwendenden Repository-Konfiguration im entsprechenden Format ein: ------ #### [ Example for yum repositories ] ``` [main] name=MyCustomRepository baseurl=https://my-custom-repository enabled=1 ``` **Tipp** Informationen zu anderen Optionen für Ihre Yum-Repository-Konfiguration finden Sie unter [dnf.conf (5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html). ------ #### [ Examples for Ubuntu Server and Debian Server ] `deb http://security.ubuntu.com/ubuntu jammy main` `deb https://site.example.com/debian distribution component1 component2 component3` Repository-Informationen für Ubuntu Server-Repositorys müssen in einer einzigen Zeile angegeben werden. Weitere Beispiele und Informationen finden Sie unter [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) auf der Website *Ubuntu Server Manuals* und unter [sources.list-Format](https://wiki.debian.org/SourcesList#sources.list_format) im *Debian-Wiki*. ------ Wählen Sie **Add another source** aus, um ein Quell-Repository für jede zusätzliche Betriebssystemversion anzugeben, bis maximal 20. Weitere Informationen über alternative Quell-Patch-Repositorys finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md). 1. (Optional) Wenden Sie unter **Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an. Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Sie können beispielsweise eine Patch-Baseline kennzeichnen, um den Schweregrad der angegebenen Patches, die Betriebssystemfamilie, auf die sie sich bezieht, und den Umgebungstyp zu identifizieren. In diesem Fall könnten Sie Tags angeben, die den folgenden name/value Schlüsselpaaren ähneln: + `Key=PatchSeverity,Value=Critical` + `Key=OS,Value=RHEL` + `Key=Environment,Value=Production` 1. Wählen Sie die Option **Patch-Baseline erstellen**.