Come vengono installate le patch - AWS Systems Manager

Come vengono installate le patch

Patch Manager, una funzionalità di AWS Systems Manager, utilizza il meccanismo integrato del sistema operativo per installare gli aggiornamenti in un nodo gestito. Ad esempio, in Windows Server, viene utilizzata l'API di Windows Update, mentre in Amazon Linux 2 viene utilizzato il gestore del pacchetto yum.

Scegli una delle seguenti schede per scoprire come Patch Manager installa le patch di sicurezza in un sistema operativo.

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

Su nodi gestiti da Amazon Linux 1, Amazon Linux 2 e Amazon Linux 2022 e Amazon Linux 2023, il flusso di lavoro di installazione delle patch è il seguente:

  1. Se un elenco delle patch viene specificato utilizzando un URL https o un URL in stile percorso Amazon Simple Storage Service (Amazon S3) utilizzando il parametro InstallOverrideList per i documenti AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, vengono installate le patch elencate e vengono ignorati i passaggi 2-7.

  2. Applicare GlobalFilters come specificato nella base di patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione.

  3. Applicare ApprovalRules come specificato nella base di patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

    Le norme di approvazione, tuttavia, sono anche soggette al fatto che la casella di spunta Includi aggiornamenti non correlati alla protezione è stata selezionata durante la creazione o l'ultimo aggiornamento di una base di patch.

    Se sono esclusi aggiornamenti non di sicurezza, viene applicata una regola implicita per selezionare solo i pacchetti con gli aggiornamenti nei repo di sicurezza. Per ciascun pacchetto, la versione candidata (in genere, quella più recente) deve fare parte di un repo di sicurezza.

    Se sono inclusi aggiornamenti non correlati alla protezione, vengono prese in considerazione anche le patch di altri repository.

  4. Applicare ApprovedPatches come specificato nella base di patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da GlobalFilters o se nessuna regola di approvazione specificata in ApprovalRules concede l'approvazione.

  5. Applicare RejectedPatches come specificato nella base di patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

  6. Se vengono approvate più versioni di una patch, verrà applicata quella più recente.

  7. L'API di aggiornamento YUM (Amazon Linux 1, Amazon Linux 2) o l'API di aggiornamento DNF (Amazon Linux 2022, Amazon Linux 2023) viene applicata alle patch approvate come segue:

    • Per le baseline delle patch predefinite fornite da AWS, vengono applicate solo le patch specificate in updateinfo.xml (solo aggiornamenti correlati alla sicurezza). Questo perché la casella di controllo Includi aggiornamenti non critici non è selezionata. Le baseline predefinite sono equivalenti a una baseline personalizzata con quanto segue:

      • La casella di controllo Includi aggiornamenti non critici non è selezionata

      • Un elenco di GRAVITÀ di [Critical, Important]

      • Un elenco di CLASSIFICAZIONE di [Security, Bugfix]

      Per Amazon Linux 1 e Amazon Linux 2, il comando yum equivalente per questo flusso di lavoro è:

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

      Per Amazon Linux 2022 e Amazon Linux 2023, il comando dfn equivalente per questo flusso di lavoro è:

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

      Quando la casella di controllo Includi aggiornamenti non critici è selezionata, vengono applicate entrambe le patch, quelle presenti in updateinfo.xml e quelle non presenti in updateinfo.xml (gli aggiornamenti correlati alla sicurezza e quelli non correlati alla sicurezza).

      Per Amazon Linux 1 e Amazon Linux 2, quando è selezionata una baseline con l'opzione Includi aggiornamenti non critici, l'elenco di GRAVITÀ è [Critical, Important] e l'elenco di CLASSIFICAZIONE è [Security, Bugfix], mentre il comando yum equivalente è:

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

      Per Amazon Linux 2022 e Amazon Linux 2023, il comando dnf equivalente è:

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

      Per Amazon Linux 2022 e Amazon Linux 2023, un livello di gravità delle patch pari a Medium è equivalente a una gravità di Moderate che potrebbe essere definita in alcuni repository esterni. Se includi le patch di gravità Medium nella patch di base, sulle istanze vengono installate anche le patch di gravità Moderate delle patch esterne.

      Quando esegui una query per i dati di conformità utilizzando l'operazione API DescribeInstancePatches, il filtro per il livello di gravità MediumMedium riporta le patch con entrambi i livelli di gravità e Moderate.

      Amazon Linux 2022 e Amazon Linux 2023 supportano anche il livello di gravità delle patch None, riconosciuto dal gestore di pacchetti DNF.

  8. Se sono stati installati aggiornamenti, il nodo gestito viene riavviato. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.)

CentOS and CentOS Stream

Di seguito è riportato il flusso di lavoro di installazione delle patch nei nodi gestiti CentOS e CentOS Stream:

  1. Se un elenco delle patch viene specificato utilizzando un URL https o un URL in stile percorso Amazon Simple Storage Service (Amazon S3) utilizzando il parametro InstallOverrideList per i documenti AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, vengono installate le patch elencate e vengono ignorati i passaggi 2-7.

    Applicare GlobalFilters come specificato nella base di patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione.

  2. Applicare ApprovalRules come specificato nella base di patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

    Le norme di approvazione, tuttavia, sono anche soggette al fatto che la casella di spunta Includi aggiornamenti non correlati alla protezione è stata selezionata durante la creazione o l'ultimo aggiornamento di una base di patch.

    Se sono esclusi aggiornamenti non di sicurezza, viene applicata una regola implicita per selezionare solo i pacchetti con gli aggiornamenti nei repo di sicurezza. Per ciascun pacchetto, la versione candidata (in genere, quella più recente) deve fare parte di un repo di sicurezza.

    Se sono inclusi aggiornamenti non correlati alla protezione, vengono prese in considerazione anche le patch di altri repository.

  3. Applicare ApprovedPatches come specificato nella base di patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da GlobalFilters o se nessuna regola di approvazione specificata in ApprovalRules concede l'approvazione.

  4. Applicare RejectedPatches come specificato nella base di patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

  5. Se vengono approvate più versioni di una patch, verrà applicata quella più recente.

  6. L'API di aggiornamento YUM (nelle versioni CentOS 6.x e 7.x) o l'aggiornamento DNF (su CentOS 8 e CentOS Stream) sono applicati alle patch approvate.

  7. Se sono stati installati aggiornamenti, il nodo gestito viene riavviato. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.)

Debian Server and Sistema Operativo Raspberry Pi

Di seguito è riportato il flusso di lavoro di installazione delle patch nelle istanze Debian Server e Raspberry Pi OS (ex Raspbian):

  1. Se un elenco delle patch viene specificato utilizzando un URL https o un URL in stile percorso Servizio di archiviazione semplice Amazon (Amazon S3) utilizzando il parametro InstallOverrideList per i documenti AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, vengono installate le patch elencate e vengono ignorati i passaggi 2-7.

  2. Se è disponibile un aggiornamento per python3-apt (un'interfaccia di libreria Python perlibapt), viene aggiornato alla versione più recente. (Questo pacchetto non correlato alla sicurezza viene aggiornato anche se non è stata selezionata l'opzione Includi aggiornamenti non correlati alla protezione).

    Importante

    Solo su Debian Server 8: poiché alcuni nodi gestiti di Debian Server 8.* fanno riferimento a un repository di pacchetti obsoleto (jessie-backports), Patch Manager esegue le seguenti fasi aggiuntive per garantire che le operazioni di applicazione di patch abbiano esito positivo:

    1. Sul tuo nodo gestito, il riferimento al jessie-backports repository viene commentato dall'elenco dei percorsi di origine (/etc/apt/sources.list.d/jessie-backports). Di conseguenza, non viene effettuato alcun tentativo di scaricare patch da tale posizione.

    2. Viene importata una chiave di firma dell'aggiornamento di protezione Stretch. Questa chiave fornisce le autorizzazioni necessarie per le operazioni di aggiornamento e installazione sulle distribuzioni Debian Server 8.*.

    3. A questo punto, viene eseguita l'operazione apt-get per assicurare che l'ultima versione di python3-apt sia installata prima dell'inizio del processo di applicazione di patch.

    4. Al termine del processo di installazione, il riferimento al repository jessie-backports viene ripristinato e la chiave di firma viene rimossa dal keyring delle sorgenti APT. Questa operazione viene eseguita per lasciare la configurazione del sistema com'era prima dell'operazione di applicazione di patch.

    La volta successiva che Patch Manager aggiorna il sistema, viene ripetuto lo stesso processo.

  3. Applicare GlobalFilters come specificato nella base di patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione.

  4. Applicare ApprovalRules come specificato nella base di patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

    Nota

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

    Le norme di approvazione, tuttavia, sono anche soggette al fatto che la casella di spunta Includi aggiornamenti non correlati alla protezione è stata selezionata durante la creazione o l'ultimo aggiornamento di una base di patch.

    Se sono esclusi aggiornamenti non di sicurezza, viene applicata una regola implicita per selezionare solo i pacchetti con gli aggiornamenti nei repo di sicurezza. Per ciascun pacchetto, la versione candidata (in genere, quella più recente) deve fare parte di un repo di sicurezza.

    Se sono inclusi aggiornamenti non correlati alla protezione, vengono prese in considerazione anche le patch di altri repository.

    Nota

    Per Debian Server e Raspberry Pi OS,, le versioni candidate alle patch sono limitate alle patch incluse in debian-security.

  5. Applicare ApprovedPatches come specificato nella base di patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da GlobalFilters o se nessuna regola di approvazione specificata in ApprovalRules concede l'approvazione.

  6. Applicare RejectedPatches come specificato nella base di patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

  7. La libreria APT viene utilizzata per aggiornare i pacchetti.

    Nota

    Patch Manager non supporta l'uso dell'opzione Pin-Priority APT per assegnare priorità ai pacchetti. Patch Manager aggrega gli aggiornamenti disponibili da tutti gli archivi abilitati e seleziona l'aggiornamento più recente che corrisponde alla baseline per ogni pacchetto installato.

  8. Se sono stati installati aggiornamenti, il nodo gestito viene riavviato. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.)

macOS

Sui nodi gestiti macOS, il flusso di lavoro di installazione delle patch funziona come riportato:

  1. L'elenco di proprietà /Library/Receipts/InstallHistory.plist è un record del software che è stato installato e aggiornato utilizzando la Gestione dei pacchetti softwareupdate e installer. Utilizzando lo strumento a riga di comando pkgutil (perinstaller) e il gestore di pacchetti softwareupdate, i comandi CLI vengono eseguiti per analizzare questo elenco.

    Per installer, la risposta ai comandi CLI include package name, version, volume, location, e i dettagli install-time, ma solo package name e version sono utilizzati da Patch Manager.

    Per softwareupdate, la risposta ai comandi CLI include il nome del pacchetto (display name),version, e date, ma solo il nome e la versione del pacchetto vengono utilizzati da Patch Manager.

    Per Brew e Brew Cask, Homebrew non supporta i suoi comandi eseguiti sotto l'utente root. Di conseguenza, Patch Manager esegue query ed esegue i comandi Homebrew come proprietario della directory Homebrew o come utente valido appartenente al gruppo proprietario della directory Homebrew. I comandi sono simili a softwareupdate e installer vengono eseguiti attraverso un sottoprocesso Python per raccogliere i dati del pacchetto, e il risultato viene analizzato per identificare i nomi e le versioni dei pacchetti.

  2. Applicare GlobalFilters come specificato nella base di patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione.

  3. Applicare ApprovalRules come specificato nella base di patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

  4. Applicare ApprovedPatches come specificato nella base di patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da GlobalFilters o se nessuna regola di approvazione specificata in ApprovalRules concede l'approvazione.

  5. Applicare RejectedPatches come specificato nella base di patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

  6. Se vengono approvate più versioni di una patch, verrà applicata quella più recente.

  7. Richiama l'interfaccia CLI del pacchetto idoneo sul nodo gestito per elaborare le patch approvate nel modo seguente:

    Nota

    installer manca della funzionalità per verificare e installare gli aggiornamenti. Pertanto, per installer, Patch Manager riportare solo i pacchetti che sono installati. Di conseguenza, i pacchetti installer non vengono mai segnalati come Missing.

    • Per le baseline delle patch predefinite fornite da AWS e per le baseline delle patch personalizzate in cui la casella di controllo Includi aggiornamenti non critici non è selezionata vengono applicati solo gli aggiornamenti correlati alla sicurezza.

    • Per le baseline delle patch personalizzate in cui la casella di controllo Includi aggiornamenti non critici è selezionata vengono applicati solo gli aggiornamenti correlati alla sicurezza.

  8. Se sono stati installati aggiornamenti, il nodo gestito viene riavviato. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.)

