Wie Sicherheitspatches ausgewählt werden

Der Hauptfokus von Patch Manager, ein Tool in AWS Systems Manager, befasst sich mit der Installation sicherheitsrelevanter Betriebssystemupdates auf verwalteten Knoten. Standardmäßig Patch Manager installiert nicht alle verfügbaren Patches, sondern einen kleineren Satz von Patches, der sich auf die Sicherheit konzentriert.

Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches angeben, Patch Manager verwendet den Schweregrad, den der Softwarehersteller für den Update-Hinweis oder den einzelnen Patch gemeldet hat. Patch Manager leitet den Schweregrad nicht aus Quellen Dritter ab, wie dem Common Vulnerability Scoring System (CVSS), oder aus von der National Vulnerability Database (NVD) veröffentlichten Kennzahlen.

Anmerkung

Auf allen Linux-basierten Systemen, die unterstützt werden von Patch Manager, können Sie ein anderes Quell-Repository wählen, das für den verwalteten Knoten konfiguriert ist, in der Regel, um nicht sicherheitsrelevante Updates zu installieren. Weitere Informationen finden Sie unter So geben Sie ein alternatives Patch-Quell-Repository an (Linux).

Wählen Sie aus den folgenden Tabs, um zu erfahren, wie Patch Manager wählt Sicherheitspatches für Ihr Betriebssystem aus.

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

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

Auf Amazon Linux 1 und 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 1

• Repo-ID: amzn-main/latest

  Repo-Name: amzn-main-Base

• Repo-ID: amzn-updates/latest

  Repo-Name: amzn-updates-Base

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 aarch64 sein.

Wenn Sie eine Amazon Linux 2023 (AL2023) -Instance erstellen, enthält sie die Updates, die in der Version AL2 0.23 verfügbar waren, und die spezifischen AMI Sie haben ausgewählt. 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.

Unter Amazon Linux 2022 sind die vorkonfigurierten Repositorys an gesperrte Versionen von Paketaktualisierungen gebunden. Wann neu Amazon Machine Images (AMIs) für Amazon Linux 2022 veröffentlicht werden, sie sind an eine bestimmte Version gebunden. Für Patch-Updates Patch Manager ruft die neueste gesperrte Version des Patch-Update-Repositorys ab und aktualisiert dann die Pakete auf dem verwalteten Knoten auf der Grundlage des Inhalts dieser gesperrten Version.

Am AL2 023 sieht das vorkonfigurierte Repository wie folgt aus:

• Repo-ID: amazonlinux

  Repository-Name: Amazon-Linux-2023-Repository

Bei Amazon Linux 2022 (Vorschauversion) sind die vorkonfigurierten Repositories an gesperrte Versionen von Paket-Updates gebunden. Wenn neu Amazon Machine Images (AMIs) für Amazon Linux 2022 veröffentlicht werden, sie sind an eine bestimmte Version gebunden. Für Patch-Updates Patch Manager ruft die neueste gesperrte Version des Patch-Update-Repositorys ab und aktualisiert dann die Pakete auf dem verwalteten Knoten auf der Grundlage des Inhalts dieser gesperrten Version.

Auf Amazon Linux 2022 sieht das vorkonfigurierte Repository wie folgt aus:

• Repo-ID: amazonlinux

  Repository-Name: Amazon-Linux-2022-Repository

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 Amazon Linux 1 und Amazon Linux 2 verwaltete Knoten verwenden YUM als Paket-Manager. Amazon Linux 2022 und Amazon Linux 2023 verwenden DNF als Paketmanager.

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, die in einem Update-Hinweis enthalten sind, werden von Patch Manager. Einigen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Aus diesem Grund Patch Manager weist den zugehörigen Paketen die Attribute eines Aktualisierungshinweises 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 Hinweise zur Option Nicht sicherheitsrelevante Updates einbeziehen finden Sie unter Wie Patches installiert werden und. Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen

CentOS and CentOS Stream

Auf CentOS und CentOS Streamverwendet der Systems Manager Patch Baseline Service vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Die folgende Liste enthält Beispiele für ein fiktives CentOS 8.2 Amazon Machine Image (AMI):

• Repo-ID: example-centos-8.2-base

  Repo-Name: Example CentOS-8.2 - Base

• Repo-ID: example-centos-8.2-extras

  Repo-Name: Example CentOS-8.2 - Extras

• Repo-ID: example-centos-8.2-updates

  Repo-Name: Example CentOS-8.2 - Updates

• Repo-ID: example-centos-8.x-examplerepo

  Repo-Name: Example CentOS-8.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.

Von CentOS 6 und 7 verwaltete Knoten verwenden Yum als Paketmanager. CentOS 8 und CentOS Stream Knoten verwenden DNF als Paketmanager. Beide Paketmanager verwenden das Konzept eines Update-Hinweises als einen aktualisierten Hinweis. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben.

CentOS und CentOS Stream Standard-Repos sind nicht mit einem Update-Hinweis konfiguriert. Das bedeutet, dass Patch Manager erkennt keine Pakete auf Standard-CentOS und CentOS Stream Repos. Zu erlauben Patch Manager Um Pakete zu verarbeiten, die nicht in einem Update-Hinweis enthalten sind, müssen Sie das EnableNonSecurity Kennzeichen in den Patch-Baseline-Regeln aktivieren.

