Wie Patches installiert 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 Patches installiert werden

Patch Manager, ein Tool in AWS Systems Manager, verwendet den für einen Betriebssystemtyp geeigneten integrierten Mechanismus, um Updates auf einem verwalteten Knoten zu installieren. Beispiel: Unter Windows Server wird die Windows Update-API verwendet und unter Amazon Linux 2 wird der yum-Paketmanager verwendet.

Patch Managerinstalliert kein neues Paket, das ein veraltetes Paket ersetzt, das derzeit installiert ist. (Ausnahmen: Das neue Paket hängt davon ab, ob ein anderes Paket-Update installiert wird, oder das neue Paket hat denselben Namen wie das veraltete Paket.) Stattdessen Patch Manager meldet und installiert verfügbare Updates für installierte Pakete. Dieser Ansatz trägt dazu bei, unerwartete Änderungen an der Systemfunktionalität zu verhindern, die auftreten können, wenn ein Paket ein anderes ersetzt.

Wenn Sie ein veraltetes Paket deinstallieren und dessen Ersatz installieren müssen, müssen Sie möglicherweise ein benutzerdefiniertes Skript verwenden oder Paketmanager-Befehle außerhalb der Patch Manager Standardoperationen verwenden.

Wählen Sie aus den folgenden Registerkarten, um zu erfahren, wie Patch Manager Patches auf einem Betriebssystem installiert.

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

Auf von Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 und Amazon Linux 2023 verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

  1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den InstallOverrideList-Parameter für die AWS-RunPatchBaseline- oder AWS-RunPatchBaselineAssociation-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

  2. Wenden Sie GlobalFilters wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.

  3. Wenden Sie ApprovalRules wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

    Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen Mit nicht sicherheitsrelevanten Updates beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

    Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.

    Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

  4. Wenden Sie ApprovedPatches wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von GlobalFilters verworfen wurden oder wenn keine in ApprovalRules festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

  5. Wenden Sie RejectedPatches wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

  6. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

  7. Die YUM-Aktualisierungs-API (Amazon Linux 1, Amazon Linux 2) oder die DNF-Aktualisierungs-API (Amazon Linux 2022, Amazon Linux 2023) wird wie folgt auf genehmigte Patches angewendet:

    • Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, werden nur die in updateinfo.xml angegebenen Patches angewendet (nur Sicherheitsupdates). Dies liegt daran, dass das Kontrollkästchen Funktionsupdates einschließen nicht aktiviert ist. Die vordefinierten Baselines entsprechen einer benutzerdefinierten Baseline mit folgenden Eigenschaften:

      • Das Kontrollkästchen Funktionsupdates einschließen ist nicht aktiviert

      • Eine Liste des SCHWEREGRADE von [Critical, Important]

      • Eine Liste der KLASSIFIZIERUNGEN von [Security, Bugfix]

      Für Amazon Linux 1 und Amazon Linux 2 lautet der entsprechende YUM-Befehl für diesen Workflow:

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      Für Amazon Linux 2022 und Amazon Linux 2023 lautet der entsprechende dnf-Befehl für diesen Workflow:

      sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

      Wenn das Kontrollkästchen Funktionsupdates einschließen aktiviert ist, werden alle Patches angewendet (Sicherheits- und Funktionsupdates), die in updateinfo.xml und nicht in updateinfo.xml sind.

      Für Amazon Linux 1 und Amazon Linux 2, wenn eine Baseline mit Funktionsupdates einschließen ausgewählt ist, und die eine SCHWEREGRAD-Liste von [Critical, Important] und eine KLASSIFIKATION-Liste von [Security, Bugfix] hat, lautet der entsprechende yum-Befehl:

      sudo yum update --security --sec-severity=Critical,Important --bugfix -y

      Für Amazon Linux 2022 und Amazon Linux 2023 lautet der entsprechende dnf-Befehl:

      sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
      Anmerkung

      Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese yum oder dnf Befehle außerhalb von ausführen. Patch Manager Sie werden jedoch nicht mit den entsprechenden Patch Manager Vorgängen installiert.

      Anmerkung

      Für Amazon Linux 2022 und Amazon Linux 2023 entspricht ein Patch-Schweregrad von Medium einem Schweregrad von Moderate, der in einigen externen Repositories definiert sein könnte. Wenn Sie Patches mit dem Medium-Schweregrad in die Patch-Baseline aufnehmen, werden auch Patches mit dem Moderate-Schweregrad von externen Patches auf den Instances installiert.

      Wenn Sie Konformitätsdaten mit der API-Aktion DescribeInstancePatches abfragen, werden beim Filtern nach dem Schweregrad Medium Patches mit den Schweregraden Medium und Moderate gemeldet.

      Amazon Linux 2022 und Amazon Linux 2023 unterstützen auch den Patch-Schweregrad None, der vom DNF-Paketmanager erkannt wird.

  8. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.)

