• La AWS Systems Manager CloudWatch dashboard non sarà più disponibile dopo il 30 aprile 2026. I clienti possono continuare a utilizzare la CloudWatch console Amazon per visualizzare, creare e gestire le proprie CloudWatch dashboard Amazon, proprio come fanno oggi. Per ulteriori informazioni, consulta la [documentazione di Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

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 Patch Manager funzionano le operazioni
<a name="patch-manager-patching-operations"></a>

Questa sezione fornisce i dettagli tecnici che illustrano come Patch Manager, uno strumento di AWS Systems Manager, determina le patch da installare e come vengono installate in ciascun sistema operativo supportato. Per i sistemi operativi Linux, fornisce inoltre informazioni su come specificare un repository di origine, in una base di patch personalizzata, relativamente alle patch diverse da quella predefinita configurata in un nodo gestito. Questa sezione fornisce inoltre dettagli sulle regole della base di patch in varie distribuzioni del sistema operativo Linux.

**Nota**  
Le informazioni contenute negli argomenti seguenti si applicano indipendentemente dal metodo o dal tipo di configurazione utilizzato per le operazioni di applicazione di patch:  
Una policy di patch configurata in Quick Setup
Un'opzione di gestione host configurata in Quick Setup
Una finestra di manutenzione per eseguire un'attività `Scan` o `Install` di patch
Un'operazione **Patch now** (Applica subito una patch) on demand

**Topics**
+ [Il modo in cui vengono calcolate le date di rilascio e di aggiornamento dei pacchetti](patch-manager-release-dates.md)
+ [Come vengono selezionate le patch di sicurezza](patch-manager-selecting-patches.md)
+ [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md)
+ [Come vengono installate le patch](patch-manager-installing-patches.md)
+ [Funzionamento delle regole delle baseline delle patch nei sistemi Linux](patch-manager-linux-rules.md)
+ [Differenze nelle operazioni di applicazione di patch tra Linux e Windows Server](patch-manager-windows-and-linux-differences.md)

# Il modo in cui vengono calcolate le date di rilascio e di aggiornamento dei pacchetti
<a name="patch-manager-release-dates"></a>

**Importante**  
Le informazioni in questa pagina si applicano ai sistemi operativi Amazon Linux 2 e Amazon Linux 2023 per istanze Amazon Elastic Compute Cloud (Amazon EC2). I pacchetti per questi tipi di sistema operativo sono creati e gestiti da Amazon Web Services. Il modo in cui i produttori di altri sistemi operativi gestiscono pacchetti e repository influisce sul modo in cui vengono calcolate le date di rilascio e di aggiornamento. OSs Oltre ad Amazon Linux 2 e Amazon Linux 2023, ad esempioRed Hat Enterprise Linux, consulta la documentazione del produttore per informazioni su come i loro pacchetti vengono aggiornati e mantenuti.

Nelle impostazioni per le [baseline di patch personalizzate](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) create, per la maggior parte dei tipi di sistema operativo, è possibile specificare che le patch vengano approvate automaticamente per l'installazione dopo un certo numero di giorni. AWS fornisce diverse linee base di patch predefinite che includono date di approvazione automatica di 7 giorni.

Il *ritardo* è il numero di giorni di attesa dopo il rilascio della patch, prima che questa venga automaticamente approvata per l'applicazione. Ad esempio, si crea una regola utilizzando la classificazione `CriticalUpdates` e si configura per un ritardo di approvazione automatica di 7 giorni. Di conseguenza, una nuova patch critica con una data di rilascio o l'ultimo aggiornamento al 7 luglio viene approvata automaticamente il 14 luglio.

Per evitare risultati imprevisti dovuti a ritardi nell'approvazione automatica su Amazon Linux 2 e Amazon Linux 2023, è importante capire il modo in cui vengono calcolate le date di rilascio e di aggiornamento.

**Nota**  
Se un repository Amazon Linux 2 o Amazon Linux 2023 non fornisce informazioni sulla data di rilascio per pacchetti, Patch Manager utilizza il tempo di compilazione del pacchetto come la data dell'approvazione automatica. Se non è possibile determinare il tempo di compilazione del pacchetto, Patch Manager utilizza una data predefinita del 1° gennaio 1970. Ciò comporta l'Patch Manageraggiramento di qualsiasi specifica della data di approvazione automatica nelle baseline delle patch configurate per approvare le patch per qualsiasi data successiva al 1° gennaio 1970.

Nella maggior parte dei casi, il tempo di attesa per l'approvazione automatica prima dell'installazione delle patch viene calcolato in base al valore `Updated Date` in `updateinfo.xml`, non al valore `Release Date`. Di seguito sono riportati dettagli importanti sui calcoli della data: 
+ `Release Date` è la data in cui viene rilasciato un *avviso*. Non significa che il pacchetto sia ancora necessariamente disponibile nei repository associati. 
+ `Update Date` è l'ultima data in cui l'avviso è stato aggiornato. Un aggiornamento a un avviso può rappresentare qualcosa di piccolo come aggiornamenti di testo o di descrizione. Non significa che il pacchetto sia stato rilasciato a partire da tale data o che sia ancora necessariamente disponibile nei repository associati. 

  Ciò significa che un pacchetto potrebbe avere un valore `Update Date` del 7 luglio ma non essere disponibile per l'installazione fino al 13 luglio (ad esempio). Supponiamo che, in questo caso, una baseline delle patch che specifichi un ritardo di approvazione automatica di 7 giorni venga eseguita in un'operazione `Install` il 14 luglio. Dato che il valore `Update Date` corrisponde a 7 giorni prima della data di esecuzione, le patch e gli aggiornamenti del pacchetto vengono installati il 14 luglio. L'installazione avviene anche se è passato solo 1 giorno da quando il pacchetto risulta disponibile per l'installazione effettiva.
+ Un pacchetto con le patch del sistema operativo o dell'applicazione può essere aggiornato più di una volta dopo il rilascio iniziale.
+ Un pacchetto può essere rilasciato negli archivi AWS gestiti per poi ripristinarlo se successivamente vengono rilevati dei problemi.

In alcune operazioni di applicazione di patch, questi fattori potrebbero non essere rilevanti. Ad esempio, se una baseline delle patch è configurata per installare una patch con valori di gravità di `Low` e `Medium`, e una classificazione di `Recommended`, qualsiasi ritardo nell'approvazione automatica potrebbe avere un impatto minimo sulle tue operazioni.

Tuttavia, nei casi in cui la tempistica delle patch critiche o con alto livello di gravità è più importante, potrebbe essere opportuno esercitare un maggiore controllo sul momento in cui le patch vengono installate. Il metodo suggerito per questa operazione consiste nell'utilizzare repository alternativi di origine delle patch anziché i repository predefiniti per le operazioni di applicazione di patch su un nodo gestito. 

È possibile specificare repository alternativi di origine delle patch al momento della creazione di una baseline delle patch personalizzata. In ciascuna baseline delle patch personalizzata, è possibile specificare le configurazioni di origine delle patch per un massimo di 20 versioni di un sistema operativo Linux supportato. Per ulteriori informazioni, consulta [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md).

# Come vengono selezionate le patch di sicurezza
<a name="patch-manager-selecting-patches"></a>

L'obiettivo principale diPatch Manager, uno strumento in AWS Systems Manager, è l'installazione degli aggiornamenti relativi alla sicurezza dei sistemi operativi sui nodi gestiti. Per impostazione predefinita, Patch Manager non installa tutte le patch disponibili, ma solo una serie limitata di patch relative alla sicurezza.

Per impostazione predefinita, Patch Manager non sostituisce un pacchetto contrassegnato come obsoleto in un archivio di pacchetti con pacchetti sostitutivi con nomi diversi, a meno che tale sostituzione non sia richiesta dall'installazione di un altro aggiornamento del pacchetto. Invece, per i comandi che aggiornano un pacchetto, segnala e installa Patch Manager solo gli aggiornamenti mancanti per il pacchetto installato ma obsoleto. Questo perché la sostituzione di un pacchetto obsoleto richiede in genere la disinstallazione di un pacchetto esistente e l'installazione del pacchetto sostitutivo. La sostituzione del pacchetto obsoleto potrebbe introdurre modifiche sostanziali o funzionalità aggiuntive non previste.

Questo comportamento è coerente con il comando `update-minimal` di YUM e DNF, che si concentra sugli aggiornamenti di sicurezza piuttosto che sugli quelli delle funzionalità. Per ulteriori informazioni, consulta [Come vengono installate le patch](patch-manager-installing-patches.md).

**Nota**  
Quando si utilizza il `ApproveUntilDate` parametro o il `ApproveAfterDays` parametro in una regola di base della patch, Patch Manager valuta le date di rilascio delle patch utilizzando il Coordinated Universal Time (UTC).   
Ad esempio, per`ApproveUntilDate`, se si specifica una data come`2025-11-16`, le patch rilasciate tra il `2025-11-16T00:00:00Z` e `2025-11-16T23:59:59Z` verranno approvate.   
Tieni presente che le date di rilascio delle patch visualizzate dai gestori di pacchetti nativi sui nodi gestiti possono mostrare orari diversi in base al fuso orario locale del sistema, ma utilizza Patch Manager sempre la data/ora UTC per i calcoli di approvazione. Ciò garantisce la coerenza con le date di rilascio delle patch pubblicate sui siti Web ufficiali di consulenza sulla sicurezza.

Per i sistemi operativi basati su Linux che segnalano un livello di gravità per le patch, Patch Manager utilizza il livello di gravità riportato dal publisher del software per la notifica di aggiornamento o la singola patch. Patch Manager non ottiene i livelli di gravità da fonti di terze parti, come il [CVSS](https://www.first.org/cvss/) (Common Vulnerability Scoring System), o dai parametri rilasciati dall'[NVD](https://nvd.nist.gov/vuln) (National Vulnerability Database).

**Nota**  
In tutti i sistemi basati su Linux supportati da Patch Manager è possibile scegliere un altro repository di origine configurato per il nodo gestito, in genere per l'installazione di aggiornamenti non relativi alla sicurezza. Per informazioni, consulta [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md).

Scegli una delle seguenti schede per scoprire come Patch Manager seleziona le patch di sicurezza per il tuo sistema operativo.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

I repository preconfigurati vengono gestiti in modo diverso su Amazon Linux 2 rispetto a Amazon Linux 2023.

In Amazon Linux 2, il servizio della baseline delle patch di Systems Manager utilizza repository preconfigurati nel nodo gestito. In genere in un nodo sono disponibili due repository (repo) preconfigurati:

**Su Amazon Linux 2**
+ **ID repository**: `amzn2-core/2/architecture`

  **Nome repository**: `Amazon Linux 2 core repository`
+ **ID repository**: `amzn2extra-docker/2/architecture`

  **Nome repository**: `Amazon Extras repo for docker`

**Nota**  
*architecture*può essere x86\$164 o (per processori Graviton) aarch64.

Quando crei un'istanza Amazon Linux 2023 (AL2023), contiene gli aggiornamenti disponibili nella versione AL2023 e nello specifico che AMI hai selezionato. La tua AL2023 istanza non riceve automaticamente aggiornamenti di sicurezza critici e importanti aggiuntivi al momento del lancio. Invece, con la funzionalità di *upgrade deterministico tramite repository con versioni* supportata per impostazione predefinita AL2023, che è attivata per impostazione predefinita, puoi applicare gli aggiornamenti in base a una pianificazione che soddisfa le tue esigenze specifiche. Per ulteriori informazioni, consulta [Aggiornamenti deterministici tramite repository con versioni](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) nella *Guida per l'utente di Amazon Linux 2023*. 

Attivo AL2023, l'archivio preconfigurato è il seguente:
+ **ID repository**: `amazonlinux`

  **Nome del repository**: repository Amazon Linux 2023

Su Amazon Linux 2023 (rilascio in anteprima), i repository preconfigurati sono legati a *versioni bloccate* degli aggiornamenti dei pacchetti. Quando AL2023 vengono rilasciati nuovi Amazon Machine Images (AMIs) for, vengono bloccati su una versione specifica. Per gli aggiornamenti delle patch, Patch Manager recupera l'ultima versione bloccata del repository degli aggiornamenti delle patch, quindi aggiorna i pacchetti sul nodo gestito in base al contenuto di quella versione bloccata.

**Funzionalità di gestione dei pacchetti.**  
I nodi gestiti da Amazon Linux 2 utilizzano Yum come gestore di pacchetti. Amazon Linux 2023 utilizza DNF come gestore di pacchetti. 

Entrambi i gestori di pacchetti utilizzano il concetto di *avviso di aggiornamento* come un file denominato `updateinfo.xml`. Un avviso di aggiornamento è semplicemente una raccolta di pacchetti per la risoluzione di problemi specifici. Tutti i pacchetti di un avviso di aggiornamento sono considerati di sicurezza da Patch Manager. Ai singoli pacchetti non vengono assegnati classificazioni o livelli di gravità. Per questo motivo, Patch Manager assegna gli attributi di un avviso di aggiornamento ai pacchetti correlati.

**Nota**  
Se si seleziona la casella di controllo **Includi aggiornamenti non critici** nella pagina **Crea baseline delle patch**, i pacchetti non classificati in un file `updateinfo.xml` (o in un pacchetto che contiene un file per il quale i valori relativi a classificazione, gravità e data non sono formattati in modo appropriato) possono essere inclusi nell'elenco di patch prefiltrato. Tuttavia, per poter essere applicata, una patch deve comunque soddisfare le regole della baseline delle patch specificate dall'utente.  
Per ulteriori informazioni sull'opzione **Includi aggiornamenti non critici**, consulta [Come vengono installate le patch](patch-manager-installing-patches.md) e [Funzionamento delle regole delle baseline delle patch nei sistemi Linux](patch-manager-linux-rules.md).

------
#### [  CentOS Stream ]

In CentOS Stream, il servizio della baseline delle patch di Systems Manager utilizza repository preconfigurati (repository) nel nodo gestito. L'elenco seguente fornisce esempi per un fittizio CentOS 9.2 Amazon Machine Image (AMI):
+ **ID repository**: `example-centos-9.2-base`

  **Nome repository**: `Example CentOS-9.2 - Base`
+ **ID repository**: `example-centos-9.2-extras` 

  **Nome repository**: `Example CentOS-9.2 - Extras`
+ **ID repository**: `example-centos-9.2-updates`

  **Nome repository**: `Example CentOS-9.2 - Updates`
+ **ID repository**: `example-centos-9.x-examplerepo`

  **Nome repository**: `Example CentOS-9.x – Example Repo Packages`

**Nota**  
Tutti gli aggiornamenti vengono scaricati dai repo remoti configurati nel nodo. Pertanto, il nodo deve avere un accesso in uscita a Internet per connettersi ai repository in modo che possa essere eseguita l'applicazione di patch.

I nodi CentOS Stream utilizzano DNF come gestore di pacchetti. Entrambi i gestori di pacchetti utilizzano il concetto di avviso degli aggiornamenti. Un avviso di aggiornamento è semplicemente una raccolta di pacchetti per la risoluzione di problemi specifici. 

Tuttavia, i repository CentOS Stream predefiniti non sono configurati con un avviso degli aggiornamenti. Ciò significa che Patch Manager non è in grado di rilevare i pacchetti in un repository CentOS Stream predefinito. Per abilitare Patch Manager all'elaborazione di pacchetti non sono contenuti in un avviso di aggiornamento, dovrai abilitare il flag `EnableNonSecurity` nelle regole di baseline delle patch.

**Nota**  
Gli avvisi degli aggiornamenti CentOS Stream sono supportati. Potrai scaricare i repo con avvisi di aggiornamento dopo l'avvio.

------
#### [ Debian Server ]

In Debian Server, il servizio della baseline delle patch di Systems Manager utilizza repository preconfigurati (repository) nell'istanza. Questi repo preconfigurati vengono utilizzati per estrarre un elenco aggiornato degli aggiornamenti dei pacchetti disponibili. A tale scopo, Systems Manager esegue l'equivalente di un comando `sudo apt-get update`. 

I pacchetti vengono quindi filtrati da repo `debian-security codename`. Ciò significa che in ogni versione di Debian Server, Patch Manager identifica solo gli aggiornamenti che fanno parte del repository associato a quella versione, come segue:
+  Debian Server11: `debian-security bullseye`
+ Debian Server12: `debian-security bookworm`

------
#### [ Oracle Linux ]

In Oracle Linux, il servizio della baseline delle patch di Systems Manager utilizza repository preconfigurati (repository) nel nodo gestito. In genere in un nodo sono disponibili due repo preconfigurati:

**Oracle Linux 7**:
+ **ID repository**: `ol7_UEKR5/x86_64`

  **Nome repository**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **ID repository**: `ol7_latest/x86_64`

  **Nome repository**: `Oracle Linux 7Server Latest (x86_64)` 

**Oracle Linux 8**:
+ **ID repository**: `ol8_baseos_latest` 

  **Nome repository**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **ID repository**: `ol8_appstream`

  **Nome repository**: `Oracle Linux 8 Application Stream (x86_64)` 
+ **ID repository**: `ol8_UEKR6`

  **Nome repository**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`

**Oracle Linux 9**:
+ **ID repository**: `ol9_baseos_latest` 

  **Nome repository**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **ID repository**: `ol9_appstream`

  **Nome repository**: `Oracle Linux 9 Application Stream Packages(x86_64)` 
+ **ID repository**: `ol9_UEKR7`

  **Nome repository**: `Oracle Linux UEK Release 7 (x86_64)`

**Nota**  
Tutti gli aggiornamenti vengono scaricati dai repo remoti configurati nel nodo. Pertanto, il nodo deve avere un accesso in uscita a Internet per connettersi ai repository in modo che possa essere eseguita l'applicazione di patch.

I nodi gestiti di Oracle Linux utilizzano Yum come programma di gestione dei pacchetti e Yum si avvale del principio dell'avviso di aggiornamento sotto forma di file denominato `updateinfo.xml`. Un avviso di aggiornamento è semplicemente una raccolta di pacchetti per la risoluzione di problemi specifici. Ai singoli pacchetti non vengono assegnati classificazioni o livelli di gravità. Per questo motivo, Patch Manager assegna gli attributi di un avviso di aggiornamento ai pacchetti correlati e installa i pacchetti in base ai filtri di classificazione specificati nella baseline delle patch.

**Nota**  
Se si seleziona la casella di controllo **Includi aggiornamenti non critici** nella pagina **Crea baseline delle patch**, i pacchetti non classificati in un file `updateinfo.xml` (o in un pacchetto che contiene un file per il quale i valori relativi a classificazione, gravità e data non sono formattati in modo appropriato) possono essere inclusi nell'elenco di patch prefiltrato. Tuttavia, per poter essere applicata, una patch deve comunque soddisfare le regole della baseline delle patch specificate dall'utente.

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

Sì AlmaLinuxRed Hat Enterprise Linux, e Rocky Linux il servizio di base delle patch di Systems Manager utilizza repository preconfigurati (repository) sul nodo gestito. In genere in un nodo sono disponibili tre repo preconfigurati:

Tutti gli aggiornamenti vengono scaricati dai repo remoti configurati nel nodo. Pertanto, il nodo deve avere un accesso in uscita a Internet per connettersi ai repository in modo che possa essere eseguita l'applicazione di patch.

**Nota**  
Se si seleziona la casella di controllo **Includi aggiornamenti non critici** nella pagina **Crea baseline delle patch**, i pacchetti non classificati in un file `updateinfo.xml` (o in un pacchetto che contiene un file per il quale i valori relativi a classificazione, gravità e data non sono formattati in modo appropriato) possono essere inclusi nell'elenco di patch prefiltrato. Tuttavia, per poter essere applicata, una patch deve comunque soddisfare le regole della baseline delle patch specificate dall'utente.

Red Hat Enterprise Linux7 nodi gestiti utilizzano Yum come gestore di pacchetti. AlmaLinux, Red Hat Enterprise Linux 8, e i nodi Rocky Linux gestiti utilizzano DNF come gestore di pacchetti. Entrambi i gestori di pacchetti utilizzano il concetto di avviso di aggiornamento come file denominato `updateinfo.xml`. Un avviso di aggiornamento è semplicemente una raccolta di pacchetti per la risoluzione di problemi specifici. Ai singoli pacchetti non vengono assegnati classificazioni o livelli di gravità. Per questo motivo, Patch Manager assegna gli attributi di un avviso di aggiornamento ai pacchetti correlati e installa i pacchetti in base ai filtri di classificazione specificati nella baseline delle patch.

RHEL 7  
I seguenti repository IDs sono associati a RHUI 2. RHUI 3 è stato lanciato a dicembre 2019 e ha introdotto uno schema di denominazione diverso per il repository Yum. IDs A seconda dell'AMI RHEL-7 AMI da cui si creano i nodi gestiti, potrebbe essere necessario aggiornare i comandi. *Per maggiori informazioni, consulta [Repository IDs for RHEL 7 in Have Changed sul Red Hat AWS Customer](https://access.redhat.com/articles/4599971) Portal.*
+ **ID repository**: `rhui-REGION-client-config-server-7/x86_64`

  **Nome repository**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **ID repository**: `rhui-REGION-rhel-server-releases/7Server/x86_64`

  **Nome repository**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **ID repository**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`

  **Nome repository**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`

AlmaLinux, 8, RHEL 8 e Rocky Linux 8  
+ **ID repository**: `rhel-8-appstream-rhui-rpms`

  **Nome repository**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **ID repository**: `rhel-8-baseos-rhui-rpms`

  **Nome repository**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **ID repository**: `rhui-client-config-server-8`

  **Nome repository**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`

AlmaLinux 9, RHEL 9 e Rocky Linux 9  
+ **ID repository**: `rhel-9-appstream-rhui-rpms`

  **Nome repository**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **ID repository**: `rhel-9-baseos-rhui-rpms`

  **Nome repository**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **ID repository**: `rhui-client-config-server-9`

  **Nome repository**:`Red Hat Enterprise Linux 9 Client Configuration`

------
#### [ SLES ]

Nei nodi gestiti SUSE Linux Enterprise Server (SLES), la libreria ZYPP ottiene l'elenco delle patch disponibili (una raccolta di pacchetti) dai seguenti percorsi:
+ Elenco di repository: `etc/zypp/repos.d/*`
+ Informazioni sui pacchetti: `/var/cache/zypp/raw/*`

I nodi gestiti SLES utilizzano Zypper come programma di gestione dei pacchetti e Zypper si avvale del principio di una patch. Una patch è semplicemente una raccolta di pacchetti per la risoluzione di un problema specifico.Patch Manager gestisce tutti i pacchetti a cui fa riferimento in una patch come correlati alla sicurezza. Poiché ai singoli pacchetti non viene attribuita alcuna classificazione o gravità, Patch Manager assegna ai pacchetti gli attributi della patch a cui appartengono.

------
#### [ Ubuntu Server ]

In Ubuntu Server, il servizio della baseline delle patch di Systems Manager utilizza repository preconfigurati (repository) nel nodo gestito. Questi repo preconfigurati vengono utilizzati per estrarre un elenco aggiornato degli aggiornamenti dei pacchetti disponibili. A tale scopo, Systems Manager esegue l'equivalente di un comando `sudo apt-get update`. 

I pacchetti vengono quindi filtrati da repository `codename-security`, in cui il nome in codice è univoco per la versione di rilascio, ad esempio `trusty` per Ubuntu Server 14. Patch Manager identifica esclusivamente gli aggiornamenti che fanno parte di questi repository: 
+ 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 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)

------
#### [ Windows Server ]

Nei sistemi operativi Microsoft Windows, Patch Manager consente di recuperare l'elenco degli aggiornamenti disponibili pubblicati da Microsoft e sono automaticamente disponibili su Windows Server Update Services (WSUS).

**Nota**  
Patch Manager rende disponibili esclusivamente le patch disponibili per le versioni del sistema operativo Windows Server che sono supportate per Patch Manager. Ad esempio, Patch Manager non può essere utilizzato per applicare patch a Windows RT.

Patch Manager effettua un monitoraggio continuo per nuovi aggiornamenti in ogni Regione AWS. L'elenco degli aggiornamenti disponibili viene aggiornato in ciascuna regione almeno una volta al giorno. Man mano che Microsoft elabora le informazioni sulle patch, Patch Manager rimuove dall'elenco gli aggiornamenti che sono stati sostituiti da quelli successivi. Pertanto, viene visualizzato e può essere installato solo l'aggiornamento più recente. Ad esempio, se `KB4012214` sostituisce `KB3135456`, solo `KB4012214` viene reso disponibile come aggiornamento in Patch Manager.

Allo stesso modo, Patch Manager installa solo le patch disponibili sul nodo gestito durante l'operazione di applicazione di patch. Per impostazione predefinita, Windows Server 2019 e Windows Server 2022 rimuovono gli aggiornamenti che vengono sostituiti da quelli successivi. Di conseguenza, quando si utilizza il parametro `ApproveUntilDate` in una baseline delle patch di Windows Server, ma la data selezionata nel parametro `ApproveUntilDate` è *precedente* alla data dell'ultima patch, si verifica lo scenario seguente:
+ La patch sostituita viene rimossa dal nodo e pertanto non è in grado di essere installata utilizzando Patch Manager.
+ La patch sostitutiva più recente è presente sul nodo ma non è ancora stata approvata per l'installazione in base alla data specificata dal parametro `ApproveUntilDate`. 

Ciò significa che il nodo gestito è conforme in termini di operazioni di Systems Manager, anche nel caso in cui una patch critica del mese precedente non sia installata. Lo stesso scenario potrebbe verificarsi quando si utilizza il parametro `ApproveAfterDays`. A causa del comportamento delle patch sostituite da Microsoft, è possibile impostare un numero (in genere superiore a 30 giorni) in modo che le patch per Windows Server non vengano mai installate quando l'ultima patch disponibile di Microsoft viene rilasciata prima che sia trascorso il numero di giorni su `ApproveAfterDays`. Si noti che questo comportamento del sistema non si applica quando si sono modificate le impostazioni del GPO (Windows Group Policy Object) per rendere disponibile la patch sostituita sui nodi gestiti.

**Nota**  
In alcuni casi, Microsoft rilascia patch per applicazioni che non specificano una data e un'ora aggiornate. In questi casi, una data e un'ora aggiornate di `01/01/1970` viene fornito per impostazione predefinita.

------

# Come specificare un repository alternativo di origine delle patch (Linux)
<a name="patch-manager-alternative-source-repository"></a>

Quando si utilizzano gli archivi predefiniti configurati su un nodo gestito per le operazioni di patchingPatch Manager, uno strumento in AWS Systems Manager cerca o installa le patch relative alla sicurezza. Questo è il comportamento predefinito per Patch Manager. Per informazioni dettagliate sulle modalità in cui Patch Manager seleziona e installa le patch di sicurezza, consulta [Come vengono selezionate le patch di sicurezza](patch-manager-selecting-patches.md).

Nei sistemi Linux, tuttavia, è possibile anche usare Patch Manager per installare patch non correlate alla sicurezza o che si trovano in un repository di origine diverso da quello di default configurato nel nodo gestito. È possibile specificare repository alternativi di origine delle patch al momento della creazione di una baseline delle patch personalizzata. In ciascuna baseline delle patch personalizzata, è possibile specificare le configurazioni di origine delle patch per un massimo di 20 versioni di un sistema operativo Linux supportato. 

Ad esempio, supponiamo che il tuo parco istanze Ubuntu Server includa anche nodi Ubuntu Server 25.04 gestiti. In questo caso è possibile specificare repository alternativi per ciascuna versione nella stessa baseline delle patch personalizzata. Per ciascuna versione, sarà necessario specificare un nome, il tipo di versione del sistema operativo (prodotto) e fornire una configurazione del repository. È possibile anche specificare un singolo repository di origine alternativo valido per tutte le versioni di un sistema operativo supportato.

**Nota**  
L'esecuzione di una baseline delle patch di base personalizzata che specifica repository di patch alternativi per un nodo gestito non li rende i nuovi repository di default del sistema operativo. Al termine dell'operazione di applicazione di patch, i repository precedentemente definiti come valori predefiniti del sistema operativo del nodo rimangono valori predefiniti.

Per un elenco di scenari di esempio per l'utilizzo di questa opzione, consulta [Utilizzi di esempio per repository alternativi di origine delle patch](#patch-manager-alternative-source-repository-examples) più avanti in questo argomento.

Per informazioni sulle baseline delle patch predefinite e personalizzate, consulta [Baseline delle patch predefinite e personalizzate](patch-manager-predefined-and-custom-patch-baselines.md).

**Esempio: utilizzo della console**  
Per specificare repository alternativi di origine delle patch con la console Systems Manager, utilizza la sezione **Origini patch** della pagina **Creazione di una baseline delle patch**. Per ulteriori informazioni sull'utilizzo delle opzioni **Patch sources** (Origini patch), consulta [Creazione di una baseline delle patch personalizzata per Linux](patch-manager-create-a-patch-baseline-for-linux.md).

**Esempio: utilizzo del AWS CLI**  
Per un esempio di utilizzo dell'opzione `--sources` con AWS Command Line Interface (AWS CLI), consulta [Creazione di una baseline delle patch con repository personalizzati per varie versioni dei sistemi operativi](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).

**Topics**
+ [Considerazioni importanti sui repository alternativi](#alt-source-repository-important)
+ [Utilizzi di esempio per repository alternativi di origine delle patch](#patch-manager-alternative-source-repository-examples)

## Considerazioni importanti sui repository alternativi
<a name="alt-source-repository-important"></a>

Durante la pianificazione della strategia di applicazione di patch con repository alternativi, tieni presente quanto segue:

**Applica le verifiche degli aggiornamenti dei repository (YUM e DNF)**  
Una configurazione predefinita per un gestore di pacchetti su una distribuzione Linux potrebbe essere impostata per ignorare un archivio di pacchetti non raggiungibile se non è possibile stabilire la connessione al repository. Per applicare la verifica degli aggiornamenti del repository, aggiungi alla configurazione del repository. `skip_if_unavailable=False`

Per ulteriori informazioni sull'opzione `skip_if_available`, consulta [Connettività all'origine della patch](patch-manager-prerequisites.md#source-connectivity).

**Per l'applicazione di patch vengono utilizzati solo i repository specificati**  
La specifica di repository alternativi non comporta l'*aggiunta* di altri repository. È possibile scegliere di specificare repository diversi da quelli configurati come predefiniti in un nodo gestito. Tuttavia, per fare in modo che vengano applicati i relativi aggiornamenti, dovrai anche specificare i repository predefiniti come parte della configurazione dell'origine delle patch alternativa.

Ad esempio, su tutti i nodi gestiti Amazon Linux 2, i repository di default sono `amzn2-core` e `amzn2extra-docker`. Se desideri includere il repository Extra Packages for Enterprise Linux (EPEL) nelle operazioni di applicazione di patch, dovrai specificare tutti i tre repository come repository alternativi.

**Nota**  
L'esecuzione di baseline delle patch personalizzata che specifica repository di patch alternativi per un nodo gestito non li rende nuovi repository predefiniti del sistema operativo. Al termine dell'operazione di applicazione di patch, i repository precedentemente definiti come valori predefiniti del sistema operativo del nodo rimangono valori predefiniti.

**Il comportamento dell'applicazione di patch per distribuzioni basate su YUM dipende dal manifesto updateinfo.xml**  
Quando specifichi repository di batch alternativi per distribuzioni basate su YUM, come Amazon Linux 2, oppure Red Hat Enterprise Linux, il comportamento dell'applicazione di patch varia a seconda che il repository includa o meno un manifesto di aggiornamento sotto forma di un file `updateinfo.xml` completo e correttamente formattato. Questo file specifica la data di rilascio, le classificazioni e le gravità dei vari pacchetti. Una qualsiasi delle seguenti attività inciderà sul comportamento dell'applicazione di patch:
+ Se applichi filtri in base alla **classificazione** e alla **gravità**, ma queste non sono specificate in `updateinfo.xml`, il pacchetto non verrà incluso dal filtro. Ciò significa anche che i pacchetti senza un file `updateinfo.xml` non saranno inclusi nell'applicazione di patch.
+ Se attivi il filtro **ApprovalAfterDays**, ma la data di rilascio del pacchetto non è in formato Unix Epoch (o non ha una data di rilascio specificata), il pacchetto non verrà incluso dal filtro.
+ Si verifica un'eccezione se selezioni la casella di controllo **Includi aggiornamenti non critici** nella pagina **Crea baseline delle patch**. In questo caso, i pacchetti senza un file `updateinfo.xml` (o quelli contenenti questo file senza i valori **Classification** (Classificazione), **Severity** (Gravità) e **Date** (Data) formattati correttamente) *saranno* inclusi nell'elenco prefiltrato delle patch. Per essere installati, dovranno comunque soddisfare gli altri requisiti delle regole della baseline delle patch.

## Utilizzi di esempio per repository alternativi di origine delle patch
<a name="patch-manager-alternative-source-repository-examples"></a>

**Esempio 1 - Aggiornamenti non correlati alla sicurezza per Ubuntu Server**  
Stai già utilizzando Patch Manager per installare patch di sicurezza su una flotta di nodi Ubuntu Server gestiti utilizzando la linea di base di patch predefinita AWS fornita. `AWS-UbuntuDefaultPatchBaseline` È possibile creare una nuova baseline delle patch basata su quella predefinita, specificando però nelle regole di approvazione che desideri installare anche aggiornamenti non correlati alla sicurezza che fanno parte della distribuzione predefinita. Quando questa baseline delle patch viene eseguita nei tuoi nodi, vengono applicate le patch sia per le problematiche relative alla sicurezza sia per quelle di altro tipo. È possibile scegliere di approvare le patch non correlate alla sicurezza anche nelle eccezioni specificate per una baseline.

**Esempio 2 - Personal Package Archives (PPA) per Ubuntu Server**  
I nodi gestiti di Ubuntu Server eseguono un software distribuito tramite un [Personal Package Archives (PPA) per Ubuntu](https://launchpad.net/ubuntu/+ppas). In questo caso, devi creare una baseline delle patch che specifichi un repository PPA configurato nei nodi gestiti come repository di origine per l'applicazione di patch. Sarà quindi possibile utilizzare Run Command per eseguire il documento della baseline delle patch nei nodi.

**Esempio 3: applicazioni aziendali interne in versioni Amazon Linux supportate**  
Nei nodi gestiti Amazon Linux, devi eseguire alcune applicazioni necessarie per la conformità normativa del settore. È possibile configurare un repository per queste applicazioni nei nodi, utilizzare YUM per installare inizialmente le applicazioni, quindi aggiornare o creare una nuova baseline delle patch per includere il nuovo repository aziendale. Successivamente, potrai utilizzare Run Command per eseguire il documento `AWS-RunPatchBaseline` con l'opzione `Scan` per assicurarti che il pacchetto aziendale sia elencato tra quelli installati e sia aggiornato nel nodo gestito. Se non è aggiornato, è possibile eseguire nuovamente il documento con l'opzione `Install` per aggiornare le applicazioni. 

# Come vengono installate le patch
<a name="patch-manager-installing-patches"></a>

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 Manager non installa un nuovo pacchetto che sostituisce uno obsoleto attualmente installato. (Eccezioni: il nuovo pacchetto è una dipendenza di un altro pacchetto in fase di aggiornamento che è stato installato 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 divenuto obsoleto e installarne il sostituto, potrebbe essere necessario utilizzare uno script personalizzato o utilizzare comandi di gestione del pacchetto 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 da 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 ignorate le fasi 2-7.

1. Applicare [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) come specificato nella baseline delle patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione. 

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) come specificato nella baseline delle 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 baseline delle 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.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) come specificato nella baseline delle patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o se nessuna regola di approvazione specificata in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) concede l'approvazione.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) come specificato nella baseline delle patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

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

1. 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**, questa ha un elenco di GRAVITÀ di `[Critical, Important]` e un elenco di CLASSIFICAZIONE di `[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 quelli ormai obsoleti con nomi diversi vengono installati se si eseguono questi comandi `yum` o `dnf` all'esterno di Patch Manager. Tuttavia, *non* vengono installati con operazioni di Patch Managerequivalenti.

**Dettagli di patch aggiuntivi per Amazon Linux 2023**  
Supporto per il livello di gravità 'Nessuno'  
Amazon Linux 2023 supporta anche il livello `None` di gravità delle patch, riconosciuto dal gestore di pacchetti DNF.   
Supporto 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 baseline delle patch, sulle istanze vengono installate anche le patch di gravità `Moderate` di quelle esterne.  
Quando esegui una query per i dati di conformità utilizzando l'operazione API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html), il filtro per il livello di gravità `Medium` riporta le patch con entrambi i livelli di gravità `Medium` e `Moderate`.  
Gestione delle dipendenze transitive per Amazon Linux 2023  
Per Amazon Linux 2023, Patch Manager potrebbe installare versioni diverse di dipendenze transitive rispetto all'installazione di comandi `dnf` equivalenti. Le dipendenze transitive sono pacchetti installati automaticamente per soddisfare i requisiti di altri pacchetti (dipendenze di 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.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**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](patch-manager-prerequisites.md#source-connectivity).

------
#### [ 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 ignorate le fasi 2-7.

   Applicare [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) come specificato nella baseline delle patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione. 

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) come specificato nella baseline delle 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 baseline delle 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.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) come specificato nella baseline delle patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o se nessuna regola di approvazione specificata in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) concede l'approvazione.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) come specificato nella baseline delle patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

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

1. L'aggiornamento DNF su CentOS Stream viene applicato alle patch approvate.
**Nota**  
Per CentOS Stream, Patch Manager potrebbe installare versioni diverse delle dipendenze transitive rispetto all'installazione di comandi `dnf` equivalenti. Le dipendenze transitive sono pacchetti installati automaticamente per soddisfare i requisiti di altri pacchetti (dipendenze di 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.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ 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.

1. Se è disponibile un aggiornamento per `python3-apt` (un'interfaccia di libreria Python per`libapt`), 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**).

1. Applicare [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) come specificato nella baseline delle patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione. 

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) come specificato nella baseline delle 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 baseline delle 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, le versioni candidate alle patch sono limitate alle patch incluse in `debian-security`.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) come specificato nella baseline delle patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o se nessuna regola di approvazione specificata in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) concede l'approvazione.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) come specificato nella baseline delle patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

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

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ 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` (per`installer`) 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.

1. Applicare [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) come specificato nella baseline delle patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione. 

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) come specificato nella baseline delle patch. Ciascuna regola di approvazione è in grado di definire un pacchetto come approvato.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) come specificato nella baseline delle patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o se nessuna regola di approvazione specificata in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) concede l'approvazione.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) come specificato nella baseline delle patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

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

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

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ 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 ignorate le fasi 2-7.

1. Applicare [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) come specificato nella baseline delle patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione. 

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) come specificato nella baseline delle 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 baseline delle 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.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) come specificato nella baseline delle patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o se nessuna regola di approvazione specificata in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) concede l'approvazione.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) come specificato nella baseline delle patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

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

1. 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 all'installazione di comandi `dnf` equivalenti. Le dipendenze transitive sono pacchetti installati automaticamente per soddisfare i requisiti di altri pacchetti (dipendenze di 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 quelli ormai obsoleti con nomi diversi vengono installati se si eseguono questi comandi `yum` o `dnf` all'esterno di Patch Manager. Tuttavia, *non* vengono installati con operazioni di Patch Managerequivalenti.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**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](patch-manager-prerequisites.md#source-connectivity).

------
#### [ 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 ignorate le fasi 2-7.

1. Applicare [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) come specificato nella baseline delle patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione. 

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) come specificato nella baseline delle 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 baseline delle 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.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) come specificato nella baseline delle patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o se nessuna regola di approvazione specificata in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) concede l'approvazione.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) come specificato nella baseline delle patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

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

1. 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 critici esclusi**
   + **Si applica a**: linee di base di patch predefinite fornite da e linee di base di patch personalizzate. AWS 
   + 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 baseline delle 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 sommario di tutti gli aggiornamenti precedenti, ma la versione più recente potrebbe non corrispondere alle baseline delle patch e viene omessa dall'operazione di applicazione di patch.
   + **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 installati automaticamente per soddisfare i requisiti di altri pacchetti (dipendenze di 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 critici inclusi**
   + **Si applica a**: baseline delle patch personalizzate.
   + Casella di controllo **Includi aggiornamenti non critici**: selezionata.
   + **Patch applicate**: vengono applicate le patch in `updateinfo.xml` *e* quelle non incluse in `updateinfo.xml` (aggiornamenti di sicurezza e non critici).
   + **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 quelli ormai obsoleti con nomi diversi vengono installati se si eseguono questi comandi `yum` o `dnf` all'esterno di Patch Manager. Tuttavia, *non* vengono installati con operazioni di Patch Managerequivalenti.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**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](patch-manager-prerequisites.md#source-connectivity).

------
#### [ 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 ignorate le fasi 2-7.

1. Applicare [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) come specificato nella baseline delle patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione. 

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) come specificato nella baseline delle 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 baseline delle 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.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) come specificato nella baseline delle patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o se nessuna regola di approvazione specificata in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) concede l'approvazione.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) come specificato nella baseline delle patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

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

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

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ 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.

