Creazione di una baseline delle patch personalizzata per Linux - AWS Systems Manager

Creazione di una baseline delle patch personalizzata per Linux

Utilizza la procedura seguente per creare una baseline delle patch personalizzata per i nodi gestiti da Linux in Patch Manager, uno strumento di AWS Systems Manager.

Per informazioni sulla creazione di una patch di base per i nodi gestiti macOS, vedi Creazione di una baseline delle patch personalizzata per macOS. Per informazioni sulla creazione di una patch di base per i nodi gestiti di Windows, consulta Creazione di una baseline delle patch personalizzata per Windows Server.

Per creare una patch di base personalizzata per i nodi gestiti da Linux
  1. Aprire la console AWS Systems Manager all'indirizzo https://console.aws.amazon.com/systems-manager/.

  2. Nel pannello di navigazione, scegli Patch Manager.

  3. Scegli la scheda Patch di base e quindi Crea patch di base.

    oppure

    Se è la prima volta che accedi a Patch Manager nella Regione AWS corrente, scegli Inizia da una panoramica, scegli la scheda Patch di base e quindi Crea una base di patch.

  4. Nel campo Nome inserisci il nome della nuova patch di base, ad esempio MyRHELPatchBaseline.

  5. (Facoltativo) Per Descrizione, inserisci una descrizione per questa patch di base.

  6. Per Sistema operativo, scegli un sistema operativo, ad esempio Red Hat Enterprise Linux.

  7. Se desideri cominciare a utilizzare subito la patch di base appena creata come impostazione predefinita per il sistema operativo selezionato, spunta la casella Rendi predefinita questa patch di base per le istanze di nome del sistema operativo.

    Nota

    Questa opzione è disponibile solo se hai effettuato l'accesso per la prima volta a Patch Manager prima del rilascio delle policy di patch del 22 dicembre 2022.

    Per informazioni sull'impostazione di una patch di base esistente come predefinita, consulta Impostare una base di patch esistente come predefinita.

  8. Nella sezione Regole di approvazione per sistema operativo utilizza i campi per creare una o più regole di approvazione automatica.

    • Prodotti: la versione del sistema operativo a cui si applica la regola di approvazione, ad esempio RedhatEnterpriseLinux7.4. L'opzione predefinita è All.

    • Classificazione: il tipo di patch a cui si applica la regola di approvazione, ad esempio Security o Enhancement. L'opzione predefinita è All.

      Suggerimento

      È possibile configurare una patch di base per controllare se sono installati aggiornamenti di versione secondaria per Linux, ad esempio RHEL 7.8. Aggiornamenti di versione secondari possono essere installati in automatico da Patch Manager a condizione che l'aggiornamento sia disponibile nel repository appropriato.

      Per i sistemi operativi Linux, gli aggiornamenti delle versioni secondari non sono classificati in modo coerente. Possono essere classificati come correzioni di bug o aggiornamenti di sicurezza, o non classificati, anche all'interno della stessa versione del kernel. Ecco alcune opzioni per controllare se una base di patch ne esegue l'installazione.

      • Opzione 1: la regola di approvazione più ampia per garantire l'installazione di aggiornamenti di versioni secondarie quando disponibili consiste nello specificare il campo Classificazione come All (*) e scegliere l'opzione Includi aggiornamenti non relativi alla sicurezza.

      • Opzione 2: per garantire che siano installate patch per una versione del sistema operativo, è possibile utilizzare un carattere jolly (*) per specificare il formato del kernel nella sezione Eccezioni patch della patch di base. Ad esempio, il formato del kernel per RHEL 7.* è kernel-3.10.0-*.el7.x86_64.

        Immettere kernel-3.10.0-*.el7.x86_64 nell'elenco Approved patches (Patch approvate) nella patch di base per assicurarsi che tutte le patch, inclusi gli aggiornamenti delle versioni secondarie, vengano applicate ai nodi gestiti RHEL 7.*. (Se conosci il nome esatto del pacchetto di una patch di versione secondaria, è possibile inserirlo quello invece.)

      • Opzione 3: è possibile avere il massimo controllo sulle patch applicate ai nodi gestiti, inclusi gli aggiornamenti di versione secondari, utilizzando il parametro InstallOverrideList nel documento AWS-RunPatchBaseline. Per ulteriori informazioni, consulta Documento di comando SSM per l'applicazione di patch: AWS-RunPatchBaseline.

    • Gravità: il valore di gravità delle patch a cui si applica la regola, ad esempio Critical. L'opzione predefinita è All.

    • Approvazione automatico: il metodo per selezionare le patch per l'approvazione automatica.

      Nota

      Poiché non è possibile determinare in modo affidabile le date di rilascio dei pacchetti di aggiornamento per Ubuntu Server, le opzioni di approvazione automatica non sono supportate per questo sistema operativo.

      • Approva le patch dopo un determinato numero di giorni: il numero di giorni in cui Patch Manager Patch Manager deve attendere dopo il rilascio o l'ultimo aggiornamento di una patch prima che una patch venga approvata automaticamente. È possibile inserire qualsiasi numero intero da zero (0) a 360. Per la maggior parte degli scenari, consigliamo di attendere non più di 100 giorni.

      • Approva le patch rilasciate fino a una data specifica: la data di rilascio delle patch per la quale Patch Manager applica automaticamente tutte le patch rilasciate o aggiornate prima di tale data (inclusa). Ad esempio, se specifichi il 7 luglio 2023, nessuna patch rilasciata o aggiornata a partire dall'8 luglio 2023 verrà installata automaticamente.

    • (Facoltativo) Report di conformità: il livello di gravità da assegnare alle patch approvate dalla linea di base, ad esempio Critical o High.

      Nota

      Se specifichi un livello di report di conformità e lo stato delle patch approvate viene riportato come Missing, la gravità di conformità complessiva riportata dalla patch di base corrisponde al livello di gravità specificato.

    • Includi aggiornamenti non relativi alla sicurezza: seleziona la casella per installare le patch del sistema operativo Linux non relative alla sicurezza disponibili nel repository di origine, oltre a quelle relative alla sicurezza.

    Per ulteriori informazioni sulle operazioni con le regole di approvazione in una patch di base personalizzata, consulta Baseline personalizzate.

  9. Per approvare esplicitamente qualsiasi patch oltre a quelle che soddisfano le regole di approvazione, procedere come segue nella sezione Eccezioni patch:

    • In Patch approvate, inserisci un elenco separato da virgole delle patch che desideri approvare.

      Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate.

    • (Facoltativo) In Livello di conformità patch approvate, assegna un livello di conformità alle patch dell'elenco.

    • Se qualche patch approvata e specificata non è correlata alla sicurezza, seleziona la casella di controllo Includi aggiornamenti non critici per installare anche queste patch sul sistema operativo Linux.

  10. Per rifiutare esplicitamente qualsiasi patch oltre che comunque soddisfano le regole di approvazione, procedere come segue nella sezione Eccezioni patch:

    • In Patch rifiutate, inserisci un elenco separato da virgole delle patch che desideri rifiutare.

      Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate.

    • In Operazione patch rifiutate, seleziona l'operazione che Patch Manager effettuerà sulle patch incluse nell'elenco Patch rifiutate.

      • Consenti come dipendenza: un pacchetto dell'elenco Patch rifiutate viene installato solo se è incluso automaticamente in un altro pacchetto. È considerato conforme alla base di patch e il relativo stato risulta InstalledOther. Si tratta dell'operazione predefinita se non viene specificata alcuna opzione.

      • Blocca: i pacchetti dell'elenco Patch rifiutate e quelli che le includono come dipendenze non verranno installati da Patch Manager in alcun caso. Se un pacchetto è stato installato prima di essere stato aggiunto all'elenco Patch rifiutate, oppure è stato successivamente installato fuori da Patch Manager, viene considerato non conforme alla baseline delle patch e il relativo stato è InstalledRejected.

    Nota

    Patch Manager cerca le dipendenze delle patch in modo ricorsivo.

  11. (Facoltativo) Per specificare repository di patch alternativi per altre versioni di un sistema operativo, ad esempio AmazonLinux2016.03 e AmazonLinux2017.09, completa la procedura seguente per ogni prodotto della sezione Origini patch:

    • In Nome, inserisci un nome per semplificare l'identificazione della configurazione di origine.

    • In Prodotto, seleziona la versione dei sistemi operativi a cui è destinato il repository di origine delle patch, ad esempio RedhatEnterpriseLinux7.4.

    • In Configurazione, immetti il valore della configurazione del repository da utilizzare nel formato appropriato:

      Example for yum repositories
      [main] name=MyCustomRepository baseurl=https://my-custom-repository enabled=1
      Suggerimento

      Per informazioni sulle altre opzioni disponibili per la configurazione del repository yum, consulta dnf.conf(5).

      Examples for Ubuntu Server and Debian Server

      deb http://security.ubuntu.com/ubuntu jammy main

      deb https://site.example.com/debian distribution component1 component2 component3

      Le informazioni sui repository per quelli di Ubuntu Server devono essere specificate in un'unica riga. Per ulteriori esempi e informazioni, consulta jammy (5) sources.list.5.gz sul sito web dei Manuali di Ubuntu Server e il formato sources.list sulla Wiki Debian.

      Sceglie Aggiungi un'altra origine per specificare un repository di origine per ciascuna versione aggiuntiva del sistema operativo, fino a un massimo di 20.

      Per ulteriori informazioni sui repository di patch di origine alternativi, consulta Come specificare un repository alternativo di origine delle patch (Linux).

  12. (Facoltativo) In Gestisci tag, applica una o più coppie valore-nome di chiave di tag alla patch di base.

    I tag sono metadati facoltativi assegnati a una risorsa. Consentono di categorizzare una risorsa in diversi modi, ad esempio in base allo scopo, al proprietario o all'ambiente. Ad esempio, è possibile applicare tag a una patch di base per identificare il livello di gravità delle patch che specifica, la famiglia del sistema operativo a cui si applica e il tipo di ambiente. In questo caso è possibile specificare tag simili alle coppie valore-nome di chiave seguenti:

    • Key=PatchSeverity,Value=Critical

    • Key=OS,Value=RHEL

    • Key=Environment,Value=Production

  13. Scegli Crea una base di patch.