CentOS and CentOS Stream

Auf von CentOS und CentOS Stream verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

  1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den InstallOverrideList-Parameter für die AWS-RunPatchBaseline- oder AWS-RunPatchBaselineAssociation-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

    Wenden Sie GlobalFilters wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.

  2. Wenden Sie ApprovalRules wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

    Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen Mit nicht sicherheitsrelevanten Updates beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

    Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.

    Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

  3. Wenden Sie ApprovedPatches wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von GlobalFilters verworfen wurden oder wenn keine in ApprovalRules festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

  4. Wenden Sie RejectedPatches wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

  5. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

  6. Auf genehmigte Patches wird die YUM-Update-API (auf CentOS 6.x und 7.x Versionen) oder das DNF-Update (auf CentOS 8 und CentOS Stream) angewendet.

  7. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.)

Debian Server and Raspberry Pi OS

Auf Debian Server und Raspberry Pi OS (früher Rasbian) Instances sieht der Patch-Installations-Workflow wie folgt aus:

  1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den InstallOverrideList-Parameter für die AWS-RunPatchBaseline- oder AWS-RunPatchBaselineAssociation-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

  2. Wenn eine Aktualisierung für python3-apt (eine Python-Bibliotheks-Schnittstelle zu libapt) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option Mit nicht sicherheitsrelevanten Updates nicht ausgewählt haben.)

    Wichtig

    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 die folgenden zusätzlichen Schritte aus, um sicherzustellen, dass Patch-Operationen erfolgreich ausgeführt werden:

    1. Auf Ihrem verwalteten Knoten wird der Verweis auf das Repository jessie-backports aus der Liste der Quellspeicherorte (/etc/apt/sources.list.d/jessie-backports) auskommentiert. Daher wird nicht versucht, Patches von diesem Speicherort herunterzuladen.

    2. Ein Signaturschlüssel für Stretch-Sicherheitsupdates wird importiert. Dieser Schlüssel stellt die erforderlichen Berechtigungen für die Aktualisierungs- und Installationsoperationen auf Debian Server 8.*-Distributionen bereit.

    3. Zu diesem Zeitpunkt wird eine apt-get-Operation ausgeführt, um sicherzustellen, dass die neueste Version von python3-apt installiert ist, bevor der Patch-Prozess beginnt.

    4. Wenn die Installation abgeschlossen ist, wird der Verweis auf das Repository jessie-backports wiederhergestellt und der Signaturschlüssel wird aus dem Schlüsselbund von APT Sources entfernt. Dies erfolgt, damit die Systemkonfiguration so belassen wird, wie sie vor der Patch-Operation war.

    Wenn Patch Manager das nächste Mal das System aktualisiert, wird dieser Vorgang wiederholt.

  3. Wenden Sie GlobalFilters wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.

  4. Wenden Sie ApprovalRules wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

    Anmerkung

    Da es nicht möglich ist, die Veröffentlichungstermine von Update-Paketen für Debian Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

    Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen Mit nicht sicherheitsrelevanten Updates beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

    Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.

    Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

    Anmerkung

    Für Debian Server und Raspberry Pi OS sind Patch-Kandidaten-Versionen auf Patches beschränkt, die in debian-security enthalten sind.

  5. Wenden Sie ApprovedPatches wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von GlobalFilters verworfen wurden oder wenn keine in ApprovalRules festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

  6. Wenden Sie RejectedPatches wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

  7. Die APT-Bibliothek wird verwendet, um Upgrades für Pakete durchzuführen.

    Anmerkung

    Patch Manager unterstützt nicht die Verwendung der Pin-Priority-APT-Option, um Paketen Prioritäten zuzuweisen. Patch Manager aggregiert verfügbare Updates aus allen aktivierten Repositorys und wählt das neueste Update aus, das der Baseline für jedes installierte Paket entspricht.

  8. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.)

macOS

