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 entsprechenden integrierten Mechanismus für einen Betriebssystemtyp, 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 Manager installiert 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 meldet und installiert Patch Manager 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 Paket-Manager-Befehle außerhalb der Standardvorgänge von Patch Manager verwenden.

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

Amazon Linux 2 and Amazon Linux 2023

Auf von Amazon Linux 2 und Amazon Linux 2023 verwalteten Knoten sieht der Workflow der Patch-Installation 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 2) oder die DNF-Aktualisierungs-API (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 2 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt:

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

      Für Amazon Linux 2023 lautet der entsprechende DNF-Befehl für diesen Workflow wie folgt:

      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 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 2023 lautet der entsprechende DNF-Befehl wie folgt:

      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 Patch Manager ausführen. Sie werden jedoch nicht mit den entsprechenden Patch Manager-Vorgängen installiert.

      Zusätzliche Patchdetails für Amazon Linux 2023
      Support für den Schweregrad „Keine“

      Amazon Linux 2023 unterstützt auch den Patch-Schweregrad None, der vom DNF-Paket-Manager erkannt wird.

      Support für den Schweregrad „Mittel“

      Für Amazon Linux 2023 entspricht ein Patch-Schweregrad von Medium einem Schweregrad von Moderate, der möglicherweise in einigen externen Repositorys definiert ist. 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.

      Transitive Abhängigkeitsbehandlung für Amazon Linux 2023

      Für Amazon Linux 2023 installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden dnf-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).

      dnf upgrade-minimal --security installiert beispielsweise die Minimalversionen transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die neuesten verfügbaren Versionen derselben transitiven Abhängigkeiten.

  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 Stream

Auf von 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. Das DNF-Update auf CentOS Stream wird auf genehmigte Patches angewendet.

    Anmerkung

    Für CentOS Stream installiert Patch Manager möglicherweise andere Versionen transitiver Abhängigkeiten als die entsprechenden dnf-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).

    dnf upgrade-minimal ‐‐security installiert beispielsweise die Minimalversionen transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die neuesten verfügbaren Versionen derselben transitiven Abhängigkeiten.

  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

Auf Debian Server-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.)

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

        Für Oracle Linux installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden dnf-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).

        dnf upgrade-minimal --security installiert beispielsweise die Minimalversionen transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die neuesten verfügbaren Versionen derselben transitiven Abhängigkeiten.

      • 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 yum- oder dnf-Befehle außerhalb von Patch Manager ausführen. 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 AlmaLinux und Rocky Linux verwalteten Knoten Red Hat Enterprise Linux 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, 9 und 10 sowie 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.

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

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

      In einigen Fällen ist ein in updateinfo.xml spezifizierter Patch möglicherweise nicht mehr in einem konfigurierten Repository verfügbar. Konfigurierte Repositorys 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-Baseline-Regeln und wird beim Patchen nicht berücksichtigt.

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

      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
      Anmerkung

      For AlmaLinuxRHEL, und Rocky Linux Rocky Linux installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden dnf Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).

      dnf upgrade-minimal --security installiert beispielsweise die Minimalversionen transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die neuesten verfügbaren Versionen derselben transitiven Abhängigkeiten.

    Szenario 2: Nicht sicherheitsrelevante Updates enthalten

    • Gilt für: Benutzerdefinierte Patch-Baselines.

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

    • Angewendete Patches: Patches in updateinfo.xml und nicht in updateinfo.xml werden angewendet (Sicherheits- und andere Updates).

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

      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 veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese yum- oder dnf-Befehle außerhalb von Patch Manager ausführen. 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 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)

  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 für den Download und die Installation von Patch Manager verwendet wird 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: