Come vengono installate le patch - AWS Systems Manager

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Come vengono installate le patch

Patch Manager, uno strumento in AWS Systems Manager, utilizza il meccanismo integrato appropriato per un tipo di sistema operativo per installare gli aggiornamenti su 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.

Patch Managernon installa un nuovo pacchetto che sostituisca un pacchetto obsoleto attualmente installato. (Eccezioni: il nuovo pacchetto dipende dall'installazione di un altro pacchetto che si sta aggiornando oppure il nuovo pacchetto ha lo stesso nome del pacchetto obsoleto.) Al contrario, Patch Manager segnala e installa gli aggiornamenti disponibili per i pacchetti installati. Questo approccio aiuta a prevenire modifiche impreviste alla funzionalità del sistema che potrebbero verificarsi quando un pacchetto sostituisce un altro.

Se è necessario disinstallare un pacchetto reso obsoleto e installarne il sostituto, potrebbe essere necessario utilizzare uno script personalizzato o utilizzare comandi di gestione dei pacchetti al di fuori delle operazioni Patch Manager standard.

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

      I nuovi pacchetti che sostituiscono i pacchetti ormai obsoleti con nomi diversi vengono installati se si eseguono questi yum o dnf comandi all'esterno di. Patch Manager Tuttavia, non vengono installati con operazioni equivalenti. Patch Manager

      Dettagli aggiuntivi sulle patch per Amazon Linux 2022 e Amazon Linux 2023
      Support per il livello di gravità «Nessuno»

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

      Support per il livello di gravità «Medio»

      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.

      Gestione delle dipendenze transitive per Amazon Linux 2022 e Amazon Linux 2023

      Per Amazon Linux 2022 e Amazon Linux 2023, Patch Manager potrebbero installare versioni diverse di dipendenze transitive rispetto ai dnf comandi equivalenti install. Le dipendenze transitive sono pacchetti che vengono installati automaticamente per soddisfare i requisiti di altri pacchetti (dipendenze delle dipendenze).

      Ad esempio, dnf upgrade-minimal --security installa le versioni minime delle dipendenze transitive necessarie per risolvere problemi di sicurezza noti, mentre Patch Manager installa le versioni più recenti disponibili delle stesse dipendenze transitive.

  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.

    Nota

    Per CentOS, Patch Manager potrebbe installare versioni diverse di dipendenze transitive rispetto ai comandi equivalenti install. dnf Le dipendenze transitive sono pacchetti che vengono installati automaticamente per soddisfare i requisiti di altri pacchetti (dipendenze delle dipendenze).

    Ad esempio, dnf upgrade-minimal --security installa le versioni minime delle dipendenze transitive necessarie per risolvere problemi di sicurezza noti, mentre Patch Manager installa le versioni più recenti disponibili delle stesse dipendenze transitive.

  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 di patch predefinite fornite da AWS e per le baseline di patch personalizzate in cui la casella di controllo Includi aggiornamenti non di sicurezza non è selezionata, vengono applicate solo le patch specificate in (solo aggiornamenti di sicurezza). updateinfo.xml

        Il comando yum equivalente per questo flusso di lavoro è:

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

        Per Oracle Linux, Patch Manager potrebbe installare versioni diverse delle dipendenze transitive rispetto ai comandi equivalenti install. dnf Le dipendenze transitive sono pacchetti che vengono installati automaticamente per soddisfare i requisiti di altri pacchetti (dipendenze delle dipendenze).

        Ad esempio, dnf upgrade-minimal --security installa le versioni minime delle dipendenze transitive necessarie per risolvere problemi di sicurezza noti, mentre Patch Manager installa le versioni più recenti disponibili delle stesse dipendenze transitive.

      • 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
    Nota

    Se si eseguono questi o comandi all'esterno, vengono installati nuovi pacchetti che sostituiscono pacchetti ormai obsoleti con nomi diversi. yum dnf Patch Manager Tuttavia, non vengono installati con operazioni equivalenti. Patch Manager

  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

Sui nodi Rocky Linux gestiti AlmaLinuxRed Hat Enterprise Linux, 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 (su RHEL 7) o l'API di aggiornamento DNF (su AlmaLinux 8 e 9, RHEL 8, 9 e 10 e Rocky Linux 8 e 9) viene applicata alle patch approvate in base alle seguenti regole:

     

    Scenario 1: aggiornamenti non relativi alla sicurezza esclusi

    • Si applica a: linee base di patch predefinite fornite da AWS e baseline di patch personalizzate.

    • Casella di controllo Includi aggiornamenti non di sicurezza: non selezionata.

    • Patch applicate: le patch specificate in updateinfo.xml (solo aggiornamenti di sicurezza) vengono applicate solo se entrambe corrispondono alla configurazione di base della patch e si trovano nei repository configurati.

      In alcuni casi, una patch specificata in updateinfo.xml potrebbe non essere più disponibile in un repository configurato. I repository configurati di solito hanno solo la versione più recente di una patch, che è un riepilogo cumulativo di tutti gli aggiornamenti precedenti, ma la versione più recente potrebbe non corrispondere alle regole di base della patch e viene omessa dall'operazione di patching.

    • Comandi: per 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 eRocky 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
      Nota

      For AlmaLinuxRHEL, e Rocky Linux Rocky Linux, Patch Manager potrebbero installare versioni diverse di dipendenze transitive rispetto ai comandi equivalenti install. dnf Le dipendenze transitive sono pacchetti che vengono installati automaticamente per soddisfare i requisiti di altri pacchetti (dipendenze delle dipendenze).

      Ad esempio, dnf upgrade-minimal --security installa le versioni minime delle dipendenze transitive necessarie per risolvere problemi di sicurezza noti, mentre Patch Manager installa le versioni più recenti disponibili delle stesse dipendenze transitive.

    Scenario 2: aggiornamenti non relativi alla sicurezza inclusi

    • Si applica a: Linee base di patch personalizzate.

    • Casella di controllo Includi aggiornamenti non di sicurezza: selezionata.

    • Patch applicate: vengono applicate le patch in updateinfo.xml entrata e quelle non incluse updateinfo.xml (aggiornamenti di sicurezza e non).

    • Comandi: per 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
    Nota

    I nuovi pacchetti che sostituiscono i pacchetti ormai obsoleti con nomi diversi vengono installati se si eseguono questi yum o dnf comandi all'esterno di. Patch Manager Tuttavia, non vengono installati con operazioni equivalenti. Patch Manager

  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-security)

    • Ubuntu Server23.10 () mantic-security

    • Ubuntu Server24,04 LITRI (1) noble-security

    • Ubuntu Server24.10 () oracular-security

    • Ubuntu Server25,04 () plucky-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.)

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 il download e l'installazione KBs, tutte le impostazioni dei Criteri di gruppo per Windows Update vengono rispettate. 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 tutto KBs dal sito Windows Update di Microsoft perché Patch Manager utilizza l'API Windows Update per il download e l'installazione di KBs. 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.

Patch Managerpotrebbe fare riferimento a KB IDs quando si creano linee base di patch personalizzate perWindows Server, ad esempio quando nella configurazione di base è incluso un elenco di patch approvate o un elenco di patch rifiutate. Vengono installati solo gli aggiornamenti a cui è assegnato un ID KB in Microsoft Windows Update o in un server WSUS daPatch Manager. Gli aggiornamenti privi di un ID KB non sono inclusi nelle operazioni di applicazione delle patch.

Per informazioni sulla creazione di linee base di patch personalizzate, consulta i seguenti argomenti: