Erstellen einer benutzerdefinierten Patch-Baseline für Linux - 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.

Erstellen einer benutzerdefinierten Patch-Baseline für Linux

Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte Patch-Baseline für verwaltete Linux-Knoten in zu erstellen Patch Manager, eine Fähigkeit von AWS Systems Manager.

Informationen zum Erstellen einer Patch-Baseline für macOS verwaltete Knoten finden Sie unterErstellen einer benutzerdefinierten Patch-Baseline für macOS. Informationen zum Erstellen einer Patch-Baseline für Windows-verwaltete Knoten finden Sie unter Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server.

So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux-verwaltete Knoten
  1. Öffnen Sie die AWS Systems Manager Konsole unter https://console.aws.amazon.com/systems-manager/.

  2. Wählen Sie im Navigationsbereich Patch Manager.

  3. Wählen Sie die Registerkarte Patch-Baselines und dann Patch-Baseline erstellen aus.

    –oder–

    Wenn Sie darauf zugreifen Patch Manager Wählen Sie zum ersten Mal in der aktuellen Version AWS-Region„Mit einer Übersicht beginnen“, dann die Registerkarte „Patch-Baselines“ und anschließend „Patch-Baseline erstellen“ aus.

  4. Geben Sie im Feld Name (Name) einen Namen für die neue Patch-Baseline ein, z. B. MyRHELPatchBaseline.

  5. (Optional) Geben Sie im Feld Description (Beschreibung) eine Beschreibung für diese Patch-Baseline ein.

  6. Wählen Sie unter Operating system (Betriebssystem) ein Betriebssystem aus, z. B. Red Hat Enterprise Linux.

  7. Wenn Sie diese Patch-Baseline sofort nach der Erstellung als Standard für das ausgewählte Betriebssystem verwenden möchten, aktivieren Sie das Kontrollkästchen neben Diese Patch-Baseline als Standard-Patch-Baseline festlegen für operating system name Instanzen.

    Anmerkung

    Diese Option ist nur verfügbar, wenn Sie zuerst darauf zugegriffen haben Patch Manager vor der Veröffentlichung der Patch-Richtlinien am 22. Dezember 2022.

    Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter Festlegen einer vorhandenen Patch-Baseline als Standard.

  8. Erstellen Sie im Abschnitt Approval Rules for operating-systems (Genehmigungsregeln für Betriebssysteme) unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.

    • Produkte: Die Version der Betriebssysteme, auf die sich die Genehmigungsregel bezieht, z. B. RedhatEnterpriseLinux7.4. Die Standardauswahl ist All.

    • Classification (Klassifizierung): Der Typ der Patches, auf die sich die Genehmigungsregel bezieht, z. B. Security oder Enhancement. Die Standardauswahl ist All.

      Tipp

      Sie können eine Patch-Baseline konfigurieren, um zu steuern, ob kleinere Versionsupgrades für Linux installiert werden, z. B. RHEL 7.8. Kleinere Versionsupgrades können automatisch installiert werden von Patch Manager vorausgesetzt, das Update ist im entsprechenden Repository verfügbar.

      Im Fall von Linux-Betriebssystemen werden Nebenversionsupgrades nicht konsistent klassifiziert. Sie können als Fehlerbehebungen oder Sicherheitsupdates klassifiziert (oder nicht klassifiziert) werden, selbst innerhalb derselben Kernel-Version. Im Folgenden werden einige Optionen aufgelistet, mit denen Sie steuern können, ob sie von einer Patch-Baseline installiert werden.

      • Option 1: Die umfassendste Genehmigungsregel, die sicherzustellt, dass Nebenversionsupgrades installiert werden, wenn verfügbar, besteht in der Angabe von Classification (Klassifizierung) als All (*) und der Auswahl der Option Include nonsecurity updates (Auch andere Updates als Sicherheitsupdates einschließen).

      • Option 2: Um die Installation von Patches für eine Betriebssystemversion sicherzustellen, können Sie ein Platzhalterzeichen (*) verwenden, um das Kernel-Format im Abschnitt Patch exceptions (Patch-Ausnahmen) der Baseline anzugeben. Zum Beispiel das Kernel-Format für RHEL 7.* istkernel-3.10.0-*.el7.x86_64.

        Tragen Sie kernel-3.10.0-*.el7.x86_64 dies in die Liste der genehmigten Patches in Ihrer Patch-Baseline ein, um sicherzustellen, dass alle Patches, einschließlich kleinerer Versions-Upgrades, auf Ihr System angewendet werden RHEL 7.* verwaltete Knoten. (Wenn Sie den genauen Paketnamen eines Nebenversionspatches kennen, können Sie diesen stattdessen eingeben.)

      • Option 3: Mithilfe des InstallOverrideListParameters im AWS-RunPatchBaseline Dokument haben Sie die größtmögliche Kontrolle darüber, welche Patches auf Ihre verwalteten Knoten angewendet werden, einschließlich kleinerer Versions-Upgrades. Weitere Informationen finden Sie unter SSMBefehlsdokument für das Patchen: AWS-RunPatchBaseline.

    • Severity (Schweregrad): Der Schweregradwert von Patches, auf den die Regel anzuwenden ist, z. B. Critical. Die Standardauswahl ist All.

    • Auto-approval (Automatische Genehmigung): Die Methode zum Auswählen von Patches für die automatische Genehmigung.

      Anmerkung

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

      • Patches nach einer bestimmten Anzahl von Tagen genehmigen: Die Anzahl der Tage für Patch Manager um zu warten, bis ein Patch veröffentlicht oder zuletzt aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.

      • Genehmigen Sie Patches, die bis zu einem bestimmten Datum veröffentlicht wurden: Das Patch-Veröffentlichungsdatum, für das Patch Manager wendet automatisch alle Patches an, die an oder vor diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 07. Juli 2023 angeben, werden Patches, die am oder nach dem 08. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.

    • (Optional) Konformitätsbericht : Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. Critical oder High).

      Anmerkung

      Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als Missing gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.

    • Include non-security updates (Nicht sicherheitsrelevante Updates einbeziehen): Aktivieren Sie das Kontrollkästchen zum Installieren von nicht sicherheitsrelevanten Linux-Betriebssystem-Patches, die im Quell-Repository verfügbar gemacht wurden, zusätzlich zu den sicherheitsrelevanten Patches.

      Anmerkung

      Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. SUSE Linux Enterprise Server, (SLES) es ist nicht erforderlich, das Kontrollkästchen zu aktivieren, da Patches für Sicherheitsprobleme und andere Probleme standardmäßig installiert werden SLES verwaltete Knoten. Weitere Informationen finden Sie im Inhalt für SLES in Wie Sicherheitspatches ausgewählt werden erlauben.

    Weitere Informationen zum Arbeiten mit Genehmigungsregeln in einer benutzerdefinierten Patch-Baseline finden Sie unter Benutzerdefinierte Baselines.

  9. Wenn Sie zusätzlich zu den Patches, die Ihren Genehmigungsregeln entsprechen, alle Patches ausdrücklich genehmigen möchten, gehen Sie im Abschnitt Patch exceptions (Patch-Ausnahmen) wie folgt vor:

    • Geben Sie im Feld Approved patches (Genehmigte Patches) eine durch Komma getrennte Liste der Patches ein, die Sie genehmigen möchten.

      Anmerkung

      Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter Paketnamenformate für genehmigte und abgelehnte Patch-Listen.

    • (Optional) Weisen Sie in der Liste Approved patches compliance level (Compliance-Stufe genehmigter Patches) den Patches in der Liste eine Compliance-Stufe zu.

    • Wenn genehmigte Patches, die Sie angeben, nicht sicherheitsbezogen sind, wählen Sie das Kästchen Genehmigte Patches umfassen nicht sicherheitsrelevante Updates aus, damit diese Patches ebenfalls auf Ihrem Linux-Betriebssystem installiert werden.

  10. Wenn Sie Patches ablehnen möchten, die ansonsten Ihren Genehmigungsregeln entsprechen, gehen Sie im Abschnitt Patch exceptions (Patch-Ausnahmen) wie folgt vor:

    • Geben Sie im Feld Rejected patches (Abgelehnte Patches) eine durch Komma getrennte Liste der Patches ein, die Sie ablehnen möchten.

      Anmerkung

      Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter Paketnamenformate für genehmigte und abgelehnte Patch-Listen.

    • Wählen Sie unter Aktion „Abgelehnte Patches“ die Aktion für Patch Manager um Patches zu übernehmen, die in der Liste der abgelehnten Patches enthalten sind.

      • Allow as dependency (Als Abhängigkeit zulassen): Ein Paket in der Liste Rejected patches (Abgelehnte Patches) wird nur installiert, wenn es sich um eine Abhängigkeit eines anderen Pakets handelt. Es gilt als konform mit der Patch-Baseline und sein Status wird als gemeldet InstalledOther. Dies ist die Standardaktion, wenn keine Option ausgewählt ist.

      • Blockieren: Pakete in der Liste der abgelehnten Patches und Pakete, die sie als Abhängigkeiten enthalten, werden nicht von installiert Patch Manager unter allen Umständen. Wenn ein Paket installiert wurde, bevor es zur Liste der abgelehnten Patches hinzugefügt wurde, oder wenn es außerhalb von installiert wurde Patch Manager danach gilt es als nicht konform mit der Patch-Baseline und sein Status wird als gemeldet. InstalledRejected

    Anmerkung

    Patch Manager sucht rekursiv nach Patch-Abhängigkeiten.

  11. (Optional) Wenn Sie alternative Patch-Repositorys für verschiedene Versionen eines Betriebssystems angeben möchten, z. B. AmazonLinux2016.03 und AmazonLinux2017.09, gehen Sie für jedes Produkt im Abschnitt Patch-Quellen wie folgt vor:

    • Geben Sie in Name (Name) einen Namen ein, um Sie bei der Identifizierung der Quellkonfiguration zu unterstützen.

    • Wählen Sie unter Product (Produkt) die Version der Betriebssysteme aus, für die das Patch-Quell-Repository bestimmt ist, z. B. RedhatEnterpriseLinux7.4.

    • Geben Sie unter Configuration den Wert der zu verwendenden Yum-Repository-Konfiguration im folgenden Format ein:

      [main] name=MyCustomRepository baseurl=https://my-custom-repository enabled=1
      Tipp

      Informationen zu anderen Optionen für Ihre Yum-Repository-Konfiguration finden Sie unter dnf.conf (5).

      Wählen Sie Add another source aus, um ein Quell-Repository für jede zusätzliche Betriebssystemversion anzugeben, bis maximal 20.

      Weitere Informationen über alternative Quell-Patch-Repositorys finden Sie unter So geben Sie ein alternatives Patch-Quell-Repository an (Linux).

  12. (Optional) Wählen Sie für Manage tags (Tags verwalten) ein oder mehrere Tag-Schlüsselname/Wertpaare für die Patch-Baseline aus.

    Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Sie können beispielsweise eine Patch-Baseline kennzeichnen, um den Schweregrad der angegebenen Patches, die Betriebssystemfamilie, auf die sie sich bezieht, und den Umgebungstyp zu identifizieren. In diesem Fall können Sie etwa Tags mit den folgenden Schlüsselnamen/Wertpaaren angeben:

    • Key=PatchSeverity,Value=Critical

    • Key=OS,Value=RHEL

    • Key=Environment,Value=Production

  13. Wählen Sie die Option Create Patch Baseline.