Anmerkung

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

Debian Server and Raspberry Pi OS

Ein Debian Server and Raspberry Pi OS (früher Raspbian) verwendet der Systems Manager Patch Baseline Service vorkonfigurierte Repositorys (Repos) auf der Instanz. 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 auf jeder Version von Debian Server, Patch Manager identifiziert nur Upgrades, die Teil des zugehörigen Repos für diese Version sind, wie folgt:

• Debian Server 8: debian-security jessie

• Debian Server 9: debian-security stretch

• Debian Server 10: debian-security buster

• Debian Server 11: debian-security bullseye

• Debian Server 12: debian-security bookworm

Anmerkung

Ein Debian Server Nur 8: Weil einige Debian Server 8.* verwaltete Knoten verweisen auf ein veraltetes Paket-Repository (jessie-backports), Patch Manager führt zusätzliche Schritte durch, um sicherzustellen, dass die Patch-Operationen erfolgreich sind. Weitere Informationen finden Sie unter Wie Patches installiert werden.

Oracle Linux

Ein Oracle Linuxverwendet der Systems Manager Patch Baseline Service 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.

Oracle Linux verwaltete Knoten verwenden Yum als Paketmanager, und Yum verwendet das Konzept einer Update-Benachrichtigung als Datei mit dem Namen. 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 Patch Manager weist den zugehörigen Paketen die Attribute eines Aktualisierungshinweises zu und installiert Pakete auf der Grundlage der in der Patch-Baseline angegebenen Klassifizierungsfilter.

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

Am, AlmaLinux Red 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 Linux 7 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 Patch Manager weist den zugehörigen Paketen die Attribute eines Aktualisierungshinweises zu und installiert Pakete auf der Grundlage der in der Patch-Baseline angegebenen Klassifizierungsfilter.

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 vom RHEL-7 AMI Aus denen Sie Ihre verwalteten Knoten erstellen, müssen Sie möglicherweise Ihre Befehle aktualisieren. Weitere Informationen finden Sie unter Repository IDs für RHEL 7 in AWS Haben sich geändert im Red Hat Kundenportal.

• 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

Ein SUSE Linux Enterprise Server (SLES) verwaltete Knoten, die ZYPP-Bibliothek ruft die Liste der verfügbaren Patches (eine Sammlung von Paketen) von den folgenden Orten ab:

• Liste der Repositorys: etc/zypp/repos.d/*

• Paketinformationen: /var/cache/zypp/raw/*

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 sicherheitsrelevant. Da einzelnen Paketen keine Klassifizierungen oder Schweregrade zugewiesen wurden, Patch Manager weist den Paketen die Attribute des Patches zu, zu dem sie gehören.

Ubuntu Server

Ein Ubuntu Serververwendet der Systems Manager Patch Baseline Service 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, deren Codename für die Release-Version eindeutig ist, z. B. für trusty Ubuntu Server 14. Patch Manager identifiziert nur Upgrades, die Teil dieser Repos sind:

• Ubuntu Server 14.04 LTS: trusty-security

• Ubuntu Server 16,04 LTS: xenial-security

• Ubuntu Server 18,04 LTS: bionic-security

• Ubuntu Server 20,04 LTS: focal-security

• Ubuntu Server 20.10 UHR: groovy-security

• Ubuntu Server 22,04 LTS () jammy-security

• Ubuntu Server 23,04 () lunar-security

Windows Server

Auf Microsoft Windows-Betriebssystemen Patch Manager ruft eine Liste verfügbarer Updates ab, die Microsoft für Microsoft Update veröffentlicht und die automatisch für Windows Server Update Services (WSUS) verfügbar sind.

Anmerkung

Patch Manager stellt nur Patches zur Verfügung für Windows Server Betriebssystemversionen, die unterstützt werden für Patch Manager. Zum Beispiel Patch Manager kann nicht zum Patchen von Windows RT verwendet werden.

Patch Manager überwacht in jedem Bereich kontinuierlich auf neue Updates 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, Patch Manager entfernt 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. Wenn es beispielsweise KB4012214 ersetztKB3135456, KB4012214 wird es nur als Update verfügbar gemacht in Patch Manager.

In ähnlicher Weise Patch Manager kann nur Patches installieren, die während des Patchvorgangs auf dem verwalteten Knoten verfügbar sind. Standardmäßig Windows Server 2019 und Windows Server 2022 entfernen Sie Updates, die durch spätere Updates ersetzt werden. Wenn Sie den ApproveUntilDate Parameter also in einem verwenden Windows Server Patch-Baseline, aber das im ApproveUntilDate Parameter gewählte Datum liegt vor dem Datum des letzten Patches, dann tritt das folgende Szenario ein:

• Der abgelöste Patch wurde vom Knoten entfernt und kann daher nicht installiert werden mit Patch Manager.

• 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 Patch-Verhaltens, das Microsoft ersetzt hat, ist es möglich, eine Zahl festzulegen (in der Regel mehr als 30 Tage), sodass Patches für Windows Server werden niemals installiert, wenn der neueste verfügbare Patch von Microsoft veröffentlicht wird, bevor die Anzahl der Tage 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.