Come vengono installate le patch - AWS Systems Manager

AWS Systems ManagerChange Managernon è più aperto a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, vedi modifica della AWS Systems ManagerChange Manager disponibilità.

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 gestore di pacchetti integrato nel sistema operativo per installare gli aggiornamenti sui nodi gestiti. Ad esempio, utilizza l'API Windows Update su Windows Server e DNF su Amazon Linux 2023. Patch Manager rispetta le configurazioni esistenti del gestore di pacchetti e del repository sui nodi, incluse impostazioni come lo stato del repository, il mirror URLs, la verifica GPG e opzioni simili. skip_if_unavailable

Patch Managernon installa un nuovo pacchetto che sostituisce 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 ne 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 2 and Amazon Linux 2023

Di seguito è riportato il flusso di lavoro di installazione delle patch nei nodi gestiti Amazon Linux 2 e Amazon Linux 2023:

  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 2) o l'API di aggiornamento DNF (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 2, il comando yum equivalente per questo flusso di lavoro è:

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

      Per Amazon Linux 2023, il comando dnf 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 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 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 di patch aggiuntivi per Amazon Linux 2023
      Support per il livello di gravità «Nessuno»

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

      Support per il livello di gravità «Medio»

      Per 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 2023

      Per Amazon Linux 2023, Patch Manager potrebbe installare versioni diverse di dipendenze transitive rispetto ai comandi dnf 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.)

Nota

Una configurazione predefinita per un gestore di pacchetti su una distribuzione Linux potrebbe essere impostata per ignorare un archivio di pacchetti non raggiungibile senza errori. In questi casi, la relativa operazione di patching procede senza installare gli aggiornamenti dal repository e si conclude con successo. Per applicare gli aggiornamenti del repository, aggiungili alla configurazione del repository. skip_if_unavailable=False

Per ulteriori informazioni sull'opzione skip_if_available, consulta Connettività all'origine della patch.

CentOS Stream

Sui nodi gestiti CentOS Stream, 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.

    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 viene applicata alle patch approvate.

    Nota

    PerchéCentOS Stream, 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.

  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

Di seguito è riportato il flusso di lavoro di installazione delle patch nelle istanze Debian Server:

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

  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 ,, le versioni candidate alle patch sono limitate alle patch incluse in .

  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 relativi alla 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

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

Nota

Una configurazione predefinita per un gestore di pacchetti su una distribuzione Linux potrebbe essere impostata per ignorare un archivio di pacchetti non raggiungibile senza errori. In questi casi, la relativa operazione di patching procede senza installare gli aggiornamenti dal repository e si conclude con successo. Per applicare gli aggiornamenti del repository, aggiungili alla configurazione del repository. skip_if_unavailable=False

Per ulteriori informazioni sull'opzione skip_if_available, consulta Connettività all'origine della patch.

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 di base di patch predefinite fornite da e linee di base di patch personalizzate. AWS

    • La casella di controllo Includi aggiornamenti non critici 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.

    • For 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.

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

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

    • For 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.)

Nota

Una configurazione predefinita per un gestore di pacchetti su una distribuzione Linux potrebbe essere impostata per ignorare un archivio di pacchetti non raggiungibile senza errori. In questi casi, la relativa operazione di patching procede senza installare gli aggiornamenti dal repository e si conclude con successo. Per applicare gli aggiornamenti del repository, aggiungili alla configurazione del repository. skip_if_unavailable=False

Per ulteriori informazioni sull'opzione skip_if_available, consulta Connettività all'origine della patch.

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 16.04 LTS: xenial-security

    • Ubuntu Server 18.04 LTS: bionic-security

    • Ubuntu Server 20.04 LTS): focal-security

    • Ubuntu Server 22.04 LTS: jammy-security

    • Ubuntu Server 22.04 LTS (noble-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: