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

Der Hauptfokus von Patch Manager, eine Funktion von AWS Systems Manager, besteht in 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 Schweregrade nicht aus Quellen von Drittanbietern ab, z. B. aus dem Common Vulnerability Scoring System (CVSS), oder aus Kennzahlen, die von der National Vulnerability Database (NVD) veröffentlicht wurden.

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 Systems Manager Patch Baseline Service 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

architecture kann x86_64 oder aarch64 sein.

Amazon Linux 2023 (AL2023) -Instances enthalten zunächst die Updates, die in der Version AL2 0.23 verfügbar waren, und den ausgewählten AMI. Standardmäßig erhält Ihre AL2 023-Instance beim Start nicht automatisch zusätzliche kritische und wichtige Sicherheitsupdates. Stattdessen können Sie mit der Funktion deterministische Upgrades durch versionierte Repositorys in AL2 023, 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.

Die verwalteten Knoten von Amazon Linux 1 und Amazon Linux 2 verwenden Yum als Paketmanager. Amazon Linux 2022 und Amazon Linux 2023 werden DNF als Paketmanager verwendet.

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.

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 werden DNF als Paketmanager verwendet. 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 Repositorys 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 DNF werden als Paketmanager verwendet. 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. RHUI3 wurde im Dezember 2019 gestartet und führte ein anderes Benennungsschema für das Yum-Repository ein. IDs Abhängig von der -7 RHEL 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: STR 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 verfügbar sind (WSUS).

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 Manager-Betriebs erfüllt, auch wenn ein kritischer Patch aus dem Vormonat möglicherweise nicht installiert wurde. Das gleiche Szenario kann auftreten, wenn der ApproveAfterDays Parameter verwendet wird. 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) geändert haben, um den abgelösten Patch auf Ihren verwalteten Knoten verfügbar zu machen.

Anmerkung

In einigen Fällen veröffentlicht Microsoft Patches für Anwendungen, die kein Datum und keine Uhrzeit der Aktualisierung angeben. In diesen Fällen wird ein aktualisiertes Datum und eine Uhrzeit von 01/01/1970 standardmäßig angegeben.