Auf von macOS verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

  1. Die /Library/Receipts/InstallHistory.plist-Eigenschaft ist ein Datensatz der Software, die mit den softwareupdate- und installer-Paketmanagern installiert und aktualisiert wurde. Unter Verwendung derpkgutil-Befehlszeilen-Tool (für installer) und des softwareupdate-Paketmanagers werden CLI-Befehle ausgeführt, um diese Liste zu analysieren.

    Für installer umfasst die Antwort auf die CLI-Befehle Details zu package name, version, volume, location und install-time, aber nur der package name und die version werden von Patch Manager verwendet.

    Für softwareupdate umfasst die Antwort auf die CLI-Befehle den Paketnamen (display name),version unddate, aber nur der Paketname und die Version werden vom Patch Manager verwendet.

    Für Brew and Brew Cask unterstützt Homebrew seine Befehle, die unter dem Root-Benutzer ausgeführt werden, nicht. Darum fragt Patch Manager entweder als Eigentümer des Homebrew-Verzeichnisses oder als gültiger Benutzer,der zur Eigentümergruppe des Homebrew-Verzeichnisses gehört, Homebrew–Befehle ab und führt sie aus. Die Befehle sind ähnlich wie softwareupdate und installer und werden durch einen Python-Subprozess ausgeführt, um Paketdaten zu sammeln. Die Ausgabe wird dann analysiert, um Paketnamen und -versionen zu identifizieren.

  2. Wenden Sie GlobalFilters wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.

  3. Wenden Sie ApprovalRules wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

  4. Wenden Sie ApprovedPatches wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von GlobalFilters verworfen wurden oder wenn keine in ApprovalRules festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

  5. Wenden Sie RejectedPatches wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

  6. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

  7. Ruft die entsprechende Paket-CLI auf dem verwalteten Knoten auf, um genehmigte Patches wie folgt zu verarbeiten:

    Anmerkung

    installer fehlt die Funktion, um nach Updates zu suchen und sie zu installieren. Daher meldet Patch Manager für installer nur, welche Pakete installiert sind. Das Ergebnis: installer-Pakete werden nie als Missing gemeldet.

    • Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, und für benutzerdefinierte Patch-Baselines, bei denen das Kästchen Funktionsupdates einschließen nicht ausgewählt wurde, werden nur Sicherheitsupdates angewendet.

    • Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen Funktionsupdates einschließen aktiviert ist, werden sowohl Sicherheits- als auch Funktionsupdates angewendet.

  8. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.)

Oracle Linux

Auf von Oracle Linux verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

  1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den InstallOverrideList-Parameter für die AWS-RunPatchBaseline- oder AWS-RunPatchBaselineAssociation-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

  2. Wenden Sie GlobalFilters wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.

  3. Wenden Sie ApprovalRules wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

    Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen Mit nicht sicherheitsrelevanten Updates beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

    Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.

    Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

  4. Wenden Sie ApprovedPatches wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von GlobalFilters verworfen wurden oder wenn keine in ApprovalRules festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

  5. Wenden Sie RejectedPatches wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

  6. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

  7. Auf von Version 7 verwalteten Knoten wird die YUM-Update-API wie folgt auf genehmigte Patches angewendet:

    • Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, und für benutzerdefinierte Patch-Baselines, bei denen das Kästchen Funktionsupdates einschließen nicht ausgewählt wurde, werden nur Patches, die in updateinfo.xml angegeben sind (nur Sicherheitsupdates), angewendet.

      Der entsprechende Yum-Befehl für diesen Workflow lautet:

      sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y

    • Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen Funktionsupdates einschließen aktiviert ist, werden sowohl Patches aus der Datei updateinfo.xml als auch solche, die nicht in updateinfo.xml enthalten sind, angewendet (sowohl Sicherheits- als auch Funktionsupdates).

      Der entsprechende Yum-Befehl für diesen Workflow lautet:

      sudo yum update --security --bugfix -y

      Auf von Version 8 und 9 verwalteten Knoten wird die DNF-Update-API wie folgt auf genehmigte Patches angewendet:

      • Für vordefinierte Standard-Patch-Baselines, die von bereitgestellt werden AWS, und für benutzerdefinierte Patch-Baselines, bei denen das Kontrollkästchen Nicht sicherheitsrelevante Updates einbeziehen nicht aktiviert ist, updateinfo.xml werden nur die in angegebenen Patches angewendet (nur Sicherheitsupdates).

        Der entsprechende Yum-Befehl für diesen Workflow lautet:

        sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important

      • Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen Funktionsupdates einschließen aktiviert ist, werden sowohl Patches aus der Datei updateinfo.xml als auch solche, die nicht in updateinfo.xml enthalten sind, angewendet (sowohl Sicherheits- als auch Funktionsupdates).

        Der entsprechende Yum-Befehl für diesen Workflow lautet:

        sudo dnf upgrade --security --bugfix
    Anmerkung

    Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese oder Befehle außerhalb von ausführen. yum dnf Patch Manager Sie werden jedoch nicht mit den entsprechenden Patch Manager Vorgängen installiert.

  8. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.)

