- 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
architecturekann x86_64 oder (für Graviton-Prozessoren) aarch64 sein.
Wenn Sie eine Amazon Linux 2023 (AL2023) -Instance erstellen, enthält sie die Updates, die in der Version AL2 023 verfügbar waren, und die von AMI Ihnen ausgewählte Version. Ihre AL2 023-Instance erhält beim Start nicht automatisch zusätzliche kritische und wichtige Sicherheitsupdates. Stattdessen können Sie mit der für AL2 023 unterstützten Funktion für deterministische Upgrades über versionierte Repositorys, 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 im Benutzerhandbuch von Amazon Linux 2023.
In Version AL2 023 sieht das vorkonfigurierte Repository wie folgt aus:
Bei Amazon Linux 2023 (Vorschauversion) sind die vorkonfigurierten Repositories an gesperrte Versionen von Paket-Updates gebunden. Wenn new Amazon Machine Images (AMIs) für AL2 023 veröffentlicht wird, sind sie für eine bestimmte Version gesperrt. 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.
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 und Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen.
-
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
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.
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:
- 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)
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.
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.
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 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:
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-securitytrusty 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.
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.
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.
