Wie Sicherheitspatches ausgewählt werden - AWS Systems Manager

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.

Wie Sicherheitspatches ausgewählt werden

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.

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 angebenApproveUntilDate, werden Patches2025-11-16, die zwischen 2025-11-16T00:00:00Z und veröffentlicht wurden2025-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 (CVSS) oder aus Metriken ab, die von der National Vulnerability Database (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).

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

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:

  • 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 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.

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 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

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
Anmerkung

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:

  • 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.