AlmaLinux, RHEL, and Rocky Linux

Auf AlmaLinuxRed Hat Enterprise Linux, und Rocky Linux verwalteten Knoten sieht der Arbeitsablauf für die Installation von Patches wie folgt aus:

  1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den InstallOverrideList-Parameter für die AWS-RunPatchBaseline- oder AWS-RunPatchBaselineAssociation-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

  2. Wenden Sie GlobalFilters wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.

  3. Wenden Sie ApprovalRules wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

    Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen Mit nicht sicherheitsrelevanten Updates beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

    Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.

    Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

  4. Wenden Sie ApprovedPatches wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von GlobalFilters verworfen wurden oder wenn keine in ApprovalRules festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

  5. Wenden Sie RejectedPatches wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

  6. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

  7. Die YUM-Update-API (auf RHEL 7) oder die DNF-Update-API (auf AlmaLinux 8 und 9, RHEL 8 und 9 und Rocky Linux 8 und 9) wird gemäß den folgenden Regeln auf genehmigte Patches angewendet:

     

    Szenario 1: Nicht sicherheitsrelevante Updates ausgeschlossen

    • Gilt für: Vordefinierte Standard-Patch-Baselines, die von bereitgestellt werden, AWS und benutzerdefinierte Patch-Baselines.

    • Kontrollkästchen „Nicht sicherheitsrelevante Updates einbeziehen“: Nicht ausgewählt.

    • Angewendete Patches: Die unter updateinfo.xml (nur Sicherheitsupdates) angegebenen Patches werden nur angewendet, wenn sie beide der Patch-Basiskonfiguration entsprechen und sich in den konfigurierten Repos befinden.

      In einigen Fällen ist ein in spezifizierter Patch updateinfo.xml möglicherweise nicht mehr in einem konfigurierten Repository verfügbar. Konfigurierte Repos verfügen normalerweise nur über die neueste Version eines Patches, bei dem es sich um einen kumulativen Rollup aller vorherigen Updates handelt. Die neueste Version entspricht jedoch möglicherweise nicht den Patch-Basisregeln und wird beim Patchen nicht berücksichtigt.

    • Befehle: Für RHEL 7 lautet der entsprechende Yum-Befehl für diesen Workflow: 

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      Für AlmaLinux, RHEL 8 undRocky Linux, lauten die entsprechenden dnf-Befehle für diesen Workflow:

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
    Szenario 2: Nicht sicherheitsrelevante Updates enthalten

    • Gilt für: Benutzerdefinierte Patch-Baselines.

    • Kontrollkästchen „Nicht sicherheitsrelevante Updates einbeziehen“: Ausgewählt.

    • Angewendete Patches: Eingeschlossene updateinfo.xml und nicht installierte Patches updateinfo.xml werden angewendet (Sicherheitsupdates und nicht sicherheitsrelevante Updates).

    • Befehle: Für RHEL 7 lautet der entsprechende yum-Befehl für diesen Workflow:

      sudo yum update --security --bugfix -y

      Für AlmaLinux 8 und 9, RHEL 8 und 9 sowie Rocky Linux 8 und 9 lautet der entsprechende dnf-Befehl für diesen Workflow:

      sudo dnf update --security --bugfix -y
    Anmerkung

    Neue Pakete, die inzwischen veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese yum oder dnf Befehle außerhalb von ausführen. Patch Manager Sie werden jedoch nicht mit den entsprechenden Patch Manager Vorgängen installiert.

  8. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.)

SLES

Auf von SUSE Linux Enterprise Server (SLES) verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

  1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den InstallOverrideList-Parameter für die AWS-RunPatchBaseline- oder AWS-RunPatchBaselineAssociation-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

  2. Wenden Sie GlobalFilters wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.

  3. Wenden Sie ApprovalRules wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

    Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen Mit nicht sicherheitsrelevanten Updates beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

    Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.

    Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

  4. Wenden Sie ApprovedPatches wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von GlobalFilters verworfen wurden oder wenn keine in ApprovalRules festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

  5. Wenden Sie RejectedPatches wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

  6. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

  7. Die Zypper-Update-API wird auf genehmigte Patches angewendet.

  8. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.)

Ubuntu Server

