• 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à.
# AWS Systems Manager Patch Manager
Patch Manager, uno strumento in AWS Systems Manager, automatizza il processo di applicazione di patch ai nodi gestiti sia con aggiornamenti relativi alla sicurezza che con altri tipi di aggiornamenti.
**Nota**
Systems Manager fornisce supporto per le *policy di patch* in Quick Setup, uno strumento di AWS Systems Manager. L'utilizzo delle policy di patch è il metodo consigliato per configurare le operazioni di applicazione di patch. Con una singola configurazione delle policy di patch, è possibile definire l'applicazione di patch per tutti gli account in tutte le regioni dell'organizzazione, per regioni e account selezionati o per una singola coppia account-regione. Per ulteriori informazioni, consulta [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
È possibile utilizzare Patch Manager per applicare patch sia per i sistemi operativi sia per le applicazioni. (In Windows Server, il supporto delle applicazioni è limitato ai soli aggiornamenti delle applicazioni Microsoft). È possibile utilizzare Patch Manager per installare Service Pack nei nodi di Windows ed eseguire aggiornamenti di versione secondari sui nodi di Linux. Puoi applicare patch a flotte di istanze Amazon Elastic Compute Cloud (Amazon EC2), dispositivi edge, server locali e macchine virtuali () in base al tipo di sistema operativo. VMs Sono incluse le versioni supportate di diversi sistemi operativi, come elencato su [Prerequisiti di Patch Manager](patch-manager-prerequisites.md). È possibile analizzare le istanze per visualizzare solo un report delle patch mancanti, oppure analizzare e installare automaticamente tutte le patch mancanti. Per iniziare a utilizzare Patch Manager, apri la [console di Systems Manager](https://console.aws.amazon.com//systems-manager/patch-manager). Nel pannello di navigazione, scegli **Patch Manager**.
AWS non testa le patch prima di renderle disponibili in. Patch Manager Inoltre, Patch Manager non supporta l'aggiornamento delle versioni principali dei sistemi operativi, ad esempio da Windows Server 2016 a Windows Server 2019, o da Red Hat Enterprise Linux (RHEL) 7.0 a RHEL 8.0.
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).
## Quali sono i vantaggi di Patch Manager per la mia organizzazione?
Patch Manager automatizza il processo di applicazione di patch ai nodi gestiti con aggiornamenti relativi alla sicurezza e di altro tipo. Fornisce diversi vantaggi:
+ **Controllo centralizzato dell'applicazione di patch**: tramite le policy di patch, è possibile configurare operazioni di applicazione di patch ricorrenti per tutti gli account in tutte le Regioni dell'organizzazione, in account e Regioni specifici o in una singola coppia account-regione.
+ **Operazioni di applicazione di patch flessibili**: è possibile scegliere di analizzare le istanze per visualizzare solo un report delle patch mancanti oppure analizzare e installare automaticamente tutte le patch mancanti.
+ **Esecuzione di report completi sulla conformità**: dopo le operazioni di analisi, è possibile visualizzare informazioni dettagliate su quali nodi gestiti non sono conformi alle patch e quali patch mancano.
+ **Supporto multipiattaforma**: Patch Manager supporta più sistemi operativi, tra cui varie distribuzioni Linux, macOS e Windows Server.
+ **Baseline delle patch personalizzate**: è possibile definire ciò che costituisce la conformità delle patch per l'organizzazione tramite baseline delle patch personalizzate che specificano quali patch sono approvate per l'installazione.
+ **Integrazione con altri AWS servizi**: Patch Manager si integra con AWS Organizations, AWS Security Hub CSPM AWS CloudTrail, e AWS Config per una gestione e una sicurezza avanzate.
+ **Aggiornamenti deterministici**: supporto per gli aggiornamenti deterministici tramite repository con versioni per sistemi operativi come Amazon Linux 2023.
## A chi è consigliato l'uso di Patch Manager?
Patch Manager è progettato per i seguenti casi d'uso:
+ Amministratori IT che devono mantenere la conformità delle patch in tutto il parco istanze di nodi gestiti;
+ Responsabili delle operazioni che necessitano di visibilità sullo stato di conformità delle patch nell'intera infrastruttura;
+ Architetti del cloud che desiderano implementare soluzioni di applicazione di patch automatizzate su larga scala;
+ DevOps ingegneri che devono integrare l'applicazione delle patch nei propri flussi di lavoro operativi
+ Organizzazioni che effettuano implementazioni con più account/più Regioni che necessitano di una gestione centralizzata delle patch;
+ Chiunque sia responsabile del mantenimento del livello di sicurezza e dell'integrità operativa dei nodi AWS gestiti, dei dispositivi perimetrali, dei server locali e delle macchine virtuali
## Quali sono le funzionalità principali di Patch Manager?
Patch Manager offre diverse funzionalità chiave:
+ **Politiche di patch**: configura le operazioni di applicazione delle patch in più Account AWS regioni utilizzando un'unica politica tramite l'integrazione con. AWS Organizations
+ **Baseline delle patch personalizzate**: definisci regole per l'approvazione automatica delle patch entro pochi giorni dalla relativa pubblicazione, nonché un elenco delle patch approvate e rifiutate.
+ **Diversi metodi di applicazione di patch**: scegli tra policy di patch, finestre di manutenzione oppure operazioni "Applica patch ora" su richiesta, per soddisfare le tue esigenze specifiche.
+ **Esecuzione di report di conformità**: genera report dettagliati sullo stato di conformità delle patch da inviare a un bucket Amazon S3 in formato CSV.
+ **Supporto multipiattaforma**: applica patch sia ai sistemi operativi che alle applicazioni a Windows Server, su varie distribuzioni Linux e macOS.
+ **Flessibilità di pianificazione**: imposta pianificazioni diverse per l'analisi e l'installazione delle patch utilizzando espressioni CRON o della frequenza personalizzate.
+ **Hook del ciclo di vita**: esegui script personalizzati prima e dopo le operazioni di applicazione di patch utilizzando i documenti di Systems Manager.
+ **Attenzione alla sicurezza**: per impostazione predefinita, Patch Manager si concentra sugli aggiornamenti relativi alla sicurezza anziché sull'installazione di tutte le patch disponibili.
+ **Controllo della frequenza**: configura le soglie di concorrenza e di errore nelle operazioni di applicazione di patch per ridurre al minimo l'impatto operativo.
## In cosa consiste la conformità in Patch Manager?
Il benchmark per ciò che costituisce la *conformità delle patch* per i nodi gestiti nelle flotte di Systems Manager non è definito dai AWS fornitori di sistemi operativi (OS) o da terze parti come le società di consulenza sulla sicurezza.
Al contrario, è l'utente che definisce cosa significa conformità delle patch per i nodi gestiti nell'organizzazione o nell'account in una *baseline delle patch*. Una baseline delle patch è una configurazione che specifica le regole per le quali le patch devono essere installate su un nodo gestito. Un nodo gestito è conforme alle patch quando è aggiornato con tutte le patch che soddisfano i criteri di approvazione specificati nella baseline delle patch.
Tieni presente che essere *conforme* a baseline delle patch non significa che un nodo gestito sia necessariamente *sicuro*. Conforme significa che le patch definite dalla baseline delle patch, che siano *disponibili* o *approvate*, sono state installate sul nodo. La sicurezza complessiva di un nodo gestito è determinata da molti fattori che non rientrano nell'ambito di Patch Manager. Per ulteriori informazioni, consulta [Sicurezza in AWS Systems Manager](security.md).
Ogni baseline delle patch è una configurazione per uno specifico tipo di sistema operativo (OS) supportato, ad esempio Red Hat Enterprise Linux (RHEL) macOS o Windows Server. Una baseline delle patch può definire le regole di applicazione di patch per tutte le versioni supportate di un sistema operativo o essere limitata solo a quelle specificate dall'utente, ad esempio RHEL 7.8. e RHEL 9.3.
In una baseline delle patch, è possibile specificare che tutte le patch con specifici classificazioni e livelli di gravità siano approvate per l'installazione. Ad esempio, è possibile includere tutte le patch classificate come `Security`, ma escludere altre classificazioni, come `Bugfix` o `Enhancement`. È inoltre possibile includere tutte le patch con una gravità pari a `Critical` ed escluderne altre, ad esempio `Important` e `Moderate`.
Puoi anche definire le patch in modo esplicito in una patch baseline aggiungendole IDs a elenchi di patch specifiche da approvare o rifiutare, ad esempio per `KB2736693` o Windows Server per `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` Amazon Linux 2023 (). AL2023 Facoltativamente, puoi specificare un certo numero di giorni di attesa per l'applicazione delle patch dopo che una patch diventa disponibile. Per Linux e macOS, è possibile specificare un elenco esterno di patch per la conformità (un elenco "Installa sovrascrivi") anziché quelle definite dalle regole della baseline delle patch.
Quando viene eseguita un'operazione di applicazione di patch, Patch Manager confronta le patch attualmente applicate a un nodo gestito con quelle da applicare in base alle regole configurate nella baseline delle patch. È possibile impostare Patch Manager in modo che mostri soltanto un report delle patch mancanti (un'operazione `Scan`) oppure Patch Manager può installare automaticamente tutte le patch mancanti in un nodo gestito (un'operazione `Scan and install`).
**Nota**
I dati sulla conformità delle patch rappresentano un' point-in-timeistantanea dell'ultima operazione di patching riuscita. Ogni rapporto di conformità contiene un orario di acquisizione che identifica quando è stato calcolato lo stato di conformità. Quando esamini i dati di conformità, considera il tempo di acquisizione per determinare se l'operazione è stata eseguita come previsto.
Patch Manager fornisce baseline delle patch predefinite che è possibile utilizzare per le operazioni di applicazione di patch; tuttavia, queste configurazioni predefinite vengono fornite come esempi e non come best practice consigliate. Ti consigliamo di creare baseline delle patch personalizzate per le tue patch, così potrai esercitare un maggiore controllo su ciò che costituisce la conformità delle patch per il tuo parco istanze.
Per ulteriori informazioni sulle baseline delle patch, consulta i seguenti argomenti:
+ [Baseline delle patch predefinite e personalizzate](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md)
+ [Visualizzazione delle linee di base delle patch AWS predefinite](patch-manager-view-predefined-patch-baselines.md)
+ [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md)
+ [Utilizzo dei report sulla conformità delle patch](patch-manager-compliance-reports.md)
## Componenti principali
Prima di iniziare a utilizzare lo strumento Patch Manager, è necessario acquisire familiarità con alcuni componenti e funzionalità principali delle operazioni di applicazione di patch dello strumento.
**Baseline delle patch**
Patch Manager utilizza *baseline delle patch* che includono regole per l'approvazione automatica di patch entro pochi giorni dalla relativa pubblicazione, oltre a un elenco delle patch approvate e rifiutate. Quando viene eseguita un'operazione di applicazione di patch, Patch Manager confronta le patch attualmente applicate a un nodo gestito con quelle da applicare in base alle regole configurate nella baseline delle patch. È possibile impostare Patch Manager in modo che mostri soltanto un report delle patch mancanti (un'operazione `Scan`) oppure Patch Manager può installare automaticamente tutte le patch mancanti in un nodo gestito (un'operazione `Scan and install`).
**Metodi operativi di applicazione di patch**
Patch Manager offre attualmente quattro metodi per eseguire operazioni `Scan` e `Scan and install`:
+ **(Consigliato) Una politica di patch configurata inQuick Setup: in** base all'integrazione con AWS Organizations, una singola policy di patch può definire i piani di applicazione delle patch e le linee di base delle patch per un'intera organizzazione, Regioni AWS compresi i diversi Account AWS account in cui operano. Una policy di patch può inoltre riguardare solo alcune unità organizzative (OUs) di un'organizzazione. È possibile utilizzare un'unica policy di patch per eseguire l'analisi e l'installazione in base a pianificazioni diverse. Per ulteriori informazioni, consultare [Configura l'applicazione di patch per le istanze in un'organizzazione utilizzando una policy di patch di Quick Setup](quick-setup-patch-manager.md) e [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
+ **Un'opzione di gestione degli host configurata in Quick Setup** — Le configurazioni di Host Management sono supportate anche dall'integrazione con AWS Organizations, che consente di eseguire un'operazione di patching per un massimo di un'intera organizzazione. Tuttavia, questa opzione si limita alla ricerca delle patch mancanti utilizzando l'attuale baseline delle patch predefinita e fornendo esiti nei report di conformità. Questo metodo operativo non è in grado di installare patch. Per ulteriori informazioni, consulta [Configura la gestione host Amazon EC2 tramite Quick Setup](quick-setup-host-management.md).
+ **Una finestra di manutenzione per eseguire un'attività di `Scan` o `Install` di patch** è una finestra di manutenzione configurabile nello strumento di Systems Manager chiamato Maintenance Windows. Questa configurazione serve a eseguire diversi tipi di attività secondo una pianificazione definita dall'utente. Un'attività di tipo Run Command viene utilizzata per eseguire processi `Scan` o `Scan and install` in un set di nodi gestiti di tua scelta. Ogni attività della finestra di manutenzione può indirizzare i nodi gestiti in una sola coppia Account AWS.Regione AWS Per ulteriori informazioni, consulta [Tutorial: creazione di una finestra di manutenzione per l'applicazione di patch tramite console](maintenance-window-tutorial-patching.md).
+ **Un'operazione **Patch now** (Applica subito una patch) on demand in Patch Manager**. L'opzione **Patch now** (Applica subito una patch) consente di ignorare le impostazioni di pianificazione quando è necessario applicare patch ai nodi gestiti il più rapidamente possibile. Con **Patch now** (Applica subito una patch), è possibile specificare se eseguire l'operazione `Scan` o `Scan and install` e scegliere i nodi gestiti sui cui eseguirla. È possibile inoltre scegliere di eseguire i documenti Systems Manager (documenti SSM) come hook del ciclo di vita durante l'applicazione di patch. Ogni operazione **Patch ora** può indirizzare i nodi gestiti in una sola Account AWSRegione AWS coppia. Per ulteriori informazioni, consulta [Patching dei nodi gestiti on demand](patch-manager-patch-now-on-demand.md).
**Creazione di report di conformità**
Dopo un'operazione `Scan`, è possibile utilizzare la console di Systems Manager per visualizzare le informazioni relative ai nodi gestiti che non sono conformi alle patch e alle patch mancanti per ciascun nodo. È possibile anche generare report di conformità alle patch in formato .csv inviati a un bucket Amazon Simple Storage Service (Amazon S3) di tua scelta. È possibile generare report una tantum o generare report in base a una pianificazione regolare. Per un singolo nodo, i report includono dettagli di tutte le patch per il nodo. Per un report su tutti i nodi gestiti, viene fornito solo un riepilogo del numero di patch mancanti. Dopo aver generato un report, puoi utilizzare uno strumento come Amazon Quick per importare e analizzare i dati. Per ulteriori informazioni, consulta [Utilizzo dei report sulla conformità delle patch](patch-manager-compliance-reports.md).
**Nota**
Un elemento di conformità generato tramite l'uso di una policy di patch ha un tipo di esecuzione `PatchPolicy`. Un elemento di conformità non generato in un'operazione di policy di patch presenta un tipo di esecuzione `Command`.
**Integrazioni**
Patch Managersi integra con le seguenti altre: Servizi AWS
+ **AWS Identity and Access Management (IAM)**: utilizza IAM per controllare quali utenti, gruppi e ruoli hanno accesso alle Patch Manager operazioni. Per ulteriori informazioni, consulta [Funzionamento di AWS Systems Manager con IAM](security_iam_service-with-iam.md) e [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md).
+ **AWS CloudTrail**— CloudTrail Da utilizzare per registrare una cronologia verificabile degli eventi delle operazioni di patch avviate da utenti, ruoli o gruppi. Per ulteriori informazioni, consulta [Registrazione delle chiamate AWS Systems Manager API con AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **AWS Security Hub CSPM**— I dati sulla conformità delle patch Patch Manager possono essere inviati a. AWS Security Hub CSPM Security Hub CSPM offre una visione completa degli avvisi di sicurezza ad alta priorità e dello stato di conformità. Monitora anche lo stato di applicazione di patch del parco istanze. Per ulteriori informazioni, consulta [Integrazione con Patch Manager AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
+ **AWS Config**— Configura la registrazione AWS Config per visualizzare i dati di gestione delle istanze Amazon EC2 nella Patch Manager dashboard. Per ulteriori informazioni, consulta [Visualizzazione dei riepiloghi del pannello di controllo delle patch](patch-manager-view-dashboard-summaries.md).
**Topics**
+ [Quali sono i vantaggi di Patch Manager per la mia organizzazione?](#how-can-patch-manager-benefit-my-organization)
+ [A chi è consigliato l'uso di Patch Manager?](#who-should-use-patch-manager)
+ [Quali sono le funzionalità principali di Patch Manager?](#what-are-the-main-features-of-patch-manager)
+ [In cosa consiste la conformità in Patch Manager?](#patch-manager-definition-of-compliance)
+ [Componenti principali](#primary-components)
+ [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md)
+ [Prerequisiti di Patch Manager](patch-manager-prerequisites.md)
+ [Come Patch Manager funzionano le operazioni](patch-manager-patching-operations.md)
+ [Documenti sul comando SSM per l'applicazione di patch a nodi gestiti](patch-manager-ssm-documents.md)
+ [Patch di base](patch-manager-patch-baselines.md)
+ [Utilizzo di Kernel Live Patching su nodi gestiti Amazon Linux 2](patch-manager-kernel-live-patching.md)
+ [Utilizzo delle risorse di Patch Manager e della conformità tramite la console](patch-manager-console.md)
+ [Lavorare con le risorse di Patch Manager utilizzando AWS CLI](patch-manager-cli-commands.md)
+ [tutorial AWS Systems Manager Patch Manager](patch-manager-tutorials.md)
+ [Risoluzione dei problemi relativi a Patch Manager](patch-manager-troubleshooting.md)
# Configurazioni delle policy di patch in Quick Setup
AWS consiglia l'uso di *politiche di patch* per configurare l'applicazione delle patch per l'organizzazione e. Account AWS Le policy di patch sono state introdotte su Patch Manager a dicembre 2022.
Una policy di patch è una configurazione che imposti tramite Quick Setup, uno strumento di AWS Systems Manager. Le policy di patch offrono un controllo più ampio e centralizzato sulle operazioni di applicazione di patch rispetto ai metodi precedenti. Le policy di patch possono essere utilizzate con [tutti i sistemi operativi supportati da Patch Manager](patch-manager-prerequisites.md#pm-prereqs), comprese le versioni supportate di Linux, macOS e Windows Server. Per istruzioni sulla creazione di una policy di patch, consulta [Configura l'applicazione di patch per le istanze in un'organizzazione utilizzando una policy di patch di Quick Setup](quick-setup-patch-manager.md).
## Funzionalità principali delle politiche di patch
Invece di utilizzare altri metodi per applicare patch ai nodi, impiega una policy di patch per sfruttare le funzionalità principali seguenti:
+ **Configurazione singola**: l'impostazione delle operazioni di applicazione di patch tramite una finestra di manutenzione o un'associazione State Manager può richiedere più attività in diverse parti della console di Systems Manager. Con una policy di patch, tutte le operazioni possono essere configurate in un'unica procedura guidata.
+ **Supporto per più account/più regioni**: utilizzando una finestra di manutenzione, un'State Managerassociazione o la funzionalità **Patch ora** disponibilePatch Manager, puoi scegliere come target i nodi gestiti in un'unica coppia. Account AWSRegione AWS Se utilizzi più account e regioni, le attività di configurazione e manutenzione possono richiedere molto tempo a causa dell'esecuzione delle attività di impostazione in ciascuna coppia account-regione. Tuttavia, se la utilizzi AWS Organizations, puoi impostare un'unica policy di patch che si applichi a tutti i nodi gestiti in all in all your. Regioni AWS Account AWS Oppure, se lo desideri, una policy relativa alle patch può essere applicata solo ad alcune unità organizzative (OUs) negli account e nelle regioni che scegli. Una policy di patch può essere applicata anche a un singolo account locale, se lo desideri.
+ **Supporto all'installazione a livello organizzativo**: l'opzione di configurazione di gestione host esistente in Quick Setup fornisce supporto per una scansione giornaliera dei nodi gestiti al fine di verificare la conformità delle patch. Tuttavia, tale scansione viene eseguita in un momento prestabilito e genera solo informazioni sulla conformità delle patch, senza alcuna installazione. Utilizzando una policy di patch, è possibile specificare diverse pianificazioni per la scansione e l'installazione. È possibile anche scegliere la frequenza e l'ora in cui eseguire tali operazioni con espressioni CRON o Rate personalizzate. Ad esempio, è possibile eseguire la scansione giornaliera delle patch mancanti in modo da ottenere informazioni sulla conformità regolarmente aggiornate. La pianificazione dell'installazione, tuttavia, potrebbe essere prevista solo una volta alla settimana per evitare tempi di inattività indesiderati.
+ **Selezione semplificata della baseline delle patch**: le policy di patch incorporano le baseline delle patch e non vi sono modifiche alla loro modalità di configurazione. Tuttavia, quando crei o aggiorni una policy relativa alle patch, puoi selezionare la baseline AWS gestita o personalizzata che desideri utilizzare per ogni tipo di sistema operativo (OS) in un unico elenco. Non è necessario specificare la baseline predefinita per ogni tipo di sistema operativo in attività separate.
**Nota**
Durante l'applicazione di patch in base all'esecuzione di una policy di patch, si utilizza il documento SSM `AWS-RunPatchBaseline`. Per ulteriori informazioni, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
**Informazioni correlate**
[Implementa centralmente le operazioni di patching in tutta AWS l'organizzazione utilizzando Systems Manager Quick Setup (blog](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/) sulle operazioni e le migrazioni AWS sul cloud)
## Altre differenze relative alle policy di patch
Di seguito sono riportate altre differenze da notare quando si utilizzano policy di patch anziché metodi precedenti:
+ **Non sono richiesti gruppi di patch**: nelle precedenti operazioni di applicazione di patch, era possibile assegnare tag a più nodi appartenenti a un unico gruppo di patch e quindi specificare la baseline delle patch da utilizzare per tale gruppo . Se non si specificava alcun gruppo, Patch Manager applicava le patch alle istanze con la baseline delle patch predefinita corrente per il tipo di sistema operativo. Con le policy di patch, non è più necessario configurare e gestire gruppi di patch.
**Nota**
La funzionalità dei gruppi di patch non è supportata nella console per le coppie account-Regione, che non utilizzavano già i gruppi di patch prima del rilascio del supporto per le policy di patch il 22 dicembre 2022. La funzionalità dei gruppi di patch è ancora disponibile nelle coppie account-Regione, che hanno iniziato a utilizzare i gruppi di patch prima di questa data.
+ **È stata rimossa la pagina "Configure patching"** (Configurazione dell'applicazione di patch): prima del rilascio delle policy di patch, era possibile specificare l'operazione di applicazione di patch e i valori predefiniti per i nodi a cui applicarle nella pagina **Configure patching** (Configurazione dell'applicazione di patch). Questa pagina è stata rimossa da Patch Manager e le relative opzioni sono ora specificate nelle policy di patch.
+ **Nessun supporto «Patch now»**: la possibilità di applicare patch ai nodi su richiesta è ancora limitata a una singola Account AWS coppia alla volta.Regione AWS Per informazioni, consulta [Patching dei nodi gestiti on demand](patch-manager-patch-now-on-demand.md).
+ **Policy di patch e informazioni sulla conformità**: quando i nodi gestiti vengono analizzati per verificarne la conformità in base a una configurazione delle policy di patch, i dati sulla conformità vengono messi a disposizione dell'utente. È possibile visualizzare e utilizzare i dati nello stesso modo in cui impieghi altri metodi di scansione della conformità. Sebbene sia possibile impostare una policy di patch per un'intera organizzazione o per più unità organizzative, le informazioni sulla conformità vengono riportate individualmente per ciascuna coppia Account AWS.Regione AWS Per ulteriori informazioni, consulta [Utilizzo dei report sulla conformità delle patch](patch-manager-compliance-reports.md).
+ **Stato di conformità dell'associazione e policy di patch**: lo stato di applicazione di patch per un nodo gestito soggetto a una policy Quick Setup di patch corrisponde allo stato dell'esecuzione dell'associazione State Manager per quel nodo. Quando lo stato di esecuzione dell'associazione è `Compliant`, anche lo stato di applicazione di patch per il nodo gestito viene contrassegnato come `Compliant`. Quando lo stato di esecuzione dell'associazione è `Non-Compliant`, anche lo stato di applicazione di patch per il nodo gestito viene contrassegnato come `Non-Compliant`.
## Regioni AWS supportata per le politiche relative alle patch
Le configurazioni delle policy di patch in Quick Setup sono attualmente supportate nelle seguenti regioni:
+ Stati Uniti orientali (Ohio) (us-east-2)
+ Stati Uniti orientali (Virginia settentrionale) (us-east-1)
+ Stati Uniti occidentali (California settentrionale) (us-west-1)
+ Stati Uniti occidentali (Oregon) (us-west-2)
+ Asia Pacifico (Mumbai) (ap-south-1)
+ Asia Pacifico (Seoul) (ap-northeast-2)
+ Asia Pacifico (Singapore) (ap-southeast-1)
+ Asia Pacifico (Sydney) (ap-southeast-2)
+ Asia Pacifico (Tokyo) (ap-northeast-1)
+ Canada (Centrale) (ca-central-1)
+ Europa (Francoforte) (eu-central-1)
+ Europa (Irlanda) (eu-west-1)
+ Europa (Londra) (eu-west-2)
+ Europa (Parigi) (eu-west-3)
+ Europa (Stoccolma) (eu-north-1)
+ Sud America (San Paolo) (sa-east-1)
# Prerequisiti di Patch Manager
Assicurati di aver soddisfatto i prerequisiti richiesti prima di utilizzare Patch Manager uno strumento in AWS Systems Manager.
**Topics**
+ [Versione SSM Agent](#agent-versions)
+ [Versione di Python](#python-version)
+ [Requisiti aggiuntivi del pacchetto](#additional-package-requirements)
+ [Connettività all'origine della patch](#source-connectivity)
+ [Accesso agli endpoint S3](#s3-endpoint-access)
+ [Autorizzazioni per installare le patch localmente](#local-installation-permissions)
+ [Sistemi operativi supportati per Patch Manager](#supported-os)
## Versione SSM Agent
La Versione 2.0.834.0 o successiva SSM Agent è in esecuzione sui nodi gestiti che si desidera gestire con Patch Manager.
**Nota**
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.
## Versione di Python
Per macOS la maggior parte dei sistemi operativi Linux (OSs), Patch Manager attualmente supporta le versioni di Python 2.6 - 3.12. I AlmaLinuxDebian Server, e Ubuntu Server OSs richiedono una versione supportata di Python 3 (3.0 - 3.12).
## Requisiti aggiuntivi del pacchetto
Per i sistemi operativi basati su DNF, potrebbero essere necessarie le `zstd` utilità e `unzip` le utilità per decomprimere le informazioni del repository e i file di patch. `xz` I sistemi operativi basati su DNF includono Amazon Linux 2023, Red Hat Enterprise Linux 8 e versioni successive, Oracle Linux 8 e versioni successive e CentOS 8 e versioni successive. Rocky Linux AlmaLinux Se visualizzi un errore simile o un errore di patch dovuto a un errore mancante`unzip`, devi installare queste utilità. `No such file or directory: b'zstd'` `No such file or directory: b'unxz'` `zstd``xz`, e `unzip` può essere installato eseguendo quanto segue:
```
dnf install zstd xz unzip
```
## Connettività all'origine della patch
Se i nodi gestiti non dispongono di una connessione diretta a Internet e si utilizza un Amazon Virtual Private Cloud (Amazon VPC) con un endpoint VPC, è necessario assicurarsi che i nodi abbiano accesso ai repository delle patch di origine (repository). Nei nodi Linux, gli aggiornamenti delle patch vengono solitamente scaricati dai repository remoti configurati nel nodo. Pertanto, il nodo deve essere in grado di connettersi al repository, in modo che possa essere eseguita l'applicazione di patch. Per ulteriori informazioni, consulta [Come vengono selezionate le patch di sicurezza](patch-manager-selecting-patches.md).
Quando applichi una patch a un nodo in esecuzione in un IPv6 unico ambiente, assicurati che il nodo sia connesso alla fonte della patch. È possibile controllare l'Run Commandoutput dell'esecuzione della patch per verificare la presenza di avvisi relativi a repository inaccessibili. Per i sistemi operativi basati su DNF, è possibile configurare i repository non disponibili da ignorare durante l'applicazione delle patch se l'opzione è impostata su under. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` I sistemi operativi basati su DNF includono Amazon Linux 2023, Red Hat Enterprise Linux 8 e versioni successive, Oracle Linux 8 e versioni successive e CentOS 8 e versioni successive. Rocky Linux AlmaLinux Su Amazon Linux 2023, l'`skip_if_unavailable`opzione è impostata come `True` predefinita.
**CentOS Stream: abilita il flag `EnableNonSecurity`**
I nodi CentOS Stream utilizzano DNF come programma di gestione dei pacchetti, che si avvale del principio 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.
**Windows Server: garantisci la connettività al catalogo di Windows Update o a Windows Server Update Services (WSUS)**
I nodi gestiti Windows Server devono essere in grado di connettersi al catalogo di Windows Update o a Windows Server Update Services (WSUS). Verificare che i nodi dispongano della connettività al [Catalogo Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx) tramite un gateway Internet, un gateway NAT o un'istanza NAT. Se si utilizza WSUS, verificare che il nodo disponga della connettività al server WSUS nell'ambiente in uso. Per ulteriori informazioni, consulta [Problema: il nodo gestito non ha accesso a Windows Update Catalog o WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access).
## Accesso agli endpoint S3
Indipendentemente dal fatto che i nodi gestiti operino in una rete privata o pubblica, senza accesso ai bucket Amazon Simple Storage Service (Amazon S3) AWS gestiti richiesti, le operazioni di patching falliscono. Per informazioni sui bucket S3 a cui i nodi gestiti devono essere in grado di accedere, consulta [SSM Agentcomunicazioni con AWS bucket S3 gestiti](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) e [Migliora la sicurezza delle istanze EC2 utilizzando gli endpoint VPC per Systems Manager](setup-create-vpc.md).
## Autorizzazioni per installare le patch localmente
Sui sistemi operativi Linux e Windows Server, Patch Manager utilizza, rispettivamente, l'account amministratore e l'account utente root per installare le patch.
Ad ogni modo, su macOS, per Brew e Brew Cask, Homebrew non supporta i comandi eseguiti con l'account dell'utente root. Di conseguenza, Patch Manager esegue query e i comandi Homebrew come proprietario della directory Homebrew, oppure come utente valido appartenente al gruppo proprietario della directory Homebrew. Pertanto, per installare le patch, il proprietario della directory `homebrew` necessita anche delle autorizzazioni ricorsive del proprietario per la directory `/usr/local`.
**Suggerimento**
Il comando seguente fornisce questa autorizzazione per l'utente specificato:
```
sudo chown -R $USER:admin /usr/local
```
## Sistemi operativi supportati per Patch Manager
Lo strumento Patch Manager non supporta tutte le stesse versioni dei sistemi operativi supportate da altri strumenti di Systems Manager. (Per l'elenco completo dei sistemi operativi supportati da Systems Manager, consulta [Sistemi operativi supportati per Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems)). Pertanto, assicurati che nei nodi gestiti che desideri utilizzare con Patch Manager sia in esecuzione uno dei sistemi operativi indicati nella seguente tabella.
**Nota**
Patch Manager si basa sui repository di patch configurati su un nodo gestito, come Windows Update Catalog e Windows Server Update Services per Windows, in modo da recuperare le patch disponibili da installare. Pertanto, per le versioni del sistema operativo EOL (end of life), nel caso non siano disponibili nuovi aggiornamenti, Patch Manager potrebbe non essere in grado di segnalare i nuovi aggiornamenti. Ciò è dovuto al fatto che non vengono rilasciati nuovi aggiornamenti dal manutentore della distribuzione Linux, Microsoft o Apple, o perché il nodo gestito non dispone della licenza appropriata per accedervi.
Ti consigliamo vivamente di evitare l'uso di versioni del sistema operativo che hanno raggiunto End-of-Life (EOL). I fornitori di sistemi operativi, tra cui AWS in genere, non forniscono patch di sicurezza o altri aggiornamenti per le versioni che hanno raggiunto l'EOL. Continuare a utilizzare un sistema EOL aumenta notevolmente il rischio di non essere in grado di applicare gli aggiornamenti, comprese le correzioni di sicurezza e altri problemi operativi. AWS non verifica la funzionalità di Systems Manager su versioni del sistema operativo che hanno raggiunto la fine del ciclo di vita.
Patch Manager riporta lo stato di conformità rispetto alle patch disponibili sul nodo gestito. Pertanto, quando un'istanza esegue un sistema operativo EOL e non sono disponibili aggiornamenti, Patch Manager potrebbe segnalare il nodo come conforme, a seconda delle baseline delle patch configurate per la relativa operazione di applicazione.
| Sistema operativo | Informazioni |
| --- | --- |
| Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-prerequisites.html) |
| macOS | *macOS è supportato solo per le istanze Amazon EC2.* 13.0-13.5 (Ventura) 14*.x* (Sonoma) 15*.x* (Sequoia) Aggiornamenti al sistema operativo macOS Patch Manager non supporta gli aggiornamenti del sistema operativo (OS) o quelli per macOS, ad esempio dalle versioni 13.1 a 13.2. Per eseguire gli aggiornamenti della versione del sistema operativo su macOS, consigliamo di utilizzare i meccanismi di aggiornamento del sistema operativo integrati di Apple. Per ulteriori informazioni, consulta [Gestione del dispositivo](https://developer.apple.com/documentation/devicemanagement) sul sito Web della documentazione Apple Developer. Supporto Homebrew Patch Manager richiede l'installazione di Homebrew, il sistema di gestione dei pacchetti software open source, in una delle seguenti posizioni di installazione predefinite: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-prerequisites.html) Le operazioni di patching che utilizzano Patch Manager non funzionano correttamente quando Homebrew non è installato. Supporto delle Regioni macOSnon è supportato in tutto. Regioni AWS Per ulteriori informazioni sul supporto di Amazon EC2 per macOS, consulta [Istanze Amazon EC2 Mac](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) nella *Guida per l'utente di Amazon EC2*. Dispositivi edge macOS SSM Agentfor AWS IoT Greengrass core devices non è supportato sumacOS. Non è possibile utilizzare Patch Manager per applicare patch macOS Dispositivi Edge. |
| Windows | Da Windows Server 2012 a Windows Server 2025, incluse le versioni R2. SSM Agentper i dispositivi AWS IoT Greengrass principali non è supportato in Windows 10. Non è possibile utilizzare Patch Manager per applicare patch ai dispositivi edge Windows 10. Supporto Windows Server 2012 e 2012 R2 Windows Server 2012 e 2012 R2 hanno raggiunto la fine del supporto il 10 ottobre 2023. Per l'utilizzo Patch Manager con queste versioni, si consiglia di utilizzare anche Extended Security Updates (ESUs) di Microsoft. Per ulteriori informazioni, consulta [Raggiungimento della fine del supporto di Windows Server 2012 e 2012 R2](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support) sul sito Web di Microsoft. |
# Come Patch Manager funzionano le operazioni
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
**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
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)
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
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
**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
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
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
**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
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
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
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
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
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
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
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
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
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 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
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
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
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.
# Documenti sul comando SSM per l'applicazione di patch a nodi gestiti
Questo argomento descrive gli otto documenti di Systems Manager (documenti SSM) attualmente disponibili, utili per assicurarti che i nodi gestiti vengano applicati patch mediante gli aggiornamenti più recenti correlati alla sicurezza.
Consigliamo di utilizzare solo cinque di questi documenti per le applicazione di patch. Questi cinque documenti SSM offrono una gamma completa di opzioni di applicazione di patch utilizzando AWS Systems Manager. Quattro di questi documenti sono stati rilasciati successivamente ai quattro documenti SSM legacy che sostituiscono e rappresentano espansioni o consolidamenti di funzionalità.
**Documenti SSM consigliati per l'applicazione di patch**
Consigliamo di utilizzare i cinque documenti SSM seguenti per le operazioni di applicazione di patch.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**Documenti SSM legacy per l'applicazione di patch**
I seguenti quattro documenti SSM legacy rimangono disponibili in alcune Regioni AWS ma non sono più aggiornati o supportati. Non è garantito che questi documenti funzionino solo in IPv6 ambienti e supporto. IPv4 Non è possibile garantire che funzionino in tutti gli scenari e potrebbero perdere supporto in futuro. Si consiglia di non utilizzare questi documenti per le operazioni di applicazione di patch.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Per i passaggi per configurare le operazioni di patching in un ambiente che supporta solo la tecnologia, IPv6 consulta. [Tutorial: applicazione di patch a un server in un IPv6 unico ambiente](patch-manager-server-patching-iPv6-tutorial.md)
Per ulteriori informazioni sull'uso di questi documenti SSM nelle operazioni di applicazione di patch, consulta le seguenti sezioni.
**Topics**
+ [Documenti SSM consigliati per i nodi gestiti di applicazione di patch](#patch-manager-ssm-documents-recommended)
+ [Documenti SSM legacy per l'applicazione di patch a nodi gestiti](#patch-manager-ssm-documents-legacy)
+ [Limitazioni note dei documenti SSM per l'applicazione di patch ai nodi gestiti](#patch-manager-ssm-documents-known-limitations)
+ [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Scenario di esempio per l'utilizzo del InstallOverrideList parametro in `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Utilizzo del BaselineOverride parametro](patch-manager-baselineoverride-parameter.md)
## Documenti SSM consigliati per i nodi gestiti di applicazione di patch
I seguenti cinque documenti SSM sono consigliati per l'uso nelle operazioni di applicazioni di patch nei nodi gestiti.
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
Supporta la configurazione di funzioni Windows Update di base e il relativo utilizzo per l'installazione automatica degli aggiornamenti (o per disabilitare gli aggiornamenti automatici). Disponibile in tutte le Regioni AWS.
Questo documento SSM richiede a Windows Update di scaricare e installare gli aggiornamenti specificati e di riavviare i nodi gestiti in base alle esigenze. Utilizzate questo documento conState Manager, uno strumento incluso AWS Systems Manager, per assicurarvi che Windows Update mantenga la sua configurazione. È inoltre possibile eseguirlo manualmente utilizzandoRun Command, uno strumento in AWS Systems Manager, per modificare la configurazione di Windows Update.
I parametri disponibili in questo documento ti consentono di specificare una categoria di aggiornamenti da installare (o se disabilitare gli aggiornamenti automatici), nonché di specificare l'ora e il giorno della settimana dell'esecuzione delle operazioni di applicazione di patch. Questo documento SSM è utile in particolare se non devi controllare rigidamente gli aggiornamenti Windows e se non devi raccogliere le informazioni sulla conformità.
**Sostituisce i seguenti documenti SSM legacy: **
+ *Nessuno*
### `AWS-InstallWindowsUpdates`
Installa gli aggiornamenti su un nodo gestito Windows Server. Disponibile in tutte le Regioni AWS.
Questo documento SSM offre le funzionalità delle basi di patch nel caso desiderassi installare un aggiornamento specifico (utilizzando il parametro `Include Kbs`) o installare le patch con specifiche classificazioni o categorie, senza necessità di avere le informazioni sulla conformità delle patch.
**Sostituisce i seguenti documenti SSM legacy:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
I tre documenti legacy svolgono diverse funzioni, ma è possibile ottenere gli stessi risultati utilizzando altre impostazioni dei parametri con il più recente documento SSM `AWS-InstallWindowsUpdates`. Tali impostazioni dei parametri sono descritte in [Documenti SSM legacy per l'applicazione di patch a nodi gestiti](#patch-manager-ssm-documents-legacy).
### `AWS-RunPatchBaseline`
Consente di installare patch nei nodi gestiti o analizza i nodi per stabilire se eventuali patch qualificate risultano mancanti. Disponibile in tutte le Regioni AWS.
`AWS-RunPatchBaseline` consente di controllare le approvazioni delle patch utilizzando la baseline delle patch specificata come «predefinita» per un tipo di sistema operativo. Fornisce le informazioni sulla conformità delle patch visualizzabili con gli strumenti di conformità di Systems Manager. Questi strumenti offrono approfondimenti sullo stato di conformità delle patch dei nodi gestiti, ad esempio a quali nodi mancano le patch e quali sono tali patch. Quando si utilizza `AWS-RunPatchBaseline`, le informazioni sulla conformità delle patch vengono registrate utilizzando il comando API`PutInventory`. Per i sistemi operativi Linux, le informazioni sulla conformità vengono fornite per le patch dal repository di fonte di default configurato in un nodo gestito e da qualsiasi repository di origine alternativo specificato in una baseline delle patch personalizzata. Per ulteriori informazioni sui repository di origine alternativi, consulta [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md). Per ulteriori informazioni sugli strumenti di conformità di Systems Manager, consulta [ConformitàAWS Systems Manager](systems-manager-compliance.md).
**Sostituisce i seguenti documenti legacy:**
+ `AWS-ApplyPatchBaseline`
Il documento legacy `AWS-ApplyPatchBaseline` è valido solo per i nodi gestiti Windows Server e non fornisce supporto per l'applicazione di patch alle applicazioni. Il più recente `AWS-RunPatchBaseline` offre lo stesso supporto per i sistemi Windows e Linux. Una versione 2.0.834.0 o successiva di SSM Agent è richiesta per poter utilizzare il documento `AWS-RunPatchBaseline`.
Per ulteriori informazioni sull'utilizzo del documento SSM `AWS-RunPatchBaseline`, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
### `AWS-RunPatchBaselineAssociation`
Consente di installare patch nelle istanze o analizza le istanze per stabilire se eventuali patch qualificate risultano mancanti. Disponibile in tutte le Regioni AWS commerciali.
`AWS-RunPatchBaselineAssociation` differisce da `AWS-RunPatchBaseline` in alcuni modi importanti:
+ `AWS-RunPatchBaselineAssociation` è destinato all'uso principalmente con associazioni State Manager create utilizzando Quick Setup, uno strumento di AWS Systems Manager. In particolare, quando utilizzi il tipo di configurazione di gestione host Quick Setup, scegliendo l'opzione **Scan instances for missing patches daily** (Scansiona le istanze per le patch mancanti ogni giorno), il sistema utilizza `AWS-RunPatchBaselineAssociation` per l'operazione.
Nella maggior parte dei casi, tuttavia, quando si impostano le proprie operazioni di patch, è necessario scegliere [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) o [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) invece di `AWS-RunPatchBaselineAssociation`.
Per ulteriori informazioni, consulta i seguenti argomenti:
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` supporta l'utilizzo di tag per identificare la baseline delle patch da utilizzare con un insieme di destinazioni durante l'esecuzione.
+ Per le operazioni di applicazione di patch che utilizzano `AWS-RunPatchBaselineAssociation`, i dati di conformità delle patch vengono compilati in termini di un'associazione State Manager specifica. I dati di conformità delle patch raccolti quando `AWS-RunPatchBaselineAssociation` viene registrato utilizzando il comando `PutComplianceItems` al posto del comando `PutInventory`. Ciò impedisce che i dati di conformità non associati a questa particolare associazione vengano sovrascritti.
Per i sistemi operativi Linux, le informazioni sulla conformità vengono fornite per le patch dal repository di origine predefinito configurato in un'istanza e da qualsiasi repository di origine alternativo specificato in una baseline delle patch personalizzata. Per ulteriori informazioni sui repository di origine alternativi, consulta [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md). Per ulteriori informazioni sugli strumenti di conformità di Systems Manager, consulta [ConformitàAWS Systems Manager](systems-manager-compliance.md).
**Sostituisce i seguenti documenti legacy:**
+ **Nessuno**
Per ulteriori informazioni sull'utilizzo del documento SSM `AWS-RunPatchBaselineAssociation`, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).
### `AWS-RunPatchBaselineWithHooks`
Consente di installare patch nei nodi gestiti o li analizza per determinare se eventuali patch qualificate risultano mancanti, con hook opzionali che è possibile utilizzare per eseguire i documenti SSM in tre punti durante il ciclo di applicazione di patch. Disponibile in tutte le Regioni AWS commerciali. Non supportato su macOS.
`AWS-RunPatchBaselineWithHooks` differisce da `AWS-RunPatchBaseline` nella sua operazione `Install`.
`AWS-RunPatchBaselineWithHooks` supporta gli hook del ciclo di vita che vengono eseguiti in punti designati durante l'applicazione di patch del nodo gestito. Poiché le installazioni di patch a volte richiedono il riavvio dei nodi gestiti, l'operazione di applicazione di patch è suddivisa in due eventi, per un totale di tre hook che supportano funzionalità personalizzate. Il primo hook è prima dell'operazione `Install with NoReboot`. Il secondo hook è dopo dell'operazione `Install with NoReboot`. Il terzo hook è disponibile dopo il riavvio del nodo.
**Sostituisce i seguenti documenti legacy:**
+ **Nessuno**
Per ulteriori informazioni sull'utilizzo del documento SSM `AWS-RunPatchBaselineWithHooks`, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
## Documenti SSM legacy per l'applicazione di patch a nodi gestiti
I seguenti quattro documenti SSM sono ancora disponibili in alcune Regioni AWS. Tuttavia, non sono più aggiornati e potrebbero non essere più supportati in futuro, pertanto ne sconsigliamo l'utilizzo. In sostituzione, usa i documenti descritti in [Documenti SSM consigliati per i nodi gestiti di applicazione di patch](#patch-manager-ssm-documents-recommended).
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
Supporta solo lei nodi gestiti Windows Server, ma non include il supporto per l'applicazione di patch alle applicazioni disponibili nel rispettivo documento sostitutivo `AWS-RunPatchBaseline`. Non disponibile nelle versioni Regioni AWS lanciate dopo agosto 2017.
**Nota**
La sostituzione per questo documento SSM, `AWS-RunPatchBaseline`, richiede la versione 2.0.834.0 o una versione successiva di SSM Agent. È possibile utilizzare il documento `AWS-UpdateSSMAgent` per aggiornare i nodi gestiti alla versione più recente dell'agente.
### `AWS-FindWindowsUpdates`
Sostituito da `AWS-InstallWindowsUpdates`, che è in grado di eseguire le stesse operazioni. Non disponibile nella versione Regioni AWS lanciata dopo aprile 2017.
Per ottenere lo stesso risultato del documento SSM legacy, utilizza la seguente configurazione dei parametri con il documento sostitutivo consigliato, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
Sostituito da `AWS-InstallWindowsUpdates`, che è in grado di eseguire le stesse operazioni. Non disponibile nelle versioni Regioni AWS lanciate dopo aprile 2017.
Per ottenere lo stesso risultato del documento SSM legacy, utilizza la seguente configurazione dei parametri con il documento sostitutivo consigliato, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
Sostituito da `AWS-InstallWindowsUpdates`, che è in grado di eseguire le stesse operazioni. Non disponibile nelle versioni Regioni AWS lanciate dopo aprile 2017.
Per ottenere lo stesso risultato del documento SSM legacy, utilizza la seguente configurazione dei parametri con il documento sostitutivo consigliato, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *comma-separated list of KB articles*
## Limitazioni note dei documenti SSM per l'applicazione di patch ai nodi gestiti
### Interruzioni esterne del riavvio
Se il sistema sul nodo avvia un riavvio durante l'installazione della patch (ad esempio, per applicare aggiornamenti al firmware o funzionalità simili SecureBoot), l'esecuzione del documento di applicazione delle patch potrebbe essere interrotta e contrassegnata come fallita anche se le patch sono state installate correttamente. Ciò si verifica perché l'agente SSM non può persistere e riprendere lo stato di esecuzione del documento dopo riavvii esterni.
Per verificare lo stato di installazione delle patch dopo un'esecuzione non riuscita, esegui un'operazione di `Scan` patch, quindi controlla i dati di conformità delle patch in Patch Manager per valutare lo stato di conformità corrente.
# Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`
AWS Systems Manager supporta`AWS-RunPatchBaseline`, un documento Systems Manager (documento SSM) perPatch Manager, uno strumento in AWS Systems Manager. Questo documento SSM esegue operazioni di applicazione di patch nei nodi gestiti per aggiornamenti correlati alla sicurezza e di altro tipo. Quando il documento viene eseguito, utilizza la baseline delle patch specificata come “predefinita” per un tipo di sistema operativo se non è specificato alcun gruppo di patch. In caso contrario, utilizza la baseline delle patch associata al gruppo di patch. Per informazioni sui gruppi di patch, consulta [Gruppi di patch](patch-manager-patch-groups.md).
È possibile utilizzare il documento `AWS-RunPatchBaseline` per applicare patch ai sistemi operativi e alle applicazioni. (In Windows Server, il supporto delle applicazioni è limitato ai soli aggiornamenti delle applicazioni Microsoft).
Questo documento supporta Linux, macOS, e nodi gestiti Windows Server. Il documento eseguirà le operazioni adeguate per ciascuna piattaforma.
**Nota**
Patch Manager supporta anche il documento SSM legacy `AWS-ApplyPatchBaseline`. Tuttavia, questo documento supporta l'applicazione di patch solo nei nodi gestiti Windows. Ti consigliamo di usare `AWS-RunPatchBaseline` perché supporta l'applicazione di patch nei nodi gestiti Linux macOS, e Windows Server. Una versione 2.0.834.0 o successiva di SSM Agent è richiesta per utilizzare il documento `AWS-RunPatchBaseline`.
------
#### [ Windows Server ]
Nei nodi Windows Server gestiti, il `AWS-RunPatchBaseline` documento scarica e richiama un PowerShell modulo, che a sua volta scarica un'istantanea della linea di base della patch che si applica al nodo gestito. Questa snapshot della baseline delle patch contiene un elenco di patch approvate compilate eseguendo una query sulla baseline delle patch su un server Windows Server Update Services (WSUS). Questo elenco viene trasferito all'API di Windows Update, che controlla il download e l'installazione delle patch approvate, in base alle necessità.
------
#### [ Linux ]
Nei nodi gestiti Linux, il documento `AWS-RunPatchBaseline` consente di richiamare un modulo Python, che a sua volta scarica una snapshot della baseline delle patch valida per il nodo gestito. Questa snapshot della baseline delle patch utilizza le regole e gli elenchi specificati delle patch approvate e bloccate per controllare il programma di gestione dei pacchetti adeguato per ciascun tipo di nodo:
+ I nodi gestiti da Amazon Linux 2, Oracle Linux e RHEL 7 utilizzano YUM. Per le operazioni con YUM, Patch Manager richiede `Python 2.6` o una versione supportata successiva (da 2.6 a 3.12). Amazon Linux 2023 utilizza DNF. Per le operazioni DNF, Patch Manager richiede una versione supportata di `Python 2` o `Python 3` (da 2.6 a 3.12).
+ I nodi gestiti 8 RHEL utilizzano DNF. Per le operazioni DNF, Patch Manager richiede una versione supportata di `Python 2` o `Python 3` (da 2.6 a 3.12). (Nessuna versione è installata per impostazione predefinita su RHEL 8. È necessario installare l'una o l'altra manualmente).
+ Le istanze Debian Server e Ubuntu Server utilizzano APT. Per le operazioni APT, Patch Manager richiede una versione supportata di `Python 3` (da 3.0 a 3.12).
------
#### [ macOS ]
Nei nodi gestiti macOS, il documento `AWS-RunPatchBaseline` consente di scaricare e richiamare un modulo Python, che a sua volta scarica una snapshot della baseline delle patch valida per il nodo. Successivamente, un sottoprocesso Python richiama il AWS Command Line Interface (AWS CLI) sul nodo per recuperare le informazioni di installazione e aggiornamento per i gestori di pacchetti specificati e per guidare il gestore di pacchetti appropriato per ogni pacchetto di aggiornamento.
------
Ogni istantanea è specifica per un gruppo di patch Account AWS, un sistema operativo e un ID di istantanea. Lo snapshot viene consegnato tramite un URL Amazon Simple Storage Service (Amazon S3) prefirmato, che scade 24 ore dopo la creazione dello snapshot. Dopo la scadenza dell'URL, tuttavia, se desideri applicare lo stesso contenuto snapshot ad altri nodi gestiti, è possibile generare un nuovo URL Amazon S3 prefirmato fino a 3 giorni dopo la creazione della copia istantanea. Per farlo, utilizzare il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Dopo avere installato tutti gli aggiornamenti approvati e applicabili e dopo avere eseguito il riavvio, le informazioni sulla conformità delle patch vengono generate in un nodo gestito e trasferite a Patch Manager.
**Nota**
Se il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaseline`, il nodo gestito non viene riavviata dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
Per informazioni sulla visualizzazione dei dati di conformità delle patch, consulta [Informazioni sulla conformità delle patch](compliance-about.md#compliance-monitor-patch).
## Parametri `AWS-RunPatchBaseline`
`AWS-RunPatchBaseline` supporta sei parametri. Il parametro `Operation` è obbligatorio. I parametri `InstallOverrideList`, `BaselineOverride` e `RebootOption` sono facoltativi. `Snapshot-ID` è tecnicamente facoltativo, ma consigliamo di specificare un valore personalizzato quando si esegue `AWS-RunPatchBaseline` esternamente alla finestra di manutenzione. Patch Manager fornisce il valore automaticamente quando il documento viene eseguito come parte di un'operazione della finestra di manutenzione.
**Topics**
+ [Nome parametro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nome parametro: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Nome parametro: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Nome parametro: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Nome parametro: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Nome parametro: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### Nome parametro: `Operation`
**Utilizzo**: obbligatorio.
**Opzioni**: `Scan` \$1 `Install`.
Scan
Quando si sceglie l'opzione `Scan`, `AWS-RunPatchBaseline` determina lo stato di conformità delle patch del nodo gestito e riferisce queste informazioni a Patch Manager. `Scan` non richiede l'installazione degli aggiornamenti o il riavvio dei nodi gestiti. L'operazione identifica dove gli aggiornamenti approvati e applicabili al nodo risultano mancanti.
Installa
Quando si sceglie l'opzione `Install`, `AWS-RunPatchBaseline` tenta di installare gli aggiornamenti applicabili e approvati che risultano mancanti nel nodo gestito. Le informazioni sulla conformità delle patch generate in un'operazione `Install` non visualizzano gli aggiornamenti mancanti, ma sono in grado di specificare lo stato di errore degli aggiornamenti se per qualsiasi motivo l'installazione non è andata a buon fine. Quando un aggiornamento è installato in un nodo gestito, questo viene riavviato per assicurare l'aggiornamento sia installato e attivo. (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-parameters-norebootoption).)
Se una patch specificata dalle regole di baseline viene installata *prima* che Patch Manager aggiorni il nodo gestito, è possibile che il sistema non venga riavviato come previsto. Ciò si verifica quando una patch viene installata manualmente da un utente o installata automaticamente da un altro programma, ad esempio il pacchetto `unattended-upgrades` su Ubuntu Server.
### Nome parametro: `AssociationId`
**Utilizzo**: facoltativo.
`AssociationId` è l'ID di un'associazione esistente in State Manager, uno strumento di AWS Systems Manager. È utilizzato da Patch Manager per aggiungere i dati di conformità a un'associazione specificata. Tale associazione è correlata a un'operazione di applicazione di patch [configurata in una policy di patch in Quick Setup](quick-setup-patch-manager.md).
**Nota**
Con `AWS-RunPatchBaseline`, se viene fornito un valore `AssociationId` insieme a una sostituzione della baseline della policy di patch, l'applicazione di patch viene eseguita come un'operazione `PatchPolicy` e il valore `ExecutionType` riportato in `AWS:ComplianceItem` è anche `PatchPolicy`. Se non viene fornito alcun valore `AssociationId`, l'applicazione di patch viene eseguita come un'operazione `Command` e anche il valore `ExecutionType` riportato nel parametro `AWS:ComplianceItem` inviato è `Command`.
Se non disponi già di un'associazione da utilizzare, è possibile crearla eseguendo il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html).
### Nome parametro: `Snapshot ID`
**Utilizzo**: facoltativo.
`Snapshot ID` è un ID univoco (GUID) utilizzato da Patch Manager per assicurare che una serie di nodi gestiti a cui vengono applicate le patch in un'unica operazione abbiano la stessa serie di patch approvate. Anche se il parametro è definito come facoltativo, la best practice dipende dal fatto che `AWS-RunPatchBaseline` sia o meno in esecuzione in una finestra di manutenzione, come descritto nella seguente tabella.
**Best practice di `AWS-RunPatchBaseline`**
| Modalità | Best practice | Informazioni |
| --- | --- | --- |
| In esecuzione AWS-RunPatchBaseline all'interno di una finestra di manutenzione | Non fornire un ID della snapshot. Patch Manager la fornirà automaticamente. | Quando utilizzi una finestra di manutenzione per eseguire `AWS-RunPatchBaseline`, non devi fornire l'ID della snapshot generata. In questo scenario, Systems Manager fornisce un valore GUID in base all'ID di esecuzione della finestra di manutenzione. In questo modo, si garantisce che venga utilizzato un ID corretto per tutte le invocazioni di `AWS-RunPatchBaseline` in tale finestra di manutenzione. Si noti che se si specifica un valore in questo scenario, la snapshot della baseline delle patch potrebbe non durare per più di 3 giorni. In seguito, verrà generata una nuova snapshot anche se hai specificato lo stesso ID dopo la scadenza della snapshot. |
| In esecuzione AWS-RunPatchBaseline al di fuori di una finestra di manutenzione | Generare e specificare un valore GUID personalizzato per l'ID della snapshot. | Se non utilizzi una finestra di manutenzione per eseguire `AWS-RunPatchBaseline`, ti consigliamo di generare e specificare un ID snapshot univoco per ogni baseline delle patch, soprattutto se stai eseguendo il documento `AWS-RunPatchBaseline` su più nodi gestiti nella stessa operazione. Se specifichi un ID in questo scenario, Systems Manager genera un altro ID snapshot per ciascun nodo gestito a cui viene inviato il comando. Di conseguenza, potrebbero venire specificate varie serie di patch fra i nodi gestiti. Ad esempio, potresti eseguire il documento `AWS-RunPatchBaseline` direttamente tramite Run Command, uno strumento di AWS Systems Manager e destinarlo a un gruppo di 50 nodi gestiti. Specificando un ID snapshot personalizzato verrà creata una singola snapshot di baseline utilizzata per valutare le patch e tutti i nodi, per garantire che il relativo stato finale sia coerente. |
| ¹ È possibile utilizzare qualsiasi strumento in grado di generare un GUID per ottenere il valore del parametro ID snapshot. Ad esempio, in PowerShell, è possibile utilizzare il `New-Guid` cmdlet per generare un GUID nel formato di. `12345699-9405-4f69-bc5e-9315aEXAMPLE` |
### Nome parametro: `InstallOverrideList`
**Utilizzo**: facoltativo.
`InstallOverrideList` consente di specificare un URL https o un URL in stile percorso Amazon S3 per un elenco delle patch da installare. Questo elenco di installazione delle patch, gestito in formato YAML, sostituisce le patch specificate dalla baseline delle patch predefinita corrente. Ciò consente di avere un controllo più granulare su quali patch vengono installate nei nodi gestiti.
**Importante**
Il nome del file `InstallOverrideList` non consente la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1).
Il comportamento dell'applicazione di patch quando si utilizza il parametro `InstallOverrideList`, differisce tra nodi gestiti da Linux e macOS o da Windows Server. Su Linux e macOS, Patch Manager tenta di applicare le patch incluse nell'elenco `InstallOverrideList` delle patch presenti in qualsiasi repository abilitato sul nodo, indipendentemente dal fatto che corrispondano o meno alle regole della baseline delle patch. Sui nodi di Windows Server, tuttavia, le patch nell'elenco `InstallOverrideList` vengono applicate *solo* quando corrispondono anche alle regole della baseline delle patch.
I report di conformità rispecchiano gli stati delle patch in base a quanto specificato nella baseline delle patch, non ciò che hai specificato in un elenco `InstallOverrideList` di patch. In altre parole, le operazioni di scansione ignorano il parametro `InstallOverrideList`. In questo modo si garantisce che i report di conformità rispecchino in modo omogeneo gli stati delle patch in base alla policy anziché in base a quanto era stato approvato per una specifica operazione di applicazione di patch.
**Nota**
Quando esegui la patch di un nodo che utilizza solo un nodo IPv6, assicurati che l'URL fornito sia raggiungibile dal nodo. Se l'opzione di SSM Agent configurazione `UseDualStackEndpoint` è impostata su`true`, viene utilizzato un client S3 dualstack quando viene fornito un URL S3. [Tutorial: applicazione di patch a un server in un IPv6 unico ambiente](patch-manager-server-patching-iPv6-tutorial.md)Per ulteriori informazioni sulla configurazione dell'agente per l'utilizzo del dualstack, consulta.
Per una descrizione di come è possibile utilizzare il parametro `InstallOverrideList` per applicare diversi tipi di patch a un gruppo di destinazione in diverse pianificazioni delle finestre di manutenzione, pur utilizzando una singola baseline delle patch, consulta [Scenario di esempio per l'utilizzo del InstallOverrideList parametro in `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).
**Formati URL validi**
**Nota**
Se il file è archiviato in un bucket pubblicamente disponibile, è possibile inoltre specificare un formato URL https o un URL in stile percorso Amazon S3. Se il file è archiviato in un bucket privato, è necessario specificare un URL in stile percorso Amazon S3.
+ **formato URL https**:
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **URL in stile percorso Amazon S3**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formati dei contenuti YAML validi**
I formati utilizzati per specificare le patch nell'elenco variano in base al sistema operativo del tuo nodo gestito. Il formato generale, tuttavia, è quello riportato di seguito:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Benché sia possibile specificare altri campi nel file YAML, questi verranno ignorati durante le operazioni delle patch.
Inoltre, è consigliabile verificare che il formato del file YAML sia valido prima di aggiungere o aggiornare l'elenco nel bucket S3. Per ulteriori informazioni sul formato YAML, consulta [yaml.org](http://www.yaml.org). Per le opzioni degli strumento di convalida, effettua la ricerca sul Web di “convalida formato yaml”.
------
#### [ Linux ]
**id**
Il campo **id** è obbligatorio. Utilizzalo per specificare le patch con l'architettura e il nome del pacchetto. Ad esempio: `'dhclient.x86_64'`. Negli id, è possibile utilizzare i caratteri jolly per indicare più pacchetti. Ad esempio: `'dhcp*'` ed `'dhcp*1.*'`.
**Titolo**
Il campo **titolo** è facoltativo, ma nei sistemi Linux offre funzionalità di filtraggio aggiuntive. Quando utilizzi **titolo**, è necessario che il campo includa le informazioni sulla versione del pacchetto in uno dei seguenti formati:
YUM/SUSE Linux Enterprise Server (SLES):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Per i titoli delle patch di Linux, è possibile utilizzare uno o più caratteri jolly in qualsiasi posizione per ampliare il numero di corrispondenze dei pacchetti. Ad esempio: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Ad esempio:
+ Il pacchetto apt versione 1.2.25 è correntemente installato nel nodo gestito, ma ora è disponibile la versione 1.2.27.
+ È possibile aggiungere apt.amd64 versione 1.2.27 all'elenco delle patch. Dipende da apt-utils.amd64 versione 1.2.27, ma apt-utils.amd64 versione 1.2.25 viene specificato nell'elenco.
In questo caso, la versione 1.2.27 di apt verrà bloccata dall'installazione e riportata come «Failed-». NonCompliant
------
#### [ Windows Server ]
**id**
Il campo **id** è obbligatorio. Utilizzatelo per specificare le patch utilizzando Microsoft Knowledge Base IDs (ad esempio KB2736693) e Microsoft Security Bulletin IDs (ad esempio, MS17 -023).
Tutti gli altri campi che intendi fornire in un elenco di patch per Windows sono facoltativi e hanno unicamente scopo informativo. È possibile utilizzare altri campi, come **title**, **classification**, **severity** o qualsiasi altro per fornire informazioni più dettagliate sulle patch specificate.
------
#### [ macOS ]
**id**
Il campo **id** è obbligatorio. Il valore per il campo **id** viene fornito utilizzando un formato `{package-name}.{package-version}` o un formato \$1package\$1name\$1.
------
**Elenchi di patch di esempio**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nome parametro: `RebootOption`
**Utilizzo**: facoltativo.
**Opzioni**: `RebootIfNeeded` \$1 `NoReboot`
**Default**: `RebootIfNeeded`
**avvertimento**
L'opzione predefinita è `RebootIfNeeded`. Assicurarsi di selezionare l'opzione corretta per il caso d'uso. Ad esempio, quando è necessario che i nodi gestiti vengano riavviati immediatamente per completare un processo di configurazione, scegli `RebootIfNeeded`. Oppure, quando è necessario mantenere la disponibilità dei nodi gestiti fino a un orario di riavvio pianificato, scegli `NoReboot`.
**Importante**
Non è consigliabile utilizzarlo Patch Manager per applicare patch a istanze di cluster in Amazon EMR (precedentemente chiamato Amazon Elastic). MapReduce In particolare, non selezionare l'opzione `RebootIfNeeded` per il parametro `RebootOption`. (Questa opzione è disponibile nei documenti del comando SSM per l'applicazione di patch `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`).
I comandi sottostanti per applicare le patch tramite Patch Manager utilizzano i comandi `yum` e `dnf`. Pertanto, le operazioni generano incompatibilità a causa del modo in cui i pacchetti vengono installati. Per informazioni sui metodi preferiti per l'aggiornamento del software sui cluster Amazon EMR, consulta [Utilizzo dell’AMI predefinita per Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) nella *Guida per la gestione di Amazon EMR*.
RebootIfNeeded
Quando si sceglie l'opzione `RebootIfNeeded`, il nodo gestito viene riavviato in uno dei seguenti casi:
+ Patch Manager installato uno o più patch.
Patch Manager non valuta se un riavvio è *obbligatorio* per la patch. Il sistema viene riavviato anche se la patch non richiede il riavvio.
+ Patch Manager rileva una o più patch con lo stato di `INSTALLED_PENDING_REBOOT` durante l'operazione `Install`.
Lo stato `INSTALLED_PENDING_REBOOT` indica che l'opzione `NoReboot` è stata selezionata l'ultima volta che l'operazione `Install` è stata eseguita, o che una patch è stata installata all'esterno di Patch Manager dall'ultimo riavvio del nodo gestito.
Il riavvio dei nodi gestiti in questi due casi garantisce che i pacchetti aggiornati vengano svuotati dalla memoria e mantengano coerenti il comportamento di patch e di riavvio in tutti i sistemi operativi.
NoReboot
Quando scegli l'opzione `NoReboot`, Patch Manager non riavvia il nodo gestito anche se ha installato patch durante l'operazione di `Install` Questa opzione è utile se i nodi gestiti non richiedono il riavvio dopo l'applicazione di patch, oppure nel caso di applicazioni o processi in esecuzione su un nodo che non dovrebbero essere interrotti da un riavvio a seguito di un'operazione di applicazione di patch. È utile anche quando si necessita di un maggiore controllo sui tempi dei riavvii del nodo gestito, ad esempio utilizzando una finestra di manutenzione.
Quando si sceglie l'opzione `NoReboot` e viene installata una patch, alla patch viene assegnato lo stato `InstalledPendingReboot`. Il nodo gestito stesso, tuttavia, viene contrassegnato come `Non-Compliant`. Dopo che si verifica un riavvio e viene eseguita un'operazione `Scan`, lo stato del nodo gestito diventa `Compliant`.
L'opzione `NoReboot` impedisce solo i riavvii a livello di sistema operativo. I riavvii a livello di servizio possono comunque avvenire come parte del processo di applicazione di patch. Ad esempio, quando Docker viene aggiornato, i servizi dipendenti come Amazon Elastic Container Service potrebbero riavviarsi automaticamente, anche con `NoReboot` abilitato. Se disponi di servizi critici, che non devono essere interrotti, prendi in considerazione misure aggiuntive come la rimozione temporanea delle istanze dal servizio o la pianificazione dell'applicazione di patch durante le finestre di manutenzione.
**File di monitoraggio dell'installazione delle patch**: per tenere traccia dell'installazione delle patch, in particolare delle patch installate dopo l'ultimo riavvio del sistema, Systems Manager mantiene un file nel nodo gestito.
**Importante**
Non eliminare o modificare il file di monitoraggio. Se questo file viene eliminato o danneggiato, il rapporto di conformità della patch per il nodo gestito non è accurato. In questo caso, riavvia il nodo ed esegui un'operazione di scansione della patch per ripristinare il file.
Questo file di monitoraggio viene archiviato nei seguenti percorsi nei nodi gestiti:
+ Sistemi operativi Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server sistema operativo:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nome parametro: `BaselineOverride`
**Utilizzo**: facoltativo.
È possibile definire le preferenze per l'applicazione di patch in runtime (tempo di esecuzione) utilizzando il parametro `BaselineOverride`. Questa sostituzione della baseline viene mantenuta come oggetto JSON in un bucket S3. Garantisce che le operazioni di applicazione di patch utilizzino le baseline fornite che corrispondono al sistema operativo host anziché applicare le norme dalla baseline delle patch predefinita
**Importante**
Il nome del file `BaselineOverride` non consente la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1).
Per ulteriori informazioni su come utilizzare il parametro `BaselineOverride`, consulta [Utilizzo del BaselineOverride parametro](patch-manager-baselineoverride-parameter.md).
### Nome parametro: `StepTimeoutSeconds`
**Utilizzo**: obbligatorio.
Il tempo in secondi, compreso tra 1 e 36.000 secondi (10 ore), entro cui un comando deve essere eseguito, prima che venga considerato non riuscito.
# Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`
Come il documento `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` esegue operazioni di applicazione di patch sulle istanze per aggiornamenti correlati alla sicurezza e di altro tipo. È possibile utilizzare il documento `AWS-RunPatchBaselineAssociation` per applicare patch ai sistemi operativi e alle applicazioni. (In Windows Server, il supporto delle applicazioni è limitato ai soli aggiornamenti delle applicazioni Microsoft).
Questo documento supporta le istanze Amazon Elastic Compute Cloud (Amazon EC2) per Linux, macOS, e Windows Server. Non supporta nodi non EC2 in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). Il documento eseguirà le azioni appropriate per ogni piattaforma, richiamando un modulo Python su Linux macOS e istanze e PowerShell un modulo su istanze Windows.
`AWS-RunPatchBaselineAssociation`, tuttavia, differisce da `AWS-RunPatchBaseline` nei seguenti modi:
+ `AWS-RunPatchBaselineAssociation` è destinato all'uso principalmente con associazioni State Manager create utilizzando [Quick Setup](systems-manager-quick-setup.md), uno strumento di AWS Systems Manager. In particolare, quando utilizzi il tipo di configurazione di gestione host Quick Setup, scegliendo l'opzione **Scan instances for missing patches daily** (Scansiona le istanze per le patch mancanti ogni giorno), il sistema utilizza `AWS-RunPatchBaselineAssociation` per l'operazione.
Nella maggior parte dei casi, tuttavia, quando si impostano le proprie operazioni di patch, è necessario scegliere [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) o [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) invece di `AWS-RunPatchBaselineAssociation`.
+ Quando utilizzi il documento `AWS-RunPatchBaselineAssociation`, è possibile specificare una coppia di chiavi di tag nel campo parametro `BaselineTags` del documento. Se una patch di base personalizzata Account AWS condivide questi tagPatch Manager, uno strumento in AWS Systems Manager uso utilizza quella baseline con tag quando viene eseguita sulle istanze di destinazione anziché la baseline di patch «predefinita» attualmente specificata per il tipo di sistema operativo.
**Nota**
Quando si sceglie di utilizzare `AWS-RunPatchBaselineAssociation` nelle operazioni di applicazione di patch diverse da quelle configurate con Quick Setup, e si desidera utilizzare il suo parametro `BaselineTags` opzionale, è necessario fornire alcune autorizzazioni aggiuntive al [profilo dell'istanza](setup-instance-permissions.md) per istanze Amazon Elastic Compute Cloud (Amazon EC2). Per ulteriori informazioni, consulta [Nome parametro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).
Entrambi i formati seguenti sono validi per il parametro `BaselineTags`:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Importante**
Le chiavi e i valori dei tag non consentono la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1).
+ Quando viene eseguito `AWS-RunPatchBaselineAssociation`, i dati di conformità delle patch raccolti vengono registrati utilizzando il comando API di `PutComplianceItems` al posto del comando `PutInventory`, che viene utilizzato da `AWS-RunPatchBaseline`. Questa differenza indica che le informazioni sulla conformità delle patch che vengono archiviate e segnalate per una specifica *associazione*. I dati di conformità delle patch generati al di fuori di questa associazione non vengono sovrascritti.
+ Le informazioni sulla conformità delle patch riportate dopo l'esecuzione di `AWS-RunPatchBaselineAssociation`indicano se un'istanza è conforme o meno. Non include dettagli a livello di patch, come dimostra l'output del comando seguente (). AWS Command Line Interface AWS CLI Il comando filtra su `Association` come tipo di conformità:
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
Quando un valore di una coppia di chiavi di tag è stato specificato come parametro per il documento `AWS-RunPatchBaselineAssociation`, Patch Manager cerca una baseline delle patch personalizzata che corrisponda al tipo di sistema operativo ed è stata contrassegnata con la stessa coppia di chiavi di tag. Questa ricerca non è limitata alla baseline delle patch predefinita corrente specificata o alla base assegnata a un gruppo di patch. Quando non viene trovata alcuna baseline con i tag specificati, Patch Manager cerca un gruppo di patch, se ne è stato specificato uno nel comando che esegue `AWS-RunPatchBaselineAssociation`. Quando nessun gruppo di patch viene abbinato, Patch Manager torna alla baseline delle patch predefinita corrente per l'account del sistema operativo.
Quando viene trovata più di una baseline delle patch con i tag specificati nel documento`AWS-RunPatchBaselineAssociation`, Patch Manager restituisce un messaggio di errore che indica che solo una baseline delle patch ha la possibilità di essere contrassegnata con quel valore di chiave in modo che l'operazione continui.
**Nota**
Sui nodi Linux, il gestore di pacchetti idonei per ogni tipo di nodo viene utilizzato per installare i pacchetti:
Amazon Linux 2, Oracle Linux e le istanze RHEL utilizzano YUM. Per le operazioni con YUM, Patch Manager richiede `Python 2.6` o una versione supportata successiva (da 2.6 a 3.12). Amazon Linux 2023 utilizza DNF. Per le operazioni DNF, Patch Manager richiede una versione supportata di `Python 2` o `Python 3` (da 2.6 a 3.12).
Le istanze Debian Server e Ubuntu Server utilizzano APT. Per le operazioni APT, Patch Manager richiede una versione supportata di `Python 3` (da 3.0 a 3.12).
Al termine di una scansione, o dopo che tutti gli aggiornamenti approvati e applicabili sono stati installati, con eventuali riavvii eseguiti, le informazioni sulla conformità delle patch sono generate su un'istanza e riportate al servizio Patch Compliance.
**Nota**
Quando il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaselineAssociation`, l'istanza non viene riavviata dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).
Per informazioni sulla visualizzazione dei dati di conformità delle patch, consulta [Informazioni sulla conformità delle patch](compliance-about.md#compliance-monitor-patch).
## Parametri `AWS-RunPatchBaselineAssociation`
`AWS-RunPatchBaselineAssociation` supporta cinque parametri. I parametri `Operation` e `AssociationId` sono obbligatori. I parametri `InstallOverrideList`, `RebootOption` e `BaselineTags` sono facoltativi.
**Topics**
+ [Nome parametro: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Nome parametro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Nome parametro: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Nome parametro: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### Nome parametro: `Operation`
**Utilizzo**: obbligatorio.
**Opzioni**: `Scan` \$1 `Install`.
Scan
Quando si sceglie l'opzione `Scan`, `AWS-RunPatchBaselineAssociation` determina lo stato di conformità delle patch dell'istanza e riferisce queste informazioni a Patch Manager. `Scan` non richiede l'installazione degli aggiornamenti o il riavvio delle istanze. L'operazione identifica dove gli aggiornamenti approvati e applicabili all'istanza risultano mancanti.
Installa
Quando si sceglie l'opzione `Install`, `AWS-RunPatchBaselineAssociation` tenta di installare gli aggiornamenti applicabili e approvati che risultano mancanti nell'istanza. Le informazioni sulla conformità delle patch generate in un'operazione `Install` non visualizzano gli aggiornamenti mancanti, ma possono specificare lo stato di errore degli aggiornamenti se per qualsiasi motivo l'installazione non è andata a buon fine. Quando un aggiornamento è installato in un'istanza, questa viene riavviata per assicurare l'aggiornamento sia installato e attivo. (Eccezione: se il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaselineAssociation`, l'istanza non viene riavviata dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta[Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)).
Se una patch specificata dalle regole di baseline viene installata *prima* Patch Manager dell'aggiornamento dell'istanza di Gestione patch, è possibile che il sistema non venga riavviato come previsto. Ciò si verifica quando una patch viene installata manualmente da un utente o installata automaticamente da un altro programma, ad esempio il pacchetto `unattended-upgrades` su Ubuntu Server.
### Nome parametro: `BaselineTags`
**Utilizzo**: facoltativo.
`BaselineTags` è un un key value di tag univoco, scelto e assegnato a una baseline delle patch personalizzata. È possibile specificare uno o più valori per questo parametro. Sono validi entrambi dei seguenti formati:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Importante**
Le chiavi e i valori dei tag non consentono la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1).
Il valore `BaselineTags` è utilizzato da Patch Manager per assicurare che una serie di istanze a cui vengono applicate le patch in un'unica operazione abbiano la stessa serie di patch approvate. Quando viene eseguita l'operazione di patch, Patch Manager controlla se una baseline delle patch per il tipo di sistema operativo è contrassegnata con la stessa coppia di key value per `BaselineTags`. Se c'è una corrispondenza, viene utilizzata questa baseline delle patch personalizzata. Se non esiste una corrispondenza, una baseline delle patch viene identificata in base a qualsiasi gruppo di patch specificato per l'operazione di applicazione di patch. Se non ce ne sono, viene utilizzata la linea di base delle patch predefinite AWS gestite per quel sistema operativo.
**Requisiti di permesso aggiuntivi**
Se utilizzi `AWS-RunPatchBaselineAssociation` nelle operazioni di applicazione di patch diverse da quelle configurate utilizzando Quick Setup, e desideri utilizzare l'opzione opzionale `BaselineTags`, è necessario aggiungere le seguenti autorizzazioni al [profilo dell'istanza](setup-instance-permissions.md) per istanze Amazon Elastic Compute Cloud (Amazon EC2).
**Nota**
Quick Setupe `AWS-RunPatchBaselineAssociation` non supportano server e macchine virtuali locali (). VMs
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
Sostituisci *patch-baseline-arn* con l'Amazon Resource Name (ARN) della patch di base a cui desideri fornire l'accesso, nel formato. `arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`
### Nome parametro: `AssociationId`
**Utilizzo**: obbligatorio.
`AssociationId` è l'ID di un'associazione esistente in State Manager, uno strumento di AWS Systems Manager. È usato da Patch Manager per aggiungere i dati di conformità a un'associazione specificata. Questa associazione è correlata a un'operazione `Scan` di patch abilitata in una [configurazione di gestione host creata in Quick Setup](quick-setup-host-management.md). Inviando i risultati delle patch come dati di conformità dell'associazione anziché come dati di conformità dell'inventario, le informazioni sulla conformità dell'inventario esistenti per le tue istanze non vengono sovrascritte dopo un'operazione di patch o per altre associazioni. IDs Se non disponi già di un'associazione da utilizzare, è possibile crearla eseguendo il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html). Esempio:
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows Server ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### Nome parametro: `InstallOverrideList`
**Utilizzo**: facoltativo.
Utilizzando `InstallOverrideList`, è possibile specificare un URL https o un URL in stile percorso Amazon Simple Storage Service (Amazon S3) per un elenco delle patch da installare. Questo elenco di installazione delle patch, gestito in formato YAML, sostituisce le patch specificate dalla baseline delle patch predefinita corrente. Ciò consente di avere un controllo più granulare su quali patch vengono installate nelle istanze.
**Importante**
Il nome del file `InstallOverrideList` non consente la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1).
Il comportamento dell'applicazione di patch quando si utilizza il parametro `InstallOverrideList`, differisce tra nodi gestiti da Linux e macOS o da Windows Server. Su Linux e macOS, Patch Manager tenta di applicare le patch incluse nell'elenco `InstallOverrideList` delle patch presenti in qualsiasi repository abilitato sul nodo, indipendentemente dal fatto che corrispondano o meno alle regole della baseline delle patch. Sui nodi di Windows Server, tuttavia, le patch nell'elenco `InstallOverrideList` vengono applicate *solo* quando corrispondono anche alle regole della baseline delle patch.
I report di conformità rispecchiano gli stati delle patch in base a quanto specificato nella baseline delle patch, non ciò che hai specificato in un elenco `InstallOverrideList` di patch. In altre parole, le operazioni di scansione ignorano il parametro `InstallOverrideList`. In questo modo si garantisce che i report di conformità rispecchino in modo omogeneo gli stati delle patch in base alla policy anziché in base a quanto era stato approvato per una specifica operazione di applicazione di patch.
**Formati URL validi**
**Nota**
Se il file è archiviato in un bucket pubblicamente disponibile, è possibile inoltre specificare un formato URL https o un URL in stile percorso Amazon S3. Se il file è archiviato in un bucket privato, è necessario specificare un URL in stile percorso Amazon S3.
+ **Esempio di formato URL https**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Esempio di URL in stile percorso Amazon S3**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formati dei contenuti YAML validi**
I formati utilizzati per specificare le patch nell'elenco variano in base al sistema operativo dell'istanza. Il formato generale, tuttavia, è quello riportato di seguito:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Benché sia possibile specificare altri campi nel file YAML, questi verranno ignorati durante le operazioni delle patch.
Inoltre, è consigliabile verificare che il formato del file YAML sia valido prima di aggiungere o aggiornare l'elenco nel bucket S3. Per ulteriori informazioni sul formato YAML, consulta [yaml.org](http://www.yaml.org). Per le opzioni degli strumento di convalida, effettua la ricerca sul Web di “convalida formato yaml”.
+ Microsoft Windows
**id**
Il campo **id** è obbligatorio. Utilizzatelo per specificare le patch utilizzando Microsoft Knowledge Base IDs (ad esempio KB2736693) e Microsoft Security Bulletin IDs (ad esempio, MS17 -023).
Tutti gli altri campi che intendi fornire in un elenco di patch per Windows sono facoltativi e hanno unicamente scopo informativo. È possibile utilizzare altri campi, come **title**, **classification**, **severity** o qualsiasi altro per fornire informazioni più dettagliate sulle patch specificate.
+ Linux
**id**
Il campo **id** è obbligatorio. Utilizzalo per specificare le patch con l'architettura e il nome del pacchetto. Ad esempio: `'dhclient.x86_64'`. Negli id, è possibile utilizzare i caratteri jolly per indicare più pacchetti. Ad esempio: `'dhcp*'` ed `'dhcp*1.*'`.
**titolo**
Il campo **titolo** è facoltativo, ma nei sistemi Linux offre funzionalità di filtraggio aggiuntive. Quando utilizzi **titolo**, è necessario che il campo includa le informazioni sulla versione del pacchetto in uno dei seguenti formati:
YUM/Red Hat Enterprise Linux (RHEL):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Per i titoli delle patch di Linux, è possibile utilizzare uno o più caratteri jolly in qualsiasi posizione per ampliare il numero di corrispondenze dei pacchetti. Ad esempio: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Ad esempio:
+ Il pacchetto apt versione 1.2.25 è correntemente installato nell'istanza, ma ora è disponibile la versione 1.2.27.
+ È possibile aggiungere apt.amd64 versione 1.2.27 all'elenco delle patch. Dipende da apt-utils.amd64 versione 1.2.27, ma apt-utils.amd64 versione 1.2.25 viene specificato nell'elenco.
In questo caso, la versione 1.2.27 di apt verrà bloccata dall'installazione e riportata come «Failed-». NonCompliant
**Altri campi**
Tutti gli altri campi che intendi fornire in un elenco di patch per Linux sono facoltativi e hanno unicamente scopo informativo. È possibile utilizzare altri campi, come **classification**, **severity** o qualsiasi altro per fornire informazioni più dettagliate sulle patch specificate.
**Elenchi di patch di esempio**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nome parametro: `RebootOption`
**Utilizzo**: facoltativo.
**Opzioni**: `RebootIfNeeded` \$1 `NoReboot`
**Default**: `RebootIfNeeded`
**avvertimento**
L'opzione predefinita è `RebootIfNeeded`. Assicurarsi di selezionare l'opzione corretta per il caso d'uso. Ad esempio, quando è necessario che le istanze vengano riavviate immediatamente per completare un processo di configurazione, scegli `RebootIfNeeded`. Oppure, quando è necessario mantenere la disponibilità delle istanze fino a un orario di riavvio pianificato, scegli `NoReboot`.
**Importante**
L'opzione `NoReboot` impedisce solo i riavvii a livello di sistema operativo. I riavvii a livello di servizio possono comunque avvenire come parte del processo di applicazione di patch. Ad esempio, quando Docker viene aggiornato, i servizi dipendenti come Amazon Elastic Container Service potrebbero riavviarsi automaticamente, anche con `NoReboot` abilitato. Se disponi di servizi critici, che non devono essere interrotti, prendi in considerazione misure aggiuntive come la rimozione temporanea delle istanze dal servizio o la pianificazione dell'applicazione di patch durante le finestre di manutenzione.
**Importante**
Non è consigliabile utilizzarlo Patch Manager per applicare patch a istanze di cluster in Amazon EMR (precedentemente chiamato Amazon Elastic). MapReduce In particolare, non selezionare l'opzione `RebootIfNeeded` per il parametro `RebootOption`. (Questa opzione è disponibile nei documenti del comando SSM per l'applicazione di patch `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`).
I comandi sottostanti per applicare le patch tramite Patch Manager utilizzano i comandi `yum` e `dnf`. Pertanto, le operazioni generano incompatibilità a causa del modo in cui i pacchetti vengono installati. Per informazioni sui metodi preferiti per l'aggiornamento del software sui cluster Amazon EMR, consulta [Utilizzo dell’AMI predefinita per Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) nella *Guida per la gestione di Amazon EMR*.
RebootIfNeeded
Quando si sceglie l'opzione `RebootIfNeeded`, l'istanza viene riavviata in uno dei seguenti casi:
+ Patch Manager installato uno o più patch.
Patch Manager non valuta se un riavvio è *obbligatorio* per la patch. Il sistema viene riavviato anche se la patch non richiede il riavvio.
+ Patch Manager rileva una o più patch con lo stato di `INSTALLED_PENDING_REBOOT` durante l'operazione `Install`.
Lo stato `INSTALLED_PENDING_REBOOT` indica che l'opzione `NoReboot` è stata selezionata l'ultima volta che l'operazione `Install` è stata eseguita, o che una patch è stata installata all'esterno di Patch Manager dall'ultimo riavvio del nodo gestito.
Il riavvio delle istanze in questi due casi garantisce che i pacchetti aggiornati vengano svuotati dalla memoria e mantengano coerenti il comportamento di patch e di riavvio in tutti i sistemi operativi.
NoReboot
Quando scegli l'opzione `NoReboot`, Patch Manager non riavvia l'istanza anche se ha installato patch durante l'operazione di `Install` Questa opzione è utile se le istanze non richiedono il riavvio dopo l'applicazione di patch, oppure nel caso di applicazioni o processi in esecuzione su un'istanza che non dovrebbero essere interrotti da un riavvio a seguito di un'operazione di applicazione di patch. È utile anche quando vuoi un maggiore controllo sui tempi dei riavvii dell'istanza, ad esempio utilizzando una finestra di manutenzione.
**File di monitoraggio dell'installazione delle patch**: per tenere traccia dell'installazione delle patch, in particolare delle patch installate dopo l'ultimo riavvio del sistema, Systems Manager mantiene un file nell'istanza gestita.
**Importante**
Non eliminare o modificare il file di monitoraggio. Quando questo file viene eliminato o danneggiato, il rapporto di conformità della patch per l'istanza non è accurato. In questo caso, riavvia l'istanza ed esegui un'operazione di scansione della patch per ripristinare il file.
Questo file di monitoraggio viene archiviato nei seguenti percorsi nelle istanze gestite:
+ Sistemi operativi Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server sistema operativo:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager supporta`AWS-RunPatchBaselineWithHooks`, un documento Systems Manager (documento SSM) perPatch Manager, uno strumento in AWS Systems Manager. Questo documento SSM esegue operazioni di applicazione di patch nei nodi gestiti per aggiornamenti correlati alla sicurezza e di altro tipo.
`AWS-RunPatchBaselineWithHooks` differisce da `AWS-RunPatchBaseline` nei seguenti modi:
+ **Un documento wrapper** – `AWS-RunPatchBaselineWithHooks` è un wrapper per `AWS-RunPatchBaseline` e si basa su `AWS-RunPatchBaseline` per alcune delle sue operazioni.
+ **L'operazione `Install` ** – `AWS-RunPatchBaselineWithHooks` supporta gli hook del ciclo di vita che vengono eseguiti in punti designati durante l'applicazione di patch del nodo gestito. Poiché le installazioni di patch a volte richiedono il riavvio dei nodi gestiti, l'operazione di applicazione di patch è suddivisa in due eventi, per un totale di tre hook che supportano funzionalità personalizzate. Il primo hook è prima dell'operazione `Install with NoReboot`. Il secondo hook è dopo dell'operazione `Install with NoReboot`. Il terzo hook è disponibile dopo il riavvio del nodo gestito.
+ **Nessun supporto per l'elenco di patch personalizzato** – `AWS-RunPatchBaselineWithHooks` non supporta il parametro di `InstallOverrideList`.
+ **Il supportoSSM Agent** – `AWS-RunPatchBaselineWithHooks`richiede che SSM Agent 3.0.502 o versione successiva deve essere installata sul nodo gestito di patch.
Quando il documento viene eseguito, utilizza la baseline delle patch attualmente specificata come “predefinita” per un tipo di sistema operativo se non è specificato alcun gruppo di patch. In caso contrario, vengono utilizzate le baseline delle patch associate al gruppo di patch. Per informazioni sui gruppi di patch, consulta [Gruppi di patch](patch-manager-patch-groups.md).
È possibile utilizzare il documento `AWS-RunPatchBaselineWithHooks` per applicare patch ai sistemi operativi e alle applicazioni. (In Windows Server, il supporto delle applicazioni è limitato ai soli aggiornamenti delle applicazioni Microsoft).
Questo documento supporta i nodi gestiti da Linux e Windows Server. Il documento eseguirà le operazioni adeguate per ciascuna piattaforma.
**Nota**
`AWS-RunPatchBaselineWithHooks` non è supportato su macOS.
------
#### [ Linux ]
Nei nodi gestiti Linux, il documento `AWS-RunPatchBaselineWithHooks` consente di richiamare un modulo Python, che a sua volta scarica una snapshot della baseline delle patch valida per il nodo gestito. Questa snapshot della baseline delle patch utilizza le regole e gli elenchi specificati delle patch approvate e bloccate per controllare il programma di gestione dei pacchetti adeguato per ciascun tipo di nodo:
+ I nodi gestiti da Amazon Linux 2, Oracle Linux e RHEL 7 utilizzano YUM. Per le operazioni con YUM, Patch Manager richiede `Python 2.6` o una versione supportata successiva (da 2.6 a 3.12). Amazon Linux 2023 utilizza DNF. Per le operazioni DNF, Patch Manager richiede una versione supportata di `Python 2` o `Python 3` (da 2.6 a 3.12).
+ I nodi gestiti 8 RHEL utilizzano DNF. Per le operazioni DNF, Patch Manager richiede una versione supportata di `Python 2` o `Python 3` (da 2.6 a 3.12). (Nessuna versione è installata per impostazione predefinita su RHEL 8. È necessario installare l'una o l'altra manualmente).
+ Le istanze Debian Server e Ubuntu Server utilizzano APT. Per le operazioni APT, Patch Manager richiede una versione supportata di `Python 3` (da 3.0 a 3.12).
------
#### [ Windows Server ]
Nei nodi Windows Server gestiti, il `AWS-RunPatchBaselineWithHooks` documento scarica e richiama un PowerShell modulo, che a sua volta scarica un'istantanea della linea di base della patch che si applica al nodo gestito. Questa snapshot della baseline delle patch contiene un elenco di patch approvate compilate eseguendo una query sulla baseline delle patch su un server Windows Server Update Services (WSUS). Questo elenco viene trasferito all'API di Windows Update, che controlla il download e l'installazione delle patch approvate, in base alle necessità.
------
Ogni istantanea è specifica per un gruppo di patch Account AWS, un sistema operativo e un ID di istantanea. Lo snapshot viene consegnato tramite un URL Amazon Simple Storage Service (Amazon S3) prefirmato, che scade 24 ore dopo la creazione dello snapshot. Dopo la scadenza dell'URL, tuttavia, se desideri applicare lo stesso contenuto snapshot ad altri nodi gestiti, è possibile generare un nuovo URL Amazon S3 prefirmato fino a tre giorni dopo la creazione della copia istantanea. Per farlo, utilizzare il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Dopo avere installato tutti gli aggiornamenti approvati e applicabili e dopo avere eseguito il riavvio, le informazioni sulla conformità delle patch vengono generate in un nodo gestito e trasferite a Patch Manager.
Se il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaselineWithHooks`, il nodo gestito non viene riavviata dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
**Importante**
Sebbene l'opzione di `NoReboot` impedisca il riavvio del sistema operativo, non impedisce i riavvii a livello di servizio, che potrebbero verificarsi quando determinati pacchetti vengono aggiornati. Ad esempio, l'aggiornamento di pacchetti come Docker può attivare il riavvio automatico dei servizi dipendenti (come i servizi di orchestrazione dei container), anche quando `NoReboot` viene specificato.
Per informazioni sulla visualizzazione dei dati di conformità delle patch, consulta [Informazioni sulla conformità delle patch](compliance-about.md#compliance-monitor-patch).
## Fasi operative di `AWS-RunPatchBaselineWithHooks`
Quando `AWS-RunPatchBaselineWithHooks` è in esecuzione, vengono portati a termine i seguenti passaggi:
1. **Scan**- Un'operazione di `Scan` utilizzando `AWS-RunPatchBaseline` viene eseguita sul nodo gestito e viene generato e caricato un report di conformità.
1. **Verificare gli stati delle patch locali** - Viene eseguito uno script per determinare quali passaggi verranno eseguiti in base all'operazione selezionata e al risultato di `Scan` della fase 1.
1. Se l'operazione selezionata è `Scan`, essa è contrassegnata come completata. L'operazione si conclude.
1. Se l'operazione selezionata è `Install`, Patch Manager valuta il risultato di `Scan` dal Passaggio 1 per determinare cosa eseguire dopo:
1. Se non vengono rilevate patch mancanti e non sono necessari riavvii in sospeso, l'operazione procede direttamente al passaggio finale (Passaggio 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati.
1. Se non vengono rilevate patch mancanti, ma sono necessari riavvii in sospeso e l'opzione di riavvio selezionata è `NoReboot`, l'operazione procede direttamente alla fase finale (Step 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati.
1. Altrimenti, l'operazione passa alla fase successiva.
1. **Funzionamento con hook pre-patch**: il documento SSM fornito per il primo hook del ciclo di vita, `PreInstallHookDocName`, viene eseguito sul nodo gestito.
1. **Installa con NoReboot**: sul nodo gestito viene eseguita un'`Install`operazione con l'opzione di `NoReboot` riavvio utilizzata e `AWS-RunPatchBaseline` viene generato e caricato un rapporto di conformità.
1. **Operazione hook post-installazione**: il documento SSM fornito per il secondo hook del ciclo di vita, `PostInstallHookDocName`, viene eseguito sul nodo gestito.
1. **Verifica del riavvio** - Viene eseguito uno script per determinare se è necessario un riavvio per il nodo gestito e quali passaggi eseguire:
1. Quando l'opzione di riavvio selezionata è `NoReboot`, essa procede direttamente alla fase finale (Step 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati.
1. Quando l'opzione di riavvio selezionata è `RebootIfNeeded`, Patch Manager verifica se sono necessari riavvii in sospeso dall'inventario raccolto al passaggio 4. Ciò significa che l'operazione continua nella fase 7 e il nodo gestito viene riavviato in uno dei seguenti casi:
1. Patch Manager ha installato una o più patch. (Patch Manager non valuta se un riavvio è obbligatorio per la patch. Il sistema viene riavviato anche se la patch non richiede il riavvio.)
1. Patch Manager rileva una o più patch con lo stato di `INSTALLED_PENDING_REBOOT` durante l'operazione di installazione. Lo stato `INSTALLED_PENDING_REBOOT` indica che l'opzione `NoReboot` è stata selezionata l'ultima volta che l'operazione di installazione è stata eseguita, o che una patch è stata installata all'esterno di Patch Manager dall'ultimo riavvio del nodo gestito.
Quando non vengono rilevate patch che rispondono a questi criteri, l'operazione di applicazione della patch del nodo gestito viene completata e si passa direttamente alla fase finale (passaggio 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati.
1. **Riavvio e report** - Un'operazione di installazione con l'opzione di riavvio di `RebootIfNeeded` viene eseguito sul nodo gestito utilizzando `AWS-RunPatchBaseline` e viene generato e caricato un report sulla conformità.
1. **Operazione hook post-riavvio**: il documento SSM fornito per il terzo hook del ciclo di vita, `OnExitHookDocName`, viene eseguito sul nodo gestito.
Per un'operazione `Scan`, se il Passaggio 1 non va a buon fine, il processo di esecuzione del documento si interrompe e il passaggio viene segnalato come non andato a buon fine, anche se i passaggi successivi vengono segnalati come esito positivo.
Per un'operazione `Install`, se uno qualsiasi dei passaggi `aws:runDocument` non va a buon fine durante l'operazione, tali passaggi vengono segnalati come non andati a buon fine e l'operazione procede direttamente al Passaggio finale (Passaggio 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati. Questo passaggio viene segnalato come non andato a buon fine, l'ultimo passaggio riporta lo stato del risultato dell'operazione e tutti i passaggi intermedi vengono segnalati come esito positivo.
## Parametri di `AWS-RunPatchBaselineWithHooks`
`AWS-RunPatchBaselineWithHooks` supporta sei parametri.
Il parametro `Operation` è obbligatorio.
I parametri `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` e `OnExitHookDocName` sono facoltativi.
`Snapshot-ID` è tecnicamente facoltativo, ma è consigliabile fornire un valore personalizzato per esso quando si esegue `AWS-RunPatchBaselineWithHooks` al di fuori di una finestra di manutenzione. Consenti a Patch Manager di fornire il valore automaticamente quando il documento viene eseguito nell'ambito di un'operazione di manutenzione.
**Topics**
+ [Nome parametro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nome parametro: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nome parametro: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nome parametro: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nome parametro: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### Nome parametro: `Operation`
**Utilizzo**: obbligatorio.
**Opzioni**: `Scan` \$1 `Install`.
Scan
Quando si sceglie l'opzione `Scan`, il sistema utilizza il documento `AWS-RunPatchBaseline` per determinare lo stato di conformità delle patch dell'istanza e riferisce queste informazioni a Patch Manager. `Scan` non richiede l'installazione degli aggiornamenti o il riavvio dei nodi gestiti. L'operazione identifica dove gli aggiornamenti approvati e applicabili al nodo risultano mancanti.
Installa
Quando si sceglie l'opzione `Install`, `AWS-RunPatchBaselineWithHooks` tenta di installare gli aggiornamenti applicabili e approvati che risultano mancanti nel nodo gestito. Le informazioni sulla conformità delle patch generate in un'operazione `Install` non visualizzano gli aggiornamenti mancanti, ma sono in grado di specificare lo stato di errore degli aggiornamenti se per qualsiasi motivo l'installazione non è andata a buon fine. Quando un aggiornamento è installato in un nodo gestito, questo viene riavviato per assicurare l'aggiornamento sia installato e attivo. (Eccezione: se il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaselineWithHooks`, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption).)
Se una patch specificata dalle regole di baseline viene installata *prima* che Patch Manager aggiorni il nodo gestito, è possibile che il sistema non venga riavviato come previsto. Ciò si verifica quando una patch viene installata manualmente da un utente o installata automaticamente da un altro programma, ad esempio il pacchetto `unattended-upgrades` su Ubuntu Server.
### Nome parametro: `Snapshot ID`
**Utilizzo**: facoltativo.
`Snapshot ID` è un ID univoco (GUID) utilizzato da Patch Manager per assicurare che una serie di nodi gestiti a cui vengono applicate le patch in un'unica operazione abbiano la stessa serie di patch approvate. Anche se il parametro è definito come facoltativo, la best practice dipende dal fatto che `AWS-RunPatchBaselineWithHooks` sia o meno in esecuzione in una finestra di manutenzione, come descritto nella seguente tabella.
**Best practice di `AWS-RunPatchBaselineWithHooks`**
| Modalità | Best practice | Informazioni |
| --- | --- | --- |
| In esecuzione AWS-RunPatchBaselineWithHooks all'interno di una finestra di manutenzione | Non fornire un ID della snapshot. Patch Manager la fornirà automaticamente. | Quando utilizzi una finestra di manutenzione per eseguire `AWS-RunPatchBaselineWithHooks`, non devi fornire l'ID della snapshot generata. In questo scenario, Systems Manager fornisce un valore GUID in base all'ID di esecuzione della finestra di manutenzione. In questo modo, si garantisce che venga utilizzato un ID corretto per tutte le invocazioni di `AWS-RunPatchBaselineWithHooks` in tale finestra di manutenzione. Si noti che se si specifica un valore in questo scenario, la snapshot della baseline delle patch potrebbe non durare per più di 3 giorni. In seguito, verrà generata una nuova snapshot anche se hai specificato lo stesso ID dopo la scadenza della snapshot. |
| In esecuzione AWS-RunPatchBaselineWithHooks al di fuori di una finestra di manutenzione | Generare e specificare un valore GUID personalizzato per l'ID della snapshot. | Se non utilizzi una finestra di manutenzione per eseguire `AWS-RunPatchBaselineWithHooks`, ti consigliamo di generare e specificare un ID snapshot univoco per ogni baseline delle patch, soprattutto se stai eseguendo il documento `AWS-RunPatchBaselineWithHooks` su più nodi gestiti nella stessa operazione. Se specifichi un ID in questo scenario, Systems Manager genera un altro ID snapshot per ciascun nodo gestito a cui viene inviato il comando. Di conseguenza, potrebbero venire specificate varie serie di patch fra i nodi. Ad esempio, potresti eseguire il documento `AWS-RunPatchBaselineWithHooks` direttamente tramite Run Command, uno strumento di AWS Systems Manager e destinarlo a un gruppo di 50 nodi gestiti. Specificando un ID snapshot personalizzato verrà creata una singola snapshot di baseline utilizzata per valutare le patch e tutti i nodi gestiti, per garantire che il relativo stato finale sia coerente. |
| ¹ È possibile utilizzare qualsiasi strumento in grado di generare un GUID per ottenere il valore del parametro ID snapshot. Ad esempio, in PowerShell, è possibile utilizzare il `New-Guid` cmdlet per generare un GUID nel formato di. `12345699-9405-4f69-bc5e-9315aEXAMPLE` |
### Nome parametro: `RebootOption`
**Utilizzo**: facoltativo.
**Opzioni**: `RebootIfNeeded` \$1 `NoReboot`
**Default**: `RebootIfNeeded`
**avvertimento**
L'opzione predefinita è `RebootIfNeeded`. Assicurarsi di selezionare l'opzione corretta per il caso d'uso. Ad esempio, quando è necessario che i nodi gestiti vengano riavviati immediatamente per completare un processo di configurazione, scegli `RebootIfNeeded`. Oppure, quando è necessario mantenere la disponibilità dei nodi gestiti fino a un orario di riavvio pianificato, scegli `NoReboot`.
**Importante**
Non è consigliabile utilizzarlo Patch Manager per applicare patch a istanze di cluster in Amazon EMR (precedentemente chiamato Amazon Elastic). MapReduce In particolare, non selezionare l'opzione `RebootIfNeeded` per il parametro `RebootOption`. (Questa opzione è disponibile nei documenti del comando SSM per l'applicazione di patch `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`).
I comandi sottostanti per applicare le patch tramite Patch Manager utilizzano i comandi `yum` e `dnf`. Pertanto, le operazioni generano incompatibilità a causa del modo in cui i pacchetti vengono installati. Per informazioni sui metodi preferiti per l'aggiornamento del software sui cluster Amazon EMR, consulta [Utilizzo dell’AMI predefinita per Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) nella *Guida per la gestione di Amazon EMR*.
RebootIfNeeded
Quando si sceglie l'opzione `RebootIfNeeded`, il nodo gestito viene riavviato in uno dei seguenti casi:
+ Patch Manager installato uno o più patch.
Patch Manager non valuta se un riavvio è *obbligatorio* per la patch. Il sistema viene riavviato anche se la patch non richiede il riavvio.
+ Patch Manager rileva una o più patch con lo stato di `INSTALLED_PENDING_REBOOT` durante l'operazione `Install`.
Lo stato `INSTALLED_PENDING_REBOOT` indica che l'opzione `NoReboot` è stata selezionata l'ultima volta che l'operazione `Install` è stata eseguita, o che una patch è stata installata all'esterno di Patch Manager dall'ultimo riavvio del nodo gestito.
Il riavvio dei nodi gestiti in questi due casi garantisce che i pacchetti aggiornati vengano svuotati dalla memoria e mantengano coerenti il comportamento di patch e di riavvio in tutti i sistemi operativi.
NoReboot
Quando scegli l'opzione `NoReboot`, Patch Manager non riavvia il nodo gestito anche se ha installato patch durante l'operazione di `Install` Questa opzione è utile se i nodi gestiti non richiedono il riavvio dopo l'applicazione di patch, oppure nel caso di applicazioni o processi in esecuzione su un nodo che non dovrebbero essere interrotti da un riavvio a seguito di un'operazione di applicazione di patch. È utile anche quando si necessita di un maggiore controllo sui tempi dei riavvii del nodo gestito, ad esempio utilizzando una finestra di manutenzione.
Quando si sceglie l'opzione `NoReboot` e viene installata una patch, alla patch viene assegnato lo stato `InstalledPendingReboot`. Il nodo gestito stesso, tuttavia, viene contrassegnato come `Non-Compliant`. Dopo che si verifica un riavvio e viene eseguita un'operazione `Scan`, lo stato del nodo diventa `Compliant`.
**File di monitoraggio dell'installazione delle patch**: per tenere traccia dell'installazione delle patch, in particolare delle patch installate dopo l'ultimo riavvio del sistema, Systems Manager mantiene un file nel nodo gestito.
**Importante**
Non eliminare o modificare il file di monitoraggio. Se questo file viene eliminato o danneggiato, il rapporto di conformità della patch per il nodo gestito non è accurato. In questo caso, riavvia il nodo ed esegui un'operazione di scansione della patch per ripristinare il file.
Questo file di monitoraggio viene archiviato nei seguenti percorsi nei nodi gestiti:
+ Sistemi operativi Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server sistema operativo:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nome parametro: `PreInstallHookDocName`
**Utilizzo**: facoltativo.
**Default**: `AWS-Noop`
Il valore da fornire per il parametro `PreInstallHookDocName` è il nome o l'Amazon Resource Name (ARN) di un documento SSM di tua scelta. Puoi fornire il nome di un documento AWS gestito o il nome o l'ARN di un documento SSM personalizzato che hai creato o che è stato condiviso con te. (Per un documento SSM che è stato condiviso con te da un altro Account AWS, devi specificare l'ARN completo della risorsa, ad esempio`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)
Il documento SSM specificato viene eseguito prima dell'operazione `Install` esegue tutte le operazioni supportate da SSM Agent, ad esempio uno script di shell per controllare il controllo dell'integrità dell'applicazione prima che venga eseguita l'applicazione di patch sul nodo gestito. Per un elenco di operazioni, consulta [Documentazione di riferimento del plugin per i documenti di comando](documents-command-ssm-plugin-reference.md)). Il nome di default del documento SSM è `AWS-Noop`, che non esegue alcuna operazione sul nodo gestito.
Per informazioni sulla creazione di un documento SSM personalizzato, consulta [Creazione del contenuto del documento SSM](documents-creating-content.md).
### Nome parametro: `PostInstallHookDocName`
**Utilizzo**: facoltativo.
**Default**: `AWS-Noop`
Il valore da fornire per il parametro `PostInstallHookDocName` è il nome o l'Amazon Resource Name (ARN) di un documento SSM di tua scelta. Puoi fornire il nome di un documento AWS gestito o il nome o l'ARN di un documento SSM personalizzato che hai creato o che è stato condiviso con te. (Per un documento SSM che è stato condiviso con te da un altro Account AWS, devi specificare l'ARN completo della risorsa, ad esempio`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)
Il documento SSM specificato viene eseguito dopo l'operazione `Install with NoReboot` ed esegue tutte le azioni supportate da SSM Agent, ad esempio uno script di shell per l'installazione di aggiornamenti di terze parti prima del riavvio. Per un elenco di operazioni, consulta [Documentazione di riferimento del plugin per i documenti di comando](documents-command-ssm-plugin-reference.md)). Il nome di default del documento SSM è `AWS-Noop`, che non esegue alcuna operazione sul nodo gestito.
Per informazioni sulla creazione di un documento SSM personalizzato, consulta [Creazione del contenuto del documento SSM](documents-creating-content.md).
### Nome parametro: `OnExitHookDocName`
**Utilizzo**: facoltativo.
**Default**: `AWS-Noop`
Il valore da fornire per il parametro `OnExitHookDocName` è il nome o l'Amazon Resource Name (ARN) di un documento SSM di tua scelta. Puoi fornire il nome di un documento AWS gestito o il nome o l'ARN di un documento SSM personalizzato che hai creato o che è stato condiviso con te. (Per un documento SSM che è stato condiviso con te da un Account AWS diverso, è necessario specificare l'ARN della risorsa completa, ad esempio `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
Il documento SSM specificato viene eseguito dopo l'operazione di riavvio del nodo gestito ed esegue tutte le operazioni supportate da SSM Agent, ad esempio uno script di shell per verificare l'integrità del nodo dopo il completamento dell'operazione di applicazione di patch. Per un elenco di operazioni, consulta [Documentazione di riferimento del plugin per i documenti di comando](documents-command-ssm-plugin-reference.md)). Il nome di default del documento SSM è `AWS-Noop`, che non esegue alcuna operazione sul nodo gestito.
Per informazioni sulla creazione di un documento SSM personalizzato, consulta [Creazione del contenuto del documento SSM](documents-creating-content.md).
# Scenario di esempio per l'utilizzo del InstallOverrideList parametro in `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`
Usa il parametro `InstallOverrideList`, quando vuoi sovrascrivere le patch specificate dalla baseline delle patch corrente della patch predefinita, in Patch Manager, uno strumento di AWS Systems Manager. In questo argomento vengono forniti esempi che illustrano come utilizzare questo parametro per effettuare le seguenti operazioni:
+ Applicare diversi set di patch a un gruppo target di nodi gestiti.
+ Applicare questi set di patch a frequenze diverse.
+ Utilizzare la stessa baseline delle patch per entrambe le operazioni.
Supponiamo che vuoi installare due diverse categorie di patch nei nodi Amazon Linux 2. Vuoi installare queste patch su pianificazioni diverse utilizzando le finestre di manutenzione. Vuoi eseguire una finestra di manutenzione ogni settimana e installare tutte le patch `Security`. Vuoi eseguire un'altra finestra di manutenzione una volta al mese e installare tutte le patch disponibili o le categorie di patch diverse da `Security`.
Tuttavia, solo una baseline delle patch alla volta può essere specificata come predefinita nel sistema operativo. Questo requisito consente di evitare situazioni in cui una baseline delle patch approva una patch mentre un'altra la blocca, il che può causare problemi tra versioni in conflitto.
Con la seguente strategia, è possibile utilizzare il parametro `InstallOverrideList` per applicare diversi tipi di patch a un gruppo di destinazione in pianificazioni diverse, pur utilizzando la stessa baseline delle patch:
1. Nella baseline delle patch predefinita, assicurati che siano specificati solo gli aggiornamenti `Security`.
1. Crea una prima finestra di manutenzione che esegue `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation` ogni settimana. Non specificare un elenco di sostituzioni.
1. Crea un elenco di sostituzioni delle patch di tutti i tipi che vuoi applicare su base mensile e archivialo in un bucket Amazon Simple Storage Service (Amazon S3).
1. Crea una seconda finestra di manutenzione che viene eseguita una volta al mese. Tuttavia, per l'attività Run Command che vuoi registrare per questa finestra di manutenzione, specifica la posizione dell'elenco di sostituzioni.
Il esito: ogni settimana vengono installate solo le patch `Security`, come definito nella baseline delle patch predefinita. Tutte le patch disponibili, o qualsiasi sottoinsieme di patch che definisci, vengono installate ogni mese.
**Nota**
Quando esegui la patch di un nodo che utilizza solo un nodo IPv6, assicurati che l'URL fornito sia raggiungibile dal nodo. Se l'opzione di SSM Agent configurazione `UseDualStackEndpoint` è impostata su`true`, viene utilizzato un client S3 dualstack quando viene fornito un URL S3. [Tutorial: applicazione di patch a un server in un IPv6 unico ambiente](patch-manager-server-patching-iPv6-tutorial.md)Per ulteriori informazioni sulla configurazione dell'agente per l'utilizzo del dualstack, consulta.
Per maggiori informazioni ed esempi, consulta [Nome parametro: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).
# Utilizzo del BaselineOverride parametro
È possibile definire le preferenze di applicazione di patch in fase di runtime utilizzando la funzionalità di sostituzione della baseline in Patch Manager, uno strumento di AWS Systems Manager. Per farlo, specificare un bucket Amazon Simple Storage Service (Amazon S3) contenente un oggetto JSON con un elenco delle baseline delle patch. L'operazione di applicazione di patch utilizza le baseline fornite nell'oggetto JSON che corrispondono al sistema operativo host anziché applicare le regole dalla baseline delle patch predefinita.
**Importante**
Il nome del file `BaselineOverride` non consente la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1).
Tranne quando un'operazione di patch utilizza una policy di patch, l'utilizzo del parametro `BaselineOverride` non sovrascrive la conformità della patch della baseline fornita nel parametro. I risultati dell'output vengono registrati nei log Stdout da Run Command, uno strumento di AWS Systems Manager. I risultati stampano solo i pacchetti contrassegnati come `NON_COMPLIANT`. Ciò significa che il pacchetto è contrassegnato come `Missing`, `Failed`, `InstalledRejected`, oppure `InstalledPendingReboot`.
Tuttavia, quando un'operazione di patch utilizza una policy di patch, il sistema passa il parametro di sostituzione dal bucket S3 associato e il valore di conformità viene aggiornato per il nodo gestito. Per ulteriori informazioni sul comportamento delle policy di patch, consulta [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
**Nota**
Quando stai applicando la patch a un nodo che utilizza solo un nodo IPv6, assicurati che l'URL fornito sia raggiungibile dal nodo. Se l'opzione di SSM Agent configurazione `UseDualStackEndpoint` è impostata su`true`, viene utilizzato un client S3 dualstack quando viene fornito un URL S3. [Tutorial: applicazione di patch a un server in un IPv6 unico ambiente](patch-manager-server-patching-iPv6-tutorial.md)Per ulteriori informazioni sulla configurazione dell'agente per l'utilizzo del dualstack, consulta.
## Utilizzo della sostituzione della baseline delle patch con i parametri ID Snapshot o dell'installazione Install Override List
Esistono due casi in cui la sostituzione della baseline delle patch ha un comportamento degno di nota.
**Utilizzo simultaneo della sostituzione della baseline e dell'ID snapshot**
Gli ID snapshot assicurano che tutti i nodi gestiti di un particolare comando di applicazione di patch applichino tutte la stessa cosa. Ad esempio, quando si esegue la patch di 1.000 nodi contemporaneamente, le patch saranno le stesse.
Quando si utilizzano sia un ID snapshot che una sostituzione della baseline delle patch, l'ID snapshot ha la precedenza sulla sostituzione della baseline della patch. Le regole di sostituzione della baseline verranno comunque utilizzate, ma verranno valutate una sola volta. Nell'esempio precedente, le patch tra i 1.000 nodi gestiti saranno sempre le stesse. Se, a metà dell'operazione di applicazione di patch, è stato modificato il file JSON nel bucket S3 di riferimento per essere diverso, le patch applicate saranno comunque le stesse. Questo perché è stato fornito l'ID snapshot.
**Utilizzo simultaneo della sostituzione della baseline e Install Override List**
Non è possibile utilizzare questi due parametri nello stesso momento. Il documento di applicazione di patch non va a buon fine se vengono forniti entrambi i parametri e non esegue alcuna scansione o installazione nel nodo gestito.
## Esempi di codice
Il seguente esempio di codice per Python mostra come generare la sostituzione della baseline delle patch.
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
Ciò produce una sostituzione della baseline delle patch simile alla seguente.
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```
# Patch di base
Gli argomenti di questa sezione forniscono informazioni sulle modalità di funzionamento delle basi di patch in Patch Manager, uno strumento di AWS Systems Manager, quando esegui un'operazione di `Scan` o `Install` sui tuoi nodi gestiti.
**Topics**
+ [Baseline delle patch predefinite e personalizzate](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md)
+ [Gruppi di patch](patch-manager-patch-groups.md)
+ [Applicazione di patch rilasciata da Microsoft in Windows Server](patch-manager-patching-windows-applications.md)
# Baseline delle patch predefinite e personalizzate
Patch Manager, uno strumento in AWS Systems Manager, fornisce linee di base di patch predefinite per ciascuno dei sistemi operativi supportati da. Patch Manager È possibile utilizzare queste basi così come sono configurate (non è possibile personalizzarle) oppure è possibile creare baseline delle patch personalizzate. Le baseline delle patch personalizzate ti consentono di ottenere un maggiore controllo sulle patch approvate o rifiutate per l'ambiente. Inoltre, le baseline predefinite assegnano un livello di conformità `Unspecified` a tutte le patch installate queste basi. Per assegnare i valori di conformità, è possibile creare una copia di una baseline predefinita e specificare i valori di conformità che vuoi assegnare alle patch. Per ulteriori informazioni, consultare [Baseline personalizzate](#patch-manager-baselines-custom) e [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md).
**Nota**
Le informazioni contenute in questo argomento 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 **Applica subito una patch** on demand
**Topics**
+ [Baseline predefinite](#patch-manager-baselines-pre-defined)
+ [Baseline personalizzate](#patch-manager-baselines-custom)
## Baseline predefinite
Nella seguente tabella sono riportate le baseline delle patch predefinite fornite con Patch Manager.
Per informazioni sulle versioni di ciascun sistema operativo supportato da Patch Manager , consulta [Prerequisiti di Patch Manager](patch-manager-prerequisites.md).
****
| Name | Sistema operativo supportato | Informazioni |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | Approva tutte le patch del sistema operativo classificate come "Sicurezza" e con un livello di gravità pari a "Critico" o "Importante". Approva inoltre tutte le patch classificate come "Bugfix". Le patch vengono approvate automaticamente 7 giorni dopo il rilascio o l'aggiornamento.¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Approva tutte le patch del sistema operativo classificate come "Sicurezza" e con un livello di gravità pari a "Critico" o "Importante". Inoltre approva tutte le patch classificate come "Bugfix". Le patch vengono approvate automaticamente 7 giorni dopo il rilascio.¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | Approva tutte le patch del sistema operativo classificate come "Sicurezza" e con un livello di gravità pari a "Critico" o "Importante". Le patch vengono approvate automaticamente sette giorni dopo il rilascio. Inoltre approva tutte le patch classificate come "Bugfix" sette giorni dopo il rilascio |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | Approva tutti gli aggiornamenti sette giorni dopo il rilascio, inclusi quelli non correlati alla sicurezza. |
| AWS-DebianDefaultPatchBaseline | Debian Server | Approva immediatamente tutte le patch del sistema operativo correlate alla sicurezza con la priorità "Obbligatorio", "Importante", "Standard", "Facoltativo" oppure "Extra". Non vi è alcun tempo di attesa prima dell'approvazione perché le date di rilascio affidabili non sono disponibili nei repository. |
| AWS-MacOSDefaultPatchBaseline | macOS | Approva tutte le patch del sistema operativo classificate come “Security”. Approva anche tutti i pacchetti con un aggiornamento corrente. |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Approva tutte le patch del sistema operativo classificate come "Sicurezza" e con un livello di gravità pari a "Importante" o "Moderato". Approva inoltre tutte le patch classificate come "Bugfix" 7 giorni dopo il rilascio. Le patch vengono approvate automaticamente 7 giorni dopo il rilascio o l'aggiornamento.¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | Approva tutte le patch del sistema operativo classificate come "Sicurezza" e con un livello di gravità pari a "Critico" o "Importante". Approva inoltre tutte le patch classificate come "Bugfix". Le patch vengono approvate automaticamente 7 giorni dopo il rilascio o l'aggiornamento.¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | Approva tutte le patch del sistema operativo classificate come "Sicurezza" e con un livello di gravità pari a "Critico" o "Importante". Approva inoltre tutte le patch classificate come "Bugfix". Le patch vengono approvate automaticamente 7 giorni dopo il rilascio o l'aggiornamento.¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Approva tutte le patch del sistema operativo classificate come "Sicurezza" e con una gravità pari a "Critica" o "Importante". Le patch vengono approvate automaticamente 7 giorni dopo il rilascio o l'aggiornamento.¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | Approva immediatamente tutte le patch del sistema operativo correlate alla sicurezza con la priorità "Obbligatorio", "Importante", "Standard", "Facoltativo" oppure "Extra". Non vi è alcun tempo di attesa prima dell'approvazione perché le date di rilascio affidabili non sono disponibili nei repository. |
| AWS-DefaultPatchBaseline | Windows Server | Approva tutte le patch del sistema Windows Server operativo classificate come "" o "CriticalUpdatesSecurityUpdates" e che hanno una severità MSRC di «Critica» o «Importante». Le patch vengono approvate automaticamente 7 giorni dopo il rilascio o l'aggiornamento.² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | Approva tutte le patch del sistema Windows Server operativo classificate come "" o "CriticalUpdatesSecurityUpdates" e che hanno una severità MSRC di «Critica» o «Importante». Le patch vengono approvate automaticamente 7 giorni dopo il rilascio o l'aggiornamento.² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Per il sistema Windows Server operativo, approva tutte le patch classificate come "" o "CriticalUpdatesSecurityUpdates" e che hanno una gravità MSRC di «Critica» o «Importante». Per le applicazioni rilasciate da Microsoft, approva tutte le patch. Sia le patch del sistema operativo sia quelle delle applicazioni vengono approvate automaticamente 7 giorni dopo il rilascio o l'aggiornamento.² |
¹ Per Amazon Linux 2, l'attesa di sette giorni prima dell'approvazione automatica delle patch viene calcolata in base al valore `Updated Date` in `updateinfo.xml`, non al valore `Release Date`. Vari fattori possono influire sul valore `Updated Date`. Altri sistemi operativi gestiscono le date di rilascio e aggiornamento in modo diverso. Per informazioni su come evitare risultati imprevisti dovuti a ritardi nell'approvazione automatica, consulta [Il modo in cui vengono calcolate le date di rilascio e di aggiornamento dei pacchetti](patch-manager-release-dates.md).
² Per Windows Server, le baseline predefinite includono un ritardo di approvazione automatica di 7 giorni. Per installare una patch entro 7 giorni dal rilascio, è necessario creare una baseline personalizzata.
## Baseline personalizzate
Consulta le seguenti informazioni utili per creare baseline delle patch personalizzate per raggiungere gli obiettivi di patch.
**Topics**
+ [Utilizzo delle approvazioni automatiche nelle baseline personalizzate](#baselines-auto-approvals)
+ [Informazioni aggiuntive per la creazione di baseline delle patch](#baseline-additional-info)
### Utilizzo delle approvazioni automatiche nelle baseline personalizzate
Se crei la tua baseline delle patch, potrai scegliere le patch da approvare automaticamente utilizzando le seguenti categorie.
+ **Sistema operativo**: versioni supportate di Windows Server, Amazon Linux, Ubuntu Server e così via.
+ **Nome prodotto** (per sistemi operativi): ad esempio, RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2 e così via.
+ **Nome prodotto** (Windows Serversolo per le applicazioni rilasciate da Microsoft su): ad esempio, Word 2016, BizTalk Server e così via.
+ **Classificazione**: ad esempio aggiornamenti critici, aggiornamenti di sicurezza e così via.
+ **Gravità**: ad esempio critica, importante e così via.
Per ogni regola di approvazione creata, è possibile scegliere di specificare un ritardo di approvazione automatica o specificare una data limite di approvazione patch.
**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.
Il ritardo è il numero di giorni di attesa dopo il rilascio o l'ultimo aggiornamento della patch, prima che questa venga automaticamente approvata per l'applicazione. Ad esempio, se crei una regola con la classificazione `CriticalUpdates` e la configuri con un ritardo dell'approvazione automatica di 7 giorni, la nuova patch critica rilasciata il 7 gennaio verrà automaticamente approvata il 14 gennaio.
Se un repository Linux non fornisce informazioni sulla data di rilascio per pacchetti, Patch Manager utilizza il tempo di compilazione del pacchetto come la data dell'approvazione automatica per Amazon Linux 2, Amazon Linux 2023 e Red Hat Enterprise Linux (RHEL). 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.
Quando si specifica una data limite di approvazione automatica, Patch Manager applica automaticamente tutte le patch rilasciate o aggiornate in data o precedente. Ad esempio, se si specifica il 7 luglio 2023 come data limite, nessuna patch rilasciata o aggiornata a partire dall'8 luglio 2023 verrà installata automaticamente.
Quando si crea una baseline delle patch personalizzata, è possibile specificare un livello di gravità di conformità per le patch approvate da quella baseline delle patch, ad esempio `Critical` o `High`. Se lo stato delle patch approvate viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
### Informazioni aggiuntive per la creazione di baseline delle patch
Quando crei una baseline delle patch, tieni presente quanto segue:
+ Patch Manager fornisce una baseline delle patch predefinita per ogni sistema operativo supportato. Queste vengono utilizzate come baseline delle patch predefinite per ciascun tipo di sistema operativo, a meno che non si crei la propria baseline delle patch designandola come predefinita per il tipo di sistema operativo corrispondente.
**Nota**
Per Windows Server, vengono fornite tre baseline delle patch predefinite. Le baseline delle patch `AWS-DefaultPatchBaseline` e `AWS-WindowsPredefinedPatchBaseline-OS` supportano solo gli aggiornamenti del sistema operativo Windows stesso. `AWS-DefaultPatchBaseline`Viene utilizzato come baseline delle patch di default per nodi gestiti Windows Server a meno che non si specifichi una baseline delle patch diversa. Le impostazioni di configurazione in queste due baseline delle patch sono le stesse. Il più recente dei due, `AWS-WindowsPredefinedPatchBaseline-OS`, è stato creato per distinguerlo dalla terza baseline delle patch predefinita per Windows Server. Quella baseline delle patch, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, può essere utilizzata per applicare patch sia nel sistema operativo Windows Server che nelle applicazioni supportate rilasciate da Microsoft.
+ 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, allora la nuova patch non viene installata durante l'operazione di applicazione. Per ulteriori informazioni sulle regole dell'applicazione di patch di Windows Server, consulta la scheda Windows Server su [Come vengono selezionate le patch di sicurezza](patch-manager-selecting-patches.md).
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`.
+ Solo per Windows Server, una patch di aggiornamento di sicurezza disponibile non approvata dalla baseline delle patch può avere un valore di conformità pari a `Compliant` o `Non-Compliant`, come definito in una baseline della patch personalizzata.
Quando si crea o si aggiorna una baseline delle patch, si sceglie lo stato da assegnare alle patch di sicurezza disponibili ma non approvate, perché non soddisfano i criteri di installazione specificati nella baseline delle patch. Ad esempio, le patch di sicurezza che si desidera installare possono essere ignorate se è stato specificato un lungo periodo di attesa dopo il rilascio di una patch prima dell'installazione. Se un aggiornamento della patch viene rilasciato durante il periodo di attesa specificato, il periodo di attesa per l'installazione della patch ricomincia da capo. Se il periodo di attesa è troppo lungo, è possibile che più versioni della patch vengano rilasciate e mai installate.
Utilizzando la console per creare o aggiornare una baseline delle patch, si specifica questa opzione nel campo **Stato di conformità degli aggiornamenti di sicurezza disponibili**. Utilizzando il [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)comando AWS CLI to run [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)or, si specifica questa opzione nel `available-security-updates-compliance-status` parametro.
+ Per i server e le macchine virtuali locali (VMs), Patch Manager tenta di utilizzare la patch di base predefinita personalizzata. Se non è disponibile alcuna baseline delle patch predefinita personalizzata, il sistema utilizza quella predefinita per il sistema operativo corrispondente.
+ Se una patch è specificata come approvata e rifiutata nella stessa baseline delle patch, viene rifiutata.
+ Un nodo gestito può avere solo una baseline delle patch definita.
+ I formati dei nomi dei pacchetti che possono essere aggiunti agli elenchi delle patch approvate e di quelle rifiutate per una baseline delle patch dipendono dal tipo di sistema operativo a cui si applicano le patch.
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).
+ Se utilizzi una [configurazione della policy di patch](patch-manager-policies.md) in Quick Setup, gli aggiornamenti apportati alle baseline delle patch personalizzate vengono sincronizzati con Quick Setup una volta ogni ora.
Quando si elimina una baseline delle patch personalizzata a cui si fa riferimento in una policy di patch, viene visualizzato un banner nella pagina **Dettagli di configurazione** di Quick Setup relativa alla policy di patch. Il banner informa che la policy di patch fa riferimento a una baseline delle patch che non esiste più, di conseguenza le successive operazioni di applicazione di patch avranno esito negativo. In questo caso, torna alla pagina **Configurazioni** di Quick Setup, seleziona la configurazione Patch Manager e scegli **Operazioni**, **Modifica configurazione**. Il nome della baseline delle patch eliminata viene evidenziato ed è necessario selezionare una nuova baseline delle patch per il sistema operativo interessato.
+ Quando si crea una regola di approvazione con valori `Classification` e `Severity` multipli, le patch vengono approvate in base agli attributi disponibili. I pacchetti con entrambi gli attributi `Classification` e `Severity` corrisponderanno ai valori della baseline selezionati per entrambi i campi. I pacchetti dotati solo di attributi `Classification` vengono confrontati solo con i valori `Classification` della baseline selezionati. I requisiti di gravità indicati nella stessa regola vengono ignorati per i pacchetti che non dispongono di attributi `Severity`.
Per informazioni sulla creazione di una baseline delle patch, consulta [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md) e [Tutorial: applicare una patch a un ambiente server utilizzando il AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).
# Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate
I formati dei nomi dei pacchetti che è possibile aggiungere agli elenchi delle patch approvate e di quelle rifiutate dipendono dal tipo di sistema operativo a cui stai applicando le patch.
## Formati dei nomi dei pacchetti per sistemi operativi Linux
I formati che è possibile specificare per le patch approvate e rifiutate della baseline delle patch variano in base al tipo di sistema operativo Linux. Più precisamente, i formati supportati dipendono dal programma di gestione dei pacchetti utilizzati dal tipo di sistema operativo Linux.
**Topics**
+ [Amazon Linux 2, Amazon Linux 2023, Oracle Linux e Red Hat Enterprise Linux (RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server e Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)
### Amazon Linux 2, Amazon Linux 2023, Oracle Linux e Red Hat Enterprise Linux (RHEL)
**Gestore dei pacchetti**: YUM, ad eccezione di Amazon Linux 2023 e RHEL 8, che utilizzano DNF come gestore di pacchetti.
**Patch approvate**: per le patch approvate, è possibile specificare uno qualsiasi dei seguenti:
+ Bugzilla IDs, nel formato `1234567` (Il sistema elabora stringhe di soli numeri come Bugzilla). IDs
+ IDsCVE, nel formato `CVE-2018-1234567`
+ Avviso IDs, in formati come e `RHSA-2017:0864` `ALAS-2018-123`
+ Nomi di pacchetto creati utilizzando uno o più componenti disponibili per la denominazione dei pacchetti. A titolo illustrativo, per il pacchetto denominato `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, i componenti sono i seguenti:
+ `name`: `dbus`
+ `architecture`: `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
Sono supportati i nomi di pacchetto con le seguenti costruzioni:
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
Alcuni esempi:
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ Supportiamo anche i componenti dei nomi dei pacchetti con un singolo carattere jolly nei formati precedenti, come i seguenti:
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
**Patch rifiutate**: per le patch rifiutate, è possibile specificare uno qualsiasi dei seguenti:
+ Nomi di pacchetto creati utilizzando uno o più componenti disponibili per la denominazione dei pacchetti. A titolo illustrativo, per il pacchetto denominato `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, i componenti sono i seguenti:
+ `name`: `dbus`
+ `architecture`; `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
Sono supportati i nomi di pacchetto con le seguenti costruzioni:
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
Alcuni esempi:
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ Supportiamo anche i componenti dei nomi dei pacchetti con un singolo carattere jolly nei formati precedenti, come i seguenti:
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
### Debian Server e Ubuntu Server
**Programma di gestione dei pacchetti**: APT
**Patch approvate** e **patch rifiutate**: per le patch approvate e rifiutate, specifica quanto segue:
+ Nomi dei pacchetti, nel formato `ExamplePkg33`
**Nota**
Per gli elenchi di Debian Server e Ubuntu Server, non includere elementi come architettura o versioni. Ad esempio, è possibile specificare il nome del pacchetto `ExamplePkg33` per includere quanto riportato di seguito in un elenco delle patch:
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`
### SUSE Linux Enterprise Server (SLES)
**Programma di gestione dei pacchetti**: Zypper
**Patch approvate** e **patch rifiutate**: per gli elenchi delle patch approvate e rifiutate, è possibile specificare uno qualsiasi dei seguenti:
+ Nomi completi dei pacchetti, in formati quali:
+ `SUSE-SLE-Example-Package-15-2023-123`
+ `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ Nomi dei pacchetti con un singolo carattere jolly, come:
+ `SUSE-SLE-Example-Package-15-2023-*`
+ `example-pkg-2023.15.4-46.17.1.*.rpm`
## Formati dei nomi dei pacchetti per macOS
**Gestori di pacchetti supportati**: aggiornamento software, installatore, Brew, Brew Cask
**Patch approvate** e **patch rifiutate**: per gli elenchi delle patch approvate e rifiutate, è possibile specificare i nomi completi dei pacchetti, in formati come:
+ `XProtectPlistConfigData`
+ `MRTConfigData`
I caratteri jolly non sono supportati dagli elenchi delle patch approvate e rifiutate per macOS.
## Formati dei nomi dei pacchetti per sistemi operativi Windows
Per i sistemi operativi Windows, specificare le patch utilizzando Microsoft Knowledge Base IDs e Microsoft Security Bulletin, ad esempio IDs:
```
KB2032276,KB2124261,MS10-048
```
# Gruppi di patch
**Nota**
I gruppi di patch non vengono utilizzati nelle operazioni di applicazione di patch basate su *policy di patch*. Per informazioni sull'utilizzo delle policy di patch, consulta [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
La funzionalità dei gruppi di patch non è supportata nella console per le coppie account-Regione, che non utilizzavano già i gruppi di patch prima del rilascio del supporto per le policy di patch il 22 dicembre 2022. La funzionalità dei gruppi di patch è ancora disponibile nelle coppie account-Regione, che hanno iniziato a utilizzare i gruppi di patch prima di questa data.
È possibile utilizzare un *gruppo di patch* per associare i nodi gestiti a una patch di base specifica, Patch Manager, uno strumento di AWS Systems Manager. I gruppi di patch garantiscono che vengano distribuite le patch appropriate, in base alle regole delle basi di patch associate, al set di nodi corretto. Inoltre aiutano a non distribuire le patch non adeguatamente verificate. Ad esempio, è possibile creare gruppi di patch per ambienti diversi (di sviluppo, di test e di produzione) e registrare ciascun gruppo con una base di patch appropriata.
Quando si esegue `AWS-RunPatchBaseline`, è possibile specificare come target i nodi gestiti utilizzando il relativo ID nodo o i tag. SSM Agent e Patch Manager quindi valutano quale patch di base utilizzare in base al valore del gruppo di patch aggiunto al nodo gestito.
## Utilizzo dei tag per definire i gruppi di patch
Crea un gruppo di patch utilizzando tag applicati sia alle tue istanze Amazon Elastic Compute Cloud (Amazon EC2) sia ai nodi non EC2 in un ambiente [ibrido e multi-cloud](operating-systems-and-machine-types.md#supported-machine-types). Notare i seguenti dettagli relativi all'utilizzo dei tag per i gruppi di patch:
+
Un gruppo di patch deve essere definito utilizzando la chiave tag `Patch Group` o `PatchGroup` applicato ai nodi gestiti. Quando si registra un gruppo di patch per una patch baseline, tutti *i valori* identici specificati per queste due chiavi vengono interpretati come parte dello stesso gruppo. Ad esempio, supponiamo di aver taggato cinque nodi con la prima delle seguenti coppie chiave-valore e cinque con la seconda:
+ `key=PatchGroup,value=DEV`
+ `key=Patch Group,value=DEV`
Il Patch Manager comando per creare una linea di base combina questi 10 nodi gestiti in un unico gruppo in base al valore. `DEV` L'AWS CLIequivalente del comando per creare una linea di base di patch per i gruppi di patch è il seguente:
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group DEV
```
La combinazione di valori di chiavi diverse in un'unica destinazione è esclusiva di questo Patch Manager comando per la creazione di un nuovo gruppo di patch e non è supportata da altre azioni API. Ad esempio, se esegui [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)azioni utilizzando `Patch Group` chiavi `PatchGroup` e con gli stessi valori, hai come target due set di nodi completamente diversi:
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:PatchGroup,Values=DEV"
```
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:Patch Group,Values=DEV"
```
+ Esistono dei limiti al targeting basato su tag. Ogni array di obiettivi per `SendCommand` può contenere un massimo di cinque coppie chiave-valore.
+ Ti consigliamo di scegliere solo una di queste convenzioni relative alle chiavi dei tag, `PatchGroup` (senza spazio) o `Patch Group` (con uno spazio). Se sono presenti [tag consentiti nei metadati dell'istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), è necessario utilizzare `PatchGroup` (senza spazio).
+ La chiave prevede la distinzione fra lettere maiuscole e minuscole. È possibile specificare un qualsiasi valore per identificare e indirizzare le risorse in quel gruppo, ad esempio "server web" o "US-EAST-PROD", ma la chiave deve essere o .
Dopo avere creato un gruppo di patch e i nodi gestiti dei tag, è possibile registrare il gruppo di patch in una patch di base. La registrazione del gruppo di patch con una patch di base garantisce che i nodi all'interno del gruppo di patch utilizzino le regole definite nella base di patch associata.
Per ulteriori informazioni su come creare un gruppo di patch e associarlo a una base di patch, consulta [Creazione e gestione di gruppi di patch](patch-manager-tag-a-patch-group.md) e [Aggiungere un gruppo di patch a una base di patch](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline).
Per visualizzare un esempio di creazione di una base di patch e di gruppi di patch con AWS Command Line Interface (AWS CLI), consulta [Tutorial: applicare una patch a un ambiente server utilizzando il AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). Per ulteriori informazioni sui tag Amazon EC2, consulta la sezione relativa al [Tagging delle risorse Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) nella *Guida per l'utente di Amazon EC2*.
## Come funziona
Quando il sistema esegue l'attività di applicazione di una patch di base a un nodo gestito, SSM Agent verifica che per il nodo sia definito un valore del gruppo di patch. Se il nodo è assegnato a un gruppo di patch, Patch Manager verifica quale patch di base è stata registrata per il gruppo. Se per il gruppo viene rilevata una base di patch, Patch Manager comunica a SSM Agent di utilizzare la base di patch associata. Se un nodo non è configurato per un gruppo di patch, Patch Manager comunica automaticamente a SSM Agent di utilizzare la patch di base di default attualmente configurata.
**Importante**
Un nodo gestito può trovarsi solo in un singolo gruppo di patch.
Un gruppo di patch può essere registrato con una sola base di patch per ciascun tipo di sistema operativo.
Per applicare il tag `Patch Group` (con uno spazio) a un'istanza di Amazon EC2, l’opzione **Consenti i tag nei metadati dell'istanza** non deve essere abilitata sull'istanza. Consenti i tag nei metadati di istanza impedisce ai nomi delle chiavi dei tag di contenere spazi. Se hai [tag consentiti nei metadati dell'istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), è necessario utilizzare la chiave di tag `PatchGroup` (senza spazio).
**Diagramma 1: esempio generale del flusso di elaborazione delle operazioni di applicazione di patch**
L'immagine seguente mostra un esempio generale dei processi eseguiti da Systems Manager quando invia un'attività Run Command al parco di server per applicare le patch utilizzando Patch Manager. Questi processi determinano quali patch di base utilizzare nelle operazioni di patch. (Un processo analogo viene utilizzato quando una finestra di manutenzione viene configurata per l'invio di un comando di applicazione patch utilizzando Patch Manager.)
L'intero processo è spiegato sotto l'illustrazione.
![\[Flusso di lavoro di Patch Manager per determinare quali baseline delle patch utilizzare durante l'esecuzione delle operazioni di applicazione.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
In questo esempio abbiamo tre gruppi di istanze EC2 di Windows Server con i seguenti tag applicati:
****
| Gruppo di istanze EC2 | Tag |
| --- | --- |
| Gruppo 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| Gruppo 2 | `key=OS,value=Windows` |
| Gruppo 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` |
Per questo esempio abbiamo anche le due basi di patch Windows Server seguenti:
****
| ID della base di confronto delle patch | Predefinita | Gruppo di patch associate |
| --- | --- | --- |
| `pb-0123456789abcdef0` | Sì | `Default` |
| `pb-9876543210abcdef0` | No | `DEV` |
Il processo generale per la scansione o l'installazione di patch con Run Command, uno strumento di AWS Systems Manager, e Patch Manager è il seguente:
1. **Inviare un comando per l'applicazione di patch**: utilizzare la console Systems Manager, SKD, AWS Command Line Interface, (AWS CLI) o AWS Tools for Windows PowerShell per inviare un'attività Run Command utilizzando il documento `AWS-RunPatchBaseline`. Il diagramma mostra un'attività Run Command per l'applicazione di patch alle istanze gestite specificando come target il tag `key=OS,value=Windows`.
1. **Determinazione della base di patch**: SSM Agent verifica i tag del gruppo di patch applicati all'istanza di EC2 e interroga Patch Manager per la base di patch corrispondente.
+ **Valore del gruppo di patch corrispondente associato alla base di patch:**
1. SSM Agent, installato nelle istanze EC2 nel gruppo 1, riceve il comando eseguito nella Fase 1 di avviare un'operazione di applicazione di patch. SSM Agent verifica che alle istanze EC2 sia applicato il valore di tag del gruppo di patch `DEV` e interroga Patch Manager per ottenere una base di patch associata.
1. Patch Manager verifica che alla base di patch `pb-9876543210abcdef0` sia associato il gruppo di patch `DEV` e invia una notifica a SSM Agent.
1. SSM Agent recupera uno snapshot della base di patch da Patch Manager in base alle regole di approvazione e alle eccezioni configurate in `pb-9876543210abcdef0` e procede con la fase successiva.
+ **Nessun tag del gruppo di patch aggiunto all'istanza:**
1. SSM Agent, installato nelle istanze EC2 nel gruppo 2, riceve il comando eseguito nella Fase 1 di avviare un'operazione di applicazione di patch. SSM Agent verifica che alle istanze EC2 non sia applicato il tag `Patch Group` e `PatchGroup`, di conseguenza, SSM Agent interroga Patch Manager per ottenere la patch di base Windows predefinita.
1. Patch Manager verifica che la base di patch predefinita Windows Server sia `pb-0123456789abcdef0` e notifica SSM Agent.
1. SSM Agent recupera uno snapshot della base di patch da Patch Manager in base alle regole di approvazione e alle eccezioni configurate nella base di patch predefinita `pb-0123456789abcdef0` e procede con la fase successiva.
+ **Nessun valore del gruppo di patch corrispondente associato a una base di patch:**
1. SSM Agent, installato nelle istanze EC2 nel gruppo 3, riceve il comando eseguito nella Fase 1 di avviare un'operazione di applicazione di patch. SSM Agent verifica che alle istanze EC2 sia applicato il valore di tag `QA` del gruppo di patch e interroga Patch Manager per ottenere una base di patch associata.
1. Patch Manager non trova una base di patch a cui sia associato il gruppo di patch `QA`.
1. Patch Manager comunica a SSM Agent di utilizzare la base di patch predefinita di Windows `pb-0123456789abcdef0`.
1. SSM Agent recupera uno snapshot della base di patch da Patch Manager in base alle regole di approvazione e alle eccezioni configurate nella base di patch predefinita `pb-0123456789abcdef0` e procede con la fase successiva.
1. **Scansione o installazione di patch**: dopo aver stabilito la base di patch appropriata da utilizzare, SSM Agent inizia a eseguire la scansione o l'installazione delle patch in base al valore dell'operazione specificato nella Fase 1. Per stabilire quali patch devono essere sottoposte a scansione o installate, vengono seguite le regole di approvazione e le eccezioni delle patch definite nella snapshot della base di patch fornita da Patch Manager.
**Ulteriori informazioni**
+ [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md)
# Applicazione di patch rilasciata da Microsoft in Windows Server
Utilizza le informazioni in questo argomento, in modo che potrai applicare patch alle applicazioni in Windows Server tramite Patch Manager, uno strumento di AWS Systems Manager.
**Applicazione di patch alle applicazioni Microsoft**
Il supporto per l'applicazione di patch per le applicazioni sui nodi gestiti da Windows Server è limitato alle applicazioni rilasciate da Microsoft.
**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.
**Baseline delle patch per applicare patch alle applicazioni rilasciate da Microsoft**
Per Windows Server, vengono fornite tre baseline delle patch predefinite. Le baseline delle patch `AWS-DefaultPatchBaseline` e `AWS-WindowsPredefinedPatchBaseline-OS` supportano solo gli aggiornamenti del sistema operativo Windows stesso. `AWS-DefaultPatchBaseline`Viene utilizzato come baseline delle patch di default per nodi gestiti Windows Server a meno che non si specifichi una baseline delle patch diversa. Le impostazioni di configurazione in queste due baseline delle patch sono le stesse. Il più recente dei due, `AWS-WindowsPredefinedPatchBaseline-OS`, è stato creato per distinguerlo dalla terza baseline delle patch predefinita per Windows Server. Quella baseline delle patch, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, può essere utilizzata per applicare patch sia nel sistema operativo Windows Server che nelle applicazioni supportate rilasciate da Microsoft.
È anche possibile creare una baseline delle patch personalizzata per aggiornare le applicazioni Microsoft su macchine Windows Server
**Supporto per le applicazioni di patch rilasciate da Microsoft nei server on-premises, nei dispositivi edge, nelle macchine virtuali e in altri nodi non EC2**
Per applicare patch alle applicazioni rilasciate da Microsoft nelle macchine virtuali (VM) e altri nodi gestiti non EC2, devi attivare il piano istanze avanzate. Viene addebitato un costo per l'utilizzo del piano istanze avanzate. **Tuttavia, non è previsto alcun costo aggiuntivo per le applicazioni di patch rilasciate da Microsoft sulle istanze Amazon Elastic Compute Cloud (Amazon EC2)**. Per ulteriori informazioni, consulta [Configurazione dei livelli di istanza](fleet-manager-configure-instance-tiers.md).
**Opzione di aggiornamento di Windows per “altri prodotti Microsoft”**
Affinché Patch Manager possa applicare patch alle applicazioni rilasciate da Microsoft sui tuoi nodi gestiti da Windows Server, l'opzione Windows Update**Inviami aggiornamenti per altri prodotti Microsoft quando aggiorno Windows** deve essere attivata sul nodo.
Per informazioni sull'abilitazione di questa opzione su un singolo nodo gestito, vedere [Aggiornare Office con Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) nel sito Web del Support Microsoft.
Per un parco istanze di nodi gestiti che esegue Windows Server 2016 e versioni successive, è possibile utilizzare un oggetto Policy di gruppo (GPO) per attivare l'impostazione. Nell'Editor Gestione Policy di gruppo, accedere a **Configurazione computer**, **Modelli amministrativi**, **Componenti di Windows**, **Aggiornamenti di Windows** e scegliere **Installare gli aggiornamenti per altri prodotti Microsoft**. Si consiglia inoltre di configurare il GPO con parametri aggiuntivi che impediscano aggiornamenti automatici non pianificati e riavvii al di fuori di Patch Manager. Per ulteriori informazioni, consulta [Configurazione degli aggiornamenti automatici in un ambiente non Active Directory](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499) sul sito Web della documentazione tecnica Microsoft.
Per un parco istanze di nodi gestiti che esegue Windows Server 2012 o 2012 R2, è possibile attivare l'opzione utilizzando uno script, come descritto in [Attivazione e disattivazione di Microsoft Update in Windows 7 tramite Script](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) nel sito web Microsoft Docs Blog. Ad esempio, è possibile eseguire le operazioni seguenti:
1. Salvare lo script dal post del blog in un file.
1. Caricare il file in un bucket Amazon Simple Storage Service (Amazon S3) o in un'altra posizione accessibile.
1. UtilizzareRun Command, uno strumento in AWS Systems Manager, per eseguire lo script sui nodi gestiti utilizzando il documento Systems Manager (documento SSM) `AWS-RunPowerShellScript` con un comando simile al seguente.
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**Requisiti minimi dei parametri**
Per includere le applicazioni rilasciate da Microsoft nella baseline delle patch personalizzata, è necessario almeno specificare il prodotto a cui si desidera applicare le patch. Il comando seguente AWS Command Line Interface (AWS CLI) illustra i requisiti minimi per applicare patch a un prodotto, come Microsoft Office 2016.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
Se si specifica la famiglia di prodotti applicativi Microsoft, ogni prodotto specificato deve essere un membro supportato della famiglia di prodotti selezionata. Ad esempio, per l'applicazione di patch al prodotto "Active Directory Rights Management Services Client 2.0", è necessario specificare la famiglia di prodotti come "Active Directory" e non, ad esempio "Office" o "SQL Server". Il AWS CLI comando seguente mostra un abbinamento corrispondente tra famiglia di prodotti e prodotto.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
**Nota**
Se viene visualizzato un messaggio di errore relativo a un prodotto e una famiglia non corrispondenti, consulta [Problema: coppie di prodotti non corrispondenti family/product](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch) per assistenza nella risoluzione del problema.
# Utilizzo di Kernel Live Patching su nodi gestiti Amazon Linux 2
Kernel Live Patching per Amazon Linux 2 ti consente di applicare patch di vulnerabilità della sicurezza e di bug critici a un kernel Linux in esecuzione, senza riavvii o interruzioni delle applicazioni in esecuzione. Questa procedura ti permette una maggiore disponibilità di servizi e applicazioni, mantenendo al contempo la sicurezza e l'aggiornamento dell'infrastruttura. Kernel Live Patching è supportato nelle istanze Amazon EC2, nei dispositivi core AWS IoT Greengrass e nelle [macchine virtuali on-premises](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html) che utilizzano Amazon Linux 2.
[Per informazioni generali su questo Kernel Live Patching argomento, AL2 consulta Kernel Live Patching la *Amazon Linux 2 User Guide*.](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html)
Dopo aver attivato Kernel Live Patching su un nodo gestito Amazon Linux 2, è possibile usare Patch Manager, uno strumento di AWS Systems Manager, per applicare patch live del kernel al nodo gestito. L'utilizzo di Patch Manager per applicare gli aggiornamenti è un'alternativa ai flussi di lavoro yum nel nodo.
**Prima di iniziare**
Per utilizzare Patch Manager per applicare patch live del kernel ai nodi gestiti di Amazon Linux 2, assicurati che i nodi siano basati sull'architettura e sulla versione del kernel corrette. Per informazioni, consulta [Configurazioni e prerequisiti supportati](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) nelle istanze *Guida per l'utente di Amazon EC2*.
**Topics**
+ [Kernel Live Patching utilizza Patch Manager](#about-klp)
+ [Come Kernel Live Patching utilizza Patch Manager](#how-klp-works)
+ [Attivazione di Kernel Live Patching tramite Run Command](enable-klp.md)
+ [Applicazione delle patch live del kernel utilizzando Run Command](install-klp.md)
+ [Disattivazione di Kernel Live Patching tramite Run Command](disable-klp.md)
## Kernel Live Patching utilizza Patch Manager
Aggiornamento della versione del kernel
Non è necessario riavviare un nodo gestito dopo aver applicato un aggiornamento della patch live del kernel. Tuttavia, AWS fornisce patch live del kernel per una versione del kernel di Amazon Linux 2 per un massimo di tre mesi dopo il suo rilascio. Dopo il periodo di tre mesi, è necessario eseguire l'aggiornamento a una versione del kernel successiva per continuare a ricevere patch live del kernel. Ti consigliamo di utilizzare una finestra di manutenzione per pianificare un riavvio del nodo almeno una volta ogni tre mesi per richiedere l'aggiornamento della versione del kernel.
Disinstallazione delle patch live del kernel
Le patch live del kernel non possono essere disinstallate utilizzando Patch Manager. È possibile invece disabilitare Kernel Live Patching, che rimuove i pacchetti RPM per le patch live del kernel applicate. Per ulteriori informazioni, consulta [Disattivazione di Kernel Live Patching tramite Run Command](disable-klp.md).
Conformità del kernel
In alcuni casi, l'installazione di tutte le correzioni CVE dalle patch live per la versione corrente del kernel può far sì che il kernel sia stesso stato di conformità di una versione più recente. Quando ciò accade, la versione più recente viene segnalata come `Installed` e il nodo gestito restituito come `Compliant`. Tuttavia, non viene restituita l'ora di installazione per la versione più recente del kernel.
Una patch live del kernel, più CVEs
Se una patch live del kernel si rivolge a più CVEs patch e queste CVEs hanno diversi valori di classificazione e gravità, per la patch CVEs viene riportata solo la classificazione e la gravità più elevate tra le altre.
Nella parte restante di questa sezione viene descritto come utilizzare Patch Manager per applicare patch live del kernel ai nodi gestiti che soddisfano questi requisiti.
## Come Kernel Live Patching utilizza Patch Manager
AWS rilascia due tipi di patch live del kernel per Amazon Linux 2: aggiornamenti di sicurezza e correzioni di bug. Per applicare questi tipi di patch, utilizzare un documento della baseline delle patch destinato solo alle classificazioni e alle severità elencate nella tabella seguente.
| Classificazione | Gravità |
| --- | --- |
| Security | Critical, Important |
| Bugfix | All |
È possibile creare una baseline delle patch personalizzata destinata solo a queste patch oppure utilizzare la baseline delle patch `AWS-AmazonLinux2DefaultPatchBaseline` predefinita. In altre parole, è possibile utilizzare `AWS-AmazonLinux2DefaultPatchBaseline` con i nodi gestiti Amazon Linux 2 in cui è abilitato Kernel Live Patching per applicare gli aggiornamenti live del kernel.
**Nota**
La configurazione `AWS-AmazonLinux2DefaultPatchBaseline` specifica un periodo di attesa di 7 giorni dopo il rilascio o l'ultimo aggiornamento di una patch prima dell'installazione automatica. Se non si desidera attendere 7 giorni per l'approvazione automatica delle patch live del kernel, è possibile creare e utilizzare una baseline delle patch personalizzata. Nella baseline delle patch, è possibile specificare nessun periodo di attesa per l'approvazione automatica o specificarne uno più breve o più lungo. Per ulteriori informazioni, consulta [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md).
Ti consigliamo la seguente strategia per applicare patch ai nodi gestiti con aggiornamenti live del kernel:
1. Attiva Kernel Live Patching sui nodi gestiti Amazon Linux 2.
1. Utilizza Run Command uno strumento per eseguire un'`Scan`operazione sui tuoi nodi gestiti utilizzando la patch di base predefinita `AWS-AmazonLinux2DefaultPatchBaseline` o personalizzata che si rivolge anche solo agli `Security` aggiornamenti con gravità classificata come `Critical` e`Important`, e la gravità di. AWS Systems Manager`Bugfix` `All`
1. Utilizza Compliance, uno strumento in AWS Systems Manager grado di verificare se viene segnalata la non conformità per l'applicazione di patch per uno qualsiasi dei nodi gestiti sottoposti a scansione. In caso affermativo, visualizza i dettagli della conformità del nodo per determinare se alcune patch live del kernel mancano dal nodo gestito.
1. Per installare patch live del kernel mancanti, utilizza Run Command con la stessa baseline delle patch specificata in precedenza, ma questa volta esegui un'operazione `Install` invece di un'operazione `Scan`.
Poiché le patch live del kernel vengono installate senza la necessità di riavviare, è possibile scegliere l'opzione di riavvio `NoReboot` per questa operazione.
**Nota**
È comunque possibile riavviare il nodo gestito se necessario per altri tipi di patch installati nel nodo o se vuoi eseguire l'aggiornamento a un kernel più recente. In questi casi, scegli invece l'opzione di riavvio `RebootIfNeeded`.
1. Torna a Conformità per verificare che le patch live del kernel siano state installate.
# Attivazione di Kernel Live Patching tramite Run Command
Per attivare Kernel Live Patching, è possibile eseguire `yum` sui tuoi nodi gestiti o usare Run Command e un documento di Systems Manager personalizzato (documento SSM) creato dall'utente.
Per informazioni sull'attivazione di Kernel Live Patching eseguendo i comandi `yum` direttamente sul nodo gestito, vedi [AbilitazioneKernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) nelle istanze *Guida per l'utente di Amazon EC2*.
**Nota**
Quando si attiva Kernel Live Patching, se il kernel già in esecuzione sul nodo gestito è *precedente* rispetto a `kernel-4.14.165-131.185.amzn2.x86_64` (la versione minima supportata), il processo installa l'ultima versione disponibile del kernel e riavvia il nodo gestito. Se il nodo sta già eseguendo `kernel-4.14.165-131.185.amzn2.x86_64` o versione successiva, il processo non installa una versione più recente e non riavvia il nodo.
**Per attivare Kernel Live Patching tramite Run Command(console)**
1. Aprire la console AWS Systems Manager all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Run Command**.
1. Seleziona **Run command (Esegui comando)**.
1. Nell'elenco **Documento di comando**, scegliere il documento SSM personalizzato`AWS-ConfigureKernelLivePatching`.
1. Nella sezione **Parametri di comando** specifica se vuoi che i nodi gestiti vengano riavviati come parte di questa operazione.
1. Per informazioni sull'utilizzo dei controlli rimanenti in questa pagina, consulta [Esecuzione di comandi dalla console](running-commands-console.md).
1. Seleziona **Esegui**.
**Per attivare Kernel Live Patching (AWS CLI)**
+ Esegui il comando seguente sul computer locale.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--parameters "EnableOrDisable=Enable" \
--targets "Key=instanceids,Values=instance-id"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--parameters "EnableOrDisable=Enable" ^
--targets "Key=instanceids,Values=instance-id"
```
------
Sostituisci *instance-id* con l'ID del nodo gestito Amazon Linux 2 in cui vuoi abilitare la caratteristica, come ad esempio i-02573cafcfEXAMPLE. Per disabilitare la caratteristica su più nodi gestiti puoi utilizzare uno dei seguenti formati.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Per informazioni sulle altre opzioni che puoi utilizzare con il comando, consulta [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in *Riferimento ai comandi della AWS CLI*.
# Applicazione delle patch live del kernel utilizzando Run Command
Per applicare patch live del kernel puoi eseguire comandi `yum` sui nodi gestiti o utilizzare Run Command e il documento SSM`AWS-RunPatchBaseline`.
Per informazioni sull'applicazione delle patch live del kernel eseguendo comandi `yum` direttamente sul nodo gestito, consulta [Applicazione delle patch live del kernel](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply) nella *Guida per l'utente di Amazon EC2*.
**Per applicare patch live del kernel utilizzando Run Command (console)**
1. Aprire la console AWS Systems Manager all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Run Command**.
1. Seleziona **Run command (Esegui comando)**.
1. Nell'elenco **Command document (Documento comando)**, scegliere il documento SSM`AWS-RunPatchBaseline`.
1. Nella sezione **Parametri di comando** esegui una delle operazioni seguenti:
+ Se devi verificare se sono disponibili nuove patch live del kernel, per **Operazione** scegli `Scan`. Per **Opzione di riavvio**, se non vuoi che i nodi gestiti vengano riavviati dopo questa operazione, scegli `NoReboot`. Al termine dell'operazione, puoi verificare la presenza di nuove patch e lo stato di conformità in Conformità.
+ Se hai già verificato la conformità delle patch e vuoi applicare le patch live del kernel disponibili, per **Operazione** scegli `Install`. Per **Opzione di riavvio**, se non desideri che i nodi gestiti vengano riavviati dopo questa operazione, scegli `NoReboot`.
1. Per informazioni sull'utilizzo dei controlli rimanenti in questa pagina, consulta [Esecuzione di comandi dalla console](running-commands-console.md).
1. Seleziona **Esegui**.
**Per applicare patch live del kernel utilizzando Run Command (AWS CLI)**
1. Per eseguire un'operazione `Scan` prima di controllare i risultati in Conformità , esegui il comando seguente dal computer locale.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
```
------
Per informazioni sulle altre opzioni che puoi utilizzare con il comando, consulta [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in *Riferimento ai comandi della AWS CLI*.
1. Per eseguire un'operazione `Install` dopo aver verificato i risultati in Conformità , esegui il comando seguente dal computer locale.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
```
------
In entrambi i comandi precedenti, sostituisci *instance-id* con l'ID del nodo gestito Amazon Linux 2 su cui vuoi applicare le patch live del kernel, ad esempio i-02573cafcfEXAMPLE. Per disabilitare la caratteristica su più nodi gestiti puoi utilizzare uno dei seguenti formati.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Per informazioni sulle altre opzioni che puoi utilizzare con questi comandi, consulta [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in *Riferimento ai comandi della AWS CLI*.
# Disattivazione di Kernel Live Patching tramite Run Command
Per abilitare Kernel Live Patching puoi eseguire comandi `yum` sui nodi gestiti o utilizzare Run Command e un documento SSM personalizzato `AWS-ConfigureKernelLivePatching`.
**Nota**
Se non è più necessario utilizzare Kernel Live Patching, puoi disabilitarla in qualsiasi momento. Nella maggior parte dei casi, la disattivazione della funzione non è necessaria.
Per informazioni sulla disattivazione di Kernel Live Patching eseguendo `yum` direttamente sul nodo gestito, consulta [AbilitazioneKernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable) nella *Guida per l'utente di Amazon EC2*.
**Nota**
Quando si disattiva Kernel Live Patching, il processo disinstalla il plugin Kernel Live Patching e quindi riavvia il nodo gestito.
**Per disattivare Kernel Live Patching tramite Run Command (console)**
1. Aprire la console AWS Systems Manager all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Run Command**.
1. Seleziona **Run command (Esegui comando)**.
1. Nell'elenco **Command document (Documento comando)**, scegliere il documento SSM `AWS-ConfigureKernelLivePatching`.
1. Nella sezione **Command parameters (Parametri di comando)** specificare i valori per i parametri necessari.
1. Per informazioni sull'utilizzo dei controlli rimanenti in questa pagina, consulta [Esecuzione di comandi dalla console](running-commands-console.md).
1. Seleziona **Esegui**.
**Per disattivare Kernel Live Patching (AWS CLI)**
+ Esegui un comando simile al seguente.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--targets "Key=instanceIds,Values=instance-id" \
--parameters "EnableOrDisable=Disable"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--targets "Key=instanceIds,Values=instance-id" ^
--parameters "EnableOrDisable=Disable"
```
------
Sostituisci *instance-id* con l'ID del nodo gestito Amazon Linux 2 in cui vuoi disabilitare la caratteristica, ad esempio i-02573cafcfEXAMPLE. Per disabilitare la caratteristica su più nodi gestiti puoi utilizzare uno dei seguenti formati.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Per informazioni sulle altre opzioni che puoi utilizzare con il comando, consulta [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in *Riferimento ai comandi della AWS CLI*.
# Utilizzo delle risorse di Patch Manager e della conformità tramite la console
Per utilizzare Patch Manager uno strumento AWS Systems Manager, completare le seguenti operazioni. Tali attività sono descritte in maggiore dettaglio più avanti in questa sezione.
1. Verifica che la patch di base AWS predefinita per ogni tipo di sistema operativo che utilizzi soddisfi le tue esigenze. In caso contrario, creare una baseline delle patch che definisca un set di patch standard per quel tipo di nodo gestito e impostarla come di default.
1. Organizzare i nodi gestiti in gruppi di patch utilizzando i tag Amazon Elastic Compute Cloud (Amazon EC2) (facoltativo, ma consigliato).
1. Esegui una delle seguenti operazioni:
+ (Consigliato) Configura una policy di patch in Quick Setup, uno strumento di Systems Manager, che consente di installare le patch mancanti in base alla pianificazione di un'intera organizzazione, un sottoinsieme di unità organizzative o di un singolo Account AWS. Per ulteriori informazioni, consulta [Configura l'applicazione di patch per le istanze in un'organizzazione utilizzando una policy di patch di Quick Setup](quick-setup-patch-manager.md).
+ Crea una finestra di manutenzione che utilizza il documento di Systems Manager (documento SSM) `AWS-RunPatchBaseline` in un tipo di attività Run Command. Per ulteriori informazioni, consulta [Tutorial: creazione di una finestra di manutenzione per l'applicazione di patch tramite console](maintenance-window-tutorial-patching.md).
+ Esegui manualmente `AWS-RunPatchBaseline` in un'operazione Run Command. Per ulteriori informazioni, consulta [Esecuzione di comandi dalla console](running-commands-console.md).
+ Applicare manualmente le patch ai nodi utilizzando la funzionalità on demand **Applica subito una patch**. Per ulteriori informazioni, consulta [Patching dei nodi gestiti on demand](patch-manager-patch-now-on-demand.md).
1. Monitorare l'applicazione di patch per verificare la conformità e analizzare gli errori.
**Topics**
+ [Creazione di una policy di patch](patch-manager-create-a-patch-policy.md)
+ [Visualizzazione dei riepiloghi del pannello di controllo delle patch](patch-manager-view-dashboard-summaries.md)
+ [Utilizzo dei report sulla conformità delle patch](patch-manager-compliance-reports.md)
+ [Patching dei nodi gestiti on demand](patch-manager-patch-now-on-demand.md)
+ [Apertura con le baseline delle patch](patch-manager-create-a-patch-baseline.md)
+ [Visualizzazione delle patch disponibili](patch-manager-view-available-patches.md)
+ [Creazione e gestione di gruppi di patch](patch-manager-tag-a-patch-group.md)
+ [Integrazione con Patch Manager AWS Security Hub CSPM](patch-manager-security-hub-integration.md)
# Creazione di una policy di patch
Una policy di patch è una configurazione che imposti tramite Quick Setup, uno strumento di AWS Systems Manager. Le policy di patch offrono un controllo più ampio e centralizzato sulle operazioni di applicazione di patch rispetto ad altri metodi precedenti. Una policy di patch definisce la pianificazione e la linea di base da utilizzare quando si applicano automaticamente le patch ai nodi e alle applicazioni.
Per ulteriori informazioni, consulta i seguenti argomenti:
+ [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md)
+ [Configura l'applicazione di patch per le istanze in un'organizzazione utilizzando una policy di patch di Quick Setup](quick-setup-patch-manager.md)
# Visualizzazione dei riepiloghi del pannello di controllo delle patch
La scheda **Dashboard** (Pannello di controllo) in Patch Manager ti consente di visualizzare un riepilogo nella console che è possibile utilizzare per monitorare le operazioni di applicazione di patch in una visualizzazione che raccoglie tutte le informazioni. Patch Manager è uno strumento di AWS Systems Manager. Sulla scheda **Dashboard** (Pannello di controllo) è possibile visualizzare le informazioni seguenti:
+ Uno snapshot del numero di nodi gestiti conformi e non conformi alle regole di applicazione di patch.
+ Uno snapshot dell'età dei risultati della conformità delle patch per i tuoi nodi gestiti.
+ Conteggio collegato del numero di nodi gestiti non conformi presenti per ciascuno dei motivi più comuni di non conformità.
+ Elenco collegato delle operazioni di applicazione di patch più recenti.
+ Elenco collegato delle attività ricorrenti di applicazione patch impostate.
**Visualizzazione dei riepiloghi del pannello di controllo delle patch**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Seleziona la scheda **Pannello di controllo**.
1. Scorrere fino alla sezione contenente i dati di riepilogo da visualizzare:
+ **Amazon EC2 instance management** (Gestione delle istanze Amazon EC2)
+ **Compliance summary** (Riepilogo della conformità)
+ **Noncompliance counts** (Conteggi delle non conformità)
+ **Compliance reports** (Report di conformità)
+ **Operazioni non basate su policy di patch**
+ **Operazioni ricorrenti non basate su policy di patch**
# Utilizzo dei report sulla conformità delle patch
Utilizza le informazioni nei seguenti argomenti per generare e utilizzare report di conformità delle patch in Patch Manager, uno strumento di AWS Systems Manager.
Le informazioni contenute negli argomenti seguenti sono valide 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 **Applica subito una patch** on demand
**Importante**
I report sulla conformità delle patch sono point-in-time istantanee generate solo da operazioni di patching riuscite. Ogni report contiene un orario di acquisizione che identifica quando è stato calcolato lo stato di conformità.
Se disponi di più tipi di operazioni per la scansione delle istanze al fine di verificarne la conformità delle patch, tieni presente che ogni scansione sovrascrive i dati di conformità delle patch delle scansioni precedenti. Di conseguenza, potresti ottenere risultati imprevisti nei dati di conformità delle patch. Per ulteriori informazioni, consulta [Identificazione dell'esecuzione che ha creato i dati di conformità delle patch](patch-manager-compliance-data-overwrites.md).
Per verificare la baseline delle patch utilizzata per generare le informazioni di conformità più recenti, accedi alla scheda **Report di conformità** in Patch Manager, individua la riga relativa al nodo gestito per il quale desideri ottenere informazioni, quindi scegli l'ID di base nella colonna **ID di base utilizzato**.
**Topics**
+ [Visualizzazione dei risultati di conformità delle patch](patch-manager-view-compliance-results.md)
+ [Generazione di report sulla conformità delle patch csv](patch-manager-store-compliance-results-in-s3.md)
+ [Correzione dei nodi gestiti non conformi con Patch Manager](patch-manager-noncompliant-nodes.md)
+ [Identificazione dell'esecuzione che ha creato i dati di conformità delle patch](patch-manager-compliance-data-overwrites.md)
# Visualizzazione dei risultati di conformità delle patch
Utilizza queste procedure per visualizzare le informazioni sulla conformità delle patch relative ai nodi gestiti.
Questa procedura si applica alle operazioni delle patch che utilizzano il documento `AWS-RunPatchBaseline`. Per informazioni sulla visualizzazione delle informazioni di conformità di patch per le relative operazioni che utilizzano il documento `AWS-RunPatchBaselineAssociation`, consulta [Identificazione di nodi gestiti non conformi](patch-manager-find-noncompliant-nodes.md).
**Nota**
Le operazioni di scansione delle patch Quick Setup e Explorer l'utilizzo del `AWS-RunPatchBaselineAssociation` documento. Quick Setupe Explorer sono entrambi strumenti in AWS Systems Manager.
**Identificare la soluzione di patch per un problema CVE specifico (Linux)**
Per molti sistemi operativi basati su Linux, i risultati della conformità delle patch indicano quali problemi di Bulletin Common Vulnerabilities and Exposure (CVE) vengono risolti con quali patch. Queste informazioni consentono di determinare con quale urgenza è necessario installare una patch mancante o non riuscita.
I dettagli di CVE sono inclusi per le versioni supportate dei seguenti tipi di sistema operativo:
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux
**Nota**
Per impostazione predefinita, CentOS Stream non fornisce informazioni CVE sugli aggiornamenti. È possibile, tuttavia, consentire questo supporto utilizzando repository di terze parti, come il repository Extra Packages for Enterprise Linux (EPEL) pubblicato da Fedora. Per informazioni, consulta [EPEL](https://fedoraproject.org/wiki/EPEL) sul Wiki di Fedora.
Attualmente, i valori dell'ID CVE vengono riportati solo per le patch con stato `Missing` o `Failed`.
Puoi anche aggiungere CVE IDs agli elenchi delle patch approvate o rifiutate nelle tue linee di base delle patch, a seconda della situazione e dei tuoi obiettivi di patch.
Per informazioni sull'utilizzo di elenchi di patch approvate e rifiutate, consulta i seguenti argomenti:
+ [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md)
+ [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 nei sistemi Linux](patch-manager-linux-rules.md)
+ [Come vengono installate le patch](patch-manager-installing-patches.md)
**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.
## Visualizzazione dei risultati della conformità delle patch
Utilizza le seguenti procedure per visualizzare i risultati di conformità delle patch nella console AWS Systems Manager .
**Nota**
Per informazioni sulla generazione dei report di conformità alle patch che vengono scaricati in un bucket Amazon Simple Storage Service (Amazon S3), consulta [Generazione di report sulla conformità delle patch csv](patch-manager-store-compliance-results-in-s3.md).
**Visualizzazione dei risultati della conformità delle patch**
1. Scegli una delle seguenti operazioni.
**Opzione 1** (consigliata): naviga da Patch Manager, uno strumento di AWS Systems Manager:
+ Nel pannello di navigazione, scegli **Patch Manager**.
+ Seleziona la scheda **Report di conformità**.
+ Nell'area **Dettagli sull'applicazione di patch**, scegli l'ID del nodo gestito per il quale desideri esaminare i risultati di conformità delle patch. Nodi che sono `stopped` o `terminated` non verranno visualizzati qui.
+ Vai nell'area **Dettagli** e, nell'elenco **Proprietà**, scegli **Patch**.
**Opzione 2**: naviga da Conformità, uno strumento di AWS Systems Manager:
+ Nel riquadro di navigazione, seleziona **Conformità**.
+ Per **Riepilogo risorse di conformità**, scegli un numero nella colonna per i tipi di risorse patch che si desidera esaminare, ad esempio **Risorse non conformi**.
+ Sotto, nell'elenco **Risorsa**, scegli l'ID del nodo gestito per il quale desideri esaminare i risultati di conformità delle patch.
+ Vai nell'area **Dettagli** e, nell'elenco **Proprietà**, scegli **Patch**.
**Opzione 3**: naviga da Fleet Manager, uno strumento di AWS Systems Manager.
+ Nel pannello di navigazione, scegli **Fleet Manager**.
+ Nell'area **Istanze gestite**, scegli l'ID del nodo gestito per il quale desideri esaminare i risultati di conformità delle patch.
+ Vai nell'area **Dettagli** e, nell'elenco **Proprietà**, scegli **Patch**.
1. (Facoltativo) Nella casella di ricerca (![\[The Search icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)), scegli tra i filtri disponibili.
Ad esempio, per Red Hat Enterprise Linux(RHEL), scegli tra le seguenti opzioni:
+ Name
+ Classificazione
+ Stato
+ Gravità
Per Windows Server, scegli tra le seguenti opzioni:
+ KB
+ Classificazione
+ Stato
+ Gravità
1. Scegli uno dei valori disponibili per il tipo di filtro scelto. Ad esempio, se hai scelto **Stato**, ora scegli uno stato di conformità come **InstalledPendingReboot****Fallito** o **Mancante**.
**Nota**
Attualmente, i valori dell'ID CVE vengono riportati solo per le patch con stato `Missing` o `Failed`.
1. A seconda dello stato di conformità del nodo gestito, è possibile scegliere l'azione da intraprendere per porre rimedio a eventuali nodi non conformi.
Ad esempio, è possibile scegliere di applicare immediatamente patch ai nodi gestiti non conformi. Per informazioni su come applicare patch su nodi gestiti on demand, consulta [Patching dei nodi gestiti on demand](patch-manager-patch-now-on-demand.md).
Per informazioni sui dati di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).
# Generazione di report sulla conformità delle patch csv
Puoi utilizzare la AWS Systems Manager console per generare report di conformità delle patch che vengono salvati come file.csv in un bucket Amazon Simple Storage Service (Amazon S3) di tua scelta. È possibile generare un singolo report su richiesta o specificare una pianificazione per la generazione automatica dei report.
I report possono essere generati per un singolo nodo gestito o per tutti i nodi gestiti nell'area selezionata. Account AWS Regione AWS Per un singolo nodo, un report contiene dettagli completi, incluse le patch relative alla non conformità IDs di un nodo. Per un report su tutti i nodi gestiti, vengono fornite solo le informazioni di riepilogo e i conteggi delle patch dei nodi non conformi.
Dopo aver generato un report, puoi utilizzare uno strumento come Amazon Quick per importare e analizzare i dati. Quick è un servizio di business intelligence (BI) che puoi utilizzare per esplorare e interpretare le informazioni in un ambiente visivo interattivo. Per ulteriori informazioni, consulta la [Amazon Quick User Guide](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html).
**Nota**
Quando si crea una baseline delle patch personalizzata, è possibile specificare un livello di gravità di conformità per le patch approvate da quella baseline delle patch, ad esempio `Critical` o `High`. Se lo stato delle patch approvate viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
È possibile anche specificare un argomento Amazon Simple Notification Service (Amazon SNS) da utilizzare per l'invio delle notifiche quando viene generato un report.
**Ruoli del servizio per la generazione di report sulla conformità delle patch**
La prima volta che generi un report, Systems Manager crea un ruolo di Automation denominato `AWS-SystemsManager-PatchSummaryExportRole` da utilizzare per il processo di esportazione a S3.
**Nota**
Se stai esportando dati di conformità in un bucket S3 crittografato, devi aggiornare la policy relativa alle AWS KMS chiavi associata per fornire le autorizzazioni necessarie per. `AWS-SystemsManager-PatchSummaryExportRole` Ad esempio, aggiungi un'autorizzazione simile a questa alla politica del tuo bucket S3: AWS KMS
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "role-arn"
}
```
Sostituisci *role-arn* con l'Amazon Resource Name (ARN) del file creato nel tuo account, nel formato. `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`
Per ulteriori informazioni, consulta [Policy delle chiavi in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.
La prima volta che si genera un rapporto in base a una pianificazione, Systems Manager crea un altro ruolo di servizio denominato`AWS-EventBridge-Start-SSMAutomationRole`, insieme al ruolo di servizio `AWS-SystemsManager-PatchSummaryExportRole` (se non è già stato creato) da utilizzare per il processo di esportazione. `AWS-EventBridge-Start-SSMAutomationRole`consente EventBridge ad Amazon di avviare un'automazione utilizzando il runbook [AWS- ExportPatchReportTo S3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).
Si consiglia di non tentare di modificare questi criteri e ruoli. In questo modo, la generazione del report sulla conformità delle patch potrebbe non riuscire. Per ulteriori informazioni, consulta [Risoluzione dei problemi relativi alla generazione del report sulla conformità delle patch](#patch-compliance-reports-troubleshooting).
**Topics**
+ [Cosa c'è in un report sulla conformità delle patch generato?](#patch-compliance-reports-to-s3-examples)
+ [Generazione di report sulla conformità delle patch per un singolo nodo](#patch-compliance-reports-to-s3-one-instance)
+ [Generazione di report sulla conformità delle patch per tutti i nodi gestiti](#patch-compliance-reports-to-s3-all-instances)
+ [Visualizzazione della cronologia dei rapporti sulla conformità delle patch](#patch-compliance-reporting-history)
+ [Visualizzazione delle pianificazioni di report sulla conformità delle patch](#patch-compliance-reporting-schedules)
+ [Risoluzione dei problemi relativi alla generazione del report sulla conformità delle patch](#patch-compliance-reports-troubleshooting)
## Cosa c'è in un report sulla conformità delle patch generato?
In questo argomento vengono fornite informazioni sui tipi di contenuto inclusi nei report di conformità delle patch generati e scaricati in un bucket S3 specificato.
### Formato report per un singolo nodo gestito
Un report generato per un singolo nodo gestito fornisce informazioni di riepilogo e dettagliate.
[Scaricare un report di esempio (singolo nodo)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)
Le informazioni di riepilogo per un singolo nodo gestito includono quanto segue:
+ Indice
+ ID istanza
+ Instance name (Nome dell'istanza)
+ IP istanza
+ Nome piattaforma
+ Versione della piattaforma
+ Versione SSM Agent
+ baseline delle patch
+ Gruppo di patch
+ Compliance status (Stato di conformità)
+ Gravità di conformità
+ Conteggio delle patch di gravità critica non conforme
+ Conteggio delle patch a gravità elevata non conforme
+ Conteggio delle patch di gravità media non conforme
+ Conteggio delle patch a bassa gravità non conforme
+ Conteggio delle patch di gravità delle informazioni non conforme
+ Conteggio delle patch di gravità non conforme non specificato
Le informazioni dettagliate per un singolo nodo gestito includono quanto segue:
+ Indice
+ ID istanza
+ Instance name (Nome dell'istanza)
+ Nome patch
+ ID KB ID/Patch
+ Stato della patch
+ Ora dell'ultimo report
+ Livelli di conformità
+ Gravità della patch
+ Classificazione di patch
+ ID CVE
+ baseline delle patch
+ URL di log
+ IP istanza
+ Nome piattaforma
+ Versione della piattaforma
+ Versione SSM Agent
**Nota**
Quando si crea una baseline delle patch personalizzata, è possibile specificare un livello di gravità di conformità per le patch approvate da quella baseline delle patch, ad esempio `Critical` o `High`. Se lo stato delle patch approvate viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
### Formato report per tutti i nodi gestiti
Un report generato per tutti i nodi gestiti fornisce solo informazioni di riepilogo.
[Scarica un report di esempio (tutti i nodi gestiti)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)
Le informazioni di riepilogo per tutti i nodi gestiti includono:
+ Indice
+ ID istanza
+ Instance name (Nome dell'istanza)
+ IP istanza
+ Nome piattaforma
+ Versione della piattaforma
+ Versione SSM Agent
+ baseline delle patch
+ Gruppo di patch
+ Compliance status (Stato di conformità)
+ Gravità di conformità
+ Conteggio delle patch di gravità critica non conforme
+ Conteggio delle patch a gravità elevata non conforme
+ Conteggio delle patch di gravità media non conforme
+ Conteggio delle patch a bassa gravità non conforme
+ Conteggio delle patch di gravità delle informazioni non conforme
+ Conteggio delle patch di gravità non conforme non specificato
## Generazione di report sulla conformità delle patch per un singolo nodo
Utilizzare la procedura seguente per generare un report di riepilogo delle patch per un singolo nodo nel tuo Account AWS. Il rapporto per un singolo nodo gestito fornisce dettagli su ogni patch non conforme, inclusi i nomi delle patch e IDs.
**Per generare report sulla conformità delle patch per un singolo nodo gestito**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Seleziona la scheda **Report di conformità**.
1. Scegli il pulsante relativo alla riga del nodo gestito per il quale generare un report e quindi fai clic su **Visualizza i dettagli**.
1. Sulla sezione **Pagina di riepilogo patch**, scegli **Esporta in S3**.
1. Per **Nome del report**, immetti un nome per semplificare l'identificazione del report in un secondo momento.
1. Per **Frequenza di report**, scegli una delle opzioni seguenti:
+ **Su richiesta**: consente di creare un report una tantum. Passa alla fase 9.
+ **In una programmazione**: specifica una pianificazione ricorrente per la generazione automatica dei report. Prosegui alla fase 8.
1. Per **Tipo di pianificazione**, specifica un'espressione della frequenza, ad esempio ogni 3 giorni, o fornire un'espressione cron per impostare la frequenza del report.
Per informazioni sulle espressioni Cron, consulta [Riferimento: espressioni Cron e della frequenza per Systems Manager](reference-cron-and-rate-expressions.md).
1. Per **Nome bucket**, seleziona il nome di un bucket S3 in cui memorizzare i file di report CSV.
**Importante**
Se lavori in un Regione AWS bucket lanciato dopo il 20 marzo 2019, devi selezionare un bucket S3 nella stessa regione. Le regioni lanciate dopo tale data sono state disattivate per impostazione predefinita. Per ulteriori informazioni e un elenco di queste regioni, consulta [Abilitazione di una regione](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in nella *Riferimenti generali di Amazon Web Services*.
1. (Facoltativo) Per inviare notifiche quando viene generato il report, espandi la sezione **Argomenti SNS** e scegli un Argomento Amazon SNS esistente da **SNS topic Amazon Resource Name (ARN)**.
1. Seleziona **Invia**.
Per informazioni sulla visualizzazione di una cronologia dei report generati, consulta [Visualizzazione della cronologia dei rapporti sulla conformità delle patch](#patch-compliance-reporting-history).
Per informazioni sulla visualizzazione dei dettagli delle pianificazioni di report create, consulta [Visualizzazione delle pianificazioni di report sulla conformità delle patch](#patch-compliance-reporting-schedules).
## Generazione di report sulla conformità delle patch per tutti i nodi gestiti
Utilizza la procedura seguente per generare un report di riepilogo delle patch per tutti i nodi gestiti in Account AWS. Il report per tutti i nodi gestiti indica quali nodi non sono conformi e il numero di patch non conformi. Non fornisce i nomi o altri identificatori delle patch. Per questi dettagli aggiuntivi, è possibile generare un report sulla conformità delle patch per un singolo nodo gestito. Per ulteriori informazioni, consulta la sezione [Generazione di report sulla conformità delle patch per un singolo nodo](#patch-compliance-reports-to-s3-one-instance) riportata in precedenza in questo argomento.
**Per generare report sulla conformità delle patch per tutti i nodi gestiti**
1. Apri la AWS Systems Manager console all'indirizzo. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Seleziona la scheda **Report di conformità**.
1. Scegli **Esportazione in S3**. (Non selezionare prima un ID nodo.)
1. Per **Nome del report**, immetti un nome per semplificare l'identificazione del report in un secondo momento.
1. Per **Frequenza di report**, scegli una delle opzioni seguenti:
+ **On demand** - Consente di creare un report una tantum. Passare alla fase 8.
+ **In un programma** - Specifica una pianificazione ricorrente per la generazione automatica dei report. Continuare con la fase 7.
1. Per **Tipo di pianificazione**, specifica un'espressione di frequenza, ad esempio ogni 3 giorni, o fornire un'espressione cron per impostare la frequenza del report.
Per informazioni sulle espressioni Cron, consulta [Riferimento: espressioni Cron e della frequenza per Systems Manager](reference-cron-and-rate-expressions.md).
1. Per **Nome bucket**, seleziona il nome di un bucket S3 in cui memorizzare i file di report CSV.
**Importante**
Se lavori in un Regione AWS bucket lanciato dopo il 20 marzo 2019, devi selezionare un bucket S3 nella stessa regione. Le regioni lanciate dopo tale data sono state disattivate per impostazione predefinita. Per ulteriori informazioni e un elenco di queste regioni, consulta [Abilitazione di una regione](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in nella *Riferimenti generali di Amazon Web Services*.
1. (Facoltativo) Per inviare notifiche quando viene generato il report, espandi la sezione **Argomenti SNS** e scegli un Argomento Amazon SNS esistente da **SNS topic Amazon Resource Name (ARN)**.
1. Seleziona **Invia**.
Per informazioni sulla visualizzazione di una cronologia dei report generati, consulta [Visualizzazione della cronologia dei rapporti sulla conformità delle patch](#patch-compliance-reporting-history).
Per informazioni sulla visualizzazione dei dettagli delle pianificazioni di report create, consulta [Visualizzazione delle pianificazioni di report sulla conformità delle patch](#patch-compliance-reporting-schedules).
## Visualizzazione della cronologia dei rapporti sulla conformità delle patch
Utilizza le informazioni contenute in questo argomento per visualizzare i dettagli sui report di conformità delle patch generati nel tuo. Account AWS
**Visualizzazione della cronologia dei rapporti sulla conformità delle patch**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Seleziona la scheda **Report di conformità**.
1. Scegliere **Visualizza tutte le esportazioni di S3** e quindi selezionare la scheda **Cronologia dell'esportazione**.
## Visualizzazione delle pianificazioni di report sulla conformità delle patch
Utilizza le informazioni contenute in questo argomento per visualizzare i dettagli sulle pianificazioni di segnalazione della conformità delle patch create nel tuo Account AWS.
**Visualizzazione della cronologia dei rapporti sulla conformità delle patch**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Seleziona la scheda **Report di conformità**.
1. Sceglie **Visualizza tutte le esportazioni di S3** e quindi selezionare la casella **Regole di report pianificati**.
## Risoluzione dei problemi relativi alla generazione del report sulla conformità delle patch
Utilizza le informazioni seguenti per risolvere i problemi relativi alla generazione del report di conformità patch in Patch Manager, uno strumento di AWS Systems Manager.
**Topics**
+ [Un messaggio segnala che la policy `AWS-SystemsManager-PatchManagerExportRolePolicy` è danneggiata](#patch-compliance-reports-troubleshooting-1)
+ [Dopo aver eliminato i ruoli o i criteri di conformità delle patch, i report pianificati non vengono generati correttamente](#patch-compliance-reports-troubleshooting-2)
### Un messaggio segnala che la policy `AWS-SystemsManager-PatchManagerExportRolePolicy` è danneggiata
**Problema**: viene visualizzato un messaggio di errore simile al seguente, indicando che `AWS-SystemsManager-PatchManagerExportRolePolicy` è danneggiato:
```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any
role that uses it, then try again. Systems Manager recreates the roles and policies
you have deleted.
```
+ **Soluzione**: utilizza la Patch Manager console o elimina AWS CLI i ruoli e le politiche interessati prima di generare un nuovo rapporto di conformità delle patch.
**Per eliminare la policy danneggiata utilizzando la console**
1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Esegui una delle seguenti operazioni:
**Report on demand** - Se il problema si è verificato durante la generazione di un report su richiesta una tantum, nella navigazione a sinistra selezionare **Policy**, cercare `AWS-SystemsManager-PatchManagerExportRolePolicy`, quindi eliminare la policy. Quindi, selezionare **Ruoli**, cercare `AWS-SystemsManager-PatchSummaryExportRole` ed eliminare il ruolo.
**Report pianificati** - Se il problema si è verificato durante la generazione di un report in base a una pianificazione, nella navigazione a sinistra seleziona **Policy**, cerca uno alla volta per `AWS-EventBridge-Start-SSMAutomationRolePolicy` e `AWS-SystemsManager-PatchManagerExportRolePolicy` ed elimina ogni policy. Quindi, selezionare **Ruoli**, cerca uno alla volta per `AWS-EventBridge-Start-SSMAutomationRole` e `AWS-SystemsManager-PatchSummaryExportRole` ed eliminare ogni ruolo.
**Per eliminare la politica danneggiata, utilizzare il AWS CLI**
*placeholder values*Sostituiscila con l'ID del tuo account.
+ Se il problema si è verificato durante la generazione di un report monouso su richiesta, esegui i seguenti comandi:
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
Se il problema si è verificato durante la generazione di un report monouso su richiesta, esegui i seguenti comandi:
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
```
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
Dopo aver completato una delle due procedure, segui i passaggi per generare o pianificare un nuovo report sulla conformità delle patch.
### Dopo aver eliminato i ruoli o i criteri di conformità delle patch, i report pianificati non vengono generati correttamente
**Problema**: la prima volta che si genera un report, Systems Manager crea un ruolo di servizio e una policy da utilizzare per il processo di esportazione (`AWS-SystemsManager-PatchSummaryExportRole` e `AWS-SystemsManager-PatchManagerExportRolePolicy`). La prima volta che si genera un report in base a una pianificazione, Systems Manager crea un altro ruolo di servizio e una policy (`AWS-EventBridge-Start-SSMAutomationRole` e `AWS-EventBridge-Start-SSMAutomationRolePolicy`). Questi consentono EventBridge ad Amazon di avviare un'automazione utilizzando il runbook [AWS- ExportPatchReportTo S3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).
Se elimini una di queste policy o di questi ruoli, le connessioni tra la pianificazione e il bucket S3 specificato e l'argomento Amazon SNS potrebbero andare perdute.
+ **Soluzione**: per risolvere questo problema, si consiglia di eliminare la pianificazione precedente e di creare una nuova pianificazione per sostituire quella che si verificava problemi.
# Correzione dei nodi gestiti non conformi con Patch Manager
Negli argomenti di questa sezione vengono fornite panoramiche su come identificare i nodi gestiti che non rispettano la conformità delle patch e su come rendere conformi i nodi.
**Topics**
+ [Identificazione di nodi gestiti non conformi](patch-manager-find-noncompliant-nodes.md)
+ [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md)
+ [Applicazione di patch a nodi gestiti non conformi](patch-manager-compliance-remediation.md)
# Identificazione di nodi gestiti non conformi
Out-of-compliance i nodi gestiti vengono identificati quando uno dei due AWS Systems Manager documenti (documenti SSM) viene eseguito. Questi documenti SSM fanno riferimento alla baseline delle patch idonea per ogni nodo gestito in Patch Manager, uno strumento di AWS Systems Manager. Essi valutano quindi lo stato della patch del nodo gestito e quindi rendono disponibili i risultati di conformità.
Esistono due documenti SSM utilizzati per identificare o aggiornare nodi gestiti non conformi: `AWS-RunPatchBaseline` e `AWS-RunPatchBaselineAssociation`. Ognuno di essi è utilizzato da processi diversi e i risultati di conformità sono disponibili attraverso diversi canali. La tabella seguente illustra le differenze tra questi documenti.
**Nota**
I dati sulla conformità delle patch Patch Manager possono essere inviati a AWS Security Hub CSPM. Security Hub CSPM offre una visione completa degli avvisi di sicurezza ad alta priorità e dello stato di conformità. Monitora anche lo stato di applicazione di patch del parco istanze. Per ulteriori informazioni, consulta [Integrazione con Patch Manager AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
| | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` |
| --- | --- | --- |
| Processi che utilizzano il documento | **Patch on demand** - È possibile eseguire la scansione o applicare patch sui nodi gestiti su richiesta utilizzando l'opzione **Applica patch ora**. Per informazioni, consulta [Patching dei nodi gestiti on demand](patch-manager-patch-now-on-demand.md). **Policy di patch per Quick Setup di Systems Manager**: è possibile creare una configurazione di applicazione di patch in Quick Setup, uno strumento di AWS Systems Manager, per eseguire la scansione o l'installazione delle patch mancanti in base a pianificazioni separate per un'intera organizzazione, un sottoinsieme di unità organizzative o un singolo Account AWS. Per informazioni, consulta [Configura l'applicazione di patch per le istanze in un'organizzazione utilizzando una policy di patch di Quick Setup](quick-setup-patch-manager.md). **Esegui un comando**: è possibile eseguire manualmente `AWS-RunPatchBaseline` in un'operazione di Run Command, uno strumento di AWS Systems Manager. Per informazioni, consulta [Esecuzione di comandi dalla console](running-commands-console.md). **Maintenance window (Finestra di manutenzione)** - È possibile creare una finestra di manutenzione che utilizza il documento SSM `AWS-RunPatchBaseline` in un tipo di attivitàRun Command. Per informazioni, consulta [Tutorial: creazione di una finestra di manutenzione per l'applicazione di patch tramite console](maintenance-window-tutorial-patching.md). | **Gestione host per Quick Setup di Systems Manager**: è possibile abilitare un'opzione di configurazione della gestione host in Quick Setup per eseguire ogni giorno la scansione delle istanze gestite e verificare la conformità delle patch. Per informazioni, consulta [Configura la gestione host Amazon EC2 tramite Quick Setup](quick-setup-host-management.md). **Systems Manager [Explorer](Explorer.md)**: se lo consentiteExplorer, lo strumento esegue regolarmente la scansione delle istanze gestite per verificare la conformità delle patch e riporta i risultati nella Explorer dashboard. AWS Systems Manager |
| Formato dei dati dei risultati della scansione delle patch | Dopo l'esecuzione di `AWS-RunPatchBaseline`, Patch Manager invia un oggetto `AWS:PatchSummary` a Inventario, uno strumento di AWS Systems Manager. Questo report viene generato solo dopo aver eseguito correttamente le operazioni di applicazione delle patch e include un orario di acquisizione che identifica quando è stato calcolato lo stato di conformità. | Dopo l'esecuzione di `AWS-RunPatchBaselineAssociation`, Patch Manager invia un oggetto `AWS:ComplianceItem` a Systems Manager Inventory |
| Visualizzazione di report di conformità delle patch nella console | È possibile visualizzare le informazioni sulla conformità delle patch per i processi che utilizzano `AWS-RunPatchBaseline` in [Conformità della configurazione di Systems Manager](systems-manager-compliance.md) e [Utilizzo dei nodi gestiti](fleet-manager-managed-nodes.md). Per ulteriori informazioni, consulta [Visualizzazione dei risultati di conformità delle patch](patch-manager-view-compliance-results.md). | Quando si utilizza Quick Setup per eseguire la scansione delle istanze gestite per verificare la conformità delle patch, è possibile visualizzare il report di conformità in [Systems ManagerFleet Manager](fleet-manager.md). Nella console Fleet Manager, scegli l'ID del nodo gestito. Nel menu **Generale**, scegli **Conformità alla configurazione**. Quando si utilizza Explorer per eseguire la scansione delle istanze gestite per verificare la conformità delle patch, è possibile visualizzare il report di conformità sia in Explorerche [Systems ManagerOpsCenter](OpsCenter.md). |
| AWS CLI comandi per la visualizzazione dei risultati di conformità delle patch | Per i processi che utilizzano`AWS-RunPatchBaseline`, è possibile utilizzare i seguenti AWS CLI comandi per visualizzare informazioni di riepilogo sulle patch su un nodo gestito. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | Per i processi che utilizzano`AWS-RunPatchBaselineAssociation`, è possibile utilizzare il AWS CLI comando seguente per visualizzare informazioni di riepilogo sulle patch su un'istanza. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) |
| Informazioni sull'applicazione di patch | Per i processi che utilizzano `AWS-RunPatchBaseline`, si specifica se si desidera che l'operazione esegua solo un'operazione `Scan` o un'operazione `Scan and install`. Se il tuo obiettivo è identificare i nodi gestiti non conformi e non correggerli, esegui solo un'operazione `Scan`. | I processi Quick Setup e Explorer, che utilizzano AWS-RunPatchBaselineAssociation, eseguono solo un'operazione Scan. |
| Ulteriori informazioni | [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) |
Per informazioni sui vari stati di conformità delle patch che potrebbero essere riportati, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md)
Per informazioni sulla correzione dei nodi gestiti che non rispettano la conformità delle patch, consulta [Applicazione di patch a nodi gestiti non conformi](patch-manager-compliance-remediation.md).
# Valori dello stato di conformità delle patch
Le informazioni sulle patch per un nodo gestito includono un rapporto sullo stato di ogni singola patch.
**Suggerimento**
Se desideri assegnare uno stato di conformità della patch specifico a un nodo gestito, puoi utilizzare il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface (AWS CLI) o l'operazione [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API. L'assegnazione dello stato di conformità non è supportata nella console.
Utilizza le informazioni riportate nelle tabelle seguenti per riuscire a identificare i motivi per cui un nodo gestito potrebbe non essere conforme alle patch.
## Valori di conformità delle patch per Debian Server e Ubuntu Server
Per Debian Server e Ubuntu Server, le regole per la classificazione dei pacchetti nei vari stati di conformità sono descritte nella seguente tabella.
**Nota**
Tieni presente quanto segue, quando valuti i valori dello stato `INSTALLED`, `INSTALLED_OTHER` e `MISSING`: se non selezioni la casella di controllo **Includi aggiornamenti non di sicurezza** durante la creazione o l'aggiornamento di una baseline delle patch, le versioni patch candidate sono limitate alle patch 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`)
`debian-security` (Debian Server)
Quando si seleziona l'opzione **Includi aggiornamenti non correlati alla sicurezza**, vengono considerate anche le patch di altri repository.
| Stato della patch | Description | Compliance status (Stato di conformità) |
| --- | --- | --- |
| **`INSTALLED`** | La patch non è inclusa nella baseline delle patch, ma è installata nel nodo gestito. Potrebbe essere stato installato manualmente da un individuo o automaticamente da Patch Manager quando il documento `AWS-RunPatchBaseline` è stato eseguito sul nodo gestito. | Conforme |
| **`INSTALLED_OTHER`** | La patch non è inclusa nella baseline, o non è approvata da essa ma è installata nel nodo gestito. La patch potrebbe essere stata installata manualmente, il pacchetto potrebbe essere una dipendenza obbligatoria di un'altra patch approvata oppure la patch potrebbe essere stata inclusa in un' InstallOverrideList operazione. Se non indichi `Block` come ** azione **Patch rifiutate, `INSTALLED_OTHER` include anche patch installate ma rifiutate. | Conforme |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` significa una delle due cose: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-compliance-states.html) In nessun caso ciò significa che una patch con questo stato *richieda* un riavvio, ma solo che il nodo non è stato riavviato dopo l'installazione della patch. | Non conforme |
| **`INSTALLED_REJECTED`** | La patch è installata nel nodo gestito, ma è specificata in un elenco di **Patch rifiutate**. Questo in genere significa che la patch è stata installata prima di essere aggiunta a un elenco di patch rifiutate. | Non conforme: |
| **`MISSING`** | La patch è approvata nella baseline, ma non è installata nel nodo gestito. Se configuri l'attività del documento `AWS-RunPatchBaseline` per l'analisi anziché per l'installazione, il sistema riporta questo stato per le patch individuate durante l'analisi ma non installate. | Non conforme |
| **`FAILED`** | La patch è approvata nella baseline, ma non è stato possibile installarla. Per risolvere questa situazione, esamina l'output del comando per ottenere informazioni utili per comprendere il problema. | Non conforme |
## Valori di conformità delle patch per altri sistemi operativi
Per tutti i sistemi operativi oltre a Debian Server e Ubuntu Server, le regole per la classificazione dei pacchetti nei vari stati di conformità sono descritte nella tabella seguente.
| Stato della patch | Description | Valore di conformità |
| --- | --- | --- |
| **`INSTALLED`** | La patch non è inclusa nella baseline delle patch, ma è installata nel nodo gestito. Potrebbe essere stato installato manualmente da un individuo o automaticamente da Patch Manager quando il documento `AWS-RunPatchBaseline` è stato eseguito sul nodo. | Conforme |
| **`INSTALLED_OTHER`**¹ | La patch non è inclusa nella baseline, ma è installata nel nodo. I possibili motivi sono due: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-compliance-states.html) | Conforme |
| **`INSTALLED_REJECTED`** | La patch è installata nel nodo gestito, ma è specificata in un elenco di Patch rifiutate. Questo in genere significa che la patch è stata installata prima di essere aggiunta a un elenco di patch rifiutate. | Non conforme: |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` significa una delle due cose: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/patch-manager-compliance-states.html) In nessun caso ciò significa che una patch con questo stato *richieda* un riavvio, ma solo che il nodo non è stato riavviato dopo l'installazione della patch. | Non conforme |
| **`MISSING`** | La patch è approvata nella baseline, ma non è installata nel nodo gestito. Se configuri l'attività del documento `AWS-RunPatchBaseline` per l'analisi anziché per l'installazione, il sistema riporta questo stato per le patch individuate durante l'analisi ma non installate. | Non conforme |
| **`FAILED`** | La patch è approvata nella baseline, ma non è stato possibile installarla. Per risolvere questa situazione, esamina l'output del comando per ottenere informazioni utili per comprendere il problema. | Non conforme |
| **`NOT_APPLICABLE`**¹ | *Questo stato di conformità viene segnalato solo per i sistemi operativi Windows Server.* La patch è approvata nella baseline, ma la funzionalità o il servizio da cui viene utilizzata non è installato nel nodo gestito. Ad esempio, una patch per un servizio server Web, come Internet Information Services (IIS), mostrerà `NOT_APPLICABLE` se è stata approvata nella baseline, ma il servizio Web non è installato nel nodo gestito. Una patch ha anche la possibilità di essere contrassegnata con `NOT_APPLICABLE` se è stata sostituita da un aggiornamento successivo. Ciò significa che è installato l'aggiornamento più recente e che l'aggiornamento `NOT_APPLICABLE` non è più richiesto. | Non applicabile |
| AVAILABLE\$1SECURITY\$1UPDATES | *Questo stato di conformità viene segnalato solo per i sistemi operativi Windows Server.* Una patch di aggiornamento di sicurezza disponibile, non approvata dalla baseline delle patch, può avere un valore di conformità di `Compliant` o `Non-Compliant`, come definito in una baseline di patch personalizzata. Quando si crea o si aggiorna una baseline delle patch, si sceglie lo stato da assegnare alle patch di sicurezza, disponibili ma non approvate, perché non soddisfano i criteri di installazione specificati nella baseline delle patch. Ad esempio, le patch di sicurezza che si desidera installare possono essere ignorate se è stato specificato un lungo periodo di attesa dopo il rilascio di una patch prima dell'installazione. Se un aggiornamento della patch viene rilasciato durante il periodo di attesa specificato, il periodo di attesa per l'installazione della patch ricomincia da capo. Se il periodo di attesa è troppo lungo, è possibile che più versioni della patch vengano rilasciate e mai installate. Per quanto riguarda il conteggio riepilogativo delle patch, quando una patch viene segnalata come `AvailableSecurityUpdate`, verrà sempre inclusa in `AvailableSecurityUpdateCount`. Se la baseline è configurata per riportare queste patch come `NonCompliant`, viene inclusa anche in `SecurityNonCompliantCount`. Se la baseline è configurata per riportare queste patch come `Compliant`, viene inclusa anche in `SecurityNonCompliantCount`. Queste patch vengono sempre segnalate con una gravità non specificata e non sono mai incluse nel `CriticalNonCompliantCount`. | Conforme o non conforme, a seconda dell'opzione selezionata per gli aggiornamenti di sicurezza disponibili. Utilizzando la console per creare o aggiornare una baseline delle patch, è possibile specificare questa opzione nel campo **Stato di conformità degli aggiornamenti di sicurezza disponibili**. Utilizzando il comando AWS CLI per eseguire il [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)or, si specifica questa opzione nel `available-security-updates-compliance-status` parametro. |
¹ Per le patch con lo stato `INSTALLED_OTHER` e `NOT_APPLICABLE`, Patch Manager omette alcuni dati dai risultati delle query in base al comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html), ad esempio i valori per `Classification` e `Severity`. Questo aiuta a prevenire il superamento del limite di dati per i singoli nodi in Inventario, uno strumento di AWS Systems Manager. Per visualizzare tutti i dettagli della patch, è possibile utilizzare il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html).
# Applicazione di patch a nodi gestiti non conformi
Molti degli stessi AWS Systems Manager strumenti e processi che è possibile utilizzare per verificare la conformità delle patch dei nodi gestiti possono essere utilizzati per rendere i nodi conformi alle regole di patch attualmente applicabili. Per rendere i nodi gestiti conformi alle patchPatch Manager, uno strumento deve eseguire un'`Scan and install`operazione. AWS Systems Manager(Se il tuo obiettivo è solo identificare i nodi gestiti non conformi ma non correggerli, esegui piuttosto un'operazione di `Scan`. Per ulteriori informazioni, consulta [Identificazione di nodi gestiti non conformi](patch-manager-find-noncompliant-nodes.md)).
**Installa le patch utilizzando Systems Manager**
È possibile scegliere tra diversi strumenti per eseguire un'operazione `Scan and install`:
+ (Consigliato) Configura una policy di patch in Quick Setup, uno strumento di Systems Manager, che consente di installare le patch mancanti in base alla pianificazione di un'intera organizzazione, un sottoinsieme di unità organizzative o di un singolo Account AWS. Per ulteriori informazioni, consulta [Configura l'applicazione di patch per le istanze in un'organizzazione utilizzando una policy di patch di Quick Setup](quick-setup-patch-manager.md).
+ Crea una finestra di manutenzione che utilizza il documento di Systems Manager (documento SSM) `AWS-RunPatchBaseline` in un tipo di attività Run Command. Per informazioni, consulta [Tutorial: creazione di una finestra di manutenzione per l'applicazione di patch tramite console](maintenance-window-tutorial-patching.md).
+ Esegui manualmente `AWS-RunPatchBaseline` in un'operazioneRun Command. Per informazioni, consulta [Esecuzione di comandi dalla console](running-commands-console.md).
+ Installa le patch su richiesta utilizzando l'opzione **Applica patch ora**. Per informazioni, consulta [Patching dei nodi gestiti on demand](patch-manager-patch-now-on-demand.md).
# Identificazione dell'esecuzione che ha creato i dati di conformità delle patch
I dati sulla conformità delle patch rappresentano un' point-in-timeistantanea dell'ultima operazione di patching riuscita. Ogni rapporto di conformità include sia un ID di esecuzione che un orario di acquisizione che consentono di identificare l'operazione che ha creato i dati di conformità e quando sono stati generati.
Quando si dispone di più tipi di operazioni per la scansione delle istanze al fine di verificarne la conformità alle patch, ogni analisi sovrascrive i dati di conformità delle patch delle scansioni precedenti. Di conseguenza, potresti ottenere risultati imprevisti nei dati di conformità delle patch.
Supponiamo ad esempio di creare una policy di patch che analizzi la conformità delle patch ogni giorno alle 2 del mattino ora locale. Tale policy di patch utilizza una baseline delle patch destinata alle patch con gravità `Critical`, `Important` e `Moderate`. Tale baseline delle patch indica inoltre alcune patch specificamente rifiutate.
Supponiamo inoltre che tu abbia già configurato una finestra di manutenzione, che non è possibile eliminare o disattivare per analizzare lo stesso set di nodi gestiti ogni giorno alle 16:00 ora locale. L'attività di quella finestra di manutenzione utilizza una baseline delle patch diversa, che si rivolge solo alle patch con severità `Critical` e non esclude alcuna patch specifica.
Quando la finestra di manutenzione esegue la seconda scansione, i dati di conformità delle patch della prima scansione vengono eliminati e sostituiti con quelli della seconda scansione.
Pertanto, consigliamo di utilizzare un solo metodo automatizzato per la scansione e l'installazione nelle operazioni di applicazione di patch. Se stai configurando le policy di patch, dovresti eliminare o disattivare altri metodi di scansione per verificarne la conformità. Per ulteriori informazioni, consulta i seguenti argomenti:
+ Per annullare un'attività di applicazione di patch da una finestra di manutenzione, consulta [Aggiornamento o annullamento della registrazione delle attività di una finestra di manutenzione utilizzando la console](sysman-maintenance-update.md#sysman-maintenance-update-tasks)
+ Per eliminare un'associazione State Manager, consulta [Eliminazione di associazioni](systems-manager-state-manager-delete-association.md).
Per disattivare le scansioni giornaliere di conformità delle patch in una configurazione di gestione host, segui questi passaggi in Quick Setup:
1. Nel pannello di navigazione, scegli **Quick Setup**.
1. Seleziona la configurazione di gestione host da aggiornare.
1. Scegli **Actions, Edit configuration** (Operazioni, Modifica configurazione).
1. Deseleziona la casella di controllo **Scan instances for missing patches daily** (Scansiona le istanze per le patch mancanti ogni giorno).
1. Scegliere **Aggiorna**.
**Nota**
L'utilizzo dell'opzione **Patch now** (Applica subito una patch) per verificare la conformità di un nodo gestito comporta anche una sovrascrittura dei dati di conformità delle patch.
# Patching dei nodi gestiti on demand
Tramite l'utilizzo di **Applica patch ora** in Patch Manager, uno strumento di AWS Systems Manager, è possibile eseguire operazioni di patch su richiesta dalla console di Systems Manager. Ciò significa che non è necessario creare una pianificazione per aggiornare lo stato di conformità dei tuoi nodi gestiti o per installare patch su nodi non conformi. Inoltre, non è necessario passare dalla console Systems Manager alla console di Systems Manager Patch Manager e Maintenance Windows viceversa per impostare o modificare una finestra di patching pianificata. AWS Systems Manager
**Applica patch ora ** è particolarmente utile quando è necessario applicare aggiornamenti zero-day o installare altre patch fondamentali nei nodi gestiti il prima possibile.
**Nota**
L'applicazione di patch su richiesta è supportata per una singola Account AWSRegione AWS coppia alla volta. Non può essere utilizzata per l'applicazione di patch basate su *policy di patch*. Ti consigliamo di mantenere la conformità tra tutti i nodi gestiti tramite le policy di patch. Per ulteriori informazioni sull'utilizzo delle policy di patch, consulta [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
**Topics**
+ [Come funziona “Applica patch ora”](#patch-on-demand-how-it-works)
+ [Esecuzione di “Applica patch ora”](#run-patch-now)
## Come funziona “Applica patch ora”
Per eseguire **Applica patch ora**, si specificano solo due impostazioni richieste:
+ Se eseguire la scansione solo per le patch mancanti o per eseguire la scansione di *e*, installare patch sui nodi gestiti
+ Su quali nodi gestiti eseguire l'operazione
Quando viene eseguita l'operazione **Patch now**, determina quale base patch utilizzare nello stesso modo in cui viene selezionata per altre operazioni di patch. Se un nodo gestito è associato a un gruppo di patch, viene utilizzata la baseline delle patch specificata per quel gruppo. Se il nodo gestito non è associato a un gruppo di patch, l'operazione utilizza la baseline delle patch attualmente impostata come di default per il tipo di sistema operativo del nodo gestito. Può trattarsi di una baseline predefinita o di una baseline personalizzata impostata come predefinita. Per ulteriori informazioni sulla selezione della baseline delle patch, consulta [Gruppi di patch](patch-manager-patch-groups.md).
Le opzioni che è possibile specificare per **Applica subito patch** includono la scelta di quando o se riavviare i nodi gestiti dopo l'applicazione di patch, la specificazione di un bucket Amazon Simple Storage Service (Amazon S3) per memorizzare i dati di log relativi a operazione di applicazione di patch ed esecuzione dei documenti di Systems Manager (documenti SSM) come hook del ciclo di vita durante l'applicazione di patch.
### Soglie di concorrenza e di errore per “Applica patch ora”
Per **Applica patch ora**, le opzioni di concorrenza e soglia di errore sono gestite da Patch Manager. Non è necessario specificare su quanti nodi gestiti applicare la patch contemporaneamente, né quanti errori sono consentiti prima che l'operazione abbia esito negativo. Patch Manager applica le impostazioni di soglia di concorrenza e di errore descritte nelle tabelle seguenti quando si esegue la patch su richiesta.
**Importante**
Le seguenti soglie si applicano solo a operazioni `Scan and install`. Per le operazioni `Scan`,Patch Manager tenta di scansionare contemporaneamente fino a 1.000 nodi e continuare la scansione fino a quando non ha riscontrato fino a 1.000 errori.
**Concurrency: operazioni di installazione**
| Numero totale di nodi gestiti nell'operazione **Patch now** | Numero di nodi gestiti sottoposti a scansione o a cui vengono applicate patch contemporaneamente |
| --- | --- |
| Meno di 25 | 1 |
| 25-100 | 5% |
| da 101 a 1.000 | 8% |
| Oltre 1.000 | 10% |
**Soglia di errore: operazioni di installazione**
| Numero totale di nodi gestiti nell'operazione **Patch now** | Numero di errori consentiti prima che l'operazione non vada a buon fine |
| --- | --- |
| Meno di 25 | 1 |
| 25-100 | 5 |
| Da 101 a 1.000 | 10 |
| Oltre 1.000 | 10 |
### Utilizzo degli hook del ciclo di vita “Applica patch ora”
**Applica patch ora** offre la possibilità di eseguire documenti di comando SSM come hook del ciclo di vita durante un'operazione di applicazione di patch `Install`. È possibile utilizzare questi hook per attività quali l'arresto delle applicazioni prima dell'applicazione di patch o dell'esecuzione dei controlli di integrità delle applicazioni dopo l'applicazione di patch o in seguito a un riavvio.
Per ulteriori informazioni sull'utilizzo di Hook del ciclo di vita, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
Nella tabella seguente sono elencati hook del ciclo di vita disponibili per ognuna delle tre opzioni di riavvio di **Applica patch ora**, oltre agli usi di esempio per ciascun hook.
**Hook del ciclo di vita e usi di esempio**
| Opzione di riavvio | Hook: prima dell'installazione | Hook: dopo l'installazione | Hook: in uscita | Hook: dopo il riavvio pianificato |
| --- | --- | --- | --- | --- |
| Riavvia se necessario | Eseguire un documento di SSM prima di iniziare l'applicazione di patch. Esempio di utilizzo: arrestare le applicazioni in modo sicuro prima dell'inizio del processo di applicazione di patch. | Eseguire un documento SSM al termine dell'operazione di applicazione di patch e prima del riavvio nodo gestito. Esempio di utilizzo: eseguire operazioni come l'installazione di applicazioni di terze parti prima di un potenziale riavvio. | Esegui un documento SSM dopo il completamento dell'operazione di applicazione di patch e il riavvio delle istanze. Esempio di utilizzo: assicurarsi che le applicazioni siano in esecuzione come previsto dopo l'applicazione di patch. | Non disponibile |
| Non riavviare le istanze | Come sopra. | Eseguire un documento SSM al termine dell'operazione di applicazione di patch. Esempio di utilizzo: assicurarsi che le applicazioni siano in esecuzione come previsto dopo l'applicazione di patch. | *Non disponibile* | *Non disponibile* |
| Pianificare un tempo di riavvio | Come sopra. | Stessa cosa per Non riavviare le istanze. | Non disponibile | Esegui un documento SSM immediatamente dopo il completamento di un riavvio pianificato. Esempio di utilizzo: assicurarsi che le applicazioni siano in esecuzione come previsto dopo il riavvio. |
## Esecuzione di “Applica patch ora”
Utilizza la procedura seguente per applicare patch ai tuoi nodi gestiti on demand.
**Per eseguire “Applica patch ora”**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Scegli **Applica patch ora**.
1. Per **Operazione di applicazione di patch**, scegli una delle opzioni seguenti:
+ **Scan**: Patch Manager trova quali patch mancano dai tuoi nodi gestiti ma non le installa. È possibile visualizzare i risultati nel pannello di controllo **Conformità** o in altri strumenti utilizzati per la visualizzazione della conformità delle patch.
+ **Scansione e installazione**: Patch Manager trova quali patch mancano ai tuoi nodi gestiti e le installa.
1. Utilizza questa fase solo se è stato scelto**Scansione e installazione** nella fase precedente. Per **Regions (Regioni)**, scegli una delle seguenti opzioni:
+ **Riavvia se necessario**: Dopo l'installazione, Patch Manager riavvia i nodi gestiti solo se necessario per completare un'installazione di patch.
+ **Non riavviare le mie istanze**: Dopo l'installazione, Patch Manager non riavvia i nodi gestiti. È possibile riavviare manualmente i nodi gestiti quando si sceglie o si gestiscono i riavvii al di fuori di Patch Manager.
+ **Pianificare un tempo di riavvio**: specificare la data, l'ora e il fuso orario UTC per Patch Manager per riavviare i nodi gestiti. Dopo aver eseguito l'operazione **Applica patch ora**, il riavvio pianificato viene elencato come associazione in State Manager con il nome `AWS-PatchRebootAssociation`.
**Importante**
Se si annulla l'operazione di patching principale dopo che è stata avviata, l'`AWS-PatchRebootAssociation`associazione in NON State Manager viene annullata automaticamente. Per evitare riavvii imprevisti, è necessario eliminare manualmente `AWS-PatchRebootAssociation` FROM State Manager se non si desidera più che si verifichi il riavvio pianificato. In caso contrario, potrebbero verificarsi riavvii non pianificati del sistema che potrebbero influire sui carichi di lavoro di produzione. È possibile trovare questa associazione nella console Systems Manager sotto **State Manager**> **Associazioni**.
1. Per **Instances to patch (Istanze a cui applicare le patch)**, scegliere una delle seguenti opzioni:
+ **Patch tutte le istanze**: Patch Manager esegue l'operazione specificata su tutti i nodi gestiti della versione corrente Regione AWS. Account AWS
+ **Applica patch solo alle istanze di destinazione specificate**: è possibile specificare i nodi gestiti da assegnare nel passaggio successivo.
1. Utilizzare questa fase solo se è stato scelto **Applica patch solo alle istanze di destinazione specificate** nella fase precedente. Nella sezione **Selezione target**, identificare i nodi gestiti in cui si desidera eseguire questa operazione specificando i tag, selezionando i nodi gestiti manualmente o specificando un gruppo di risorse.
**Nota**
Se un nodo gestito che ti aspetti di vedere non è presente nell'elenco, consulta [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md) per suggerimenti sulla risoluzione dei problemi.
Se scegli come target un gruppo di risorse, tieni presente che i gruppi di risorse basati su uno AWS CloudFormation stack devono comunque essere etichettati con il tag predefinito`aws:cloudformation:stack-id`. Se è stato rimosso, Patch Manager potrebbe non essere in grado di determinare quali nodi gestiti appartengono al gruppo di risorse.
1. (Facoltativo) Per **Archiviazione di log di applicazione di patch**, se si desidera creare e salvare i log da questa operazione di applicazione di patch, selezionare il bucket S3 per la memorizzazione dei log.
**Nota**
Le autorizzazioni S3 che danno la possibilità di scrivere dati in un bucket S3 sono quelle del profilo dell'istanza (per istanze EC2) o del ruolo di servizio IAM (in macchine attivate da sistemi ibridi) assegnate all'istanza, non quelle dell'utente IAM che esegue questo processo. Per ulteriori informazioni, consulta le pagine [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md) oppure [Creazione di un ruolo di servizio IAM richiesto per System Manager in ambiente ibrido e multicloud](hybrid-multicloud-service-role.md). Inoltre, se il bucket S3 specificato si trova in un altro bucket Account AWS, assicurati che il profilo di istanza o il ruolo del servizio IAM associato al nodo gestito disponga delle autorizzazioni necessarie per scrivere su quel bucket.
1. (Facoltativo) Se si desidera eseguire documenti SSM come hook del ciclo di vita durante punti specifici dell'operazione di applicazione di patch, eseguire le operazioni seguenti:
+ Scegliere **Usa hook del ciclo di vita**.
+ Per ogni hook disponibile, selezionare il documento SSM da eseguire nel punto specificato dell'operazione:
+ Prima dell'installazione
+ Dopo l'installazione
+ All'uscita
+ Dopo il riavvio pianificato
**Nota**
Il documento predefinito, `AWS-Noop`, non esegue alcuna operazione.
1. Scegli **Applica patch ora**.
Viene aperta la pagina **Resoconto di esecuzione dell'associazione**. La patch ora utilizza le associazioni in State Manager, uno strumento di AWS Systems Manager, per le sue operazioni). Nell'area **Riepilogo dell'operazione** è possibile monitorare lo stato della scansione o dell'applicazione di patch nei nodi gestiti specificati.
# Apertura con le baseline delle patch
Una baseline delle patch in Patch Manager, uno strumento di AWS Systems Manager, definisce le patch approvate da installare nei nodi gestiti. È possibile specificare singolarmente le patch approvate o rifiutate. È possibile anche creare regole di approvazione automatica per specificare che determinati tipi di aggiornamenti (ad esempio, quelli critici) devono essere approvati automaticamente. L'elenco dei rifiutati ha la priorità sulle regole e sull'elenco di quelli approvati. Per utilizzare un elenco di patch approvate per installare pacchetti specifici, è necessario, innanzitutto, rimuovere tutte le regole di approvazione automatica. Quando identifichi esplicitamente una patch come rifiutata, non verrà approvata né installata, anche se corrisponde a tutti i criteri specificati in una regola di approvazione automatica. Inoltre, verrà installata una patch in un nodo gestito solo se è valida per il software del nodo, anche se tale patch è stata comunque approvata per il nodo gestito.
**Topics**
+ [Visualizzazione delle linee di base delle patch AWS predefinite](patch-manager-view-predefined-patch-baselines.md)
+ [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md)
+ [Impostare una baseline delle patch esistente come predefinita](patch-manager-default-patch-baseline.md)
**Ulteriori informazioni**
+ [Patch di base](patch-manager-patch-baselines.md)
# Visualizzazione delle linee di base delle patch AWS predefinite
Patch Manager, uno strumento di AWS Systems Manager, include una linea di base di patch predefinita per ogni sistema operativo supportato da. Patch Manager È possibile utilizzare queste baseline delle patch predefinite, che non possono essere personalizzate, oppure crearne una personale. La procedura seguente descrive come visualizzare una baseline delle patch predefinita per vedere se soddisfa le proprie esigenze. Per ulteriori informazioni sulle baseline delle patch, consulta [Baseline delle patch predefinite e personalizzate](patch-manager-predefined-and-custom-patch-baselines.md).
**Per visualizzare le linee di base delle patch AWS predefinite**
1. Aprire la console all'indirizzo. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Nell'elenco delle baseline delle patch scegliere l'ID di una delle baseline delle patch predefinite.
oppure
Se è la prima volta che accedi a Patch Manager nella Regione AWS corrente, scegli **Inizia con una panoramica**, scegli la scheda **Baseline delle patch**, quindi scegli l'ID di baseline delle patch predefinite.
**Nota**
Per Windows Server, vengono fornite tre baseline delle patch predefinite. Le baseline delle patch `AWS-DefaultPatchBaseline` e `AWS-WindowsPredefinedPatchBaseline-OS` supportano solo gli aggiornamenti del sistema operativo Windows stesso. `AWS-DefaultPatchBaseline`Viene utilizzato come baseline delle patch di default per nodi gestiti Windows Server a meno che non si specifichi una baseline delle patch diversa. Le impostazioni di configurazione in queste due baseline delle patch sono le stesse. Il più recente dei due, `AWS-WindowsPredefinedPatchBaseline-OS`, è stato creato per distinguerlo dalla terza baseline delle patch predefinita per Windows Server. Quella baseline delle patch, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, può essere utilizzata per applicare patch sia nel sistema operativo Windows Server che nelle applicazioni supportate rilasciate da Microsoft.
Per ulteriori informazioni, consulta [Impostare una baseline delle patch esistente come predefinita](patch-manager-default-patch-baseline.md).
1. Nella sezione **Regole di approvazione**, rivedi la configurazione della baseline delle patch.
1. Se la configurazione è accettabile per i tuoi nodi gestiti, è possibile passare direttamente alla procedura [Creazione e gestione di gruppi di patch](patch-manager-tag-a-patch-group.md).
oppure
Per creare una baseline delle patch predefinita personale, proseguire con l'argomento [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md).
# Utilizzo delle baseline delle patch personalizzate
Patch Manager, uno strumento in AWS Systems Manager, include una patch di base predefinita per ogni sistema operativo supportato da. Patch Manager È possibile utilizzare queste baseline delle patch predefinite, che non possono essere personalizzate, oppure crearne una personale.
Le seguenti procedure descrivono come creare, aggiornare e cancellare le proprie baseline delle patch personalizzate. Per ulteriori informazioni sulle baseline delle patch, consulta [Baseline delle patch predefinite e personalizzate](patch-manager-predefined-and-custom-patch-baselines.md).
**Topics**
+ [Creazione di una baseline delle patch personalizzata per Linux](patch-manager-create-a-patch-baseline-for-linux.md)
+ [Creazione di una baseline delle patch personalizzata per macOS](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Creazione di una baseline delle patch personalizzata per Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
+ [Aggiornamento o eliminazione di una baseline delle patch personalizzata](patch-manager-update-or-delete-a-patch-baseline.md)
# Creazione di una baseline delle patch personalizzata per Linux
Utilizza la procedura seguente per creare una baseline delle patch personalizzata per i nodi gestiti da Linux in Patch Manager, uno strumento di AWS Systems Manager.
Per informazioni sulla creazione di una baseline delle patch per i nodi gestiti macOS, vedi [Creazione di una baseline delle patch personalizzata per macOS](patch-manager-create-a-patch-baseline-for-macos.md). Per informazioni sulla creazione di una baseline delle patch per i nodi gestiti di Windows, consulta [Creazione di una baseline delle patch personalizzata per Windows Server](patch-manager-create-a-patch-baseline-for-windows.md).
**Per creare una baseline delle patch personalizzata per i nodi gestiti da Linux**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Scegli la scheda **Baseline delle patch** e quindi **Crea baseline delle patch**.
oppure
Se è la prima volta che accedi a Patch Manager nella Regione AWS corrente, scegli **Inizia da una panoramica**, scegli la scheda **baseline delle patch** e quindi **Crea una baseline delle patch**.
1. Nel campo **Nome** inserisci il nome della nuova baseline delle patch, ad esempio `MyRHELPatchBaseline`.
1. (Facoltativo) Per **Descrizione**, inserisci una descrizione per questa baseline delle patch.
1. Per **Sistema operativo**, scegli un sistema operativo, ad esempio `Red Hat Enterprise Linux`.
1. Se desideri iniziare a utilizzare questa patch di base come predefinita per il sistema operativo selezionato non appena la crei, seleziona la casella accanto a **Imposta questa patch baseline come patch baseline predefinita per le istanze**. *operating system name*
**Nota**
Questa opzione è disponibile solo se hai effettuato l'accesso per la prima volta a Patch Manager prima del rilascio delle [policy di patch](patch-manager-policies.md) del 22 dicembre 2022.
Per informazioni sull'impostazione di una baseline delle patch esistente come predefinita, consulta [Impostare una baseline delle patch esistente come predefinita](patch-manager-default-patch-baseline.md).
1. Nella sezione **Regole di approvazione per sistema operativo** utilizza i campi per creare una o più regole di approvazione automatica.
+ **Prodotti**: la versione del sistema operativo a cui si applica la regola di approvazione, ad esempio `RedhatEnterpriseLinux7.4`. L'opzione predefinita è `All`.
+ **Classificazione**: il tipo di patch a cui si applica la regola di approvazione, ad esempio `Security` o `Enhancement`. L'opzione predefinita è `All`.
**Suggerimento**
È possibile configurare una baseline delle patch per controllare se sono installati aggiornamenti di versione secondaria per Linux, ad esempio RHEL 7.8. Aggiornamenti di versione secondari possono essere installati in automatico da Patch Manager a condizione che l'aggiornamento sia disponibile nel repository appropriato.
Per i sistemi operativi Linux, gli aggiornamenti delle versioni secondari non sono classificati in modo coerente. Possono essere classificati come correzioni di bug o aggiornamenti di sicurezza, o non classificati, anche all'interno della stessa versione del kernel. Ecco alcune opzioni per controllare se una baseline delle patch ne esegue l'installazione.
**Opzione 1**: la regola di approvazione più ampia per garantire l'installazione di aggiornamenti di versioni secondarie quando disponibili consiste nello specificare il campo **Classificazione** come `All` (\$1) e scegliere l'opzione **Includi aggiornamenti non relativi alla sicurezza**.
**Opzione 2**: per garantire che siano installate patch per una versione del sistema operativo, è possibile utilizzare un carattere jolly (\$1) per specificare il formato del kernel nella sezione **Eccezioni patch** della baseline delle patch. Ad esempio, il formato del kernel per RHEL 7.\$1 è `kernel-3.10.0-*.el7.x86_64`.
Immettere `kernel-3.10.0-*.el7.x86_64` nell'elenco **Approved patches (Patch approvate)** nella baseline delle patch per assicurarsi che tutte le patch, inclusi gli aggiornamenti delle versioni secondarie, vengano applicate ai nodi gestiti RHEL 7.\$1. (Se conosci il nome esatto del pacchetto di una patch di versione secondaria, è possibile inserirlo quello invece.)
**Opzione 3**: puoi avere il massimo controllo su quali patch vengono applicate ai nodi gestiti, inclusi gli aggiornamenti di versione minori, utilizzando il parametro nel documento. [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)`AWS-RunPatchBaseline` Per ulteriori informazioni, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
+ **Gravità**: il valore di gravità delle patch a cui si applica la regola, ad esempio `Critical`. L'opzione predefinita è `All`.
+ **Approvazione automatico**: il metodo per selezionare le patch per l'approvazione automatica.
**Nota**
Poiché non è possibile determinare in modo affidabile le date di rilascio dei pacchetti di aggiornamento per Ubuntu Server, le opzioni di approvazione automatica non sono supportate per questo sistema operativo.
+ **Approva le patch dopo un determinato numero di giorni**: il numero di giorni in cui Patch Manager Patch Manager deve attendere dopo il rilascio o l'ultimo aggiornamento di una patch prima che una patch venga approvata automaticamente. È possibile inserire qualsiasi numero intero da zero (0) a 360. Per la maggior parte degli scenari, consigliamo di attendere non più di 100 giorni.
+ **Approva le patch rilasciate fino a una data specifica**: la data di rilascio delle patch per la quale Patch Manager applica automaticamente tutte le patch rilasciate o aggiornate prima di tale data (inclusa). Ad esempio, se specifichi il 7 luglio 2023, nessuna patch rilasciata o aggiornata a partire dall'8 luglio 2023 verrà installata automaticamente.
+ (Facoltativo) **Report di conformità**: il livello di gravità da assegnare alle patch approvate dalla baseline, ad esempio `Critical` o `High`.
**Nota**
Se specifichi un livello di report di conformità e lo stato delle patch approvate viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
+ **Includi aggiornamenti non relativi alla sicurezza**: seleziona la casella per installare le patch del sistema operativo Linux non relative alla sicurezza disponibili nel repository di origine, oltre a quelle relative alla sicurezza.
Per ulteriori informazioni sulle operazioni con le regole di approvazione in una baseline delle patch personalizzata, consulta [Baseline personalizzate](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).
1. Per approvare esplicitamente qualsiasi patch oltre a quelle che soddisfano le regole di approvazione, procedere come segue nella sezione **Eccezioni patch**:
+ In **Patch approvate**, inserisci un elenco separato da virgole delle patch che desideri approvare.
Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).
+ (Facoltativo) In **Livello di conformità patch approvate**, assegna un livello di conformità alle patch dell'elenco.
+ Se qualche patch approvata e specificata non è correlata alla sicurezza, seleziona la casella di controllo **Includi aggiornamenti non critici** per installare anche queste patch sul sistema operativo Linux.
1. Per rifiutare esplicitamente qualsiasi patch oltre che comunque soddisfano le regole di approvazione, procedere come segue nella sezione **Eccezioni patch**:
+ In **Patch rifiutate**, inserisci un elenco separato da virgole delle patch che desideri rifiutare.
Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).
+ In **Operazione patch rifiutate**, seleziona l'operazione che Patch Manager effettuerà sulle patch incluse nell'elenco **Patch rifiutate**.
+ **Consenti come dipendenza**: un pacchetto dell'elenco **Patch rifiutate** viene installato solo se è incluso automaticamente in un altro pacchetto. È considerato conforme alla linea di base della patch e il suo stato è riportato come. *InstalledOther* Si tratta dell'operazione predefinita se non viene specificata alcuna opzione.
+ **Blocca**: i pacchetti dell'elenco **Patch rifiutate** e quelli che le includono come dipendenze non verranno installati da Patch Manager in alcun caso. Se un pacchetto è stato installato prima di essere stato aggiunto all'elenco **Patch rifiutate**, oppure è stato successivamente installato fuori da Patch Manager, viene considerato non conforme alla baseline delle patch e il relativo stato è *InstalledRejected*.
**Nota**
Patch Manager cerca le dipendenze delle patch in modo ricorsivo.
1. **(Facoltativo) Se desideri specificare repository di patch alternativi per diverse versioni di un sistema operativo, ad esempio *AmazonLinux2016.03 e *AmazonLinux2017.09**, procedi come segue per ogni prodotto nella sezione Fonti delle patch:**
+ In **Nome**, inserisci un nome per semplificare l'identificazione della configurazione di origine.
+ In **Prodotto**, seleziona la versione dei sistemi operativi a cui è destinato il repository di origine delle patch, ad esempio `RedhatEnterpriseLinux7.4`.
+ In **Configurazione**, immetti il valore della configurazione del repository da utilizzare nel formato appropriato:
------
#### [ Example for yum repositories ]
```
[main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
```
**Suggerimento**
Per informazioni sulle altre opzioni disponibili per la configurazione del repository yum, consulta [dnf.conf(5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html).
------
#### [ Examples for Ubuntu Server and Debian Server ]
`deb http://security.ubuntu.com/ubuntu jammy main`
`deb https://site.example.com/debian distribution component1 component2 component3`
Le informazioni sui repository per quelli di Ubuntu Server devono essere specificate in un'unica riga. Per ulteriori esempi e informazioni, consulta [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) sul sito web dei *Manuali di Ubuntu Server* e [il formato sources.list](https://wiki.debian.org/SourcesList#sources.list_format) sulla *Wiki Debian*.
------
Sceglie **Aggiungi un'altra origine** per specificare un repository di origine per ciascuna versione aggiuntiva del sistema operativo, fino a un massimo di 20.
Per ulteriori informazioni sui repository di patch di origine alternativi, consulta [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md).
1. (Facoltativo) Per **Gestisci tag**, applica una o più name/value coppie di chiavi di tag alla baseline della patch.
I tag sono metadati facoltativi assegnati a una risorsa. Consentono di categorizzare una risorsa in diversi modi, ad esempio in base allo scopo, al proprietario o all'ambiente. Ad esempio, è possibile applicare tag a una baseline delle patch per identificare il livello di gravità delle patch che specifica, la famiglia del sistema operativo a cui si applica e il tipo di ambiente. In questo caso, è possibile specificare tag simili alle seguenti name/value coppie di chiavi:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. Scegli **Crea una baseline delle patch**.
# Creazione di una baseline delle patch personalizzata per macOS
Utilizza la procedura seguente per creare una baseline delle patch personalizzata per i nodi gestiti da macOS in Patch Manager, uno strumento di AWS Systems Manager.
Per informazioni sulla creazione di una baseline delle patch per i nodi gestiti Windows Server, vedi [Creazione di una baseline delle patch personalizzata per Windows Server](patch-manager-create-a-patch-baseline-for-windows.md). Per informazioni sulla creazione di una baseline delle patch per i nodi gestiti Linux, vedi [Creazione di una baseline delle patch personalizzata per Linux](patch-manager-create-a-patch-baseline-for-linux.md).
**Nota**
macOSnon è supportato in tutto Regioni AWS. Per ulteriori informazioni sul supporto di Amazon EC2 per macOS, consulta [Istanze Amazon EC2 Mac](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) nella *Guida per l'utente di Amazon EC2*.
**Creazione di una baseline delle patch personalizzata per i nodi gestiti macOS**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Scegli la scheda **Baseline delle patch** e quindi **Crea baseline delle patch**.
oppure
Se è la prima volta che accedi a Patch Manager nella Regione AWS corrente, scegli **Inizia da una panoramica**, scegli la scheda **baseline delle patch** e quindi **Crea una baseline delle patch**.
1. Nel campo **Nome** inserisci il nome della nuova baseline delle patch, ad esempio `MymacOSPatchBaseline`.
1. (Facoltativo) Per **Descrizione**, inserisci una descrizione per questa baseline delle patch.
1. Per **Sistema operativo**, seleziona macOS.
1. Se desideri cominciare a utilizzare subito la baseline delle patch appena creata come impostazione predefinita per macOS, seleziona la casella vicino a **Rendi predefinita questa baseline delle patch per le istanze di macOS**.
**Nota**
Questa opzione è disponibile solo se hai effettuato l'accesso per la prima volta a Patch Manager prima del rilascio delle [policy di patch](patch-manager-policies.md) del 22 dicembre 2022.
Per informazioni sull'impostazione di una baseline delle patch esistente come predefinita, consulta [Impostare una baseline delle patch esistente come predefinita](patch-manager-default-patch-baseline.md).
1. Nella sezione **Regole di approvazione per sistema operativo** utilizza i campi per creare una o più regole di approvazione automatica.
+ **Prodotti**: la versione del sistema operativo a cui si applica la regola di approvazione, ad esempio `BigSur11.3.1` o `Ventura13.7`. L'opzione predefinita è `All`.
+ **Classificazione**: Il gestore di pacchetti o i gestori di pacchetti a cui si desidera applicare i pacchetti durante il processo di applicazione delle patch. È possibile scegliere tra le seguenti opzioni:
+ softwareupdate
+ Installer (Programma di installazione)
+ Brew
+ Brew cask
L'opzione predefinita è `All`.
+ (Facoltativo) **Report di conformità**: il livello di gravità da assegnare alle patch approvate dalla baseline, ad esempio `Critical` o `High`.
**Nota**
Quando si specifica un livello di report di conformità e lo stato delle patch approvate viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
Per ulteriori informazioni sulle operazioni con le regole di approvazione in una baseline delle patch personalizzata, consulta [Baseline personalizzate](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).
1. Per approvare esplicitamente qualsiasi patch oltre a quelle che soddisfano le regole di approvazione, procedere come segue nella sezione **Eccezioni patch**:
+ In **Patch approvate**, inserisci un elenco separato da virgole delle patch che desideri approvare.
Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).
+ (Facoltativo) In **Livello di conformità patch approvate**, assegna un livello di conformità alle patch dell'elenco.
1. Per rifiutare esplicitamente qualsiasi patch oltre che comunque soddisfano le regole di approvazione, procedere come segue nella sezione **Eccezioni patch**:
+ In **Patch rifiutate**, inserisci un elenco separato da virgole delle patch che desideri rifiutare.
Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).
+ In **Operazione patch rifiutate**, seleziona l'operazione che Patch Manager effettuerà sulle patch incluse nell'elenco **Patch rifiutate**.
+ **Consenti come dipendenza**: un pacchetto dell'elenco **Patch rifiutate** viene installato solo se è incluso automaticamente in un altro pacchetto. È considerato conforme alla linea di base della patch e il suo stato è riportato come. *InstalledOther* Si tratta dell'operazione predefinita se non viene specificata alcuna opzione.
+ **Blocca**: i pacchetti dell'elenco **Patch rifiutate** e quelli che le includono come dipendenze non verranno installati da Patch Manager in alcun caso. Se un pacchetto è stato installato prima di essere stato aggiunto all'elenco **Patch rifiutate**, oppure è stato successivamente installato fuori da Patch Manager, viene considerato non conforme alla baseline delle patch e il relativo stato è *InstalledRejected*.
1. (Facoltativo) Per **Gestisci tag**, applica una o più name/value coppie di chiavi di tag alla linea di base della patch.
I tag sono metadati facoltativi assegnati a una risorsa. Consentono di categorizzare una risorsa in diversi modi, ad esempio in base allo scopo, al proprietario o all'ambiente. Ad esempio, è possibile applicare tag a una baseline delle patch per identificare il livello di gravità delle patch che specifica, il gestore di pacchetti a cui si applica e il tipo di ambiente. In questo caso, è possibile specificare tag simili alle seguenti name/value coppie di chiavi:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=PackageManager,Value=softwareupdate`
+ `Key=Environment,Value=Production`
1. Scegli **Crea una baseline delle patch**.
# Creazione di una baseline delle patch personalizzata per Windows Server
Utilizza la procedura seguente per creare una baseline delle patch personalizzata per i nodi gestiti di Windows in Patch Manager, uno strumento di AWS Systems Manager.
Per informazioni sulla creazione di una baseline delle patch per i nodi gestiti Linux, vedi [Creazione di una baseline delle patch personalizzata per Linux](patch-manager-create-a-patch-baseline-for-linux.md). Per informazioni sulla creazione di baseline delle patch per i nodi gestiti da macOS, vedi [Creazione di una baseline delle patch personalizzata per macOS](patch-manager-create-a-patch-baseline-for-macos.md).
Per un esempio di creazione di una baseline delle patch limitata solo all'installazione di Windows Service Pack, consulta [Tutorial: creare una baseline delle patch per l'installazione di Windows Service Pack tramite la console](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
**Creazione di una baseline delle patch personalizzata (Windows)**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Scegli la scheda **Baseline delle patch** e quindi **Crea baseline delle patch**.
oppure
Se è la prima volta che accedi a Patch Manager nella Regione AWS corrente, scegli **Inizia da una panoramica**, scegli la scheda **baseline delle patch** e quindi **Crea una baseline delle patch**.
1. Nel campo **Nome** inserisci il nome della nuova baseline delle patch, ad esempio `MyWindowsPatchBaseline`.
1. (Facoltativo) Per **Descrizione**, inserisci una descrizione per questa baseline delle patch.
1. Per **Sistema operativo**, seleziona `Windows`.
1. Per lo **stato di conformità degli aggiornamenti di sicurezza disponibili**, scegli lo stato che desideri assegnare alle patch di sicurezza, disponibili, ma non approvate, perché non soddisfano i criteri di installazione specificati nella baseline delle patch, **Non conforme** o **Conforme**.
Scenario di esempio: le patch di sicurezza che potresti voler installare possono essere ignorate, se hai specificato un lungo periodo di attesa dopo il rilascio di una patch prima dell'installazione. Se un aggiornamento della patch viene rilasciato durante il periodo di attesa specificato, il periodo di attesa per l'installazione della patch ricomincia da capo. Se il periodo di attesa è troppo lungo, è possibile che più versioni della patch vengano rilasciate, ma non installate mai.
1. Se desideri iniziare a utilizzare subito questa baseline delle patch appena creata come impostazione predefinita per Windows, seleziona **Rendi predefinita questa baseline delle patch per le istanze di Windows Server**.
**Nota**
Questa opzione è disponibile solo se hai effettuato l'accesso per la prima volta a Patch Manager prima del rilascio delle [policy di patch](patch-manager-policies.md) del 22 dicembre 2022.
Per informazioni sull'impostazione di una baseline delle patch esistente come predefinita, consulta [Impostare una baseline delle patch esistente come predefinita](patch-manager-default-patch-baseline.md).
1. Nella sezione **Regole di approvazione per i sistemi operativi**, utilizza i campi per creare una o più regole di approvazione automatica.
+ **Prodotti**: la versione del sistema operativo a cui si applica la regola di approvazione, ad esempio `WindowsServer2012`. L'opzione predefinita è `All`.
+ **Classificazione**: il tipo di patch a cui si applica la regola di approvazione, ad esempio `CriticalUpdates`, `Drivers` e `Tools`. L'opzione predefinita è `All`.
**Suggerimento**
È possibile includere le installazioni di Windows Service Pack nelle regole di approvazione includendo `ServicePacks` o scegliendo `All` nell'elenco **Classificazione**. Per vedere un esempio, consulta [Tutorial: creare una baseline delle patch per l'installazione di Windows Service Pack tramite la console](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
+ **Gravità**: il valore di gravità delle patch a cui si applica la regola, ad esempio `Critical`. L'opzione predefinita è `All`.
+ **Approvazione automatico**: il metodo per selezionare le patch per l'approvazione automatica.
+ **Approva le patch dopo un determinato numero di giorni**: il numero di giorni in cui Patch Manager Patch Manager deve attendere dopo il rilascio o l'aggiornamento di una patch prima che una patch venga approvata automaticamente. È possibile inserire qualsiasi numero intero da zero (0) a 360. Per la maggior parte degli scenari, consigliamo di attendere non più di 100 giorni.
+ **Approva le patch rilasciate fino a una data specifica**: la data di rilascio delle patch per la quale Patch Manager applica automaticamente tutte le patch rilasciate o aggiornate prima di tale data (inclusa). Ad esempio, se si specifica il 7 luglio 2023, nessuna patch rilasciata o aggiornata a partire dall'8 luglio 2023 verrà installata automaticamente.
+ (Facoltativo) **Report di conformità**: il livello di gravità da assegnare alle patch approvate dalla baseline, ad esempio `High`.
**Nota**
Se specifichi un livello di report di conformità e lo stato delle patch approvate viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
1. (Facoltativo) Nella sezione **Regole di approvazione per le applicazioni**, utilizza i campi per creare una o più regole di approvazione automatica.
**Nota**
Anziché specificare le regole di approvazione, è possibile specificare elenchi di patch approvate e rifiutate come eccezioni di patch. Vedere i passaggi 10 e 11.
+ **Famiglia di prodotti**: la famiglia di prodotti Microsoft generale per cui si desidera specificare una regola, ad esempio `Office` o `Exchange Server`.
+ **Prodotti**: la versione dell'applicazione a cui si applica la regola di approvazione, ad esempio `Office 2016` o `Active Directory Rights Management Services Client 2.0 2016`. L'opzione predefinita è `All`.
+ **Classificazione**: il tipo di patch a cui si applica la regola di approvazione, ad esempio `CriticalUpdates`. L'opzione predefinita è `All`.
+ **Gravità**: il valore di gravità delle patch a cui si applica la regola, ad esempio `Critical`. L'opzione predefinita è `All`.
+ **Approvazione automatico**: il metodo per selezionare le patch per l'approvazione automatica.
+ **Approva le patch dopo un determinato numero di giorni**: il numero di giorni in cui Patch Manager Patch Manager deve attendere dopo il rilascio o l'aggiornamento di una patch prima che una patch venga approvata automaticamente. È possibile inserire qualsiasi numero intero da zero (0) a 360. Per la maggior parte degli scenari, consigliamo di attendere non più di 100 giorni.
+ **Approva le patch rilasciate fino a una data specifica**: la data di rilascio delle patch per la quale Patch Manager applica automaticamente tutte le patch rilasciate o aggiornate prima di tale data (inclusa). Ad esempio, se specifichi il 7 luglio 2023, nessuna patch rilasciata o aggiornata a partire dall'8 luglio 2023 verrà installata automaticamente.
+ (Facoltativo) **Report di conformità**: il livello di gravità da assegnare alle patch approvate dalla baseline, ad esempio `Critical` o `High`.
**Nota**
Se si specifica un livello di report di conformità e lo stato delle patch approvate viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
1. (Facoltativo) Per approvare esplicitamente qualsiasi patch anziché selezionare patch in base alle regole di approvazione, completa la procedura seguente nella sezione **Eccezioni di patch**:
+ In **Patch approvate**, inserisci un elenco separato da virgole delle patch che desideri approvare.
Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).
+ (Facoltativo) In **Livello di conformità patch approvate**, assegna un livello di conformità alle patch dell'elenco.
1. Per rifiutare esplicitamente qualsiasi patch oltre che comunque soddisfano le regole di approvazione, procedere come segue nella sezione **Eccezioni patch**:
+ In **Patch rifiutate**, inserisci un elenco separato da virgole delle patch che desideri rifiutare.
Per informazioni sui formati accettati per gli elenchi delle patch approvate e di quelle rifiutate, consulta [Formati dei nomi dei pacchetti per gli elenchi delle patch approvate e rifiutate](patch-manager-approved-rejected-package-name-formats.md).
+ In **Operazione patch rifiutate**, seleziona l'operazione che Patch Manager effettuerà sulle patch incluse nell'elenco **Patch rifiutate**.
+ **Consenti come dipendenza**: Windows Server non supporta il concetto di dipendenza dei pacchetti. Quando un pacchetto nell'elenco delle **patch rifiutate** è già installato sul nodo, lo stato viene riportato come `INSTALLED_OTHER`. Qualsiasi pacchetto non già installato sul nodo viene ignorato.
+ **Blocco**: i pacchetti nell'elenco delle **Patch rifiutate** non vengono installati da Patch Manager in nessun caso. Se un pacchetto è stato installato prima di essere stato aggiunto all'elenco **Patch rifiutate**, oppure è stato successivamente installato fuori da Patch Manager, viene considerato non conforme alla baseline delle patch e il relativo stato è `INSTALLED_REJECTED`.
Per ulteriori informazioni sulle operazioni relative ai pacchetti rifiutati, consulta le [Opzioni dell'elenco delle patch rifiutate nelle baseline delle patch personalizzate](patch-manager-windows-and-linux-differences.md#rejected-patches-diff).
1. (Facoltativo) Per **Gestisci tag**, applica una o più name/value coppie di chiavi di tag alla linea di base della patch.
I tag sono metadati facoltativi assegnati a una risorsa. Consentono di categorizzare una risorsa in diversi modi, ad esempio in base allo scopo, al proprietario o all'ambiente. Ad esempio, è possibile applicare tag a una baseline delle patch per identificare il livello di gravità delle patch che specifica, la famiglia del sistema operativo a cui si applica e il tipo di ambiente. In questo caso, è possibile specificare tag simili alle seguenti name/value coppie di chiavi:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. Scegli **Crea una baseline delle patch**.
# Aggiornamento o eliminazione di una baseline delle patch personalizzata
È possibile aggiornare o eliminare una baseline delle patch personalizzata creata in Patch Manager, uno strumento di AWS Systems Manager. Quando si aggiorna una baseline delle patch, è possibile modificare il nome, la descrizione, le regole di approvazione e le eccezioni per le patch approvate e rifiutate. Si possono aggiornare anche i tag che vengono applicati alla baseline delle patch. Non è possibile modificare il tipo di sistema operativo per cui è stata creata una patch baseline e non è possibile apportare modifiche a una baseline di patch predefinita fornita da. AWS
## Aggiornamento o eliminazione di una baseline delle patch
Segui questi passaggi per aggiornare o eliminare una baseline delle patch.
**Importante**
Presta attenzione durante l'eliminazione di una baseline delle patch personalizzata che potrebbe essere utilizzata da una configurazione delle policy di patch in Quick Setup.
Se utilizzi una [configurazione della policy di patch](patch-manager-policies.md) in Quick Setup, gli aggiornamenti apportati alle baseline delle patch personalizzate vengono sincronizzati con Quick Setup una volta ogni ora.
Quando si elimina una baseline delle patch personalizzata a cui si fa riferimento in una policy di patch, viene visualizzato un banner nella pagina **Dettagli di configurazione** di Quick Setup relativa alla policy di patch. Il banner informa che la policy di patch fa riferimento a una baseline delle patch che non esiste più, di conseguenza le successive operazioni di applicazione di patch avranno esito negativo. In questo caso, torna alla pagina **Configurazioni** di Quick Setup, seleziona la configurazione Patch Manager e scegli **Operazioni**, **Modifica configurazione**. Il nome della baseline delle patch eliminata viene evidenziato ed è necessario selezionare una nuova baseline delle patch per il sistema operativo interessato.
**Aggiornamento o eliminazione di una baseline delle patch**
1. Apri la console all' AWS Systems Manager indirizzo. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Scegliere la baseline delle patch che si desidera aggiornare o eliminare ed eseguire una delle operazioni seguenti:
+ Per rimuovere la linea di base della patch dalla tua Account AWS, scegli **Elimina**. Il sistema richiede di confermare le operazioni.
+ Per modificare il nome o la descrizione della baseline delle patch, le regole di approvazione o le eccezioni relative alle patch, scegliere **Modifica**. Nella pagina **Modifica delle baseline delle patch**, modifica i valori e le opzioni desiderate, quindi scegli **Salva le modifiche**.
+ Per aggiungere, modificare o eliminare i tag applicati alla baseline delle patch, scegli la scheda **Tag**, quindi scegli **Modifica tag**. Nella pagina **Modifica tag della baseline delle patch**, aggiorna i tag della baseline delle patch e scegli **Salva le modifiche**.
Per informazioni sulle scelte di configurazione disponibili, consulta [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md).
# Impostare una baseline delle patch esistente come predefinita
**Importante**
Qualsiasi selezione delle baseline delle patch predefinite effettuata qui non si applica alle operazioni basate su una policy di patch. Le policy di patch utilizzano le proprie specifiche per le baseline delle patch. Per ulteriori informazioni sulle policy di patch, consulta [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
Quando si crea una baseline delle patch personalizzata in Patch Manager, uno strumento di AWS Systems Manager, è possibile impostarla subito come base predefinita per il tipo di sistema operativo associato, non appena la crei. Per informazioni, consulta [Utilizzo delle baseline delle patch personalizzate](patch-manager-manage-patch-baselines.md).
È possibile anche impostare una baseline delle patch come predefinita per un tipo di sistema operativo.
**Nota**
I passaggi da seguire dipendono dal fatto che tu abbia effettuato l'accesso a Patch Manager per la prima volta prima o dopo il rilascio delle policy di patch il 22 dicembre 2022. Se l'hai usato Patch Manager prima di quella data, è possibile utilizzare la procedura della console. In caso contrario, utilizzare la AWS CLI procedura. Il menu **Operazioni** a cui si fa riferimento nella procedura della console non viene visualizzato nelle regioni in cui Patch Manager non è stato utilizzato prima del rilascio delle policy di patch.
**Per impostare una baseline delle patch come predefinita**
1. Aprire la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Selezionare la scheda **baseline delle patch**
1. Nell'elenco delle baseline delle patch scegliere il pulsante di una baseline delle patch che attualmente non è impostata come predefinita per un tipo di sistema operativo.
La colonna **Baseline predefinita** indica le basiline attualmente impostate come predefinite.
1. Nel menu **Operazioni**, scegli **Imposta baseline delle patch predefinita**.
**Importante**
Il menu **Azioni** non è disponibile se non hai utilizzato la Patch Manager versione attuale Account AWS e la regione prima del 22 dicembre 2022. Per ulteriori informazioni, consulta la **nota** riportata in precedenza in questo argomento.
1. Nella finestra di dialogo di conferma, scegli **Imposta la configurazione predefinita**.
**Per impostare una baseline delle patch come predefinita (AWS CLI)**
1. Esegui il [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html)comando per visualizzare un elenco di patch di base disponibili e i relativi nomi di risorse e IDs Amazon Resource Names ()ARNs.
```
aws ssm describe-patch-baselines
```
1. Esegui il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) per impostare una baseline come predefinita per il sistema operativo a cui è associata. Sostituiscilo *baseline-id-or-ARN* con l'ID della patch di base personalizzata o della baseline predefinita da utilizzare.
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--baseline-id baseline-id-or-ARN
```
Di seguito è riportato un esempio di impostazione di una baseline personalizzata come impostazione predefinita.
```
aws ssm register-default-patch-baseline \
--baseline-id pb-abc123cf9bEXAMPLE
```
Di seguito è riportato un esempio di impostazione di una linea di base predefinita gestita da come predefinita. AWS
```
aws ssm register-default-patch-baseline \
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--baseline-id baseline-id-or-ARN
```
Di seguito è riportato un esempio di impostazione di una baseline personalizzata come impostazione predefinita.
```
aws ssm register-default-patch-baseline ^
--baseline-id pb-abc123cf9bEXAMPLE
```
Di seguito è riportato un esempio di impostazione di una linea di base predefinita gestita da AWS come predefinita.
```
aws ssm register-default-patch-baseline ^
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
```
------
# Visualizzazione delle patch disponibili
ConPatch Manager, uno strumento in AWS Systems Manager, è possibile visualizzare tutte le patch disponibili per un sistema operativo specifico e, facoltativamente, una versione specifica del sistema operativo.
**Suggerimento**
Per generare un elenco di patch disponibili e salvarle in un file, è possibile utilizzare il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) e specificare il tuo [output](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html) preferito.
**Visualizzazione delle patch disponibili**
1. Apri la AWS Systems Manager console all'indirizzo. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Seleziona la scheda **Patch**.
oppure
Se è la prima volta che accedi a Patch Manager nella Regione AWS corrente, scegli **Inizia da una panoramica** e quindi scegli la scheda **Patch**.
**Nota**
Per Windows Server, la scheda **Patch** mostra gli aggiornamenti disponibili da Windows Server Update Service (WSUS).
1. Per **Sistema operativo**, seleziona il sistema operativo per il quale desideri visualizzare le patch disponibili, ad esempio `Windows` o `Amazon Linux`.
1. (Facoltativo) Per **Prodotto**, scegliere una versione del sistema operativo, ad esempio `WindowsServer2019` o `AmazonLinux2018.03`.
1. (Facoltativo) Per aggiungere o rimuovere colonne di informazioni per i risultati, scegli il pulsante Configura (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/configure-button.png)) in alto a destra dell'elenco **Patch**. (Per impostazione predefinita, la scheda **Patch** visualizza le colonne solo per alcuni metadati delle patch disponibili.)
Per informazioni sui tipi di metadati che è possibile aggiungere alla visualizzazione, consulta [Patch](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html) nella *Documentazione di riferimento API di AWS Systems Manager *.
# Creazione e gestione di gruppi di patch
Se *non* utilizzi policy di patch nelle tue operazioni, è possibile organizzare i tuoi tentativi di applicazione di patch aggiungendo nodi gestiti ai gruppi di patch utilizzando i tag.
**Nota**
I gruppi di patch non vengono utilizzati nelle operazioni di applicazione di patch basate su *policy di patch*. Per informazioni sull'utilizzo delle policy di patch, consulta [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
La funzionalità dei gruppi di patch non è supportata nella console per le coppie account-Regione, che non utilizzavano già i gruppi di patch prima del rilascio del supporto per le policy di patch il 22 dicembre 2022. La funzionalità dei gruppi di patch è ancora disponibile nelle coppie account-Regione, che hanno iniziato a utilizzare i gruppi di patch prima di questa data.
Per utilizzare i tag nelle operazioni di applicazione di patch, devi applicare la chiave dei tag `Patch Group` o `PatchGroup` ai nodi gestiti. Devi inoltre specificare il nome che desideri assegnare al gruppo di patch come valore del tag. È possibile specificare un valore tag qualsiasi, ma la chiave di tag deve essere `Patch Group` o `PatchGroup`.
`PatchGroup` (senza spazio) è necessario se sono presenti [tag consentiti nei metadati dell'istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS).
Dopo aver raggruppato i nodi gestiti utilizzando i tag, aggiungere il valore del gruppo di patch a una baseline delle patch. Registrando il gruppo di patch con una baseline delle patch, ci si assicura che vengano installate le patch corrette durante l'operazione di applicazione di patch. Per ulteriori informazioni sui gruppi di patch, consulta [Gruppi di patch](patch-manager-patch-groups.md).
Completa le attività descritte in questo argomento per preparare i nodi gestiti all'applicazione di patch utilizzando i tag con i nodi e la baseline delle patch. L’attività 1 è richiesta solo se stai applicando patch a istanze Amazon EC2. L'attività 2 è richiesta solo se stai applicando patch a istanze non EC2 in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). L'attività 3 è richiesta per tutti i nodi gestiti.
**Suggerimento**
È inoltre possibile aggiungere tag ai nodi gestiti utilizzando il AWS CLI comando `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` o l'operazione ssm-agent-minimum-s `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)` 3-permissions-required dell'API Systems Manager.
**Topics**
+ [Attività 1: aggiunta di istanze EC2 a un gruppo di patch mediante tag](#sysman-patch-group-tagging-ec2)
+ [Attività 2: aggiunta di nodi gestiti a un gruppo di patch mediante i tag](#sysman-patch-group-tagging-managed)
+ [Attività 3: aggiunta di un gruppo di patch a una baseline delle patch](#sysman-patch-group-patchbaseline)
## Attività 1: aggiunta di istanze EC2 a un gruppo di patch mediante tag
È possibile aggiungere tag alle istanze EC2 utilizzando la console di Systems Manager o la console di Amazon EC2. Questa attività è richiesta solo se stai applicando patch a istanze Amazon EC2.
**Importante**
Per applicare il tag `Patch Group` (con uno spazio) a un'istanza di Amazon EC2, l’opzione **Consenti i tag nei metadati dell'istanza** non deve essere abilitata sull'istanza. Consenti i tag nei metadati di istanza impedisce ai nomi delle chiavi dei tag di contenere spazi. Se hai [tag consentiti nei metadati dell'istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), è necessario utilizzare la chiave di tag `PatchGroup` (senza spazio).
**Opzione 1: per aggiungere istanze EC2 a un gruppo di patch (console di Systems Manager)**
1. Apri la console all'indirizzo. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Nel pannello di navigazione, scegli **Fleet Manager**.
1. Nell'elenco **Nodi gestiti** scegli l'ID dell'istanza EC2 gestita da configurare per l'applicazione di patch. Gli ID dei nodi per le istanze EC2 iniziano con `i-`.
**Nota**
Quando si utilizza la console Amazon EC2 AWS CLI, è possibile applicare `Key = PatchGroup` tag `Key = Patch Group` o a istanze che non sono ancora configurate per l'uso con Systems Manager.
Se un nodo che ti aspetti di vedere non è presente nell'elenco, consulta [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md) per suggerimenti sulla risoluzione dei problemi.
1. Seleziona la scheda **Tag**, quindi scegli **Modifica**.
1. Nella colonna di sinistra immettere **Patch Group** o **PatchGroup**. Se sono presenti [tag consentiti nei metadati dell'istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), è necessario utilizzare `PatchGroup` (senza spazio).
1. Nella colonna di destra inserisci un valore di tag da utilizzare come nome di questo gruppo di patch.
1. Scegli **Salva**.
1. Ripeti la procedura per aggiungere altre istanze EC2 allo stesso gruppo di patch.
**Opzione 2: per aggiungere istanze EC2 a un gruppo di patch (console di Amazon EC2)**
1. Apri la [console Amazon EC2](https://console.aws.amazon.com/ec2/) e nel pannello di navigazione scegli **Istanze**.
1. Nell'elenco delle istanze, scegline una da configurare per l'applicazione di patch.
1. Dal menu **Operazioni**, scegli **Impostazioni istanza**, **Gestisci tag**.
1. Scegli **Aggiungi nuovo tag**.
1. Per **Chiave**, immetti **Patch Group** o **PatchGroup**. Se sono presenti [tag consentiti nei metadati dell'istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), è necessario utilizzare `PatchGroup` (senza spazio).
1. Per **Valore**, immetti un valore da utilizzare come nome per il gruppo di patch.
1. Scegli **Save** (Salva).
1. Ripetere la procedura per aggiungere altre istanze allo stesso gruppo di patch.
## Attività 2: aggiunta di nodi gestiti a un gruppo di patch mediante i tag
Segui i passaggi descritti in questo argomento per aggiungere tag ai dispositivi AWS IoT Greengrass principali e ai nodi gestiti non EC2 ad attivazione ibrida (mi-\$1). Questa attività è richiesta solo se stai applicando patch a istanze non EC2 in un ambiente ibrido e multicloud.
**Nota**
Non è possibile aggiungere i tag per i nodi gestiti non EC2 utilizzando la console di Amazon EC2.
**Per aggiungere nodi gestiti non EC2 a un gruppo di patch (console di Systems Manager)**
1. AWS Systems Manager Apri [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)la console all'indirizzo.
1. Nel pannello di navigazione, scegli **Fleet Manager**.
1. Nell'elenco **Nodi gestiti**, scegli il nome del nodo gestito da configurare per l'applicazione di patch.
**Nota**
Se un nodo che ti aspetti di vedere non è presente nell'elenco, consulta [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md) per suggerimenti sulla risoluzione dei problemi.
1. Seleziona la scheda **Tag**, quindi scegli **Modifica**.
1. Nella colonna di sinistra immettere **Patch Group** o **PatchGroup**. Se sono presenti [tag consentiti nei metadati dell'istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), è necessario utilizzare `PatchGroup` (senza spazio).
1. Nella colonna di destra inserisci un valore di tag da utilizzare come nome di questo gruppo di patch.
1. Scegli **Save** (Salva).
1. Ripetere la procedura per aggiungere altri nodi gestiti allo stesso gruppo di patch.
## Attività 3: aggiunta di un gruppo di patch a una baseline delle patch
Per associare una determinata baseline delle patch ai propri nodi gestiti, è necessario aggiungere il valore del gruppo di patch alla baseline delle patch. Registrando il gruppo di patch con una baseline delle patch, ci si assicura che vengano installate le patch corrette durante un'operazione di applicazione di patch. Questa attività è necessaria sia che si applichino patch a istanze EC2, nodi gestiti non EC2 o entrambi.
Per ulteriori informazioni sui gruppi di patch, consulta [Gruppi di patch](patch-manager-patch-groups.md).
**Nota**
I passaggi da seguire dipendono dal fatto che tu abbia effettuato l'accesso a Patch Manager per la prima volta prima o dopo il rilascio delle [policy di patch](patch-manager-policies.md) il 22 dicembre 2022.
**Per aggiungere un gruppo di patch a una baseline delle patch (console di Systems Manager)**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Se accedi a Patch Manager per la prima volta nella Regione AWS corrente e si apre la pagina iniziale di Patch Manager, scegli **Inizia con una panoramica**.
1. Scegli la scheda **baseline delle patch**, quindi dall'elenco **baseline delle patch** scegli il nome della baseline delle patch da configurare per il gruppo di patch.
Se hai effettuato l'accesso per la prima volta a Patch Manager solo dopo il rilascio delle policy di patch, devi scegliere una baseline personalizzata che hai creato.
1. Se la pagina dei dettagli dell'**ID baseline** include un menu **Operazioni**, procedi come segue:
+ Scegliere **Operazioni**, quindi **Modifica i gruppi di patch**.
+ Inserisci il *valore* di tag aggiunto ai nodi gestiti in [Attività 2: aggiunta di nodi gestiti a un gruppo di patch mediante i tag](#sysman-patch-group-tagging-managed), quindi scegli **Aggiungi**.
Se la pagina dei dettagli dell'**ID baseline** *non* include un menu **Operazioni**, i gruppi di patch non possono essere configurati nella console. È possibile invece procedere come descritto di seguito:
+ (Consigliato) Configura una policy di patch in Quick Setup, uno strumento di AWS Systems Manager, per mappare una baseline delle patch su una o più istanze EC2.
Per ulteriori informazioni, consulta [Utilizzo delle policy di patch di Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) e [Automatizzazione dell'applicazione di patch a livello di organizzazione utilizzando una policy di patch di Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
+ Utilizzate il [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html)comando in AWS Command Line Interface (AWS CLI) per configurare un gruppo di patch.
# Integrazione con Patch Manager AWS Security Hub CSPM
[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)ti offre una visione completa del tuo stato di sicurezza in. AWS Security Hub CSPM raccoglie dati sulla sicurezza da tutti i prodotti Account AWS partner Servizi AWS di terze parti e supporta. Con Security Hub CSPM, puoi verificare il tuo ambiente rispetto agli standard e alle best practice del settore della sicurezza. Security Hub CSPM ti aiuta ad analizzare le tendenze della sicurezza e a identificare i problemi di sicurezza con la massima priorità.
Utilizzando l'integrazione traPatch Manager, uno strumento in AWS Systems Manager e Security Hub CSPM, è possibile inviare i risultati sui nodi non conformi al Security Patch Manager Hub CSPM. Un esito è la registrazione osservabile di un controllo di sicurezza o di un rilevamento correlato alla sicurezza. Security Hub CSPM può quindi includere i risultati relativi alle patch nella sua analisi del livello di sicurezza.
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 **Applica subito una patch** on demand
**Contents**
+ [In che modo Patch Manager invia gli esiti a CSPM di Security Hub](#securityhub-integration-sending-findings)
+ [Tipi di esiti che Patch Manager invia](#securityhub-integration-finding-types)
+ [Latenza per l'invio degli esiti](#securityhub-integration-finding-latency)
+ [Riprova quando CSPM Security Hub non è disponibile](#securityhub-integration-retry-send)
+ [Visualizzazione dei risultati in Security Hub CSPM](#securityhub-integration-view-findings)
+ [Esito tipico di Patch Manager](#securityhub-integration-finding-example)
+ [Attivazione e configurazione dell'integrazione](#securityhub-integration-enable)
+ [Come interrompere l'invio degli esiti](#securityhub-integration-disable)
## In che modo Patch Manager invia gli esiti a CSPM di Security Hub
In CSPM Security Hub, i problemi di sicurezza vengono monitorati come esiti. Alcuni risultati derivano da problemi rilevati da altri Servizi AWS partner o da terze parti. Security Hub CSPM dispone anche di una serie di regole che utilizza per rilevare problemi di sicurezza e generare risultati.
Patch Managerè uno degli strumenti di Systems Manager che invia i risultati al Security Hub CSPM. Dopo aver eseguito un'operazione di applicazione delle patch eseguendo un documento SSM (`AWS-RunPatchBaseline`,, o`AWS-RunPatchBaselineWithHooks`)`AWS-RunPatchBaselineAssociation`, le informazioni sull'applicazione delle patch vengono inviate a Inventory o Compliance, agli strumenti di o a entrambi. AWS Systems Manager Dopo che Inventory, Compliance o entrambi ricevono i dati, Patch Manager riceve una notifica. In seguito, Patch Manager valuta i dati per verificarne la precisione, la formattazione e la conformità. Se tutte le condizioni sono soddisfatte, Patch Manager inoltra i dati al Security Hub CSPM.
CSPM Security Hub fornisce strumenti per gestire gli esiti da tutte queste origini. È possibile visualizzare e filtrare gli elenchi di esiti e visualizzare i dettagli per un riscontro. Per ulteriori informazioni, consulta [Visualizzazione degli esiti](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html) nella *Guida per l'utente AWS Security Hub *. È inoltre possibile monitorare lo stato di un'indagine in un esito. Per ulteriori informazioni, consulta [Operazioni sugli esiti](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html) nella *Guida per l'utente di AWS Security Hub *.
Tutti i risultati in Security Hub CSPM utilizzano un formato JSON standard chiamato AWS Security Finding Format (ASFF). L'ASFF include dettagli sull'origine del problema, sulle risorse interessate e sullo stato corrente dell'esito. Per ulteriori informazioni, consulta [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm) nella *Guida per l'utente di AWS Security Hub *.
### Tipi di esiti che Patch Manager invia
Patch Managerinvia i risultati a Security Hub CSPM utilizzando il [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html). In ASFF, il `Types` campo fornisce il tipo di esito. Gli esiti ottenuti da Patch Manager possono avere i seguenti valori per `Types`:
+ Gestione del software e della configurazione Checks/Patch
Patch Manager invia un esito per nodo gestito non conforme. Il risultato viene riportato con il tipo di risorsa [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance)in modo che i risultati possano essere correlati con altre integrazioni CSPM di Security Hub che segnalano i tipi di risorse. `AwsEc2Instance` Patch Managerinoltra un risultato a Security Hub CSPM solo se l'operazione ha rilevato che il nodo gestito non è conforme. L'esito include i risultati di riepilogo di patch.
**Nota**
Dopo aver segnalato un nodo non conforme a Security Hub CSPM. Patch Managernon invia un aggiornamento a Security Hub CSPM dopo che il nodo è stato reso conforme. È possibile risolvere manualmente i risultati in Security Hub CSPM dopo l'applicazione delle patch richieste al nodo gestito.
Per ulteriori informazioni sulla definizione di conformità, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md). *Per ulteriori informazioni in merito`PatchSummary`, consulta l'API [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)Reference.AWS Security Hub *
### Latenza per l'invio degli esiti
Quando viene Patch Manager creato un nuovo risultato, di solito viene inviato al CSPM di Security Hub entro pochi secondi o 2 ore. La velocità dipende dal traffico nella Regione AWS in fase di elaborazione in quel momento.
### Riprova quando CSPM Security Hub non è disponibile
In caso di interruzione del servizio, viene eseguita una AWS Lambda funzione per reinserire i messaggi nella coda principale dopo la riattivazione del servizio. Dopo che i messaggi sono nella coda principale, il tentativo è automatico.
Se Security Hub CSPM non è disponibile, Patch Manager riprova a inviare i risultati finché non vengono ricevuti.
### Visualizzazione dei risultati in Security Hub CSPM
Questa procedura descrive come visualizzare i risultati in Security Hub CSPM sui nodi gestiti della flotta che non sono conformi alle patch.
**Per esaminare i risultati CSPM di Security Hub per la conformità delle patch**
1. Accedi a Console di gestione AWS e apri la AWS Security Hub CSPM console all'indirizzo. [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/)
1. Nel riquadro di navigazione, seleziona **Esiti**.
1. Scegli la casella **Aggiungi filtri** (![\[The Search icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)).
1. Nel menu, sotto **Filtri**, scegli **Nome prodotto**.
1. Nella finestra di dialogo che si apre, scegli **è** nel primo campo e poi inserisci **Systems Manager Patch Manager** nel secondo campo.
1. Scegli **Applica**.
1. Aggiungi eventuali filtri aggiuntivi che desideri per restringere i risultati.
1. Nell'elenco degli esiti, scegli il titolo di un esito su cui desideri maggiori informazioni.
Sul lato destro dello schermo si apre un riquadro con ulteriori dettagli sulla risorsa, sul problema rilevato e sulla soluzione consigliata.
**Importante**
Al momento, Security Hub CSPM riporta il tipo di risorsa di tutti i nodi gestiti come. `EC2 Instance` Sono inclusi i server locali e le macchine virtuali (VMs) registrati per l'uso con Systems Manager.
**Classificazioni di gravità**
L'elenco degli esiti di **Systems Manager Patch Manager** include un report sulla gravità dell'esito. I livelli di **gravità** includono i seguenti, dal meno grave al più grave:
+ **INFORMATIVO**: non è stato riscontrato alcun problema.
+ **BASSO**: il problema non richiede alcuna correzione.
+ **MEDIO**: il problema va risolto, ma non con urgenza.
+ **ALTO**: il problema deve essere risolto in via prioritaria.
+ **CRITICO**: il problema deve essere risolto immediatamente per evitare l'escalation.
La gravità è determinata dal pacchetto non conforme più grave presente su un'istanza. Poiché è possibile disporre di più baseline delle patch con più livelli di gravità, tra tutti i pacchetti non conformi viene segnalata la gravità più elevata. Ad esempio, supponiamo di avere due pacchetti non conformi in cui la gravità del pacchetto A è "Critica" e la gravità del pacchetto B è "Bassa". "Critica" verrà riportata come gravità.
Tieni presente che il campo di gravità è direttamente correlato al campo `Compliance` di Patch Manager. Si tratta di un campo che è possibile assegnare alle singole patch che corrispondono alla regola. Poiché questo campo `Compliance` è assegnato a singole patch, non si riflette sul livello di riepilogo delle patch.
**Contenuti correlati**
+ [Esiti](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html) nella *Guida per l'utente di AWS Security Hub *
+ [Conformità delle patch per più account con Patch Manager e Centrale di sicurezza](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/) nel *blog AWS Management & Governance*
## Esito tipico di Patch Manager
Patch Managerinvia i risultati al Security Hub CSPM utilizzando il [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html).
Ecco un esempio di un esito tipico di Patch Manager.
```
{
"SchemaVersion": "2018-10-08",
"Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
"GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"AwsAccountId": "111122223333",
"Types": [
"Software & Configuration Checks/Patch Management/Compliance"
],
"CreatedAt": "2021-11-11T22:05:25Z",
"UpdatedAt": "2021-11-11T22:05:25Z",
"Severity": {
"Label": "INFORMATIONAL",
"Normalized": 0
},
"Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
"Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
"Remediation": {
"Recommendation": {
"Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
"Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
}
},
"SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
"ProductFields": {
"aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"aws/securityhub/ProductName": "Systems Manager Patch Manager",
"aws/securityhub/CompanyName": "AWS"
},
"Resources": [
{
"Type": "AwsEc2Instance",
"Id": "i-02573cafcfEXAMPLE",
"Partition": "aws",
"Region": "us-east-2"
}
],
"WorkflowState": "NEW",
"Workflow": {
"Status": "NEW"
},
"RecordState": "ACTIVE",
"PatchSummary": {
"Id": "pb-0c10e65780EXAMPLE",
"InstalledCount": 45,
"MissingCount": 2,
"FailedCount": 0,
"InstalledOtherCount": 396,
"InstalledRejectedCount": 0,
"InstalledPendingReboot": 0,
"OperationStartTime": "2021-11-11T22:05:06Z",
"OperationEndTime": "2021-11-11T22:05:25Z",
"RebootOption": "NoReboot",
"Operation": "SCAN"
}
}
```
## Attivazione e configurazione dell'integrazione
Per utilizzare l'Patch Managerintegrazione con Security Hub CSPM, è necessario attivare Security Hub CSPM. *Per informazioni su come attivare Security Hub CSPM, vedere [Configurazione del CSPM di Security Hub nella Guida](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html) per l'utente.AWS Security Hub *
La procedura seguente descrive come integrare Patch Manager e Security Hub CSPM quando Security Hub CSPM è già attivo ma Patch Manager l'integrazione è disattivata. È necessario completare questa procedura solo se l'integrazione è stata disattivata manualmente.
**Per aggiungere Patch Manager all'integrazione CSPM di Security Hub**
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Seleziona la scheda **Impostazioni**.
oppure
Se è la prima volta che accedi a Patch Manager nella Regione AWS corrente, scegli **Inizia da una panoramica** e quindi scegli la scheda **Impostazioni**.
1. **Nella sezione **Esporta in Security Hub CSPM**, a destra dei **risultati di conformità delle patch che non vengono esportati in Security Hub**, scegli Abilita.**
## Come interrompere l'invio degli esiti
Per interrompere l'invio degli esiti a CSPM Security Hub, è possibile utilizzare la console CSPM Security Hub o l'API.
Per ulteriori informazioni, consulta gli argomenti seguenti nella *Guida per l'utente AWS Security Hub *:
+ [Disabilitazione e abilitazione del flusso di esiti di un'integrazione (console)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [Disabilitazione del flusso di risultati da un'integrazione (API CSPM Security Hub,) AWS CLI](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)
# Lavorare con le risorse di Patch Manager utilizzando AWS CLI
La sezione include esempi di comandi AWS Command Line Interface (AWS CLI) che è possibile utilizzare per eseguire attività di configurazione perPatch Manager, uno strumento in AWS Systems Manager.
Per un'illustrazione dell'utilizzo di patch AWS CLI per applicare patch a un ambiente server utilizzando una linea di base di patch personalizzata, vedere. [Tutorial: applicare una patch a un ambiente server utilizzando il AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
Per ulteriori informazioni sull'utilizzo di AWS CLI for AWS Systems Manager tasks, consulta la [AWS Systems Manager sezione del AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html).
**Topics**
+ [AWS CLI comandi per le linee di base delle patch](#patch-baseline-cli-commands)
+ [AWS CLI comandi per gruppi di patch](#patch-group-cli-commands)
+ [AWS CLI comandi per visualizzare i riepiloghi e i dettagli delle patch](#patch-details-cli-commands)
+ [AWS CLI comandi per la scansione e l'applicazione di patch ai nodi gestiti](#patch-operations-cli-commands)
## AWS CLI comandi per le linee di base delle patch
**Topics**
+ [Creazione di una baseline delle patch](#patch-manager-cli-commands-create-patch-baseline)
+ [Creazione di una baseline delle patch con repository personalizzati per varie versioni dei sistemi operativi](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [Aggiornamento di una baseline delle patch](#patch-manager-cli-commands-update-patch-baseline)
+ [Assegnazione di un nuovo nome a una baseline delle patch](#patch-manager-cli-commands-rename-patch-baseline)
+ [Eliminazione di una baseline delle patch](#patch-manager-cli-commands-delete-patch-baseline)
+ [Elenco di tutte le baseline delle patch](#patch-manager-cli-commands-describe-patch-baselines)
+ [Elenca tutte le linee di base delle AWS patch fornite](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [Elenco di tutte le baseline delle patch personali](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [Visualizzazione di una baseline delle patch](#patch-manager-cli-commands-get-patch-baseline)
+ [Ottenimento della baseline delle patch predefinita](#patch-manager-cli-commands-get-default-patch-baseline)
+ [Impostare una linea di baseline delle patch personalizzata come impostazione predefinita](#patch-manager-cli-commands-register-default-patch-baseline)
+ [Reimposta la linea di base di una AWS patch come predefinita](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [Tag di una baseline delle patch](#patch-manager-cli-commands-add-tags-to-resource)
+ [Elenca i tag di una baseline delle patch.](#patch-manager-cli-commands-list-tags-for-resource)
+ [Rimozione di un tag da una baseline delle patch](#patch-manager-cli-commands-remove-tags-from-resource)
### Creazione di una baseline delle patch
Il seguente comando crea una baseline delle patch che approva tutti gli aggiornamenti correlati alla sicurezza critici o importanti per Windows Server 2012 R2 5 giorni dopo il rilascio. Sono state specificate anche le patch per gli elenchi approvati e rifiutati. Inoltre, la baseline delle patch è stata contrassegnata per indicare che è destinata a un ambiente di produzione.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Windows-Server-2012R2" \
--tags "Key=Environment,Value=Production" \
--description "Windows Server 2012 R2, Important and Critical security updates" \
--approved-patches "KB2032276,MS10-048" \
--rejected-patches "KB2124261" \
--rejected-patches-action "ALLOW_AS_DEPENDENCY" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Windows-Server-2012R2" ^
--tags "Key=Environment,Value=Production" ^
--description "Windows Server 2012 R2, Important and Critical security updates" ^
--approved-patches "KB2032276,MS10-048" ^
--rejected-patches "KB2124261" ^
--rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Creazione di una baseline delle patch con repository personalizzati per varie versioni dei sistemi operativi
Applicabile solo per i nodi gestiti Linux. Il seguente comando mostra come specificare i repository delle patch da utilizzare per una determinata versione del sistema operativo Amazon Linux. In questo esempio viene utilizzato un repository di origine abilitato per impostazione predefinita in Amazon Linux 2017.09, ma potrebbe essere adattato per un altro repository di fonte configurato per un nodo gestito.
**Nota**
Per illustrare meglio questo comando più complesso, utilizziamo l'opzione `--cli-input-json` con opzioni aggiuntive archiviate in un file JSON esterno.
1. Creare un file JSON con un nome simile a `my-patch-repository.json` e aggiungervi il seguente contenuto.
```
{
"Description": "My patch repository for Amazon Linux 2",
"Name": "Amazon-Linux-2",
"OperatingSystem": "AMAZON_LINUX_2",
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 7,
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": [
"Important",
"Critical"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"Security",
"Bugfix"
]
},
{
"Key": "PRODUCT",
"Values": [
"AmazonLinux2"
]
}
]
}
}
]
},
"Sources": [
{
"Name": "My-AL2",
"Products": [
"AmazonLinux2"
],
"Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
}
]
}
```
1. Nella directory in cui è stato salvato il file, eseguire il comando seguente:
```
aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### Aggiornamento di una baseline delle patch
Il seguente comando aggiunge due patch come rifiutate e una come approvata a una baseline delle patch esistente.
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).
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--rejected-patches "KB2032276" "MS10-048" \
--approved-patches "KB2124261"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--rejected-patches "KB2032276" "MS10-048" ^
--approved-patches "KB2124261"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001494.035,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Assegnazione di un nuovo nome a una baseline delle patch
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001795.287,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Eliminazione di una baseline delle patch
```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Elenco di tutte le baseline delle patch
```
aws ssm describe-patch-baselines
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
Di seguito è mostrato un altro comando che elenca tutte le baseline delle patch in una Regione AWS.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[All]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[All]"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### Elenca tutte le linee di base delle AWS patch fornite
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[AWS]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[AWS]"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
]
}
```
### Elenco di tutte le baseline delle patch personali
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[Self]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[Self]"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineIdentities":[
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### Visualizzazione di una baseline delle patch
```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```
**Nota**
Per le baseline delle patch personalizzate, è possibile specificare l'ID della baseline delle patch o l'Amazon Resource Name (ARN) completo. Per una linea AWS di base di patch fornita, è necessario specificare l'ARN completo. Ad esempio, `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`.
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"PatchGroups":[
"Web Servers"
],
"RejectedPatches":[
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1480997823.81,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Ottenimento della baseline delle patch predefinita
```
aws ssm get-default-patch-baseline --region us-east-2
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### Impostare una linea di baseline delle patch personalizzata come impostazione predefinita
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Reimposta la linea di base di una AWS patch come predefinita
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Tag di una baseline delle patch
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tags "Key=Project,Value=Testing"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tags "Key=Project,Value=Testing"
```
------
### Elenca i tag di una baseline delle patch.
------
#### [ Linux & macOS ]
```
aws ssm list-tags-for-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm list-tags-for-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE"
```
------
### Rimozione di un tag da una baseline delle patch
------
#### [ Linux & macOS ]
```
aws ssm remove-tags-from-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tag-keys "Project"
```
------
#### [ Windows Server ]
```
aws ssm remove-tags-from-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tag-keys "Project"
```
------
## AWS CLI comandi per gruppi di patch
**Topics**
+ [Creazione di un gruppo di patch](#patch-manager-cli-commands-create-patch-group)
+ [Registrazione del gruppo di patch "server web" con una baseline delle patch](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [Registra un gruppo di patch «Backend» con la patch di base fornita AWS](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [Visualizzazione delle registrazioni dei gruppi di patch](#patch-manager-cli-commands-describe-patch-groups)
+ [Annullamento della registrazione di un gruppo di patch da una baseline delle patch](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)
### Creazione di un gruppo di patch
**Nota**
I gruppi di patch non vengono utilizzati nelle operazioni di applicazione di patch basate su *policy di patch*. Per informazioni sull'utilizzo delle policy di patch, consulta [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
Per organizzare i tentativi di applicazione di patch, consigliamo di aggiungere nodi gestiti ai gruppi di patch utilizzando i tag, I gruppi di patch richiedono l'utilizzo della chiave di tag `Patch Group` o `PatchGroup`. Se sono presenti [tag consentiti nei metadati dell'istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), è necessario utilizzare `PatchGroup` (senza spazio). È possibile specificare un valore tag qualsiasi, ma la chiave di tag deve essere `Patch Group` o `PatchGroup`. Per ulteriori informazioni sui gruppi di patch, consulta [Gruppi di patch](patch-manager-patch-groups.md).
Dopo aver raggruppato i nodi gestiti utilizzando i tag, aggiungere il valore del gruppo di patch a una baseline delle patch. Registrando il gruppo di patch con una baseline delle patch, ci si assicura che vengano installate le patch corrette durante l'operazione di applicazione di patch.
#### Attività 1: aggiunta di istanze EC2 a un gruppo di patch mediante tag
**Nota**
Quando si utilizza la console Amazon Elastic Compute Cloud (Amazon EC2) AWS CLI e, è possibile `Key = Patch Group` applicare `Key = PatchGroup` o tag a istanze che non sono ancora configurate per l'uso con Systems Manager. Se un'istanza EC2 che ti aspetti di vedere in Patch Manager non è elencata dopo aver applicato il tag `Patch Group` o `Key = PatchGroup`, consultare [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md) per suggerimenti per la risoluzione dei problemi.
Eseguire il seguente comando per aggiungere il tag `PatchGroup` a un'istanza EC2.
```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```
#### Attività 2: aggiunta di nodi gestiti a un gruppo di patch mediante i tag
Eseguire il comando seguente per aggiungere il tag `PatchGroup` a un nodo gestito.
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "ManagedInstance" \
--resource-id "mi-0123456789abcdefg" \
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "ManagedInstance" ^
--resource-id "mi-0123456789abcdefg" ^
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### Attività 3: aggiunta di un gruppo di patch a una baseline delle patch
Eseguire il comando seguente per associare il valore di tag `PatchGroup` alla baseline delle patch specificata.
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Development"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Development"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroup": "Development",
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### Registrazione del gruppo di patch "server web" con una baseline delle patch
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Web Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Web Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroup":"Web Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Registra un gruppo di patch «Backend» con la patch di base fornita AWS
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
--patch-group "Backend"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
--patch-group "Backend"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroup":"Backend",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### Visualizzazione delle registrazioni dei gruppi di patch
```
aws ssm describe-patch-groups --region us-east-2
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroupPatchBaselineMappings":[
{
"PatchGroup":"Backend",
"BaselineIdentity":{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":false,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
},
{
"PatchGroup":"Web Servers",
"BaselineIdentity":{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":true,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
}
]
}
```
### Annullamento della registrazione di un gruppo di patch da una baseline delle patch
------
#### [ Linux & macOS ]
```
aws ssm deregister-patch-baseline-for-patch-group \
--region us-east-2 \
--patch-group "Production" \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm deregister-patch-baseline-for-patch-group ^
--region us-east-2 ^
--patch-group "Production" ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroup":"Production",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
## AWS CLI comandi per visualizzare i riepiloghi e i dettagli delle patch
**Topics**
+ [Ottenimento di tutte le patch definite da una baseline delle patch](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [Ottieni tutte le patch per la versione AmazonLinux 2018.03 che hanno una classificazione e una gravità di `SECURITY` `Critical`](#patch-manager-cli-commands-describe-available-patches-linux)
+ [Ottieni tutte le patch per Windows Server 2012 che presentano una gravità MSRC pari a `Critical`](#patch-manager-cli-commands-describe-available-patches)
+ [Ottenimento di tutte le patch disponibili](#patch-manager-cli-commands-describe-available-patches)
+ [Ottenimento dello stati di riepilogo delle patch per nodo gestito](#patch-manager-cli-commands-describe-instance-patch-states)
+ [Ottenimento dei dettagli di conformità delle patch per un nodo gestito](#patch-manager-cli-commands-describe-instance-patches)
+ [Visualizzare i risultati della conformità delle patch (AWS CLI)](#viewing-patch-compliance-results-cli)
### Ottenimento di tutte le patch definite da una baseline delle patch
**Nota**
Questo comando è supportato solo per le baseline delle patch Windows Server.
------
#### [ Linux & macOS ]
```
aws ssm describe-effective-patches-for-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm describe-effective-patches-for-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"NextToken":"--token string truncated--",
"EffectivePatches":[
{
"PatchStatus":{
"ApprovalDate":1384711200.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system
by installing this update from Microsoft. For a complete listing of the
issues that are included in this update, see the associated Microsoft
Knowledge Base article. After you install this update, you may have to
restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
"ReleaseDate":1384279200.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2876331",
"MsrcNumber":"MS13-089",
"Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
}
},
{
"PatchStatus":{
"ApprovalDate":1428858000.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"Windows Server 2012 R2 Update is a cumulative
set of security updates, critical updates and updates. You
must install Windows Server 2012 R2 Update to ensure that
your computer can continue to receive future Windows Updates,
including security updates. For a complete listing of the
issues that are included in this update, see the associated
Microsoft Knowledge Base article for more information. After
you install this item, you may have to restart your computer.",
"Classification":"SecurityUpdates",
"Title":"Windows Server 2012 R2 Update (KB2919355)",
"ReleaseDate":1428426000.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2919355",
"MsrcNumber":"MS14-018",
"Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
}
}
---output truncated---
```
### Ottieni tutte le patch per la versione AmazonLinux 2018.03 che hanno una classificazione e una gravità di `SECURITY` `Critical`
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Patches": [
{
"AdvisoryIds": ["ALAS-2011-1"],
"BugzillaIds": [ "1234567" ],
"Classification": "SECURITY",
"CVEIds": [ "CVE-2011-3192"],
"Name": "zziplib",
"Epoch": "0",
"Version": "2.71",
"Release": "1.3.amzn1",
"Arch": "i686",
"Product": "AmazonLinux2018.03",
"ReleaseDate": 1590519815,
"Severity": "CRITICAL"
}
]
}
---output truncated---
```
### Ottieni tutte le patch per Windows Server 2012 che presentano una gravità MSRC pari a `Critical`
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Patches":[
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 (KB2727528)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2727528",
"MsrcNumber":"MS12-072",
"Id":"1eb507be-2040-4eeb-803d-abc55700b715"
},
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Microsoft .NET Framework 3.5 on
Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2729462",
"MsrcNumber":"MS12-074",
"Id":"af873760-c97c-4088-ab7e-5219e120eab4"
}
---output truncated---
```
### Ottenimento di tutte le patch disponibili
```
aws ssm describe-available-patches --region us-east-2
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues
that are included in this update, see the associated Microsoft Knowledge Base
article. After you install this update, you may have to restart your system.",
"Id": "11adea10-0701-430e-954f-9471595ae246",
"KbNumber": "KB4074588",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518548400,
"Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based
Systems (KB4074588)",
"Vendor": "Microsoft"
},
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
"Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
"KbNumber": "KB4074590",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518544805,
"Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based
Systems (KB4074590)",
"Vendor": "Microsoft"
}
---output truncated---
```
### Ottenimento dello stati di riepilogo delle patch per nodo gestito
Il riepilogo per nodo gestito fornisce il numero di patch nei seguenti stati per nodo: "NotApplicable«, «Mancante», «Non riuscito», "" InstalledOther e «Installato».
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states \
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states ^
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"InstancePatchStates":[
{
"InstanceId": "i-08ee91c0b17045407",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
"InstalledCount": 50,
"InstalledOtherCount": 353,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 0,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 671,
"OperationStartTime": "2020-01-24T12:37:56-08:00",
"OperationEndTime": "2020-01-24T12:37:59-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
},
{
"InstanceId": "i-09a618aec652973a9",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
"InstalledCount": 36,
"InstalledOtherCount": 396,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 3,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 420,
"OperationStartTime": "2020-01-24T12:37:34-08:00",
"OperationEndTime": "2020-01-24T12:37:37-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
}
---output truncated---
```
### Ottenimento dei dettagli di conformità delle patch per un nodo gestito
```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-libs.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:24-07:00"
},
{
"Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-utils.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:32-07:00"
},
{
"Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
"KBId": "dhclient.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:31-07:00"
},
---output truncated---
```
### Visualizzare i risultati della conformità delle patch (AWS CLI)
**Per visualizzare i risultati della conformità delle patch per un singolo nodo gestito**
Esegui il seguente comando in AWS Command Line Interface (AWS CLI) per visualizzare i risultati di conformità delle patch per un singolo nodo gestito.
```
aws ssm describe-instance-patch-states --instance-id instance-id
```
Sostituisci *instance-id* con l'ID del nodo gestito di cui desideri visualizzare i risultati, nel formato `i-02573cafcfEXAMPLE` o`mi-0282f7c436EXAMPLE`.
Questo sistema restituisce informazioni simili alle seguenti.
```
{
"InstancePatchStates": [
{
"InstanceId": "i-02573cafcfEXAMPLE",
"PatchGroup": "mypatchgroup",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
"CriticalNonCompliantCount": 2,
"SecurityNonCompliantCount": 2,
"OtherNonCompliantCount": 1,
"InstalledCount": 123,
"InstalledOtherCount": 334,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 1,
"FailedCount": 2,
"UnreportedNotApplicableCount": 11,
"NotApplicableCount": 2063,
"OperationStartTime": "2021-05-03T11:00:56-07:00",
"OperationEndTime": "2021-05-03T11:01:09-07:00",
"Operation": "Scan",
"LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
"RebootOption": "RebootIfNeeded"
}
]
}
```
**Per visualizzare un riepilogo del conteggio delle patch per tutte le istanze EC2 in una Regione**
`describe-instance-patch-states` supporta il recupero dei risultati di una sola istanza gestita alla volta. Tuttavia, l'utilizzo di uno script personalizzato con `describe-instance-patch-states`, è possibile generare un report più granulare.
Ad esempio, se lo [Strumento di filtro jq](https://stedolan.github.io/jq/download/) è installato sul computer locale, è possibile eseguire il seguente comando per identificare quali delle istanze EC2 in un particolare Regione AWS hanno uno stato di `InstalledPendingReboot`.
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
*region*rappresenta l'identificatore di una regione Regione AWS supportata da AWS Systems Manager, ad esempio `us-east-2` per la regione Stati Uniti orientali (Ohio). Per un elenco dei *region* valori supportati, vedere la colonna **Regione** negli [endpoint del servizio Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) in. *Riferimenti generali di Amazon Web Services*
Esempio:
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
Il sistema restituisce informazioni simili alle seguenti.
```
1 i-02573cafcfEXAMPLE
0 i-0471e04240EXAMPLE
3 i-07782c72faEXAMPLE
6 i-083b678d37EXAMPLE
0 i-03a530a2d4EXAMPLE
1 i-01f68df0d0EXAMPLE
0 i-0a39c0f214EXAMPLE
7 i-0903a5101eEXAMPLE
7 i-03823c2fedEXAMPLE
```
Oltre a `InstalledPendingRebootCount`, l'elenco dei tipi di conteggio che è possibile cercare include quanto segue:
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`
## AWS CLI comandi per la scansione e l'applicazione di patch ai nodi gestiti
Dopo aver eseguito i seguenti comandi per verificare la conformità delle patch o installare le patch, è possibile utilizzare i comandi nella sezione [AWS CLI comandi per visualizzare i riepiloghi e i dettagli delle patch](#patch-details-cli-commands) per visualizzare informazioni sullo stato della patch e sulla conformità.
**Topics**
+ [Scansione dei nodi gestiti per la conformità alle patch (AWS CLI)](#patch-operations-scan)
+ [Installazione di patch sui nodi gestiti (AWS CLI)](#patch-operations-install-cli)
### Scansione dei nodi gestiti per la conformità alle patch (AWS CLI)
**Per eseguire la scansione di nodi gestiti specifici per la conformità delle patch**
Eseguire il seguente comando seguente.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Command": {
"CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974475.267,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621952275.267,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**Per analizzare i nodi gestiti per verificare la conformità delle patch in base al tag del gruppo**
Eseguire il seguente comando seguente.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Command": {
"CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974983.128,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621952783.128,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
### Installazione di patch sui nodi gestiti (AWS CLI)
**Per installare patch su nodi gestiti specifici**
Eseguire il seguente comando seguente.
**Nota**
I nodi gestiti di destinazione si riavviano in base alle necessità per completare l'installazione della patch. Per ulteriori informazioni, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Command": {
"CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975301.791,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621953101.791,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**Per installare patch su nodi gestiti in un gruppo di patch specifico**
Eseguire il seguente comando seguente.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
-parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Command": {
"CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975407.865,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621953207.865,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
# tutorial AWS Systems Manager Patch Manager
I tutorial di questa sezione mostrano come utilizzare Patch Manager uno strumento in AWS Systems Manager diversi scenari di applicazione delle patch.
**Topics**
+ [Tutorial: applicazione di patch a un server in un IPv6 unico ambiente](patch-manager-server-patching-iPv6-tutorial.md)
+ [Tutorial: creare una baseline delle patch per l'installazione di Windows Service Pack tramite la console](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutorial: aggiorna le dipendenze dell'applicazione, applica patch a un nodo gestito ed esegui un controllo dell'integrità specifico dell'applicazione tramite la console](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutorial: applicare una patch a un ambiente server utilizzando il AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
# Tutorial: applicazione di patch a un server in un IPv6 unico ambiente
Patch Managersupporta l'applicazione di patch ai nodi in ambienti che dispongono solo di. IPv6 Aggiornando la SSM Agent configurazione, le operazioni di patching possono essere configurate in modo da effettuare solo chiamate agli endpoint IPv6 del servizio.
**Per applicare patch a un server in un unico ambiente IPv6**
1. Assicurati che SSM Agent la versione 3.3270.0 o successiva sia installata sul nodo gestito.
1. Sul nodo gestito, accedi al file di configurazione. SSM Agent Puoi trovare il `amazon-ssm-agent.json` file nelle seguenti directory:
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
Se `amazon-ssm-agent.json` non esiste ancora, copia il contenuto della `amazon-ssm-agent.json.template` stessa directory in`amazon-ssm-agent.json`.
1. Aggiorna la voce seguente per impostare la regione corretta e impostala `UseDualStackEndpoint` su`true`:
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. Riavviate il SSM Agent servizio utilizzando il comando appropriato per il vostro sistema operativo:
+ Linux: `sudo systemctl restart amazon-ssm-agent`
+ Ubuntu Serverusando Snap: `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` seguito da `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` seguito da `Start-Service AmazonSSMAgent`
Per l'elenco completo dei comandi per sistema operativo, vedere[Verifica dello stato di SSM Agent e avvio dell'agente](ssm-agent-status-and-restart.md).
1. Eseguite qualsiasi operazione di patching per verificare che le operazioni di patching abbiano successo solo nel vostro ambiente IPv6. Assicurati che i nodi a cui applicare le patch siano connessi alla fonte della patch. È possibile controllare l'Run Commandoutput dell'esecuzione della patch per verificare la presenza di avvisi relativi a repository inaccessibili. Quando applichi una patch a un nodo in esecuzione in un IPv6 unico ambiente, assicurati che il nodo sia connesso alla fonte della patch. È possibile controllare l'Run Commandoutput dell'esecuzione della patch per verificare la presenza di avvisi relativi a repository inaccessibili. Per i sistemi operativi basati su DNF, è possibile configurare i repository non disponibili da ignorare durante l'applicazione delle patch se l'opzione è impostata su under. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` I sistemi operativi basati su DNF includono Amazon Linux 2023, Red Hat Enterprise Linux 8 e versioni successive, Oracle Linux 8 e versioni successive e CentOS 8 e versioni successive. Rocky Linux AlmaLinux Su Amazon Linux 2023, l'`skip_if_unavailable`opzione è impostata come `True` predefinita.
**Nota**
Quando utilizzi le funzionalità Install Override List o Baseline Override, assicurati che l'URL fornito sia raggiungibile dal nodo. Se l'opzione di SSM Agent configurazione `UseDualStackEndpoint` è impostata su`true`, viene utilizzato un client S3 dualstack quando viene fornito un URL S3.
# Tutorial: creare una baseline delle patch per l'installazione di Windows Service Pack tramite la console
Quando crei una baseline delle patch personalizzata, è possibile specificare che siano installati tutti, alcuni o solo un tipo di patch supportata.
Nelle baseline delle patch per Windows, è possibile selezionare `ServicePacks` come unica opzione di **Classificazione** per limitare gli aggiornamenti delle patch solo ai Service Pack. I service pack possono essere installati automaticamente da Patch Manager uno strumento in AWS Systems Manager, a condizione che l'aggiornamento sia disponibile in Windows Update o Windows Server Update Services (WSUS).
È possibile configurare una baseline delle patch per controllare se sono installati i Service Pack per tutte le versioni di Windows o solo quelli per versioni specifiche, ad esempio Windows 7 o Windows Server 2016.
Completa la procedura seguente per creare una baseline delle patch personalizzata da utilizzare esclusivamente per l'installazione di tutti i Service Pack nei nodi gestiti di Windows.
**Per creare una baseline delle patch per l'installazione di Windows Service Pack (console)**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Scegli la scheda **Baseline delle patch** e quindi **Crea baseline delle patch**.
1. Nel campo **Nome** inserisci il nome della baseline delle patch, ad esempio `MyWindowsServicePackPatchBaseline`.
1. (Facoltativo) Per **Descrizione**, inserisci una descrizione per questa baseline delle patch.
1. Per **Sistema operativo**, seleziona `Windows`.
1. Se desideri iniziare a utilizzare subito questa baseline delle patch appena creata come impostazione predefinita per Windows, seleziona **Rendi predefinita questa baseline delle patch per le istanze di Windows Server**.
**Nota**
Questa opzione è disponibile solo se hai effettuato l'accesso per la prima volta a Patch Manager prima del rilascio delle [policy di patch](patch-manager-policies.md) del 22 dicembre 2022.
Per informazioni sull'impostazione di una baseline delle patch esistente come predefinita, consulta [Impostare una baseline delle patch esistente come predefinita](patch-manager-default-patch-baseline.md).
1. Nella sezione **Regole di approvazione per i sistemi operativi**, utilizza i campi per creare una o più regole di approvazione automatica.
+ **Prodotto**: le versioni del sistema operativo alle quali si applica la regola di approvazione, ad esempio `WindowsServer2012`. È possibile scegliere una, più di una o tutte le versioni supportate di Windows. L'opzione predefinita è `All`.
+ **Classificazione**: scegli `ServicePacks`.
+ **Gravità**: il valore di gravità delle patch a cui si applica la regola. Per assicurarti che tutti i Service Pack siano inclusi nella regola, scegli `All`.
+ **Approvazione automatico**: il metodo per selezionare le patch per l'approvazione automatica.
+ **Approva le patch dopo un determinato numero di giorni**: il numero di giorni in cui Patch Manager Patch Manager deve attendere dopo il rilascio o l'aggiornamento di una patch prima che una patch venga approvata automaticamente. È possibile inserire qualsiasi numero intero da zero (0) a 360. Per la maggior parte degli scenari, consigliamo di attendere non più di 100 giorni.
+ **Approva le patch rilasciate fino a una data specifica**: la data di rilascio delle patch per la quale Patch Manager applica automaticamente tutte le patch rilasciate o aggiornate prima di tale data (inclusa). Ad esempio, se si specifica il 7 luglio 2023, nessuna patch rilasciata o aggiornata a partire dall'8 luglio 2023 verrà installata automaticamente.
+ (Facoltativo) **Report di conformità**: il livello di gravità da assegnare ai Service Pack approvati dalla baseline, ad esempio `High`.
**Nota**
Se si specifica un livello di report di conformità e lo stato delle patch di un Service Pack approvato viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
1. (Facoltativo) Per **Gestisci tag**, applica una o più name/value coppie di chiavi di tag alla linea di base della patch.
I tag sono metadati facoltativi assegnati a una risorsa. Consentono di categorizzare una risorsa in diversi modi, ad esempio in base allo scopo, al proprietario o all'ambiente. Per questa baseline delle patch dedicata all'aggiornamento dei Service Pack, è possibile specificare coppie chiave-valore come le seguenti:
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. Scegli **Crea una baseline delle patch**.
# Tutorial: aggiorna le dipendenze dell'applicazione, applica patch a un nodo gestito ed esegui un controllo dell'integrità specifico dell'applicazione tramite la console
In molti casi, un nodo gestito deve essere riavviato dopo che è stata applicata la patch con l'aggiornamento software più recente. Tuttavia, il riavvio di nodo in produzione senza misure di protezione può causare diversi problemi, ad esempio richiamare allarmi, registrare dati metrici errati e interrompere le sincronizzazioni dei dati.
Questo tutorial illustra come evitare problemi come questi utilizzando il documento (documento SSM) AWS Systems Manager `AWS-RunPatchBaselineWithHooks` per ottenere una complessa operazione di applicazione di patch in più fasi che consente di eseguire le operazioni seguenti:
1. Impedire nuove connessioni all'applicazione
1. Installare gli aggiornamenti nel sistema operativo
1. Aggiornare le dipendenze del pacchetto dell'applicazione
1. Riavviare il sistema
1. Esegui un controllo dell'integrità specifico dell'applicazione
Per questo esempio, abbiamo impostato la nostra infrastruttura in questo modo:
+ Le macchine virtuali di destinazione vengono registrate come nodi gestiti con Systems Manager.
+ `Iptables` viene utilizzato come firewall locale.
+ L'applicazione ospitata sui nodi gestiti è in esecuzione sulla porta 443.
+ L'applicazione ospitata sui nodi gestiti è un'applicazione di `nodeJS`.
+ L'applicazione ospitata sui nodi gestiti è gestita dal gestore di processi pm2.
+ L'applicazione dispone già di un endpoint di controllo dell'integrità specificato.
+ L'endpoint di controllo dell'integrità dell'applicazione non richiede l'autenticazione dell'utente finale. L'endpoint consente un controllo dell'integrità che soddisfi i requisiti dell'organizzazione per stabilire la disponibilità. Nei tuoi ambienti, potrebbe essere sufficiente accertare semplicemente che l'applicazione `nodeJS` sia in esecuzione e in grado di ascoltare le richieste. In altri casi, è possibile verificare anche che sia già stata stabilita una connessione al livello di memorizzazione nella cache o al livello di database.
Gli esempi riportati in questo tutorial sono esclusivamente a scopo dimostrativo e non devono essere implementati così come sono negli ambienti di produzione. Inoltre, tenere presente che la funzionalità hook del ciclo di vita di Patch Manager, una funzionalità di Systems Manager, con il documento `AWS-RunPatchBaselineWithHooks` può supportare numerosi altri scenari. Di seguito sono riportati vari esempi.
+ Arresta un agente di reporting dei parametri di riferimento prima di applicare patch e riavviarlo dopo il riavvio dei nodi gestiti.
+ Staccare il nodo gestito da un cluster CRM o PCS prima di applicare patch e ricollegarsi dopo il riavvio del nodo.
+ Aggiornare software di terze parti (ad esempio, Java, Tomcat, applicazioni Adobe e così via) su macchine Windows Server dopo l'applicazione degli aggiornamenti del sistema operativo (OS), ma prima del riavvio del nodo gestito.
**Per aggiornare le dipendenze dell'applicazione, applicare patch a un nodo gestito ed eseguire un controllo dell'integrità specifico dell'applicazione**
1. Creare un documento SSM per lo script di preinstallazione con i seguenti contenuti e denominarlo `NodeJSAppPrePatch`. Sostituisci *your\$1application* con il nome della tua applicazione.
Questo script blocca immediatamente le nuove richieste in arrivo e fornisce cinque secondi per le richieste già attive da completare prima di iniziare l'operazione di applicazione delle patch. Per l'opzione `sleep`, specifica un numero di secondi maggiore del necessario per il completamento delle richieste in arrivo.
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
Per informazioni sulla creazione di un documento SSM, consulta [Creazione del contenuto del documento SSM](documents-creating-content.md).
1. Crea un altro documento SSM con il seguente contenuto per lo script post-installazione per aggiornare le dipendenze dell'applicazione e denominarlo `NodeJSAppPostPatch`. Sostituisci */your/application/path* con il percorso dell'applicazione.
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. Crea un altro documento SSM con il seguente contenuto per il tuo script `onExit` per eseguire il backup dell'applicazione ed eseguire un controllo dell'integrità. Denomina questo documento SSM `NodeJSAppOnExitPatch`. Sostituisci *your\$1application* con il nome della tua applicazione.
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. Crea un'associazione in State Manager, uno strumento di AWS Systems Manager, per eseguire l'operazione eseguendo i passaggi seguenti:
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegliere **State Manager**, quindi **Create association (Crea associazione)**.
1. Per **Nome**, fornire un nome per identificare lo scopo dell'associazione.
1. Nell'elenco **Document (Documento)** scegliere `AWS-RunPatchBaselineWithHooks`.
1. Per **Operation (Operazione)**, selezionare **Install (Installa)**.
1. (Facoltativo) Per **ID snapshot**, fornire un GUID generato per velocizzare l'operazione e garantire la coerenza. Il valore GUID può essere semplice come `00000000-0000-0000-0000-111122223333`.
1. Per **Nome documento Hook pre-installazione**, immettere`NodeJSAppPrePatch`.
1. Per **Post Install Hook Doc Name** (Nome documento Hook post-installazione), immetti `NodeJSAppPostPatch`.
1. Per **On ExitHook Doc Name**, inserisci`NodeJSAppOnExitPatch`.
1. Per **Targets**, identificare i nodi gestiti specificando i tag, scegliendo i nodi manualmente, scegliendo un gruppo di risorse o scegliendo tutti i nodi gestiti.
1. Per **Specificare la pianificazione**, specificare la frequenza di esecuzione dell'associazione. Ad esempio, per l'applicazione di patch su nodi gestiti, una volta alla settimana è una cadenza comune.
1. Nella sezione **Rate control (Controllo della velocità)** scegli le opzioni per controllare l'esecuzione dell'associazione su più nodi gestiti. Assicurarsi che solo una parte dei nodi gestiti venga aggiornata alla volta. In caso contrario, tutto o la maggior parte del parco potrebbe essere disconnesso in una sola volta. Per informazioni sull'utilizzo dei controlli di velocità, consultare [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
1. (Facoltativo) In **Opzioni di output**, per salvare l'output del comando in un file, seleziona la casella **Abilita scrittura in S3**. Digita i nomi del bucket e del prefisso (cartella) nelle caselle.
**Nota**
Le autorizzazioni S3 che consentono di scrivere dati in un bucket S3 sono quelle del profilo dell'istanza assegnate al nodo gestito e non quelle dell'utente IAM che esegue questo processo. Per ulteriori informazioni, consulta le pagine [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md) oppure [Creazione di un ruolo di servizio IAM per un ambiente ibrido](hybrid-multicloud-service-role.md). Inoltre, se il bucket S3 specificato si trova in un Account AWS diverso, assicurarsi che il profilo dell'istanza o il ruolo di servizio IAM associato all'istanza disponga delle autorizzazioni necessarie per scrivere su quel bucket.
1. Scegli **Crea associazione**.
# Tutorial: applicare una patch a un ambiente server utilizzando il AWS CLI
La procedura seguente mostra in che modo un utente potrebbe applicare patch a un ambiente server utilizzando una baseline delle patch personalizzata, gruppi di patch e una finestra di manutenzione.
**Prima di iniziare**
+ Installazione o aggiornamento dell'SSM Agent sui tuoi nodi gestiti. Per applicare patch ai nodi gestiti Linux, i nodi devono essere in esecuzione la versione 2.0.834.0 SSM Agent o successive. Per ulteriori informazioni, consulta [Aggiornamento di SSM Agent utilizzando Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Configura ruoli e autorizzazioni perMaintenance Windows, uno strumento in AWS Systems Manager. Per ulteriori informazioni, consulta [Configurazione di Maintenance Windows](setting-up-maintenance-windows.md).
+ Installa e configura AWS Command Line Interface (AWS CLI), se non l'hai già fatto.
Per informazioni, consulta la pagina [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Per configurare Patch Manager e applicare patch ai nodi gestiti (riga di comando).**
1. Eseguire il comando seguente per creare una baseline delle patch per Windows denominata `Production-Baseline`. Questa baseline delle patch approva le patch per un ambiente di produzione 7 giorni dopo il rilascio o l'ultimo aggiornamento. In questo modo, la baseline delle patch è stata contrassegnata per indicare che è destinata a un ambiente di produzione.
**Nota**
Il parametro `OperatingSystem` e `PatchFilters` variano a seconda del sistema operativo dei nodi gestiti di destinazione a cui si applica la baseline delle patch. Per ulteriori informazioni, consultare [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) e [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html).
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Eseguire i comandi seguenti per registrare la baseline delle patch "Production-Baseline" per due gruppi di patch. I gruppi sono denominati «Server database» e «Server front-end».
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Eseguire i seguenti comandi per creare due finestre di manutenzione per il server di produzione. La prima finestra viene eseguita ogni martedì alle 22:00. La seconda finestra viene eseguita ogni sabato alle 22:00. Inoltre, la finestra di manutenzione è stata contrassegnata per indicare che è destinata a un ambiente di produzione.
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. Eseguire i comandi seguenti per registrare i gruppi di patch server `Database` e `Front-End` con le rispettive finestre di manutenzione.
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. Eseguire i comandi seguenti per registrare un'attività di patch che installa aggiornamenti mancanti nei server `Database` e `Front-End` durante le rispettive finestre di manutenzione.
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. Eseguire il seguente comando per ottenere il riepilogo di conformità delle patch di alto livello per un gruppo di patch. Il riepilogo della conformità patch di alto livello include il numero di nodi gestiti con patch nei rispettivi stati di patch.
**Nota**
Si prevede di visualizzare gli zeri per il numero di nodi gestiti nel riepilogo fino a quando l'attività di patch viene eseguita durante la prima finestra di manutenzione.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. Eseguire il seguente comando per ottenere il riepilogo dello stato di un nodo gestito per le patch di un gruppo. Il riepilogo per nodo gestito include un numero di patch nei rispettivi stati di patch per nodo gestito per un gruppo di patch.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
Per esempi di altri AWS CLI comandi che puoi usare per le tue attività Patch Manager di configurazione, vedi[Lavorare con le risorse di Patch Manager utilizzando AWS CLI](patch-manager-cli-commands.md).
# Risoluzione dei problemi relativi a Patch Manager
Utilizza le informazioni seguenti per risolvere i problemi relativi a Patch Manager, uno strumento di AWS Systems Manager.
**Topics**
+ [Problema: errore «Invoke-PatchBaselineOperation : Accesso negato» o «Impossibile scaricare il file da S3" per `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Problema: l'applicazione di patch non riesce senza una causa apparente o un messaggio di errore](#race-condition-conflict)
+ [Problema: risultati imprevisti per la conformità delle patch](#patch-manager-troubleshooting-compliance)
+ [Errori durante l'esecuzione di `AWS-RunPatchBaseline` su Linux](#patch-manager-troubleshooting-linux)
+ [Errori durante l'esecuzione di `AWS-RunPatchBaseline` su Windows Server](#patch-manager-troubleshooting-windows)
+ [Errori durante l'esecuzione `AWS-RunPatchBaseline` su macOS](#patch-manager-troubleshooting-macos)
+ [Utilizzo dei runbook di automazione Supporto AWS](#patch-manager-troubleshooting-using-support-runbooks)
+ [Contattare Supporto AWS](#patch-manager-troubleshooting-contact-support)
## Problema: errore «Invoke-PatchBaselineOperation : Accesso negato» o «Impossibile scaricare il file da S3" per `baseline_overrides.json`
**Problema**: quando vengono eseguite le operazioni di applicazione di patch specificate dalla policy di patch, viene visualizzato un errore simile all'esempio seguente.
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**Causa**: hai creato una policy di patch in Quick Setup e alcuni dei nodi gestiti presentavano già un profilo dell'istanza (per le istanze EC2) o un ruolo di servizio (per le macchine non EC2) collegato.
Tuttavia, come mostrato nell'immagine seguente, non hai selezionato la casella di controllo **Aggiungi le policy IAM richieste ai profili di istanza esistenti collegati alle istanze**.
![\[\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
Quando crei una policy di patch, viene creato anche un bucket Amazon S3 per archiviare il file di configurazione della policy `baseline_overrides.json`. Se non selezioni la casella di controllo **Aggiungi le policy IAM richieste ai profili di istanza esistenti collegati alle istanze** al momento della creazione della policy, le policy IAM e i tag delle risorse necessari per accedere a `baseline_overrides.json` nel bucket S3 non vengono aggiunti automaticamente ai profili di istanza IAM e ai ruoli di servizio esistenti.
**Soluzione 1**: elimina la configurazione della policy di patch esistente, quindi crea una configurazione sostitutiva, assicurandoti di selezionare la casella di controllo **Aggiungi le policy IAM richieste ai profili di istanza esistenti collegati alle istanze**. Questa selezione applica le policy IAM create da questa configurazione di Quick Setup ai nodi a cui è già associato un profilo di istanza o un ruolo di servizio. (Per impostazione predefinita, Quick Setup aggiunge le policy richieste alle istanze e ai nodi che *non* dispongono già di profili di istanza o ruoli di servizio). Per ulteriori informazioni, consulta [Automatizzazione dell'applicazione di patch a livello di organizzazione utilizzando una policy di patch di Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
**Soluzione 2**: aggiungi manualmente le autorizzazioni e i tag richiesti a ogni profilo di istanza IAM e ruolo di servizio IAM che utilizzi con Quick Setup. Per istruzioni, consulta [Autorizzazioni per il bucket S3 con policy di patch](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).
## Problema: l'applicazione di patch non riesce senza una causa apparente o un messaggio di errore
**Problema**: un'operazione di applicazione di patch non riesce senza restituire un messaggio di errore.
**Possibile causa**: quando si applicano le patch ai nodi gestiti, l'esecuzione del documento può essere interrotta e contrassegnata come fallita anche se le patch sono state installate correttamente. Ciò può verificarsi se il sistema avvia un riavvio imprevisto durante l'operazione di applicazione delle patch (ad esempio, per applicare aggiornamenti al firmware o funzionalità simili). SecureBoot L'agente SSM non può persistere e riprendere lo stato di esecuzione del documento dopo riavvii esterni, con il risultato che l'esecuzione viene segnalata come non riuscita.
**Soluzione**: per verificare lo stato di installazione delle patch dopo un'esecuzione non riuscita, esegui un'operazione di `Scan` patching, quindi controlla i dati di conformità delle patch in Patch Manager per valutare lo stato di conformità corrente.
Se stabilisci che i riavvii esterni non sono stati la causa dell'errore in questo scenario, ti consigliamo di contattare. [Supporto AWS](#patch-manager-troubleshooting-contact-support)
## Problema: risultati imprevisti per la conformità delle patch
**Problema**: quando si esaminano i dettagli di conformità delle patch generati dopo un'operazione `Scan`, questi includono informazioni che non riflettono le regole configurate nella baseline delle patch. Ad esempio, un'eccezione aggiunta all'elenco **Rejected patches** (Patch rifiutate) in una baseline delle patch viene elencata come `Missing`. Oppure le patch classificate come `Important` sono elencate come mancanti anche se la baseline delle patch specifica solo le patch `Critical`.
**Causa**: Patch Manager attualmente supporta diversi metodi di esecuzione delle operazioni `Scan`:
+ 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 **Applica subito una patch** on demand
L'esecuzione di un'operazione `Scan`, sovrascrive i dettagli di conformità della scansione più recente. Se hai impostato più metodi per eseguire un'operazione `Scan` e questi utilizzano baseline delle patch diverse con regole diverse, i esiti di conformità delle patch saranno diversi.
**Soluzione**: per evitare risultati imprevisti relativi alla conformità delle patch, ti consigliamo di utilizzare un solo metodo alla volta per eseguire l'operazione `Scan` di Patch Manager. Per ulteriori informazioni, consulta [Identificazione dell'esecuzione che ha creato i dati di conformità delle patch](patch-manager-compliance-data-overwrites.md).
## Errori durante l'esecuzione di `AWS-RunPatchBaseline` su Linux
**Topics**
+ [Problema: errore “Nessun file o directory di questo tipo”](#patch-manager-troubleshooting-linux-1)
+ [Problema: Errore “un altro processo ha acquisito il blocco yum”](#patch-manager-troubleshooting-linux-2)
+ [Problema: errore “Autorizzazione negata/non riuscita a eseguire i comandi”](#patch-manager-troubleshooting-linux-3)
+ [Problema: errore “Impossibile scaricare il payload”](#patch-manager-troubleshooting-linux-4)
+ [Problema: errore “gestore di pacchetti non supportato e combinazione di versione python”](#patch-manager-troubleshooting-linux-5)
+ [Problema:Patch Manager non sta applicando le regole specificate per escludere determinati pacchetti](#patch-manager-troubleshooting-linux-6)
+ [Problema: l'applicazione di patch non va a buon fine e Patch Manager segnala che l'estensione Indicazione nome server a TLS non è disponibile](#patch-manager-troubleshooting-linux-7)
+ [Problema: Patch Manager riporta “Niente più specchi da testare”](#patch-manager-troubleshooting-linux-8)
+ [Problema: l'applicazione di patch non riesce con "Il codice di errore restituito da curl è 23"](#patch-manager-troubleshooting-linux-9)
+ [Problema: l'applicazione della patch non riesce e viene visualizzato il messaggio "Errore durante la decompressione del pacchetto rpm..."](#error-unpacking-rpm)
+ [Problema: l'applicazione di patch non riesce con «riscontrare un errore sul lato del servizio durante il caricamento dell'inventario»](#inventory-upload-error)
+ [Problema: l'applicazione di patch non riesce e viene visualizzato il messaggio "Sono stati rilevati errori durante il download dei pacchetti"](#errors-while-downloading)
+ [Problema: l'applicazione della patch non riesce a causa di un errore di memoria esaurita (OOM)](#patch-manager-troubleshooting-linux-oom)
+ [Problema: l'applicazione di patch non riesce e viene visualizzato il messaggio "Impossibile verificare le seguenti firme perché la chiave pubblica non è disponibile"](#public-key-unavailable)
+ [Problema: l'applicazione della patch non riesce e viene visualizzato il messaggio '' NoMoreMirrorsRepoError](#no-more-mirrors-repo-error)
+ [Problema: l'applicazione di patch non riesce e viene visualizzato il messaggio "Impossibile scaricare il payload"](#payload-download-error)
+ [Problema: l'applicazione di patch non riesce e viene visualizzato il messaggio “Il frontend dpkg è bloccato da un altro processo”](#dpkg-frontend-locked)
+ [Problema: l'applicazione di patch su Ubuntu Server non riesce con l'errore “dpkg è stato interrotto”](#dpkg-interrupted)
+ [Problema: il gestore di pacchetti non è in grado di risolvere una dipendenza dal pacchetto](#unresolved-dependency)
+ [Problema: il pacchetto Zypper blocca gli errori di dipendenza sui nodi gestiti SLES](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Problema: impossibile acquisire il blocco. È in corso un'altra operazione di patching.](#patch-manager-troubleshooting-linux-concurrent-lock)
### Problema: errore “Nessun file o directory di questo tipo”
**Problema**: Quando si esegue `AWS-RunPatchBaseline`, l'applicazione di patch non riesce con uno dei seguenti errori.
```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```
```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```
```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```
**Causa 1**: due comandi per eseguire `AWS-RunPatchBaseline` erano in esecuzione nello stesso momento sullo stesso nodo gestito. Questo crea una condizione di competizione che fa sì che le `file patch-baseline-operations*` non sono state create o accessibili correttamente.
**Causa 2**: lo spazio di archiviazione insufficiente rimane sotto la directory `/var`.
**Soluzione 1**: assicurati che nessuna finestra di manutenzione contenga due o più Run Command attività eseguite `AWS-RunPatchBaseline` con lo stesso livello di priorità e eseguite sulla stessa destinazione. IDs In tal caso, riordina la priorità. Run Commandè uno strumento in AWS Systems Manager.
**Soluzione 2**: assicurarsi che una sola finestra di manutenzione per volta stia eseguendo attività Run Command che utilizzano `AWS-RunPatchBaseline` sugli stessi target e sullo stesso programma. In tal caso, modificare la pianificazione.
**Soluzione 3**: Assicurarsi che solo un'associazione State Manager stia eseguendo `AWS-RunPatchBaseline` sulla stessa pianificazione e avendo come target gli stessi nodi gestiti. State Manager è uno strumento di AWS Systems Manager.
**Soluzione 4**: Liberare spazio di archiviazione sufficiente sotto la directory `/var` per i pacchetti di aggiornamento.
### Problema: Errore “un altro processo ha acquisito il blocco yum”
**Problema**: Quando si esegue `AWS-RunPatchBaseline`, l'applicazione di patch ha esito negativo con il seguente errore.
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**Causa**: Il documento `AWS-RunPatchBaseline` è stato avviato in esecuzione sul nodo gestito in cui è già in esecuzione in un'altra operazione e ha acquisito il processo di gestione di pacchetti `yum`.
**Soluzione**: assicurati che non vi siano associazioni State Manager, attività di finestra di manutenzione o altre configurazioni che eseguono `AWS-RunPatchBaseline` su una pianificazione che abbiano come target lo stesso nodo gestito nello stesso momento.
### Problema: errore “Autorizzazione negata/non riuscita a eseguire i comandi”
**Problema**: Quando si esegue `AWS-RunPatchBaseline`, l'applicazione di patch ha esito negativo con il seguente errore.
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**Causa**: `/var/lib/amazon/` potrebbe essere montato con autorizzazioni `noexec`. Questo è un problema, perché SSM Agent scarica gli script del payload in `/var/lib/amazon/ssm` e li esegue da quella posizione.
**Soluzione**: Assicurarsi di aver configurato partizioni esclusive per `/var/log/amazon` e `/var/lib/amazon`, e che sono montate con autorizzazioni `exec`.
### Problema: errore “Impossibile scaricare il payload”
**Problema**: Quando si esegue `AWS-RunPatchBaseline`, l'applicazione di patch ha esito negativo con il seguente errore.
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**Causa**: il nodo gestito non dispone delle autorizzazioni necessarie per accedere al bucket Amazon Simple Storage Service (Amazon S3) specificato.
**Soluzione**: Aggiornare la configurazione di rete in modo che gli endpoint S3 siano raggiungibili. Per ulteriori informazioni, consulta le informazioni sugli accessi necessari ai bucket S3 per Patch Manager in [SSM Agentcomunicazioni con AWS bucket S3 gestiti](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
### Problema: errore “gestore di pacchetti non supportato e combinazione di versione python”
**Problema**: Quando si esegue `AWS-RunPatchBaseline`, l'applicazione di patch ha esito negativo con il seguente errore.
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**Causa**: non è installata una versione supportata di python3 sull’istanza Debian Server oppure Ubuntu Server.
**Soluzione**: installa una versione supportata di Python3 (da 3.0 a 3.12) sul server, necessaria per i nodi gestiti Debian Server e Ubuntu Server.
### Problema:Patch Manager non sta applicando le regole specificate per escludere determinati pacchetti
**Problema**: Si è tentato di escludere determinati pacchetti specificandoli nel file `/etc/yum.conf`, nel formato `exclude=package-name`, ma non sono esclusi durante l'operazione Patch Manager `Install`.
**Causa**: Patch Manager non incorpora esclusioni specificate nel file `/etc/yum.conf`.
**Soluzione**: Per escludere pacchetti specifici, creare una baseline delle patch personalizzata e creare una norma per escludere i pacchetti che non si desidera installare.
### Problema: l'applicazione di patch non va a buon fine e Patch Manager segnala che l'estensione Indicazione nome server a TLS non è disponibile
**Problema**: L'operazione di applicazione di patch emette il seguente messaggio.
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**Causa**: questo messaggio non indica un errore. Invece, è un avvertimento che la versione precedente di Python distribuita con il sistema operativo non supporta l'indicazione del nome del server TLS. Lo script di payload della patch Systems Manager emette questo avviso quando ci si connette a AWS APIs quel supporto SNI.
**Soluzione**: Per risolvere eventuali errori di applicazione di patch quando viene segnalato questo messaggio, esaminare il contenuto dei file `stdout` e `stderr`. Se non hai configurato la patch baseline per archiviare questi file in un bucket S3 o in Amazon CloudWatch Logs, puoi localizzare i file nella seguente posizione sul tuo nodo gestito Linux.
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### Problema: Patch Manager riporta “Niente più specchi da testare”
**Problema**: L'operazione di applicazione di patch emette il seguente messaggio.
```
[Errno 256] No more mirrors to try.
```
**Causa**: i repository configurati sul nodo gestito non funzionano correttamente. Tra le cause possibili sono incluse:
+ La cache `yum` è danneggiata.
+ Impossibile raggiungere un URL del repository a causa di problemi relativi alla rete.
**Soluzione**: Patch Manager utilizza il gestore di pacchetti predefinito del nodo gestito per eseguire l'operazione di patch. Verificare che i repository siano configurati e funzionino correttamente.
### Problema: l'applicazione di patch non riesce con "Il codice di errore restituito da curl è 23"
**Problema**: un'operazione di applicazione di patch che utilizza `AWS-RunPatchBaseline` non riesce con un errore simile al seguente:
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**Causa**: lo strumento curl in uso sui sistemi non dispone delle autorizzazioni necessarie per scrivere sul filesystem. Ciò può verificarsi se lo strumento curl predefinito del gestore di pacchetti è stato sostituito da una versione diversa, ad esempio una versione installata con snap.
**Soluzione**: se la versione curl fornita dal gestore di pacchetti è stata disinstallata quando è stata installata una versione diversa, reinstallala.
Se devi mantenere installate più versioni di curl, assicurati che la versione associata al gestore di pacchetti si trovi nella prima directory elencata nella variabile `PATH`. È possibile verificarlo eseguendo il comando `echo $PATH` per vedere l'ordine corrente delle directory in cui viene controllata la presenza di file eseguibili sul sistema.
### Problema: l'applicazione della patch non riesce e viene visualizzato il messaggio "Errore durante la decompressione del pacchetto rpm..."
**Problema**: un'operazione di applicazione di patch non riesce con un errore simile al seguente:
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**Causa 1**: quando un particolare pacchetto è presente in più programmi di installazione di pacchetti, ad esempio `pip` e `yum` oppure `dnf`, possono verificarsi conflitti quando si utilizza il gestore di pacchetti predefinito.
Un esempio comune si verifica con il pacchetto `urllib3`, che si trova in `pip`, `yum` e `dnf`.
**Causa 2**: il pacchetto `python-urllib3` risulta danneggiato. Ciò può accadere se i file del pacchetto sono stati installati o aggiornati da `pip` dopo che il pacchetto `rpm` era stato precedentemente installato da `yum` o `dnf`.
**Soluzione**: rimuovi il pacchetto `python-urllib3` da pip eseguendo il comando `sudo pip uninstall urllib3`, mantenendo il pacchetto solo nel gestore di pacchetti predefinito (`yum` o `dnf`).
### Problema: l'applicazione di patch non riesce con «riscontrare un errore sul lato del servizio durante il caricamento dell'inventario»
**Problema**: durante l'esecuzione del `AWS-RunPatchBaseline` documento, viene visualizzato il seguente messaggio di errore:
```
Encounter service side error when uploading the inventory
```
**Causa**: due comandi per eseguire `AWS-RunPatchBaseline` erano in esecuzione nello stesso momento sullo stesso nodo gestito. Ciò crea una condizione di gara durante l'inizializzazione del client boto3 durante le operazioni di patching.
**Soluzione**: assicurati che non vi siano associazioni State Manager, attività di finestra di manutenzione o altre configurazioni che eseguono `AWS-RunPatchBaseline` su una pianificazione che abbiano come target lo stesso nodo gestito nello stesso momento.
### Problema: l'applicazione di patch non riesce e viene visualizzato il messaggio "Sono stati rilevati errori durante il download dei pacchetti"
**Problema**: durante l'applicazione di patch, viene visualizzato un errore simile al seguente:
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**Causa**: questo errore può verificarsi quando la memoria disponibile su un nodo gestito è insufficiente.
**Soluzione**: configura la memoria di swap o aggiorna l'istanza a un tipo diverso per aumentare il supporto di memoria. Quindi inizia una nuova operazione di applicazione di patch.
### Problema: l'applicazione della patch non riesce a causa di un errore di memoria esaurita (OOM)
**Problema**: quando si esegue`AWS-RunPatchBaseline`, l'operazione di applicazione delle patch non riesce a causa della memoria insufficiente sul nodo gestito. È possibile che vengano visualizzati errori come`Cannot allocate memory`, `Killed` (dal killer OOM di Linux) oppure che l'operazione non riesca in modo imprevisto. È più probabile che questo errore si verifichi nelle istanze con meno di 1 GB di RAM, ma può interessare anche le istanze con più memoria quando è disponibile un gran numero di aggiornamenti.
**Causa**: Patch Manager esegue le operazioni di patching utilizzando il gestore di pacchetti nativo sul nodo gestito. La memoria richiesta durante un'operazione di patching dipende da diversi fattori, tra cui:
+ Il numero di pacchetti installati e gli aggiornamenti disponibili nel nodo gestito.
+ Il gestore di pacchetti in uso e le sue caratteristiche di memoria.
+ Altri processi in esecuzione sul nodo gestito al momento dell'operazione di patching.
I nodi gestiti con un numero elevato di pacchetti installati o un gran numero di aggiornamenti disponibili richiedono più memoria durante le operazioni di patching. Quando la memoria disponibile è insufficiente, il processo di applicazione delle patch fallirà e verrà chiuso con un errore. Il sistema operativo può anche interrompere il processo di applicazione delle patch.
**Soluzione**: prova una o più delle seguenti soluzioni:
+ Pianifica le operazioni di patching durante i periodi di bassa attività di carico di lavoro sul nodo gestito, ad esempio utilizzando finestre di manutenzione.
+ Aggiorna l'istanza a un tipo con più memoria.
+ Configura la memoria di swap sul nodo gestito. Tieni presente che nelle istanze con un throughput EBS limitato, un uso intensivo dello swap può causare un peggioramento delle prestazioni.
+ Rivedi e riduci il numero di processi in esecuzione sul nodo gestito durante le operazioni di patching.
### Problema: l'applicazione di patch non riesce e viene visualizzato il messaggio "Impossibile verificare le seguenti firme perché la chiave pubblica non è disponibile"
**Problema**: un'operazione di applicazione di patch non riesce su Ubuntu Server con un errore simile al seguente:
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**Causa**: la chiave GNU Privacy Guard (GPG) è scaduta o risulta mancante.
**Soluzione**: aggiorna la chiave GPG o aggiungi di nuovo la chiave.
Ad esempio, utilizzando l'errore mostrato in precedenza, vediamo che la chiave `467B942D3A79BD29` risulta mancante e deve essere aggiunta. Per farlo, esegui uno dei comandi seguenti:
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
Oppure, per aggiornare tutte le chiavi, esegui il seguente comando:
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
Se l'errore si ripresenta dopo questa operazione, consigliamo di segnalare il problema all'organizzazione che gestisce il repository. Fino a quando non sarà disponibile una correzione, è possibile modificare il file `/etc/apt/sources.list` in modo da omettere il repository durante il processo di applicazione di patch.
A tale scopo, apri il file `sources.list` per modificarlo, individua la riga del repository e inserisci un carattere `#` all'inizio della riga per commentarla. Salva e chiudi il file.
### Problema: l'applicazione della patch non riesce e viene visualizzato il messaggio '' NoMoreMirrorsRepoError
**Problema**: viene visualizzato un errore simile al seguente:
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**Causa**: si è verificato un errore nel repository di origine.
**Soluzione**: si consiglia di segnalare il problema all'organizzazione che gestisce il repository. Finché l'errore non viene corretto, è possibile disabilitare il repository a livello di sistema operativo. A tale scopo, esegui il comando seguente, sostituendo il valore per *repo-name* con il nome del repository:
```
yum-config-manager --disable repo-name
```
Di seguito è riportato un esempio.
```
yum-config-manager --disable pgdg94
```
Dopo aver eseguito questo comando, esegui un'altra operazione di applicazione di patch.
### Problema: l'applicazione di patch non riesce e viene visualizzato il messaggio "Impossibile scaricare il payload"
**Problema**: viene visualizzato un errore simile al seguente:
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**Causa**: la configurazione del nodo gestito contiene errori o è incompleta.
**Soluzione**: assicurati che il nodo gestito sia configurato con quanto segue:
+ Regola TCP 443 in uscita nel gruppo di sicurezza.
+ Regola TCP 443 in uscita in NACL.
+ Regola TCP 1024-65535 in entrata in NACL.
+ NAT/IGW nella tabella di routing per fornire connettività a un endpoint S3. Se l'istanza non dispone di accesso a Internet, forniscile la connettività con l'endpoint S3. A tale scopo, aggiungi un endpoint gateway S3 nel VPC e integralo con la tabella di routing del nodo gestito.
### Problema: l'applicazione di patch non riesce e viene visualizzato il messaggio “Il frontend dpkg è bloccato da un altro processo”
**Problema**: un'operazione di applicazione di patch non riesce con un errore simile al seguente:
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**Causa**: il gestore di pacchetti sta già eseguendo un altro processo su un nodo gestito a livello di sistema operativo. Se il completamento dell'altro processo richiede molto tempo, l'operazione di applicazione di patch di Patch Manager può andare in timeout e non riuscire.
**Soluzione**: una volta completato l'altro processo che utilizza il gestore di pacchetti, esegui una nuova operazione di applicazione di patch.
### Problema: l'applicazione di patch su Ubuntu Server non riesce con l'errore “dpkg è stato interrotto”
**Problema**: su Ubuntu Server, un'operazione di applicazione di patch non riesce con un errore simile al seguente:
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**Causa**: uno o più pacchetti non sono configurati correttamente.
**Soluzione**: Eseguire i seguenti passaggi:
1. Controlla quali pacchetti sono interessati e quali sono i problemi di ogni pacchetto eseguendo i seguenti comandi, uno alla volta:
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. Correggi i pacchetti che presentano problemi eseguendo il seguente comando:
```
sudo dpkg --configure -a
```
1. Se il comando precedente non ha risolto completamente il problema, esegui il seguente comando:
```
sudo apt --fix-broken install
```
### Problema: il gestore di pacchetti non è in grado di risolvere una dipendenza dal pacchetto
**Problema**: il gestore di pacchetti nativo sul nodo gestito non è in grado di risolvere una dipendenza dal pacchetto e l'applicazione di patch non riesce. Il seguente esempio di messaggio di errore indica questo tipo di errore su un sistema operativo che utilizza `yum` come gestore di pacchetti.
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**Causa**: nei sistemi operativi Linux, Patch Manager utilizza il gestore di pacchetti nativo sul computer per eseguire operazioni di applicazione di patch, ad esempio, `yum`, `dnf`, `apt` e `zypper`. Le applicazioni rilevano, installano, aggiornano o rimuovono automaticamente i pacchetti dipendenti in base alle esigenze. Tuttavia, alcune condizioni possono impedire al gestore di pacchetti di completare un'operazione di dipendenza, ad esempio:
+ Sul sistema operativo sono configurati più repository in conflitto.
+ L'URL di un repository remoto è inaccessibile a causa di problemi relativi alla rete.
+ Nel repository è stato trovato un pacchetto per l'architettura sbagliata.
**Soluzione**: l'applicazione di patch potrebbe non riuscire a causa di un problema di dipendenza per un'ampia gamma di motivi. Pertanto, ti consigliamo di contattarci Supporto AWS per ricevere assistenza nella risoluzione dei problemi.
### Problema: il pacchetto Zypper blocca gli errori di dipendenza sui nodi gestiti SLES
**Problema**: quando si esegue `AWS-RunPatchBaseline` l'`Install`operazione su SUSE Linux Enterprise Server istanze, l'applicazione delle patch fallisce con errori di controllo delle dipendenze relativi ai blocchi dei pacchetti. Potrebbe essere visualizzato un messaggio di errore simile al seguente.
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
In questo esempio, il pacchetto `mock-pkg-standalone` è bloccato, cosa che è possibile verificare eseguendo `sudo zypper locks` e cercando il nome del pacchetto nell'output.
Oppure potresti vedere delle voci di log che indicano errori nel controllo delle dipendenze:
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**Nota**
Questo problema si verifica solo durante `Install` le operazioni. `Scan`le operazioni non applicano blocchi ai pacchetti e non sono influenzate dai blocchi esistenti.»
**Causa**: questo errore si verifica quando i blocchi dei pacchetti zypper impediscono l'installazione o l'aggiornamento dei pacchetti a causa di conflitti di dipendenza. I lucchetti dei pacchetti possono essere presenti per diversi motivi:
+ **Blocchi applicati dal cliente**: tu o il tuo amministratore di sistema avete bloccato manualmente i pacchetti usando comandi zypper come. `zypper addlock`
+ **Patch Manager ha rifiutato le patch**: applica Patch Manager automaticamente i blocchi dei pacchetti quando specifichi i pacchetti nell'elenco delle **patch rifiutate baseline delle patch** per impedirne l'installazione.
+ **Blocchi residui dovuti a operazioni interrotte**: in rari casi, se un'operazione di patch è stata interrotta (ad esempio dal riavvio del sistema) prima di poter eliminare i blocchi temporanei, i blocchi residui dei pacchetti Patch Manager potrebbero rimanere sul nodo gestito.
**Soluzione**: per risolvere i problemi di blocco dei pacchetti zypper, segui questi passaggi in base alla causa:
**Fase 1: identificare i pacchetti bloccati**
Connettersi SLES al nodo ed eseguire il comando seguente per elencare tutti i pacchetti attualmente bloccati:
```
sudo zypper locks
```
**Fase 2: Determinare l'origine dei blocchi**
+ Se i pacchetti bloccati sono quelli che hai bloccato intenzionalmente per la stabilità del sistema, valuta se devono rimanere bloccati o se possono essere temporaneamente sbloccati per essere patchati.
+ Se i pacchetti bloccati corrispondono alle voci dell'elenco delle tue baseline delle patch **Patch rifiutate**, si tratta probabilmente di blocchi residui dovuti a un'operazione di patch interrotta. Durante le normali operazioni, Patch Manager applica temporaneamente questi blocchi e li rimuove automaticamente al termine dell'operazione. È possibile rimuovere i pacchetti dall'elenco dei pacchetti rifiutati o modificare le regole della baseline delle patch.
+ Se non riconosci i pacchetti bloccati e non sono stati bloccati intenzionalmente, potrebbero essere blocchi residui di una precedente operazione di patch interrotta.
**Fase 3: rimuovere i lucchetti in modo appropriato**
Utilizza il seguente comando per rimuovere blocchi specifici dei pacchetti:
```
sudo zypper removelock package-name
```
Per rimuovere tutti i blocchi dei pacchetti (usare con cautela), esegui:
```
sudo zypper cleanlocks
```
**Fase 4: aggiorna la baseline delle patch (se applicabile)**
Se i blocchi sono stati causati da patch rifiutate nella baseline delle patch:
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Scegli la scheda **baseline delle patch** e quindi scegli la tua baseline delle patch personalizzata.
1. Scegli **Operazioni**, **Modifica baseline delle patch**.
1. Nella sezione **Patch rifiutate**, esaminate i pacchetti elencati e rimuovete quelli di cui dovrebbe essere consentita l'installazione.
1. Scegli **Save changes** (Salva modifiche).
**Fase 5: Riprovare a eseguire l'operazione con la patch**
Dopo aver rimosso i blocchi problematici e aggiornato la baseline delle patch, se necessario, esegui nuovamente il documento `AWS-RunPatchBaseline`.
**Nota**
Quando Patch Manager applica blocchi per le patch rifiutate durante `Install` le operazioni, è progettato per ripulire automaticamente questi blocchi al termine dell'operazione di patch. Se vedi questi blocchi durante l'esecuzione`sudo zypper locks`, significa che una precedente operazione di patch è stata interrotta prima che potesse avvenire la pulizia. Tuttavia, se l'operazione di una patch viene interrotta, potrebbe essere necessaria la pulizia manuale come descritto in questa procedura.
**Prevenzione**: per evitare future controversie tra zypper lock:
+ Esamina attentamente l'elenco delle patch rifiutate della tua baseline delle patch per assicurarti che includa solo i pacchetti che desideri veramente escludere.
+ Evita di bloccare manualmente i pacchetti che potrebbero essere necessari come dipendenze per gli aggiornamenti di sicurezza.
+ Se devi bloccare i pacchetti manualmente, documenta i motivi e rivedi periodicamente i blocchi.
+ Assicurati che le operazioni sulle patch vengano completate correttamente e non vengano interrotte dai riavvii del sistema o da altri fattori.
+ Monitora le operazioni di patch fino al completamento ed evita di interromperle con riavvii del sistema o altre azioni che potrebbero impedire la corretta pulizia dei blocchi temporanei.
### Problema: impossibile acquisire il blocco. È in corso un'altra operazione di patching.
**Problema**: quando si esegue`AWS-RunPatchBaseline`, l'applicazione della patch non riesce con il codice di errore 4 e il seguente messaggio di errore.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Causa**: questo errore si verifica quando più operazioni di patching tentano di essere eseguite contemporaneamente sullo stesso nodo gestito. Il file di blocco impedisce operazioni di patch simultanee per evitare conflitti e garantire la stabilità del sistema.
**Soluzione**: assicuratevi che le operazioni di patching non siano programmate per essere eseguite contemporaneamente sullo stesso nodo gestito. Esamina le seguenti configurazioni per identificare e risolvere i conflitti di pianificazione:
+ **Politiche di patch**: controllate le configurazioni delle policy di patch di Quick Setup per assicurarvi che non si sovrappongano ad altre pianificazioni di patch.
+ **Finestre di manutenzione**: esaminate le associazioni delle finestre di manutenzione per verificare che più finestre non riguardino gli stessi nodi gestiti con attività di patch in momenti sovrapposti.
+ Operazioni **manuali Patch now: evita di avviare operazioni** manuali di **Patch now mentre è in corso l'applicazione delle patch** pianificate.
## Errori durante l'esecuzione di `AWS-RunPatchBaseline` su Windows Server
**Topics**
+ [Problema: coppie di prodotti non corrispondenti family/product](#patch-manager-troubleshooting-product-family-mismatch)
+ [Problema: `AWS-RunPatchBaseline` restituisce un `HRESULT` (Windows Server)](#patch-manager-troubleshooting-hresult)
+ [Problema: il nodo gestito non ha accesso a Windows Update Catalog o WSUS](#patch-manager-troubleshooting-instance-access)
+ [Problema: il PatchBaselineOperations PowerShell modulo non è scaricabile](#patch-manager-troubleshooting-module-not-downloadable)
+ [Problema: patch mancanti](#patch-manager-troubleshooting-missing-patches)
+ [Problema: impossibile acquisire il blocco. È in corso un'altra operazione di patching.](#patch-manager-troubleshooting-windows-concurrent-lock)
### Problema: coppie di prodotti non corrispondenti family/product
**Problema**: Quando si crea una baseline delle patch nella console Systems Manager, è necessario specificare una famiglia di prodotti e un prodotto. Ad esempio si potrebbe scegliere:
+ **Product family (Famiglia di prodotti)**: `Office`
**Product (Prodotto)**: `Office 2016`
**Causa**: se si tenta di creare una patch di base con una family/product coppia di prodotti non corrispondenti, viene visualizzato un messaggio di errore. Di seguito sono elencati i motivi per cui questo può verificarsi:
+ Hai selezionato una famiglia di prodotti e una coppia di prodotti validi ma poi hai rimosso la selezione della famiglia di prodotti.
+ È stato scelto un prodotto dal sottoelenco **Obsolete or mismatched options (Opzioni obsolete o non corrispondenti)** anziché dal sottoelenco **Available and matching options (Opzioni disponibili e corrispondenti)**.
Elementi del prodotto La sottolista di **opzioni obsolete o non corrispondenti** potrebbe essere stata inserita erroneamente tramite un comando SDK o (). AWS Command Line Interface AWS CLI`create-patch-baseline` Questo potrebbe significare che è stato introdotto un errore di digitazione o che un prodotto è stato assegnato alla famiglia di prodotti sbagliata. Un prodotto viene incluso anche nel sottoelenco **Opzioni obsolete o non corrispondenti**, se è stato specificato per una baseline delle patch precedente, ma in Microsoft non sono disponibili patch.
**Soluzione**: Per evitare che il problema si presenti nella console, è preferibile scegliere sempre le opzioni dai sottoelenchi **Currently available (Attualmente disponibili)**.
È inoltre possibile visualizzare i prodotti per i quali attualmente sono disponibili patch utilizzando il 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)` in AWS CLI o il comando 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)`.
### Problema: `AWS-RunPatchBaseline` restituisce un `HRESULT` (Windows Server)
**Problema:** hai ricevuto un errore simile al seguente:
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**Causa**: questo output indica che Windows Update nativo non è APIs stato in grado di eseguire le operazioni di applicazione delle patch.
**Soluzione**: controlla il codice `HResult` negli argomenti di microsoft.com seguenti per identificare le fasi di risoluzione dei problemi per risolvere l'errore:
+ [Codici di errore di Windows Update per componente](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Errori comuni e mitigazione di Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### Problema: il nodo gestito non ha accesso a Windows Update Catalog o WSUS
**Problema:** hai ricevuto un errore simile al seguente:
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**Causa**: questo errore potrebbe essere correlato ai componenti di Windows Update o a una mancanza di connettività al catalogo di Windows Update o Windows Server Update Services (WSUS).
**Soluzione**: verifica che il nodo gestito disponga di connettività al [Catalogo Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx) tramite un gateway Internet, un gateway NAT o un'istanza NAT. Se si utilizza WSUS, verificare che il nodo gestito disponga della connettività al server WSUS nell'ambiente in uso. Se la connettività è disponibile per la destinazione desiderata, consulta la documentazione Microsoft per altre potenziali cause di `HResult 0x80072EE2`. Questo potrebbe indicare un problema a livello di sistema operativo.
### Problema: il PatchBaselineOperations PowerShell modulo non è scaricabile
**Problema:** hai ricevuto un errore simile al seguente.
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**Soluzione**: controlla la connettività del nodo gestito e le autorizzazioni per Amazon Simple Storage Service (Amazon S3). Il ruolo del nodo gestito AWS Identity and Access Management (IAM) deve utilizzare le autorizzazioni minime citate in. [SSM Agentcomunicazioni con AWS bucket S3 gestiti](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) Il nodo deve comunicare con l'endpoint Amazon S3 tramite l'endpoint gateway Amazon S3, il gateway NAT o il gateway Internet. Per ulteriori informazioni sui requisiti degli endpoint VPC per AWS Systems Manager SSM Agent (SSM Agent), consulta. [Migliora la sicurezza delle istanze EC2 utilizzando gli endpoint VPC per Systems Manager](setup-create-vpc.md)
### Problema: patch mancanti
**Problema**: `AWS-RunPatchbaseline` completato con successo, ma ci sono alcune patch mancanti.
Di seguito sono elencate alcune cause comuni e le loro soluzioni.
**Causa 1**: la baseline non è efficace.
**Soluzione 1**: per verificare se questa è la causa, procedi come indicato di seguito.
1. Apri la AWS Systems Manager console all'indirizzo. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Nel pannello di navigazione, scegli **Run Command**.
1. Seleziona la scheda **Cronologia dei comandi** e quindi seleziona il comando di cui si desidera controllare la baseline.
1. Seleziona il nodo gestito con patch mancanti.
1. Seleziona **Fase 1 - Output ** e trova il valore `BaselineId`.
1. Controlla la [Configurazione della patch](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) assegnata, ovvero il sistema operativo, il nome del prodotto, la classificazione e la gravità per la baseline delle patch.
1. Accedi a [Catalogo Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx).
1. Cerca nell'articolo della Microsoft Knowledge Base (KB) IDs (ad esempio, KB3216916).
1. Verifica che il valore in **Prodotto** corrisponda a quello del tuo nodo e seleziona il **Titolo** corrispondente. Si aprirà una nuova finestra **Dettagli aggiornamento**.
1. Nella scheda **Panoramica**, **classificazione** e **Gravità MSRC** devono corrispondere alla configurazione della baseline delle patch trovata in precedenza.
**Causa 2**: la patch è stata sostituita.
**Soluzione 2**: Per verificare che sia vero, procedi come indicato di seguito.
1. Accedi a [Catalogo Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx).
1. Cerca nell'articolo della Microsoft Knowledge Base (KB) IDs (ad esempio, KB3216916).
1. Verifica che il valore in **Prodotto** corrisponda a quello del tuo nodo e seleziona il **Titolo** corrispondente. Si aprirà una nuova finestra **Dettagli aggiornamento**.
1. Accedi alla scheda **Package details**. Cerca una voce sotto l'intestazione **Questo aggiornamento è stato sostituito dagli aggiornamenti seguenti:**
**Causa 3**: la stessa patch potrebbe avere numeri KB diversi, perché gli aggiornamenti in linea di WSUS e Windows vengono gestiti come canali di rilascio indipendenti da Microsoft.
**Soluzione 3**: verifica l'idoneità della patch. Se il pacchetto non è disponibile in WSUS, installa [Sistema operativo Build 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Se il pacchetto è disponibile per tutte le build del sistema operativo, installa [Build del sistema operativo 18362.1256 e 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).
### Problema: impossibile acquisire il blocco. È in corso un'altra operazione di patching.
**Problema**: quando si esegue`AWS-RunPatchBaseline`, l'applicazione della patch non riesce con il codice di errore 4 e il seguente messaggio di errore.
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Causa**: questo errore si verifica quando più operazioni di patching tentano di essere eseguite contemporaneamente sullo stesso nodo gestito. Il file di blocco impedisce operazioni di patch simultanee per evitare conflitti e garantire la stabilità del sistema.
**Soluzione**: assicuratevi che le operazioni di patching non siano programmate per essere eseguite contemporaneamente sullo stesso nodo gestito. Esamina le seguenti configurazioni per identificare e risolvere i conflitti di pianificazione:
+ **Politiche di patch**: controllate le configurazioni delle policy di patch di Quick Setup per assicurarvi che non si sovrappongano ad altre pianificazioni di patch.
+ **Finestre di manutenzione**: esaminate le associazioni delle finestre di manutenzione per verificare che più finestre non riguardino gli stessi nodi gestiti con attività di patch in momenti sovrapposti.
+ Operazioni **manuali Patch now: evita di avviare operazioni** manuali di **Patch now mentre è in corso l'applicazione delle patch** pianificate.
## Errori durante l'esecuzione `AWS-RunPatchBaseline` su macOS
**Topics**
+ [Problema: impossibile acquisire il blocco. È in corso un'altra operazione di patching.](#patch-manager-troubleshooting-macos-concurrent-lock)
### Problema: impossibile acquisire il blocco. È in corso un'altra operazione di patching.
**Problema**: quando si esegue`AWS-RunPatchBaseline`, l'applicazione della patch non riesce con il codice di errore 4 e il seguente messaggio di errore.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Causa**: questo errore si verifica quando più operazioni di patching tentano di essere eseguite contemporaneamente sullo stesso nodo gestito. Il file di blocco impedisce operazioni di patch simultanee per evitare conflitti e garantire la stabilità del sistema.
**Soluzione**: assicuratevi che le operazioni di patching non siano programmate per essere eseguite contemporaneamente sullo stesso nodo gestito. Esamina le seguenti configurazioni per identificare e risolvere i conflitti di pianificazione:
+ **Politiche di patch**: controllate le configurazioni delle policy di patch di Quick Setup per assicurarvi che non si sovrappongano ad altre pianificazioni di patch.
+ **Finestre di manutenzione**: esaminate le associazioni delle finestre di manutenzione per verificare che più finestre non riguardino gli stessi nodi gestiti con attività di patch in momenti sovrapposti.
+ Operazioni **manuali Patch now: evita di avviare operazioni** manuali di **Patch now mentre è in corso l'applicazione delle patch** pianificate.
## Utilizzo dei runbook di automazione Supporto AWS
Supporto AWS fornisce due runbook di automazione che è possibile utilizzare per risolvere determinati problemi relativi all'applicazione di patch.
+ `AWSSupport-TroubleshootWindowsUpdate` - Il runbook [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) viene utilizzato per identificare problemi che potrebbero causare errori negli aggiornamenti di Windows Server per le istanze Windows Server Amazon Elastic Compute Cloud (Amazon EC2).
+ `AWSSupport-TroubleshootPatchManagerLinux` – Il runbook [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) risolve i problemi più comuni che possono causare un errore di patch sui nodi gestiti basati su Linux tramite Patch Manager. L'obiettivo principale di questo runbook è identificare la causa principale dell'errore del comando patch e suggerire un piano di correzione.
**Nota**
L'esecuzione dei runbook di automazione è a pagamento. Per informazioni, consulta [AWS Systems Manager Pricing for Automation](https://aws.amazon.com/systems-manager/pricing/#Automation).
## Contattare Supporto AWS
Se non riesci a trovare soluzioni per la risoluzione dei problemi in questa sezione o nei problemi di Systems Manager in [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager), e se disponi di un [piano Sviluppatore, Business o Enterprise Supporto](https://aws.amazon.com/premiumsupport/plans), è possibile creare un caso di supporto tecnico a [Supporto AWS](https://aws.amazon.com/premiumsupport/).
Prima di contattare Supporto, raccogli i seguenti articoli:
+ [Log di SSM Agent](ssm-agent-logs.md)
+ Run CommandID comando, ID finestra di manutenzione o ID esecuzione Automation
+ Per i nodi gestiti Windows Server, raccogli anche quanto segue:
+ `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` come descritto nella scheda **Windows** di[Come vengono installate le patch](patch-manager-installing-patches.md)
+ Log degli aggiornamenti di Windows: per Windows Server 2012 R2 e versioni precedenti, usa `%windir%/WindowsUpdate.log`. Per il Windows Server 2016 e versioni successive, esegui il PowerShell comando [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)prima di utilizzarlo `%windir%/WindowsUpdate.log`
+ Per i nodi gestiti da Linux, raccogli anche quanto segue:
+ Il contenuto della directory `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`