Oracle Linux

Sui nodi gestiti Oracle Linux, il flusso di lavoro di installazione delle patch funziona come riportato:

  1. Se un elenco delle patch viene specificato utilizzando un URL https o un URL in stile percorso Amazon Simple Storage Service (Amazon S3) utilizzando il parametro InstallOverrideList per i documenti AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, vengono installate le patch elencate e vengono ignorati i passaggi 2-7.

  2. Applicare GlobalFilters come specificato nella base di patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione.

  3. Applicare ApprovalRules come specificato nella base di patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

    Le norme di approvazione, tuttavia, sono anche soggette al fatto che la casella di spunta Includi aggiornamenti non correlati alla protezione è stata selezionata durante la creazione o l'ultimo aggiornamento di una base di patch.

    Se sono esclusi aggiornamenti non di sicurezza, viene applicata una regola implicita per selezionare solo i pacchetti con gli aggiornamenti nei repo di sicurezza. Per ciascun pacchetto, la versione candidata (in genere, quella più recente) deve fare parte di un repo di sicurezza.

    Se sono inclusi aggiornamenti non correlati alla protezione, vengono prese in considerazione anche le patch di altri repository.

  4. Applicare ApprovedPatches come specificato nella base di patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da GlobalFilters o se nessuna regola di approvazione specificata in ApprovalRules concede l'approvazione.

  5. Applicare RejectedPatches come specificato nella base di patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

  6. Se vengono approvate più versioni di una patch, verrà applicata quella più recente.

  7. Sui nodi gestiti della versione 7, l'API di aggiornamento YUM viene applicata alle patch approvate come segue:

    • Per le baseline delle patch predefinite fornite da AWS e per le baseline delle patch personalizzate in cui la casella di controllo Includi aggiornamenti non critici non è selezionata vengono applicate solo le patch specificate in updateinfo.xml (solo gli aggiornamenti correlati alla sicurezza).

      Il comando yum equivalente per questo flusso di lavoro è:

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

    • Per le baseline delle patch personalizzate in cui la casella di controllo Includi aggiornamenti non critici è selezionata vengono applicate entrambe le patch, quelle presenti in updateinfo.xml e quelle non presenti in updateinfo.xml (gli aggiornamenti correlati alla sicurezza e quelli non correlati alla sicurezza).

      Il comando yum equivalente per questo flusso di lavoro è:

      sudo yum update --security --bugfix -y

      Nei nodi gestiti della versione 8 e 9, l'API di aggiornamento DNF viene applicata alle patch approvate come segue:

      • Per le baseline delle patch predefinite fornite da AWS e per le baseline delle patch personalizzate in cui la casella di controllo Includi aggiornamenti non critici non è selezionata vengono applicate solo le patch specificate in updateinfo.xml (solo gli aggiornamenti correlati alla sicurezza).

        Il comando yum equivalente per questo flusso di lavoro è:

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

      • Per le baseline delle patch personalizzate in cui la casella di controllo Includi aggiornamenti non critici è selezionata vengono applicate entrambe le patch, quelle presenti in updateinfo.xml e quelle non presenti in updateinfo.xml (gli aggiornamenti correlati alla sicurezza e quelli non correlati alla sicurezza).

        Il comando yum equivalente per questo flusso di lavoro è:

        sudo dnf upgrade --security --bugfix

  8. Se sono stati installati aggiornamenti, il nodo gestito viene riavviato. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.)

AlmaLinux, RHEL, and Rocky Linux