Auf von Ubuntu Server verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

  1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den InstallOverrideList-Parameter für die AWS-RunPatchBaseline- oder AWS-RunPatchBaselineAssociation-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

  2. Wenn eine Aktualisierung für python3-apt (eine Python-Bibliotheks-Schnittstelle zu libapt) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option Mit nicht sicherheitsrelevanten Updates nicht ausgewählt haben.)

  3. Wenden Sie GlobalFilters wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.

  4. Wenden Sie ApprovalRules wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

    Anmerkung

    Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

    Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen Mit nicht sicherheitsrelevanten Updates beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

    Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.

    Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

    Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen Mit nicht sicherheitsrelevanten Updates beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

    Anmerkung

    Für jede Version von Ubuntu Server sind die Patchkandidatenversionen wie folgt auf Patches beschränkt, die Teil des zugehörigen Repositorys für diese Version 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-lobster

  5. Wenden Sie ApprovedPatches wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von GlobalFilters verworfen wurden oder wenn keine in ApprovalRules festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

  6. Wenden Sie RejectedPatches wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

  7. Die APT-Bibliothek wird verwendet, um Upgrades für Pakete durchzuführen.

    Anmerkung

    Patch Manager unterstützt nicht die Verwendung der Pin-Priority-APT-Option, um Paketen Prioritäten zuzuweisen. Patch Manager aggregiert verfügbare Updates aus allen aktivierten Repositorys und wählt das neueste Update aus, das der Baseline für jedes installierte Paket entspricht.

  8. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.)

Windows Server

Wenn eine Patch-Operation auf einem von Windows Server verwalteten Knoten durchgeführt wird, fordert die Instance einen Snapshot der entsprechenden Patch-Baseline von Systems Manager an. Dieser Snapshot enthält die Liste aller in der Patch-Baseline verfügbaren Updates, die für die Bereitstellung genehmigt wurden. Diese Liste der Updates wird an die Windows-Update-API gesendet, die festlegt, welche Updates für den verwalteten Knoten zutreffen, und diese bei Bedarf installiert. Windows erlaubt nur die Installation der neuesten verfügbaren Version einer KB. Patch Manager installiert die neueste Version einer KB, wenn sie oder eine frühere Version der KB mit der angewendeten Patch-Baseline übereinstimmt. Wenn Updates installiert sind, wird der verwaltete Knoten danach so oft wie nötig neu gestartet, bis alle erforderlichen Patches abgeschlossen sind. (Ausnahme: Wenn der RebootOption-Parameter im NoReboot-Dokument auf AWS-RunPatchBaseline gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter Parametername: RebootOption.) Die Zusammenfassung des Patch-Vorgangs finden Sie in der Ausgabe der Run Command-Anfrage. Zusätzliche Protokolle finden Sie auf dem verwalteten Knoten im %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs-Ordner.

Da die Windows Update-API zum Herunterladen und Installieren verwendet wird KBs, werden alle Gruppenrichtlinieneinstellungen für Windows Update berücksichtigt. Für die Verwendung von Patch Manager sind keine Gruppenrichtlinien-Einstellungen erforderlich. Allerdings werden alle definierten Einstellungen angewendet, wie etwa die Weiterleitung von verwalteten Knoten an einen Windows Server Update Services (WSUS)-Server.

Anmerkung

Standardmäßig lädt Windows alles KBs von der Windows Update-Website von Microsoft herunter, da die Windows Update-API Patch Manager verwendet wird, um den Download und die Installation von voranzutreiben KBs. Der verwaltete Knoten muss daher die Website von Microsoft Windows Update erreichen können. Andernfalls tritt ein Fehler bei der Patch-Operation auf. Alternativ können Sie einen WSUS-Server als KB-Repository konfigurieren und Ihre verwalteten Knoten so konfigurieren, dass sie den WSUS-Server anvisieren, anstatt Gruppenrichtlinien zu verwenden.

Patch Managerverweist möglicherweise auf KB, IDs wenn benutzerdefinierte Patch-Baselines für erstellt werdenWindows Server, z. B. wenn eine Liste zulässiger Patches oder abgelehnter Patches in der Basiskonfiguration enthalten ist. Nur Updates, denen in Microsoft Windows Update oder einem WSUS-Server eine KB-ID zugewiesen wurde, werden von Patch Manager installiert. Updates, denen eine KB-ID fehlt, sind nicht in den Patchvorgängen enthalten.

Informationen zum Erstellen benutzerdefinierter Patch-Baselines finden Sie in den folgenden Themen: