• 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à. # 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.