Wie Sicherheitspatches ausgewählt werden - AWS Systems Manager

Wie Sicherheitspatches ausgewählt werden

Der primäre Schwerpunkt von Patch Manager, einer Funktion von AWS Systems Manager, liegt auf der Installation von Sicherheits-Updates für Betriebssysteme 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.

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

Die Architektur kann x86_64 oder aarch64 sein.

Amazon Linux 2023 (AL2023)-Instances enthalten zunächst die Updates, die in der Version von AL2023 und der ausgewählten AMI verfügbar waren. Standardmäßig erhält Ihre AL2023-Instance beim Start nicht automatisch zusätzliche kritische und wichtige Sicherheitsupdates. Mit dem Feature für deterministische Upgrades durch versionierte Repositorys in AL2023, die standardmäßig aktiviert ist, können Sie stattdessen Aktualisierungen nach einem Zeitplan durchführen, 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. Wenn neue Amazon Machine Images (AMIs) für Amazon Linux 2022 veröffentlicht 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.

Auf AL2023 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 neue Amazon Machine Images (AMIs) für Amazon Linux 2022 veröffentlicht 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.

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

CentOS and CentOS Stream

Der Patch-Baseline-Service des Systems Managers auf CentOS und CentOS Stream verwendet 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 werden jedoch nicht mit einem Update-Hinweis konfiguriert. Das bedeutet, dass Patch Manager Pakete auf einem Standard-CentOS- und 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 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

Auf Debian Server und Raspberry Pi OS (früher Raspbian) verwendet der Patch-Baseline-Service des Systems Managers 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 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

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

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

Auf AlmaLinux, Red Hat Enterprise Linux, und Rocky Linux verwendet der Systems Manager Patch Baseline Service vorkonfigurierte Repositories (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 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

Die folgenden Repository-IDs sind RHUI 2 zugeordnet. RHUI 3 wurde im Dezember 2019 veröffentlicht und führte ein anderes Benennungsschema für Yum-Repository-IDs ein. 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 für RHEL 7 in AWS wurden 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

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 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 STR: groovy-security

  • Ubuntu Server 22.04 LTS (jammy-security)

  • Ubuntu Server 23.04 (lunar-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.