Erstellen einer benutzerdefinierten Patch-Baseline für Linux

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

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

   –oder–

   Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie Mit einer Übersicht beginnen, wechseln Sie zur Registerkarte Patch-Baselines und wählen Sie dann Patch-Baseline erstellen.

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 vor der Veröffentlichung der Patch-Richtlinien am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.

   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 Nebenversions-Upgrades für Linux installiert werden, z. B. RHEL 7.8. Nebenversionsupgrades können vom Patch Manager automatisch installiert werden, wenn das Update im entsprechenden Repository verfügbar ist.

     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 ist das Kernel-Format für RHEL 7.* kernel-3.10.0-*.el7.x86_64.

       Geben Sie kernel-3.10.0-*.el7.x86_64 in der Liste Approved patches (Genehmigte Patches) in Ihrer Patch-Baseline ein, um die Anwendung aller Patches einschließlich Nebenversionsupgrades auf Ihren von RHEL 7.* verwalteten Knoten sicherzustellen. (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

     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.

     • Approve patches after a specified number of days (Patches nach einer bestimmten Anzahl von Tagen genehmigen): Die Anzahl der Tage, die der Patch Manager warten muss, nachdem 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.

     • Approve patches released up to a specific date (Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden): Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu 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

     Das Kontrollkästchen muss für SUSE Linux Enterprise Server (SLES), nicht aktiviert werden, da sicherheitsrelevante und nicht sicherheitsrelevante Patches standardmäßig auf SLES-verwaltete Knoten installiert werden. Weitere Informationen finden Sie im Content für SLES unter Wie Sicherheitspatches ausgewählt werden.

   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 in der Liste Rejected patches action (Aktion für abgelehnte Patches) die Aktion aus, die Patch Manager für Patches in der Liste Rejected patches (Abgelehnte Patches) ausführen soll.

      • 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 sowie Pakete, die diese als Abhängigkeiten enthalten, werden Patch Manager unter keinen Umständen installiert. Wenn ein Paket installiert wurde, bevor es zur Liste der abgelehnten Patches hinzugefügt wurde, oder wenn es außerhalb oder Patch Manager danach installiert wird, gilt es als nicht konform mit der Patch-Baseline und sein Status wird als gemeldet. InstalledRejected

    Anmerkung

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