Su AlmaLinux, Red Hat Enterprise Linux e i nodi gestiti Rocky Linux, il flusso di lavoro di installazione delle patch funziona come riportato:

  1. Se un elenco delle patch viene specificato utilizzando un URL https o un URL in stile percorso Amazon Simple Storage Service (Amazon S3) utilizzando il parametro InstallOverrideList per i documenti AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, vengono installate le patch elencate e vengono ignorati i passaggi 2-7.

  2. Applicare GlobalFilters come specificato nella base di patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione.

  3. Applicare ApprovalRules come specificato nella base di patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

    Le norme di approvazione, tuttavia, sono anche soggette al fatto che la casella di spunta Includi aggiornamenti non correlati alla protezione è stata selezionata durante la creazione o l'ultimo aggiornamento di una base di patch.

    Se sono esclusi aggiornamenti non di sicurezza, viene applicata una regola implicita per selezionare solo i pacchetti con gli aggiornamenti nei repo di sicurezza. Per ciascun pacchetto, la versione candidata (in genere, quella più recente) deve fare parte di un repo di sicurezza.

    Se sono inclusi aggiornamenti non correlati alla protezione, vengono prese in considerazione anche le patch di altri repository.

  4. Applicare ApprovedPatches come specificato nella base di patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da GlobalFilters o se nessuna regola di approvazione specificata in ApprovalRules concede l'approvazione.

  5. Applicare RejectedPatches come specificato nella base di patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

  6. Se vengono approvate più versioni di una patch, verrà applicata quella più recente.

  7. L'API di aggiornamento YUM (su RHEL 7) o l'API di aggiornamento DNF (su AlmaLinux 8 e 9, RHEL 8 e 9 e Rocky Linux 8 e 9) viene applicata alle patch approvate come segue:

    • Per le baseline delle patch predefinite fornite da AWS e per le baseline delle patch personalizzate in cui la casella di controllo Includi aggiornamenti non critici non è selezionata vengono applicate solo le patch specificate in updateinfo.xml (solo gli aggiornamenti correlati alla sicurezza).

      For RHEL 7, il comando yum equivalente per questo flusso di lavoro è:

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

      Per AlmaLinux, RHEL 8 e Rocky Linux, i comandi dnf equivalenti per questo flusso di lavoro sono:

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y

    • Per le baseline delle patch personalizzate in cui la casella di controllo Includi aggiornamenti non critici è selezionata vengono applicate entrambe le patch, quelle presenti in updateinfo.xml e quelle non presenti in updateinfo.xml (gli aggiornamenti correlati alla sicurezza e quelli non correlati alla sicurezza).

      For RHEL 7, il comando yum equivalente per questo flusso di lavoro è:

      sudo yum update --security --bugfix -y

      Per AlmaLinux 8 e 9, RHEL 8 e 9 e Rocky Linux 8 e 9, il comando dnf equivalente per questo flusso di lavoro è:

      sudo dnf update --security --bugfix -y

  8. Se sono stati installati aggiornamenti, il nodo gestito viene riavviato. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.)

SLES

Sui nodi gestiti SUSE Linux Enterprise Server (SLES), è riportato il flusso di lavoro di installazione delle patch come segue:

  1. Se un elenco delle patch viene specificato utilizzando un URL https o un URL in stile percorso Amazon Simple Storage Service (Amazon S3) utilizzando il parametro InstallOverrideList per i documenti AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, vengono installate le patch elencate e vengono ignorati i passaggi 2-7.

  2. Applicare GlobalFilters come specificato nella base di patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione.

  3. Applicare ApprovalRules come specificato nella base di patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

    Le norme di approvazione, tuttavia, sono anche soggette al fatto che la casella di spunta Includi aggiornamenti non correlati alla protezione è stata selezionata durante la creazione o l'ultimo aggiornamento di una base di patch.

    Se sono esclusi aggiornamenti non di sicurezza, viene applicata una regola implicita per selezionare solo i pacchetti con gli aggiornamenti nei repo di sicurezza. Per ciascun pacchetto, la versione candidata (in genere, quella più recente) deve fare parte di un repo di sicurezza.

    Se sono inclusi aggiornamenti non correlati alla protezione, vengono prese in considerazione anche le patch di altri repository.

  4. Applicare ApprovedPatches come specificato nella base di patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da GlobalFilters o se nessuna regola di approvazione specificata in ApprovalRules concede l'approvazione.

  5. Applicare RejectedPatches come specificato nella base di patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

  6. Se vengono approvate più versioni di una patch, verrà applicata quella più recente.

  7. L'API di aggiornamento Zypper viene applicata alle patch approvate.

  8. Se sono stati installati aggiornamenti, il nodo gestito viene riavviato. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.)

Ubuntu Server

Sui nodi gestiti Ubuntu Server, il flusso di lavoro di installazione delle patch funziona come riportato:

  1. Se un elenco delle patch viene specificato utilizzando un URL https o un URL in stile percorso Amazon Simple Storage Service (Amazon S3) utilizzando il parametro InstallOverrideList per i documenti AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, vengono installate le patch elencate e vengono ignorati i passaggi 2-7.

  2. Se è disponibile un aggiornamento per python3-apt (un'interfaccia di libreria Python perlibapt), viene aggiornato alla versione più recente. (Questo pacchetto non correlato alla sicurezza viene aggiornato anche se non è stata selezionata l'opzione Includi aggiornamenti non correlati alla protezione).

  3. Applicare GlobalFilters come specificato nella base di patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione.

  4. Applicare ApprovalRules come specificato nella base di patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

    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.

    Le norme di approvazione, tuttavia, sono anche soggette al fatto che la casella di spunta Includi aggiornamenti non correlati alla protezione è stata selezionata durante la creazione o l'ultimo aggiornamento di una base di patch.

    Se sono esclusi aggiornamenti non di sicurezza, viene applicata una regola implicita per selezionare solo i pacchetti con gli aggiornamenti nei repo di sicurezza. Per ciascun pacchetto, la versione candidata (in genere, quella più recente) deve fare parte di un repo di sicurezza.

    Se sono inclusi aggiornamenti non correlati alla protezione, vengono prese in considerazione anche le patch di altri repository.

    Le norme di approvazione, tuttavia, sono anche soggette al fatto che la casella di spunta Includi aggiornamenti non correlati alla protezione è stata selezionata durante la creazione o l'ultimo aggiornamento di una base di patch.

    Nota

    Per ogni versione di Ubuntu Server, le versioni patch candidate sono limitate alle patch che fanno parte del repository associato a quella versione, come segue:

    • 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. Applicare ApprovedPatches come specificato nella base di patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da GlobalFilters o se nessuna regola di approvazione specificata in ApprovalRules concede l'approvazione.

  6. Applicare RejectedPatches come specificato nella base di patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

  7. La libreria APT viene utilizzata per aggiornare i pacchetti.

    Nota

    Patch Manager non supporta l'uso dell'opzione Pin-Priority APT per assegnare priorità ai pacchetti. Patch Manager aggrega gli aggiornamenti disponibili da tutti gli archivi abilitati e seleziona l'aggiornamento più recente che corrisponde alla baseline per ogni pacchetto installato.

  8. Se sono stati installati aggiornamenti, il nodo gestito viene riavviato. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.)

Windows Server

Se l'operazione di applicazione elle patch viene eseguita in un nodo gestito Windows Server, il nodo richiede uno snapshot della base di patch appropriata da Systems Manager. Tale snapshot contiene l'elenco di tutti gli aggiornamenti disponibili nella base di patch che sono stati approvati per la distribuzione. Questo elenco di aggiornamenti viene inviato all'API di Windows Update, che determinerà quali aggiornamenti sono applicabili al nodo gestito e li installerà in base alle esigenze. Windows consente l'installazione solo dell'ultima versione disponibile di un KB. Patch Manager installa la versione più recente di un KB quando questa, o qualsiasi versione precedente del KB, corrisponde alla baseline delle patch applicata. Se vengono installati eventuali aggiornamenti, il nodo gestito verrà riavviato tutte le volte necessarie per completare l'applicazione di tutte le patch richieste. (Eccezione: se il parametro RebootOption è impostato su NoReboot nel documento AWS-RunPatchBaseline, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta Nome parametro: RebootOption.) Il riepilogo dell'applicazione di patch è disponibile nell'output della richiesta Run Command. I log aggiuntivi sono disponibili nella cartella %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs del nodo.

Poiché l'API di Windows Update viene utilizzata per scaricare e installare i KB, vengono rispettate tutte le impostazioni delle policy di gruppo per Windows Update. Per utilizzare Patch Manager, non è necessaria alcuna impostazione della policy di gruppo, ma verranno applicate le eventuali impostazioni definite, ad esempio l'indirizzamento dei nodi gestiti a un server Windows Server Update Services (WSUS).

Nota

Per impostazione predefinita, Windows scarica tutti i KB dal sito Windows Update di Microsoft poiché Patch Manager utilizza l'API di Windows Update per gestire i relativi download e l'installazione. Di conseguenza, il nodo gestito deve essere in grado di raggiungere il sito di Microsoft Windows Update o l'applicazione della patch non andrà a buon fine. In alternativa, è possibile configurare un server WSUS che funga da repository di KB e configurare i nodi gestiti che abbiano come target tale server WSUS anziché l'utilizzo delle policy di gruppo.