1. Se è disponibile un aggiornamento per `python3-apt` (un'interfaccia di libreria Python per`libapt`), 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**).

1. Applicare [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) come specificato nella baseline delle patch, mantenendo solo i pacchetti qualificati per un'ulteriore elaborazione. 

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) come specificato nella baseline delle 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 baseline delle 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 baseline delle 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 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) come specificato nella baseline delle patch. Le patch vengono approvate per l'aggiornamento anche se sono ignorate da [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o se nessuna regola di approvazione specificata in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) concede l'approvazione.

1. Applica [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) come specificato nella baseline delle patch. Le patch rifiutate vengono rimosse dall'elenco di quelle approvate e non saranno applicate.

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

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Windows Server ]

Se l'operazione di applicazione elle patch viene eseguita in un nodo gestito Windows Server, il nodo richiede uno snapshot della baseline delle patch appropriata da Systems Manager. Tale snapshot contiene l'elenco di tutti gli aggiornamenti disponibili nella baseline delle 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).) Il riepilogo dell'applicazione di patch è disponibile nell'output della richiesta Run Command. I log aggiuntivi sono disponibili nel nodo gestito della cartella `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`.

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 di patch.   
Per informazioni sulla creazione di baseline delle patch personalizzate, consulta i seguenti argomenti:  
 [Creazione di una baseline delle patch personalizzata per Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
 [Creare una baseline delle patch (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Formati dei nomi dei pacchetti per sistemi operativi Windows](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)

------

# Funzionamento delle regole delle baseline delle patch nei sistemi Linux
<a name="patch-manager-linux-rules"></a>

Le regole di una baseline delle patch nelle distribuzioni Linux operano in modo diverso in base al tipo di distribuzione. A differenza degli aggiornamenti delle patch sui nodi Windows Server gestiti, le regole vengono valutate su ciascun nodo per prendere in considerazione i repository configurati sull'istanza. Patch Manager, uno strumento in AWS Systems Manager, utilizza il gestore di pacchetti nativo per guidare l'installazione delle patch approvate dalla patch baseline.

Per i sistemi operativi basati su Linux che segnalano un livello di gravità per le patch, Patch Manager utilizza il livello di gravità riportato dal publisher del software per la notifica di aggiornamento o la singola patch. Patch Manager non ottiene i livelli di gravità da fonti di terze parti, come il [CVSS](https://www.first.org/cvss/) (Common Vulnerability Scoring System), o dai parametri rilasciati dall'[NVD](https://nvd.nist.gov/vuln) (National Vulnerability Database).

**Topics**
+ [Funzionamento della baseline delle patch in Amazon Linux 2 e Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Funzionamento delle regole delle baseline delle patch in CentOS Stream](#linux-rules-centos)
+ [Funzionamento delle regole delle baseline delle patch in Debian Server](#linux-rules-debian)
+ [Funzionamento delle regole delle baseline delle patch in macOS](#linux-rules-macos)
+ [Funzionamento delle regole delle baseline delle patch in Oracle Linux](#linux-rules-oracle)
+ [Come funzionano le regole di base delle patch su AlmaLinuxRHEL, e Rocky Linux](#linux-rules-rhel)
+ [Funzionamento delle regole delle baseline delle patch in SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Funzionamento delle regole delle baseline delle patch in Ubuntu Server](#linux-rules-ubuntu)

## Funzionamento della baseline delle patch in Amazon Linux 2 e Amazon Linux 2023
<a name="linux-rules-amazon-linux"></a>

**Nota**  
Amazon Linux 2023 (AL2023) utilizza repository con versioni che possono essere bloccati su una versione specifica tramite una o più impostazioni di sistema. Per tutte le operazioni di patching sulle istanze AL2023 EC2Patch Manager, utilizza le versioni più recenti del repository, indipendentemente dalla configurazione del sistema. Per ulteriori informazioni, consulta [Aggiornamenti deterministici tramite repository con versioni](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) nella *Guida per l'utente di Amazon Linux 2023*.

Su Amazon Linux 2 e Amazon Linux 2023, il processo di selezione delle patch è il seguente:

1. Sul nodo gestito, la libreria YUM (Amazon Linux 2) o la libreria DNF (Amazon Linux 2023) accede al file `updateinfo.xml` per ogni repository configurato. 

   Se non è presente un file `updateinfo.xml`, l'installazione delle patch dipende dalle impostazioni per **Le patch approvate includono aggiornamenti non critici** e **Approvazione automatica**. Ad esempio, se gli aggiornamenti non relativi alla protezione sono consentiti, vengono installati quando arriva l'ora di approvazione automatica.

1. Ogni avviso di aggiornamento di `updateinfo.xml` include vari attributi che denotano le proprietà dei pacchetti dell'avviso, come descritto nella seguente tabella.  
**Attributi degli avvisi di aggiornamento**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).

1. Il prodotto del nodo gestito è determinato da SSM Agent. Questo attributo corrisponde al valore dell'attributo chiave Product nel tipo di dati [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) della baseline delle patch.

1. La selezione dei pacchetti per l'aggiornamento si basa sulle seguenti linee guida.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Per informazioni sui valori dello stato di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).

## Funzionamento delle regole delle baseline delle patch in CentOS Stream
<a name="linux-rules-centos"></a>

I repository CentOS Stream predefiniti non includono un file `updateinfo.xml`. Tuttavia, i repository personalizzati creati o utilizzati potrebbero includere questo file. In questo argomento, i riferimenti a `updateinfo.xml` si applicano solo a questi repository personalizzati.

Di seguito è riportato processo di selezione delle patch in CentOS Stream:

1. Nel nodo gestito, la libreria DNF accede al `updateinfo.xml` file, qualora esistesse in un repository personalizzato, per ciascun repository configurato.

   Quando non viene rilevato un file `updateinfo.xml`, che include sempre i repository predefiniti, l'installazione delle patch dipende dalle impostazioni per **Includi aggiornamenti non critici** e **Approvazione automatica**. Ad esempio, se gli aggiornamenti non relativi alla protezione sono consentiti, vengono installati quando arriva l'ora di approvazione automatica.

1. Quando `updateinfo.xml` è presente, ogni avviso di aggiornamento nel file include vari attributi che denotano le proprietà dei pacchetti dell'avviso, come descritto nella seguente tabella.  
**Attributi degli avvisi di aggiornamento**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).

1. In tutti i casi, Il prodotto del nodo gestito è determinato da SSM Agent. Questo attributo corrisponde al valore dell'attributo chiave Product nel tipo di dati [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) della baseline delle patch.

1. La selezione dei pacchetti per l'aggiornamento si basa sulle seguenti linee guida.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Per informazioni sui valori dello stato di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).

## Funzionamento delle regole delle baseline delle patch in Debian Server
<a name="linux-rules-debian"></a>

In Debian Server, il servizio delle baseline delle patch offre l'applicazione di filtri nei campi *Priorità* e *Sezione *. Questi campi sono in genere presenti per tutti pacchetti Debian Server. Per determinare se una patch è stata selezionata dalla baseline delle patch, Patch Manager effettua quanto segue:

1. Nei sistemi Debian Server, viene eseguito l'equivalente di `sudo apt-get update` per aggiornare l'elenco dei pacchetti disponibili. I repo non vengono configurati e i dati vengono estratti dai repo configurati in un elenco `sources`.

1. Se è disponibile un aggiornamento per `python3-apt` (un'interfaccia di libreria Python per`libapt`), 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**).

1. Quindi, vengono applicati gli elenchi [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) e [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches).
**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 baseline delle 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. In questo caso, per Debian Server, le versioni candidate alle patch sono limitate alle patch incluse nei seguenti repository:

   Questi repository sono denominati come segue:
   + Debian Server11: `debian-security bullseye`
   + Debian Server12: `debian-security bookworm`

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

   Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).

Per visualizzare i contenuti dei campi *Priority (Priorità)* e *Section (Sezione)*, eseguire il seguente comando `aptitude`: 

**Nota**  
Potrebbe essere necessario installare prima Aptitude nei sistemi Debian Server.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

Nella risposta a questo comando, tutti i pacchetti aggiornabili vengono specificati in questo formato: 

```
name, priority, section, archive, candidate version
```

Per informazioni sui valori dello stato di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).

## Funzionamento delle regole delle baseline delle patch in macOS
<a name="linux-rules-macos"></a>

Di seguito è riportato processo di selezione delle patch in macOS:

1. Sul nodo gestito, Patch Manager accede al contenuto analizzato del file `InstallHistory.plist` e identifica i nomi e le versioni dei pacchetti. 

   Per dettagli sul processo di analisi, consulta la sezione **macOS** in [Come vengono installate le patch](patch-manager-installing-patches.md).

1. Il prodotto del nodo gestito è determinato da SSM Agent. Questo attributo corrisponde al valore dell'attributo chiave Product nel tipo di dati [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) della baseline delle patch.

1. La selezione dei pacchetti per l'aggiornamento si basa sulle seguenti linee guida.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Per informazioni sui valori dello stato di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).

## Funzionamento delle regole delle baseline delle patch in Oracle Linux
<a name="linux-rules-oracle"></a>

Di seguito è riportato processo di selezione delle patch in Oracle Linux:

1. Nel nodo gestito, la libreria YUM accede al file `updateinfo.xml` per ciascun repo configurato.
**Nota**  
Il file `updateinfo.xml` potrebbe non essere disponibile se il repo non è gestito da Oracle Oracle. Se non viene rilevato un file `updateinfo.xml`, l'installazione delle patch dipende dalle impostazioni per **Includi aggiornamenti non critici** e **Approvazione automatica**. Ad esempio, se gli aggiornamenti non relativi alla protezione sono consentiti, vengono installati quando arriva l'ora di approvazione automatica.

1. Ogni avviso di aggiornamento di `updateinfo.xml` include vari attributi che denotano le proprietà dei pacchetti dell'avviso, come descritto nella seguente tabella.  
**Attributi degli avvisi di aggiornamento**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).

1. Il prodotto del nodo gestito è determinato da SSM Agent. Questo attributo corrisponde al valore dell'attributo chiave Product nel tipo di dati [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) della baseline delle patch.

1. La selezione dei pacchetti per l'aggiornamento si basa sulle seguenti linee guida.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Per informazioni sui valori dello stato di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).

## Come funzionano le regole di base delle patch su AlmaLinuxRHEL, e Rocky Linux
<a name="linux-rules-rhel"></a>

Su AlmaLinux, Red Hat Enterprise Linux (RHEL) eRocky Linux, il processo di selezione delle patch è il seguente:

1. Sul nodo gestito, la libreria YUM (RHEL7) o la libreria DNF (AlmaLinux 8 e 9, RHEL 8, 9 e 10 e Rocky Linux 8 e 9) accede al `updateinfo.xml` file per ogni repository configurato.
**Nota**  
Il file `updateinfo.xml` potrebbe non essere disponibile se il repo non è gestito da Red Hat. Se non viene trovato alcun file `updateinfo.xml`, non verrà applicata nessuna patch.

1. Ogni avviso di aggiornamento di `updateinfo.xml` include vari attributi che denotano le proprietà dei pacchetti dell'avviso, come descritto nella seguente tabella.  
**Attributi degli avvisi di aggiornamento**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).

1. Il prodotto del nodo gestito è determinato da SSM Agent. Questo attributo corrisponde al valore dell'attributo chiave Product nel tipo di dati [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) della baseline delle patch.

1. La selezione dei pacchetti per l'aggiornamento si basa sulle seguenti linee guida.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Per informazioni sui valori dello stato di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).

## Funzionamento delle regole delle baseline delle patch in SUSE Linux Enterprise Server
<a name="linux-rules-sles"></a>

In SLES, ogni patch include i seguenti attributi che denotano le proprietà dei pacchetti della patch:
+ **Category**: corrisponde al valore dell'attributo chiave **Classification** nel tipo di dati [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) della baseline delle patch. Indica il tipo di patch incluso nell'avviso di aggiornamento.

  È possibile visualizzare l'elenco dei valori supportati utilizzando il AWS CLI comando **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** o l'operazione **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** API. È anche possibile visualizzare l'elenco nell'area **Norme di approvazione**della pagina **Create patch baseline (Creazione di una baseline delle patch)** della pagina**Edit patch baseline (Modifica della baseline delle patch)** nella console Systems Manager.
+ **Gravità**: corrisponde al valore dell'attributo chiave **Gravità** nel tipo di dati [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) della baseline delle patch. Indica la gravità delle patch.

  È possibile visualizzare l'elenco dei valori supportati utilizzando il AWS CLI comando **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** o l'operazione API**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. È anche possibile visualizzare l'elenco nell'area **Norme di approvazione**della pagina **Create patch baseline (Creazione di una baseline delle patch)** della pagina**Edit patch baseline (Modifica della baseline delle patch)** nella console Systems Manager.

Il prodotto del nodo gestito è determinato da SSM Agent. Questo attributo corrisponde al valore dell'attributo chiave **Product** nel tipo di dati [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) della baseline delle patch. 

Per ogni patch, la baseline delle patch viene utilizzata come filtro, per includere nell'aggiornamento solo i pacchetti qualificati. Se più pacchetti sono applicabili dopo l'applicazione della definizione della baseline delle patch, verrà utilizzata la versione più recente. 

Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).

## Funzionamento delle regole delle baseline delle patch in Ubuntu Server
<a name="linux-rules-ubuntu"></a>

In Ubuntu Server, il servizio delle baseline delle patch offre l'applicazione di filtri nei campi *Priorità* e *Sezione*. Questi campi sono in genere presenti per tutti pacchetti Ubuntu Server. Per determinare se una patch è stata selezionata dalla baseline delle patch, Patch Manager effettua quanto segue:

1. Nei sistemi Ubuntu Server, viene eseguito l'equivalente di `sudo apt-get update` per aggiornare l'elenco dei pacchetti disponibili. I repo non vengono configurati e i dati vengono estratti dai repo configurati in un elenco `sources`.

1. Se è disponibile un aggiornamento per `python3-apt` (un'interfaccia di libreria Python per`libapt`), 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**).

1. Quindi, vengono applicati gli elenchi [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) e [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches).
**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 baseline delle 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. In questo caso, per Ubuntu Server, le versioni candidate alle patch sono limitate alle patch incluse nei seguenti repository:
   + 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 24.04 LTS (`noble-security`)
   + Ubuntu Server 25.04 (`plucky-security`)

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

   Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).

Per visualizzare i contenuti dei campi *Priority (Priorità)* e *Section (Sezione)*, eseguire il seguente comando `aptitude`: 

**Nota**  
Potrebbe essere necessario installare prima Aptitude nei sistemi Ubuntu Server 16.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

Nella risposta a questo comando, tutti i pacchetti aggiornabili vengono specificati in questo formato: 

```
name, priority, section, archive, candidate version
```

Per informazioni sui valori dello stato di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).

# Differenze nelle operazioni di applicazione di patch tra Linux e Windows Server
<a name="patch-manager-windows-and-linux-differences"></a>

Questo argomento illustra le differenze fondamentali tra l'applicazione di patch in Linux e Windows Server in Patch Manager, uno strumento di AWS Systems Manager.

**Nota**  
Per applicare patch ai nodi gestiti Linux, i nodi devono essere in esecuzione la versione 2.0.834.0 SSM Agent o successive.  
Una versione aggiornata di SSM Agent viene distribuita ogni volta che vengono aggiunti nuovi strumenti a Systems Manager o eseguiti aggiornamenti degli strumenti esistenti. Il mancato utilizzo della versione più recente dell'agente può impedire al nodo gestito di utilizzare vari strumenti e funzionalità di Systems Manager. Per questo motivo, ti consigliamo di automatizzare il processo di aggiornamento di SSM Agent sulle macchine. Per informazioni, consulta [Automazione degli aggiornamenti di SSM Agent](ssm-agent-automatic-updates.md). Iscriviti alla pagina [Note di rilascio di SSM Agent](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) su GitHub per ricevere notifiche sugli aggiornamenti di SSM Agent.

## Differenza 1: valutazione delle patch
<a name="patch-evaluation_diff"></a>

Patch Manager utilizza diversi processi sui nodi gestiti Windows e Linux per valutare quali patch devono essere presenti. 

**Linux**  
Per l'applicazione di patch in Linux, Systems Manager valuta le regole della baseline delle patch e l'elenco delle patch approvate e rifiutate in *ciascun* nodo gestito. Systems Manager deve valutare l'applicazione di patch in ogni nodo perché il servizio recupera l'elenco delle patch e aggiornamenti noti dai repository configurati nel nodo gestito.

**Windows**  
Per l'applicazione di patch in Windows, Systems Manager valuta le regole della baseline delle patch e l'elenco delle patch approvate e rifiutate *direttamente nel servizio*. Può eseguire questa operazione perché le patch di Windows vengono estratte da un unico repository (Windows Update).

## Differenza 2: patch `Not Applicable`
<a name="not-applicable-diff"></a>

A causa del numero elevato di pacchetti disponibili per i sistemi operativi Linux, Systems Manager non indica i dettagli delle patch con lo stato *Not Applicable* Una patch `Not Applicable` è, ad esempio, una patch per il software Apache quando nell'istanza non è installato Apache. Systems Manager riporta il numero di `Not Applicable` patch nel riepilogo, ma se si chiama l'[DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html)API per un nodo gestito, i dati restituiti non includono le patch con uno stato di. `Not Applicable` Questo comportamento è diverso da quello in Windows.

## Differenza 3: supporto dei documenti SSM
<a name="document-support-diff"></a>

Il documento Systems Manager `AWS-ApplyPatchBaseline` (documento SSM) non supporta i nodi gestiti di Linux. Per l'applicazione di baseline delle patch a entrambi i nodi gestiti a Linux, macOS, e Windows Server, il documento SSM consigliato è `AWS-RunPatchBaseline`. Per ulteriori informazioni, consultare [Documenti sul comando SSM per l'applicazione di patch a nodi gestiti](patch-manager-ssm-documents.md) e [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

## Differenza 4: patch di applicazione
<a name="application-patches-diff"></a>

L'obiettivo principale di Patch Manager è l'applicazione di patch ai sistemi operativi, Tuttavia può essere utilizzato Patch Manager anche per applicare patch ad alcune applicazioni nei propri nodi gestiti.

**Linux**  
Nei sistemi operativi Linux Patch Manager usa il repository configurato per gli aggiornamenti e non fa differenze tra le patch dei sistemi operativi e quelle di applicazione. È possibile utilizzare Patch Manager per specificare da quali repository recuperare gli aggiornamenti. Per ulteriori informazioni, consulta [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md).

**Windows**  
Nei nodi gestiti di Windows Server è possibile applicare le regole di approvazione e le eccezioni relative alle patch *approvate* e *rifiutate* per le applicazioni rilasciate da Microsoft, come Microsoft Word 2016 e Microsoft Exchange Server 2016. Per ulteriori informazioni, consulta [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md).

## Differenza 5: opzioni dell'elenco delle patch rifiutate nelle baseline delle patch personalizzate
<a name="rejected-patches-diff"></a>

Quando si crea una baseline delle patch personalizzata, è possibile specificare una o più patch per un elenco di **Patch rifiutate**. Per i nodi gestiti da Linux, è possibile anche scegliere di consentirne l'installazione nel caso siano dipendenze per un'altra patch consentita dalla baseline.

Windows Server, tuttavia, non supporta il concetto di dipendenze dalle patch. È possibile aggiungere una patch all'elenco delle **Patch rifiutate** in una baseline personalizzata per Windows Server, ma il esito dipende da quanto segue: se la patch rifiutata è già installata o meno su un nodo gestito e dall'opzione scelta per l'**Operazione patch rifiutate**.

Fai riferimento alla tabella seguente per i dettagli sulle opzioni di patch rifiutate su Windows Server.


| Stato di installazione | Opzione: “Consenti come dipendenza” | Opzione: “Blocco” | 
| --- | --- | --- | 
| La patch è già installata | Stato segnalato: INSTALLED\$1OTHER | Stato segnalato: INSTALLED\$1REJECTED | 
| La patch non è già installata | Patch ignorata | Patch ignorata | 

Ogni patch per Windows Server che viene rilasciata da Microsoft contiene in genere tutte le informazioni necessarie per il corretto completamento dell'installazione. A volte, tuttavia, è necessario un pacchetto prerequisito, da installare manualmente. Patch Manager non riporta informazioni su questi prerequisiti. Per informazioni correlate, consulta la sezione [Risoluzione dei problemi di Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting) sul sito web di Microsoft.