• 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 Strumenti per i nodi
AWS Systems Manager *fornisce i seguenti strumenti per accedere, gestire e configurare i nodi gestiti.* Un nodo gestito è qualsiasi macchina configurata per l'uso con Systems Manager in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types).
**Topics**
+ [
# ConformitàAWS Systems Manager
](systems-manager-compliance.md)
+ [
# AWS Systems Manager Distributor
](distributor.md)
+ [
# AWS Systems Manager Fleet Manager
](fleet-manager.md)
+ [
# AWS Systems Manager Attivazioni ibride
](activations.md)
+ [
# AWS Systems Manager Inventory
](systems-manager-inventory.md)
+ [
# AWS Systems Manager Patch Manager
](patch-manager.md)
+ [
# AWS Systems Manager Run Command
](run-command.md)
+ [
# AWS Systems Manager Session Manager
](session-manager.md)
+ [
# AWS Systems Manager State Manager
](systems-manager-state.md)
# ConformitàAWS Systems Manager
Puoi utilizzare Compliance, uno strumento di AWS Systems Manager, per scansionare la tua flotta di nodi gestiti alla ricerca di conformità delle patch e incongruenze di configurazione. Puoi raccogliere e aggregare dati da più regioni Account AWS e quindi approfondire risorse specifiche non conformi. Per impostazione predefinita, Conformità visualizza i dati di conformità correnti sull'applicazione di patch in Patch Manager e sulle associazioni in State Manager. (Patch Manager e State Manager sono strumenti di AWS Systems Manager.) Per iniziare a utilizzare Conformità, apri la [console di Systems Manager](https://console.aws.amazon.com//systems-manager/compliance). Nel riquadro di navigazione, seleziona **Conformità**.
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).
Conformità offre gli ulteriori vantaggi e funzionalità seguenti:
+ Visualizzazione della cronologia della conformità e monitoraggio delle modifiche per i dati relativi alle patch di Patch Manager e alle associazioni State Manager utilizzando AWS Config.
+ Personalizzazione di Conformità per creare tipi di conformità in base a requisiti aziendali o IT specifici.
+ Risolvi i problemi utilizzando Run Command un altro strumento in AWS Systems ManagerState Manager, o Amazon EventBridge.
+ Trasferisci i dati su Amazon Athena e Amazon Quick per generare report a livello di flotta.
**EventBridge supporto**
Questo strumento Systems Manager è supportato come tipo di *evento* nelle EventBridge regole di Amazon. Per informazioni, consulta [Monitoraggio degli eventi di Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md) e [Riferimento: modelli e tipi di EventBridge eventi Amazon per Systems Manager](reference-eventbridge-events.md).
**Integrazione di Chef InSpec**
Systems Manager si integra con [https://www.chef.io/inspec/](https://www.chef.io/inspec/). InSpec è un framework di runtime open source che consente di creare profili leggibili dall'uomo su Amazon Simple Storage Service (GitHubAmazon S3). È quindi possibile utilizzare Systems Manager per eseguire analisi della conformità e visualizzare i nodi gestiti conformi e non conformi. Per ulteriori informazioni, consulta [Utilizzo di profili Chef InSpec con la conformità Systems Manager](integration-chef-inspec.md).
**Prezzi**
Conformità è disponibile senza costi aggiuntivi. Paghi solo per le risorse che utilizzi. AWS
**Topics**
+ [
# Nozioni di base su Compliance
](compliance-prerequisites.md)
+ [
# Configurazione delle autorizzazioni per la conformità
](compliance-permissions.md)
+ [
# Creazione di una sincronizzazione dei dati delle risorse per Conformità
](compliance-datasync-create.md)
+ [
# Scopri i dettagli sulla conformità
](compliance-about.md)
+ [
# Eliminazione di una sincronizzazione dei dati delle risorse per Compliance
](systems-manager-compliance-delete-RDS.md)
+ [
# Risoluzione dei problemi di conformità mediante EventBridge
](compliance-fixing.md)
+ [
# Assegna metadati di conformità personalizzati utilizzando AWS CLI
](compliance-custom-metadata-cli.md)
# Nozioni di base su Compliance
Per iniziare a utilizzare Compliance, uno strumento di AWS Systems Manager, completare le seguenti attività.
****
| Processo | Ulteriori informazioni |
| --- | --- |
| Compliance opera con i dati delle patch in Patch Manager e le associazioni in State Manager. (Patch Manager e State Manager sono ugualmente strumenti di AWS Systems Manager.) Compliance funziona anche con i tipi di conformità personalizzati nei nodi gestiti tramite Systems Manager. Verifica di aver completato i requisiti di configurazione per le istanze Amazon Elastic Compute Cloud (Amazon EC2) e le macchine non EC2 in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). | [Configurazione della console unificata di Systems Manager per un'organizzazione](systems-manager-setting-up-organizations.md) |
| Aggiorna il ruolo (IAM) AWS Identity and Access Management utilizzato dai nodi gestiti per limitare le autorizzazioni di conformità. | [Configurazione delle autorizzazioni per la conformità](compliance-permissions.md) |
| Se intendi monitorare la conformità delle patch, verifica di aver configurato Patch Manager. Affinché Compliance possa visualizzare i dati di conformità delle patch, è prima necessario eseguire operazioni di applicazione di patch con Patch Manager. | [AWS Systems Manager Patch Manager](patch-manager.md) |
| Se intendi monitorare la conformità delle associazioni, verifica di aver creato associazioni State Manager. Affinché Compliance possa visualizzare i dati di conformità delle associazioni, è necessario creare prima associazioni. | [AWS Systems Manager State Manager](systems-manager-state.md) |
| (Facoltativa) Configurazione del sistema per visualizzare la cronologia della conformità e il monitoraggio delle modifiche. | [Visualizzazione della cronologia e del monitoraggio delle modifiche della configurazione di conformità](compliance-about.md#compliance-history) |
| (Facoltativa) Creazione di tipi di conformità personalizzati. | [Assegna metadati di conformità personalizzati utilizzando AWS CLI](compliance-custom-metadata-cli.md) |
| (Facoltativa) Creazione di una sincronizzazione dei dati delle risorse per aggregare tutti i dati di conformità in un bucket Amazon Simple Storage Service (Amazon S3) di destinazione. | [Creazione di una sincronizzazione dei dati delle risorse per Conformità](compliance-datasync-create.md) |
# Configurazione delle autorizzazioni per la conformità
Come best practice di sicurezza, ti consigliamo di aggiornare il ruolo AWS Identity and Access Management (IAM) utilizzato dai tuoi nodi gestiti con le seguenti autorizzazioni per limitare la capacità del nodo di utilizzare l'azione [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API. Questa azione API registra un tipo di conformità e altri dettagli di conformità su una risorsa designata, come un' EC2 istanza Amazon o un nodo gestito.
Se il tuo nodo è un' EC2 istanza Amazon, devi aggiornare il profilo dell'istanza IAM utilizzato dall'istanza con le seguenti autorizzazioni. Per ulteriori informazioni sui profili di istanza per le EC2 istanze gestite da Systems Manager, vedere[Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md). Per altri tipi di nodi gestiti, aggiorna il ruolo IAM utilizzato dal nodo con le seguenti autorizzazioni. Per ulteriori informazioni, consulta [Aggiornare autorizzazioni per un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) nella *Guida per l'utente IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:SourceInstanceARN": "${ec2:SourceInstanceARN}"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ssm:SourceInstanceARN": "${ssm:SourceInstanceARN}"
}
}
}
]
}
```
------
# Creazione di una sincronizzazione dei dati delle risorse per Conformità
Puoi utilizzare la funzionalità di sincronizzazione dei dati delle risorse AWS Systems Manager per inviare dati di conformità da tutti i nodi gestiti a un bucket Amazon Simple Storage Service (Amazon S3) di destinazione. Quando crei la sincronizzazione, puoi specificare nodi gestiti da più nodi e il tuo Account AWS ambiente Regioni AWS[ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). La sincronizzazione dei dati delle risorse aggiorna quindi automaticamente i dati centralizzati quando vengono raccolti nuovi dati di conformità. Con tutti i dati di conformità archiviati in un bucket S3 di destinazione, puoi utilizzare servizi come Amazon Athena e Amazon Quick per interrogare e analizzare i dati aggregati. La configurazione della sincronizzazione dei dati delle risorse per Conformità è un'operazione una tantum.
Utilizza la procedura seguente per creare una sincronizzazione dei dati delle risorse per Conformità con la Console di gestione AWS.
**Creazione e configurazione di un bucket S3 per la sincronizzazione dei dati della risorsa (console)**
1. Apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Crea un bucket in cui archiviare i dati di conformità aggregati. Per ulteriori informazioni, consulta [Create a Bucket (Creazione di un bucket)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) nella *Guida per l'utente di Amazon Simple Storage Service*. Prendi nota del nome del bucket e del Regione AWS luogo in cui lo hai creato.
1. Apri il bucket, scegli la scheda **Autorizzazioni**, quindi **Policy di bucket**.
1. Copia e incolla la policy di bucket seguente nell'editor di policy. Sostituisci amzn-s3-demo-bucket e *Account-ID* con il nome del bucket S3 che hai creato e un ID valido. Account AWS Facoltativamente, sostituirlo *Bucket-Prefix* con il nome di un prefisso Amazon S3 (sottodirectory). Se non hai creato un prefisso, rimuovi*Bucket-Prefix*/dall'ARN nella policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/Bucket-Prefix/*/accountid=111122223333/*"],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}
```
------
**Come creare una sincronizzazione dei dati delle risorse**
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 **Fleet Manager**.
1. Scegliere **Account management (Gestione account)**, **Resource Data Syncs (Sincronizzazioni dei dati delle risorse)** e quindi **Create resource data sync (Crea sincronizzazione dati risorsa)**.
1. Nel campo **Sync name (Nome sincronizzazione)** digitare un nome per la configurazione di sincronizzazione.
1. Nel campo **Nome del bucket**, digita il nome del bucket Amazon S3 creato all'inizio di questa procedura.
1. (Facoltativo) Nel campo **Prefisso bucket**, inserisci il nome del prefisso di un bucket S3 (sottodirectory).
1. Nel campo **Regione bucket**, scegli **Questa Regione**, se il bucket S3 creato si trova nella Regione AWS corrente. Se il bucket si trova in un'altra regione Regione AWS, scegli **Un'altra regione** e inserisci il nome della regione.
**Nota**
Se la sincronizzazione e il bucket S3 target si trovano in Regioni diverse, potrebbero essere applicati i prezzi per il trasferimento dei dati. Per ulteriori informazioni, consulta [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/).
1. Scegli **Create** (Crea).
# Scopri i dettagli sulla conformità
Compliance, uno strumento in AWS Systems Manager grado di raccogliere e riportare dati sullo stato delle patch nelle Patch Manager patch e nelle associazioni in. State Manager (Patch Managere State Manager sono presenti anche entrambi gli strumenti in.) AWS Systems Manager Conformità riporta inoltre tipi di conformità personalizzati specificati per i nodi gestiti. Questa sezione contiene informazioni dettagliate su ognuno di questi tipi di conformità e su come visualizzare i dati di conformità di Systems Manager. Include inoltre informazioni su come visualizzare la cronologia della conformità e il monitoraggio delle modifiche.
**Nota**
Systems Manager si integra con [https://www.chef.io/inspec/](https://www.chef.io/inspec/). InSpec è un framework di runtime open source che consente di creare profili leggibili dall'uomo su Amazon Simple Storage Service (GitHubAmazon S3). È quindi possibile utilizzare Systems Manager per eseguire analisi della conformità e visualizzare le istanze conformi e non conformi. Per ulteriori informazioni, consulta [Utilizzo di profili Chef InSpec con la conformità Systems Manager](integration-chef-inspec.md).
## Informazioni sulla conformità delle patch
Dopo l'utilizzo di Patch Manager per l'installazione di patch nelle istanze, le informazioni sullo stato di conformità sono immediatamente disponibili nella console oppure in risposta a comandi AWS Command Line Interface (AWS CLI) o a operazioni API corrispondenti di Systems Manager.
Per informazioni sui valori dello stato di conformità delle patch, consulta [Valori dello stato di conformità delle patch](patch-manager-compliance-states.md).
## Informazioni sulla conformità delle associazioni State Manager
Dopo aver creato una o più State Manager associazioni, le informazioni sullo stato di conformità sono immediatamente disponibili nella console o in risposta ai AWS CLI comandi o alle corrispondenti operazioni dell'API Systems Manager. Per le associazioni, Compliance mostra lo stato `Compliant` o `Non-compliant` e il livello di gravità assegnato all'associazione, ad esempio `Critical` o `Medium`.
Quando State Manager esegue un'associazione su un nodo gestito, attiva un processo di aggregazione della conformità, che aggiorna lo stato di conformità per tutte le associazioni su quel nodo. Il valore `ExecutionTime` nei report di conformità indica quando lo stato di conformità è stato acquisito da Systems Manager, non quando l'associazione è stata eseguita sul nodo gestito. Ciò significa che numerose associazioni potrebbero visualizzare valori `ExecutionTime` identici, anche se sono state eseguite in momenti diversi. Per determinare i tempi effettivi di esecuzione delle associazioni, fate riferimento alla cronologia di esecuzione dell'associazione utilizzando il AWS CLI comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association-execution-targets.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association-execution-targets.html)o visualizzando i dettagli di esecuzione nella console.
## Informazioni sulla personalizzazione della conformità
È possibile assegnare metadati di conformità a un nodo gestito. Tali metadati possono quindi essere aggregati ad altri dati di conformità per la creazione di report di conformità. Supponiamo ad esempio che l'azienda esegua le versioni 2.0, 3.0 e 4.0 del software X nei nodi gestiti. Se l'azienda desidera standardizzare la versione 4.0, le istanze che eseguono le versioni 2.0 e 3.0 sono non conformi. È possibile utilizzare l'operazione [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API per annotare in modo esplicito quali nodi gestiti eseguono versioni precedenti del software X. È possibile assegnare metadati di conformità solo utilizzando AWS CLI, AWS Tools for Windows PowerShell o il. SDKs Il comando di esempio riportato di seguito della CLI assegna metadati di conformità a un'istanza gestita e specifica il tipo di conformità nel formato obbligatorio `Custom:`. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id i-1234567890abcdef0 \
--resource-type ManagedInstance \
--compliance-type Custom:SoftwareXCheck \
--execution-summary ExecutionTime=AnyStringToDenoteTimeOrDate \
--items Id=Version2.0,Title=SoftwareXVersion,Severity=CRITICAL,Status=NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id i-1234567890abcdef0 ^
--resource-type ManagedInstance ^
--compliance-type Custom:SoftwareXCheck ^
--execution-summary ExecutionTime=AnyStringToDenoteTimeOrDate ^
--items Id=Version2.0,Title=SoftwareXVersion,Severity=CRITICAL,Status=NON_COMPLIANT
```
------
**Nota**
Il parametro `ResourceType` supporta solo `ManagedInstance`. Se si aggiunge la conformità personalizzata a un dispositivo core gestito AWS IoT Greengrass , è necessario specificare un `ResourceType` di `ManagedInstance`.
I gestori della conformità possono quindi visualizzare riepiloghi o creare report su quali nodi gestiti siano conformi e quali non lo siano. A un nodo è possibile assegnare un massimo di 10 diversi tipi di conformità personalizzati.
Per un esempio di come creare un tipo di conformità personalizzato e visualizzare i dati di conformità, consulta [Assegna metadati di conformità personalizzati utilizzando AWS CLI](compliance-custom-metadata-cli.md).
## Visualizzazione dei dati di conformità correnti
Questa sezione illustra come visualizzare i dati di conformità nella console Systems Manager e mediante AWS CLI. Per informazioni su come visualizzare la cronologia della conformità e il monitoraggio delle modifiche di patch e associazioni, consulta [Visualizzazione della cronologia e del monitoraggio delle modifiche della configurazione di conformità](#compliance-history).
**Topics**
+ [
### Visualizzazione dei dati di conformità correnti (console)
](#compliance-view-results-console)
+ [
### Visualizzazione dei dati di conformità correnti (AWS CLI)
](#compliance-view-data-cli)
### Visualizzazione dei dati di conformità correnti (console)
Per visualizzare i dati di conformità nella console Systems Manager, utilizza la procedura seguente.
**Visualizzazione dei report di conformità correnti nella console 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 riquadro di navigazione, seleziona **Conformità**.
1. Nella sezione **Filtro del pannello di controllo di conformità**, seleziona un'opzione per filtrare i dati di conformità. La sezione **Riepilogo risorse di conformità** mostra il numero di dati di conformità in base al filtro scelto.
1. Per eseguire il drill down in una risorsa per ulteriori informazioni, scorri verso il basso fino all'area **Panoramica dettagliata delle risorse** e scegli l'ID di un nodo gestito.
1. Nella pagina dei dettagli **ID istanza** o in **Nome** seleziona la scheda **Conformità di configurazione** per visualizzare il report dettagliato sulla conformità di configurazione del nodo gestito.
**Nota**
Per informazioni sulla risoluzione dei problemi di conformità, consulta [Risoluzione dei problemi di conformità mediante EventBridge](compliance-fixing.md).
### Visualizzazione dei dati di conformità correnti (AWS CLI)
È possibile visualizzare i riepiloghi dei dati di conformità per le patch, le associazioni e i tipi di conformità personalizzati AWS CLI utilizzando i seguenti AWS CLI comandi.
[https://docs.aws.amazon.com/cli/latest/reference/ssm/list-compliance-summaries.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-compliance-summaries.html)
Restituisce un conteggio riepilogativo dello stato conforme e non conforme delle associazioni in base al filtro specificato. (API:) [ListComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListComplianceSummaries.html)
[https://docs.aws.amazon.com/cli/latest/reference/ssm/list-resource-compliance-summaries.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-resource-compliance-summaries.html)
Restituisce un conteggio riepilogativo a livello di risorsa. Il riepilogo contiene informazioni sullo stato conforme e non conforme e conteggi dettagliati della gravità delle voci di conformità in base alle opzioni di filtro specificate. (API: [ListResourceComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListResourceComplianceSummaries.html))
È possibile visualizzare ulteriori dati di conformità per l'applicazione di patch utilizzando i comandi dell' AWS CLI riportati di seguito.
[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-group-state.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-group-state.html)
Restituisce lo stato di conformità aggregato generale delle patch di un gruppo di patch. (API: [DescribePatchGroupState](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchGroupState.html))
[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patch-states-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patch-states-for-patch-group.html)
Restituisce lo stato generale delle patch del gruppo di patch specificato per le istanze. (API: [DescribeInstancePatchStatesForPatchGroup](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatchStatesForPatchGroup.html))
**Nota**
Per un'illustrazione di come configurare l'applicazione delle patch e visualizzare i dettagli sulla conformità delle patch utilizzando il AWS CLI, vedere. [Tutorial: applicare una patch a un ambiente server utilizzando il AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
## Visualizzazione della cronologia e del monitoraggio delle modifiche della configurazione di conformità
Conformità di Systems Manager mostra i dati di conformità *correnti* relativi all'applicazione delle patch e alle associazioni per i nodi gestiti. È possibile visualizzare la cronologia della conformità delle patch e delle associazioni e il monitoraggio delle modifiche utilizzando. [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/) AWS Config fornisce una visualizzazione dettagliata della configurazione delle AWS risorse del tuo Account AWS. Questo include le relazioni tra le risorse e la maniera in cui sono state configurate in passato, in modo che tu possa vedere come le configurazioni e le relazioni cambiano nel corso del tempo. Per visualizzare la cronologia della conformità e il monitoraggio delle modifiche per l'applicazione delle patch e le associazioni, è necessario abilitare le risorse seguenti in AWS Config:
+ `SSM:PatchCompliance`
+ `SSM:AssociationCompliance`
Per informazioni su come scegliere e configurare queste specifiche risorse in AWS Config, consulta [Scegli quali risorse deve registrare AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html) nella *AWS Config Guida per gli sviluppatori*.
**Nota**
Per informazioni sui AWS Config prezzi, consulta la sezione [Prezzi](https://aws.amazon.com/config/pricing/).
# Eliminazione di una sincronizzazione dei dati delle risorse per Compliance
Se non desideri più utilizzare AWS Systems Manager Compliance per visualizzare i dati sulla conformità, ti consigliamo anche di eliminare le sincronizzazioni dei dati delle risorse utilizzate per la raccolta dei dati sulla conformità.
**Per eliminare una sincronizzazione dei dati delle risorse in Compliance**
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 **Fleet Manager**.
1. Scegliere **Gestione dell'account**, **Sincronizzazione dei dati delle risorse**.
1. Scegliere un sync dall'elenco.
**Importante**
Assicurati di scegliere la sincronizzazione utilizzata per Compliance. Systems Manager supporta la sincronizzazione dei dati delle risorse per molteplici strumenti. Se si sceglie la sincronizzazione errata, è possibile interrompere l'aggregazione dei dati per Systems Manager Explorer o l'Inventario di Systems Manager.
1. Scegli **Elimina**.
1. Elimina il bucket Amazon Simple Storage Service (Amazon S3) in cui sono stati memorizzati i dati. Per informazioni sull'eliminazione di un bucket S3, consulta la pagina [Eliminazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html).
# Risoluzione dei problemi di conformità mediante EventBridge
È possibile risolvere rapidamente i problemi di conformità di patch e associazione utilizzando Run Command, uno strumento di AWS Systems Manager. È possibile scegliere come target l'istanza o le ID AWS IoT Greengrass o i tag del dispositivo principale e lanciare il documento `AWS-RunPatchBaseline` o il documento `AWS-RefreshAssociation`. Se il problema di conformità non viene risolto aggiornando l'associazione o rieseguendo la baseline di patch, è necessario esaminare le associazioni, le baseline di patch o le configurazioni delle istanze per comprendere il motivo per cui le operazioni di Run Command non hanno risolto il problema.
Per ulteriori informazioni sull'applicazione di patch, consulta [AWS Systems Manager Patch Manager](patch-manager.md) e [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
Per ulteriori informazioni sulle associazioni, consulta [Utilizzo delle associazioni in Systems Manager](state-manager-associations.md).
Per ulteriori informazioni sull'esecuzione di un comando, consulta [AWS Systems Manager Run Command](run-command.md).
**Specificare Compliance come destinazione di un evento EventBridge**
È anche possibile configurare Amazon EventBridge in modo che esegua un'operazione in risposta a eventi Systems Manager Compliance. Ad esempio, se l'installazione di aggiornamenti critici delle patch o l'esecuzione di un'associazione che installa software antivirus ha esito negativo in uno o più nodi, è possibile configurare EventBridge in modo da eseguire il documento `AWS-RunPatchBaseline` o `AWS-RefreshAssocation` quando si verifica l'evento Compliance.
Per configurare Compliance come target di un evento EventBridge, utilizza la procedura seguente.
**Per configurare Compliance come destinazione di un evento EventBridge (console)**
1. Apri la console Amazon EventBridge all'indirizzo [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Nel pannello di navigazione, scegli **Regole**.
1. Scegli **Create rule** (Crea regola).
1. Immettere un nome e una descrizione per la regola.
Una regola non può avere lo stesso nome di un'altra regola nella stessa Regione AWS e sullo stesso bus di eventi.
1. Per **Select event bus** (Seleziona bus di eventi), scegli il bus di eventi che desideri associare a questa regola. Se desideri che questa regola risponda ad eventi corrispondenti provenienti dal tuo Account AWS, seleziona **default event bus** (Bus di eventi predefiniti). Quando un Servizio AWS nell'account emette un evento, passa sempre al bus di eventi predefinito dell'account.
1. Per **Rule type** (Tipo di regola), scegli **Rule with an event pattern** (Regola con un modello di eventi).
1. Scegli **Next (Successivo)**.
1. Per **Event source** (Origine evento), scegli **AWS events or EventBridge partner events** (Eventi o eventi di partner EventBridge).
1. Nella sezione **Modello di eventi**, scegli **Modulo di modello di eventi**.
1. Per **Origine evento**, scegli **Servizi AWS**.
1. Per **AWS**, scegli **Systems Manager**.
1. Nel campo **Event Type (Tipo di evento)** scegliere **Compliance (Conformità)**.
1. Per **Specific detail type(s)** (Tipi di dettagli specifici), scegli **Configuration Compliance State Change** (Modifica dello stato di conformità della configurazione).
1. Scegli **Next (Successivo)**.
1. Per **Target types** (Tipi di destinazione), scegli **AWS service** (Servizio ).
1. Per **Select a target** (Seleziona una destinazione), scegli **Systems ManagerRun Command**.
1. Nell'elenco **Document (Documento)**, scegliere un documento Systems Manager (documento SSM) da eseguire quando viene richiamata la destinazione. Ad esempio, scegliere `AWS-RunPatchBaseline`per un evento di patch non conforme o `AWS-RefreshAssociation` per un evento di associazione non conforme.
1. Specificare le informazioni per i campi e i parametri rimanenti.
**Nota**
I campi e i parametri obbligatori sono contrassegnati da un asterisco (\$1) accanto al nome. Per creare un target, è necessario specificare un valore per ogni parametro o campo obbligatorio. In caso contrario, la regola viene creata dal sistema ma non verrà eseguita.
1. Scegli **Next (Successivo)**.
1. (Facoltativo) Inserire uno o più tag per la regola. Per ulteriori informazioni, consulta [Assegnazione di tag alle Your Amazon EventBridge Resources](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html) nella *Guida per l'utente di Amazon EventBridge*.
1. Scegli **Next (Successivo)**.
1. Rivedi i dettagli della regola e scegli **Create rule** (Crea regola).
# Assegna metadati di conformità personalizzati utilizzando AWS CLI
La procedura seguente illustra il processo di utilizzo di AWS Command Line Interface (AWS CLI) per chiamare l'operazione AWS Systems Manager [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API per assegnare metadati di conformità personalizzati a una risorsa. Questa operazione API può anche essere utilizzata per assegnare manualmente metadati di conformità delle patch e delle associazioni a un nodo gestito, come illustrato nella procedura dettagliata seguente. Per ulteriori informazioni sulla personalizzazione della conformità, consulta [Informazioni sulla personalizzazione della conformità](compliance-about.md#compliance-custom).
**Per assegnare metadati di conformità personalizzati a un'istanza gestita (AWS CLI)**
1. 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).
1. Eseguire questo comando per assegnare metadati di conformità personalizzati a un nodo gestito. Sostituisci ogni *example resource placeholder* con le tue informazioni. Il parametro `ResourceType` supporta solo un valore di `ManagedInstance`. Specificate questo valore anche se state assegnando metadati di conformità personalizzati a un dispositivo AWS IoT Greengrass principale gestito.
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Custom:user-defined_string \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value \
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Custom:user-defined_string ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value ^
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
1. Ripetere il passaggio precedente per assegnare ulteriori metadati di conformità personalizzati a uno o più nodi. È anche possibile assegnare manualmente metadati di conformità delle patch o delle associazioni ai nodi gestiti utilizzando i comandi riportati di seguito:
Metadati di conformità delle associazioni
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Association \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value \
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Association ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value ^
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
Metadati di conformità delle patch
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Patch \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value,ExecutionId=user-defined_ID,ExecutionType=Command \
--items Id=for_example, KB12345,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT,Details="{PatchGroup=name_of_group,PatchSeverity=the_patch_severity, for example, CRITICAL}"
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Patch ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value,ExecutionId=user-defined_ID,ExecutionType=Command ^
--items Id=for_example, KB12345,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT,Details="{PatchGroup=name_of_group,PatchSeverity=the_patch_severity, for example, CRITICAL}"
```
------
1. Eseguire questo comando per visualizzare un elenco delle voci di conformità per uno specifico nodo gestito. Utilizzare filtri per esplorare dati di conformità specifici.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-items \
--resource-ids instance_ID \
--resource-types ManagedInstance \
--filters one_or_more_filters
```
------
#### [ Windows ]
```
aws ssm list-compliance-items ^
--resource-ids instance_ID ^
--resource-types ManagedInstance ^
--filters one_or_more_filters
```
------
Gli esempi seguenti illustrano come utilizzare questo comando con i filtri.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-items \
--resource-ids i-02573cafcfEXAMPLE \
--resource-type ManagedInstance \
--filters Key=DocumentName,Values=AWS-RunPowerShellScript Key=Status,Values=NON_COMPLIANT,Type=NotEqual Key=Id,Values=cee20ae7-6388-488e-8be1-a88ccEXAMPLE Key=Severity,Values=UNSPECIFIED
```
------
#### [ Windows ]
```
aws ssm list-compliance-items ^
--resource-ids i-02573cafcfEXAMPLE ^
--resource-type ManagedInstance ^
--filters Key=DocumentName,Values=AWS-RunPowerShellScript Key=Status,Values=NON_COMPLIANT,Type=NotEqual Key=Id,Values=cee20ae7-6388-488e-8be1-a88ccEXAMPLE Key=Severity,Values=UNSPECIFIED
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=OverallSeverity,Values=UNSPECIFIED
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=OverallSeverity,Values=UNSPECIFIED
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=OverallSeverity,Values=UNSPECIFIED Key=ComplianceType,Values=Association Key=InstanceId,Values=i-02573cafcfEXAMPLE
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=OverallSeverity,Values=UNSPECIFIED Key=ComplianceType,Values=Association Key=InstanceId,Values=i-02573cafcfEXAMPLE
```
------
1. Esegui questo comando per visualizzare un riepilogo degli stati di conformità. Utilizzare filtri per esplorare dati di conformità specifici.
```
aws ssm list-resource-compliance-summaries --filters One or more filters.
```
Gli esempi seguenti illustrano come utilizzare questo comando con i filtri.
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=ExecutionType,Values=Command
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=ExecutionType,Values=Command
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=OverallSeverity,Values=CRITICAL
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=OverallSeverity,Values=CRITICAL
```
------
1. Esegui questo comando per visualizzare un conteggio riepilogativo delle risorse conformi e non conformi per un tipo di conformità. Utilizzare filtri per esplorare dati di conformità specifici.
```
aws ssm list-compliance-summaries --filters One or more filters.
```
Gli esempi seguenti illustrano come utilizzare questo comando con i filtri.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=PatchGroup,Values=TestGroup
```
------
#### [ Windows ]
```
aws ssm list-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=PatchGroup,Values=TestGroup
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=ExecutionId,Values=4adf0526-6aed-4694-97a5-14522EXAMPLE
```
------
#### [ Windows ]
```
aws ssm list-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=ExecutionId,Values=4adf0526-6aed-4694-97a5-14522EXAMPLE
```
------
# AWS Systems Manager Distributor
Distributor, uno strumento in AWS Systems Manager, consente di creare pacchetti e pubblicare software su nodi AWS Systems Manager gestiti. È possibile creare pacchetti e pubblicare il proprio software o utilizzarlo Distributor per trovare e pubblicare pacchetti software AWS forniti dagli agenti, ad esempio pacchetti di terze parti come **Trend Micro**. **AmazonCloudWatchAgent**La pubblicazione di un pacchetto pubblicizza versioni specifiche del documento del pacchetto ai nodi gestiti identificati utilizzando node IDs Account AWS IDs, tag o un. Regione AWS Per cominciare a utilizzare Distributor, apri la [console di Systems Manager](https://console.aws.amazon.com//systems-manager/distributor). Nel pannello di navigazione, scegli **Distributor**.
Dopo aver creato un pacchetto in Distributor, puoi installare il pacchetto in uno dei modi seguenti:
+ Una sola volta con [AWS Systems Manager Run Command](run-command.md).
+ In base a una pianificazione con [AWS Systems Manager State Manager](systems-manager-state.md).
**Importante**
I pacchetti distribuiti da venditori di terze parti non sono gestiti AWS e vengono pubblicati dal fornitore del pacchetto. Consigliamo di condurre ulteriore due diligence per garantire il rispetto dei controlli di sicurezza interni. La sicurezza è una responsabilità condivisa tra te AWS e te. Questo è descritto come il modello di responsabilità condivisa. Per ulteriori informazioni consulta il [Modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/).
## Quali sono i vantaggi di Distributor per la mia organizzazione?
Distributor offre questi vantaggi:
+ **Un solo pacchetto, molte piattaforme**
Quando creai un pacchetto in Distributor, il sistema crea un documento AWS Systems Manager (documento SSM). È possibile allegare file con estensione zip a questo documento. Quando lanci Distributor, il sistema elabora le istruzioni nel documento SSM e installa il pacchetto software nel file .zip sulle destinazioni specificate. Distributor supporta più sistemi operativi, tra cui Windows, Ubuntu Server, Debian Server, e Red Hat Enterprise Linux. Per ulteriori informazioni sulle piattaforme supportate, consulta [Architetture e piattaforme dei pacchetti supportate](#what-is-a-package-platforms).
+ **Controlla l'accesso ai pacchetti nei gruppi di istanze gestite**
Puoi utilizzare Run Command o State Manager per controllare quali nodi gestiti ricevono un pacchetto e quale versione del pacchetto. Run Command e State Manager sono strumenti di AWS Systems Manager. I nodi gestiti possono essere raggruppati per istanza o dispositivo IDs, Account AWS numeri, tag o Regioni AWS. Puoi utilizzare le associazioni di State Manager per distribuire diverse versioni di un pacchetto a diversi gruppi di istanze.
+ **Molti pacchetti di AWS agenti inclusi e pronti all'uso**
Distributorinclude molti pacchetti di AWS agenti pronti per la distribuzione nei nodi gestiti. Cercare i pacchetti nellaDistributor `Packages`che sono pubblicati da `Amazon`. A titolo di esempio si possono menzionare `AmazonCloudWatchAgent` e `AWSPVDriver`.
+ **Distribuzione automatica **
Per mantenere aggiornato il tuo ambiente, utilizza State Manager per programmare i pacchetti per l'implementazione automatica nei nodi gestiti di destinazione quando vengono avviati per la prima volta.
## A chi è consigliato l'uso di Distributor?
+ Qualsiasi AWS cliente che desideri creare pacchetti software nuovi o implementare pacchetti software esistenti, inclusi i pacchetti AWS pubblicati, su più nodi gestiti di Systems Manager contemporaneamente.
+ Sviluppatori software che creano pacchetti software.
+ Amministratori responsabili dell'aggiornamento dei nodi gestiti di Systems Manager con la maggior parte dei pacchetti up-to-date software.
## Quali sono le funzionalità di Distributor?
+ **Implementazione dei pacchetti nelle istanze di Windows e Linux**
ConDistributor, puoi distribuire pacchetti software su AWS IoT Greengrass istanze Amazon Elastic Compute Cloud (Amazon EC2) e dispositivi principali per Linux e. Windows Server Per un elenco dei tipi di sistema operativo dell'istanza supportati, consulta [Architetture e piattaforme dei pacchetti supportate](#what-is-a-package-platforms).
**Nota**
Distributor è supportato dal sistema operativo macOS.
+ **Distribuisci i pacchetti una sola volta o in base a una pianificazione automatica**
Puoi scegliere di distribuire i pacchetti una sola volta, in base a una pianificazione periodica o ogni volta che la versione del pacchetto predefinita viene modificata.
+ **Reinstallazione completa dei pacchetti o esecuzione di aggiornamenti in locale**
Per installare una nuova versione di un pacchetto, è possibile disinstallare completamente la versione corrente e sostituirla con una nuova oppure aggiornare solo la versione corrente con componenti nuovi e aggiornati, in base a uno *script di aggiornamento* fornito. L'applicazione del pacchetto non è disponibile durante una reinstallazione, ma può rimanere disponibile durante un aggiornamento in locale. Gli aggiornamenti locali sono particolarmente utili per applicazioni di monitoraggio della sicurezza o altri scenari in cui è necessario evitare tempi di inattività dell'applicazione.
+ **Accesso alle funzionalità da console PowerShell, CLI e SDK Distributor**
Puoi lavorare con Distributor la console Systems Manager, AWS Command Line Interface (AWS CLI) o l' AWS SDK di tua scelta. AWS Strumenti per PowerShell
+ **Controllo degli accessi IAM**
Utilizzando le policy AWS Identity and Access Management (IAM), è possibile controllare quali membri dell'organizzazione possono creare, aggiornare, distribuire o eliminare pacchetti o versioni di pacchetti. Ad esempio, potresti voler assegnare a un amministratore le autorizzazioni per distribuire i pacchetti, ma non per modificarli o per creare nuove versioni di pacchetti.
+ **Supporto delle funzionalità di registrazione e verifica**
Puoi controllare e registrare le azioni Distributor degli utenti all'interno della tua azienda Account AWS attraverso l'integrazione con altri Servizi AWS. Per ulteriori informazioni, consulta [Verifica e registrazione dell'attività Distributor](distributor-logging-auditing.md).
## Cos'è un pacchetto in Distributor?
Un *pacchetto* è una raccolta di software o di risorse installabili che include quanto segue.
+ Un file .zip del software per ogni piattaforma del sistema operativo di destinazione. Ogni file .zip deve includere quanto segue.
+ Un copione **install** e uno **uninstall** script. Windows Serveri nodi gestiti basati richiedono PowerShell script (script denominati `install.ps1` and`uninstall.ps1`). I nodi gestiti basati su Linux richiedono script di shell (script denominati e). `install.sh` `uninstall.sh` AWS Systems Manager SSM Agentlegge ed esegue le istruzioni contenute negli script and. **install** **uninstall**
+ Un file eseguibile. SSM Agent deve trovare questo eseguibile per installare il pacchetto nei nodi gestiti di destinazione.
+ Un file manifest in formato JSON che descrive il contenuto del pacchetto. Il file manifest non è incluso nel file .zip, ma è archiviato nello stesso bucket Amazon Simple Storage Service (Amazon S3) dei file .zip che formano il pacchetto. Il manifest identifica la versione del pacchetto e mappa i file .zip del pacchetto agli attributi del nodo gestito di destinazione, ad esempio la versione del sistema operativo o l'architettura. Per informazioni su come creare il manifest, consulta [Fase 2: creazione del manifesto del pacchetto JSON](distributor-working-with-packages-create.md#packages-manifest).
Quando scegli la creazione del pacchetto **Simple (Semplice)** nella console Distributor, Distributor genera automaticamente gli script di installazione e disinstallazione, gli hash del file e il manifest del pacchetto JSON, in base al nome file dell'eseguibile software e alle piattaforme e architetture di destinazione.
### Architetture e piattaforme dei pacchetti supportate
È possibile utilizzare Distributor per pubblicare pacchetti sulle seguenti piattaforme di nodi gestiti di Systems Manager. Il valore di una versione deve corrispondere esattamente alla versione della release dell'AMI del sistema operativo Amazon Machine Image (AMI) di destinazione. Per ulteriori informazioni su come determinare questa versione, consulta la fase 4 di [Fase 2: creazione del manifesto del pacchetto JSON](distributor-working-with-packages-create.md#packages-manifest).
**Nota**
Systems Manager non supporta tutti i seguenti sistemi operativi per i dispositivi AWS IoT Greengrass principali. Per ulteriori informazioni, vedere [Configurazione dei dispositivi AWS IoT Greengrass principali](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) nella *Guida per gli AWS IoT Greengrass Version 2 sviluppatori*.
| Platform (Piattaforma) | Valore del codice nel file manifest | Architetture supportate |
| --- | --- | --- |
| AlmaLinux | almalinux | x86\$164 ARM64 |
| Amazon Linux 2 e Amazon Linux 2023 | `amazon` | x86\$164 o x86 ARM64(tipi di istanze Amazon Linux 2 e AL2023 A1) |
| Debian Server | `debian` | x86\$164 o x86 |
| openSUSE | `opensuse` | x86\$164 |
| openSUSE Leap | `opensuseleap` | x86\$164 |
| Oracle Linux | `oracle` | x86\$164 |
| Red Hat Enterprise Linux (RHEL) | `redhat` | x86\$164 ARM64 (RHEL 7.6 e versioni successive, tipi di istanza A1) |
| Rocky Linux | rocky | x86\$164 ARM64 |
| SUSE Linux Enterprise Server (SLES) | `suse` | x86\$164 |
| Ubuntu Server | `ubuntu` | x86\$164 o x86 ARM64 (Ubuntu Server 16 e versioni successive, tipi di istanza A1) |
| Windows Server | `windows` | x86\$164 |
**Topics**
+ [
## Quali sono i vantaggi di Distributor per la mia organizzazione?
](#distributor-benefits)
+ [
## A chi è consigliato l'uso di Distributor?
](#distributor-who)
+ [
## Quali sono le funzionalità di Distributor?
](#distributor-features)
+ [
## Cos'è un pacchetto in Distributor?
](#what-is-a-package)
+ [
# Configurazione di Distributor
](distributor-getting-started.md)
+ [
# Utilizzo dei pacchetti Distributor
](distributor-working-with.md)
+ [
# Verifica e registrazione dell'attività Distributor
](distributor-logging-auditing.md)
+ [
# Risoluzione dei problemi AWS Systems ManagerDistributor
](distributor-troubleshooting.md)
# Configurazione di Distributor
Prima di utilizzare Distributor uno strumento per creare, gestire e distribuire pacchetti software, segui questi passaggi. AWS Systems Manager
## Completare i prerequisiti Distributor
Prima di utilizzare uno strumento Distributor AWS Systems Manager, assicurati che l'ambiente soddisfi i seguenti requisiti.
**Prerequisiti di Distributor**
| Requisito | Description |
| --- | --- |
| SSM Agent | AWS Systems Manager SSM Agentla versione 2.3.274.0 o successiva deve essere installata nei nodi gestiti su cui si desidera eseguire la distribuzione o da cui si desidera rimuovere i pacchetti. Per installare o aggiornare SSM Agent, consulta [Utilizzo di SSM Agent](ssm-agent.md). |
| AWS CLI | (Facoltativo) Per utilizzare AWS Command Line Interface (AWS CLI) anziché la console Systems Manager per creare e gestire pacchetti, installa la versione più recente di AWS CLI sul tuo computer locale. Per ulteriori informazioni su come installare o aggiornare CLI, consulta [Installazione di AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) nella *Guida per l'utente di AWS Command Line Interface *. |
| AWS Strumenti per PowerShell | (Facoltativo) Per utilizzare Tools for PowerShell anziché la console Systems Manager per creare e gestire pacchetti, installa la versione più recente di Tools for PowerShell sul tuo computer locale. Per ulteriori informazioni su come installare o aggiornare gli strumenti per PowerShell, vedere [Configurazione di AWS Tools for Windows PowerShell or AWS Tools for PowerShell Core nella](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html) *Guida per l'AWS Strumenti per PowerShell utente*. |
**Nota**
Systems Manager non supporta la distribuzione di pacchetti ai nodi gestiti di Oracle Linux utilizzando Distributor.
## Verificare o creare un profilo dell'istanza IAM con le autorizzazioni di Distributor
Per impostazione predefinita, AWS Systems Manager non dispone dell'autorizzazione per eseguire azioni sulle istanze. È necessario concedere l'accesso utilizzando un profilo di istanza AWS Identity and Access Management (IAM). Un profilo dell'istanza è un container che trasmette le informazioni sul ruolo IAM a un'istanza di Amazon Elastic Compute Cloud (Amazon EC2) all'avvio. Questo requisito si applica alle autorizzazioni per tutti gli strumenti di Systems Manager, non solo per Distributor.
**Nota**
Quando configuri i dispositivi edge per eseguire il software AWS IoT Greengrass Core e SSM Agent specifichi un ruolo di servizio IAM che consente a Systems Manager di eseguire azioni su di esso. Non è necessario configurare dispositivi edge gestiti con un profilo dell'istanza.
Se già utilizzi altri strumenti di Systems Manager, ad esempio Run Command e State Manager, un profilo dell'istanza con le autorizzazioni richieste per Distributor è già associato alle tue istanze. Il modo più semplice per assicurarti di disporre delle autorizzazioni per eseguire Distributor attività è allegare la SSMManaged InstanceCore policy di **Amazon** al profilo della tua istanza. Per ulteriori informazioni, consulta la pagina [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md).
## Controllo dell'accesso utenti ai pacchetti
Utilizzando le policy AWS Identity and Access Management (IAM), puoi controllare chi può creare, distribuire e gestire i pacchetti. Puoi anche controllare quali operazioni API di Run Command e State Manager possono eseguire sui nodi gestiti. Ad esempioDistributor, entrambi Run Command e State Manager due sono strumenti in AWS Systems Manager.
**Formato ARN**
I pacchetti definiti dall'utente sono associati al documento Amazon Resource Names (ARNs) e hanno il seguente formato.
```
arn:aws:ssm:region:account-id:document/document-name
```
Di seguito è riportato un esempio di :
```
arn:aws:ssm:us-west-1:123456789012:document/ExampleDocumentName
```
Puoi utilizzare un paio di policy IAM predefinite AWS fornite, una per gli utenti finali e una per gli amministratori, per concedere le autorizzazioni per le attività. Distributor In alternativa, puoi creare policy IAM personalizzate adatte ai tuoi specifici requisiti di autorizzazione.
Per ulteriori informazioni sull'utilizzo delle variabili nelle policy IAM, consulta [Elementi delle policy IAM: variabili](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html).
Per informazioni su come creare policy e collegarle a utenti o gruppi, consulta le pagine [Creazione di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) e [Aggiunta e rimozione di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) nella *Guida per l'utente di IAM*.
## Creazione o scelta di un bucket Amazon S3 per archiviare i pacchetti Distributor
Quando crei un pacchetto utilizzando il flusso di lavoro **Semplice** nella console AWS Systems Manager , scegli un bucket Amazon Simple Storage Service (Amazon S3) esistente in cui Distributor carica il software. Distributor è uno strumento di AWS Systems Manager. Nel flusso di lavoro **Avanzato**, è necessario caricare i file .zip del software o le risorse in un bucket Amazon S3 prima di iniziare. Sia che crei un pacchetto utilizzando i flussi di lavoro **Semplice** o **Avanzato** nella console o l'API, prima di iniziare a creare il pacchetto devi disporre di un bucket Amazon S3. Come parte del processo di creazione del pacchetto, Distributor copia il software installabile e le risorse da questo bucket in un archivio Systems Manager interno. Poiché le risorse vengono copiate in una memoria interna, puoi eliminare o riutilizzare il bucket Amazon S3 al termine della creazione del pacchetto.
Per ulteriori informazioni sulla creazione di un bucket, consulta la sezione relativa alla [creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) nella *Guida alle operazioni di base di Amazon Simple Storage Service*. *Per ulteriori informazioni su come eseguire un AWS CLI comando per creare un bucket, consulta la sezione Command [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html)Reference.AWS CLI *
# Utilizzo dei pacchetti Distributor
Puoi utilizzare la console AWS Systems Manager, gli strumenti a riga di comando AWS (AWS CLI e AWS Strumenti per PowerShell) e gli SDK AWS per aggiungere, gestire o distribuire i pacchetti in Distributor. Distributor è uno strumento di AWS Systems Manager. Prima di aggiungere un pacchetto a Distributor:
+ Crea e comprimi le risorse installabili.
+ (Facoltativo) Crea un file manifest JSON per il pacchetto. Questa operazione non è necessaria per utilizzare il processo di creazione del pacchetto **Simple (Semplice)** nella console Distributor. La creazione del pacchetto semplice genera automaticamente un file manifest JSON.
Puoi utilizzare la console AWS Systems Manager o un editor di testo o JSON per creare il file manifest.
+ Avere un bucket Amazon Simple Storage Service (Amazon S3) pronto per memorizzare le risorse o il software installabili. Se stai utilizzando il processo di creazione del pacchetto **Advanced (Avanzato)**, carica le risorse nel bucket Amazon S3 prima di iniziare.
**Nota**
Puoi eliminare o riutilizzare questo bucket al termine della creazione del pacchetto perché Distributor sposta i contenuti del pacchetto in un bucket interno Systems Manager come parte del processo di creazione del pacchetto.
I pacchetti pubblicati da AWS sono già compressi e pronti per la distribuzione. Per distribuire un pacchetto pubblicato da AWS verso i nodi gestiti, consulta [Installazione o aggiornamento dei pacchetti Distributor](distributor-working-with-packages-deploy.md).
Puoi condividere pacchetti Distributor tra Account AWS. Quando si utilizza un pacchetto condiviso da un altro account in AWS CLI i comandi utilizzano il pacchetto Amazon Resource Name (ARN) anziché il nome del pacchetto.
**Topics**
+ [
# Visualizzare i pacchetti in Distributor
](distributor-view-packages.md)
+ [
# Creazione di un pacchetto in Distributor
](distributor-working-with-packages-create.md)
+ [
# Modifica delle autorizzazioni del pacchetto Distributor nella console
](distributor-working-with-packages-ep.md)
+ [
# Modifica dei tag del pacchetto Distributor nella console
](distributor-working-with-packages-tags.md)
+ [
# Aggiunta di una versione a un pacchetto Distributor
](distributor-working-with-packages-version.md)
+ [
# Installazione o aggiornamento dei pacchetti Distributor
](distributor-working-with-packages-deploy.md)
+ [
# Disinstallazione di un pacchetto Distributor
](distributor-working-with-packages-uninstall.md)
+ [
# Eliminazione di un pacchetto Distributor
](distributor-working-with-packages-dpkg.md)
# Visualizzare i pacchetti in Distributor
Per visualizzare i pacchetti disponibili per l'installazione, è possibile utilizzare la AWS Systems Manager console o lo strumento da riga di AWS comando preferito. Distributorè uno strumento in AWS Systems Manager. Per accedereDistributor, apri la AWS Systems Manager console e scegli **Distributor**nel riquadro di navigazione a sinistra. Vedrai tutti i pacchetti a tua disposizione.
La sezione seguente descrive come visualizzare i pacchetti Distributor utilizzando lo strumento a riga di comando preferito.
## Visualizzazione dei pacchetti utilizzando la riga di comando
Questa sezione contiene informazioni su come utilizzare lo strumento a riga di comando preferito per visualizzare Distributor utilizzando i comandi forniti.
------
#### [ Linux & macOS ]
**Per visualizzare i pacchetti usando Linux AWS CLI**
+ Per visualizzare tutti i pacchetti, esclusi i pacchetti condivisi, esegui il comando seguente.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package
```
+ Per visualizzare tutti i pacchetti di proprietà di Amazon, esegui il comando seguente.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ Per visualizzare tutti i pacchetti di proprietà di terze parti, esegui il comando seguente.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ Windows ]
**Per visualizzare i pacchetti utilizzando Windows AWS CLI**
+ Per visualizzare tutti i pacchetti, esclusi i pacchetti condivisi, esegui il comando seguente.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package
```
+ Per visualizzare tutti i pacchetti di proprietà di Amazon, esegui il comando seguente.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ Per visualizzare tutti i pacchetti di proprietà di terze parti, esegui il comando seguente.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ PowerShell ]
**Per visualizzare i pacchetti utilizzando gli Strumenti per PowerShell**
+ Per visualizzare tutti i pacchetti, esclusi i pacchetti condivisi, esegui il comando seguente.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "DocumentType"
$filter.Values = "Package"
Get-SSMDocumentList `
-Filters @($filter)
```
+ Per visualizzare tutti i pacchetti di proprietà di Amazon, esegui il comando seguente.
```
$typeFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$typeFilter.Key = "DocumentType"
$typeFilter.Values = "Package"
$ownerFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$ownerFilter.Key = "Owner"
$ownerFilter.Values = "Amazon"
Get-SSMDocumentList `
-Filters @($typeFilter,$ownerFilter)
```
+ Per visualizzare tutti i pacchetti di proprietà di terze parti, esegui il comando seguente.
```
$typeFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$typeFilter.Key = "DocumentType"
$typeFilter.Values = "Package"
$ownerFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$ownerFilter.Key = "Owner"
$ownerFilter.Values = "ThirdParty"
Get-SSMDocumentList `
-Filters @($typeFilter,$ownerFilter)
```
------
# Creazione di un pacchetto in Distributor
Per creare un pacchetto, prepara il software o le risorse installabili, un file per piattaforma del sistema operativo. Per creare un pacchetto è richiesto almeno un file.
A volte, piattaforme diverse potrebbero utilizzare lo stesso file, ma tutti i file collegati al pacchetto devono essere elencati nella sezione `Files` del manifesto. Se stai creando un pacchetto utilizzando il flusso di lavoro semplice nella console, il manifesto viene generato automaticamente. Il numero massimo di file che puoi collegare a un singolo documento è 20. La dimensione massima di ogni file è di 1 GB. Per ulteriori informazioni sulle piattaforme supportate, consulta [Architetture e piattaforme dei pacchetti supportate](distributor.md#what-is-a-package-platforms).
Quando crei un pacchetto, il sistema crea un nuovo [Documento SSM](documents.md). Il documento consente di distribuire il pacchetto nei nodi gestiti.
Solo a scopo dimostrativo, è disponibile un pacchetto di esempio, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), da scaricare dal nostro sito Web. Il pacchetto di esempio include un manifest JSON completo e tre file.zip contenenti i programmi di installazione per la versione 7.0.0. PowerShell Gli script di installazione e disinstallazione non contengono comandi validi. Anche se è necessario comprimere ogni software installabile e gli script in un file .zip per creare un pacchetto nel flusso di lavoro **Avanzato**, le risorse installabili non vengono compresse nel flusso di lavoro **Semplice**.
**Topics**
+ [
## Crea un pacchetto utilizzando il flusso di lavoro Semplice
](#distributor-working-with-packages-create-simple)
+ [
## Creare un pacchetto utilizzando il flusso di lavoro Avanzato
](#distributor-working-with-packages-create-adv)
## Crea un pacchetto utilizzando il flusso di lavoro Semplice
Questa sezione descrive come creare un pacchetto in Distributor scegliendo il flusso di lavoro di creazione del pacchetto **Semplice** nella console Distributor. Distributor è uno strumento di AWS Systems Manager. Per creare un pacchetto, prepara le risorse installabili, un file per ogni piattaforma del sistema operativo. Per creare un pacchetto è richiesto almeno un file. Il processo di creazione del pacchetto **Semplice** genera automaticamente script di installazione e disinstallazione, hash del file e un manifesto in formato JSON. Il flusso di lavoro **Semplice** gestisce il processo di caricamento e compressione dei file installabili e la creazione di un nuovo pacchetto e del [documento SSM](documents.md) associato. Per ulteriori informazioni sulle piattaforme supportate, consulta [Architetture e piattaforme dei pacchetti supportate](distributor.md#what-is-a-package-platforms).
Quando si utilizza il metodo semplice per creare un pacchetto, Distributor crea script `install` e `uninstall` per l'utente. Tuttavia, quando si crea un pacchetto per un aggiornamento in locale, è necessario fornire i propri contenuti dello script `update` nella scheda **Aggiorna script**. Quando si aggiungono comandi di input per uno script `update`, Distributor include questo script nel pacchetto.zip creato per l'utente, insieme agli script `install` e `uninstall`.
**Nota**
Utilizza l'opzione di aggiornamento `In-place` per aggiungere file nuovi o aggiornati a un'installazione di pacchetti esistente senza disconnettere l'applicazione associata.
**Creazione di un pacchetto tramite il flusso di lavoro semplice**
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 **Distributor**.
1. Nella home page Distributor, scegli **Crea pacchetto**, quindi seleziona **Semplice**.
1. Nella pagina **Crea pacchetto**, inserisci un nome per il pacchetto. I nomi dei pacchetti possono contenere lettere, numeri, punti, trattini e caratteri di sottolineatura. Il nome deve essere abbastanza generico da applicarsi a tutte le versioni degli allegati del pacchetto, ma abbastanza specifico da identificare lo scopo del pacchetto.
1. (Facoltativo) In **Nome della versione**, immetti un nome di versione. I nomi delle versioni possono essere composti da un massimo di 512 caratteri e non possono contenere caratteri speciali.
1. Per **Posizione**, scegli un bucket utilizzando il nome e il prefisso del bucket o utilizzandone l'URL.
1. Per **Carica software**, scegli **Aggiungi software**, quindi passa ai file software installabili con estensione `.rpm`, `.msi` o `.deb`. Se il nome del file contiene spazi, il caricamento non riesce. Puoi caricare più file del software in una singola operazione.
1. Per **Piattaforma di destinazione**, verifica che la piattaforma del sistema operativo di destinazione visualizzata per ogni file installabile sia corretta. Se il sistema operativo mostrato non è corretto, scegli il sistema operativo corretto nell'elenco a discesa.
Nel flusso di lavoro di creazione del pacchetto **Semplice**, poiché ogni file installabile viene caricato solo una volta, sono richieste fasi aggiuntive per indicare a Distributor di utilizzare un singolo file come destinazione di più sistemi operativi. Ad esempio, se carichi un file del software installabile denominato `Logtool_v1.1.1.rpm`, devi modificare alcune impostazioni predefinite nel flusso di lavoro **Semplice**, per indirizzare lo stesso software su versioni supportate sia dal sistema operativo di Amazon Linux che da quello di Ubuntu Server. Quando si utilizzano più piattaforme, esegui una delle seguenti operazioni.
+ Utilizza il flusso di lavoro **Avanzato**, comprimi ogni file installabile in un file .zip prima di iniziare e creare manualmente il manifesto, in modo da poter destinare un file installabile a più piattaforme o versioni del sistema operativo. Per ulteriori informazioni, consulta [Creare un pacchetto utilizzando il flusso di lavoro Avanzato](#distributor-working-with-packages-create-adv).
+ Modifica manualmente il file manifest nel flusso di lavoro **Semplice**, in modo che il file .zip sia destinato a più piattaforme o versioni di sistema operativo. Per ulteriori informazioni su come eseguire questa operazione, consulta la fine della fase 4 in [Fase 2: creazione del manifesto del pacchetto JSON](#packages-manifest).
1. Per **Versione della piattaforma**, verifica che la versione della piattaforma del sistema operativo mostrata sia **\$1any** o una versione principale seguita da una wildcard (7.\$1) o l'esatta versione della release del sistema operativo specifico che deve essere valida per il software. Per ulteriori informazioni sulla specifica della versione della piattaforma del sistema operativo, consulta la fase 4 in [Fase 2: creazione del manifesto del pacchetto JSON](#packages-manifest).
1. Per **Architettura**, scegli l'architettura del processore corretta per ogni file installabile dall'elenco a discesa. Per ulteriori informazioni sulle architetture del processore supportate, consulta [Architetture e piattaforme dei pacchetti supportate](distributor.md#what-is-a-package-platforms).
1. (Facoltativo) Espandere **Script** ed esaminare gli script generati da Distributor per il software installabile.
1. (Facoltativo) Per fornire uno script di aggiornamento da utilizzare con gli aggiornamenti in locale, espandere **Script**, scegliere la scheda **Aggiorna script** e immettere i comandi di script di aggiornamento
Systems Manager non genera script di aggiornamento per conto dell'utente.
1. Per aggiungere altri file del software installabile, scegli **Aggiungi software**. Altrimenti, vai alla fase successiva.
1. (Facoltativo) Espandi **Manifesto** ed esamina il manifesto del pacchetto JSON generato da Distributor per il software installabile. Se hai modificato eventuali informazioni sul software da momento in cui hai avviato questa procedura, ad esempio versione della piattaforma o piattaforma di destinazione, scegli **Genera manifesto** per visualizzare il manifesto del pacchetto aggiornato.
Puoi modificare il manifesto manualmente, se desideri che un software installabile sia destinato a più di un sistema operativo, come descritto nella fase 8. Per ulteriori informazioni sulla modifica del manifesto, consulta [Fase 2: creazione del manifesto del pacchetto JSON](#packages-manifest).
1. Scegli **Crea pacchetto**.
Attendi che Distributor termini il caricamento del software e la creazione del pacchetto. Distributor mostra lo stato di caricamento per ogni file installabile. In base al numero e alla dimensione dei pacchetti che si stanno aggiungendo, questa operazione può richiedere alcuni minuti. Distributor esegue automaticamente il reindirizzamento alla pagina **Dettagli del pacchetto** per il nuovo pacchetto, ma puoi scegliere di aprire questa pagina personalmente dopo che il software è stato caricato. La pagina **Dettagli del pacchetto** non mostra tutte le informazioni sul pacchetto finché Distributor non termina il processo di creazione del pacchetto. Per interrompere il processo di caricamento e di creazione del pacchetto, scegli **Annulla**.
Se Distributor non è in grado di caricare i file installabili del software, visualizza un messaggio **Caricamento non riuscito**. Per riprovare a eseguire il caricamento, scegli **Riprova caricamento**. Per ulteriori informazioni su come risolvere gli errori di creazione del pacchetto, consulta [Risoluzione dei problemi AWS Systems ManagerDistributor](distributor-troubleshooting.md).
## Creare un pacchetto utilizzando il flusso di lavoro Avanzato
In questa sezione, vengono fornite ulteriori informazioni su come utenti esperti possono creare un pacchetto in Distributor dopo il caricamento di risorse installabili compresse con script di installazione e disinstallazione e un file manifest JSON, in un bucket di Amazon S3.
Per creare un pacchetto, preparare i file .zip delle risorse installabili, un file .zip per ogni piattaforma del sistema operativo. Per creare un pacchetto è richiesto almeno un file .zip. Quindi, crea un manifesto JSON. Il manifesto include i puntatori per i file del codice del pacchetto. Dopo aver aggiunto i file del codice richiesti a una cartella o a una directory e dopo aver popolato il manifesto con i valori corretti, carica il pacchetto in un bucket S3.
Un pacchetto di esempio, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), può essere scaricato dal nostro sito Web. Il pacchetto di esempio include un manifesto JSON completato e tre file .zip.
**Topics**
+ [
### Fase 1: creazione dei file ZIP
](#packages-zip)
+ [
### Fase 2: creazione del manifesto del pacchetto JSON
](#packages-manifest)
+ [
### Fase 3: caricamento del pacchetto e del manifesto in un bucket Amazon S3
](#packages-upload-s3)
+ [
### Fase 4: aggiunta di un pacchetto a Distributor
](#distributor-working-with-packages-add)
### Fase 1: creazione dei file ZIP
La base del pacchetto è costituita da almeno un file .zip con software o risorse installabili. Un pacchetto include un file .zip per ogni sistema operativo da supportare, a meno che questo non possa essere installato su più sistemi operativi. Ad esempio, le versioni supportate delle istanze di Red Hat Enterprise Linux e di Amazon Linux, in genere, possono eseguire gli stessi file eseguibili .RPM, quindi è sufficiente collegare un solo file .zip al pacchetto per supportare entrambi i sistemi operativi.
**File richiesti**
Gli elementi seguenti sono obbligatori in ogni file .zip.
+ Un copione **install** e uno **uninstall** script. Windows Serveri nodi gestiti basati richiedono PowerShell script (script denominati `install.ps1` and`uninstall.ps1`). I nodi gestiti basati su Linux richiedono script shell, denominati `install.sh` e `uninstall.sh`. SSM Agent esegue le istruzioni negli script **install** e **uninstall**.
Ad esempio, gli script di installazione potrebbero eseguire un programma di installazione, ad esempio .rpm o .msi, potrebbero copiare file o impostare opzioni di configurazione.
+ Un file eseguibile, pacchetti di installazione (.rpm, .deb, .msi e così via), altri script o file di configurazione.
**File facoltativi**
Il seguente elemento è facoltativo in ogni file.zip:
+ Uno script **update**. Fornire uno script di aggiornamento consente di utilizzare l'opzione `In-place update` per installare un pacchetto. Quando si desidera aggiungere file nuovi o aggiornati a un'installazione di pacchetto esistente, l'`In-place update`opzione non mette offline l'applicazione del pacchetto durante l'aggiornamento. Windows Serveri nodi gestiti basati richiedono uno PowerShell script (denominato script`update.ps1`). I nodi gestiti basati su Linux richiedono uno script shell (nome script `update.sh`). SSM Agent esegue le istruzioni nello script **update**.
Per ulteriori informazioni sull'installazione o sull'aggiornamento dei pacchetti, consulta [Installazione o aggiornamento dei pacchetti Distributor](distributor-working-with-packages-deploy.md).
[Per esempi di file con estensione zip, inclusi esempi **install** e **uninstall** script, scaricate il pacchetto di esempio, ExamplePackage .zip.](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip)
### Fase 2: creazione del manifesto del pacchetto JSON
Dopo la preparazione e la compressione dei file installabili, crea un manifesto JSON. Di seguito è riportato il modello. Le parti del modello del manifesto sono descritte nella procedura in questa sezione. Puoi utilizzare un editor JSON per creare questo manifesto in un file separato. In alternativa, puoi creare il manifesto nella AWS Systems Manager console quando crei un pacchetto.
```
{
"schemaVersion": "2.0",
"version": "your-version",
"publisher": "optional-publisher-name",
"packages": {
"platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-1.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-2.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-3.zip"
}
}
}
},
"files": {
".zip-file-name-1.zip": {
"checksums": {
"sha256": "checksum"
}
},
".zip-file-name-2.zip": {
"checksums": {
"sha256": "checksum"
}
}
}
}
```
**Per creare un manifesto del pacchetto JSON**
1. Aggiungi la versione dello schema al manifesto. In questo rilascio, la versione dello schema è sempre `2.0`.
```
{ "schemaVersion": "2.0",
```
1. Aggiungi una versione del pacchetto definita dall'utente al manifesto. Questo è anche il valore di **Nome versione** specificato quando aggiungi il pacchetto a Distributor. Diventa parte del documento AWS Systems Manager che Distributor crea quando aggiungi il pacchetto. Questo valore viene anche fornito come input nel documento `AWS-ConfigureAWSPackage` per installare una versione del pacchetto diversa dall'ultima. Un valore `version` può contenere lettere, numeri, trattini bassi, trattini e punti e può avere una lunghezza massima di 128 caratteri. È consigliabile utilizzare una versione del pacchetto leggibile per semplificare a te e agli altri amministratori la specifica delle versioni esatte del pacchetto durante la distribuzione. Di seguito è riportato un esempio di :
```
"version": "1.0.1",
```
1. (Facoltativo) Aggiungi il nome di un publisher. Di seguito è riportato un esempio di :
```
"publisher": "MyOrganization",
```
1. Aggiungi pacchetti. La sezione `"packages"` descrive le piattaforme, le architetture e le versioni supportate dal file .zip nel pacchetto. Per ulteriori informazioni, consulta [Architetture e piattaforme dei pacchetti supportate](distributor.md#what-is-a-package-platforms).
*platform-version*Può essere il valore jolly,`_any`. Utilizzarlo per indicare che un file .zip supporta qualsiasi versione della piattaforma. È inoltre possibile specificare una versione principale seguita da un carattere jolly in modo che tutte le versioni secondarie siano supportate, ad esempio 7.\$1. Se scegli di specificare un *platform-version* valore per una versione specifica del sistema operativo, assicurati che corrisponda alla versione di rilascio esatta del sistema operativo AMI che hai scelto come target. Di seguito sono elencate le risorse consigliate per ottenere il valore corretto del sistema operativo.
+ Su nodi gestiti basati su Windows Server, la versione di release è disponibile sotto forma di dati Windows Management Instrumentation (WMI). Puoi eseguire il seguente comando dal prompt dei comandi per ottenere le informazioni sulla versione, quindi puoi analizzare i risultati per `version`.
```
wmic OS get /format:list
```
+ In un nodo gestito basato su Linux, per ottenere la versione devi cercare prima il rilascio del sistema operativo (il comando seguente). Cerca il valore di `VERSION_ID`.
```
cat /etc/os-release
```
Se non vengono restituiti i risultati richiesti, esegui il secondo comando per ottenere le informazioni di rilascio LSB dal file `/etc/lsb-release`, quindi cerca il valore di `DISTRIB_RELEASE`.
```
lsb_release -a
```
Se questi metodi non riescono, in genere è possibile individuare il rilascio in base alla distribuzione. Ad esempio, su Debian Server puoi analizzare il file `/etc/debian_version` oppure su Red Hat Enterprise Linux il `/etc/redhat-release`.
```
hostnamectl
```
```
"packages": {
"platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-1.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-2.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-3.zip"
}
}
}
}
```
Di seguito è riportato un esempio di : In questo esempio, la piattaforma del sistema operativo è `amazon`, la versione supportata è `2016.09`, l'architettura è `x86_64` e il file .zip che supporta questa piattaforma è `test.zip`.
```
{
"amazon": {
"2016.09": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
Puoi aggiungere il valore jolly `_any` per indicare che il pacchetto supporta tutte le versioni dell'elemento padre. Ad esempio, per indicare che il pacchetto è supportato su qualsiasi versione di Amazon Linux, l'istruzione del pacchetto deve essere simile alla seguente. Puoi utilizzare il carattere jolly `_any` a livello di versione o di architettura per supportare tutte le versioni di una piattaforma, tutte le architetture di una versione oppure tutte le versioni e tutte le architetture di una piattaforma.
```
{
"amazon": {
"_any": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
L'esempio seguente aggiunge `_any` per mostrare che il primo pacchetto, `data1.zip`, è supportato per tutte le architetture di Amazon Linux 2016.09. Il secondo pacchetto, `data2.zip`, è supportato per tutte le versioni di Amazon Linux, ma solo per i nodi gestiti con l'architettura `x86_64`. Entrambe le versioni `2023.8` e `_any` sono voci di `amazon`. Esiste una sola piattaforma (Amazon Linux)), ma diverse versioni, architetture e relativi file .zip supportati.
```
{
"amazon": {
"2023.8": {
"_any": {
"file": "data1.zip"
}
},
"_any": {
"x86_64": {
"file": "data2.zip"
}
}
}
}
```
È possibile fare riferimento a un file .zip più volte nella sezione `"packages"` del manifesto, se il file .zip supporta più di una piattaforma. Ad esempio, se un file .zip supporta sia le versioni 8.x di Red Hat Enterprise Linux che di Amazon Linux, la sezione `"packages"` contiene due voci che puntano allo stesso file .zip, come mostrato nell'esempio seguente.
```
{
"amazon": {
"2023.8.20250715 ": {
"x86_64": {
"file": "test.zip"
}
}
},
"redhat": {
"8.*": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
1. Aggiungere l'elenco dei file .zip che fanno parte di questo pacchetto dalla fase 4. Ogni voce di file richiede il nome del file e il checksum del valore hash `sha256`. I valori checksum nel manifesto devono corrispondere al valore hash `sha256` nelle risorse compresse per evitare errori di installazione del pacchetto.
Per ottenere il checksum esatto dai file installabili, puoi eseguire i comandi riportati di seguito. In Linux, eseguire `shasum -a 256 file-name.zip` o `openssl dgst -sha256 file-name.zip`. In Windows, esegui il `Get-FileHash -Path path-to-.zip-file` cmdlet in. [PowerShell](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-6)
La sezione `"files"` del manifesto include un riferimento a ciascuno dei file .zip nel pacchetto.
```
"files": {
"test-agent-x86.deb.zip": {
"checksums": {
"sha256": "EXAMPLE2706223c7616ca9fb28863a233b38e5a23a8c326bb4ae241dcEXAMPLE"
}
},
"test-agent-x86_64.deb.zip": {
"checksums": {
"sha256": "EXAMPLE572a745844618c491045f25ee6aae8a66307ea9bff0e9d1052EXAMPLE"
}
},
"test-agent-x86_64.nano.zip": {
"checksums": {
"sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
}
},
"test-agent-rhel8-x86.nano.zip": {
"checksums": {
"sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
}
},
"test-agent-x86.msi.zip": {
"checksums": {
"sha256": "EXAMPLE12a4abb10315aa6b8a7384cc9b5ca8ad8e9ced8ef1bf0e5478EXAMPLE"
}
},
"test-agent-x86_64.msi.zip": {
"checksums": {
"sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
}
},
"test-agent-rhel8-x86.rpm.zip": {
"checksums": {
"sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
}
}
}
```
1. Dopo aver aggiunto le informazioni sul pacchetto, salva e chiudi il file manifest.
Di seguito è riportato un esempio di un manifesto completato. Questo esempio mostra un file .zip, `NewPackage_LINUX.zip`, che supporta più di una piattaforma, ma viene indicato nella sezione `"files"` una sola volta.
```
{
"schemaVersion": "2.0",
"version": "1.7.1",
"publisher": "Amazon Web Services",
"packages": {
"windows": {
"_any": {
"x86_64": {
"file": "NewPackage_WINDOWS.zip"
}
}
},
"amazon": {
"_any": {
"x86_64": {
"file": "NewPackage_LINUX.zip"
}
}
},
"ubuntu": {
"_any": {
"x86_64": {
"file": "NewPackage_LINUX.zip"
}
}
}
},
"files": {
"NewPackage_WINDOWS.zip": {
"checksums": {
"sha256": "EXAMPLEc2c706013cf8c68163459678f7f6daa9489cd3f91d52799331EXAMPLE"
}
},
"NewPackage_LINUX.zip": {
"checksums": {
"sha256": "EXAMPLE2b8b9ed71e86f39f5946e837df0d38aacdd38955b4b18ffa6fEXAMPLE"
}
}
}
}
```
#### Esempio di pacchetto
Un pacchetto di esempio, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), è disponibile per il download dal nostro sito Web. Il pacchetto di esempio include un manifesto JSON completato e tre file .zip.
### Fase 3: caricamento del pacchetto e del manifesto in un bucket Amazon S3
Preparare il pacchetto copiando o spostando tutti i file .zip in una cartella o una directory. Un pacchetto valido richiede il manifesto creato in [Fase 2: creazione del manifesto del pacchetto JSON](#packages-manifest) e tutti i file .zip identificati nel file manifest.
**Per caricare il pacchetto e il manifesto in Amazon S3**
1. Copiare o spostare tutti i file di archivio .zip specificati nel manifesto in una cartella o una directory. Non comprimere la cartella o la directory in cui si spostano i file di archivio .zip e il file manifest.
1. Creare un bucket o sceglierne uno esistente. Per ulteriori informazioni consulta la sezione relativa alla [creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) nella *Guida alle operazioni di base di Amazon Simple Storage Service*. Per ulteriori informazioni su come eseguire un AWS CLI comando per creare un bucket, consulta [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html)la sezione *AWS CLI Command* Reference.
1. Carica la cartella o la directory nel bucket. Per ulteriori informazioni, consulta [Aggiungi un oggetto in un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PuttingAnObjectInABucket.html) nella *Guida alle operazioni di base di Amazon Simple Storage Service*. Se hai intenzione di incollare il tuo manifest JSON nella AWS Systems Manager console, non caricarlo. Per ulteriori informazioni su come eseguire un AWS CLI comando per caricare file in un bucket, consulta la sezione *AWS CLI Command [https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html)*Reference.
1. Nella home page del bucket, scegli la cartella o la directory che hai caricato. Se hai caricato i file in una sottocartella in un bucket, prendi nota della sottocartella (nota anche come un *prefisso*). Il prefisso è necessario per aggiungere il pacchetto a Distributor.
### Fase 4: aggiunta di un pacchetto a Distributor
Puoi usare la AWS Systems Manager console, gli strumenti della riga di AWS comando (AWS CLI and AWS Strumenti per PowerShell) o AWS SDKs aggiungere un nuovo pacchetto aDistributor. Quando aggiungi un pacchetto, stai aggiungendo un nuovo [documento SSM](documents.md). Il documento consente di implementare il pacchetto nei nodi gestiti.
**Topics**
+ [
#### Aggiunta di un pacchetto tramite la console
](#create-pkg-console)
+ [
#### Aggiungi un pacchetto utilizzando il AWS CLI
](#create-pkg-cli)
#### Aggiunta di un pacchetto tramite la console
È possibile utilizzare la AWS Systems Manager console per creare un pacchetto. Tieni pronto il nome del bucket in cui hai caricato il pacchetto in [Fase 3: caricamento del pacchetto e del manifesto in un bucket Amazon S3](#packages-upload-s3).
**Per aggiungere un pacchetto a Distributor (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 **Distributor**.
1. Nella home page Distributor, scegli **Create package (Crea pacchetto)** e seleziona **Advanced (Avanzato)**.
1. Nella pagina **Crea pacchetto**, inserisci un nome per il pacchetto. I nomi dei pacchetti possono contenere lettere, numeri, punti, trattini e caratteri di sottolineatura. Il nome deve essere abbastanza generico da applicarsi a tutte le versioni degli allegati del pacchetto, ma abbastanza specifico da identificare lo scopo del pacchetto.
1. Per **Nome della versione**, immetti il valore esatto della voce `version` nel file manifest.
1. Per **Nome del bucket S3**, scegli il nome del bucket in cui sono stati caricati i file .zip e il manifesto in [Fase 3: caricamento del pacchetto e del manifesto in un bucket Amazon S3](#packages-upload-s3).
1. Per **Prefisso della chiave S3**, immetti la sottocartella del bucket in cui sono archiviati i file .zip e il manifesto.
1. Per **Manifesto**, scegli **Estrai dal pacchetto** per utilizzare un manifesto caricato nel bucket Amazon S3 con i file .zip.
(Facoltativo) Se non è stato caricato il manifesto JSON nel bucket S3 in cui sono stati archiviati i file .zip, scegli **Nuovo manifesto**. Puoi creare o incollare l'intero manifesto nel campo Editor JSON. Per ulteriori informazioni su come creare il manifesto JSON, consulta [Fase 2: creazione del manifesto del pacchetto JSON](#packages-manifest).
1. Al termine, scegli **Crea pacchetto**.
1. Attendere che Distributor crei il pacchetto dai file .zip e manifest. In base al numero e alla dimensione dei pacchetti che si stanno aggiungendo, questa operazione può richiedere alcuni minuti. Distributor esegue automaticamente il reindirizzamento alla pagina **Dettagli del pacchetto** per il nuovo pacchetto, ma puoi scegliere di aprire questa pagina personalmente dopo che il software è stato caricato. La pagina **Dettagli del pacchetto** non mostra tutte le informazioni sul pacchetto finché Distributor non termina il processo di creazione del pacchetto. Per interrompere il processo di caricamento e di creazione del pacchetto, scegli **Annulla**.
#### Aggiungi un pacchetto utilizzando il AWS CLI
È possibile utilizzare il AWS CLI per creare un pacchetto. Tieni pronto l'URL del bucket da cui hai caricato il pacchetto in [Fase 3: caricamento del pacchetto e del manifesto in un bucket Amazon S3](#packages-upload-s3).
**Per aggiungere un pacchetto ad Amazon S3 utilizzando AWS CLI**
1. Per utilizzarlo AWS CLI per creare un pacchetto, esegui il comando seguente, sostituendolo *package-name* con il nome del pacchetto e *path-to-manifest-file* con il percorso del file manifest JSON. amzn-s3-demo-bucket è l'URL del bucket Amazon S3 in cui è archiviato l'intero pacchetto. Quando esegui il comando **create-document** in Distributor, devi specificare il valore `Package` per `--document-type`.
Se non è stato aggiunto il file manifest al bucket Amazon S3, il valore del parametro `--content` è il percorso al file manifest JSON.
```
aws ssm create-document \
--name "package-name" \
--content file://path-to-manifest-file \
--attachments Key="SourceUrl",Values="amzn-s3-demo-bucket" \
--version-name version-value-from-manifest \
--document-type Package
```
Di seguito è riportato un esempio di :
```
aws ssm create-document \
--name "ExamplePackage" \
--content file://path-to-manifest-file \
--attachments Key="SourceUrl",Values="https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage" \
--version-name 1.0.1 \
--document-type Package
```
1. Verifica che il pacchetto sia stato aggiunto e mostra il manifesto del pacchetto eseguendo il comando seguente, sostituendolo con il nome del pacchetto. *package-name* Per ottenere una versione specifica del documento (non la stessa di un pacchetto), puoi aggiungere il parametro `--document-version`.
```
aws ssm get-document \
--name "package-name"
```
Per informazioni sulle altre opzioni che puoi utilizzare con il comando **create-document**, consulta [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html) nella sezione AWS Systems Manager *Riferimento ai comandi AWS CLI *. Per informazioni sulle altre opzioni che puoi utilizzare con il comando **get-document** , consulta [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html).
# Modifica delle autorizzazioni del pacchetto Distributor nella console
Dopo aver aggiunto un pacchetto aDistributor, uno strumento in AWS Systems Manager, puoi modificare le autorizzazioni del pacchetto nella console Systems Manager. Puoi aggiungerne altre Account AWS alle autorizzazioni di un pacchetto. I pacchetti possono essere condivisi solo con altri account nella stessa Regione AWS . La condivisione tra regioni non è supportata. Per impostazione predefinita, i pacchetti sono impostati su **Privato**, il che significa che solo coloro che hanno accesso al creatore del pacchetto Account AWS possono visualizzare le informazioni sul pacchetto e aggiornare o eliminare il pacchetto. Se le autorizzazioni **Private (Privato)** sono accettabili, puoi ignorare questa procedura.
**Nota**
È possibile aggiornare le autorizzazioni dei pacchetti condivisi con 20 o meno account.
**Per modificare le autorizzazioni del pacchetto nella 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 **Distributor**.
1. Nella pagina **Packages (Pacchetti)** scegli il pacchetto di cui desideri modificare le autorizzazioni.
1. Nella scheda **Package details (Dettagli pacchetto)** scegli **Edit permissions (Modifica autorizzazioni)** per modificare le autorizzazioni.
1. Per **Edit permissions (Modifica autorizzazioni)**, scegliere **Shared with specific accounts (Condiviso con account specifici)**.
1. In **Shared with specific accounts (Condiviso con account specifici)** aggiungi i numeri degli account Account AWS , uno alla volta. Al termine, seleziona **Salva**.
# Modifica dei tag del pacchetto Distributor nella console
Dopo aver aggiunto un pacchetto aDistributor, uno strumento in AWS Systems Manager, è possibile modificare i tag del pacchetto nella console Systems Manager. Questi tag vengono applicati al pacchetto e non sono connessi ai tag sui nodi gestiti in cui desideri implementare il pacchetto. I tag sono coppie chiave-valore che prevedono una distinzione tra lettere maiuscole e minuscole e che consentono di raggruppare e filtrare i pacchetti in base a criteri rilevanti per la tua organizzazione. Se non desideri aggiungere tag, puoi procedere con l'installazione del pacchetto o con l'aggiunta di una nuova versione.
**Per modificare i tag del pacchetto nella 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 **Distributor**.
1. Nella pagina **Packages (Pacchetti)** scegli il pacchetto di cui desideri modificare i tag.
1. Nella scheda **Package details (Dettagli pacchetto** in **Tags**, scegli **Edit (Modifica)**.
1. Per **Add tags (Aggiungi tag)**, inserire una chiave tag oppure una coppia chiave-valore del tag, quindi scegliere **Add (Aggiungi)**. Ripeti se desideri aggiungere ulteriori tag. Per eliminare i tag, scegli **X** sul tag nella parte inferiore della finestra.
1. Dopo aver aggiunto i tag al pacchetto, scegli **Save (Salva)**.
# Aggiunta di una versione a un pacchetto Distributor
Per aggiungere una versione del pacchetto, [crea un pacchetto](distributor-working-with-packages-create.md), quindi utilizza Distributor per aggiungere una versione del pacchetto aggiungendo una voce al documento AWS Systems Manager (SSM) già esistente per le versioni precedenti. Distributorè uno strumento in AWS Systems Manager. Per risparmiare tempo, aggiorna il manifesto di una versione precedente del pacchetto, modifica il valore della voce `version` nel manifesto (ad esempio da `Test_1.0` a `Test_2.0`) e salvalo come manifesto per la nuova versione. Il flusso di lavoro **Aggiungi versione** semplice nella console Distributor aggiorna automaticamente il file manifest.
Una nuova versione del pacchetto può:
+ Sostituire almeno uno dei file installabili collegati alla versione corrente.
+ Aggiungere nuovi file installabili per supportare piattaforme aggiuntive.
+ Eliminare i file per interrompere il supporto per piattaforme specifiche.
Una versione più recente può utilizzare lo stesso bucket Amazon Simple Storage Service (Amazon S3), ma deve avere un URL con un nome file diverso indicato alla fine. Puoi utilizzare la console Systems Manager o l'opzione AWS Command Line Interface (AWS CLI) per aggiungere la nuova versione. Il caricamento di un file installabile con il nome esatto di un file installabile esistente nel bucket Amazon S3 sovrascrive il file esistente. Nessun file installabile viene copiato dalla versione precedente nella nuova versione; è necessario caricare i file installabili dalla versione precedente affinché siano parte di una nuova versione. Dopo che Distributor ha completato la creazione di una nuova versione del pacchetto, puoi eliminare o riutilizzare il bucket Amazon S3, perché Distributor copia il software in un bucket Systems Manager interno come parte del processo di controllo delle versioni.
**Nota**
Ogni pacchetto è limitato a un massimo di 25 versioni. Puoi eliminare le versioni che non sono più necessarie.
**Topics**
+ [
## Aggiunta di una versione del pacchetto utilizzando la console
](#add-pkg-version)
+ [
## Aggiungere una versione del pacchetto utilizzando il AWS CLI
](#add-pkg-version-cli)
## Aggiunta di una versione del pacchetto utilizzando la console
Prima di procedere, segui le istruzioni in [Creazione di un pacchetto in Distributor](distributor-working-with-packages-create.md) per creare un nuovo pacchetto per la versione. Quindi, utilizza la console Systems Manager per aggiungere una nuova versione del pacchetto a Distributor.
### Aggiunta di una versione del pacchetto utilizzando il flusso di lavoro Simple (Semplice)
Per aggiungere una versione del pacchetto utilizzando il flusso di lavoro **Simple (Semplice)**, prepara file installabili aggiornati o aggiungi file installabili per supportare più piattaforme e architetture. Quindi, utilizza Distributor per caricare file installabili nuovi e aggiornati e aggiungere una versione del pacchetto. Il flusso di lavoro **Aggiungi versione** semplificato nella console Distributor aggiorna automaticamente il file manifest e il documento SSM associato.
**Per aggiungere una versione del pacchetto utilizzando il flusso di lavoro Simple (Semplice)**
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 **Distributor**.
1. Nella home page di Distributor, scegli il pacchetto a cui aggiungere un'altra versione.
1. Nella pagina **Add version (Aggiungi versione)**, scegli **Simple (Semplice)**.
1. Per **Version name (Nome versione)**, immettere un nome della versione. Il nome della versione per la nuova versione deve essere diverso dai nomi delle versioni precedenti. I nomi delle versioni possono essere composti da un massimo di 512 caratteri e non possono contenere caratteri speciali.
1. Per **Nome del bucket S3**, scegli un bucket S3 esistente dall'elenco. Questo può essere lo stesso bucket utilizzato per archiviare i file installabili per versioni precedenti, ma i nomi dei file installabili devono essere diversi per evitare di sovrascrivere i file installabili esistenti nel bucket.
1. Per **Prefisso della chiave S3**, immetti la sottocartella del bucket in cui sono archiviate le risorse installabili.
1. Per **Upload software (Carica software)**, naviga ai file del software installabili da collegare alla nuova versione. I file installabili da versioni esistenti non vengono automaticamente copiati in una nuova versione; è necessario caricare gli eventuali file installabili da versioni precedenti del pacchetto se si desidera che i file installabili facciano parte della nuova versione. Puoi caricare più file del software in una singola operazione.
1. Per **Piattaforma di destinazione**, verifica che la piattaforma del sistema operativo di destinazione visualizzata per ogni file installabile sia corretta. Se il sistema operativo mostrato non è corretto, scegli il sistema operativo corretto nell'elenco a discesa.
Nel flusso di lavoro di controllo delle versioni **Semplice**, poiché ogni file installabile viene caricato solo una volta, sono richieste fasi aggiuntive per fare si che un singolo file sia destinato a più sistemi operativi. Ad esempio, se carichi un file del software installabile denominato `Logtool_v1.1.1.rpm`, devi modificare alcune impostazioni predefinite nel flusso di lavoro **Semplice**, per istruire Distributor, affinché diriga lo stesso software sia sul sistema operativo di Amazon Linux che di Ubuntu Server. Per ovviare a questa limitazione puoi adottare una delle soluzioni riportate di seguito.
+ Utilizza il flusso di lavoro di controllo delle versioni **Avanzato**, comprimi ogni file installabile in un file .zip prima di iniziare e creare manualmente il manifesto, in modo da poter destinare un file installabile a più piattaforme o versioni del sistema operativo. Per ulteriori informazioni, consulta [Aggiunta di una versione del pacchetto utilizzando il flusso di lavoro Avanzato](#add-pkg-version-adv).
+ Modifica manualmente il file manifest nel flusso di lavoro **Semplice**, in modo che il file .zip sia destinato a più piattaforme o versioni di sistema operativo. Per ulteriori informazioni su come eseguire questa operazione, consulta la fine della fase 4 in [Fase 2: creazione del manifesto del pacchetto JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Per **Versione della piattaforma**, verifica che la versione della piattaforma del sistema operativo mostrata sia **\$1any** o una versione principale seguita da un carattere jolly (8.\$1) o l'esatta versione di rilascio del sistema operativo specifico, che deve essere valida per il software. Per ulteriori informazioni sulla specifica della versione della piattaforma, consulta la fase 4 in [Fase 2: creazione del manifesto del pacchetto JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Per **Architecture (Architettura)**, scegli l'architettura del processore corretta per ogni file installabile dall'elenco a discesa. Per ulteriori informazioni sulle architetture supportate, consulta [Architetture e piattaforme dei pacchetti supportate](distributor.md#what-is-a-package-platforms).
1. (Facoltativo) Espandere **Scripts (Script)** ed esaminare gli script di installazione e disinstallazione generati da Distributor per il software installabile.
1. Per aggiungere altri file del software installabili nella versione, scegli **Add software (Aggiungi software)**. Altrimenti, vai alla fase successiva.
1. (Facoltativo) Espandi **Manifesto** ed esamina il manifesto del pacchetto JSON generato da Distributor per il software installabile. Se hai modificato eventuali informazioni sul software installabile dal momento in cui hai avviato questa procedura, ad esempio versione della piattaforma o piattaforma di destinazione, scegli **Genera manifesto** per visualizzare il manifesto del pacchetto aggiornato.
Puoi modificare il manifesto manualmente se desideri che un software installabile sia la destinazione di più sistemi operativi, come descritto nella fase 9. Per ulteriori informazioni sulla modifica del manifesto, consulta [Fase 2: creazione del manifesto del pacchetto JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Al termine dell'aggiunta del software e dell'esame della piattaforma di destinazione, della versione e dei dati dell'architettura, scegli **Aggiungi versione**.
1. Attendi che Distributor termini il caricamento del software e la creazione della nuova versione del pacchetto. Distributor mostra lo stato di caricamento per ogni file installabile. In base al numero e alla dimensione dei pacchetti che stai aggiungendo, questa operazione può richiedere alcuni minuti. Distributor esegue automaticamente il reindirizzamento alla pagina **Dettagli del pacchetto** per il pacchetto, ma puoi scegliere di aprire questa pagina personalmente dopo che il software è stato caricato. La pagina **Dettagli del pacchetto** non mostra tutte le informazioni sul pacchetto finché Distributor non termina la creazione della nuova versione del pacchetto. Per interrompere il caricamento e la creazione della versione del pacchetto, scegli **Interrompi caricamento**.
1. Se Distributor non è in grado di caricare i file installabili del software, visualizza un messaggio **Caricamento non riuscito**. Per riprovare a eseguire il caricamento, scegli **Riprova caricamento**. Per ulteriori informazioni su come risolvere errori di creazione della versione del pacchetto, consulta [Risoluzione dei problemi AWS Systems ManagerDistributor](distributor-troubleshooting.md).
1. Quando Distributor ha terminato la creazione della nuova versione del pacchetto, nella pagina **Dettagli**, nella scheda **Versioni**, visualizza la nuova versione nell'elenco delle versioni del pacchetto disponibili. Imposta una versione predefinita del pacchetto scegliendo una versione e selezionando **Imposta versione predefinita**.
Se non imposti una versione predefinita, verrà selezionata la versione più recente del pacchetto.
### Aggiunta di una versione del pacchetto utilizzando il flusso di lavoro Avanzato
Per aggiungere una versione del pacchetto, [crea un pacchetto](distributor-working-with-packages-create.md), quindi utilizza Distributor per aggiungere una versione del pacchetto aggiungendo una voce al documento SSM che esiste per versioni precedenti. Per risparmiare tempo, aggiorna il manifesto di una versione precedente del pacchetto, modifica il valore della voce `version` nel manifesto (ad esempio da `Test_1.0` a `Test_2.0`) e salvalo come manifesto per la nuova versione. È necessario disporre di un manifesto aggiornato per aggiungere una nuova versione del pacchetto utilizzando il flusso di lavoro **Avanzato**.
**Per aggiungere una versione del pacchetto utilizzando il flusso di lavoro Avanzato**
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 **Distributor**.
1. Nella home page di Distributor, scegli il pacchetto a cui aggiungere un'altra versione, quindi seleziona **Aggiungi versione**.
1. Per **Nome versione**, immetti il valore esatto nella voce `version` del proprio file manifest.
1. Per **Nome del bucket S3**, scegli un bucket S3 esistente dall'elenco. Questo può essere lo stesso bucket utilizzato per archiviare i file installabili per versioni precedenti, ma i nomi dei file installabili devono essere diversi per evitare di sovrascrivere i file installabili esistenti nel bucket.
1. Per **Prefisso della chiave S3**, immetti la sottocartella del bucket in cui sono archiviate le risorse installabili.
1. Per **Manifesto**, scegli **Estrai dal pacchetto** per utilizzare un manifesto caricato nel bucket S3 con i file .zip.
(Facoltativo) Se non è stato caricato il manifesto JSON rivisto nel bucket Amazon S3 in cui sono stati archiviati i file .zip, scegli **Nuovo manifesto**. Puoi creare o incollare l'intero manifesto nel campo Editor JSON. Per ulteriori informazioni su come creare il manifesto JSON, consulta [Fase 2: creazione del manifesto del pacchetto JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Al completamento del manifesto, scegli **Aggiungi versione del pacchetto**.
1. Nella pagina **Dettagli**, nella scheda **Versioni**, visualizza la nuova versione nell'elenco delle versioni del pacchetto disponibili. Imposta una versione predefinita del pacchetto scegliendo una versione e selezionando **Imposta versione predefinita**.
Se non imposti una versione predefinita, verrà selezionata la versione più recente del pacchetto.
## Aggiungere una versione del pacchetto utilizzando il AWS CLI
È possibile utilizzare il AWS CLI per aggiungere una nuova versione del pacchetto aDistributor. Prima di eseguire questi comandi, devi creare una nuova versione del pacchetto e caricarla su S3, come descritto all'inizio di questo argomento.
**Per aggiungere una versione del pacchetto utilizzando il AWS CLI**
1. Eseguite il comando seguente per modificare il AWS Systems Manager documento con una voce per una nuova versione del pacchetto. Sostituiscilo *document-name* con il nome del documento. Sostituiscilo *amzn-s3-demo-bucket* con l'URL del manifesto JSON che hai copiato. [Fase 3: caricamento del pacchetto e del manifesto in un bucket Amazon S3](distributor-working-with-packages-create.md#packages-upload-s3) *S3-bucket-URL-of-package*è l'URL del bucket Amazon S3 in cui è archiviato l'intero pacchetto. Sostituisci *version-name-from-updated-manifest* con il valore di `version` nel manifesto. Imposta il parametro `--document-version` su `$LATEST` per associare il documento a questa versione del pacchetto, la versione più recente del documento.
```
aws ssm update-document \
--name "document-name" \
--content "S3-bucket-URL-to-manifest-file" \
--attachments Key="SourceUrl",Values="amzn-s3-demo-bucket" \
--version-name version-name-from-updated-manifest \
--document-version $LATEST
```
Di seguito è riportato un esempio di :
```
aws ssm update-document \
--name ExamplePackage \
--content "https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage/manifest.json" \
--attachments Key="SourceUrl",Values="https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage" \
--version-name 1.1.1 \
--document-version $LATEST
```
1. Esegui il comando seguente per verificare che il pacchetto sia stato aggiornato e visualizzare il manifesto del pacchetto. Sostituiscilo *package-name* con il nome del pacchetto e, facoltativamente, *document-version* con il numero di versione del documento (diverso dalla versione del pacchetto) che hai aggiornato. Se questa versione del pacchetto è associata alla versione più recente del documento, puoi specificare `$LATEST` per il valore del parametro facoltativo `--document-version`.
```
aws ssm get-document \
--name "package-name" \
--document-version "document-version"
```
Per informazioni sulle altre opzioni che è possibile utilizzare con il **update-document** comando, vedere [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html)la AWS Systems Manager sezione della Guida ai *AWS CLI comandi*.
# Installazione o aggiornamento dei pacchetti Distributor
È possibile distribuire pacchetti nei nodi AWS Systems Manager gestiti utilizzando Distributor uno strumento in AWS Systems Manager. Per distribuire i pacchetti, usa Console di gestione AWS o AWS Command Line Interface ()AWS CLI. Al momento, puoi distribuire una sola versione di un pacchetto per ogni comando. È possibile installare nuovi pacchetti o aggiornare le installazioni esistenti in locale. Puoi scegliere di implementare una versione specifica oppure sempre quella più recente di un pacchetto per la distribuzione. Ti consigliamo di utilizzareState Manager, uno strumento in AWS Systems Manager, per installare i pacchetti. L'utilizzo State Manager aiuta a garantire che i nodi gestiti eseguano sempre la maggior parte della up-to-date versione del pacchetto.
**Importante**
I pacchetti installati tramite Distributor devono essere disinstallati solo utilizzando Distributor. In caso contrario, Systems Manager può comunque registrare l'applicazione come `INSTALLED` e portare ad altri risultati indesiderati.
| Preferenza | AWS Systems Manager azione | Ulteriori informazioni |
| --- | --- | --- |
| Installare o aggiornare immediatamente un pacchetto. | Run Command | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| Installare o aggiornare un pacchetto in base a una pianificazione, in modo che l'installazione includa sempre la versione predefinita. | State Manager | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| Installare automaticamente un pacchetto sui nuovi nodi gestiti che hanno un tag o set di tag specifico. Ad esempio, l'installazione dell' CloudWatch agente Amazon su nuove istanze. | State Manager | Uno dei modi per farlo consiste nell'applicare i tag ai nuovi nodi gestiti, quindi specificare i tag come destinazioni nell'associazione di State Manager. State Manager installa automaticamente il pacchetto in un'associazione sui nodi gestiti che hanno tag corrispondenti. Per informazioni, consulta [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md). |
**Topics**
+ [
## Installazione o aggiornamento di un pacchetto una tantum utilizzando la console
](#distributor-deploy-pkg-console)
+ [
## Pianificazione dell'installazione o dell'aggiornamento di un pacchetto utilizzando la console
](#distributor-deploy-sm-pkg-console)
+ [
## Installazione di un pacchetto una sola volta utilizzando il AWS CLI
](#distributor-deploy-pkg-cli)
+ [
## Aggiornamento di un pacchetto una sola volta utilizzando il AWS CLI
](#distributor-update-pkg-cli)
+ [
## Pianificazione dell'installazione di un pacchetto utilizzando il AWS CLI
](#distributor-smdeploy-pkg-cli)
+ [
## Pianificazione dell'aggiornamento di un pacchetto utilizzando il AWS CLI
](#distributor-smupdate-pkg-cli)
## Installazione o aggiornamento di un pacchetto una tantum utilizzando la console
Puoi utilizzare la AWS Systems Manager console per installare o aggiornare un pacchetto una sola volta. Quando si configura un'installazione singola[AWS Systems Manager Run Command](run-command.md), Distributor utilizza uno strumento per eseguire l'installazione. AWS Systems Manager
**Per installare o aggiornare un pacchetto una tantum utilizzando la 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 **Distributor**.
1. Nella home page di Distributor, scegli il pacchetto da installare.
1. Scegli **Install one time (Installa una tantum)**.
Questo comando apre Run Command con il documento del comando `AWS-ConfigureAWSPackage` e il pacchetto Distributor già selezionati.
1. Per **Document version (Versione documento)**, selezionare la versione del documento `AWS-ConfigureAWSPackage` che si desidera eseguire.
1. Per **Action (Operazione)**, selezionare **Install (Installa)**.
1. Per **Installation type (Tipo di installazione)**, scegliere una delle seguenti opzioni:
+ **Uninstall and reinstall (Disinstalla e reinstalla)**: il pacchetto viene completamente disinstallato e quindi reinstallato. L'applicazione non è disponibile fino al completamento della reinstallazione.
+ **In-place update (Aggiornamento in locale)**: solo i file nuovi o modificati vengono aggiunti all'installazione esistente in base alle istruzioni fornite in uno script `update`. L'applicazione rimane disponibile durante tutto il processo di aggiornamento. Questa opzione non è supportata per i pacchetti AWS pubblicati ad eccezione del `AWSEC2Launch-Agent` pacchetto.
1. Per **Name (Nome)**, verificare che sia immesso il nome del pacchetto selezionato.
1. (Facoltativo) In **Version (Versione)**, immettere il nome della versione del pacchetto. Se lasci vuoto questo campo, Run Command installa la versione predefinita selezionata in Distributor.
1. In **Targets (Destinazioni)**, identificare i nodi gestiti in cui si desidera eseguire questa operazione specificando i tag, selezionando le istanze manualmente o indicando un gruppo di risorse.
**Nota**
Se nell'elenco non si visualizza un nodo gestito, vedi [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md).
1. In **Altri parametri**:
+ In **Commento**, digita le informazioni su questo comando.
+ In **Timeout (secondi)**, specifica il numero di secondi che il sistema dovrà attendere prima di generare un errore per l'intera esecuzione del comando.
1. Per **Rate control (Controllo velocità)**:
+ In **Concurrency (Simultaneità)**, specificare un numero o una percentuale di destinazioni su cui eseguire contemporaneamente il comando.
**Nota**
Se sono state selezionate le destinazioni specificando i tag o i gruppi di risorse, e se non si conosce con certezza il numero di nodi gestiti di destinazione, limitare il numero di destinazioni che possono eseguire il documento contemporaneamente specificando una percentuale.
+ In **Error threshold (Soglia di errore)** specifica quando interrompere l'esecuzione del comando sulle altre destinazioni dopo un errore su un numero o una percentuale di nodi gestiti. Se ad esempio si specificano tre errori, Systems Manager interrompe l'invio del comando quando riceve il quarto errore. Anche i nodi gestiti che stanno ancora elaborando il comando potrebbero inviare errori.
1. (Facoltativo) Nella sezione **Opzioni di output**, per salvare l'output del comando in un file, seleziona la casella **Scrivi l'output del comando in un bucket S3**. Digita i nomi del bucket e del prefisso (cartella) nelle caselle.
**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 per un ambiente ibrido](hybrid-multicloud-service-role.md). Inoltre, se il bucket S3 specificato si trova su un Account AWS diverso, assicurarsi che il profilo dell'istanza o il ruolo di servizio IAM associato al nodo gestito disponga delle autorizzazioni necessarie per scrivere su quel bucket.
1. Se vuoi che vengano inviate notifiche sullo stato dell'esecuzione del comando, nella sezione **Notifiche SNS** selezionara la casella di controllo **Abilita notifiche SNS**.
Per ulteriori informazioni, sulla configurazione delle notifiche Amazon SNS per Run Command consulta [Monitoraggio delle modifiche di stato di Systems Manager utilizzando le notifiche Amazon SNS](monitoring-sns-notifications.md).
1. Quando si è pronti per installare il pacchetto, scegliere **Run (Esegui)**.
1. L'area **Command status (Stato del comando)** segnala lo stato di avanzamento dell'esecuzione. Se il comando è ancora in corso, scegliere l'icona di aggiornamento nell'angolo in alto a sinistra della console finché la colonna **Overall status (Stato generale)** o **Detailed status (Stato dettagliato)** non mostra **Success (Riuscito)** o **Failed (Non riuscito)**.
1. Nell'area **Targets and outputs (Destinazioni e uscite)**, scegli il pulsante accanto al nome del nodo gestito e seleziona **View output (Visualizza output)**.
La pagina di output del comando mostra i risultati di esecuzione del comando.
1. (Facoltativo) Se si sceglie di scrivere l'output dei comandi in un bucket Amazon S3, seleziona **Amazon S3** per visualizzare i dati del log di output.
## Pianificazione dell'installazione o dell'aggiornamento di un pacchetto utilizzando la console
È possibile utilizzare la AWS Systems Manager console per pianificare l'installazione o l'aggiornamento di un pacchetto. Quando pianifichi l'installazione o l'aggiornamento del un pacchetto, Distributor utilizza [AWS Systems Manager State Manager](systems-manager-state.md) per eseguire l'installazione o l'aggiornamento.
**Per pianificare un'installazione del pacchetto utilizzando la 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 **Distributor**.
1. Nella home page di Distributor, scegliere il pacchetto da installare o aggiornare.
1. Per **Install package (Installa pacchetto)**, scegliere **Install on a schedule (Installa in base a una pianificazione)**.
Questo comando apre State Manager in una nuova associazione creata per te.
1. Per **Name (Nome)** immettere un nome (ad esempio **Deploy-test-agent-package**). Questo passaggio è facoltativo, ma è consigliato. Gli spazi non sono consentiti nel nome.
1. Nell'elenco **Document (Documento)**, il nome del documento `AWS-ConfigureAWSPackage` è già selezionato.
1. Per **Action (Operazione)**, verificare che sia selezionata l'opzione **Install (Installa)**.
1. Per **Installation type (Tipo di installazione)**, scegliere una delle seguenti opzioni:
+ **Uninstall and reinstall (Disinstalla e reinstalla)**: il pacchetto viene completamente disinstallato e quindi reinstallato. L'applicazione non è disponibile fino al completamento della reinstallazione.
+ **In-place update (Aggiornamento in locale)**: solo i file nuovi o modificati vengono aggiunti all'installazione esistente in base alle istruzioni fornite in uno script `update`. L'applicazione rimane disponibile durante tutto il processo di aggiornamento.
1. Per **Name (Nome)**, verificare che sia inserito il nome del pacchetto.
1. Per **Version (Versione)**, se si desidera installare una versione del pacchetto diversa dall'ultima versione pubblicata, immettere l'identificatore della versione.
1. In **Targets (Destinazioni)** scegliere **Selecting all managed instances in this account (Selezione di tutte le istanze gestite in questo account)**, **Specifying tags (Specifica tag)** o **Manually Selecting Instance (Selezione manuale dell'istanza)**. Se fai riferimento alle risorse con i tag, immetti una chiave e un valore del tag nei campi visualizzati.
**Nota**
Puoi scegliere i dispositivi AWS IoT Greengrass principali gestiti **scegliendo Selezione di tutte le istanze gestite in questo account** o **Selezione manuale dell'istanza**.
1. In **Specify schedule (Specifica pianificazione)** scegliere **On Schedule (In base a pianificazione)** per eseguire l'associazione in base a una pianificazione regolare o **No Schedule (Nessuna pianificazione)** per eseguire l'associazione una sola volta. Per ulteriori informazioni su queste opzioni, consulta [Utilizzo delle associazioni in Systems Manager](state-manager-associations.md). Utilizza i controlli per creare una pianificazione `cron` o rate per l'associazione.
1. Scegli **Crea associazione**.
1. Nella pagina **Association (Associazione)**, scegliere il pulsante accanto all'associazione creata e selezionare **Apply association now (Applica associazione ora)**.
State Manager crea ed esegue immediatamente l'associazione sulle destinazioni specificate. Per ulteriori informazioni sui risultati dell'esecuzione delle associazioni, consulta [Utilizzo delle associazioni in Systems Manager](state-manager-associations.md) in questa guida.
Per ulteriori informazioni sull'utilizzo delle opzioni in **Advanced options (Opzioni avanzate)**, **Rate control (Controllo della velocità)** e **Output options (Opzioni di output)**, consulta [Utilizzo delle associazioni in Systems Manager](state-manager-associations.md).
## Installazione di un pacchetto una sola volta utilizzando il AWS CLI
È possibile eseguire **send-command** l'installazione AWS CLI di un Distributor pacchetto una sola volta. Se il pacchetto è già installato, l'applicazione verrà disconnessa mentre il pacchetto viene disinstallato e sostituito con la nuova versione.
**Per installare un pacchetto una sola volta usando il AWS CLI**
+ Esegui il comando seguente nell' AWS CLI.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
**Nota**
Il comportamento predefinito per `installationType` è `Uninstall and reinstall`. È possibile omettere `"installationType":["Uninstall and reinstall"]` da questo comando quando si installa un pacchetto completo.
Di seguito è riportato un esempio di :
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-00000000000000" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["ExamplePackage"]}'
```
Per informazioni sulle altre opzioni che è possibile utilizzare con il **send-command** comando, vedere [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)la AWS Systems Manager sezione del *AWS CLI Command Reference*.
## Aggiornamento di un pacchetto una sola volta utilizzando il AWS CLI
È possibile eseguire **send-command** il AWS CLI per aggiornare un Distributor pacchetto senza mettere offline l'applicazione associata. Vengono sostituiti solo i file nuovi o aggiornati nel pacchetto.
**Per aggiornare un pacchetto una sola volta utilizzando il AWS CLI**
+ Esegui il comando seguente nell' AWS CLI.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
**Nota**
Quando si aggiungono file nuovi o modificati, è necessario includere `"installationType":["In-place update"]` nel comando.
Di seguito è riportato un esempio di :
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["ExamplePackage"]}'
```
Per informazioni sulle altre opzioni che è possibile utilizzare con il **send-command** comando, vedere [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)la AWS Systems Manager sezione del *AWS CLI Command Reference*.
## Pianificazione dell'installazione di un pacchetto utilizzando il AWS CLI
È possibile eseguire l'installazione AWS CLI di un Distributor pacchetto **create-association** in base a una pianificazione. Il valore `--name`, ossia il nome del documento, è sempre `AWS-ConfigureAWSPackage`. Il comando seguente utilizza la chiave `InstanceIds` per specificare i nodi gestiti di destinazione. Se il pacchetto è già installato, l'applicazione verrà disconnessa mentre il pacchetto viene disinstallato e sostituito con la nuova versione.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"instance-ID1\",\"instance-ID2\"]}]
```
**Nota**
Il comportamento predefinito per `installationType` è `Uninstall and reinstall`. È possibile omettere `"installationType":["Uninstall and reinstall"]` da questo comando quando si installa un pacchetto completo.
Di seguito è riportato un esempio di :
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["Test-ConfigureAWSPackage"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"i-02573cafcfEXAMPLE\",\"i-0471e04240EXAMPLE\"]}]
```
Per informazioni sulle altre opzioni utilizzabili con il **create-association** comando, consulta [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)la AWS Systems Manager sezione del *AWS CLI Command Reference*.
## Pianificazione dell'aggiornamento di un pacchetto utilizzando il AWS CLI
È possibile eseguire l'aggiornamento AWS CLI di un Distributor pacchetto **create-association** in base a una pianificazione senza mettere offline l'applicazione associata. Vengono sostituiti solo i file nuovi o aggiornati nel pacchetto. Il valore `--name`, ossia il nome del documento, è sempre `AWS-ConfigureAWSPackage`. Il comando seguente utilizza la chiave `InstanceIds` per specificare le istanze di destinazione.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"instance-ID1\",\"instance-ID2\"]}]
```
**Nota**
Quando si aggiungono file nuovi o modificati, è necessario includere `"installationType":["In-place update"]` nel comando.
Di seguito è riportato un esempio di :
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["Test-ConfigureAWSPackage"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"i-02573cafcfEXAMPLE\",\"i-0471e04240EXAMPLE\"]}]
```
Per informazioni sulle altre opzioni utilizzabili con il **create-association** 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)consulta la AWS Systems Manager sezione della Guida ai *AWS CLI comandi*.
# Disinstallazione di un pacchetto Distributor
Puoi usare Console di gestione AWS o il AWS Command Line Interface (AWS CLI) per disinstallare Distributor i pacchetti dai tuoi nodi AWS Systems Manager gestiti utilizzandoRun Command. Distributore Run Command sono strumenti in AWS Systems Manager. In questa versione, puoi disinstallare una sola versione di un pacchetto per ogni comando. Puoi disinstallare una versione specifica oppure la versione predefinita.
**Importante**
I pacchetti installati tramite Distributor devono essere disinstallati solo utilizzando Distributor. In caso contrario, Systems Manager può comunque registrare l'applicazione come `INSTALLED` e portare ad altri risultati indesiderati.
**Topics**
+ [
## Disinstallazione di un pacchetto utilizzando la console
](#distributor-pkg-uninstall-console)
+ [
## Disinstallazione di un pacchetto utilizzando AWS CLI
](#distributor-pkg-uninstall-cli)
## Disinstallazione di un pacchetto utilizzando la console
Puoi utilizzare Run Command nella console Systems Manager per disinstallare un pacchetto una sola volta. Distributor utilizza [AWS Systems Manager Run Command](run-command.md) per disinstallare i pacchetti.
**Per disinstallare un pacchetto utilizzando la 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 **Run Command**.
1. Nella home page di Run Command, scegli **Run command (Esegui comando)**.
1. Scegli il documento del comando `AWS-ConfigureAWSPackage`.
1. In **Action (Operazione)** scegli **Uninstall (Disinstalla)**
1. In **Name (Nome)** digita il nome del pacchetto da disinstallare.
1. Per **Targets (Obiettivi)**, scegli il metodo di destinazione dei file utilizzato dai tuoi nodi gestiti. È possibile specificare una chiave di tag e valori condivisi dalle destinazioni. È inoltre possibile specificare le destinazioni scegliendo attributi, ad esempio un'ID, una piattaforma e una versione SSM Agent.
1. Puoi utilizzare le opzioni avanzate per aggiungere commenti sull'operazione, modificare i valori **Concurrency (Concorrenza)** ed **Error threshold (Soglia errore)** in **Rate control (Controllo frequenza)**, specificare le opzioni di output oppure configurare le notifiche di Amazon Simple Notification Service (Amazon SNS). Per ulteriori informazioni, consulta [Esecuzione di comandi dalla console](https://docs.aws.amazon.com/systems-manager/latest/userguide/rc-console.html) in questa guida.
1. Quando sei pronto a disinstallare il pacchetto, scegli **Run (Esegui)**, quindi **View results (Visualizza risultati)**.
1. Nell'elenco di comandi scegli il comando `AWS-ConfigureAWSPackage` che hai eseguito. Se il comando è ancora in corso, scegli l'icona di aggiornamento nell'angolo in alto a destra della console.
1. Quando la colonna **Status** (Stato) mostra **Success** (Riuscito) o **Failed** (Non riuscito), scegli la scheda **Output**.
1. Scegli **View output (Visualizza output)**. La pagina di output del comando mostra i risultati di esecuzione del comando.
## Disinstallazione di un pacchetto utilizzando AWS CLI
È possibile utilizzare AWS CLI per disinstallare un Distributor pacchetto dai nodi gestiti utilizzandoRun Command.
**Per disinstallare un pacchetto utilizzando il AWS CLI**
+ Esegui il comando seguente nell' AWS CLI.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Uninstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
Di seguito è riportato un esempio di :
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Uninstall"],"name":["Test-ConfigureAWSPackage"]}'
```
Per informazioni sulle altre opzioni che è possibile utilizzare con il **send-command** comando, vedere [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)la AWS Systems Manager sezione della Guida di *riferimento ai AWS CLI comandi*.
# Eliminazione di un pacchetto Distributor
In questa sezione viene descritto come eliminare un pacchetto. Non è possibile eliminare una versione di un pacchetto, ma solo l'intero pacchetto.
## Eliminazione di un pacchetto utilizzando la console
È possibile utilizzare la AWS Systems Manager console per eliminare un pacchetto o una versione del pacchetto daDistributor, uno strumento in AWS Systems Manager. L'eliminazione di un pacchetto cancella tutte le relative versioni da Distributor.
**Per eliminare una pacchetto utilizzando la 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 **Distributor**.
1. Nella home page di **Distributor**, scegliere il pacchetto da eliminare.
1. Nella pagina dei dettagli del pacchetto, scegli **Delete package (Elimina pacchetto)**.
1. Quando viene richiesto di confermare l'eliminazione, scegli **Delete package (Elimina pacchetto)**.
## Eliminazione di una versione del pacchetto utilizzando la console
Puoi utilizzare la console Systems Manager per eliminare una versione del pacchetto da Distributor.
**Per eliminare una versione del pacchetto utilizzando la 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 **Distributor**.
1. Nella home page di **Distributor**, scegliere il pacchetto di cui eliminare la versione.
1. Nella pagina delle versioni del pacchetto, scegliere la versione da eliminare e scegliere **Delete version (Elimina versione)**.
1. Quando viene richiesto di confermare l'eliminazione, scegliere **Delete package version (Elimina versione del pacchetto)**.
## Eliminazione di un pacchetto utilizzando la riga di comando
Puoi utilizzare lo strumento a riga di comando preferito per eliminare un pacchetto da Distributor.
------
#### [ Linux & macOS ]
**Per eliminare un pacchetto utilizzando il AWS CLI**
1. Esegui il comando seguente per elencare i documenti per i pacchetti specifici. Nei risultati di questo comando, cerca il pacchetto da eliminare.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
1. Eseguire il comando seguente per eliminare un pacchetto. Sostituire *package-name* con il nome del pacchetto.
```
aws ssm delete-document \
--name "package-name"
```
1. Eseguire di nuovo il comando **list-documents** per verificare che il pacchetto sia stato eliminato. Il pacchetto che hai eliminato non viene incluso nell'elenco.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
------
#### [ Windows ]
**Per eliminare un pacchetto utilizzando il AWS CLI**
1. Esegui il comando seguente per elencare i documenti per i pacchetti specifici. Nei risultati di questo comando, cerca il pacchetto da eliminare.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
1. Eseguire il comando seguente per eliminare un pacchetto. Sostituire *package-name* con il nome del pacchetto.
```
aws ssm delete-document ^
--name "package-name"
```
1. Eseguire di nuovo il comando **list-documents** per verificare che il pacchetto sia stato eliminato. Il pacchetto che hai eliminato non viene incluso nell'elenco.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
------
#### [ PowerShell ]
**Per eliminare un pacchetto utilizzando Tools for PowerShell**
1. Esegui il comando seguente per elencare i documenti per i pacchetti specifici. Nei risultati di questo comando, cerca il pacchetto da eliminare.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
1. Eseguire il comando seguente per eliminare un pacchetto. Sostituire *package-name* con il nome del pacchetto.
```
Remove-SSMDocument `
-Name "package-name"
```
1. Eseguire di nuovo il comando **Get-SSMDocumentList** per verificare che il pacchetto sia stato eliminato. Il pacchetto che hai eliminato non viene incluso nell'elenco.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
------
## Eliminazione di una versione del pacchetto utilizzando la riga di comando
Puoi utilizzare lo strumento a riga di comando preferito per eliminare una versione del pacchetto da Distributor.
------
#### [ Linux & macOS ]
**Per eliminare una versione del pacchetto utilizzando il AWS CLI**
1. Eseguire il comando seguente per elencare le versioni del pacchetto. Nei risultati di questo comando, cercare la versione del pacchetto da eliminare.
```
aws ssm list-document-versions \
--name "package-name"
```
1. Per eliminare la versione del pacchetto, esegui il comando seguente. Sostituire *package-name* con il nome del pacchetto e *version* con il numero di versione.
```
aws ssm delete-document \
--name "package-name" \
--document-version version
```
1. Eseguire il comando **list-document-versions** per verificare che la versione del pacchetto sia stata eliminata. La versione del pacchetto eliminata non è più presente nell'elenco.
```
aws ssm list-document-versions \
--name "package-name"
```
------
#### [ Windows ]
**Per eliminare una versione del pacchetto utilizzando il AWS CLI**
1. Eseguire il comando seguente per elencare le versioni del pacchetto. Nei risultati di questo comando, cercare la versione del pacchetto da eliminare.
```
aws ssm list-document-versions ^
--name "package-name"
```
1. Per eliminare la versione del pacchetto, esegui il comando seguente. Sostituire *package-name* con il nome del pacchetto e *version* con il numero di versione.
```
aws ssm delete-document ^
--name "package-name" ^
--document-version version
```
1. Eseguire il comando **list-document-versions** per verificare che la versione del pacchetto sia stata eliminata. La versione del pacchetto eliminata non è più presente nell'elenco.
```
aws ssm list-document-versions ^
--name "package-name"
```
------
#### [ PowerShell ]
**Per eliminare una versione del pacchetto utilizzando Tools for PowerShell**
1. Eseguire il comando seguente per elencare le versioni del pacchetto. Nei risultati di questo comando, cercare la versione del pacchetto da eliminare.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
1. Per eliminare la versione del pacchetto, esegui il comando seguente. Sostituire *package-name* con il nome del pacchetto e *version* con il numero di versione.
```
Remove-SSMDocument `
-Name "package-name" `
-DocumentVersion version
```
1. Eseguire il comando **Get-SSMDocumentVersionList** per verificare che la versione del pacchetto sia stata eliminata. La versione del pacchetto eliminata non è più presente nell'elenco.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
------
Per informazioni sulle altre opzioni utilizzabili con il **list-documents** comando, [https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html)consultate la AWS Systems Manager sezione del *AWS CLI Command Reference*. Per informazioni sulle altre opzioni che puoi utilizzare con il comando **delete-document** , consulta [https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html).
# Verifica e registrazione dell'attività Distributor
È possibile utilizzare AWS CloudTrail per controllare le attività relative aDistributor, uno strumento in AWS Systems Manager. Per ulteriori informazioni sulle opzioni di verifica e registrazione per Systems Manager, consulta [Registrazione e monitoraggio AWS Systems Manager](monitoring.md).
## DistributorAttività di audit utilizzando CloudTrail
CloudTrail acquisisce le chiamate API effettuate nella AWS Systems Manager console, AWS Command Line Interface (AWS CLI) e nell'SDK Systems Manager. Le informazioni possono essere visualizzate nella CloudTrail console o archiviate in un bucket Amazon Simple Storage Service (Amazon S3). Un bucket viene utilizzato per tutti i CloudTrail log del tuo account.
I log di Run Command e le azioni di State Manager mostrano l’attività di creazione di documenti, installazione e disinstallazione di pacchetti. Run Command e State Manager sono strumenti di AWS Systems Manager. Per ulteriori informazioni sulla visualizzazione e l'utilizzo dei CloudTrail registri delle attività di Systems Manager, vedere[Registrazione delle chiamate AWS Systems Manager API con AWS CloudTrail](monitoring-cloudtrail-logs.md).
# Risoluzione dei problemi AWS Systems ManagerDistributor
Le informazioni seguenti consentono di risolvere i problemi che potrebbero verificarsi durante l'utilizzo di Distributor, uno strumento di AWS Systems Manager.
**Topics**
+ [
## È installato un pacchetto errato con lo stesso nome
](#distributor-tshoot-1)
+ [
## Errore: non è stato possibile recuperare il manifesto. Non è stato possibile trovare la versione più recente del pacchetto
](#distributor-tshoot-2)
+ [
## Errore: non è stato possibile recuperare il manifesto. Eccezione per convalida
](#distributor-tshoot-3)
+ [
## Il pacchetto non è supportato (manca l'azione di installazione)
](#distributor-tshoot-4)
+ [
## Errore: impossibile scaricare il manifesto, Il documento con nome non esiste
](#distributor-tshoot-5)
+ [
## Caricamento non riuscito.
](#distributor-tshoot-6)
+ [
## Errore: impossibile trovare la piattaforma. Nessun manifesto trovato per la piattaforma: Oracle, versione 8.9, architettura x86\$164
](#distributor-tshoot-7)
## È installato un pacchetto errato con lo stesso nome
**Problema:** hai installato un pacchetto, ma Distributor ha installato un pacchetto diverso.
**Causa:** durante l'installazione, Systems Manager rileva tra i risultati i pacchetti pubblicati da AWS prima dei pacchetti esterni definiti dall'utente. Se il nome del pacchetto definito dall'utente è lo stesso di un nome di pacchetto AWS pubblicato, il AWS pacchetto viene installato al posto del pacchetto.
**Soluzione:** per evitare questo problema, assegnate al pacchetto un nome diverso dal nome di un pacchetto AWS pubblicato.
## Errore: non è stato possibile recuperare il manifesto. Non è stato possibile trovare la versione più recente del pacchetto
**Problema:** hai ricevuto un errore simile al seguente.
```
Failed to retrieve manifest: ResourceNotFoundException: Could not find the latest version of package
arn:aws:ssm:::package/package-name status code: 400, request id: guid
```
**Causa:** stai utilizzando una versione di SSM Agent con Distributor precedente alla versione 2.3.274.0.
**Soluzione:** aggiorna la versione di SSM Agent alla versione 2.3.274.0 o successiva. Per ulteriori informazioni, consulta [Aggiornamento di SSM Agent utilizzando Run Command](run-command-tutorial-update-software.md#rc-console-agentexample) o [Procedura dettagliata: aggiorna SSM Agent automaticamente con AWS CLI](state-manager-update-ssm-agent-cli.md).
## Errore: non è stato possibile recuperare il manifesto. Eccezione per convalida
**Problema:** hai ricevuto un errore simile al seguente.
```
Failed to retrieve manifest: ValidationException: 1 validation error detected: Value 'documentArn'
at 'packageName' failed to satisfy constraint: Member must satisfy regular expression pattern:
arn:aws:ssm:region-id:account-id:package/package-name
```
**Causa:** stai utilizzando una versione di SSM Agent con Distributor precedente alla versione 2.3.274.0.
**Soluzione:** aggiorna la versione di SSM Agent alla versione 2.3.274.0 o successiva. Per ulteriori informazioni, consulta [Aggiornamento di SSM Agent utilizzando Run Command](run-command-tutorial-update-software.md#rc-console-agentexample) o [Procedura dettagliata: aggiorna SSM Agent automaticamente con AWS CLI](state-manager-update-ssm-agent-cli.md).
## Il pacchetto non è supportato (manca l'azione di installazione)
**Problema:** hai ricevuto un errore simile al seguente.
```
Package is not supported (package is missing install action)
```
**Causa:** la struttura della directory del pacchetto non è corretta.
**Soluzione:**non comprimere una directory padre contenente il software e gli script richiesti. Invece, crea un file `.zip` di tutti i contenuti richiesti direttamente nel percorso assoluto. Per verificare che il file `.zip` è stato creato correttamente, decomprimere la directory della piattaforma di destinazione ed esaminare la struttura della directory. Ad esempio, il percorso assoluto dello script di installazione dovrebbe essere `/ExamplePackage_targetPlatform/install.sh`.
## Errore: impossibile scaricare il manifesto, Il documento con nome non esiste
**Problema:** hai ricevuto un errore simile al seguente.
```
Failed to download manifest - failed to retrieve package document description: InvalidDocument: Document with name filename does not exist.
```
**Causa 1:** Distributor non riesce a trovare il pacchetto in base al nome del pacchetto quando si condivide un pacchetto Distributor da un altro account.
**Soluzione 1:** quando viene condiviso un pacchetto da un altro account, utilizzare il nome della risorsa Amazon (ARN) completo per il pacchetto e non solo il nome.
**Causa 2:** quando utilizzi un VPC, non hai fornito al tuo profilo di istanza IAM l'accesso al bucket S3 AWS gestito che contiene il documento `AWS-ConfigureAWSPackage` per il Regione AWS quale ti stai rivolgendo.
**Soluzione 2:** assicurati che il profilo dell'istanza IAM SSM Agent fornisca l'accesso al bucket S3 AWS gestito che contiene il documento relativo al target a cui Regione AWS ti `AWS-ConfigureAWSPackage` rivolgi, come spiegato in. [SSM Agentcomunicazioni con AWS bucket S3 gestiti](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)
## Caricamento non riuscito.
**Problema:** hai ricevuto un errore simile al seguente.
```
Upload failed. At least one of your files was not successfully uploaded to your S3 bucket.
```
**Causa:** il nome del pacchetto software include uno spazio. Ad esempio, `Hello World.msi` non verrebbe caricato.
## Errore: impossibile trovare la piattaforma. Nessun manifesto trovato per la piattaforma: Oracle, versione 8.9, architettura x86\$164
**Problema:** hai ricevuto un errore simile al seguente.
```
Failed to find platform: no manifest found for platform: oracle, version 8.9, architecture x86_64
```
**Causa:** l'errore indica che il manifesto del pacchetto JSON non ha alcuna definizione per quella piattaforma, in questo caso, Oracle Linux.
**Soluzione:** scarica il pacchetto che si desidera distribuire dal sito [Trend Micro Deep Security Software](https://help.deepsecurity.trendmicro.com/software.html). Crea un pacchetto software `.rpm` utilizzando il [Crea un pacchetto utilizzando il flusso di lavoro Semplice](distributor-working-with-packages-create.md#distributor-working-with-packages-create-simple). Imposta i seguenti valori per il pacchetto e completa il pacchetto software di caricamento utilizzando Distributor:
```
Platform version: _any
Target platform: oracle
Architecture: x86_64
```
# AWS Systems Manager Fleet Manager
Fleet Manager, uno strumento di AWS Systems Manager, è un'esperienza di interfaccia utente unificata (IU) che consente di gestire in remoto i nodi in esecuzione su AWS oppure on-premises. con Fleet Manager è possibile visualizzare lo stato di integrità e delle prestazioni dell'intero parco istanze server da un'unica console. È inoltre possibile raccogliere dati da singoli nodi per eseguire processi comuni di risoluzione dei problemi e gestione dalla console. Ciò include la connessione alle istanze di Windows tramite Remote Desktop Protocol (RDP), la visualizzazione del contenuto di cartelle e file, la gestione del registro di Windows, la gestione degli utenti del sistema operativo e altro ancora.
Per iniziare a utilizzare Fleet Manager, apri la [console di Systems Manager](https://console.aws.amazon.com/systems-manager/fleet-manager). Nel pannello di navigazione, scegli **Fleet Manager**.
## A chi è consigliato l'uso di Fleet Manager?
Si consiglia a tutti i clienti AWS che desiderano un sistema centralizzato per gestire il proprio parco istanze di nodi di utilizzare Fleet Manager.
## Quali sono i vantaggi di Fleet Manager per la mia organizzazione?
Fleet Manager offre questi vantaggi:
+ Eseguire una serie di attività comuni di amministrazione dei sistemi senza dover connettersi manualmente ai nodi gestiti.
+ Gestire nodi in esecuzione su più piattaforme da un'unica console unificata.
+ Gestire nodi che eseguono sistemi operativi diversi da un'unica console unificata.
+ Migliorare l'efficienza dell'amministrazione dei sistemi.
## Quali sono le funzionalità di Fleet Manager?
Le caratteristiche principali di Fleet Manager comprendono:
+ **Accedere al portale della Knowledgebase Red Hat**
Accedere a binari, conoscenze condivisione e forum di discussione nel portale della Knowledgebase di Red Hat tramite istanze Red Hat Enterprise Linux (RHEL).
+ **Stato del nodo gestito**
Visualizza quali istanze gestite sono `running` e quali istanze sono `stopped`. Per ulteriori informazioni sulle istanze arrestate, consulta [Arrestare e avviare un'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html) nella *Guida per l'utente di Amazon EC2*. Per i dispositivi core AWS IoT Greengrass, è possibile visualizzare quali sono `online`, `offline` o verificare lo stato `Connection lost`.
**Nota**
Se l'istanza è stata interrotta prima del 12 luglio 2021, non verrà visualizzata la proprietà evidenziatore `stopped`. Per mostrare l'evidenziatore, avvia e arresta l'istanza.
+ **Visualizzazione delle informazioni sull'istanza**
Visualizza le informazioni sui dati delle cartelle e dei file archiviati nei volumi collegati alle istanze gestite, i dati sulle prestazioni delle istanze in tempo reale e i dati di log archiviati nelle istanze.
+ **Visualizzare le informazioni dei dispositivi edge**
Visualizza il nome dell'oggetto AWS IoT Greengrass per il dispositivo, lo stato e la versione ping SSM Agent e altro ancora.
+ **Gestione account e registro**
Gestisci gli account utente del sistema operativo (OS) nelle istanze e il registro nelle istanze di Windows.
+ **Controlla l'accesso alle caratteristiche**
Controlla l'accesso alle funzionalità Fleet Manager tramite le policy (IAM) AWS Identity and Access Management. Con queste policy, puoi controllare quali utenti singoli o gruppi della tua organizzazione possono utilizzare diverse caratteristiche Fleet Manager e quali nodi gestiti possono gestire.
**Topics**
+ [
## A chi è consigliato l'uso di Fleet Manager?
](#fleet-who)
+ [
## Quali sono i vantaggi di Fleet Manager per la mia organizzazione?
](#fleet-benefits)
+ [
## Quali sono le funzionalità di Fleet Manager?
](#fleet-features)
+ [
# Configurazione di Fleet Manager
](setting-up-fleet-manager.md)
+ [
# Utilizzo dei nodi gestiti
](fleet-manager-managed-nodes.md)
+ [
# Gestione automatica delle istanze EC2 con la configurazione di gestione host predefinita
](fleet-manager-default-host-management-configuration.md)
+ [
# Connettersi a un'istanza gestita da Windows Server utilizzando Remote Desktop
](fleet-manager-remote-desktop-connections.md)
+ [
# Gestione dei volumi Amazon EBS all'interno di un'istanza gestita
](fleet-manager-manage-amazon-ebs-volumes.md)
+ [
# Accesso al portale Red Hat Knowledge base
](fleet-manager-red-hat-knowledge-base-access.md)
+ [
# Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti
](fleet-manager-troubleshooting-managed-nodes.md)
# Configurazione di Fleet Manager
Prima che gli utenti nell'Account AWS possano utilizzare Fleet Manager, uno strumento di AWS Systems Manager, per monitorare e controllare i nodi gestiti, è necessario che vengano concesse le autorizzazioni necessarie. Inoltre, è necessario che qualsiasi istanza Amazon Elastic Compute Cloud (Amazon EC2); dispositivo core AWS IoT Greengrass, server on-premises, dispositivo edge e macchina virtuale (VM) da monitorare e gestire utilizzando Fleet Manager, siano * nodi gestiti* da Systems Manager. Un nodo gestito è qualsiasi macchina configurata per l'uso con Systems Manager in ambienti [ibridi e multicloud](operating-systems-and-machine-types.md#supported-machine-types).
Ciò significa che i nodi devono soddisfare determinati prerequisiti ed essere configurati con AWS Systems Manager Agent (SSM Agent).
A seconda del tipo di macchina, fai riferimento a uno dei seguenti argomenti per assicurarti che le macchine soddisfino i requisiti per i nodi gestiti.
+ Istanze Amazon EC2: [Gestire le istanze EC2 con Systems Manager](systems-manager-setting-up-ec2.md)
**Suggerimento**
È possibile utilizzare anche Quick Setup, uno strumento di AWS Systems Manager, per configurare rapidamente e al meglio le istanze Amazon EC2 come istanze gestite in un singolo account. Se l'azienda o l'organizzazione utilizza AWS Organizations, è possibile configurare istanze su più unità organizzative (UO) e Regioni AWS. Per ulteriori informazioni sull'utilizzo di Quick Setup per la configurazione delle istanze gestite, consulta [Configura la gestione host Amazon EC2 tramite Quick Setup](quick-setup-host-management.md).
+ On-premises e altri tipi di server nel cloud: [Gestione dei nodi in ambienti ibridi e multicloud con Systems Manager](systems-manager-hybrid-multicloud.md)
+ Dispositivi (edge) AWS IoT Greengrass: [Gestione dei dispositivi edge con Systems Manager](systems-manager-setting-up-edge-devices.md)
**Topics**
+ [
# Controllo dell'accesso ad Fleet Manager
](configuring-fleet-manager-permissions.md)
# Controllo dell'accesso ad Fleet Manager
Per poter essere utilizzatoFleet Manager, uno strumento nel AWS Systems Manager tuo utente o ruolo AWS Identity and Access Management (IAM) deve disporre delle autorizzazioni richieste. Puoi creare una policy IAM che fornisca accesso a tutti le funzionalità Fleet Manager oppure modifica il criterio per concedere l'accesso alle caratteristiche scelte. Quindi concedi queste autorizzazioni agli utenti o alle identità del tuo account.
**Attività 1: crea policy IAM per definire le autorizzazioni di accesso**
Segui uno dei metodi illustrati nel seguente argomento della *Guida per l'utente IAM* per creare un IAM che fornisca alle identità (utenti, ruoli o gruppi di utenti) l'accesso a Fleet Manager:
+ [Definisci le autorizzazioni IAM personalizzate con le policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)
È possibile utilizzare una delle policy di esempio fornita di seguito o modificarle in base alle autorizzazioni che si desidera concedere. Forniamo policy di esempio di accesso completo a Fleet Manager e di accesso in sola lettura.
**Attività 2: collega le policy IAM agli utenti per concedere le autorizzazioni**
Dopo aver creato la policy o le policy IAM che definiscono le autorizzazioni di accesso a Fleet Manager, utilizza una delle seguenti procedure nella *Guida per l’utente IAM* per concedere queste autorizzazioni alle identità dell’account:
+ [Aggiunta di autorizzazioni per identità IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)
+ [Aggiunta di autorizzazioni per identità IAM (AWS CLI)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-cli)
+ [Aggiunta di autorizzazioni per identità IAM (API AWS )](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-api)
**Topics**
+ [
## Policy di esempio per l'accesso di amministratore di Fleet Manager
](#admin-policy-sample)
+ [
## Policy di esempio per l'accesso in sola lettura a Fleet Manager
](#read-only-policy-sample)
## Policy di esempio per l'accesso di amministratore di Fleet Manager
La seguente policy fornisce le autorizzazioni per tutte le funzionalità di Fleet Manager. Ciò significa che un utente può creare ed eliminare utenti e gruppi locali, modificare l'appartenenza ai gruppi per qualsiasi gruppo locale e modificare le chiavi o i valori del registro di Windows Server. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags",
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "General",
"Effect": "Allow",
"Action": [
"ssm:AddTagsToResource",
"ssm:DescribeInstanceAssociationsStatus",
"ssm:DescribeInstancePatches",
"ssm:DescribeInstancePatchStates",
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetServiceSetting",
"ssm:GetInventorySchema",
"ssm:ListComplianceItems",
"ssm:ListInventoryEntries",
"ssm:ListTagsForResource",
"ssm:ListCommandInvocations",
"ssm:ListAssociations",
"ssm:RemoveTagsFromResource"
],
"Resource": "*"
},
{
"Sid": "DefaultHostManagement",
"Effect": "Allow",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
},
{
"Sid": "SendCommand",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:SendCommand",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*:111122223333:document/SSM-SessionManagerRunShell",
"arn:aws:ssm:*:*:document/AWS-PasswordReset",
"arn:aws:ssm:*:*:document/AWSFleetManager-AddUsersToGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-CopyFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateDirectory",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateGroup",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateUser",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateUserInteractive",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateWindowsRegistryKey",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteGroup",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteUser",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteWindowsRegistryKey",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteWindowsRegistryValue",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetDiskInformation",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileSystemContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetPerformanceCounters",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetProcessDetails",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetUsers",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsEvents",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsRegistryContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-MountVolume",
"arn:aws:ssm:*:*:document/AWSFleetManager-MoveFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-RemoveUsersFromGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-RenameFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-SetWindowsRegistryValue",
"arn:aws:ssm:*:*:document/AWSFleetManager-StartProcess",
"arn:aws:ssm:*:*:document/AWSFleetManager-TerminateProcess"
]
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
}
]
}
```
------
## Policy di esempio per l'accesso in sola lettura a Fleet Manager
La seguente policy fornisce le autorizzazioni per le funzionalità di Fleet Manager di sola lettura. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "General",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceAssociationsStatus",
"ssm:DescribeInstancePatches",
"ssm:DescribeInstancePatchStates",
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetServiceSetting",
"ssm:GetInventorySchema",
"ssm:ListComplianceItems",
"ssm:ListInventoryEntries",
"ssm:ListTagsForResource",
"ssm:ListCommandInvocations",
"ssm:ListAssociations"
],
"Resource": "*"
},
{
"Sid": "SendCommand",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:SendCommand",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*:111122223333:document/SSM-SessionManagerRunShell",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetDiskInformation",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileSystemContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetPerformanceCounters",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetProcessDetails",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetUsers",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsEvents",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsRegistryContent"
]
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
}
]
}
```
------
# Utilizzo dei nodi gestiti
Un *nodo gestito* è qualsiasi macchina configurata per. AWS Systems Manager Puoi configurare i seguenti tipi di macchine come nodi gestiti:
+ Istanze Amazon Elastic Compute Cloud (Amazon EC2)
+ Server presso la propria sede (server on-premises)
+ AWS IoT Greengrass dispositivi principali
+ AWS IoT e dispositivi non AWS periferici
+ Macchine virtuali (VMs), anche VMs in altri ambienti cloud
Nella console di Systems Manager, qualsiasi macchina con prefisso "mi-" è stata configurata come nodo gestito utilizzando un'[*attivazione ibrida*](activations.md). I dispositivi Edge visualizzano il nome dell' AWS IoT oggetto.
**Nota**
L'unica funzionalità supportata per le istanze di macOS è la visualizzazione del file system.
**Informazioni sui livelli delle istanze di Systems Manager**
AWS Systems Manager offre un livello di istanze standard e un livello di istanze avanzate. Entrambi supportano nodi gestiti nell’ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). Il livello standard-instances consente di registrare un massimo di 1.000 computer per unità. Account AWS Regione AWS Se devi registrare più di 1.000 macchine in un singolo account e regione, utilizza il piano istanze avanzate. Non vi sono limitazioni nel numero di nodi gestiti che si possono creare nel livello istanze avanzate. Tutti i nodi gestiti configurati per Systems Manager hanno un prezzo su pay-per-use base. Per ulteriori informazioni su come abilitare le istanze avanzate, consulta [Attivazione del piano istanze avanzate](fleet-manager-enable-advanced-instances-tier.md). Per ulteriori informazioni sui prezzi, consulta [Prezzi di AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
Di seguito sono fornite alcune informazioni aggiuntive sul piano istanze standard e sul piano istanze avanzate:
+ Le istanze avanzate consentono inoltre di connettersi ai non EC2 nodi in un ambiente [ibrido e multicloud utilizzando](operating-systems-and-machine-types.md#supported-machine-types). AWS Systems Manager Session Manager Session Managerfornisce un accesso interattivo tramite shell alle istanze. Per ulteriori informazioni, consulta [AWS Systems Manager Session Manager](session-manager.md).
+ La quota di istanze standard si applica anche alle EC2 istanze che utilizzano un'attivazione locale di Systems Manager (che non è uno scenario comune).
+ Per applicare patch alle applicazioni rilasciate da Microsoft su macchine virtuali (VMs) istanze locali, attiva il livello delle istanze avanzate. Viene addebitato un costo per l'utilizzo del piano istanze avanzate. Non sono previsti costi aggiuntivi per applicare patch alle applicazioni rilasciate da Microsoft su istanze Amazon Elastic Compute Cloud (Amazon EC2). Per ulteriori informazioni, consulta [Applicazione di patch rilasciata da Microsoft in Windows Server](patch-manager-patching-windows-applications.md).
**Visualizza i nodi gestiti**
Se li propri nodi gestiti non sono elencati nella console, procedi come segue:
1. Verifica che la console sia aperta nel punto in Regione AWS cui hai creato i nodi gestiti. È possibile passare da una Regione all'altra utilizzando l'elenco nell'angolo in alto a destra della console.
1. Verifica che la procedura di configurazione per i nodi gestiti soddisfi i requisiti di Systems Manager. Per informazioni, consulta [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md).
1. Per i computer diversi EC2 da computer, verifica di aver completato il processo di attivazione ibrida. Per ulteriori informazioni, consulta [Gestione dei nodi in ambienti ibridi e multicloud con Systems Manager](systems-manager-hybrid-multicloud.md).
Prendi nota della seguenti informazioni aggiuntive:
+ La Fleet Manager console non mostra EC2 i nodi Amazon che sono stati terminati.
+ Systems Manager richiede riferimenti temporali precisi per eseguire le operazioni sui computer. Se la data e l'ora non sono impostate correttamente nei nodi gestiti, tali informazioni potrebbero non corrispondere alla data di firma delle richieste API. Per ulteriori informazioni, consulta [Casi d'uso e best practice](systems-manager-best-practices.md).
+ Quando creai o modifichi tag, potrebbe volerci fino a un'ora affinché il sistema mostri le modifiche nel filtro della tabella.
+ Se lo stato di un nodo gestito è rimasto `Connection Lost` per almeno 30 giorni, il nodo potrebbe non essere più elencato nella console Fleet Manager. Per inserirlo nuovamente nell'elenco, è necessario risolvere il problema che ha causato la perdita della connessione. Per suggerimenti sulla risoluzione dei problemi, consulta [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md).
**Verifica del supporto di Systems Manager su un nodo gestito**
AWS Config fornisce AWS Managed Rules, regole predefinite e personalizzabili che vengono AWS Config utilizzate per valutare se le configurazioni AWS delle risorse sono conformi alle migliori pratiche comuni. AWS Config Le Managed Rules includono la regola [ec2- -manager. instance-managed-by-systems](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html) Questa regola verifica se le EC2 istanze Amazon nel tuo account sono gestite da Systems Manager. Per ulteriori informazioni, consulta [Regole gestite di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html).
**Maggiore sicurezza nei nodi gestiti**
Per informazioni su come aumentare la posizione di sicurezza rispetto ai comandi non autorizzati a livello di root nei nodi gestiti, consulta [Limitare l'accesso ai comandi a livello di root tramite SSM Agent](ssm-agent-restrict-root-level-commands.md)
**Annullare registrazione dei nodi gestiti**
Puoi annullare la registrazione dei nodi gestiti in qualsiasi momento. Ad esempio, se gestisci più nodi con lo stesso ruolo AWS Identity and Access Management (IAM) e noti qualsiasi tipo di comportamento dannoso, puoi annullare la registrazione di un numero qualsiasi di computer in qualsiasi momento. (Per registrare nuovamente la stessa macchina, è necessario utilizzare un codice di attivazione ibrido e un ID di attivazione diversi da quelli utilizzati in precedenza per la registrazione.) Per ulteriori informazioni sull'annullamento delle registrazioni dei nodi gestiti, consulta [Annullamento della registrazione dei nodi gestiti in un ambiente ibrido e multicloud](fleet-manager-deregister-hybrid-nodes.md).
**Topics**
+ [
# Configurazione dei livelli di istanza
](fleet-manager-configure-instance-tiers.md)
+ [
# Reimpostazione delle password nei nodi gestiti.
](fleet-manager-reset-password.md)
+ [
# Annullamento della registrazione dei nodi gestiti in un ambiente ibrido e multicloud
](fleet-manager-deregister-hybrid-nodes.md)
+ [
# Utilizzo dei file system del sistema operativo utilizzando Fleet Manager
](fleet-manager-file-system-management.md)
+ [
# Monitoraggio delle prestazioni dei nodi gestiti
](fleet-manager-monitoring-node-performance.md)
+ [
# Lavorare con i processi
](fleet-manager-manage-processes.md)
+ [
# Visualizzazione dei log sui nodi gestiti
](fleet-manager-view-node-logs.md)
+ [
# Gestione di account e gruppi di utenti del sistema operativo sui nodi gestiti utilizzando Fleet Manager
](fleet-manager-manage-os-user-accounts.md)
+ [
# Gestione del registro di Windows sui nodi gestiti
](fleet-manager-manage-windows-registry.md)
# Configurazione dei livelli di istanza
Questo argomento descrive gli scenari in cui è necessario attivare il livello di istanze avanzate.
AWS Systems Manager [offre un livello di istanze standard e un livello di istanze avanzate per macchine non EC2 in un ambiente ibrido e multicloud.](operating-systems-and-machine-types.md#supported-machine-types)
[Puoi registrare fino a 1.000 nodi standard attivati da sistemi ibridi per account senza costi aggiuntivi.](activations.md) Regione AWS Tuttavia, per registrare più di 1.000 nodi ibridi è necessario attivare il piano istanze avanzate. Viene addebitato un costo per l'utilizzo del piano istanze avanzate. Per ulteriori informazioni, consultare [AWS Systems Manager Prezzi](https://aws.amazon.com/systems-manager/pricing/).
Anche con meno di 1.000 nodi attivati da sistemi ibridi registrati, altri due scenari richiedono il livello di istanze avanzate:
+ Desideri utilizzare Session Manager per connetterti a nodi non EC2.
+ Desideri applicare patch alle applicazioni, non ai sistemi operativi, rilasciate da Microsoft su nodi non EC2.
**Nota**
Non è previsto alcun costo per le applicazioni di patch rilasciate da Microsoft sulle istanze Amazon EC2.
## Scenari dettagliati a livello di istanze avanzate
Le seguenti informazioni forniscono dettagli sui tre scenari per i quali è necessario attivare il livello di istanze avanzate.
Scenario 1: desideri registrare più di 1.000 nodi attivati da sistemi ibridi
Utilizzando il livello standard-instances, puoi registrare un massimo di 1.000 nodi non EC2 in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) per account specifico senza costi aggiuntivi. Regione AWS Se devi registrare più di 1.000 nodi non EC2 in una regione, devi utilizzare il piano istanze avanzate. È quindi possibile attivare il numero desiderato di macchine per il proprio ambiente ibrido e multicloud. Le istanze avanzate vengono addebitate in base al numero di nodi avanzati attivato come nodi gestiti da Systems Manager e alle ore di esecuzione di tali nodi.
Tutti i nodi gestiti da Systems Manager che utilizzano il processo di attivazione descritto in [Creazione di un'attivazione ibrida per registrare i nodi con Systems Manager](hybrid-activation-managed-nodes.md) sono quindi soggetti a pagamento se si superano i 1.000 nodi on-premises in una Regione in un account specifico.
Puoi anche attivare istanze Amazon Elastic Compute Cloud (Amazon EC2) esistenti utilizzando le attivazioni ibride di Systems Manager e utilizzarle come istanze non EC2, ad esempio per i test. Questi nodi si qualificano anche come nodi ibridi. Non è uno scenario comune.
Scenario 2: applicazione di patch alle applicazioni rilasciate da Microsoft su nodi attivati ibridi
Il piano istanze avanzate è necessario anche se si desidera applicare patch alle applicazioni rilasciate da Microsoft su nodi non EC2 in un ambiente ibrido e multicloud. Se attivi il livello delle istanze avanzate per applicare patch alle applicazioni Microsoft su nodi non EC2, vengono addebitati costi per tutti i nodi on-premises, anche se ne hai meno di 1.000.
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 [Applicazione di patch rilasciata da Microsoft in Windows Server](patch-manager-patching-windows-applications.md).
Scenario 3: connessione a nodi attivati da sistemi ibridi tramite Session Manager
Session Manager fornisce un accesso interattivo shell alle istanze. Per collegarsi a nodi gestiti attivati da sistemi ibridi utilizzando Session Manager, è necessario innanzitutto attivare il piano istanze avanzate. Vengono quindi addebitati costi per tutti i nodi attivati da sistemi ibridi, anche se ne hai meno di 1.000.
**Riepilogo: quando è necessario il piano istanze avanzate?**
Utilizza la tabella seguente per verificare quando è necessario utilizzare il piano istanze avanzate e per quali scenari si applicano costi aggiuntivi.
****
| Scenario | È richiesto il piano istanze avanzate? | Vengono applicati costi aggiuntivi? |
| --- | --- | --- |
| Il numero di nodi attivati da sistemi ibridi nella mia regione in un account specifico è superiore a 1.000. | Sì | Sì |
| Desidero utilizzare Patch Manager per applicare patch alle applicazioni rilasciate da Microsoft su un numero qualsiasi di nodi attivati da ibridi, anche meno di 1.000. | Sì | Sì |
| Desidero utilizzare Session Manager per connettermi a un numero qualsiasi di nodi attivati da ibridi, anche a meno di 1.000. | Sì | Sì |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/fleet-manager-configure-instance-tiers.html) | No | No |
**Topics**
+ [
## Scenari dettagliati a livello di istanze avanzate
](#systems-manager-managed-instances-tier-scenarios)
+ [
# Attivazione del piano istanze avanzate
](fleet-manager-enable-advanced-instances-tier.md)
+ [
# Ripristino dal livello istanze avanzate al livello istanze standard
](fleet-manager-revert-to-standard-tier.md)
# Attivazione del piano istanze avanzate
AWS Systems Manager [offre un livello di istanze standard e un livello di istanze avanzate per macchine non EC2 in un ambiente ibrido e multicloud.](operating-systems-and-machine-types.md#supported-machine-types) Il livello delle istanze standard consente di registrare un massimo di 1.000 macchine attivate in modalità ibrida per unità. Account AWS Regione AWSÈ inoltre necessario utilizzare il livello delle istanze avanzate Patch Manager per applicare patch alle applicazioni rilasciate da Microsoft su nodi non EC2 e connettersi a nodi non EC2 utilizzando Session Manager. Per ulteriori informazioni, consulta [Attivazione del piano istanze avanzate](#fleet-manager-enable-advanced-instances-tier).
Questa sezione descrive come configurare l'ambiente ibrido e multicloud per utilizzare il piano istanze avanzate.
**Prima di iniziare**
Consulta i dettagli prezzi per le istanze avanzate. Le istanze avanzate sono disponibili su un. per-use-basis Per ulteriori informazioni, consulta, [Prezzi di AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Configurazione delle autorizzazioni per attivare il piano istanze avanzate
Verifica di disporre dell'autorizzazione in AWS Identity and Access Management (IAM) per modificare l'ambiente dal livello delle istanze standard al livello delle istanze avanzate. È necessario che la policy IAM `AdministratorAccess` sia collegata all'utente, al gruppo o al ruolo oppure disporre dell'autorizzazione a modificare l'impostazione del servizio al piano di attivazione di Systems Manager. L'impostazione del piano attivazione utilizza le seguenti operazioni API:
+ [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html)
+ [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html)
+ [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html)
Utilizza la procedura seguente per aggiungere una policy IAM in linea a un account utente. Questa policy consente a un utente di visualizzare l'impostazione del piano istanze gestite corrente. Questa policy consente inoltre all'utente di modificare o reimpostare l'impostazione corrente nella e specificata. Account AWS Regione AWS
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel pannello di navigazione, seleziona **Utenti**.
1. Nell'elenco, scegli il nome dell'utente in cui incorporare una policy.
1. Scegli la scheda **Autorizzazioni**.
1. Nella parte destra della pagina, in **Policy di autorizzazione**, scegli **Aggiungi policy in linea**.
1. Scegli la scheda **JSON**.
1. Sostituire il contenuto di default con il seguente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/activation-tier"
}
]
}
```
------
1. Scegliere **Review policy (Rivedi policy)**.
1. Nella pagina **Rivedi policy**, per **Nome** inserisci un nome per la policy in linea. Ad esempio: **Managed-Instances-Tier**.
1. Scegli **Crea policy**.
Gli amministratori possono specificare autorizzazioni di sola lettura assegnando la policy in linea seguente all'utente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "*"
}
]
}
```
------
Per ulteriori informazioni sulla creazione e modifica di policy IAM, consulta [Creazione di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l'utente IAM*.
## Attivazione del piano istanze avanzate (console)
La procedura seguente mostra come utilizzare la console Systems Manager per modificare *tutti i* nodi non EC2 che sono stati aggiunti utilizzando l'attivazione a istanze gestite, nel livello specificato Account AWS e Regione AWS, per utilizzare il livello di istanze avanzate.
**Prima di iniziare**
Verifica che la console sia aperta nel punto in cui hai creato le istanze gestite. Regione AWS È possibile passare da una Regione all'altra utilizzando l'elenco nell'angolo in alto a destra della console.
Verifica di aver completato i requisiti di configurazione per le istanze Amazon Elastic Compute Cloud (Amazon EC2) e le macchine non EC2 in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). Per informazioni, consulta [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Importante**
La procedura seguente descrive come modificare un'impostazione a livello di account. Questa modifica comporta costi che vengono addebitati al tuo account.
**Per attivare il piano istanze avanzate (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 **Fleet Manager**.
1. Scegli **Impostazioni**, quindi **Modifica delle impostazioni del livello di istanza**.
1. Esamina le informazioni nella finestra di dialogo sulla modifica delle impostazioni dell'account.
1. Se approvi, scegli l'opzione di accettazione, quindi scegli **Cambia impostazione**.
Il sistema può richiedere alcuni minuti per completare il processo di trasferimento di tutte le istanze dal piano istanze standard al piano istanze avanzate.
**Nota**
Per informazioni sulla modifica per tornare al livello istanze standard, consulta [Ripristino dal livello istanze avanzate al livello istanze standard](fleet-manager-revert-to-standard-tier.md).
## Attivazione del piano istanze avanzate (AWS CLI)
La procedura seguente mostra come utilizzare AWS Command Line Interface per modificare *tutti i* server locali aggiunti utilizzando l'attivazione di istanze gestite, nel livello specificato Account AWS e Regione AWS per utilizzare il livello avanzato. VMs
**Importante**
La procedura seguente descrive come modificare un'impostazione a livello di account. Questa modifica comporta costi che vengono addebitati al tuo account.
**Per attivare il livello delle istanze avanzate utilizzando il AWS CLI**
1. Apri AWS CLI ed esegui il comando seguente. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier \
--setting-value advanced
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier ^
--setting-value advanced
```
------
Se il comando va a buon fine, non viene generato output.
1. Esegui il comando seguente per visualizzare le impostazioni correnti del servizio per i nodi gestiti nella versione corrente Account AWS e Regione AWS.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
Il comando restituisce informazioni simili alle seguenti.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "advanced",
"LastModifiedDate": 1555603376.138,
"LastModifiedUser": "arn:aws:sts::123456789012:assumed-role/Administrator/User_1",
"ARN": "arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier",
"Status": "PendingUpdate"
}
}
```
## Attivazione del piano istanze avanzate (PowerShell)
La procedura seguente mostra come utilizzare AWS Tools for Windows PowerShell per modificare *tutti i* server locali e VMs che sono stati aggiunti utilizzando l'attivazione a istanza gestita, nel livello specificato Account AWS e Regione AWS per utilizzare il livello avanzato.
**Importante**
La procedura seguente descrive come modificare un'impostazione a livello di account. Questa modifica comporta costi che vengono addebitati al tuo account.
**Per attivare il livello delle istanze avanzate utilizzando PowerShell**
1. Apri AWS Tools for Windows PowerShell ed esegui il comando seguente. Sostituisci ogni *example resource placeholder* con le tue informazioni.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "advanced"
```
Se il comando va a buon fine, non viene generato output.
1. Esegui il comando seguente per visualizzare le impostazioni correnti del servizio per i nodi gestiti nella versione corrente Account AWS e Regione AWS.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
Il comando restituisce informazioni simili alle seguenti.
```
ARN:arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier
LastModifiedDate : 4/18/2019 4:02:56 PM
LastModifiedUser : arn:aws:sts::123456789012:assumed-role/Administrator/User_1
SettingId : /ssm/managed-instance/activation-tier
SettingValue : advanced
Status : PendingUpdate
```
Il sistema può richiedere alcuni minuti per completare il processo di trasferimento di tutti i nodi dal piano istanze standard al piano istanze avanzate.
**Nota**
Per informazioni sulla modifica per tornare al livello istanze standard, consulta [Ripristino dal livello istanze avanzate al livello istanze standard](fleet-manager-revert-to-standard-tier.md).
# Ripristino dal livello istanze avanzate al livello istanze standard
In questa sezione viene descritto come modificare i nodi attivati da sistemi ibridi in esecuzione nel livello istanze avanzate sul livello istanze standard. Questa configurazione si applica a tutti i nodi attivati in modalità ibrida in un unico Account AWS nodo. Regione AWS
**Prima di iniziare**
Esamina i seguenti dettagli importanti.
**Nota**
Non puoi ripristinare il livello di istanza standard se esegui più di 1.000 nodi attivati da sistemi ibridi nell'account e nella regione. È necessario annullare la registrazione dei nodi fino a quando non hai al massimo 1.000 nodi. Questo si applica inoltre a istanze Amazon Elastic Compute Cloud (Amazon EC2) che utilizzano un'attivazione ibrida di Systems Manager (che non è uno scenario comune). Per ulteriori informazioni, consulta [Annullamento della registrazione dei nodi gestiti in un ambiente ibrido e multicloud](fleet-manager-deregister-hybrid-nodes.md).
Dopo il ripristino, non sarà possibile utilizzare Session Manager, uno strumento di AWS Systems Manager, per accedere in modo interattivo ai nodi attivati da sistemi ibridi.
Dopo il ripristino, non sarà possibile utilizzare Patch Manager, uno strumento di AWS Systems Manager, per applicare le patch alle applicazioni rilasciate da Microsoft su nodi attivati da sistemi ibridi.
Il processo di ripristino di tutti i nodi attivati da sistemi ibridi al livello di istanza standard può richiedere più di 30 minuti.
Questa sezione descrive come ripristinare tutti i nodi attivati dagli ibridi in un livello di istanze avanzate Account AWS e Regione AWS dal livello delle istanze avanzate al livello delle istanze standard.
## Ripristino del livello istanze standard (console)
La procedura seguente mostra come utilizzare la console Systems Manager per modificare tutti i nodi attivati in modalità ibrida nell'ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) per utilizzare il livello di istanze standard nel livello specificato e. Account AWS Regione AWS
**Per ripristinare il livello di istanze standard (console)**
1. AWS Systems Manager Aprire la console all'indirizzo. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Nel pannello di navigazione, scegli **Fleet Manager**.
1. Selezionare il menu a discesa **Impostazioni dell'account** e scegliere **Impostazioni del piano istanza**.
1. Scegliere **Change account setting (Modifica impostazione dell'account)**.
1. Esaminare le informazioni nel popup relative alla modifica delle impostazioni dell'account e quindi, se approvate, scegliere l'opzione per accettare e continuare.
## Ripristino del livello di istanze standard (AWS CLI)
La procedura seguente mostra come utilizzare il AWS Command Line Interface per modificare tutti i nodi attivati da ibridi nell'ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) per utilizzare il livello delle istanze standard nel livello specificato e. Account AWS Regione AWS
**Per tornare al livello delle istanze standard utilizzando il AWS CLI**
1. Aprire AWS CLI ed eseguire il comando seguente. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier \
--setting-value standard
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier ^
--setting-value standard
```
------
Se il comando va a buon fine, non viene generato output.
1. Esegui il comando seguente 30 minuti dopo per visualizzare le impostazioni per le istanze gestite nella versione corrente Account AWS e Regione AWS.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
Il comando restituisce informazioni simili alle seguenti.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "standard",
"LastModifiedDate": 1555603376.138,
"LastModifiedUser": "System",
"ARN": "arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier",
"Status": "Default"
}
}
```
Lo stato diventa *Default (Predefinito)* dopo l'approvazione della richiesta.
## Ripristino del livello di istanze standard (PowerShell)
La procedura seguente mostra come utilizzare per modificare i nodi attivati AWS Tools for Windows PowerShell da ibridi nell'ambiente ibrido e multicloud per utilizzare il livello standard-instances nell'ambiente specificato e. Account AWS Regione AWS
**Per tornare al livello delle istanze standard utilizzando PowerShell**
1. Apri AWS Tools for Windows PowerShell ed esegui il comando seguente.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "standard"
```
Se il comando va a buon fine, non viene generato output.
1. Esegui il comando seguente 30 minuti dopo per visualizzare le impostazioni per le istanze gestite nella versione corrente Account AWS e Regione AWS.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
Il comando restituisce informazioni simili alle seguenti.
```
ARN: arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier
LastModifiedDate : 4/18/2019 4:02:56 PM
LastModifiedUser : System
SettingId : /ssm/managed-instance/activation-tier
SettingValue : standard
Status : Default
```
Lo stato diventa *Default (Predefinito)* dopo l'approvazione della richiesta.
# Reimpostazione delle password nei nodi gestiti.
Puoi ripristinare la password per qualsiasi utente su un nodo gestito. Ciò include istanze AWS IoT Greengrass Amazon Elastic Compute Cloud (Amazon EC2), dispositivi core e server locali, dispositivi edge e macchine virtuali () gestiti da. VMs AWS Systems Manager La funzionalità di ripristino della password è basata su Session Manager, uno strumento di AWS Systems Manager. Puoi usare questa funzionalità per connetterti a nodi gestiti senza aprire porte in entrata, mantenendo host bastione o gestendo chiavi SSH.
Il ripristino della password è utile quando un utente ha dimenticato una password o quando desidera aggiornare rapidamente una password senza effettuare una connessione RDP o SSH al nodo gestito.
**Prerequisiti**
Prima di ripristinare la password in un nodo gestito, è necessario soddisfare i seguenti requisiti:
+ Il nodo gestito su cui desideri modificare una password deve essere un nodo gestito di Systems Manager. Inoltre, la versione SSM Agent 2.3.668.0 o successiva deve essere installata sul nodo gestito.) Per informazioni sull'installazione o l'aggiornamento di SSM Agent, consulta [Utilizzo di SSM Agent](ssm-agent.md).
+ La funzione di ripristino della password utilizza la configurazione Session Manager impostata per l'account per connettersi al nodo gestito. Pertanto, i prerequisiti per l'utilizzo di Session Manager devono essere stati completati per il tuo account nella Regione AWS corrente. Per ulteriori informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
**Nota**
Il supporto Session Manager per nodi on-premises è fornito solo per il piano istanze avanzate. Per ulteriori informazioni, consulta [Attivazione del piano istanze avanzate](fleet-manager-enable-advanced-instances-tier.md).
+ L' AWS utente che sta modificando la password deve disporre dell'`ssm:SendCommand`autorizzazione per il nodo gestito. Per ulteriori informazioni, consulta [Limitazione dell'accesso Run Command in base ai tag](run-command-setting-up.md#tag-based-access).
**Limitazione dell'accesso**
Puoi limitare la capacità di un utente di ripristinare le password a istanze specifiche. Questo avviene mediante policy basate sull'identità per l'operazione Session Manager `ssm:StartSession` con il documento SSM `AWS-PasswordReset`. Per ulteriori informazioni, consulta [Controllo dell'accesso della sessione utente alle istanze](session-manager-getting-started-restrict-access.md).
**Crittografia dei dati**
Attiva AWS Key Management Service (AWS KMS) la crittografia completa Session Manager dei dati per utilizzare l'opzione di reimpostazione della password per i nodi gestiti. Per ulteriori informazioni, consulta [Attiva la crittografia delle chiavi KMS per i dati delle sessioni (console)](session-preferences-enable-encryption.md).
## Reimpostazione di una password su un nodo gestito
È possibile reimpostare una password su un nodo gestito da Systems Manager utilizzando la **Fleet Manager**console Systems Manager o il AWS Command Line Interface (AWS CLI).
**Per modificare la password su un nodo gestito (console)**
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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo che richiede una nuova password.
1. Scegli **Operazioni istanza, Reimposta password**.
1. Per **User name (Nome utente)**, inserisci il nome dell'utente per il quale stai modificando la password. Può essere qualsiasi nome utente che dispone di un account sul nodo.
1. Seleziona **Invia**.
1. Segui i prompt nella finestra di comando **Enter new password (Inserisci nuova password)** per specificare la nuova password.
**Nota**
Se la versione di SSM Agent sul nodo gestito non supporta la reimpostazione delle password, verrà richiesto di installare una versione supportata utilizzando Run Command, uno strumento di AWS Systems Manager.
**Per ripristinare la password su un nodo gestito (AWS CLI)**
1. Per ripristinare la password per un utente su un nodo gestito, esegui il comando seguente. Sostituisci ogni *example resource placeholder* con le tue informazioni.
**Nota**
Per utilizzare AWS CLI per reimpostare una password, il Session Manager plug-in deve essere installato sul computer locale. Per informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name "AWS-PasswordReset" \
--parameters '{"username": ["user-name"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name "AWS-PasswordReset" ^
--parameters username="user-name"
```
------
1. Segui i prompt nella finestra di comando **Enter new password (Inserisci nuova password)** per specificare la nuova password.
## Risoluzione dei problemi di reimpostazione della password su nodi gestiti.
Molti problemi di reimpostazione password possono essere risolti assicurando di aver completato i [prerequisiti di reimpostazione della password](#pw-reset-prereqs). Per altri problemi, utilizza le informazioni seguenti per risolvere i problemi di reimpostazione della password.
**Topics**
+ [
### Nodo gestito non disponibile
](#password-reset-troubleshooting-instances)
+ [
### SSM Agentnon up-to-date (console)
](#password-reset-troubleshooting-ssmagent-console)
+ [
### Le opzioni di reimpostazione della password non sono fornite (AWS CLI)
](#password-reset-troubleshooting-ssmagent-cli)
+ [
### Nessuna autorizzazione per eseguire `ssm:SendCommand`
](#password-reset-troubleshooting-sendcommand)
+ [
### Messaggio di errore Session Manager
](#password-reset-troubleshooting-session-manager)
### Nodo gestito non disponibile
**Problema**: desideri reimpostare la password per un nodo gestito nella pagina della console **Managed instances (Istanze gestite)**, ma il nodo non è nell'elenco.
+ **Soluzione**: il nodo gestito a cui connettersi potrebbe non essere configurato per Systems Manager. Per utilizzare un'istanza EC2 con Systems Manager, è necessario allegare all'istanza un profilo di istanza AWS Identity and Access Management (IAM) che dia a Systems Manager l'autorizzazione a eseguire azioni sulle istanze. Per informazioni, consulta la pagina [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md).
Per usare una macchina non EC2 con Systems Manager, crea un ruolo di servizio IAM che fornisca a Systems Manager l'autorizzazione per eseguire operazioni sui nodi gestiti. Per ulteriori informazioni, consulta [Creare il ruolo di servizio IAM richiesto per Systems Manager in ambienti ibridi e multicloud](hybrid-multicloud-service-role.md). (Session Managersupporto per server locali ed VMs è fornito solo per il livello di istanze avanzate. Per ulteriori informazioni, vedere.) [Attivazione del piano istanze avanzate](fleet-manager-enable-advanced-instances-tier.md)
### SSM Agentnon up-to-date (console)
**Problema**: un messaggio segnala che la versione di SSM Agent non supporta la funzionalità di reimpostazione della password.
+ **Soluzione**: è richiesta la versione 2.3.668.0 o successiva di SSM Agent per eseguire reimpostazioni delle password. Nella console, puoi aggiornare l'agente sul nodo gestito scegliendo **Update SSM Agent** (Aggiorna agente SSM).
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.
### Le opzioni di reimpostazione della password non sono fornite (AWS CLI)
**Problema**: ti connetti correttamente a un nodo gestito utilizzando il AWS CLI `[https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)` comando. Hai specificato il documento SSM `AWS-PasswordReset` e fornito un nome utente valido, ma le richieste di modifica della password non vengono visualizzate.
+ **Soluzione**: la versione di SSM Agent sul nodo gestito non lo è up-to-date. Per eseguire la reimpostazione delle password è richiesta la versione 2.3.668.0 o successiva.
Una versione aggiornata di SSM Agent viene distribuita ogni volta che vengono aggiunti nuovi strumenti a Systems Manager o eseguiti aggiornamenti agli 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.
### Nessuna autorizzazione per eseguire `ssm:SendCommand`
**Problema**: tenti di connetterti a un nodo gestito per modificarne la password, ma ricevi un messaggio di errore che indica che non sei autorizzato a eseguire `ssm:SendCommand` sul nodo gestito.
+ **Soluzione**: la policy IAM deve includere l'autorizzazione per eseguire il comando `ssm:SendCommand`. Per informazioni, consulta [Limitazione dell'accesso Run Command in base ai tag](run-command-setting-up.md#tag-based-access).
### Messaggio di errore Session Manager
**Problema**: ricevi un messaggio di errore correlato a Session Manager.
+ **Soluzione**: il supporto della reimpostazione della password richiede che Session Manager sia configurato correttamente. Per informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md) e [Risoluzione dei problemi relativi a Session Manager](session-manager-troubleshooting.md).
# Annullamento della registrazione dei nodi gestiti in un ambiente ibrido e multicloud
Se non desideri più gestire un server locale, un dispositivo periferico o una macchina virtuale (VM) utilizzando AWS Systems Manager, puoi annullarne la registrazione. L'annullamento della registrazione di un nodo attivato in modalità ibrida lo rimuove dall'elenco dei nodi gestiti in Systems Manager. AWS Systems Manager L'agente (SSM Agent) in esecuzione sul nodo attivato da sistemi ibridi non sarà in grado di aggiornare il token di autorizzazione perché non è più registrato. SSM Agent verrà ibernato e riduce la sua frequenza di ping a Systems Manager nel cloud a una volta all'ora. Systems Manager gestisce la cronologia dei comandi per un nodo gestito di cui è stata annullata la registrazione per 30 giorni.
**Nota**
Puoi registrare nuovamente un server on-premises, un dispositivo periferico o una macchina virtuale locale utilizzando lo stesso codice di attivazione e lo stesso ID, purché non sia stato raggiunto il limite di istanze per il codice di attivazione e l'ID designati. Puoi verificare il limite di istanze nella console scegliendo **Strumenti per i nodi**, quindi scegli **Attivazioni ibride**. Se il valore delle **istanze registrate** è inferiore al **limite di registrazione**, puoi registrare nuovamente una macchina utilizzando lo stesso codice di attivazione e lo stesso ID. Se è maggiore, è necessario utilizzare un codice di attivazione e un ID diversi.
Nella procedura seguente viene descritto come annullare la registrazione di un nodo attivato da sistemi ibridi utilizzando la console di Systems Manager. Per informazioni su come eseguire questa operazione utilizzando il AWS Command Line Interface, vedere [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html).
Per le relative informazioni, consultare i seguenti argomenti:
+ [Annullamento della registrazione e nuova registrazione di un nodo gestito (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister) (Linux)
+ [Annullamento della registrazione e nuova registrazione di un nodo gestito (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister) (Windows Server)
**Per annullare la registrazione di un nodo (console) attivato in modalità ibrida**
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 **Fleet Manager**.
1. Selezionare la casella di controllo accanto al nodo gestito di cui si desidera annullare la registrazione.
1. Scegliere **Operazioni del nodo, Strumenti, Annulla la registrazione di questo nodo gestito**.
1. Esaminare le informazioni nella finestra di dialogo **Annulla la registrazione di questo nodo gestito**. in caso di approvazione, scegliere **Annulla registrazione**.
# Utilizzo dei file system del sistema operativo utilizzando Fleet Manager
È possibile utilizzareFleet Manager, uno strumento in AWS Systems Manager, per lavorare con il file system sui nodi gestiti. Utilizzando Fleet Manager è possibile visualizzare le informazioni sulla directory e i dati dei file memorizzati nei volumi collegati ai nodi gestiti. Ad esempio, è possibile visualizzare il nome, le dimensioni, l'estensione, il proprietario e le autorizzazioni per le directory e i file. È possibile visualizzare in anteprima fino a 10.000 righe di dati di file come testo dalla console Fleet Manager. Puoi utilizzare questa funzionalità anche per i file `tail`. Quando utilizzi `tail` per visualizzare i dati di file, le ultime 10 righe del file vengono visualizzate all'inizio. Man mano che nuove righe di dati vengono scritte nel file, la visualizzazione viene aggiornata in tempo reale. Di conseguenza, è possibile esaminare i dati di registro dalla console, in modo da migliorare l'efficienza della risoluzione dei problemi e dell'amministrazione dei sistemi. Inoltre è possibile creare directory e copiare, tagliare, incollare, rinominare o eliminare file e directory.
Consigliamo di creare backup regolari o di fare snapshot dei volumi Amazon Elastic Block Store (Amazon EBS) collegati ai nodi gestiti. Quando vengono copiati, tagliati o incollati i file, vengono sostituiti i file e le directory esistenti nel percorso di destinazione con lo stesso nome dei nuovi file o directory. Se si sostituiscono o si modificano file e directory di sistema, possono verificarsi seri problemi. AWS non garantisce che questi problemi possano essere risolti. Modificare i file di sistema a proprio rischio. L'utente è responsabile di tutte le modifiche ai file e alle directory e garantisce di disporre di backup. L'eliminazione o la sostituzione di file e directory non può essere annullata.
**Nota**
Fleet Managerutilizza Session Manager uno strumento per visualizzare anteprime e `tail` file di testo. AWS Systems Manager Per le istanze di Amazon Elastic Compute Cloud (Amazon EC2), il profilo dell'istanza associato alle istanze gestite deve fornire le autorizzazioni per Session Manager in modo da poter utilizzare questa funzionalità. Per ulteriori informazioni sull'aggiunta delle autorizzazioni Session Manager a un profilo dell'istanza, consulta [Aggiunta di autorizzazioni Session Manager per un ruolo IAM esistente](getting-started-add-permissions-to-existing-profile.md).
**Topics**
+ [
# Visualizzazione del file system del sistema operativo tramite Fleet Manager
](fleet-manager-viewing-file-system.md)
+ [
# Visualizzazione in anteprima dei file del sistema operativo utilizzando Fleet Manager
](fleet-manager-preview-os-files.md)
+ [
# Tailing dei file del sistema operativo utilizzando Fleet Manager
](fleet-manager-tailing-os-files.md)
+ [
# Copiare, tagliare e incollare file o directory del sistema operativo utilizzando Fleet Manager
](fleet-manager-move-files-or-directories.md)
+ [
# Ridenominazione di file e directory del sistema operativo utilizzando Fleet Manager
](fleet-manager-renaming-files-and-directories.md)
+ [
# Eliminazione di file e directory del sistema operativo utilizzando Fleet Manager
](fleet-manager-deleting-files-and-directories.md)
+ [
# Creazione di directory del sistema operativo utilizzando Fleet Manager
](fleet-manager-creating-directories.md)
+ [
# Tagliare, copiare e incollare le directory del sistema operativo utilizzando Fleet Manager
](fleet-manager-managing-directories.md)
# Visualizzazione del file system del sistema operativo tramite Fleet Manager
Utilizza Fleet Manager per visualizzare il file system del sistema operativo su un nodo gestito da Systems Manager.
**Per visualizzare il file system del sistema operativo utilizzando Fleet 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 **Fleet Manager**.
1. Seleziona il collegamento del nodo gestito con il file system che desideri visualizzare.
1. Scegli **Strumenti, File system**.
# Visualizzazione in anteprima dei file del sistema operativo utilizzando Fleet Manager
Utilizza Fleet Manager per visualizzare in anteprima i file di testo su un sistema operativo.
**Per visualizzare le anteprime di testo dei file utilizzando Fleet 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 **Fleet Manager**.
1. Seleziona il collegamento del nodo gestito con i file che desideri visualizzare in anteprima.
1. Scegli **Strumenti, File system**.
1. Seleziona il **Nome del file** della directory contenente il file da visualizzare in anteprima.
1. Scegli il pulsante accanto al file di cui si desidera visualizzare in anteprima il contenuto.
1. Scegli **Operazioni, Anteprima come testo**.
# Tailing dei file del sistema operativo utilizzando Fleet Manager
Utilizza Fleet Manager per eseguire il tailing di un file su un nodo gestito.
**Per eseguire il tailing dei file con Fleet 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 **Fleet Manager**.
1. Seleziona il collegamento del nodo gestito con i file che desideri controllare.
1. Scegli **Strumenti, File system**.
1. Seleziona il **File name** (Nome del file) della directory contenente il file da controllare.
1. Scegli il pulsante accanto al file di cui si desidera eseguire la coda del contenuto.
1. Scegli **Operazioni, File di coda**.
# Copiare, tagliare e incollare file o directory del sistema operativo utilizzando Fleet Manager
Utilizza Fleet Manager per copiare, tagliare e incollare file del sistema operativo su un nodo gestito.
**Per copiare o tagliare e incollare file o directory utilizzando Fleet 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 **Fleet Manager**.
1. Selezionare il collegamento del nodo gestito con i file che si desidera copiare o tagliare e incollare.
1. Scegli **Strumenti, File system**.
1. Per copiare o tagliare un file, selezionare il **Nome file** della directory che contiene il file che si desidera copiare o tagliare. Per copiare o tagliare una directory, scegliere il pulsante accanto alla directory che si desidera copiare o tagliare e quindi procedere al passaggio 8.
1. Scegli il pulsante accanto al file che si desidera copiare o tagliare.
1. Nel menu **Actions (Operazioni)** scegli **Copy (Copia)** o **Cut (Taglia)**.
1. Nella schermata **File system**, scegli il pulsante accanto alla directory in cui incollare il file.
1. Nel menu **Actions (Operazioni)**, scegli **Paste (Incolla)**.
# Ridenominazione di file e directory del sistema operativo utilizzando Fleet Manager
Utilizza Fleet Manager per rinominare file e directory su nodo gestito nell’account.
**Rinominare file o directory con Fleet 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 **Fleet Manager**.
1. Selezionare il collegamento del nodo gestito con i file o le directory che si desidera rinominare.
1. Scegli **Strumenti, File system**.
1. Per rinominare un file, selezionare il **Nome file** della directory che contiene il file che si desidera rinominare. Per rinominare una directory, scegliere il pulsante accanto alla directory che si desidera rinominare e quindi procedere al passaggio 8.
1. Scegli il pulsante accanto al file che desideri rinominare.
1. Scegli **Operazioni, Rinomina**.
1. Nel campo **Nome file**, inserisci il nuovo nome per il file e seleziona **Rinomina**.
# Eliminazione di file e directory del sistema operativo utilizzando Fleet Manager
Utilizza Fleet Manager per eliminare file e directory su un nodo gestito nell’account.
**Per eliminare file o directory utilizzando Fleet 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 **Fleet Manager**.
1. Seleziona il collegamento del nodo gestito con i file o le directory che desideri eliminare.
1. Scegli **Strumenti, File system**.
1. Per eliminare un file, seleziona il **Nome file** della directory che contiene il file che desideri eliminare. Per eliminare una directory, scegli il pulsante accanto alla directory da eliminare e procedere al passaggio 7.
1. Scegli il pulsante accanto al file che desideri eliminare.
1. Scegli **Operazioni, Elimina**.
# Creazione di directory del sistema operativo utilizzando Fleet Manager
Utilizza Fleet Manager per creare directory su nodo gestito nell’account.
**Per creare una directory utilizzando Fleet 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 **Fleet Manager**.
1. Seleziona il collegamento del nodo gestito in cui desideri creare una directory.
1. Scegli **Strumenti, File system**.
1. Seleziona il **File Name (Nome file)** della directory in cui desideri creare una nuova directory.
1. Seleziona **CREATE DIRECTORY**.
1. Nel campo **Nome directory**, inserisci il nome per la nuova directory e seleziona **Crea directory**.
# Tagliare, copiare e incollare le directory del sistema operativo utilizzando Fleet Manager
Utilizza Fleet Manager per tagliare, copiare e incollare le directory su un nodo gestito nell’account.
**Per copiare o tagliare e incollare directory con Fleet 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 **Fleet Manager**.
1. Selezionare il collegamento del nodo gestito con i file che si desidera copiare o tagliare e incollare.
1. Scegli **Strumenti, File system**.
1. Scegliere il pulsante accanto alla directory che si desidera copiare o tagliare e quindi procedere al passaggio 8.
1. Nel menu **Actions (Operazioni)** scegli **Copy (Copia)** o **Cut (Taglia)**.
1. Nella schermata **File system**, scegli il pulsante accanto alla directory in cui incollare il file.
1. Nel menu **Actions (Operazioni)**, scegli **Paste (Incolla)**.
# Monitoraggio delle prestazioni dei nodi gestiti
È possibile utilizzare Fleet Manager uno strumento per visualizzare i dati sulle prestazioni dei nodi gestiti in tempo reale. AWS Systems Manager I dati sulle prestazioni vengono recuperati dalle unità di conteggio delle prestazioni.
Le seguenti unità di conteggio delle prestazioni sono disponibili in Fleet Manager:
+ Utilizzo CPU
+ Utilizzo del disco input/output (I/O)
+ Traffico di rete
+ Utilizzo della memoria
**Nota**
Fleet ManagerutilizzaSession Manager, uno strumento in AWS Systems Manager, per recuperare i dati sulle prestazioni. Per le istanze di Amazon Elastic Compute Cloud (Amazon EC2), il profilo dell'istanza associato alle istanze gestite deve fornire le autorizzazioni per Session Manager in modo da poter utilizzare questa funzionalità. Per ulteriori informazioni sull'aggiunta delle autorizzazioni Session Manager a un profilo dell'istanza, consulta [Aggiunta di autorizzazioni Session Manager per un ruolo IAM esistente](getting-started-add-permissions-to-existing-profile.md).
**Per visualizzare i dati relativi alle prestazioni con Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito di cui desideri monitorare le prestazioni.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Contatori delle prestazioni**.
# Lavorare con i processi
Utilizza Fleet Manager, uno strumento di AWS Systems Manager, per lavorare con processi sui nodi gestiti. Utilizzando Fleet Manager, puoi visualizzare le informazioni relative ai processi. Ad esempio, è possibile visualizzare l'utilizzo della CPU e l'utilizzo della memoria dei processi oltre ai relativi handle e thread. Con Fleet Manager, è possibile avviare e terminare i processi dalla console.
**Nota**
Fleet Manager utilizza Session Manager, uno strumento di AWS Systems Manager, per recuperare i dati di processo. Per le istanze di Amazon Elastic Compute Cloud (Amazon EC2), il profilo di istanza associato alle istanze gestite deve fornire le autorizzazioni per Session Manager in modo da poter utilizzare questa funzionalità. Per ulteriori informazioni sull'aggiunta delle autorizzazioni Session Manager a un profilo dell'istanza, consulta [Aggiunta di autorizzazioni Session Manager per un ruolo IAM esistente](getting-started-add-permissions-to-existing-profile.md).
**Topics**
+ [
# Visualizzazione dei dettagli sui processi del sistema operativo utilizzando Fleet Manager
](fleet-manager-view-process-details.md)
+ [
# Avvio di un processo del sistema operativo su un nodo gestito utilizzando Fleet Manager
](fleet-manager-start-process.md)
+ [
# Interruzione di un processo del sistema operativo utilizzando Fleet Manager
](fleet-manager-terminate-process.md)
# Visualizzazione dei dettagli sui processi del sistema operativo utilizzando Fleet Manager
Utilizza Fleet Manager per visualizzare i dettagli sui processi sui nodi gestiti.
**Per visualizzare i dettagli relativi ai processi con Fleet 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 **Fleet Manager**.
1. Selezionare il collegamento del nodo di cui si desidera visualizzare i processi.
1. Scegli **Strumenti, Processi**.
# Avvio di un processo del sistema operativo su un nodo gestito utilizzando Fleet Manager
Utilizza Fleet Manager per avviare un processo su un nodo gestito.
**Per avviare un processo con Fleet 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 **Fleet Manager**.
1. Seleziona il collegamento del nodo gestito su cui desideri avviare un processo.
1. Scegli **Strumenti, Processi**.
1. Seleziona **Start new process (Avvia un nuovo processo)**.
1. Nel campo **Nome del processo o percorso completo**, inserisci il nome del processo o il percorso completo dell'eseguibile.
1. (Facoltativo) Nel campo **Directory di lavoro**, immetti il percorso della directory in cui desideri eseguire il processo.
# Interruzione di un processo del sistema operativo utilizzando Fleet Manager
**Per interrompere un processo del sistema operativo utilizzando Fleet 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 **Fleet Manager**.
1. Seleziona il collegamento del nodo gestito su cui desideri avviare un processo.
1. Scegli **Strumenti, Processi**.
1. Scegliere il pulsante accanto al processo che si desidera terminare.
1. Scegli **Operazioni, Terminare il processo** oppure **Operazioni, Terminare la struttura del processo**.
**Nota**
La chiusura di un albero di processo termina anche tutti i processi e le applicazioni che utilizzano tale processo.
# Visualizzazione dei log sui nodi gestiti
Puoi utilizzare Fleet Manager, uno strumento di AWS Systems Manager, per visualizzare i dati log archiviati nei tuoi nodi gestiti. Per i nodi gestiti di Windows, è possibile visualizzare i log eventi Windows e copiare i relativi dettagli dalla console. Per facilitare la ricerca degli eventi, filtrare i registri eventi di Windows in base al **livello dell'evento**, all'**ID evento**,all'**origine evento** e all'**ora di creazione**. È inoltre possibile visualizzare altri dati di registro utilizzando la procedura descritta per visualizzare il file system. Per ulteriori informazioni sulla visualizzazione del file system con Fleet Manager consulta [Utilizzo dei file system del sistema operativo utilizzando Fleet Manager](fleet-manager-file-system-management.md).
**Per visualizzare i log eventi di Windows con Fleet Manager**
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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito di cui si desidera visualizzare i registri di eventi.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Log eventi di Windows**.
1. Seleziona il **Log name (Nome log)** che contiene gli eventi che si desidera visualizzare.
1. Selezionare il pulsante accanto al **Log name (Nome log)** che si desidera visualizzare, quindi selezionare **View events (Visualizza eventi)**.
1. Seleziona il pulsante accanto all'evento che desideri visualizzare, quindi seleziona **View event details (Visualizza dettagli evento)**.
1. (Opzionale) Seleziona **Copy as JSON (Copia come JSON)** per copiare i dettagli dell'evento negli appunti.
# Gestione di account e gruppi di utenti del sistema operativo sui nodi gestiti utilizzando Fleet Manager
È possibile utilizzareFleet Manager, uno strumento in AWS Systems Manager, per gestire gli account utente e i gruppi del sistema operativo (OS) sui nodi gestiti. Ad esempio, è possibile creare ed eliminare utenti e gruppi. Inoltre, è possibile visualizzare dettagli quali l'appartenenza al gruppo, i ruoli utente e lo stato.
**Importante**
Fleet Managerutilizza Run Command eSession Manager, in particolare AWS Systems Manager, strumenti per varie operazioni di gestione degli utenti. Di conseguenza, un utente potrebbe concedere autorizzazioni a un account utente del sistema operativo che altrimenti non sarebbe possibile. Questo perché AWS Systems Manager Agent (SSM Agent) viene eseguito su istanze Amazon Elastic Compute Cloud (Amazon EC2) utilizzando le autorizzazioni root (Linux) o le autorizzazioni SYSTEM (). Windows Server Per ulteriori informazioni su come limitare l'accesso ai comandi di livello root tramite SSM Agent, consulta [Limitare l'accesso ai comandi a livello di root tramite SSM Agent](ssm-agent-restrict-root-level-commands.md). Per limitare l'accesso a questa funzionalità, ti consigliamo di creare politiche AWS Identity and Access Management (IAM) per i tuoi utenti che consentano l'accesso solo alle azioni da te definite. Per ulteriori informazioni sulla creazione di policy IAM per Fleet Manager, consulta [Controllo dell'accesso ad Fleet Manager](configuring-fleet-manager-permissions.md).
**Topics**
+ [
# Creazione di un utente o di un gruppo del sistema operativo utilizzando Fleet Manager
](manage-os-user-accounts-create.md)
+ [
# Aggiorna l'appartenenza di utenti o gruppi utilizzando Fleet Manager
](manage-os-user-accounts-update.md)
+ [
# Eliminazione di un utente o di un gruppo del sistema operativo utilizzando Fleet Manager
](manage-os-user-accounts-delete.md)
# Creazione di un utente o di un gruppo del sistema operativo utilizzando Fleet Manager
**Nota**
Fleet Manager utilizza Session Manager per impostare le password per i nuovi utenti. Per le istanze Amazon EC2, il profilo istanza associato alle tue istanze gestite deve fornire le autorizzazioni per Session Manager in modo da poter utilizzare questa funzionalità. Per ulteriori informazioni sull'aggiunta delle autorizzazioni Session Manager a un profilo dell'istanza, consulta [Aggiunta di autorizzazioni Session Manager per un ruolo IAM esistente](getting-started-add-permissions-to-existing-profile.md).
Invece di accedere direttamente a un server per creare un account utente o un gruppo, è possibile utilizzare la console Fleet Manager per eseguire le stesse attività.
**Per creare un account utente del sistema operativo utilizzando Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito su cui si desidera creare un nuovo utente.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Utenti e gruppi**.
1. Seleziona la scheda **Users (Utenti)**, quindi scegli **Create user (Creazione dell'utente)**.
1. Inserire un valore per **Name (Nome)** del nuovo utente.
1. (Consigliato) Seleziona la casella di controllo accanto a **Set password (Imposta password)**. Al termine della procedura verrà richiesto di fornire una password per il nuovo utente.
1. Seleziona **Create user (Crea utente)**. Se è stata selezionata la casella di controllo per creare una password per il nuovo utente, verrà richiesto di inserire un valore per la password e selezionare **Done (Fatto)**. Se la password specificata non soddisfa i requisiti specificati dalle policy locali o di dominio del nodo gestito, viene restituito un errore.
**Per creare un gruppo del sistema operativo utilizzando Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui si desidera creare un gruppo.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Utenti e gruppi**.
1. Scegliere la scheda **Gruppi** quindi scegliere **Crea gruppo**.
1. Inserire un valore per **Name (Nome)** del nuovo gruppo.
1. (Opzionale) inserire un valore per **Description (Descrizione)** del nuovo gruppo.
1. (Opzionale) Seleziona gli utenti da aggiungere a **Group members (Membri del gruppo)** per il nuovo gruppo.
1. Seleziona **Create group (Crea gruppo)**.
# Aggiorna l'appartenenza di utenti o gruppi utilizzando Fleet Manager
Invece di accedere direttamente a un server per aggiornare un account utente o un gruppo, è possibile utilizzare la console Fleet Manager per eseguire le stesse attività.
**Per aggiungere un account utente del sistema operativo a un nuovo gruppo utilizzando Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui esiste l'account utente che desideri aggiornare.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Utenti e gruppi**.
1. Scegli la scheda **Users** (Utenti);
1. Scegli il pulsante accanto all'utente che si desidera aggiornare.
1. Scegli **Operazioni, Aggiungi utente al gruppo**.
1. Scegli il gruppo a cui aggiungere l'utente in **Add to group (Aggiungi a gruppo)**.
1. Seleziona **Add user to group (Aggiungi utente al gruppo)**.
**Per modificare l'appartenenza a un gruppo del sistema operativo utilizzando Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui esiste il gruppo che desideri aggiornare.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Utenti e gruppi**.
1. Scegliere la scheda **Groups (Gruppi)**.
1. Scegli il pulsante accanto al gruppo che si desidera aggiornare.
1. Scegli **Operazioni, Modifica gruppo**.
1. Scegli gli utenti che desideri aggiungere o rimuovere in **Group members (Membri del gruppo)**.
1. Seleziona **Modify group (Modifica gruppo)**.
# Eliminazione di un utente o di un gruppo del sistema operativo utilizzando Fleet Manager
Invece di accedere direttamente a un server per eliminare un account utente o un gruppo, è possibile utilizzare la console Fleet Manager per eseguire le stesse attività.
**Per eliminare un account utente del sistema operativo utilizzando Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui esiste l'account utente che desideri eliminare.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Utenti e gruppi**.
1. Scegli la scheda **Users** (Utenti);
1. Scegli il pulsante accanto all'utente che si desidera eliminare.
1. Scegli **Operazioni, Elimina utente locale**.
**Per eliminare un gruppo del sistema operativo utilizzando Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui esiste il gruppo che desideri eliminare.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Utenti e gruppi**.
1. Scegli la scheda **Group (Gruppo)**.
1. Scegli il pulsante accanto al gruppo che si desidera aggiornare.
1. Scegli **Operazioni, Elimina gruppo locale**.
# Gestione del registro di Windows sui nodi gestiti
È possibile utilizzareFleet Manager, uno strumento in AWS Systems Manager, per gestire il registro sui nodi Windows Server gestiti. Dalla console Fleet Manager è possibile creare, copiare, aggiornare ed eliminare voci e valori del registro.
**Importante**
Ti consigliamo di creare un backup del registro o di acquisire uno snapshot del volume principale Amazon Elastic Block Store (Amazon EBS) allegato al tuo nodo gestito, prima di modificare il registro. Possono verificarsi problemi gravi se si modifica il registro in modo errato. Questi problemi potrebbero richiedere la reinstallazione del sistema operativo o il ripristino del volume principale del nodo da un'istantanea. AWS non garantisce che questi problemi possano essere risolti. Modifica il registro a proprio rischio e pericolo. L'utente è responsabile di tutte le modifiche al registro e garantisce di disporre di backup.
## Crea una chiave o voce del registro di Windows
**Per creare una chiave del registro di Windows con Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui desideri creare una chiave di registro.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Registro di Windows**.
1. Scegli l'hive in cui si desidera creare una nuova chiave di registro selezionando il **Registry name (Nome del registro)**.
1. Scegli **Crea, Crea chiave di registro**.
1. Scegli il pulsante accanto alla voce di registro in cui si desidera creare una chiave nuova.
1. Scegli **Create registry key (Crea chiave di registro)**.
1. Inserisci un valore per **Name (Nome)** della nuova chiave di registro e seleziona **Submit (Invia)**.
**Per creare una voce del registro di Windows con Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto all'istanza in cui si desidera creare una voce di registro.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Registro di Windows**.
1. Scegli l'hive e la chiave di registro seguente in cui si desidera creare una nuova chiave di registro selezionando il **Registry name (Nome del registro)**.
1. Scegli **Crea, Crea voce di registro**.
1. Inserisci un valore per **Name (Nome)** della nuova voce di registro.
1. Scegli **Type (Tipo)** di valore che si desidera creare per la voce di registro. Per ulteriori informazioni sui tipi di valore del registro, consulta [Registry value types (Tipi di valori del registro)](https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-value-types).
1. Inserisci un valore per **Value (Valore)** della nuova voce di registro.
## Aggiorna una voce di registro di Windows
**Per aggiornare una voce del registro di Windows con Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui desideri aggiornare una voce di registro.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Registro di Windows**.
1. Scegli l'hive e la chiave di registro seguente che si desidera aggiornare selezionando il **Registry name (Nome del registro)**.
1. Scegli il pulsante accanto alla voce di registro che si desidera aggiornare.
1. Scegli **Operazioni, Aggiorna voce di registro**.
1. Inserisci un nuovo valore per **Value (Valore)** della voce di registro.
1. Scegliere **Aggiorna**.
## Elimina una chiave o voce del registro di Windows
**Per eliminare una chiave del registro di Windows con Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui desideri eliminare una chiave di registro.
1. Scegli **Strumenti, Registro di Windows**.
1. Scegli l'hive e la chiave di registro seguente che si desidera eliminare selezionando il **Registry name (Nome del registro)**.
1. Scegli il pulsante accanto alla chiave di registro che si desidera eliminare.
1. Scegli **Operazioni, Elimina chiave di registro**.
**Per eliminare una voce del registro di Windows con Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto al nodo gestito in cui desideri eliminare una voce di registro.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Registro di Windows**.
1. Scegli l'hive e la chiave di registro seguente contenente la voce che si desidera eliminare selezionando il **Registry name (Nome del registro)**.
1. Scegli il pulsante accanto alla voce di registro che si desidera eliminare.
1. Scegli **Operazioni, Elimina voce di registro**.
# Gestione automatica delle istanze EC2 con la configurazione di gestione host predefinita
*L'impostazione Default Host Management Configuration consente di AWS Systems Manager gestire automaticamente le istanze Amazon EC2 come istanze gestite.* Un'istanza gestita è un'istanza EC2 configurata per l'uso con Systems Manager.
I vantaggi della gestione delle istanze con Systems Manager includono:
+ Connettersi in modo sicuro alle istanze EC2 utilizzando Session Manager.
+ Esegui le scansioni automatiche delle patch utilizzando Patch Manager.
+ Visualizzare informazioni dettagliate sulle istanze utilizzando Inventario di Systems Manager Inventory.
+ Tieni traccia delle istanze e gestiscile utilizzando Fleet Manager.
+ Mantenere SSM Agent aggiornato automaticamente.
*Fleet Manager, Inventory, Patch Manager e Session Manager sono strumenti di Systems Manager.*
Utilizzando Default Host Management Configuration, puoi gestire le istanze EC2 senza dover creare manualmente un profilo di istanza AWS Identity and Access Management (IAM). Invece, Default Host Management Configuration crea e applica un ruolo IAM predefinito per garantire che Systems Manager disponga delle autorizzazioni per gestire tutte le istanze nel Account AWS e in Regione AWS cui è attivato.
Se le autorizzazioni fornite non sono sufficienti per il tuo caso d'uso, è possibile anche aggiungere policy al ruolo IAM predefinito creato dalla configurazione di gestione host predefinita. In alternativa, se non hai bisogno di autorizzazioni per tutte le funzionalità fornite dal ruolo IAM predefinito, è possibile creare ruoli e policy personalizzati. Qualsiasi modifica apportata al ruolo IAM scelto per la configurazione di gestione host predefinita si applica a tutte le istanze Amazon EC2 gestite nella Regione e nell'account.
Per ulteriori informazioni sulla policy utilizzata dalla configurazione di gestione host predefinita, consulta la pagina [AWS politica gestita: Amazon SSMManaged EC2 InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy).
**Implementazione dell'accesso con privilegi minimi**
La procedura in questo argomento deve essere eseguita solo dagli amministratori. Pertanto, si consiglia di implementare l'*accesso con privilegi minimi* per impedire agli utenti non amministrativi di configurare o modificare la funzionalità Configurazione di gestione host predefinita. Per visualizzare esempi di policy che limitano l'accesso alla funzionalità Configurazione di gestione host predefinita, consulta [Esempi di policy con privilegi minimi per la funzionalità Configurazione di gestione host predefinita](#least-privilege-examples) più avanti in questo argomento.
**Importante**
Le informazioni di registrazione delle istanze registrate utilizzando la configurazione di gestione host predefinita sono archiviate localmente nelle directory `var/lib/amazon/ssm` o `C:\ProgramData\Amazon`. La rimozione di tali directory o dei relativi file impedirà all'istanza di acquisire le credenziali necessarie per connettersi a Systems Manager utilizzando la configurazione di gestione host predefinita. In questi casi, è necessario utilizzare un profilo dell'istanza IAM per fornire le autorizzazioni richieste all'istanza o ricreare l'istanza.
**Topics**
+ [
## Prerequisiti
](#dhmc-prerequisites)
+ [
## Attivazione dell'impostazione di Configurazione di gestione host predefinita
](#dhmc-activate)
+ [
## Disattivazione dell'impostazione di Configurazione di gestione host predefinita
](#dhmc-deactivate)
+ [
## Esempi di policy con privilegi minimi per la funzionalità Configurazione di gestione host predefinita
](#least-privilege-examples)
## Prerequisiti
Per utilizzare Default Host Management Configuration nel Regione AWS luogo in Account AWS cui si attiva l'impostazione, è necessario soddisfare i seguenti requisiti.
+ Un'istanza da gestire deve utilizzare Instance Metadata Service Version 2 (IMDSv2).
La configurazione di gestione host predefinita non supporta Instance Metadata Service versione 1. Per informazioni sulla transizione a IMDSv2, consulta [Transition to using Instance Metadata Service Version 2 nella Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) *User* Guide
+ Per poter essere gestito, SSM Agent versione 3.2.582.0 o successiva deve essere installato sull'istanza.
Per informazioni sulla verifica della versione di SSM Agent installata sull'istanza, consulta [Verifica del numero di versione di SSM Agent](ssm-agent-get-version.md).
Per informazioni sull'aggiornamento di SSM Agent, consulta [Aggiornamento automatico di SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console).
+ In qualità di amministratore che esegue le attività descritte in questo argomento, devi disporre delle autorizzazioni per le operazioni e [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html)API [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html). [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html) Inoltre, è necessario disporre delle autorizzazioni per l'autorizzazione `iam:PassRole` del ruolo IAM `AWSSystemsManagerDefaultEC2InstanceManagementRole`. Quello seguente è un esempio di policy che concede queste autorizzazioni. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting",
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
}
]
}
```
------
+ Se un profilo dell'istanza IAM è già collegato a un'istanza EC2 da gestire utilizzando Systems Manager, devi rimuoverne tutte le autorizzazioni che consentono l'operazione `ssm:UpdateInstanceInformation`. SSM Agent tenta di utilizzare le autorizzazioni del profilo dell'istanza prima di utilizzare le autorizzazioni della configurazione di gestione host predefinita. Se consenti l'operazione `ssm:UpdateInstanceInformation` nel profilo dell'istanza IAM, l'istanza non utilizzerà le autorizzazioni della configurazione di gestione host predefinita.
## Attivazione dell'impostazione di Configurazione di gestione host predefinita
È possibile attivare la configurazione predefinita della gestione dell'host dalla Fleet Manager console o utilizzando AWS Command Line Interface o AWS Tools for Windows PowerShell.
È necessario attivare l’impostazione di Configurazione di gestione host predefinita in ciascuna Regione nella quale si desidera che gestisca le istanze Amazon EC2.
Dopo aver attivato la Configurazione di gestione host predefinita, le istanze potrebbero impiegare fino a 30 minuti per utilizzare le credenziali del ruolo scelto nel Passaggio 5 della seguente procedura.
**Per attivare la funzionalità Configurazione di gestione host predefinita (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 **Fleet Manager**.
1. Scegli **Gestione account, Configura la Configurazione di gestione host predefinita**.
1. Attiva **Abilita la configurazione di gestione host predefinita**.
1. Scegli il ruolo AWS Identity and Access Management (IAM) utilizzato per abilitare gli strumenti Systems Manager per le tue istanze. Ti consigliamo di utilizzare il ruolo predefinito fornito dalla configurazione di gestione host predefinita. Contiene il set minimo di autorizzazioni necessario per gestire le istanze Amazon EC2 utilizzando Systems Manager. Se preferisci utilizzare un ruolo personalizzato, la policy di attendibilità del ruolo deve riconoscere Systems Manager come un'entità attendibile.
1. Scegli **Configura** per completare la configurazione.
**Per attivare la funzionalità Configurazione di gestione host predefinita (riga di comando)**
1. Crea un file JSON sul tuo computer locale contenente la seguente policy di attendibilità.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
```
------
1. Apri AWS CLI o Tools for Windows PowerShell ed esegui uno dei seguenti comandi, a seconda del tipo di sistema operativo del computer locale, per creare un ruolo di servizio nel tuo account. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws iam create-role \
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole \
--path /service-role/ \
--assume-role-policy-document file://trust-policy.json
```
------
#### [ Windows ]
```
aws iam create-role ^
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole ^
--path /service-role/ ^
--assume-role-policy-document file://trust-policy.json
```
------
#### [ PowerShell ]
```
New-IAMRole `
-RoleName "AWSSystemsManagerDefaultEC2InstanceManagementRole" `
-Path "/service-role/" `
-AssumeRolePolicyDocument "file://trust-policy.json"
```
------
1. Esegui il comando seguente per collegare la policy gestita `AmazonSSMManagedEC2InstanceDefaultPolicy` al ruolo appena creato. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy \
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy ^
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ PowerShell ]
```
Register-IAMRolePolicy `
-PolicyArn "arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy" `
-RoleName "AWSSystemsManagerDefaultEC2InstanceManagementRole"
```
------
1. Apri AWS CLI o Tools for Windows PowerShell ed esegui il comando seguente. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role \
--setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role ^
--setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ PowerShell ]
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role" `
-SettingValue "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole"
```
------
Se il comando va a buon fine, non viene generato output.
1. Esegui il comando seguente per visualizzare le impostazioni correnti del servizio per la configurazione predefinita della gestione host nella versione corrente Account AWS e Regione AWS.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ PowerShell ]
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
```
------
Il comando restituisce informazioni simili alle seguenti.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/default-ec2-instance-management-role",
"SettingValue": "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"LastModifiedDate": "2022-11-28T08:21:03.576000-08:00",
"LastModifiedUser": "System",
"ARN": "arn:aws:ssm:us-east-2:-123456789012:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
"Status": "Custom"
}
}
```
## Disattivazione dell'impostazione di Configurazione di gestione host predefinita
È possibile disattivare la configurazione predefinita della gestione dell'host dalla Fleet Manager console o utilizzando AWS Command Line Interface o AWS Tools for Windows PowerShell.
Devi disattivare l’impostazione di Configurazione di gestione host predefinita in ciascuna Regione nella quale si desidera impedire che gestisca le istanze Amazon EC2. La disattivazione in una Regione non comporta la disattivazione in tutte le Regioni.
Se disattivi la funzionalità Configurazione di gestione host predefinita e non hai collegato un profilo dell'istanza alle istanze Amazon EC2 che consenta l'accesso a Systems Manager, queste non saranno più gestite da Systems Manager.
**Per disattivare la funzionalità Configurazione di gestione host predefinita (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 **Fleet Manager**.
1. Scegli **Gestione account, Configurazione di gestione host predefinita**.
1. Disattiva **Abilita configurazione di gestione host predefinita**.
1. Scegli **Configura** per disabilitare la configurazione di gestione host predefinita.
**Per disattivare la funzionalità Configurazione di gestione host predefinita (riga di comando)**
+ Apri AWS CLI o Tools for Windows PowerShell ed esegui il seguente comando. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm reset-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ Windows ]
```
aws ssm reset-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ PowerShell ]
```
Reset-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
```
------
## Esempi di policy con privilegi minimi per la funzionalità Configurazione di gestione host predefinita
Le seguenti policy di esempio mostrano come impedire ai membri dell'organizzazione di apportare modifiche all'impostazione della funzionalità Configurazione di gestione host predefinita nell'account.
### Politica di controllo del servizio per AWS Organizations
La seguente politica illustra come impedire ai membri non amministrativi dell'utente di aggiornare l'impostazione predefinita della configurazione di gestione dell'host. AWS Organizations Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:ResetServiceSetting"
],
"Resource": "arn:aws:ssm:*:*:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
},
{
"Effect": "Deny",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ssm.amazonaws.com"
},
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
},
{
"Effect": "Deny",
"Resource": "arn:aws:iam::*:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole"
],
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
}
]
}
```
------
### Policy per i principali IAM
La seguente policy dimostra come impedire a gruppi, ruoli o utenti IAM dell'utente di aggiornare l'impostazione AWS Organizations della configurazione di gestione host predefinita. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:ResetServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Deny",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole"
}
]
}
```
------
# Connettersi a un'istanza gestita da Windows Server utilizzando Remote Desktop
Puoi utilizzareFleet Manager, uno strumento in AWS Systems Manager, per connetterti alle tue istanze Windows Server Amazon Elastic Compute Cloud (Amazon EC2) utilizzando (RDP). Remote Desktop Protocol Fleet Manager Il Desktop remoto, basato su [Amazon DCV](https://docs.aws.amazon.com/dcv/latest/adminguide/what-is-dcv.html), offre una connettività sicura alle istanze Windows Server direttamente dalla console di Systems Manager. È possibile avere fino a quattro connessioni simultanee in un'unica finestra del browser.
L'API Fleet Manager Remote Desktop è denominata AWS Systems Manager GUI Connect. Per informazioni sull'utilizzo dell'API Systems Manager GUI Connect, consulta il *[Documento di riferimento dell'API AWS Systems Manager GUI Connect](https://docs.aws.amazon.com/ssm-guiconnect/latest/APIReference)*.
Attualmente, è possibile utilizzare Desktop remoto solo con istanze che eseguono Windows Server 2012 RTM o versioni successive. Desktop remoto supporta solo input in lingua inglese.
Fleet Manager Remote Desktop è un servizio solo per console e non supporta connessioni da riga di comando alle istanze gestite. Per connettersi a un'istanza gestita Windows Server tramite una shell, è possibile utilizzare Session Manager, un altro strumento di AWS Systems Manager. Per ulteriori informazioni, consulta [AWS Systems Manager Session Manager](session-manager.md).
**Nota**
La durata di una connessione RDP non è determinata dalla durata delle credenziali AWS Identity and Access Management (IAM) dell'utente. Al contrario, la connessione persiste invece fino al raggiungimento della sua durata massima o del limite di inattività, a seconda dell'evento che si verifica per primo. Per ulteriori informazioni, consulta [Durata e simultaneità della connessione remota](#rdp-duration-concurrency).
Per informazioni sulla configurazione delle autorizzazioni AWS Identity and Access Management (IAM) per consentire alle istanze di interagire con Systems Manager, consulta [Configurare le autorizzazioni delle istanze per Systems](setup-instance-permissions.md) Manager.
**Topics**
+ [
## Configurazione dell'ambiente
](#rdp-prerequisites)
+ [
## Configurazione delle autorizzazioni IAM per Desktop remoto
](#rdp-iam-policy-examples)
+ [
## Autenticazione delle connessioni Desktop remoto
](#rdp-authentication)
+ [
## Durata e simultaneità della connessione remota
](#rdp-duration-concurrency)
+ [
## Gestione degli attributi tramite Systems Manager GUI Connect AWS IAM Identity Center
](#iam-identity-center-attribute-handling)
+ [
## Connessione a un nodo gestito tramite Desktop remoto
](#rdp-connect-to-node)
+ [
## Visualizzazione delle informazioni sulle connessioni correnti e completate
](#list-connections)
## Configurazione dell'ambiente
Prima di utilizzare Desktop remoto, verifica che il tuo ambiente soddisfi i requisiti seguenti:
+ **Configurazione di nodi gestiti**
Assicurati che le istanze Amazon EC2 siano configurate come [nodi gestiti](fleet-manager-managed-nodes.md) in Systems Manager.
+ **Versione minima di SSM Agent**
Verifica che i nodi eseguano SSM Agent versione 3.0.222.0 o successiva. Per informazioni su come verificare la versione dell'agente in esecuzione su un nodo, consulta [Verifica del numero di versione di SSM Agent](ssm-agent-get-version.md). Per informazioni sull'installazione o l'aggiornamento di SSM Agent, consulta [Utilizzo di SSM Agent](ssm-agent.md).
+ **Configurazione della porta RDP**
Per accettare connessioni remote, il servizio Remote Desktop Services sui nodi Windows Server deve utilizzare la porta RDP 3389 predefinita. Questa è la configurazione predefinita di Amazon Machine Images () AMIs fornita da. AWS Non è richiesto esplicitamente di aprire alcuna porta in entrata per utilizzare Desktop remoto.
+ **Versione del modulo PSReadLine per la funzionalità della tastiera**
Per assicurarti che la tastiera funzioni correttamente in PowerShell, verifica che sui nodi che eseguono Windows Server 2022 sia installato il modulo PSReadLine versione 2.2.2 o successiva. Se i nodi utilizzano una versione precedente, è possibile installare la versione richiesta utilizzando i seguenti comandi.
```
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
```
Dopo aver installato il provider NuGet del pacchetto, esegui il comando seguente.
```
Install-Module `
-Name PSReadLine `
-Repository PSGallery `
-MinimumVersion 2.2.2 -Force
```
+ **Configurazione di Session Manager**
Prima di utilizzare Desktop remoto, è necessario completare i prerequisiti per l'installazione di Session Manager. Quando ti connetti a un'istanza utilizzando Remote Desktop, Regione AWS vengono applicate tutte le preferenze di sessione definite per il tuo Account AWS e. Per ulteriori informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
**Nota**
Se registri l'attività di Session Manager utilizzando Amazon Simple Storage Service (Amazon S3), le connessioni Desktop remoto genereranno l'errore seguente in `bucket_name/Port/stderr`. Questo errore è previsto e può essere ignorato.
```
Setting up data channel with id SESSION_ID failed: failed to create websocket for datachannel with error: CreateDataChannel failed with no output or error: createDataChannel request failed: unexpected response from the service
Session is already terminated
```
## Configurazione delle autorizzazioni IAM per Desktop remoto
Oltre alle autorizzazioni IAM richieste per Systems ManagerSession Manager, l'utente o il ruolo utilizzato deve disporre delle autorizzazioni per l'avvio delle connessioni.
**Autorizzazioni per l'avvio delle connessioni**
Per effettuare connessioni RDP alle istanze EC2 nella console, sono necessarie le seguenti autorizzazioni:
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
**Autorizzazioni per elencare le connessioni**
Per visualizzare gli elenchi di connessioni nella console, è richiesta la seguente autorizzazione:
`ssm-guiconnect:ListConnections`
Di seguito sono riportati alcuni esempi di policy IAM che è possibile collegare a un utente o a un ruolo per consentire diversi tipi di interazione con Desktop remoto. Sostituisci ogni *example resource placeholder* con le tue informazioni.
### Policy standard per la connessione alle istanze EC2
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*::document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
### Policy per la connessione a istanze EC2 con tag specifici
**Nota**
Nella seguente policy IAM, la sezione `SSMStartSession` richiede un nome della risorsa Amazon (ARN) per l'azione `ssm:StartSession`. Come mostrato, l'ARN specificato *non* richiede un Account AWS ID. Se si specifica un ID account, Fleet Manager restituisce `AccessDeniedException`.
La `AccessTaggedInstances` sezione, che si trova più in basso nella politica di esempio, richiede anche ARNs for`ssm:StartSession`. Per quelli ARNs, devi specificare Account AWS IDs.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:*::document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "AccessTaggedInstances",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag key": [
"tag value"
]
}
}
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
### Politica per la connessione AWS IAM Identity Center degli utenti alle istanze EC2
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSO",
"Effect": "Allow",
"Action": [
"sso:ListDirectoryAssociations*",
"identitystore:DescribeUser"
],
"Resource": "*"
},
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userName}"
]
}
}
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:managed-instance/*",
"arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "SSMSendCommand",
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:managed-instance/*",
"arn:aws:ssm:*:*:document/AWSSSO-CreateSSOUser"
]
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
## Autenticazione delle connessioni Desktop remoto
Quando stabilisci una connessione remota, puoi autenticarti utilizzando le credenziali Windows o la coppia di chiavi Amazon EC2 (file `.pem`) associata all'istanza. Per informazioni sull'uso delle coppie di chiavi, consulta [Coppie di chiavi Amazon EC2 e istanze Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) nella *Guida per l'utente di Amazon EC2*.
In alternativa, se sei autenticato all' Console di gestione AWS utilizzo AWS IAM Identity Center, puoi connetterti alle istanze senza fornire credenziali aggiuntive. Per un esempio di policy per consentire l'autenticazione della connessione remota utilizzando Centro identità IAM, consulta [Configurazione delle autorizzazioni IAM per Desktop remoto](#rdp-iam-policy-examples).
**Prima di iniziare**
Osserva le seguenti condizioni per l'uso dell'autenticazione di Centro identità IAM prima di avviare la connessione utilizzando Desktop remoto.
+ Desktop remoto supporta l'autenticazione di Centro identità IAM per i nodi nella stessa Regione AWS in cui hai abilitato Centro identità IAM.
+ Desktop remoto supporta nomi utente di IAM Identity Center composti da un massimo di 16 caratteri.
+ Desktop remoto supporta nomi utente di IAM Identity Center composti da caratteri alfanumerici e dai seguenti caratteri speciali: `.` `-` `_`
**Importante**
Le connessioni non avranno esito positivo per i nomi utente di IAM Identity Center che contengono i seguenti caratteri: `+` `=` `,`
IAM Identity Center supporta questi caratteri nei nomi utente, a differenza delle connessioni Fleet Manager RDP.
Inoltre, se un nome utente IAM Identity Center contiene uno o più simboli `@`, Fleet Manager ignora il primo simbolo `@` e tutti i caratteri che lo seguono, indipendentemente dal fatto che `@` introduca o meno la parte di dominio di un indirizzo e-mail. Ad esempio, per il nome utente IAM Identity Center `diego_ramirez@example.com`, la parte `@example.com` viene ignorata e il nome utente di Fleet Manager diventa `diego_ramirez`. Per `diego_r@mirez@example.com`, Fleet Manager ignora `@mirez@example.com` e il nome utente di Fleet Manager diventa `diego_r`.
+ Quando una connessione viene autenticata utilizzando IAM Identity Center, Remote Desktop crea un utente Windows locale nel gruppo Local Administrators dell'istanza. Questo utente persiste dopo la fine della connessione remota.
+ Desktop remoto non consente l'autenticazione IAM Identity Center per i nodi che sono controller del dominio Microsoft Active Directory.
+ Sebbene Desktop remoto consenta di utilizzare l'autenticazione IAM Identity Center per i nodi *uniti* a un dominio Active Directory, non è consigliabile farlo. Questo metodo di autenticazione concede autorizzazioni amministrative agli utenti che potrebbero sovrascrivere le autorizzazioni più restrittive concesse dal dominio.
**Regioni supportate per l'autenticazione di Centro identità IAM**
Connessioni Remote Desktop che utilizzano l'autenticazione di Centro identità IAM sono supportate nelle Regioni AWS seguenti:
+ 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)
+ Africa (Città del Capo) (af-south-1)
+ Asia Pacifico (Hong Kong) (ap-east-1)
+ Asia Pacifico (Mumbai) (ap-south-1)
+ Asia Pacifico (Tokyo) (ap-northeast-1)
+ Asia Pacifico (Seoul) (ap-northeast-2)
+ Asia Pacifico (Osaka-Locale) (ap-northeast-3)
+ Asia Pacifico (Singapore) (ap-southeast-1)
+ Asia Pacifico (Sydney) (ap-southeast-2)
+ Asia Pacific (Giacarta) (ap-southeast-3)
+ Canada (Centrale) (ca-central-1)
+ Europa (Francoforte) (eu-central-1)
+ Europa (Stoccolma) (eu-north-1)
+ Europa (Irlanda) (eu-west-1)
+ Europa (Londra) (eu-west-2)
+ Europa (Parigi) (eu-west-3)
+ Israele (Tel Aviv) (il-central-1)
+ Sud America (San Paolo) (sa-east-1)
+ Europa (Milano) (eu-south-1)
+ Medio Oriente (Bahrein) (me-south-1)
+ AWS GovCloud (Stati Uniti orientali) (-1) us-gov-east
+ AWS GovCloud (Stati Uniti occidentali) (us-gov-west-1)
## Durata e simultaneità della connessione remota
Le seguenti condizioni si applicano alle connessioni Desktop remoto attive:
+ **Durata della connessione**
Per impostazione predefinita, una connessione Desktop remoto viene interrotta dopo 60 minuti. Per evitare che una connessione venga interrotta, puoi scegliere **Rinnova sessione** prima di disconnetterti per reimpostare il timer di durata.
+ **Timeout di connessione**
Una connessione Desktop remoto si interrompe dopo essere rimasta inattiva per più di 10 minuti.
+ **Connessioni persistenti**
Dopo la connessione a Windows Server tramite Desktop remoto, la connessione persiste fino al raggiungimento della sua massima durata (60 minuti) o del limite di timeout di inattività (10 minuti). La durata della connessione non è determinata dalla durata delle credenziali AWS Identity and Access Management (IAM) dell'utente. La connessione persiste dopo la scadenza delle credenziali IAM, se i suoi limiti di durata non vengono soddisfatti. Quando si utilizza Desktop remoto, è necessario terminare la connessione dopo la scadenza delle credenziali IAM uscendo dalla pagina del browser.
+ **Connessioni simultanee**
Per impostazione predefinita, puoi avere un massimo di 5 connessioni Desktop remoto attive contemporaneamente per la stessa Account AWS e Regione AWS. Per richiedere un aumento di quote di servizio fino a 50 connessioni simultanee, consulta [Richiesta di aumento delle quote](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) nella *Guida per l'utente di Service Quotas*.
**Nota**
La licenza standard di Windows Server consente due connessioni RDP simultanee. Per supportare più connessioni, è necessario acquistare licenze di accesso client aggiuntive (CALs) da Microsoft o licenze Microsoft Remote Desktop Services da. AWS Per ulteriori informazioni sulle licenze aggiuntive, consulta i seguenti argomenti:
[Licenze di Accesso Client e licenze di gestione](https://www.microsoft.com/en-us/licensing/product-licensing/client-access-license) sul sito Web di Microsoft
[Utilizza gli abbonamenti basati sull'utente di License Manager per i prodotti software supportati](https://docs.aws.amazon.com/license-manager/latest/userguide/user-based-subscriptions.html) nella *Guida per l'utente di License Manager*
## Gestione degli attributi tramite Systems Manager GUI Connect AWS IAM Identity Center
Systems Manager GUI Connect è l'API che supporta le connessioni Fleet Manager nelle istanze EC2 tramite RDP. I seguenti dati utente di IAM Identity Center vengono conservati dopo la chiusura di una connessione:
+ `username`
Systems Manager GUI Connect crittografa questo attributo di identità a riposo utilizzando un Chiave gestita da AWS per impostazione predefinita. Le chiavi gestite dal cliente non sono supportate per la crittografia di questo attributo in Systems Manager GUI Connect. Se elimini un utente nella tua istanza IAM Identity Center, Systems Manager GUI Connect continua a mantenere l'attributo `username` associato a quell'utente per sette anni, dopodiché viene eliminato. Questi dati vengono conservati per supportare gli eventi di controllo, ad esempio elencare la cronologia delle connessioni di Systems Manager GUI Connect. I dati non possono essere eliminati manualmente.
## Connessione a un nodo gestito tramite Desktop remoto
**copy/paste Supporto del browser per il testo**
Utilizzando i browser Google Chrome e Microsoft Edge, è possibile copiare e incollare testo da un nodo gestito al computer locale e dal computer locale a un nodo gestito a cui hai effettuato la connessione.
Utilizzando il browser Mozilla Firefox, è possibile copiare e incollare il testo da un nodo gestito solo sul proprio computer locale. La copia dal computer locale al nodo gestito non è supportata.
**Per connetterti a un nodo gestito tramite Desktop remoto di Fleet 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 **Fleet Manager**.
1. Scegli il nodo a cui desideri connetterti. Puoi selezionare la casella di controllo o il nome del nodo.
1. Nel menu **Operazioni del nodo**, scegli **Connessione con Desktop remoto**.
1. Scegli il tuo **Tipo di autenticazione** preferito. Se scegli **Credenziali utente**, inserisci il nome utente e la password per un account utente Windows sul nodo a cui stai eseguendo la connessione. Se scegli **Coppia di chiavi**, puoi fornire l'autenticazione utilizzando uno dei seguenti metodi:
1. Scegli **Sfoglia la macchina locale** se desideri selezionare la chiave PEM associata all'istanza dal file system locale.
oppure
1. Scegli **Incolla contenuto della coppia di chiavi** se desideri copiare il contenuto del file PEM e incollarlo nel campo fornito.
1. Seleziona **Connetti**.
1. Per scegliere la risoluzione dello schermo preferita, nel menu **Operazioni**, scegli **Risoluzioni**, quindi seleziona una delle seguenti opzioni:
+ **Adatta automaticamente**
+ **1920 x 1080**
+ **1400 x 900**
+ **1366 x 768**
+ **800 x 600**
L'opzione **Adatta automaticamente** imposta la risoluzione in base alle dimensioni dello schermo rilevate.
## Visualizzazione delle informazioni sulle connessioni correnti e completate
Utilizza la sezione Fleet Manager della console Systems Manager per visualizzare le informazioni sulle connessioni RDP effettuate nel proprio account. Utilizzando un set di filtri, è possibile limitare l'elenco delle connessioni visualizzate a un intervallo di tempo, un'istanza specifica, l'utente che ha effettuato le connessioni e le connessioni con uno stato specifico. La console fornisce anche schede che mostrano informazioni su tutte le connessioni attualmente attive e tutte le connessioni passate.
**Per visualizzare le informazioni sulle connessioni correnti e completate**
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 **Fleet Manager**.
1. Scegli **Gestione account, Connessione con Remote Desktop (Desktop remoto)**.
1. Scegli una delle seguenti schede:
+ **Connessioni attive**
+ **Cronologia delle connessioni**
1. Per restringere ulteriormente l'elenco dei risultati di connessione visualizzati, specificate uno o più filtri nella casella di ricerca (![\[\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)). È anche possibile inserire un termine di ricerca a testo libero.
# Gestione dei volumi Amazon EBS all'interno di un'istanza gestita
[Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) fornisce volumi di archiviazione a blocchi da utilizzare con le istanze Amazon Elastic Compute Cloud (EC2). Il comportamento dei volumi EBS è simile a quello dei dispositivi a blocchi non formattati e non elaborati. Puoi montare questi volumi come dispositivi sulle istanze.
Puoi utilizzareFleet Manager, uno strumento in AWS Systems Manager, per gestire i volumi Amazon EBS sulle tue istanze gestite. Ad esempio, puoi inizializzare un volume EBS, formattare una partizione e montare il volume per renderlo disponibile all'uso.
**Nota**
Fleet Manager attualmente supporta la gestione dei volumi di Amazon EBS solo per le istanze Windows Server.
## Visualizzazione dei dettagli di un volume EBS
**Visualizzazione dei dettagli di un volume EBS con Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto all'istanza gestita di cui desideri visualizzare i dettagli dei volumi EBS.
1. Seleziona **Visualizza dettagli**.
1. Scegli **Strumenti, Volumi EBS**.
1. Per visualizzare i dettagli di un volume EBS, scegli il rispettivo ID nella colonna **ID volume**.
## Inizializzazione e formattazione di un volume EBS
**Inizializzazione e formattazione di un volume EBS con Fleet 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 **Fleet Manager**.
1. Scegli il pulsante accanto all'istanza gestita per la quale desideri inizializzare, formattare e montare un volume EBS. Puoi inizializzare un volume EBS solo se il suo disco è vuoto.
1. Seleziona **Visualizza dettagli**.
1. Nel menu **Strumenti**, scegli **Volumi EBS**.
1. Scegli il pulsante accanto al volume EBS che desideri inizializzare e formattare.
1. Scegli **Inizializzazione e formattazione**.
1. In **Stile di partizione**, scegli lo stile di partizione che desideri utilizzare per il volume EBS.
1. (Facoltativo) Scegli una **Lettera di unità** per la partizione.
1. (Facoltativo) Immetti un **Nome della partizione** per identificare la partizione.
1. Scegli il **File system** da utilizzare per organizzare i file e i dati memorizzati nella partizione.
1. Scegli **Conferma** per rendere il volume EBS disponibile per l'uso. Non è possibile modificare la configurazione della partizione Console di gestione AWS dopo la conferma, tuttavia è possibile utilizzare SSH o RDP per accedere all'istanza e modificare la configurazione della partizione.
# Accesso al portale Red Hat Knowledge base
Puoi utilizzare Fleet Manager uno strumento per accedere al portale della Knowledge base se sei un cliente Red Hat. AWS Systems Manager Sei considerato un cliente Red Hat se esegui istanze Red Hat Enterprise Linux (RHEL) o utilizzi servizi RHEL su AWS. Il portale della Knowledge base include binari e forum di condivisione di conoscenze e discussioni per il supporto della community disponibili solo per i clienti con licenza Red Hat.
Oltre alle autorizzazioni AWS Identity and Access Management (IAM) richieste per Systems Manager eFleet Manager, l'utente o il ruolo utilizzato per accedere alla console deve consentire all'`rhelkb:GetRhelURL`azione di accedere al portale della Knowledge base.
**Per accedere al portale Red Hat Knowledgebase**
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 **Fleet Manager**.
1. Seleziona l'istanza RHEL che desideri utilizzare per connetterti al Red Hat Knowledgebase Portal.
1. Scegli **Gestione account**, **Accedi a Red Hat Knowledgebase** per aprire la pagina Red Hat Knowledge base.
Se utilizzi RHEL on AWS per eseguire RHEL carichi di lavoro completamente supportati, puoi anche accedere alla Red Hat Knowledge base tramite il sito Web di Red Hat utilizzando AWS le tue credenziali.
# Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti
Per diversi AWS Systems Manager strumenti come Run CommandDistributor, eSession Manager, puoi scegliere di selezionare manualmente i nodi gestiti su cui desideri eseguire un'operazione. In casi come questi, dopo avere specificato che si desidera scegliere manualmente i nodi, viene visualizzato un elenco dei nodi gestiti. su cui puoi decidere di eseguire l'operazione.
Questo argomento fornisce informazioni per aiutarti nell'esecuzione della diagnosi del motivo per cui un nodo gestito *che hai confermato come in esecuzione* non è incluso negli elenchi dei nodi gestiti in Systems Manager.
Affinché un nodo possa essere gestito da Systems Manager e reso disponibile negli elenchi dei nodi gestiti, deve soddisfare tre requisiti:
+ SSM Agent deve essere installato e in esecuzione su un nodo con un sistema operativo supportato.
**Nota**
Alcuni AWS managed Amazon Machine Images (AMIs) sono configurati per avviare istanze [SSM Agent](ssm-agent.md)preinstallate. (È possibile configurare anche una AMI per preinstallare SSM Agent.) Per ulteriori informazioni, consulta [Trova AMIs con SSM Agent preinstallato](ami-preinstalled-agent.md).
+ Per le istanze Amazon Elastic Compute Cloud (Amazon EC2), devi collegare AWS Identity and Access Management un profilo di istanza (IAM) all'istanza. Il profilo dell'istanza consente all'istanza di comunicare con il servizio Systems Manager. Se non si assegna un profilo dell'istanza all'istanza, è possibile registrarlo utilizzando un'[attivazione ibrida](activations.md), che non è uno scenario comune.
+ SSM Agent deve essere in grado di connettersi a un endpoint di Systems Manager per registrarsi con il servizio. Successivamente, il nodo gestito deve essere disponibile per il servizio, il che viene confermato da parte del servizio attraverso l'invio di un segnale ogni cinque minuti per controllare l'integrità dell'istanza.
+ Se lo stato di un nodo gestito è rimasto `Connection Lost` per almeno 30 giorni, il nodo potrebbe non essere più elencato nella console Fleet Manager. Per inserirlo nuovamente nell'elenco, è necessario risolvere il problema che ha causato la perdita della connessione.
Dopo aver verificato che un nodo gestito sia in esecuzione, puoi utilizzare il comando seguente per verificare se SSM Agent si è registrato correttamente con il servizio Systems Manager. Questo comando non restituisce risultati fino a quando la registrazione non è correttamente avvenuta.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-associations-status \
--instance-id instance-id
```
------
#### [ Windows ]
```
aws ssm describe-instance-associations-status ^
--instance-id instance-id
```
------
#### [ PowerShell ]
```
Get-SSMInstanceAssociationsStatus `
-InstanceId instance-id
```
------
Se la registrazione ha avuto esito positivo e il nodo gestito è ora disponibile per le operazioni di Systems Manager, il comando restituisce risultati simili ai seguenti.
```
{
"InstanceAssociationStatusInfos": [
{
"AssociationId": "fa262de1-6150-4a90-8f53-d7eb5EXAMPLE",
"Name": "AWS-GatherSoftwareInventory",
"DocumentVersion": "1",
"AssociationVersion": "1",
"InstanceId": "i-02573cafcfEXAMPLE",
"Status": "Pending",
"DetailedStatus": "Associated"
},
{
"AssociationId": "f9ec7a0f-6104-4273-8975-82e34EXAMPLE",
"Name": "AWS-RunPatchBaseline",
"DocumentVersion": "1",
"AssociationVersion": "1",
"InstanceId": "i-02573cafcfEXAMPLE",
"Status": "Queued",
"AssociationName": "SystemAssociationForScanningPatches"
}
]
}
```
Se la registrazione non è ancora completata o non ha avuto esito positivo, il comando restituisce risultati simili al seguente:
```
{
"InstanceAssociationStatusInfos": []
}
```
Se il comando non restituisce risultati dopo circa 5 minuti, utilizzare le informazioni seguenti per risolvere i problemi relativi ai nodi gestiti.
**Topics**
+ [
## Soluzione 1: verifica che SSM Agent sia installato e in esecuzione sul nodo gestito
](#instances-missing-solution-1)
+ [
## Soluzione 2: verificare che sia stato specificato un profilo dell'istanza IAM per l'istanza (solo per istanze EC2)
](#instances-missing-solution-2)
+ [
## Soluzione 3: verifica della connettività degli endpoint del servizio
](#instances-missing-solution-3)
+ [
## Soluzione 4: verifica del supporto del sistema operativo di destinazione
](#instances-missing-solution-4)
+ [
## Soluzione 5: verifica di lavorare nella Regione AWS stessa istanza di Amazon EC2
](#instances-missing-solution-5)
+ [
## Soluzione 6: verifica la configurazione proxy applicata a SSM Agent sul tuo nodo gestito
](#instances-missing-solution-6)
+ [
## Soluzione 7: installazione di un certificato TLS sulle istanze gestite
](#hybrid-tls-certificate)
+ [
# Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti tramite `ssm-cli`
](troubleshooting-managed-nodes-using-ssm-cli.md)
## Soluzione 1: verifica che SSM Agent sia installato e in esecuzione sul nodo gestito
Verifica che sul nodo gestito sia installata e in esecuzione la versione più recente di SSM Agent.
Per determinare se SSM Agent è installato e in esecuzione su un nodo gestito, consulta [Verifica dello stato di SSM Agent e avvio dell'agente](ssm-agent-status-and-restart.md).
Per installare o reinstallare SSM Agent su un nodo gestito, consulta i seguenti argomenti:
+ [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Linux](manually-install-ssm-agent-linux.md)
+ [Come installare SSM Agent su nodi Linux ibridi](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Windows Server](manually-install-ssm-agent-windows.md)
+ [Come installare SSM Agent su nodi Windows ibridi](hybrid-multicloud-ssm-agent-install-windows.md)
## Soluzione 2: verificare che sia stato specificato un profilo dell'istanza IAM per l'istanza (solo per istanze EC2)
Per le istanze Amazon Elastic Compute Cloud (Amazon EC2), verifica che l'istanza sia configurata con un profilo dell'istanza AWS Identity and Access Management (IAM) che consente all'istanza di comunicare con l'API di Systems Manager. Inoltre, verifica che l'utente disponga di una policy di attendibilità IAM che gli consenta di comunicare con l'API di Systems Manager.
**Nota**
I server locali, i dispositivi perimetrali e le macchine virtuali (VMs) utilizzano un ruolo di servizio IAM anziché un profilo di istanza. Per ulteriori informazioni, consulta [Creazione di un ruolo di servizio IAM richiesto per System Manager in ambiente ibrido e multicloud](hybrid-multicloud-service-role.md).
**Per determinare se un profilo dell'istanza con le autorizzazioni necessarie è collegato a un'istanza EC2**
1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Nel riquadro di navigazione, scegliere **Instances (Istanze)**.
1. Scegliere l'istanza in cui verificare la presenza di un profilo dell'istanza.
1. Sulla scheda **Descrizione** nel riquadro inferiore, individua **Ruolo IAM** e scegli il nome del ruolo.
1. Nella pagina **Riepilogo** del ruolo per il profilo dell'istanza, nella scheda **Autorizzazioni**, assicurarsi che `AmazonSSMManagedInstanceCore` sia elencato sotto **Policy di autorizzazione**.
Se invece viene utilizzato una policy personalizzata, assicurarsi che fornisca le stesse autorizzazioni di `AmazonSSMManagedInstanceCore`.
[Apri `AmazonSSMManagedInstanceCore` nella console](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore$jsonEditor)
Per informazioni su ulteriori policy che possono essere allegate a un profilo dell'istanza per Systems Manager, consulta la pagina [Creazione di un profilo dell'istanza IAM richiesto per Systems Manager](setup-instance-permissions.md).
## Soluzione 3: verifica della connettività degli endpoint del servizio
Verifica che l'istanza disponga della connettività agli endpoint del servizio Systems Manager. Questa connettività viene fornita creando e configurando endpoint VPC per Systems Manager o consentendo il traffico in uscita HTTPS (porta 443) agli endpoint di servizio.
Per le istanze Amazon EC2, l'endpoint del servizio Systems Manager per il Regione AWS viene utilizzato per registrare l'istanza se la configurazione del cloud privato virtuale (VPC) consente il traffico in uscita. Tuttavia, se la configurazione VPC in cui è stata avviata l'istanza non permette il traffico in uscita e non è possibile modificarla per consentire la connettività agli endpoint di servizio pubblici, è necessario configurare invece gli endpoint di interfaccia per il VPC.
Per ulteriori informazioni, consulta [Migliora la sicurezza delle istanze EC2 utilizzando gli endpoint VPC per Systems Manager](setup-create-vpc.md).
## Soluzione 4: verifica del supporto del sistema operativo di destinazione
Verifica che l'operazione scelta possa essere eseguita sul tipo di nodo gestito che si prevede di visualizzare in elenco. Alcune operazioni di Systems Manager possono essere indirizzate solo alle istanze di Windows o solo alle istanze di Linux. Ad esempio, i documenti Systems Manager (SSM) `AWS-InstallPowerShellModule` e `AWS-ConfigureCloudWatch` possono essere eseguiti solo su istanze di Windows. Nella pagina **Esegui un comando**, se scegli uno di questi documenti e selezioni **Scegli le istanze manualmente**, vengono elencate e rese disponibili per la selezione solo le istanze di Windows.
## Soluzione 5: verifica di lavorare nella Regione AWS stessa istanza di Amazon EC2
Le istanze Amazon EC2 vengono create e disponibili in aree specifiche Regioni AWS, come la regione degli Stati Uniti orientali (Ohio) (us-east-2) o la regione Europa (Irlanda) (eu-west-1). Assicurati di lavorare nella Regione AWS stessa istanza Amazon EC2 con cui desideri lavorare. Per ulteriori informazioni, consulta [Scelta di una Regione](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html#select-region) in *Nozioni di base su Console di gestione AWS*.
## Soluzione 6: verifica la configurazione proxy applicata a SSM Agent sul tuo nodo gestito
Verifica che la configurazione proxy applicata a SSM Agent sul tuo nodo gestito sia corretta. Se la configurazione del proxy non è corretta, il nodo non può connettersi agli endpoint di servizio richiesti oppure Systems Manager potrebbe identificare in modo errato il sistema operativo del nodo gestito. Per ulteriori informazioni, consultare [Configurazione di SSM Agent per l'utilizzo di un proxy sui nodi Linux](configure-proxy-ssm-agent.md) e [Configurazione di SSM Agent per utilizzare un proxy per le istanze Windows Server](configure-proxy-ssm-agent-windows.md).
## Soluzione 7: installazione di un certificato TLS sulle istanze gestite
Un certificato Transport Layer Security (TLS) deve essere installato su ogni istanza gestita con cui utilizzi. AWS Systems Manager Servizi AWS usa questi certificati per crittografare le chiamate verso altri. Servizi AWS
Un certificato TLS è già installato per impostazione predefinita su ogni istanza Amazon EC2 creata da qualsiasi Amazon Machine Image (AMI). La maggior parte dei sistemi operativi moderni include il certificato TLS richiesto da Amazon Trust Services CAs nel proprio trust store.
Per verificare se il certificato richiesto è installato sull'istanza, esegui il seguente comando in base al sistema operativo dell'istanza. Assicurati di sostituire la *region* parte dell'URL con quella Regione AWS in cui si trova l'istanza gestita.
------
#### [ Linux & macOS ]
```
curl -L https://ssm.region.amazonaws.com
```
------
#### [ Windows ]
```
Invoke-WebRequest -Uri https://ssm.region.amazonaws.com
```
------
Il comando dovrebbe restituire un errore `UnknownOperationException`. Se invece ricevi un messaggio SSL/TLS di errore, è possibile che il certificato richiesto non sia installato.
Se ritieni AMIs che i certificati CA di Amazon Trust Services richiesti non siano installati sui tuoi sistemi operativi di base, su istanze create con istanze non fornite da Amazon o sui tuoi server locali VMs, devi installare e consentire un certificato di [Amazon Trust Services](https://www.amazontrust.com/repository/) o utilizzare AWS Certificate Manager (ACM) per creare e gestire certificati per un servizio integrato supportato.
In ciascuna delle istanze gestite deve essere installato uno dei seguenti certificati Transport Layer Security (TLS).
+ Amazon CA root 1
+ Autorità di certificazione root dei servizi Starfield - G2
+ Autorità di certificazione Starfield di livello 2
Per ulteriori informazioni su ACM, consulta la *Guida per l'utente di [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/)*.
Se i certificati nel tuo ambiente di elaborazione sono gestiti da un Group Policy Object (GPO), potresti dover configurare le policy di gruppo affinché includano uno di tali certificati.
Per ulteriori informazioni sui certificati Amazon Root e Starfield, consulta il post del blog [How to Prepare AWS for's Move to Its Own Certificate Authority](https://aws.amazon.com/blogs/security/how-to-prepare-for-aws-move-to-its-own-certificate-authority/).
# Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti tramite `ssm-cli`
`ssm-cli` è uno strumento a riga di comando autonomo incluso nell'installazione di SSM Agent. Quando si installa SSM Agent 3.1.501.0 o versione successiva su un computer, è possibile eseguire comandi `ssm-cli` su quel computer. L'output di questi comandi aiuta a determinare se la macchina soddisfa i requisiti minimi per una macchina Amazon EC2 o non EC2 da AWS Systems Manager gestire e quindi aggiunta agli elenchi di nodi gestiti in Systems Manager. (SSM Agentla versione 3.1.501.0 è stata rilasciata a novembre 2021.)
**Requisiti minimi**
Affinché un'istanza Amazon EC2 o una macchina non EC2 possa essere gestita AWS Systems Manager e disponibile in elenchi di nodi gestiti, deve soddisfare tre requisiti principali:
+ SSM Agent deve essere installato e in esecuzione su una macchina con un [sistema operativo supportato](operating-systems-and-machine-types.md#prereqs-operating-systems).
Alcuni AWS managed Amazon Machine Images (AMIs) for EC2 sono configurati per avviare istanze con istanze preinstallate. [SSM Agent](ssm-agent.md) (È possibile configurare anche una AMI per preinstallare SSM Agent.) Per ulteriori informazioni, consulta [Trova AMIs con SSM Agent preinstallato](ami-preinstalled-agent.md).
+ Un profilo di istanza AWS Identity and Access Management (IAM) (per istanze EC2) o un ruolo di servizio IAM (per macchine non EC2) che fornisce le autorizzazioni necessarie per comunicare con il servizio Systems Manager deve essere collegato alla macchina.
+ SSM Agent deve essere in grado di connettersi a un endpoint di Systems Manager per registrarsi con il servizio. Successivamente, il nodo gestito deve essere disponibile per il servizio, il che viene confermato dal servizio che invia un segnale ogni cinque minuti per controllare l'integrità del nodo gestito.
**Comandi preconfigurati in `ssm-cli`**
Sono inclusi comandi preconfigurati che raccolgono le informazioni richieste per la diagnostica del motivo per cui una macchina confermata come in esecuzione non è inclusa negli elenchi dei nodi gestiti in Systems Manager. Questi comandi vengono eseguiti quando si specifica l'opzione `get-diagnostics`.
Sulla macchina, esegui il seguente comando per utilizzare `ssm-cli` che ti aiuterà a risolvere i problemi relativi alla disponibilità dei nodi gestiti.
------
#### [ Linux & macOS ]
```
ssm-cli get-diagnostics --output table
```
------
#### [ Windows ]
Su macchine Windows Server, devi passare alla directory `C:\Program Files\Amazon\SSM` prima di eseguire il comando.
```
ssm-cli.exe get-diagnostics --output table
```
------
#### [ PowerShell ]
Su macchine Windows Server, devi passare alla directory `C:\Program Files\Amazon\SSM` prima di eseguire il comando.
```
.\ssm-cli.exe get-diagnostics --output table
```
------
Il comando restituisce un output come una tabella simile alla seguente.
**Nota**
I controlli di connettività su `ssmmessages``s3`,`kms`,`logs`, ed `monitoring` endpoint riguardano funzionalità opzionali aggiuntive, come Session Manager la possibilità di accedere ad Amazon Simple Storage Service (Amazon S3) o CloudWatch Amazon Logs e utilizzare la crittografia (). AWS Key Management Service AWS KMS
------
#### [ Linux & macOS ]
```
[root@instance]# ssm-cli get-diagnostics --output table
┌───────────────────────────────────────┬─────────┬───────────────────────────────────────────────────────────────────────┐
│ Check │ Status │ Note │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ EC2 IMDS │ Success │ IMDS is accessible and has instance id i-0123456789abcdefa in Region │
│ │ │ us-east-2 │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Hybrid instance registration │ Skipped │ Instance does not have hybrid registration │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssm endpoint │ Success │ ssm.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ec2messages endpoint │ Success │ ec2messages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssmmessages endpoint │ Success │ ssmmessages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to s3 endpoint │ Success │ s3.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to kms endpoint │ Success │ kms.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to logs endpoint │ Success │ logs.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to monitoring endpoint │ Success │ monitoring.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ AWS Credentials │ Success │ Credentials are for │
│ │ │ arn:aws:sts::123456789012:assumed-role/Fullaccess/i-0123456789abcdefa │
│ │ │ and will expire at 2021-08-17 18:47:49 +0000 UTC │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Agent service │ Success │ Agent service is running and is running as expected user │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Proxy configuration │ Skipped │ No proxy configuration detected │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ SSM Agent version │ Success │ SSM Agent version is 3.0.1209.0, latest available agent version is │
│ │ │ 3.1.192.0 │
└───────────────────────────────────────┴─────────┴───────────────────────────────────────────────────────────────────────┘
```
------
#### [ Windows Server and PowerShell ]
```
PS C:\Program Files\Amazon\SSM> .\ssm-cli.exe get-diagnostics --output table
┌───────────────────────────────────────┬─────────┬─────────────────────────────────────────────────────────────────────┐
│ Check │ Status │ Note │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ EC2 IMDS │ Success │ IMDS is accessible and has instance id i-0123456789EXAMPLE in │
│ │ │ Region us-east-2 │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Hybrid instance registration │ Skipped │ Instance does not have hybrid registration │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssm endpoint │ Success │ ssm.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ec2messages endpoint │ Success │ ec2messages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssmmessages endpoint │ Success │ ssmmessages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to s3 endpoint │ Success │ s3.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to kms endpoint │ Success │ kms.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to logs endpoint │ Success │ logs.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to monitoring endpoint │ Success │ monitoring.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ AWS Credentials │ Success │ Credentials are for │
│ │ │ arn:aws:sts::123456789012:assumed-role/SSM-Role/i-123abc45EXAMPLE │
│ │ │ and will expire at 2021-09-02 13:24:42 +0000 UTC │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Agent service │ Success │ Agent service is running and is running as expected user │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Proxy configuration │ Skipped │ No proxy configuration detected │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Windows sysprep image state │ Success │ Windows image state value is at desired value IMAGE_STATE_COMPLETE │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ SSM Agent version │ Success │ SSM Agent version is 3.2.815.0, latest agent version in us-east-2 │
│ │ │ is 3.2.985.0 │
└───────────────────────────────────────┴─────────┴─────────────────────────────────────────────────────────────────────┘
```
------
La tabella seguente fornisce ulteriori dettagli per ciascuna delle verifiche eseguite da `ssm-cli`.
**Controlli diagnostici `ssm-cli`**
| Verifica | Informazioni |
| --- | --- |
| Servizio di metadati delle istanze Amazon EC2. | Indica se il nodo gestito è in grado di raggiungere il servizio di metadati. Un test non riuscito indica un problema di connettività a http://169.254.169.254 che può essere causato da configurazioni di firewall e proxy locali di routing, proxy o sistema operativo (OS). |
| Registrazione dell'istanza ibrida | Indica se SSM Agent è registrato utilizzando un'attivazione ibrida. |
| Connettività ad endpoint ssm | Indica se il nodo è in grado di raggiungere gli endpoint di servizio per Systems Manager sulla porta TCP 443. Un test fallito indica che i problemi di connettività https://ssm.region.amazonaws.com dipendono dalla posizione in Regione AWS cui si trova il nodo. I problemi di connettività possono essere causati dalla configurazione VPC, inclusi gruppi di sicurezza, liste di controllo dell'accesso alla rete, tabelle di routing o firewall e proxy del sistema operativo. |
| Connettività ad endpoint ec2messages | Indica se il nodo è in grado di raggiungere gli endpoint di servizio per Systems Manager sulla porta TCP 443. Un test non riuscito indica problemi di connettività a https://ec2messages.region.amazonaws.com seconda della posizione Regione AWS in cui si trova il nodo. I problemi di connettività possono essere causati dalla configurazione VPC, inclusi gruppi di sicurezza, liste di controllo dell'accesso alla rete, tabelle di routing o firewall e proxy del sistema operativo. |
| Connettività ad endpoint ssmmessages | Indica se il nodo è in grado di raggiungere gli endpoint di servizio per Systems Manager sulla porta TCP 443. Un test non riuscito indica problemi di connettività a https://ssmmessages.region.amazonaws.com seconda della posizione Regione AWS in cui si trova il nodo. I problemi di connettività possono essere causati dalla configurazione VPC, inclusi gruppi di sicurezza, liste di controllo dell'accesso alla rete, tabelle di routing o firewall e proxy del sistema operativo. |
| Connettività ad endpoint s3 | Indica se il modo è in grado di raggiungere l'endpoint di servizio per Amazon Simple Storage Service sulla porta TCP 443. Un test non riuscito indica problemi di connettività a https://s3.region.amazonaws.com seconda della posizione Regione AWS in cui si trova il nodo. La connettività a questo endpoint non è necessaria per la visualizzazione di un nodo nell'elenco dei nodi gestiti. |
| Connettività ad endpoint kms | Indica se il nodo è in grado di raggiungere l'endpoint del servizio AWS Key Management Service sulla porta TCP 443. Un test non riuscito indica problemi di connettività a `https://kms.region.amazonaws.com` seconda della posizione in Regione AWS cui si trova il nodo. La connettività a questo endpoint non è necessaria per la visualizzazione di un nodo nell'elenco dei nodi gestiti. |
| Connettività ad endpoint logs | Indica se il nodo è in grado di raggiungere l'endpoint del servizio per Amazon CloudWatch Logs sulla porta TCP 443. Un test non riuscito indica problemi di connettività a https://logs.region.amazonaws.com seconda della posizione in Regione AWS cui si trova il nodo. La connettività a questo endpoint non è necessaria per la visualizzazione di un nodo nell'elenco dei nodi gestiti. |
| Connettività ad endpoint monitoring | Indica se il nodo è in grado di raggiungere l'endpoint del servizio per Amazon CloudWatch sulla porta TCP 443. Un test non riuscito indica problemi di connettività a https://monitoring.region.amazonaws.com seconda della posizione in Regione AWS cui si trova il nodo. La connettività a questo endpoint non è necessaria per la visualizzazione di un nodo nell'elenco dei nodi gestiti. |
| AWS Credenziali | Indica se SSM Agent dispone delle credenziali richieste in base al profilo dell'istanza IAM (per le istanze EC2) o al ruolo di servizio IAM (per macchine non EC2) collegate alla macchina. Un test non riuscito indica che nessun profilo dell'istanza IAM o ruolo di servizio IAM è collegato alla macchina o che non contiene le autorizzazioni richieste per Systems Manager. |
| Servizio agente | Indica se il servizio SSM Agent è in esecuzione e se il servizio è in esecuzione come root per Linux o macOS, o SYSTEM per Windows Server. Un test non riuscito indica che il servizio SSM Agent non è in esecuzione o non è in esecuzione come root o SYSTEM. |
| Configurazione del proxy | Indica se SSM Agent è configurato per l'utilizzo di un proxy. |
| Stato dell'immagine Sysprep (solo Windows) | Indica lo stato di Sysprep sul nodo, SSM Agent non verrà avviato sul nodo se lo stato Sysprep ha un valore diverso da IMAGE\$1STATE\$1COMPLETE. |
| Versione SSM Agent | Indica se l'ultima versione disponibile di SSM Agent è installata. |
# AWS Systems Manager Attivazioni ibride
*Per configurare EC2 macchine diverse da utilizzare AWS Systems Manager in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types), è necessario creare un'attivazione ibrida.* I tipi non EC2 automatici supportati come nodi gestiti includono quanto segue:
+ Server presso la propria sede (server on-premises)
+ AWS IoT Greengrass dispositivi principali
+ AWS IoT e dispositivi non AWS periferici
+ Macchine virtuali (VMs), anche VMs in altri ambienti cloud
Quando esegui il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html) per avviare un processo di attivazione ibrido, riceverai un codice di attivazione e un ID nella risposta al comando. Il codice di attivazione e l'ID vengono quindi inclusi nel comando per installare SSM Agent sul computer, come descritto nel passaggio 3 di [Installare SSM Agent su nodi Linux ibridi](hybrid-multicloud-ssm-agent-install-linux.md) e nel passaggio 4 di [Installazione di SSM Agent su nodi ibridi di Windows Server](hybrid-multicloud-ssm-agent-install-windows.md).
Questo processo di attivazione si applica a tutti i tipi diversi dalle EC2 macchine, *ad eccezione* dei dispositivi AWS IoT Greengrass principali. Per informazioni sulla configurazione dei dispositivi core AWS IoT Greengrass per Systems Manager, consulta [Gestione dei dispositivi edge con Systems Manager](systems-manager-setting-up-edge-devices.md).
**Nota**
Il supporto non è attualmente fornito per sistemi diversi dai EC2 macOS computer.
**Informazioni sui livelli delle istanze di Systems Manager**
AWS Systems Manager offre un livello di istanze standard e un livello di istanze avanzate. Entrambi supportano nodi gestiti nell’ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). Il livello standard-instances consente di registrare un massimo di 1.000 computer per unità. Account AWS Regione AWS Se devi registrare più di 1.000 macchine in un singolo account e regione, utilizza il piano istanze avanzate. Non vi sono limitazioni nel numero di nodi gestiti che si possono creare nel livello istanze avanzate. Tutti i nodi gestiti configurati per Systems Manager hanno un prezzo su pay-per-use base. Per ulteriori informazioni su come abilitare le istanze avanzate, consulta [Attivazione del piano istanze avanzate](fleet-manager-enable-advanced-instances-tier.md). Per ulteriori informazioni sui prezzi, consulta [Prezzi di AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
Di seguito sono fornite alcune informazioni aggiuntive sul piano istanze standard e sul piano istanze avanzate:
+ Le istanze avanzate consentono inoltre di connettersi ai non EC2 nodi in un ambiente [ibrido e multicloud utilizzando](operating-systems-and-machine-types.md#supported-machine-types). AWS Systems Manager Session Manager Session Managerfornisce un accesso interattivo tramite shell alle istanze. Per ulteriori informazioni, consulta [AWS Systems Manager Session Manager](session-manager.md).
+ La quota di istanze standard si applica anche alle EC2 istanze che utilizzano un'attivazione locale di Systems Manager (che non è uno scenario comune).
+ Per applicare patch alle applicazioni rilasciate da Microsoft su macchine virtuali (VMs) istanze locali, attiva il livello delle istanze avanzate. Viene addebitato un costo per l'utilizzo del piano istanze avanzate. Non sono previsti costi aggiuntivi per applicare patch alle applicazioni rilasciate da Microsoft su istanze Amazon Elastic Compute Cloud (Amazon EC2). Per ulteriori informazioni, consulta [Applicazione di patch rilasciata da Microsoft in Windows Server](patch-manager-patching-windows-applications.md).
# AWS Systems Manager Inventory
AWS Systems Manager L'inventario offre visibilità sull'ambiente AWS informatico. È possibile utilizzare Inventory per raccogliere i *metadati* dai tuoi nodi gestiti. È possibile archiviare questi metadati in un bucket centrale Amazon Simple Storage Service (Amazon S3), quindi utilizzare gli strumenti predefiniti per eseguire query sui dati e individuare rapidamente quali nodi eseguono il software e le configurazioni richiesti dalla tua policy software e i nodi che devono essere aggiornati. È possibile Inventory su tutti i nodi gestiti utilizzando una procedura con un solo clic. Puoi anche configurare e visualizzare i dati di inventario da più Regioni AWS fonti Account AWS utilizzando Amazon Athena. Per iniziare a utilizzare l'inventario, apri la [console di Systems Manager](https://console.aws.amazon.com//systems-manager/inventory). Nel riquadro di navigazione, seleziona **Inventory (Inventario)**.
Quando i tipi di metadati preconfigurati raccolti da l'inventario di Systems Manager non soddisfano le proprie esigenze, è possibile creare un inventario personalizzato. Un inventario personalizzato è semplicemente un file JSON con le informazioni che fornisci e aggiungi al nodo gestito in una directory specifica. I dati raccolti da l'inventario di Systems Manager sono quelli contenuti in questo inventario personalizzato. Ad esempio, se esegui un data center di grandi dimensioni, è possibile specificare la posizione del rack di ciascun server come inventario personalizzato. È possibile quindi visualizzare i dati nello spazio sul rack quando visualizzi altri dati di inventario.
**Importante**
L'inventario di Systems Manager raccoglie *solo* i metadati dei nodi gestiti. non accede alle informazioni o ai dati proprietari.
La tabella seguente elenca i tipi di dati che è possibile raccogliere con Systems Manager Inventory. La tabella descrive anche diverse offerte per i nodi di destinazione e gli intervalli di raccolta che è possibile specificare.
****
| Configurazione | Informazioni |
| --- | --- |
| Tipi di metadati | È possibile configurare Inventory per raccogliere i seguenti tipi di dati: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/systems-manager-inventory.html) Per visualizzare un elenco di tutti i metadati raccolti da Inventory, consulta [Metadati raccolti da Inventory](inventory-schema.md). |
| Nodi di destinazione | Puoi scegliere di inventariare tutti i nodi gestiti all'interno del tuo Account AWS sito, selezionarli singolarmente o scegliere come target gruppi di nodi utilizzando i tag. Per ulteriori informazioni sulla raccolta dei dati di inventario da tutti i nodi gestiti, consulta [Fai l'inventario di tutti i nodi gestiti nel tuo Account AWS](inventory-collection.md#inventory-management-inventory-all). |
| Quando raccogliere le informazioni | È possibile specificare un intervallo di raccolta in termini di minuti, ore e giorni. L'intervallo di raccolta più breve è ogni 30 minuti. |
**Nota**
A seconda della quantità di dati raccolti, il sistema può impiegare alcuni minuti per restituire i dati sull'output specificato. Dopo la raccolta delle informazioni, i dati vengono inviati tramite un canale HTTPS sicuro a un AWS archivio di testo semplice accessibile solo dal tuo. Account AWS
È possibile visualizzare i dati della console Systems Manager nella pagina **Inventory (Inventario)**, che comprende diverse schede predefinite che permettono di eseguire le query sui dati.
![\[Schede Inventory (Inventario) di Systems Manager nella console Systems Manager.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-cards.png)
**Nota**
*Le schede di inventario filtrano automaticamente le istanze EC2 gestite da Amazon con lo stato *Terminato* e interrotto.* *Per i nodi locali e gestiti dai dispositivi AWS IoT Greengrass principali, le schede Inventory filtrano automaticamente i nodi con lo stato Terminato.*
Se crei una sincronizzazione dati risorsa per sincronizzare e archiviare tutti i tuoi dati in un singolo bucket Amazon S3, è possibile esplorare i dati dalla pagina **Inventory Detailed View (Vista dettagliata inventario)**. Per ulteriori informazioni, consulta [Esecuzione di query sui dati di inventario da più regioni e account](systems-manager-inventory-query.md).
**EventBridge supporto**
Questo strumento Systems Manager è supportato come tipo di *evento* nelle EventBridge regole di Amazon. Per informazioni, consulta [Monitoraggio degli eventi di Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md) e [Riferimento: modelli e tipi di EventBridge eventi Amazon per Systems Manager](reference-eventbridge-events.md).
**Topics**
+ [
# Ulteriori informazioni su l'inventario di Systems Manager
](inventory-about.md)
+ [
# Impostazione dell'inventario di Systems Manager
](systems-manager-inventory-setting-up.md)
+ [
# Configurazione della raccolta dell'inventario
](inventory-collection.md)
+ [
# Esecuzione di query sui dati di inventario da più regioni e account
](systems-manager-inventory-query.md)
+ [
# Esecuzione di query su una raccolta di inventario mediante filtri
](inventory-query-filters.md)
+ [
# Aggregazione dei dati di inventario
](inventory-aggregate.md)
+ [
# Utilizzo di inventari personalizzati
](inventory-custom.md)
+ [
# Visualizzazione della cronologia e del monitoraggio delle modifiche di Inventory
](inventory-history.md)
+ [
# Interruzione della raccolta dati ed eliminazione dei dati di inventario
](systems-manager-inventory-delete.md)
+ [
# Assegnazione di metadati di inventario personalizzati a un nodo gestito
](inventory-custom-metadata.md)
+ [
# Utilizzo di AWS CLI per configurare la raccolta dei dati di inventario
](inventory-collection-cli.md)
+ [
# Procedura dettagliata: utilizzo di sincronizzazione dati risorsa per aggregare dati di inventario
](inventory-resource-data-sync.md)
+ [
# Risoluzione dei problemi di Inventory Systems Manager
](syman-inventory-troubleshooting.md)
# Ulteriori informazioni su l'inventario di Systems Manager
Quando configuri AWS Systems Manager Inventory, devi specificare il tipo di metadati da raccogliere, i nodi gestiti da cui raccogliere i metadati e una pianificazione per la raccolta dei metadati. Queste configurazioni vengono salvate con il tuo Account AWS come associazione AWS Systems Manager State Manager. Un'associazione è semplicemente una configurazione.
**Nota**
Inventory raccoglie solo metadati. Non raccoglie dati personali o proprietari.
**Topics**
+ [
# Metadati raccolti da Inventory
](inventory-schema.md)
+ [
# Utilizzo dell'inventario dei file e del registro di sistema di Windows
](inventory-file-and-registry.md)
# Metadati raccolti da Inventory
Il seguente esempio mostra la lista completa dei metadati raccolti da ciascun plugin dell'inventario AWS Systems Manager.
```
{
"typeName": "AWS:InstanceInformation",
"version": "1.0",
"attributes":[
{ "name": "AgentType", "dataType" : "STRING"},
{ "name": "AgentVersion", "dataType" : "STRING"},
{ "name": "ComputerName", "dataType" : "STRING"},
{ "name": "InstanceId", "dataType" : "STRING"},
{ "name": "IpAddress", "dataType" : "STRING"},
{ "name": "PlatformName", "dataType" : "STRING"},
{ "name": "PlatformType", "dataType" : "STRING"},
{ "name": "PlatformVersion", "dataType" : "STRING"},
{ "name": "ResourceType", "dataType" : "STRING"},
{ "name": "AgentStatus", "dataType" : "STRING"},
{ "name": "InstanceStatus", "dataType" : "STRING"}
]
},
{
"typeName" : "AWS:Application",
"version": "1.1",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "Release", "dataType": "STRING"},
{ "name": "Epoch", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"},
{ "name": "Summary", "dataType": "STRING"},
{ "name": "PackageId", "dataType": "STRING"}
]
},
{
"typeName" : "AWS:File",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Size", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "FileVersion", "dataType": "STRING"},
{ "name": "InstalledDate", "dataType": "STRING"},
{ "name": "ModificationTime", "dataType": "STRING"},
{ "name": "LastAccessTime", "dataType": "STRING"},
{ "name": "ProductName", "dataType": "STRING"},
{ "name": "InstalledDir", "dataType": "STRING"},
{ "name": "ProductLanguage", "dataType": "STRING"},
{ "name": "CompanyName", "dataType": "STRING"},
{ "name": "ProductVersion", "dataType": "STRING"}
]
},
{
"typeName": "AWS:AWSComponent",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsUpdate",
"version":"1.0",
"attributes":[
{ "name": "HotFixId", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstalledBy", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Network",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "SubnetMask", "dataType": "STRING"},
{ "name": "Gateway", "dataType": "STRING"},
{ "name": "DHCPServer", "dataType": "STRING"},
{ "name": "DNSServer", "dataType": "STRING"},
{ "name": "MacAddress", "dataType": "STRING"},
{ "name": "IPV4", "dataType": "STRING"},
{ "name": "IPV6", "dataType": "STRING"}
]
},
{
"typeName": "AWS:PatchSummary",
"version":"1.0",
"attributes":[
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "BaselineId", "dataType": "STRING"},
{ "name": "SnapshotId", "dataType": "STRING"},
{ "name": "OwnerInformation", "dataType": "STRING"},
{ "name": "InstalledCount", "dataType": "NUMBER"},
{ "name": "InstalledPendingRebootCount", "dataType": "NUMBER"},
{ "name": "InstalledOtherCount", "dataType": "NUMBER"},
{ "name": "InstalledRejectedCount", "dataType": "NUMBER"},
{ "name": "NotApplicableCount", "dataType": "NUMBER"},
{ "name": "UnreportedNotApplicableCount", "dataType": "NUMBER"},
{ "name": "MissingCount", "dataType": "NUMBER"},
{ "name": "FailedCount", "dataType": "NUMBER"},
{ "name": "OperationType", "dataType": "STRING"},
{ "name": "OperationStartTime", "dataType": "STRING"},
{ "name": "OperationEndTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING"},
{ "name": "RebootOption", "dataType": "STRING"},
{ "name": "LastNoRebootInstallOperationTime", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING", "isOptional": "true"},
{ "name": "NonCompliantSeverity", "dataType": "STRING", "isOptional": "true"},
{ "name": "SecurityNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "CriticalNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "OtherNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"}
]
},
{
"typeName": "AWS:PatchCompliance",
"version":"1.0",
"attributes":[
{ "name": "Title", "dataType": "STRING"},
{ "name": "KBId", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "State", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ComplianceItem",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionId", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionTime", "dataType": "STRING", "isContext": "true"},
{ "name": "Id", "dataType": "STRING"},
{ "name": "Title", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "DocumentName", "dataType": "STRING"},
{ "name": "DocumentVersion", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "PatchSeverity", "dataType": "STRING"},
{ "name": "PatchState", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedText", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedLink", "dataType": "STRING", "isOptional": "true"},
{ "name": "CVEIds", "dataType": "STRING", "isOptional": "true"}
]
},
{
"typeName": "AWS:ComplianceSummary",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "OverallSeverity", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING"},
{ "name": "ExecutionType", "dataType": "STRING"},
{ "name": "ExecutionTime", "dataType": "STRING"},
{ "name": "CompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "CompliantHighCount", "dataType": "NUMBER"},
{ "name": "CompliantMediumCount", "dataType": "NUMBER"},
{ "name": "CompliantLowCount", "dataType": "NUMBER"},
{ "name": "CompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "CompliantUnspecifiedCount", "dataType": "NUMBER"},
{ "name": "NonCompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantHighCount", "dataType": "NUMBER"},
{ "name": "NonCompliantMediumCount", "dataType": "NUMBER"},
{ "name": "NonCompliantLowCount", "dataType": "NUMBER"},
{ "name": "NonCompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantUnspecifiedCount", "dataType": "NUMBER"}
]
},
{
"typeName": "AWS:InstanceDetailedInformation",
"version":"1.0",
"attributes":[
{ "name": "CPUModel", "dataType": "STRING"},
{ "name": "CPUCores", "dataType": "NUMBER"},
{ "name": "CPUs", "dataType": "NUMBER"},
{ "name": "CPUSpeedMHz", "dataType": "NUMBER"},
{ "name": "CPUSockets", "dataType": "NUMBER"},
{ "name": "CPUHyperThreadEnabled", "dataType": "STRING"},
{ "name": "OSServicePack", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Service",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "ServiceType", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "DependentServices", "dataType": "STRING"},
{ "name": "ServicesDependedOn", "dataType": "STRING"},
{ "name": "StartType", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRegistry",
"version":"1.0",
"attributes":[
{ "name": "KeyPath", "dataType": "STRING"},
{ "name": "ValueName", "dataType": "STRING"},
{ "name": "ValueType", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRole",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "Path", "dataType": "STRING"},
{ "name": "FeatureType", "dataType": "STRING"},
{ "name": "DependsOn", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "Installed", "dataType": "STRING"},
{ "name": "InstalledState", "dataType": "STRING"},
{ "name": "SubFeatures", "dataType": "STRING"},
{ "name": "ServerComponentDescriptor", "dataType": "STRING"},
{ "name": "Parent", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Tag",
"version":"1.0",
"attributes":[
{ "name": "Key", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ResourceGroup",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Arn", "dataType": "STRING"}
]
},
{
"typeName": "AWS:BillingInfo",
"version": "1.0",
"attributes": [
{ "name": "BillingProductId", "dataType": "STRING"}
]
}
```
**Nota**
Per `"typeName": "AWS:InstanceInformation"`, `InstanceStatus` può essere uno dei seguenti: Attivo, ConnectionLost, Arrestato, Terminato.
Con la versione 2.5, il pacchetto RPM (Resource Package Manager) ha sostituito l'attributo Serial con Epoch. L'attributo Epoch è un numero intero monotonicamente crescente come l'attributo Serial. Quando crei l'inventario utilizzando il tipo `AWS:Application`, un valore maggiore per Epoch indica una versione più recente. Se i valori di Epoch sono identici o vuoti, utilizza il valore dell'attributo Version o Release per determinare la versione più recente.
Alcuni metadati non sono disponibili da istanze Linux. In particolare, per "typeName": "aws:Network", i seguenti tipi di metadati non sono ancora supportati per le istanze Linux. SONO supportate per Windows.
\$1 "name": "SubnetMask", "dataType": "STRING"\$1,
\$1 "name": "DHCPServer", "dataType": "STRING"\$1,
\$1 "name": "DNSServer", "dataType": "STRING"\$1,
\$1 "name": "Gateway", "dataType": "STRING"\$1,
# Utilizzo dell'inventario dei file e del registro di sistema di Windows
AWS Systems Manager Inventory consente di cercare e inventariare i file su Windows Server Linux e sistemi macOS operativi. Puoi anche eseguire un inventario del registro di sistema di Windows in cui eseguire ricerche.
**File**: puoi raccogliere informazioni sui metadati dei file, ad esempio nomi file, data e ora di creazione dei file, data e ora dell'ultimo accesso/aggiornamento dei file, dimensioni dei file, per citarne alcuni. Per avviare la raccolta dell'inventario dei file, devi specificare un percorso su cui eseguire l'inventario, uno o più modelli che definiscono i tipi di file di cui eseguire un inventario e se il percorso deve essere attraversato in modo ricorsivo. Systems Manager esegue l'inventario di tutti i metadati dei file per i file nel percorso specificato che corrispondono al modello. L'inventario dei file utilizza il seguente parametro di input.
```
{
"Path": string,
"Pattern": array[string],
"Recursive": true,
"DirScanLimit" : number // Optional
}
```
+ **Path**: il percorso della directory in cui desideri eseguire l'inventario dei file. Per Windows, puoi utilizzare variabili di ambiente, come `%PROGRAMFILES% `, a condizione che la variabile sia associata a un solo percorso di directory. Ad esempio, se usi la variabile %PATH% associata a più percorsi di directory, Inventory genera un errore.
+ **Pattern**: una gamma di modelli per identificare i file.
+ **Recursive**: un valore booleano che indica se Inventory deve attraversare le directory in modo ricorsivo.
+ **DirScanLimit**: Un valore opzionale che specifica il numero di directory da scansionare. Utilizza questo parametro per ridurre al minimo l'impatto sui tuoi nodi gestiti. Inventario analizza un massimo di 5.000 directory.
**Nota**
Inventory raccoglie i metadati per un massimo di 500 file in tutti i percorsi specificati.
Di seguito sono elencati alcuni esempi di come specificare i parametri per l'esecuzione di un inventario di file.
+ Su Linux e macOS, raccogli i metadati dei file ".sh" nella directory `/home/ec2-user`, escludendo tutte le sottodirectory.
```
[{"Path":"/home/ec2-user","Pattern":["*.sh", "*.sh"],"Recursive":false}]
```
+ In Windows, raccogli i metadati di tutti i file ".exe" nella cartella Programmi, includendo le sottodirectory in modo ricorsivo.
```
[{"Path":"C:\Program Files","Pattern":["*.exe"],"Recursive":true}]
```
+ In Windows, raccogli i metadati di modelli di log specifici.
```
[{"Path":"C:\ProgramData\Amazon","Pattern":["*amazon*.log"],"Recursive":true}]
```
+ Limita il numero di directory durante la raccolta ricorsiva.
```
[{"Path":"C:\Users","Pattern":["*.ps1"],"Recursive":true, "DirScanLimit": 1000}]
```
**Windows Registry**: puoi raccogliere chiavi e valori del registro di sistema di Windows. È possibile scegliere un percorso chiave e raccogliere tutte le chiavi e i valori in modo ricorsivo. È possibile inoltre raccogliere una determinata chiave di registro e il relativo valore per un percorso specifico. Inventory raccoglie il percorso, il nome, il tipo e il valore delle chiave.
```
{
"Path": string,
"Recursive": true,
"ValueNames": array[string] // optional
}
```
+ **Percorso**: il percorso della chiave del registro di sistema.
+ **Recursive**: un valore booleano che indica se la funzione Inventario deve attraversare i percorsi del registro di sistema in modo ricorsivo.
+ **ValueNames**: Una matrice di nomi di valori per eseguire l'inventario delle chiavi di registro. Se utilizzi questo parametro, Systems Manager eseguirà l'inventario solo dei nomi di valori specificati per il percorso indicato.
**Nota**
Inventory raccoglie i metadati per un massimo di 250 valori della chiave di registro di sistema per tutti i percorsi specificati.
Di seguito sono elencati alcuni esempi di come specificare i parametri per l'esecuzione di un inventario del registro di sistema di Windows.
+ Raccogli in modo ricorsivo tutte le chiavi e i valori per un percorso specifico.
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon","Recursive": true}]
```
+ Raccogli tutte le chiavi e i valori per un percorso specifico (ricerca ricorsiva disabilitata).
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Intel\PSIS\PSIS_DECODER", "Recursive": false}]
```
+ Raccogli una chiave specifica utilizzando l'opzione `ValueNames`.
```
{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\MachineImage","ValueNames":["AMIName"]}
```
# Impostazione dell'inventario di Systems Manager
Prima di utilizzare AWS Systems Manager Inventory per raccogliere metadati su applicazioni, servizi, AWS componenti e altro in esecuzione sui nodi gestiti, ti consigliamo di configurare la sincronizzazione dei dati delle risorse per centralizzare lo storage dei dati di inventario in un unico bucket Amazon Simple Storage Service (Amazon S3). Ti consigliamo inoltre di configurare il EventBridge monitoraggio di Amazon degli eventi dell'inventario. Questi processi semplificano la visualizzazione e la gestione dei dati di inventario e della raccolta.
**Topics**
+ [
# Creazione di un Resource Data Sync per Inventario
](inventory-create-resource-data-sync.md)
+ [
# Utilizzo EventBridge per monitorare gli eventi dell'inventario
](systems-manager-inventory-setting-up-eventbridge.md)
# Creazione di un Resource Data Sync per Inventario
In questo argomento viene descritto come impostare e configurare la sincronizzazione dei dati delle risorse per AWS Systems Manager Inventory. Per informazioni sulla sincronizzazione dati risorsa Systems Manager Explorer, consulta [Configurazione di Systems Manager Explorer per visualizzare dati da più account e regioni](Explorer-resource-data-sync.md).
## Informazioni su Resource Data Sync
Puoi utilizzare Resource Data Sync di Systems Manager per inviare i dati di inventario raccolti da tutti i nodi gestiti in un singolo bucket Amazon Simple Storage Service (Amazon S3). La sincronizzazione dei dati della risorsa aggiorna automaticamente i dati centralizzati una volta raccolti i nuovi dati inventario. Con tutti i dati di inventario archiviati in un bucket Amazon S3 di destinazione, puoi utilizzare servizi come Amazon Athena e Amazon Quick per interrogare e analizzare i dati aggregati.
Ad esempio, supponi di aver configurato Inventory per raccogliere dati sul sistema operativo e sulle applicazioni in esecuzione in un parco di 150 nodi gestiti. Alcuni di questi nodi si trovano in un data center on-premises, mentre altri sono in esecuzione in Amazon Elastic Compute Cloud (Amazon EC2) su più Regioni AWS. Se *non* hai configurato Resource Data Sync, devi raccogliere manualmente i dati di inventario raccolti per ogni nodo gestito oppure devi creare script per raccogliere queste informazioni. Dovrai quindi trasferire i dati in un'applicazione per potervi eseguire query e analisi.
Con Resource Data Sync, puoi eseguire un'unica operazione per sincronizzare tutti i dati di Inventory da tutte i tuoi nodi gestiti. Una volta creata la sincronizzazione, Systems Manager crea una base di tutti i dati di inventario e la salva nel bucket Amazon S3 di destinazione. Quando vengono raccolti nuovi dati di inventario, Systems Manager aggiorna automaticamente i dati nel bucket Amazon S3. Potrai quindi trasferire i dati in modo rapido ed economico su Amazon Athena e Amazon Quick.
Il diagramma 1 mostra il modo in cui la sincronizzazione dei dati della risorsa aggrega i dati di inventario di Amazon EC2 e altri tipi di macchina presenti in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) in un bucket Amazon S3 di destinazione. Questo diagramma mostra anche come funziona la sincronizzazione dei dati delle risorse con più e. Account AWS Regioni AWS
**Diagramma 1: Sincronizzazione dei dati delle risorse con più e Account AWS Regioni AWS**
![\[Architettura di Systems Manager Resource Data Sync\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-resource-data-sync-updated.png)
Se elimini un nodo gestito, Resource Data Sync mantiene il file Inventory per il nodo eliminato. Tuttavia, per i nodi in esecuzione, sincronizzazione dati risorsa sovrascrive automaticamente i file di inventario precedenti quando vengono creati e scritti nel bucket Amazon S3 nuovi file. Se desideri tenere traccia delle variazioni dell'inventario nel tempo, puoi utilizzare il AWS Config servizio per tenere traccia del tipo di `SSM:ManagedInstanceInventory` risorsa. Per ulteriori informazioni, consulta [Guida introduttiva a AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html).
Utilizza le procedure in questa sezione per creare una sincronizzazione dei dati delle risorse per Inventory utilizzando Amazon S3 e AWS Systems Manager le console. Puoi anche utilizzarla AWS CloudFormation per creare o eliminare una sincronizzazione dei dati delle risorse. Per CloudFormation utilizzarla, aggiungi la [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html)risorsa al tuo CloudFormation modello. Per informazioni, consulta una delle seguenti fonti:
+ [AWS CloudFormation risorsa per la sincronizzazione dei dati delle risorse in AWS Systems Manager](https://aws.amazon.com/blogs/mt/aws-cloudformation-resource-for-resource-data-sync-in-aws-systems-manager/) (blog)
+ [Utilizzo di modelli AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) nella *Guida per l'utente di AWS CloudFormation *
**Nota**
Puoi usare AWS Key Management Service (AWS KMS) per crittografare i dati di inventario nel bucket Amazon S3. Per un esempio di come creare una sincronizzazione crittografata utilizzando AWS Command Line Interface (AWS CLI) e come lavorare con i dati centralizzati in Amazon Athena e Amazon Quick, consulta. [Procedura dettagliata: utilizzo di sincronizzazione dati risorsa per aggregare dati di inventario](inventory-resource-data-sync.md)
## Prima di iniziare
Prima di creare una sincronizzazione dati risorsa, utilizzare la procedura seguente per creare un bucket Amazon S3 centralizzato per archiviare i dati di inventario aggregati. La procedura descrive come assegnare la policy di bucket che consente a Systems Manager di scrivere i dati di inventario nel bucket da più account. Se si dispone già di un bucket Amazon S3 che si desidera utilizzare per aggregare i dati di inventario per la sincronizzazione dati risorsa, è necessario configurare il bucket per utilizzare la policy nella procedura seguente.
**Nota**
L'inventario di Systems Manager non può aggiungere dati a un bucket Amazon S3 specificato se tale bucket è configurato per l'utilizzo del comando Object Lock. Verifica che il bucket Amazon S3 creato o scelto per la sincronizzazione dati risorsa non sia configurato per l'utilizzo del comando Object Lock di Amazon S3. Per ulteriori informazioni, consulta [Come funziona Amazon S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
**Creazione e configurazione di un bucket Amazon S3 per la sincronizzazione dati risorsa**
1. Apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Creare un bucket in cui archiviare i dati di inventario aggregati. Per ulteriori informazioni, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) nella *Guida per l'utente di Amazon Simple Storage Service*. Prendi nota del nome del bucket e del Regione AWS luogo in cui lo hai creato.
1. Scegli la scheda **Autorizzazioni** e quindi **Policy (Policy di bucket**.
1. Copia e incolla la policy di bucket seguente nell'editor di policy. *amzn-s3-demo-bucket*Sostituiscilo con il nome del bucket S3 che hai creato. Sostituisci *account\$1ID\$1number* con un Account AWS numero ID valido.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=111122223333/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=444455556666/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=123456789012/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=777788889999/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:111122223333:resource-data-sync/*"
}
}
}
]
}
```
------
1. Salvare le modifiche.
## Crea una Resource Data Sync per Inventory
Utilizza la procedura seguente per creare un Resource Data Sync per Inventory di Systems Manager utilizzando la console Systems Manager. Per informazioni su come creare una sincronizzazione dei dati delle risorse utilizzando il AWS CLI, vedere[Utilizzo di AWS CLI per configurare la raccolta dei dati di inventario](inventory-collection-cli.md).
**Come creare una sincronizzazione dei dati delle risorse**
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 **Fleet Manager**.
1. Nel menu **Gestione dell'account**, scegli **Sincronizzazione dati risorsa**.
1. Scegli **Crea sincronizzazione dei dati di risorsa**.
1. Nel campo **Nome di sincronizzazione**, inserisci un nome per la configurazione di sincronizzazione.
1. Nel campo **Nome bucket**, inserire il nome del bucket Amazon S3 creato utilizzando la procedura **Creazione e configurazione di un bucket Amazon S3 per la sincronizzazione dati risorsa**.
1. (Facoltativo) Nel campo **Prefisso bucket**, inserisci il nome di un prefisso del bucket Amazon S3 (sottodirectory).
1. Nel campo **Regione bucket**, scegli **Questa Regione**, se il bucket Amazon S3 creato si trova nella Regione AWS attuale. Se il bucket si trova in un'altra Regione AWS, scegli **Altra Regione** e digita il nome della Regione.
**Nota**
Se la sincronizzazione e il bucket Amazon S3 di destinazione si trovano in regioni diverse, potrebbero essere applicati i prezzi per il trasferimento dei dati. Per ulteriori informazioni, consulta [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/).
1. (Facoltativo) Nel campo **ARN chiave KMS**, digita o incolla un ARN della chiave KMS per crittografare i dati di inventario in Amazon S3.
1. Scegli **Create** (Crea).
Per sincronizzare i dati di inventario di più dati Regioni AWS, è necessario creare una sincronizzazione dei dati delle risorse in *ogni* regione. Ripeti questa procedura in ogni Regione AWS punto in cui desideri raccogliere i dati di inventario e inviarli al bucket centrale Amazon S3. Quando si crea la sincronizzazione per ciascuna regione, specificare il bucket Amazon S3 centralizzato nel campo** Nome bucket**. Quindi utilizzare l'opzione **Regione bucket** per scegliere la Regione in cui è stato creato il bucket Amazon S3 centralizzato, come illustrato nella schermata seguente. Alla successiva esecuzione dell'associazione per raccogliere i dati di inventario, Systems Manager archivia i dati nel bucket Amazon S3 centralizzato.
![\[Sincronizzazione dei dati delle risorse di Systems Manager da più Regioni AWS\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-rds-multiple-regions.png)
## Creazione di una sincronizzazione dei dati delle risorse di inventario per gli account definiti in AWS Organizations
Puoi sincronizzare i dati di inventario da quelli Account AWS definiti in AWS Organizations a un bucket Amazon S3 centrale. Dopo aver completato le procedure seguenti, i dati dell'inventario vengono sincronizzati con i *singol*i prefissi chiave Amazon S3 nel bucket centrale. Ogni key prefix rappresenta un ID diverso Account AWS .
**Prima di iniziare**
Prima di iniziare, verifica di aver configurato e configurato Account AWS in AWS Organizations. Per ulteriori informazioni, consulta [ nella *Guida per l'utente di AWS Organizations *.](https://docs.aws.amazon.com/organizations/latest/userguide/rgs_getting-started.html)
Inoltre, tieni presente che devi creare la sincronizzazione dei dati delle risorse basata sull'organizzazione per ciascuna Regione AWS e Account AWS definita in. AWS Organizations
### Creazione di un bucket Amazon S3 centralizzato
Utilizza la procedura seguente per creare un bucket Amazon S3 centralizzato per archiviare i dati di inventario aggregati. La procedura descrive come assegnare la policy di bucket che consente a Systems Manager di scrivere i dati di inventario nel bucket dal tuo ID account AWS Organizations . Se si dispone già di un bucket Amazon S3 che si desidera utilizzare per aggregare i dati di inventario per la sincronizzazione dati risorsa, è necessario configurare il bucket per utilizzare la policy nella procedura seguente.
**Per creare e configurare un bucket Amazon S3 per la sincronizzazione dei dati delle risorse per più account definiti in AWS Organizations**
1. Apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Creare un bucket in cui archiviare i dati di inventario aggregati. Per ulteriori informazioni, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) nella *Guida per l'utente di Amazon Simple Storage Service*. Prendi nota del nome del bucket e del Regione AWS luogo in cui lo hai creato.
1. Scegli la scheda **Autorizzazioni** e quindi **Policy (Policy di bucket**.
1. Copia e incolla la policy di bucket seguente nell'editor di policy. Sostituisci *amzn-s3-demo-bucket * e *organization-id* con il nome del bucket Amazon S3 che hai creato e un ID account valido AWS Organizations .
Facoltativamente, sostituirlo *bucket-prefix* con il nome di un prefisso Amazon S3 (sottodirectory). Se non hai creato un prefisso, rimuovi*bucket-prefix*/dall'ARN nella seguente politica.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceOrgID": "organization-id"
}
}
},
{
"Sid": " SSMBucketDeliveryTagging",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObjectTagging",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
]
}
]
}
```
------
### Crea una sincronizzazione dei dati delle risorse di inventario per gli account definiti in AWS Organizations
La procedura seguente descrive come utilizzare la AWS CLI per creare una sincronizzazione dei dati delle risorse per gli account definiti in AWS Organizations. È necessario utilizzare il AWS CLI per eseguire questa operazione. È inoltre necessario eseguire questa procedura per ogni Regione AWS elemento Account AWS definito in AWS Organizations.
**Per creare una sincronizzazione dei dati delle risorse per un account definito in AWS Organizations (AWS CLI)**
1. 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).
1. Esegui il comando seguente per accertarti di non disporre di sincronizzazioni di dati della risorsa *basata su AWS Organizations*. È possibile avere più sincronizzazioni standard, incluse più sincronizzazioni standard e una sincronizzazione basata sulle organizzazioni. È possibile disporre di una sola sincronizzazione dati risorsa basata sull'organizzazione.
```
aws ssm list-resource-data-sync
```
Se il comando restituisce altre sincronizzazioni dati risorsa basate sull'organizzazione, è necessario eliminarle o scegliere di non crearne una nuova.
1. Eseguire il comando seguente per creare una sincronizzazione dei dati delle risorse per un account definito in AWS Organizations. Per amzn-s3-demo-bucket, specificare il nome del bucket Amazon S3 creato in precedenza in questo argomento. Se hai creato un prefisso (sottodirectory) per il tuo bucket, specifica queste informazioni per. *prefix-name*
```
aws ssm create-resource-data-sync --sync-name name --s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix-name,SyncFormat=JsonSerDe,Region=Regione AWS, for example us-east-2,DestinationDataSharing={DestinationDataSharingType=Organization}"
```
1. Ripeti i passaggi 2 e 3 per ogni Regione AWS Account AWS punto in cui desideri sincronizzare i dati con il bucket Amazon S3 centrale.
### Gestione delle sincronizzazioni dei dati della risorsa
Ciascuno Account AWS può avere 5 sincronizzazioni di dati di risorse per persona. Regione AWS Puoi utilizzare la console AWS Systems ManagerFleet Manager per gestire le sincronizzazioni dei dati della risorsa.
**Per visualizzare le sincronizzazioni dei dati della risorsa**
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 **Fleet Manager**.
1. Nel menu a discesa **Gestione account**, scegli **Sincronizzazione dati risorsa**.
1. Seleziona una sincronizzazione dei dati della risorsa dalla tabella, quindi scegli **Visualizza dettagli** per visualizzare le informazioni sulla sincronizzazione dei dati della risorsa.
**Come eliminare una sincronizzazione dei dati delle risorse**
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 **Fleet Manager**.
1. Nel menu a discesa **Gestione account**, scegli **Sincronizzazione dati risorsa**.
1. Seleziona una sincronizzazione dei dati della risorsa dalla tabella, quindi scegli **Elimina**.
# Utilizzo EventBridge per monitorare gli eventi dell'inventario
Puoi configurare una regola in Amazon EventBridge per creare un evento in risposta alle modifiche dello stato delle risorse di AWS Systems Manager Inventory. EventBridge supporta eventi per le seguenti modifiche allo stato dell'inventario. Tutti gli eventi vengono emessi in base al miglior tentativo.
**Tipo di inventario personalizzato eliminato per un'istanza specifica**: se una regola è configurata per monitorare questo evento, EventBridge crea un evento quando viene eliminato un tipo di inventario personalizzato su uno specifico gestore. EventBridgeinvia un evento per nodo per tipo di inventario personalizzato. Di seguito è riportato un modello di evento di esempio.
```
{
"timestampMillis": 1610042981103,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:09:41 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "succeeded",
"action": "delete",
"resource-type": "managed-instance",
"resource-id": "i-12345678",
"action-reason": "",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**Evento di eliminazione del tipo di inventario personalizzato per tutte le istanze**: se una regola è configurata per monitorare questo evento, EventBridge crea un evento quando viene eliminato un tipo di inventario personalizzato per tutti i nodi gestiti. Di seguito è riportato un modello di evento di esempio.
```
{
"timestampMillis": 1610042904712,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:08:24 PM",
"resources": [
],
"body": {
"action-status": "succeeded",
"action": "delete-summary",
"resource-type": "managed-instance",
"resource-id": "",
"action-reason": "The delete for type name Custom:SomeCustomInventoryType was completed. The deletion summary is: {\"totalCount\":1,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.1\",\"count\":1,\"remainingCount\":0}]}",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**[PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)chiamata con un evento della versione precedente dello schema**: se una regola è configurata per monitorare questo evento, EventBridge crea un evento quando viene effettuata una PutInventory chiamata che utilizza una versione dello schema precedente allo schema corrente. Questo evento si applica a tutti i tipi di inventario. Di seguito è riportato un modello di evento di esempio.
```
{
"timestampMillis": 1610042629548,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:03:49 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "failed",
"action": "put",
"resource-type": "managed-instance",
"resource-id": "i-01f017c1b2efbe2bc",
"action-reason": "The inventory item with type name Custom:MyCustomInventoryType was sent with a disabled schema verison 1.0. You must send a version greater than 1.0",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
Per informazioni su come EventBridge configurare il monitoraggio di questi eventi, vedere[Configurazione EventBridge per gli eventi di Systems Manager](monitoring-systems-manager-events.md).
# Configurazione della raccolta dell'inventario
Questa sezione descrive come configurare la raccolta AWS Systems Manager dell'inventario su uno o più nodi gestiti utilizzando la console Systems Manager. Per un esempio di come configurare la raccolta dell'inventario utilizzando AWS Command Line Interface (AWS CLI), vedere[Utilizzo di AWS CLI per configurare la raccolta dei dati di inventario](inventory-collection-cli.md).
Quando configuri la raccolta dell'inventario, inizi con la creazione di un' AWS Systems Manager State Managerassociazione. Systems Manager raccoglie i dati di inventario quando viene eseguita l'associazione. Se non create prima l'associazione e tentate di richiamare il `aws:softwareInventory` plugin utilizzando, ad esempio AWS Systems Manager Run Command, il sistema restituisce il seguente errore: `The aws:softwareInventory plugin can only be invoked via ssm-associate.`
**Nota**
Tenere presente il comportamento seguente se si creano più associazioni di inventario per un nodo gestito.
A ogni nodo può essere assegnata un'associazione di inventario destinata a *tutti i* nodi (--targets «Key=InstanceIds, Values=\$1»).
A ogni nodo può anche essere assegnata un'associazione specifica che utilizza key/value coppie di tag o un gruppo di risorse. AWS
Se a un nodo vengono assegnate più associazioni d'inventario, lo stato mostra *Saltato* per l'associazione che non è stata eseguita. L'associazione eseguita più di recente visualizza lo stato effettivo dell'associazione d'inventario.
Se a un nodo vengono assegnate più associazioni di inventario e ciascuna utilizza una key/value coppia di tag, tali associazioni di inventario non vengono eseguite sul nodo a causa del conflitto di tag. L'associazione viene ancora eseguita su nodi che non presentano il key/value conflitto di tag.
**Prima di iniziare**
Prima di configurare la raccolta dell'inventario, completa le seguenti attività.
+ Aggiorna AWS Systems Manager SSM Agent i nodi che desideri inventariare. Eseguendo la versione più recente dell'SSM Agent, sei in grado di raccogliere i metadati per tutti i tipi di inventario supportati. Per informazioni su come aggiornare l'SSM Agent mediante State Manager, consulta [Procedura dettagliata: aggiorna SSM Agent automaticamente con AWS CLI](state-manager-update-ssm-agent-cli.md).
+ Verifica di aver completato i requisiti di configurazione per le istanze Amazon Elastic Compute Cloud (Amazon EC2) e le macchine non EC2 in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). Per informazioni, consulta [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md).
+ Per Windows Server i nodi Microsoft, verifica che il nodo gestito sia configurato con Windows PowerShell 3.0 (o versione successiva). SSM Agentutilizza il `ConvertTo-Json` cmdlet in PowerShell per convertire i dati di inventario di Windows Update nel formato richiesto.
+ (Facoltativo) Crea una sincronizzazione dati risorsa per archiviare centralmente i dati dell'inventario in un bucket Amazon S3. La sincronizzazione dati risorsa aggiorna automaticamente i dati centralizzati quando vengono raccolti nuovi dati dell'inventario. Per ulteriori informazioni, consulta [Procedura dettagliata: utilizzo di sincronizzazione dati risorsa per aggregare dati di inventario](inventory-resource-data-sync.md).
+ (Facoltativo) Crea un file JSON per raccogliere un inventario personalizzato. Per ulteriori informazioni, consulta [Utilizzo di inventari personalizzati](inventory-custom.md).
## Fai l'inventario di tutti i nodi gestiti nel tuo Account AWS
Puoi inventariare tutti i nodi gestiti del tuo Account AWS sistema creando un'associazione di inventario globale. Un'associazione di inventario globale effettua le seguenti operazioni:
+ Applica automaticamente la configurazione (associazione) dell'inventario globale a tutti i nodi gestiti esistenti nel tuo Account AWS. i nodi gestiti che dispongono già di un'associazione di inventario vengono ignorate quando l'associazione di inventario globale viene applicata ed è in esecuzione. Quando un nodo viene saltato, il messaggio di stato dettagliato indica `Overridden By Explicit Inventory Association`. Questi nodi vengono ignorate dall'associazione globale, ma continueranno a riportare l'inventario quando eseguono l'associazione di inventario a esse assegnata.
+ Aggiunge automaticamente i nuovi nodi creati nel tuo Account AWS all'associazione di inventario globale.
**Nota**
Se un nodo gestito è configurato per l'associazione di inventario globale e gli viene assegnata un'associazione specifica, l'inventario di Systems Manager declassa l'associazione globale e applica l'associazione specifica.
Le associazioni di inventario globale sono disponibili in SSM Agent 2.0.790.0 o versione successiva. Per informazioni su come aggiornare l'SSM Agent sui tuoi nodi, consulta [Aggiornamento di SSM Agent utilizzando Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
### Configurazione della raccolta dell'inventario con un solo clic (console)
Usa la seguente procedura per configurare Systems Manager Inventory per tutti i nodi gestiti nel tuo Account AWS e in un unico Regione AWS.
**Per configurare tutti i nodi gestiti nella Regione corrente per l'inventario Systems Manager**
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 riquadro di navigazione, seleziona **Inventario**.
1. Nella scheda **Istanze gestite con inventario abilitato**, scegli **Fai clic qui per abilitare l'inventario in tutte le istanze**.
![\[Attivazione dell'inventario di Systems Manager in tutti i nodi gestiti.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-one-click-1.png)
Se l'esito è positivo, la console mostra il seguente messaggio.
![\[Attivazione dell'inventario di Systems Manager in tutti i nodi gestiti.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-one-click-2.png)
A seconda del numero di nodi gestiti nel tuo account, l'applicazione dell'associazione dell'inventario globale può richiedere alcuni minuti. Attendi qualche minuto, quindi aggiorna la pagina. Verifica che l'immagine cambi per confermare il completamento della configurazione dell'inventario in tutti i nodi gestiti.
### Configurazione della raccolta con la console
Questa sezione include informazioni su come configurare l'inventario di Systems Manager per raccogliere metadati dai tuoi nodi gestiti utilizzando la console Systems Manager. Puoi raccogliere rapidamente i metadati da tutti i nodi di uno specifico Account AWS (e da tutti i nodi futuri che potrebbero essere creati in quell'account) oppure puoi raccogliere selettivamente i dati di inventario utilizzando tag o nodo. IDs
**Nota**
Prima di completare questa procedura, verifica se esiste già un'associazione di inventario globale. Se esiste già un'associazione di inventario globale, ogni volta che avvii una nuova istanza, l'associazione viene applicata all’istanza e la nuova istanza viene inserita nell’inventario.
**Per configurare la raccolta dell'inventario**
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 riquadro di navigazione, seleziona **Inventario**.
1. Scegli **Configura inventario**.
1. Nella sezione **Destinazioni**, identifica i nodi in cui si desidera eseguire questa operazione scegliendo una delle seguenti opzioni.
+ **Selezione di tutte le istanze gestite in questo account**: questa opzione seleziona tutti i nodi gestiti per le quali non esiste alcuna associazione di inventario. Se si sceglie questa opzione, i nodi che presentano già associazioni di inventario vengono ignorate durante la raccolta dell'inventario e vengono visualizzate con lo stato **Ignorato** nei risultati dell'inventario. Per ulteriori informazioni, consulta [Fai l'inventario di tutti i nodi gestiti nel tuo Account AWS](#inventory-management-inventory-all).
+ **Specifica di un tag)**: utilizza questa opzione per specificare un singolo tag per identificare i nodi del proprio account da cui raccogliere l'inventario. Se si utilizza un tag, tutti i nodi create in futuro con lo stesso tag verranno riportate nell'inventario. Se esiste un'associazione di inventario con tutti i nodi, utilizzando un tag per selezionare nodi specifici come destinazione per un altro inventario, l'appartenenza dei nodi viene sostituita nel gruppo di destinazione **Tutte le istanze gestite**. I nodi gestiti con il tag specificato vengono ignorati nella futura raccolta dell'inventario da **Tutte le istanze gestite**.
+ **Selezione manuale delle istanze**: utilizza questa opzione per scegliere specifici nodi gestiti nel tuo account. Scegliendo esplicitamente nodi specifici mediante questa opzione vengono sostituite le associazioni di inventario nella destinazione **Tutte le istanze gestite**. Il nodo viene ignorato nella futura raccolta dell'inventario da **Tutte le istanze gestite**.
**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.
1. Nella sezione **Pianificazione**, scegli la frequenza alla quale desideri che il sistema raccolga metadati di inventario dai tuoi nodi.
1. Nella sezione **Parametri**, utilizza gli elenchi per attivare/disattivare vari tipi di raccolte di inventario. Per ulteriori informazioni sulla raccolta dell'inventario dei file e del registro di sistema di Windows, consulta [Utilizzo dell'inventario dei file e del registro di sistema di Windows](inventory-file-and-registry.md).
1. Nella sezione **Avanzate**, scegli **Sincronizza i log di esecuzione dell'inventario in un bucket Amazon S3**, se si desidera memorizzare lo stato di esecuzione dell'associazione in un bucket Amazon S3.
1. Scegli **Configura inventario**. Systems Manager crea un'associazione State Manager ed esegue immediatamente l'inventario sui nodi.
1. Nel pannello di navigazione, scegli **State Manager**. Verificare che sia stata creata una nuova associazione che utilizza il documento `AWS-GatherSoftwareInventory`. La pianificazione dell'associazione utilizza un'espressione della frequenza. Inoltre, verifica che il campo **Stato** indichi **Completato**. Se si sceglie l'opzione **Sincronizza i log di esecuzione dell'inventario in un bucket Amazon S3)**, sarà possibile visualizzare il log dei dati in Amazon S3 dopo qualche minuto. Se desideri visualizzare i dati dell'inventario per un determinato nodo, scegliere **Istanze gestite** nel pannello di navigazione.
1. Scegli un nodo, quindi scegli **Mostra dettagli**.
1. Nella pagina dei dettagli del nodo, scegli **Inventario**. Utilizza gli elenchi **Tipo di inventario** per filtrare l'inventario.
# Esecuzione di query sui dati di inventario da più regioni e account
AWS Systems Manager Inventory si integra con Amazon Athena per aiutarti a interrogare i dati di inventario da Regioni AWS più e. Account AWS L'integrazione con Athena utilizza la sincronizzazione dei dati delle risorse in modo da poter visualizzare i dati di inventario da tutti i nodi gestiti nella pagina **Visualizzazione dettagliata** della AWS Systems Manager console.
**Importante**
Questa funzionalità consente di eseguire la scansione dei dati nel bucket Amazon Simple Storage Service (Amazon S3) e Amazon Athena per AWS Glue interrogare i dati. A seconda della quantità di dati su cui vengono eseguiti il crawling e le query, ti può essere addebitato l'utilizzo di questi servizi. Con AWS Glue, paghi una tariffa oraria, fatturata al secondo, per i crawler (scoperta dei dati) e i processi ETL (elaborazione e caricamento dei dati). Con Athena, i costi addebitati dipendono dalla quantità di dati scansionati da ciascuna query. Ti consigliamo di prendere visione delle linee guida in materia di prezzi per tali servizi prima di utilizzare l'integrazione di Amazon Athena con l'inventario di Systems Manager. Per ulteriori dettagli, consulta [Prezzi di Amazon Athena](https://aws.amazon.com/athena/pricing/) e [AWS Glue Prezzi](https://aws.amazon.com/glue/pricing/).
Puoi visualizzare i dati di inventario nella pagina **Detailed View (Visualizzazione dettagliata)** in tutte le Regioni AWS in cui è disponibile Amazon Athena. Per un elenco delle regioni supportate, consulta [Endpoint del servizio Amazon Athena](https://docs.aws.amazon.com/general/latest/gr/athena.html#athena_region) in *Riferimenti generali di Amazon Web Services*.
**Prima di iniziare**
L'integrazione di Athena utilizza Resource Data Sync. Devi impostare e configurare Resource Data Sync per l'utilizzo di questa funzionalità. Per ulteriori informazioni, consulta [Procedura dettagliata: utilizzo di sincronizzazione dati risorsa per aggregare dati di inventario](inventory-resource-data-sync.md).
Inoltre, tieni presente che la pagina **Visualizzazione dettagliata** mostra i dati di inventario per il *proprietario* del bucket Amazon S3 centralizzato utilizzato da Sincronizzazione dati risorsa. Se non sei il proprietario del bucket Amazon S3 centralizzato, non puoi visualizzare i dati di inventario nella pagina **Visualizzazione dettagliata**.
## Configurazione dell'accesso
Per poter eseguire query e visualizzare i dati da più account e Regioni nella pagina **Visualizzazione dettagliata** nella console Systems Manager, devi prima configurare l'entità IAM con l'autorizzazione alla visualizzazione dei dati.
Se i dati di inventario sono archiviati in un bucket Amazon S3 che utilizza la crittografia AWS Key Management Service (AWS KMS), devi anche configurare l'entità IAM e il ruolo del `Amazon-GlueServiceRoleForSSM` servizio per la crittografia. AWS KMS
**Topics**
+ [
### Configurazione dell'entità IAM per accedere alla pagina Visualizzazione dettagliata
](#systems-manager-inventory-query-iam-user)
+ [
### (Facoltativo) Configura le autorizzazioni per la visualizzazione dei dati AWS KMS crittografati
](#systems-manager-inventory-query-kms)
### Configurazione dell'entità IAM per accedere alla pagina Visualizzazione dettagliata
Di seguito vengono descritte le autorizzazioni minime necessarie per visualizzare i dati di inventario nella pagina **Visualizzazione dettagliata**.
La policy gestita di `AWSQuicksightAthenaAccess`
Il seguente `PassRole` e altri blocchi di autorizzazioni obbligatorie
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGlue",
"Effect": "Allow",
"Action": [
"glue:GetCrawler",
"glue:GetCrawlers",
"glue:GetTables",
"glue:StartCrawler",
"glue:CreateCrawler"
],
"Resource": "*"
},
{
"Sid": "iamPassRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/SSMInventoryGlueRole",
"arn:aws:iam::111122223333:role/SSMInventoryServiceRole"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "glue.amazonaws.com"
}
}
},
{
"Sid": "iamRoleCreation",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:AttachRolePolicy"
],
"Resource": "arn:aws:iam::111122223333:role/*"
},
{
"Sid": "iamPolicyCreation",
"Effect": "Allow",
"Action": "iam:CreatePolicy",
"Resource": "arn:aws:iam::111122223333:policy/*"
}
]
}
```
------
(Facoltativo) Se il bucket Amazon S3 utilizzato per archiviare i dati di inventario è crittografato utilizzando AWS KMS, devi aggiungere anche il seguente blocco alla policy.
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
Per fornire l’accesso, aggiungi autorizzazioni agli utenti, gruppi o ruoli:
+ Utenti e gruppi in: AWS IAM Identity Center
Crea un set di autorizzazioni. Segui le istruzioni riportate nella pagina [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) (Creazione di un set di autorizzazioni) nella *Guida per l’utente di AWS IAM Identity Center *.
+ Utenti gestiti in IAM tramite un provider di identità:
Crea un ruolo per la federazione delle identità. Segui le istruzioni riportate nella pagina [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) della *Guida per l’utente IAM*.
+ Utenti IAM:
+ Crea un ruolo che l’utente possa assumere. Segui le istruzioni riportate nella pagina [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) della *Guida per l’utente IAM*.
+ (Non consigliato) Collega una policy direttamente a un utente o aggiungi un utente a un gruppo di utenti. Segui le istruzioni riportate nella pagina [Aggiunta di autorizzazioni a un utente (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) nella *Guida per l’utente IAM*.
### (Facoltativo) Configura le autorizzazioni per la visualizzazione dei dati AWS KMS crittografati
Se il bucket Amazon S3 utilizzato per archiviare i dati di inventario è crittografato utilizzando AWS Key Management Service (AWS KMS), devi configurare l'entità IAM e il ruolo **GlueServiceRoleForAmazon-SSM** con le `kms:Decrypt` autorizzazioni per la chiave. AWS KMS
**Prima di iniziare**
Per fornire le `kms:Decrypt` autorizzazioni per la AWS KMS chiave, aggiungi il seguente blocco di policy alla tua entità IAM:
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
Se non l'hai già fatto, completa la procedura e aggiungi `kms:Decrypt` le autorizzazioni per la AWS KMS chiave.
Utilizza la seguente procedura per configurare il ruolo **GlueServiceRoleForAmazon-SSM** con `kms:Decrypt` le autorizzazioni per la AWS KMS chiave.
**Per configurare il ruolo **Amazon- GlueServiceRoleFor SSM** con `kms:Decrypt` autorizzazioni**
1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel riquadro di navigazione, scegli **Ruoli**, quindi utilizza il campo di ricerca per individuare il ruolo **GlueServiceRoleForAmazon-SSM**. Viene visualizzata la pagina **Riepilogo**.
1. Utilizza il campo di ricerca per trovare il ruolo **GlueServiceRoleForAmazon-SSM**. Scegli il nome del ruolo. Viene visualizzata la pagina **Riepilogo**.
1. Scegli il nome del ruolo. Viene visualizzata la pagina **Riepilogo**.
1. Scegli **Aggiungi policy in linea**. Viene visualizzata la pagina **Crea policy**.
1. Scegli la scheda **JSON**.
1. Elimina il testo JSON esistente nell'editor, quindi copia e incolla la seguente policy nell'editor JSON.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_ARN"
]
}
]
}
```
------
1. Scegli **Esamina policy**.
1. Nella pagina **Rivedi policy**, immetti un nome nel campo **Nome**.
1. Scegli **Crea policy**.
## Interrogazione dei dati nella pagina di visualizzazione dettagliata inventario
Utilizzare la procedura seguente per visualizzare i dati di inventario da più Regioni AWS e Account AWS nella pagina di **visualizzazione dettagliata** dell'inventario di Systems Manager.
**Importante**
La pagina **Visualizzazione dettagliata** di Inventario è disponibile solo in Regioni AWS che offrono Amazon Athena. Se le seguenti schede non sono visualizzate nella pagina dell'inventario di Systems Manager, significa che Athena non è disponibile nella Regione e non è possibile utilizzare la funzione **Visualizzazione dettagliata** per eseguire query sui dati.
![\[Visualizzazione del pannello di controllo Inventario | Visualizzazione dettagliata | Schede Impostazioni\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
**Per visualizzare i dati di inventario di più regioni e account nella AWS Systems Manager 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 riquadro di navigazione, seleziona **Inventario**.
1. Scegli la scheda **Visualizzazione dettagliata**.
![\[Accesso alla pagina di visualizzazione dettagliata AWS Systems Manager dell'inventario\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-detailed-view.png)
1. Scegli Sincronizzazione dati risorsa per cui eseguire query sui dati.
![\[Visualizzazione dei dati di inventario nella AWS Systems Manager console\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-display-data.png)
1. Nell'elenco **Tipo di inventario**, scegli il tipo di dati di inventario su cui eseguire query, quindi premi Enter.
![\[Scelta del tipo di inventario nella AWS Systems Manager console\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-type.png)
1. Per filtrare i dati, scegli la barra Filtro, quindi seleziona un'opzione del filtro.
![\[Filtraggio dei dati di inventario nella console AWS Systems Manager\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-filter.png)
Puoi utilizzare il pulsante **Esporta in formato CSV** per visualizzare l'attuale set di query in un'applicazione per fogli di calcolo come Microsoft Excel. Puoi anche utilizzare i pulsanti **Cronologia delle query** ed **Esegui query avanzate** per visualizzare i dettagli della cronologia e interagire con i tuoi dati in Amazon Athena.
### Modifica della pianificazione del AWS Glue crawler
AWS Glue per impostazione predefinita, esegue la scansione dei dati di inventario nel bucket centrale Amazon S3 due volte al giorno. Se modifichi frequentemente i tipi di dati da raccogliere sui tuoi nodi, puoi eseguire il crawling dei dati con una frequenza maggiore, come descritto nella procedura seguente.
**Importante**
AWS Glue ti addebita in Account AWS base a una tariffa oraria, fatturata al secondo, per i crawler (rilevamento dei dati) e i processi ETL (elaborazione e caricamento dei dati). Prima di modificare la pianificazione del crawler, visualizza la pagina [Prezzi di AWS Glue](https://aws.amazon.com/glue/pricing/).
**Per modificare la pianificazione del crawler dei dati di inventario**
1. Apri la console all'indirizzo. AWS Glue [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)
1. Nel riquadro di navigazione, selezionare **Crawler**.
1. Nell'elenco dei crawler, scegliere l'opzione accanto al crawler dei dati dell'inventario di Systems Manager. Il nome del crawler utilizza il seguente formato:
`AWSSystemsManager-s3-bucket-name-Region-account_ID`
1. Scegli **Operazione**, quindi **Modifica crawler**.
1. Nel riquadro di navigazione, seleziona **Pianifica**.
1. Nel campo **Espressione Cron**, specifica una nuova pianificazione utilizzando un formato cron. Per ulteriori informazioni sul formato cron, consulta [Pianificazioni basate sul tempo per processi e crawler](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html) nella *Guida per sviluppatori di AWS Glue *.
**Importante**
Puoi mettere in pausa il crawler per evitare di incorrere in addebiti da. AWS Glue Se si sospende il crawler o si modifica la frequenza in modo che venga eseguito meno spesso il crawling dei dati, la pagina **Visualizzazione dettagliata** dell'inventario potrebbe visualizzare dati non aggiornati.
# Esecuzione di query su una raccolta di inventario mediante filtri
Dopo aver raccolto i dati di inventario, puoi utilizzare le funzionalità di filtro AWS Systems Manager per interrogare un elenco di nodi gestiti che soddisfano determinati criteri di filtro.
**Per eseguire query sui nodi in base ai filtri di inventario**
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 riquadro di navigazione, seleziona **Inventario**.
1. Nella sezione **Filter by resource groups, tags or inventory types (Filtra per gruppi di risorse, tag o tipi di inventario)**, scegliere la casella di filtro. Viene visualizzato un elenco di filtri predefiniti.
1. Scegliere un attributo a cui applicare il filtro. Ad esempio, scegli `AWS:Application`. Se richiesto, scegliere un attributo secondario da filtrare. Ad esempio, scegli `AWS:Application.Name`.
1. Scegliere un delimitatore dall'elenco. Ad esempio, scegliere **Begin with (Inizia per)**. Viene visualizzata una casella di testo nel filtro.
1. Inserire un valore nella casella di testo. Ad esempio, inserire *Amazon* (SSM Agent è denominato *Amazon SSM Agent*).
1. Premi Enter. Il sistema restituisce un elenco di nodi gestiti che include il nome di un'applicazione che inizia con la parola *Amazon*.
**Nota**
È possibile combinare più filtri per perfezionare la ricerca.
# Aggregazione dei dati di inventario
Dopo aver configurato i nodi gestiti per AWS Systems Manager Inventory, puoi visualizzare i conteggi aggregati dei dati di inventario. Ad esempio, supponi di aver configurato decine o centinaia di nodi gestiti per raccogliere il tipo di inventario `AWS:Application`. Utilizzando le informazioni contenute in questa sezione, puoi visualizzare il numero esatto di nodi configurati per raccogliere questi dati.
Puoi anche visualizzare dettagli di Inventory specifici aggregando un tipo di dati. Ad esempio, il tipo di inventario `AWS:InstanceInformation` raccoglie informazioni sulla piattaforma del sistema operativo con il tipo di dati `Platform`. Aggregando i dati nel tipo di dati `Platform`, puoi visualizzare rapidamente quanti nodi eseguono Windows Server, quanti eseguono Linux e macOS.
Le procedure in questa sezione descrivono come visualizzare i conteggi aggregati dei dati di inventario utilizzando AWS Command Line Interface ()AWS CLI. **Puoi anche visualizzare i conteggi aggregati preconfigurati nella AWS Systems Manager console nella pagina Inventario.** Questi pannelli di controllo preconfigurati sono denominati *informazioni di inventario* e offrono sistemi di correzione con un solo clic per i problemi di configurazione di Inventario.
Nota i seguenti dettagli importanti relativi ai conteggi di aggregazione dei dati di Inventario:
+ Se si chiude un nodo gestito per la raccolta dei dati di inventario, Systems Manager conserva i dati di inventario per 30 giorni, quindi li elimina. Per i nodi in esecuzione, il sistema elimina i dati di inventario con più di 30 giorni. Se devi archiviare i dati di inventario per più di 30 giorni, puoi utilizzarli AWS Config per registrare la cronologia o interrogare e caricare periodicamente i dati su un bucket Amazon Simple Storage Service (Amazon S3).
+ Se un nodo è stato configurato in precedenza per riportare un determinato tipo di dati di Inventory, ad esempio `AWS:Network`, e in seguito decidi di modificare la configurazione per interrompere la raccolta di quel tipo di dati, i conteggi di aggregazione mostreranno ancora i dati `AWS:Network` finché il nodo non verrà terminato e non saranno passati 30 giorni.
Per informazioni su come configurare e raccogliere rapidamente i dati di inventario da tutti i nodi di uno specifico Account AWS (e da eventuali nodi futuri che potrebbero essere creati in quell'account), consulta[Fai l'inventario di tutti i nodi gestiti nel tuo Account AWS](inventory-collection.md#inventory-management-inventory-all).
**Topics**
+ [
## Aggregazione dei dati di inventario per visualizzare il numero di nodi che raccolgono specifici tipi di dati
](#inventory-aggregate-type)
+ [
## Aggregazione dei dati di inventario con i gruppi per vedere i nodi configurate o non configurate per raccogliere un tipo di inventario
](#inventory-aggregate-groups)
## Aggregazione dei dati di inventario per visualizzare il numero di nodi che raccolgono specifici tipi di dati
Puoi utilizzare l'operazione AWS Systems Manager [GetInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetInventory.html)API per visualizzare i conteggi aggregati di nodi che raccolgono uno o più tipi di inventario e tipi di dati. Ad esempio, il tipo di `AWS:InstanceInformation` inventario consente di visualizzare un aggregato di sistemi operativi utilizzando l'operazione GetInventory API con il tipo di `AWS:InstanceInformation.PlatformType` dati. Di seguito è riportato un esempio di comando e output AWS CLI :
```
aws ssm get-inventory --aggregators "Expression=AWS:InstanceInformation.PlatformType"
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Entities":[
{
"Data":{
"AWS:InstanceInformation":{
"Content":[
{
"Count":"7",
"PlatformType":"windows"
},
{
"Count":"5",
"PlatformType":"linux"
}
]
}
}
}
]
}
```
**Nozioni di base**
Determina i tipi di Inventory e i tipi di dati di cui desideri visualizzare i conteggi. Puoi visualizzare un elenco dei tipi di inventario e dei tipi di dati che supportano l'aggregazione eseguendo questo comando in AWS CLI.
```
aws ssm get-inventory-schema --aggregator
```
Il comando restituisce un elenco JSON dei tipi di Inventory e dei tipi di dati che supportano l'aggregazione. Il **TypeName**campo mostra i tipi di inventario supportati. Il campo **Nome** mostra ogni tipo di dati. Ad esempio, nell'elenco seguente, il tipo di Inventory `AWS:Application` include tipi di dati per `Name` e `Version`.
```
{
"Schemas": [
{
"TypeName": "AWS:Application",
"Version": "1.1",
"DisplayName": "Application",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "Version"
}
]
},
{
"TypeName": "AWS:InstanceInformation",
"Version": "1.0",
"DisplayName": "Platform",
"Attributes": [
{
"DataType": "STRING",
"Name": "PlatformName"
},
{
"DataType": "STRING",
"Name": "PlatformType"
},
{
"DataType": "STRING",
"Name": "PlatformVersion"
}
]
},
{
"TypeName": "AWS:ResourceGroup",
"Version": "1.0",
"DisplayName": "ResourceGroup",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
}
]
},
{
"TypeName": "AWS:Service",
"Version": "1.0",
"DisplayName": "Service",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "ServiceType"
},
{
"DataType": "STRING",
"Name": "Status"
},
{
"DataType": "STRING",
"Name": "StartType"
}
]
},
{
"TypeName": "AWS:WindowsRole",
"Version": "1.0",
"DisplayName": "WindowsRole",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "FeatureType"
},
{
"DataType": "STRING",
"Name": "Installed"
}
]
}
]
}
```
Puoi aggregare i dati per tutti i tipi di Inventory elencati creando un comando che utilizzi la sintassi seguente:
```
aws ssm get-inventory --aggregators "Expression=InventoryType.DataType"
```
Ecco alcuni esempi.
**Esempio 1**
Questo esempio aggrega il conteggio dei ruoli Windows utilizzati dai tuoi nodi.
```
aws ssm get-inventory --aggregators "Expression=AWS:WindowsRole.Name"
```
**Esempio 2**
Questo esempio aggrega il conteggio delle applicazioni installate nei tuoi nodi.
```
aws ssm get-inventory --aggregators "Expression=AWS:Application.Name"
```
**Combinazione di più aggregatori**
È possibile anche combinare più tipi di Inventory e tipi di dati in un unico comando per aiutarti a comprendere meglio i dati. Ecco alcuni esempi.
**Esempio 1**
Questo esempio aggrega il conteggio dei sistemi operativi utilizzati dai tuoi nodi. Restituisce inoltre il nome specifico dei sistemi operativi.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:InstanceInformation.PlatformType", "Aggregators":[{"Expression": "AWS:InstanceInformation.PlatformName"}]}]'
```
**Esempio 2**
Questo esempio aggrega il conteggio delle applicazioni in esecuzione sui tuoi nodi e la versione specifica di ciascuna applicazione.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:Application.Name", "Aggregators":[{"Expression": "AWS:Application.Version"}]}]'
```
Se preferisci, puoi creare un'espressione di aggregazione con uno o più tipi di Inventory e tipi di dati in un file JSON e richiamare il file tramite AWS CLI. Il file JSON deve utilizzare la seguente sintassi:
```
[
{
"Expression": "string",
"Aggregators": [
{
"Expression": "string"
}
]
}
]
```
Devi salvare il file con l'estensione .json.
Di seguito è riportato un esempio che utilizza più tipi di Inventory e tipi di dati.
```
[
{
"Expression": "AWS:Application.Name",
"Aggregators": [
{
"Expression": "AWS:Application.Version",
"Aggregators": [
{
"Expression": "AWS:InstanceInformation.PlatformType"
}
]
}
]
}
]
```
Utilizza il comando seguente per richiamare il file tramite AWS CLI.
```
aws ssm get-inventory --aggregators file://file_name.json
```
Il comando restituisce informazioni simili alle seguenti.
```
{"Entities":
[
{"Data":
{"AWS:Application":
{"Content":
[
{"Count": "3",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "4",
"PlatformType": "windows",
"Version": "6.2.8",
"Name": "microsoft office"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "1",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "2",
"PlatformType": "linux",
"Version": "6.3",
"Name": "authconfig"}
]
}
},
"ResourceType": "ManagedInstance"}
]
}
```
## Aggregazione dei dati di inventario con i gruppi per vedere i nodi configurate o non configurate per raccogliere un tipo di inventario
I gruppi in Inventory di Systems Manager ti consentono di vedere rapidamente il numero di nodi gestiti che sono o meno configurati per raccogliere uno o più tipi di Inventory. Con i gruppi, devi specificare uno o più tipi di Inventory nonché un filtro che utilizzi l'operatore `exists`.
Ad esempio, supponi di disporre di quattro nodi gestiti, configurati per raccogliere i seguenti tipi di Inventory:
+ Nodo 1: `AWS:Application`
+ Nodo 2: `AWS:File`
+ Nodo 3: `AWS:Application`, `AWS:File`
+ Nodo 4: `AWS:Network`
Puoi eseguire il seguente comando da AWS CLI per vedere quanti nodi sono configurati per raccogliere entrambi `AWS:Application` i `AWS:File inventory` tipi. La risposta restituisce anche il numero di nodi non configurati per raccogliere questi tipi di Inventory.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationAndFile,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists},{Key=TypeName,Values=[AWS:File],Type=Exists}]}]'
```
La risposta del comando mostra che è configurata un solo nodo gestito per raccogliere entrambi i tipi di Inventory, `AWS:Application` e `AWS:File`.
```
{
"Entities":[
{
"Data":{
"ApplicationAndFile":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
**Nota**
I gruppi non restituiscono il conteggio dei tipi di dati. Inoltre, non puoi approfondire i risultati per vedere i IDs nodi che sono o non sono configurati per raccogliere il tipo di inventario.
Se preferisci, puoi creare un'espressione di aggregazione con uno o più tipi di Inventory in un file JSON e richiamare il file tramite AWS CLI. Il file JSON deve utilizzare la seguente sintassi:
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Name",
"Filters":[
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
},
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Devi salvare il file con l'estensione .json.
Utilizza il comando seguente per richiamare il file tramite AWS CLI.
```
aws ssm get-inventory --cli-input-json file://file_name.json
```
**Esempi aggiuntivi**
I seguenti esempi illustrano come aggregare dati di Inventory per vedere quali nodi gestiti sono o meno configurati per raccogliere i tipi di Inventory specificati. Questi esempi utilizzano AWS CLI. Ogni esempio include un comando completo con filtri, eseguibile dalla riga di comando, e un file di esempio input.json, nel caso tu preferisca inserire le informazioni in un file.
**Esempio 1**
Questo esempio aggrega il conteggio dei nodi configurate o meno per raccogliere il tipo di Inventory `AWS:Application` oppure `AWS:File`.
Utilizza il comando seguente da AWS CLI.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationORFile,Filters=[{Key=TypeName,Values=[AWS:Application, AWS:File],Type=Exists}]}]'
```
Se preferisci utilizzare un file, copia e incolla il seguente esempio in un file e salvalo come input.json.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"ApplicationORFile",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application",
"AWS:File"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Utilizza il comando seguente da AWS CLI.
```
aws ssm get-inventory --cli-input-json file://input.json
```
Il comando restituisce informazioni simili alle seguenti.
```
{
"Entities":[
{
"Data":{
"ApplicationORFile":{
"Content":[
{
"notMatchingCount":"1"
},
{
"matchingCount":"3"
}
]
}
}
}
]
}
```
**Esempio 2**
Questo esempio aggrega il conteggio dei nodi configurati o meno per raccogliere i tipi di inventario `AWS:Application`, `AWS:File` e `AWS:Network`.
Utilizza il comando seguente da AWS CLI.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=Application,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists}]}, {Name=File,Filters=[{Key=TypeName,Values=[AWS:File],Type=Exists}]}, {Name=Network,Filters=[{Key=TypeName,Values=[AWS:Network],Type=Exists}]}]'
```
Se preferisci utilizzare un file, copia e incolla il seguente esempio in un file e salvalo come input.json.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Application",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application"
],
"Type":"Exists"
}
]
},
{
"Name":"File",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:File"
],
"Type":"Exists"
}
]
},
{
"Name":"Network",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Network"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Utilizza il comando seguente da AWS CLI.
```
aws ssm get-inventory --cli-input-json file://input.json
```
Il comando restituisce informazioni simili alle seguenti.
```
{
"Entities":[
{
"Data":{
"Application":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"File":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"Network":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
# Utilizzo di inventari personalizzati
*Puoi assegnare tutti i metadati che desideri ai tuoi nodi creando AWS Systems Manager un inventario personalizzato di Inventory.* Ad esempio, supponiamo che tu gestisca un numero elevato di server nel tuo data center e che i server siano stati configurati come nodi gestiti da Systems Manager. Attualmente, le informazioni relative alla posizione del rack dei server vengono archiviate in un foglio di calcolo. Con l'inventario personalizzato, puoi specificare la posizione del rack di ciascun nodo come metadati del nodo. Quando raccogli l'inventario con Systems Manager, i metadati vengono raccolti con altri metadati di inventario. Puoi poi trasferire tutti i metadati di inventario in un bucket Amazon S3 centralizzato utilizzando [Resource Data Sync](inventory-resource-data-sync.html) ed eseguendo una query sui dati.
**Nota**
Systems Manager supporta un massimo di 20 tipi di inventario personalizzati per Account AWS.
Per assegnare un inventario personalizzato a un nodo, è possibile utilizzare l'operazione dell'[PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API Systems Manager, come descritto in[Assegnazione di metadati di inventario personalizzati a un nodo gestito](inventory-custom-metadata.md). In alternativa, puoi creare e caricare nel nodo un file JSON dell'inventario personalizzato. Questa sezione descrive come creare il file JSON.
Il file JSON di esempio seguente con inventario personalizzato specifica le informazioni rack relative a un server on-premises. Questo esempio specifica un tipo di dati di inventario personalizzato (`"TypeName": "Custom:RackInformation"`), con più voci in `Content` che descrivono i dati.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:RackInformation",
"Content": {
"Location": "US-EAST-02.CMH.RACK1",
"InstalledTime": "2016-01-01T01:01:01Z",
"vendor": "DELL",
"Zone" : "BJS12",
"TimeZone": "UTC-8"
}
}
```
Puoi anche specificare voci distinte nella sezione `Content`, come mostrato nell'esempio seguente.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:PuppetModuleInfo",
"Content": [{
"Name": "puppetlabs/aws",
"Version": "1.0"
},
{
"Name": "puppetlabs/dsc",
"Version": "2.0"
}
]
}
```
Lo schema JSON per l'inventario personalizzato richiede le sezioni `SchemaVersion`, `TypeName` e `Content`, in cui puoi definire le informazioni.
```
{
"SchemaVersion": "user_defined",
"TypeName": "Custom:user_defined",
"Content": {
"user_defined_attribute1": "user_defined_value1",
"user_defined_attribute2": "user_defined_value2",
"user_defined_attribute3": "user_defined_value3",
"user_defined_attribute4": "user_defined_value4"
}
}
```
Il valore di `TypeName` è limitato a 100 caratteri. Inoltre, il valore di `TypeName` deve iniziare con la parola `Custom` in maiuscolo. Ad esempio, `Custom:PuppetModuleInfo`. Pertanto, i seguenti esempi costituirebbero un'eccezione: `CUSTOM:PuppetModuleInfo`, `custom:PuppetModuleInfo`.
La `Content` sezione include attributi e*data*. Questi elementi non prevedono alcuna distinzione tra maiuscole e minuscole. Tuttavia, se definisci un attributo (ad esempio: "`Vendor`": "DELL"), sarà necessario fare riferimento a tale attributo in modo coerente nei tuoi file dell'inventario personalizzato. Se specifichi "`Vendor`": "DELL" (utilizzando la maiuscola "V" in `vendor`) in un file e quindi specifichi "`vendor`": "DELL" (utilizzando la minuscola "v" in `vendor`) in un altro file, il sistema restituisce un errore.
**Nota**
È necessario salvare il file con estensione `.json` e l'inventario definito deve essere costituito solo da valori stringa.
Dopo aver creato il file, devi salvarlo nel nodo. La tabella riportata di seguito mostra il percorso in cui devono essere archiviati i file JSON dell'inventario personalizzato nel nodo.
****
| Sistema operativo | Path |
| --- | --- |
| Linux | /var/lib/amazon/ssm/*node-id*/inventory/custom |
| macOS | `/opt/aws/ssm/data/node-id/inventory/custom` |
| Windows Server | %SystemDrive%\$1ProgramData\$1 Amazon\$1 SSM\$1\$1 InstanceData*node-id*\$1 inventario\$1 personalizzato |
Per un esempio di come utilizzare l'inventario personalizzato, consulta [Get Disk Utilization of Your Fleet Using EC2 Systems Manager Custom Inventory Types](https://aws.amazon.com/blogs/mt/get-disk-utilization-of-your-fleet-using-ec2-systems-manager-custom-inventory-types/).
## Eliminazione di un inventario personalizzato
Puoi utilizzare l'operazione [DeleteInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeleteInventory.html)API per eliminare un tipo di inventario personalizzato e i dati associati a quel tipo. Puoi richiamare il comando delete-inventory tramite AWS Command Line Interface (AWS CLI) per eliminare tutti i dati di un tipo di inventario. Puoi richiamare il comando delete-inventory tramite `SchemaDeleteOption` per eliminare un tipo di inventario personalizzato.
**Nota**
Il tipo di inventario viene chiamato anche schema di inventario.
Il parametro `SchemaDeleteOption` include le seguenti opzioni:
+ **DeleteSchema**: Questa opzione elimina il tipo personalizzato specificato e tutti i dati ad esso associati. Puoi ricreare lo schema in un secondo momento, se lo desideri.
+ **DisableSchema**: Se si sceglie questa opzione, il sistema disattiva la versione corrente, elimina tutti i relativi dati e ignora tutti i nuovi dati se la versione è inferiore o uguale alla versione disattivata. Puoi consentire nuovamente questo tipo di inventario chiamando l'[PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)azione per una versione successiva alla versione disattivata.
**Per eliminare o disattivare l'inventario personalizzato utilizzando il AWS CLI**
1. 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).
1. Eseguire questo comando per utilizzare l'opzione `dry-run` per vedere quali dati verranno eliminati dal sistema. Questo comando non elimina alcun dato.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --dry-run
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
Per informazioni su come comprendere il riepilogo di eliminazione dell'inventario, consultare [Comprendere il riepilogo di eliminazione dell'inventario](#delete-custom-inventory-summary).
1. Eseguire questo comando per eliminare tutti i dati di un tipo di inventario personalizzato.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name"
```
**Nota**
L'output di questo comando non mostra l'avanzamento dell'eliminazione. Per questo motivo, TotalCount e Remaining Count sono sempre gli stessi perché il sistema non ha ancora eliminato nulla. È possibile utilizzare il describe-inventory-deletions comando per mostrare l'avanzamento dell'eliminazione, come descritto più avanti in questo argomento.
Il sistema restituisce informazioni simili alle seguenti.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"custom_type_name"
}
```
Il sistema elimina dal servizio Inventory di Systems Manager tutti i dati del tipo di inventario personalizzato specificato.
1. Eseguire il seguente comando seguente. Il comando esegue le operazioni seguenti per la versione corrente del tipo di inventario: disattiva la versione corrente, elimina tutti i dati e ignora tutti i nuovi dati se la versione è inferiore o uguale a quella disattivata.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DisableSchema"
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
È possibile visualizzare un tipo di inventario disattivato utilizzando il comando seguente.
```
aws ssm get-inventory-schema --type-name Custom:custom_type_name
```
1. Eseguire questo comando per eliminare un tipo di inventario.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DeleteSchema"
```
Il sistema elimina lo schema e tutti i dati del tipo di inventario personalizzato specificato.
Il sistema restituisce informazioni simili alle seguenti.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
### Visualizzazione dello stato dell'eliminazione
È possibile controllare lo stato di un'operazione di eliminazione utilizzando il `describe-inventory-deletions` AWS CLI comando. Puoi specificare un ID di eliminazione per visualizzare lo stato di una determinata operazione di eliminazione. In alternativa, puoi omettere l'ID di eliminazione per visualizzare un elenco di tutte le eliminazioni eseguite negli ultimi 30 giorni.
****
1. Eseguire questo comando per visualizzare lo stato di un'operazione di eliminazione. Il sistema restituisce l'ID di eliminazione nel riepilogo delete-inventory.
```
aws ssm describe-inventory-deletions --deletion-id system_generated_deletion_ID
```
Il sistema restituisce lo stato più recente. L'operazione di eliminazione potrebbe non essere ancora completata. Il sistema restituisce informazioni simili alle seguenti.
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 1,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 1,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "InProgress",
"LastStatusMessage": "The Delete is in progress",
"LastStatusUpdateTime": 1521744844,
"TypeName": "Custom:custom_type_name"}
]
}
```
Se l'operazione di eliminazione viene completata correttamente, `LastStatusMessage` indica "Deletion is successful".
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"}
]
}
```
1. Eseguire questo comando per visualizzare un elenco di tutte le eliminazioni effettuate negli ultimi 30 giorni.
```
aws ssm describe-inventory-deletions --max-results a number
```
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521682552,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521682852,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521680145,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521680471,
"TypeName": "Custom:custom_type_name"}
],
"NextToken": "next-token"
```
### Comprendere il riepilogo di eliminazione dell'inventario
Per poter comprendere i contenuti del riepilogo di eliminazione dell'inventario, prendi in considerazione l'esempio seguente. Un utente assegnato a Custom: RackSpace inventario su tre nodi. Gli articoli 1 e 2 dell'inventario utilizzano la versione 1.0 di tipo personalizzato (» SchemaVersion «:"1.0"). L'articolo 3 dell'inventario utilizza la versione 2.0 di tipo personalizzato (» SchemaVersion «:"2.0").
RackSpace inventario personalizzato 1
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567890",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace inventario personalizzato 2
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567891",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace inventario personalizzato 3
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567892",
"SchemaVersion":"2.0" "Content":[
{
content of custom type omitted
}
]
}
```
L'utente esegue il comando seguente per visualizzare in anteprima i dati che saranno eliminati.
```
aws ssm delete-inventory --type-name "Custom:RackSpace" --dry-run
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"DeletionId":"1111-2222-333-444-66666",
"DeletionSummary":{
"RemainingCount":3,
"TotalCount":3,
TotalCount and RemainingCount are the number of items that would be deleted if this was not a dry run. These numbers are the same because the system didn't delete anything.
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0. Neither item was deleted.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 1.0. This item was not deleted.
"RemainingCount":1,
"Version":"2.0"
}
],
},
"TypeName":"Custom:RackSpace"
}
```
L'utente esegue il seguente comando per eliminare Custom: RackSpace inventory.
**Nota**
L'output di questo comando non mostra l'avanzamento dell'eliminazione. Per questo motivo, `TotalCount` e `RemainingCount` restano invariati, dato che il sistema non ha ancora effettuato eliminazioni. Puoi utilizzare il comando `describe-inventory-deletions` per visualizzare l'avanzamento dell'eliminazione.
```
aws ssm delete-inventory --type-name "Custom:RackSpace"
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"DeletionId":"1111-2222-333-444-7777777",
"DeletionSummary":{
"RemainingCount":3, There are three items to delete
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 2.0.
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"RackSpace"
}
```
### Visualizzazione delle azioni di eliminazione dell'inventario in EventBridge
Puoi configurare Amazon EventBridge per creare un evento ogni volta che un utente elimina l'inventario personalizzato. EventBridge offre tre tipi di eventi per le operazioni personalizzate di eliminazione dell'inventario:
+ **Operazione di eliminazione per un'istanza**: indica se l'inventario personalizzato per un determinato nodo gestito è stato eliminato o meno.
+ **Riepilogo dell'operazione di eliminazione**: un riepilogo dell'operazione di eliminazione.
+ **Avviso per la disattivazione del tipo di inventario personalizzato**: un evento di avviso se un utente ha chiamato l'operazione [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API per una versione del tipo di inventario personalizzato che era stata precedentemente disattivata.
Di seguito sono riportati gli esempi di ciascun evento:
**Operazione di eliminazione per un'istanza**
```
{
"version":"0",
"id":"998c9cde-56c0-b38b-707f-0411b3ff9d11",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:24:34Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0a5feb270fc3f0b97"
],
"detail":{
"action-status":"succeeded",
"action":"delete",
"resource-type":"managed-instance",
"resource-id":"i-0a5feb270fc3f0b97",
"action-reason":"",
"type-name":"Custom:MyInfo"
}
}
```
**Riepilogo dell'operazione di eliminazione**
```
{
"version":"0",
"id":"83898300-f576-5181-7a67-fb3e45e4fad4",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:28:25Z",
"region":"us-east-1",
"resources":[
],
"detail":{
"action-status":"succeeded",
"action":"delete-summary",
"resource-type":"managed-instance",
"resource-id":"",
"action-reason":"The delete for type name Custom:MyInfo was completed. The deletion summary is: {\"totalCount\":2,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.0\",\"count\":2,\"remainingCount\":0}]}",
"type-name":"Custom:MyInfo"
}
}
```
**Avviso per il tipo di inventario personalizzato disattivato**
```
{
"version":"0",
"id":"49c1855c-9c57-b5d7-8518-b64aeeef5e4a",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:46:58Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0ee2d86a2cfc371f6"
],
"detail":{
"action-status":"failed",
"action":"put",
"resource-type":"managed-instance",
"resource-id":"i-0ee2d86a2cfc371f6",
"action-reason":"The inventory item with type name Custom:MyInfo was sent with a disabled schema version 1.0. You must send a version greater than 1.0",
"type-name":"Custom:MyInfo"
}
}
```
Utilizza la procedura seguente per creare una EventBridge regola per le operazioni personalizzate di eliminazione dell'inventario. Questa procedura illustra come creare una regola che invia notifiche per le operazioni di eliminazione di inventari personalizzati a un argomento Amazon SNS. Prima di iniziare, verifica di avere un argomento Amazon SNS o creane uno nuovo. Per ulteriori informazioni, consulta [Nozioni di base](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html) nella *Guida per gli sviluppatori di Amazon Simple Notification Service*.
**EventBridge Per configurare le operazioni di eliminazione dell'inventario**
1. Apri la EventBridge console Amazon all'indirizzo [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Nel pannello di navigazione, scegli **Regole**.
1. Scegli **Crea regola**.
1. Inserisci un nome e una descrizione per la regola.
Una regola non può avere lo stesso nome di un'altra regola nella stessa Regione e sullo stesso router di eventi.
1. Per **Router di eventi**, seleziona il router di eventi che desideri associare a questa regola. Se desideri che questa regola risponda agli eventi corrispondenti generati dai tuoi Account AWS, seleziona **Predefinito**. Quando un Servizio AWS utente del tuo account emette un evento, questo passa sempre al bus eventi predefinito del tuo account.
1. Per **Tipo di regola**, scegli **Regola con un modello di eventi**.
1. Scegli **Next (Successivo)**.
1. Per **Event source**, scegli **AWS eventi o eventi EventBridge partner**.
1. Nella sezione **Modello di eventi**, scegli **Modulo di modello di eventi**.
1. Per **Origine evento**, scegli **Servizi AWS **.
1. Per **AWS **, scegli **Systems Manager**.
1. Per **Tipo di evento**, scegli **Inventario**.
1. Per **Tipi di dettagli specifici**, scegli **Modifica dello stato della risorsa inventario**.
1. Scegli **Next (Successivo)**.
1. Per **Tipi di destinazione**, scegli **Servizio AWS **.
1. Per **Seleziona una destinazione**, scegli **Argomento SNS**, quindi scegli l'argomento dall'elenco **Argomento**.
1. Nella sezione **Impostazioni aggiuntive**, per **Configura l'input di destinazione**, verifica che sia selezionato **Evento abbinato**.
1. Scegli **Next (Successivo)**.
1. (Facoltativo) Inserire uno o più tag per la regola. Per ulteriori informazioni, consulta [Tagging Your Amazon EventBridge Resources](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html) nella *Amazon EventBridge User Guide*.
1. Scegli **Next (Successivo)**.
1. Rivedi i dettagli della regola e scegli **Crea regola**.
# Visualizzazione della cronologia e del monitoraggio delle modifiche di Inventory
Puoi visualizzare la cronologia AWS Systems Manager dell'inventario e il monitoraggio delle modifiche per tutti i tuoi nodi gestiti utilizzando [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/). AWS Config fornisce una visualizzazione dettagliata della configurazione delle AWS risorse nel tuo Account AWS. Questo include le relazioni tra le risorse e la maniera in cui sono state configurate in passato, in modo che tu possa vedere come le configurazioni e le relazioni cambiano nel corso del tempo. Per visualizzare la cronologia e il monitoraggio delle modifiche dell'inventario, devi attivare le risorse seguenti in AWS Config:
+ SSM: ManagedInstanceInventory
+ SSM: PatchCompliance
+ SSM: AssociationCompliance
+ SSM: FileData
**Nota**
Tieni presente le informazioni importanti sulla cronologia dell'inventario e sul monitoraggio delle modifiche riportate di seguito.
Se si utilizza AWS Config per tenere traccia delle modifiche nel sistema, è necessario configurare Systems Manager Inventory per raccogliere `AWS:File` i metadati in modo da poter visualizzare le modifiche ai file in AWS Config (`SSM:FileData`). Se non lo fai, allora AWS Config non tiene traccia delle modifiche ai file sul tuo sistema.
Attivando SSM: PatchCompliance e SSM:AssociationCompliance, è possibile visualizzare la cronologia di conformità delle Patch Manager patch di Systems Manager e delle State Manager associazioni Systems Manager e il tracciamento delle modifiche. Per ulteriori informazioni sulla gestione della conformità per queste risorse, consulta [Scopri i dettagli sulla conformità](compliance-about.md).
La procedura seguente descrive come attivare la cronologia dell'inventario e la registrazione delle modifiche AWS Config utilizzando (). AWS Command Line Interface AWS CLI Per ulteriori informazioni su come scegliere e configurare queste risorse in AWS Config, consulta [Selezione dei AWS Config record di risorse nella Guida](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html) per gli *AWS Config sviluppatori*. Per informazioni sui prezzi di AWS Config , consulta la pagina dei [prezzi di ](https://aws.amazon.com/config/pricing/).
**Prima di iniziare**
AWS Config richiede le autorizzazioni AWS Identity and Access Management (IAM) per ottenere dettagli di configurazione sulle risorse di Systems Manager. Nella procedura seguente, è necessario specificare un Amazon Resource Name (ARN) per un ruolo IAM che AWS Config autorizza le risorse di Systems Manager. Puoi collegare la policy gestita `AWS_ConfigRole` al ruolo IAM assegnato a AWS Config. Per ulteriori informazioni su questo ruolo, consulta [AWS managed policy: AWS\$1 ConfigRole](https://docs.aws.amazon.com/config/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AWS_ConfigRole) nella *AWS Config Developer Guide*. Per informazioni su come creare un ruolo IAM e assegnare la policy gestita `AWS_ConfigRole` a tale ruolo, consulta [Creazione di un ruolo per delegare le autorizzazioni a un Servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *Guida per l'utente IAM*.
**Per attivare la cronologia dell'inventario e la registrazione delle modifiche in AWS Config**
1. 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).
1. Copiare e incollare i seguenti esempi JSON in un file di testo semplice e salvarlo come recordingGroup.json.
```
{
"allSupported":false,
"includeGlobalResourceTypes":false,
"resourceTypes":[
"AWS::SSM::AssociationCompliance",
"AWS::SSM::PatchCompliance",
"AWS::SSM::ManagedInstanceInventory",
"AWS::SSM::FileData"
]
}
```
1. Eseguire questo comando per caricare il file recordingGroup.json in AWS Config.
```
aws configservice put-configuration-recorder --configuration-recorder name=myRecorder,roleARN=arn:aws:iam::123456789012:role/myConfigRole --recording-group file://recordingGroup.json
```
1. Eseguire questo comando per avviare la registrazione della cronologia e del monitoraggio delle modifiche di Inventory.
```
aws configservice start-configuration-recorder --configuration-recorder-name myRecorder
```
Dopo aver configurato la cronologia e il monitoraggio delle modifiche, è possibile eseguire il drill-down della cronologia per un determinato nodo gestito scegliendo il pulsante **AWS Config** nella console Systems Manager. Puoi accedere al pulsante **AWS Config** dalla pagina **Istanze gestite** o dalla pagina **Inventario**. A seconda delle dimensioni del monitor, potresti dover scorrere la pagina verso destra per visualizzare il pulsante.
# Interruzione della raccolta dati ed eliminazione dei dati di inventario
Se non desideri più utilizzare AWS Systems Manager Inventory per visualizzare i metadati relativi alle tue AWS risorse, puoi interrompere la raccolta dei dati ed eliminare i dati che sono già stati raccolti. Questa sezione include le seguenti informazioni.
**Topics**
+ [
## Interruzione della raccolta dei dati
](#systems-manager-inventory-delete-association)
+ [
## Eliminazione di un Resource Data Sync di Inventory
](#systems-manager-inventory-delete-RDS)
## Interruzione della raccolta dei dati
Quando si configura inizialmente Systems Manager per la raccolta dei dati di inventario, il sistema crea un'associazione State Manager che definisce la pianificazione e le risorse da cui raccogliere i metadati. È possibile interrompere la raccolta dei dati eliminando qualsiasi associazione State Manager che utilizza il documento `AWS-GatherSoftwareInventory`.
**Eliminazione di un'associazione Inventory**
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 **State Manager**.
1. Scegliere un'associazione che utilizzi il documento `AWS-GatherSoftwareInventory` e quindi scegliere **Delete (Elimina)**.
1. Ripetere il passaggio tre per tutte le associazioni rimanenti che utilizzano il documento `AWS-GatherSoftwareInventory`.
## Eliminazione di un Resource Data Sync di Inventory
Se non desideri più utilizzare AWS Systems Manager Inventory per visualizzare i metadati relativi alle tue AWS risorse, ti consigliamo anche di eliminare le sincronizzazioni dei dati delle risorse utilizzate per la raccolta dei dati di inventario.
**Eliminare un Resource Data Sync di Inventory**
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 riquadro di navigazione, seleziona **Inventario**.
1. Scegliere **Resource Data Syncs (Sincronizzazioni dati risorsa)**.
1. Scegliere una sincronizzazione dall'elenco.
**Importante**
Assicurati di scegliere la sincronizzazione utilizzata per Inventory. Systems Manager supporta la sincronizzazione dei dati delle risorse per molteplici strumenti. Se si sceglie la sincronizzazione errata, è possibile interrompere l'aggregazione dei dati per Systems Manager Explorer o la conformità di Systems Manager.
1. Seleziona **Delete (Elimina)**
1. Ripetere questi passaggi per tutte le sincronizzazioni dati risorsa rimanenti da eliminare.
1. Elimina il bucket Amazon Simple Storage Service (Amazon S3) in cui sono stati archiviati i dati. Per informazioni sull'eliminazione di un bucket Amazon S3, consulta [Eliminazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html).
# Assegnazione di metadati di inventario personalizzati a un nodo gestito
La procedura seguente illustra il processo di utilizzo dell'operazione AWS Systems Manager [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API per assegnare i metadati di inventario personalizzati a un nodo gestito. Questo esempio assegna le informazioni sulla posizione della pila a un nodo. Per ulteriori informazioni sull'inventario personalizzato, consulta [Utilizzo di inventari personalizzati](inventory-custom.md).
**Per assegnare metadati di Inventory personalizzati a un nodo**
1. 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).
1. Eseguire questo comando per assegnare informazioni sulla posizione della pila a un nodo.
**Linux**
```
aws ssm put-inventory --instance-id "ID" --items '[{"CaptureTime": "2016-08-22T10:01:01Z", "TypeName": "Custom:RackInfo", "Content":[{"RackLocation": "Bay B/Row C/Rack D/Shelf E"}], "SchemaVersion": "1.0"}]'
```
**Windows**
```
aws ssm put-inventory --instance-id "ID" --items "TypeName=Custom:RackInfo,SchemaVersion=1.0,CaptureTime=2021-05-22T10:01:01Z,Content=[{RackLocation='Bay B/Row C/Rack D/Shelf F'}]"
```
1. Eseguire questo comando per visualizzare le voci dell'inventario personalizzato per questo nodo.
```
aws ssm list-inventory-entries --instance-id ID --type-name "Custom:RackInfo"
```
Il sistema risponde con informazioni simili alle seguenti.
```
{
"InstanceId": "ID",
"TypeName": "Custom:RackInfo",
"Entries": [
{
"RackLocation": "Bay B/Row C/Rack D/Shelf E"
}
],
"SchemaVersion": "1.0",
"CaptureTime": "2016-08-22T10:01:01Z"
}
```
1. Eseguire il comando seguente per visualizzare lo schema di inventario personalizzato.
```
aws ssm get-inventory-schema --type-name Custom:RackInfo
```
Il sistema risponde con informazioni simili alle seguenti.
```
{
"Schemas": [
{
"TypeName": "Custom:RackInfo",
"Version": "1.0",
"Attributes": [
{
"DataType": "STRING",
"Name": "RackLocation"
}
]
}
]
}
```
# Utilizzo di AWS CLI per configurare la raccolta dei dati di inventario
Le procedure seguenti forniranno le istruzioni per configurare AWS Systems Manager Inventory per raccogliere i metadati dai tuoi nodi gestiti. Quando configuri la raccolta dell'inventario, puoi iniziare creando un'associazione State Manager Systems Manager. Systems Manager raccoglie i dati di inventario quando viene eseguita l'associazione. Se non crei prima l'associazione e tenti di richiamare il plugin `aws:softwareInventory` utilizzando, ad esempio, Run Command Systems Manager, il sistema restituisce il seguente errore:
`The aws:softwareInventory plugin can only be invoked via ssm-associate`.
**Nota**
Un nodo può avere una sola associazione di Inventory configurata alla volta. Se configuri un nodo con due o più associazioni di Inventory, l'associazione non viene eseguita e non viene raccolto alcun dato dell'inventario.
## Configurazione rapida di tutti i nodi gestiti per Inventory (CLI)
Puoi configurare rapidamente tutti i nodi gestiti nella tua regione Account AWS e nella regione corrente per raccogliere i dati di inventario. Questo processo è noto come creazione di un'associazione di inventario globale. Per creare un'associazione di inventario globale utilizzando AWS CLI, utilizzate l'opzione wildcard per il `instanceIds` valore, come illustrato nella procedura seguente.
**Per configurare l'inventario per tutti i nodi gestiti nella tua regione Account AWS e nella regione corrente (CLI)**
1. 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).
1. Eseguire il seguente comando seguente.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name AWS-GatherSoftwareInventory \
--targets Key=InstanceIds,Values=* \
--schedule-expression "rate(1 day)" \
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name AWS-GatherSoftwareInventory ^
--targets Key=InstanceIds,Values=* ^
--schedule-expression "rate(1 day)" ^
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
**Nota**
Questo comando non consente a Inventory di raccogliere metadati per il Registro di sistema o i file di Windows. Per l'inventario di questi tipi di dati, utilizza la procedura successiva.
## Configurazione manuale di Inventory nei tuoi nodi gestiti (CLI)
Utilizza la seguente procedura per configurare manualmente AWS Systems Manager Inventory sui nodi gestiti utilizzando node IDs o tag.
**Per configurare manualmente i nodi gestiti per Inventory (CLI)**
1. 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).
1. Eseguire questo comando per creare un'associazione State Manager che esegue Inventory di Systems Manager sul nodo. Sostituisci ogni *example resource placeholder* con le tue informazioni. Questo comando configura il servizio perché venga eseguito ogni sei ore e per raccogliere da un nodo dati su configurazione della rete, Windows Update e metadati dell'applicazione.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=an_instance_ID" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=an_instance_ID" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
Il sistema risponde con informazioni simili alle seguenti.
```
{
"AssociationDescription": {
"ScheduleExpression": "rate(240 minutes)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "Test",
"OutputS3BucketName": "Test bucket",
"OutputS3Region": "us-east-2"
}
},
"Name": "The name you specified",
"Parameters": {
"applications": [
"Enabled"
],
"networkConfig": [
"Enabled"
],
"windowsUpdates": [
"Enabled"
]
},
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1480544990.06,
"Date": 1480544990.06,
"Targets": [
{
"Values": [
"i-02573cafcfEXAMPLE"
],
"Key": "InstanceIds"
}
]
}
}
```
È possibile definire come target grandi gruppi di nodi utilizzando il parametro `Targets` con i tag EC2. Guarda l'esempio seguente.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=tag:Environment,Values=Production" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=tag:Environment,Values=Production" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
È anche possibile eseguire un inventario di file e chiavi del registro di sistema di Windows su un nodo Windows Server utilizzando i tipi di inventario `files` e `windowsRegistry` con espressioni. Per ulteriori informazioni su questi tipi di inventario, consulta [Utilizzo dell'inventario dei file e del registro di sistema di Windows](inventory-file-and-registry.md).
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" \
--schedule-expression "rate(240 minutes)" \
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' \
--profile dev-pdx
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" ^
--schedule-expression "rate(240 minutes)" ^
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' ^
--profile dev-pdx
```
------
1. Eseguire questo comando per visualizzare lo stato dell'associazione.
```
aws ssm describe-instance-associations-status --instance-id an_instance_ID
```
Il sistema risponde con informazioni simili alle seguenti.
```
{
"InstanceAssociationStatusInfos": [
{
"Status": "Pending",
"DetailedStatus": "Associated",
"Name": "reInvent2016PolicyDocumentTest",
"InstanceId": "i-1a2b3c4d5e6f7g",
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "1"
}
]
}
```
# Procedura dettagliata: utilizzo di sincronizzazione dati risorsa per aggregare dati di inventario
La procedura dettagliata seguente descrive come creare una configurazione di sincronizzazione dei dati delle risorse per AWS Systems Manager Inventory utilizzando AWS Command Line Interface ()AWS CLI. Una sincronizzazione dati risorsa trasferisce automaticamente i dati di inventario della porta da tutti i nodi gestiti a un bucket Amazon Simple Storage Service (Amazon S3) centralizzato. La sincronizzazione aggiorna automaticamente i dati nel bucket Amazon S3 centralizzato ogni volta che vengono rilevati dati di inventario.
Questa procedura dettagliata descrive anche come utilizzare Amazon Athena e Amazon Quick per interrogare e analizzare i dati aggregati. Per informazioni sulla creazione di una sincronizzazione dei dati delle risorse utilizzando Systems Manager in Console di gestione AWS, vedere[Procedura dettagliata: utilizzo di sincronizzazione dati risorsa per aggregare dati di inventario](#inventory-resource-data-sync). Per informazioni sull'interrogazione dell'inventario da più Regioni AWS account utilizzando Systems Manager in Console di gestione AWS, vedere[Esecuzione di query sui dati di inventario da più regioni e account](systems-manager-inventory-query.md).
**Nota**
Questa procedura guidata include informazioni su come crittografare la sincronizzazione utilizzando AWS Key Management Service (AWS KMS). Inventory non raccoglie dati sensibili, proprietari o specifici dell'utente, pertanto la crittografia è facoltativa. Per ulteriori informazioni in merito AWS KMS, vedere la [Guida per AWS Key Management Service gli sviluppatori](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Prima di iniziare**
Prima di iniziare la spiegazione passo per passo in questa sezione, consulta o completa i processi descritti di seguito.
+ Raccogli dati di inventario dai tuoi nodi gestiti. Ai fini delle sezioni Amazon Athena e Amazon Quick di questa procedura dettagliata, ti consigliamo di raccogliere i dati dell'Applicazione. Per ulteriori informazioni su come raccogliere i dati di Inventory, consulta [Configurazione della raccolta dell'inventario](inventory-collection.md) o [Utilizzo di AWS CLI per configurare la raccolta dei dati di inventario](inventory-collection-cli.md).
+ (Facoltativo) Se i dati di inventario sono archiviati in un bucket Amazon Simple Storage Service (Amazon S3) che AWS Key Management Service utilizza la crittografia AWS KMS(), devi anche configurare il tuo account IAM e il ruolo del servizio per `Amazon-GlueServiceRoleForSSM` la crittografia. AWS KMS Se non si configura l'account IAM e questo ruolo, Systems Manager visualizza `Cannot load Glue tables`, quando si sceglie l'opzione **Visualizzazione dettagliata** nella console. Per ulteriori informazioni, consulta [(Facoltativo) Configura le autorizzazioni per la visualizzazione dei dati AWS KMS crittografati](systems-manager-inventory-query.md#systems-manager-inventory-query-kms).
+ (Facoltativo) Se desideri crittografare la sincronizzazione dei dati delle risorse utilizzando AWS KMS, devi creare una nuova chiave che includa la seguente politica oppure aggiornare una chiave esistente e aggiungervi questa politica.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "ssm-access-policy",
"Statement": [
{
"Sid": "ssm-access-policy-statement",
"Action": [
"kms:GenerateDataKey"
],
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KMS_key_id",
"Condition": {
"StringLike": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:123456789012:resource-data-sync/*"
}
}
}
]
}
```
------
**Per creare un Resource Data Sync for Inventory**
1. Apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Creare un bucket in cui archiviare i dati di inventario aggregati. Per ulteriori informazioni, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) nella *Guida per l'utente di Amazon Simple Storage Service*. Prendi nota del nome del bucket e del Regione AWS luogo in cui lo hai creato.
1. Dopo aver creato il bucket, scegliere la scheda **Autorizzazioni**, quindi **Policy del bucket**.
1. Copia e incolla la policy di bucket seguente nell'editor di policy. Sostituisci amzn-s3-demo-bucket e con il *account-id* nome del bucket Amazon S3 che hai creato e un ID valido. Account AWS Quando aggiungi più account, aggiungi una stringa di condizioni e un ARN aggiuntivi per ogni account. Rimuovi i segnaposto aggiuntivi dall'esempio quando aggiungi un account. Facoltativamente, sostituirlo *bucket-prefix* con il nome di un prefisso Amazon S3 (sottodirectory). Se non hai creato un prefisso, rimuovilo *bucket-prefix/* dall'ARN nella policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=111122223333/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": [
"111122223333",
"444455556666",
"123456789012",
"777788889999"
]
},
"ArnLike": {
"aws:SourceArn": [
"arn:aws:ssm:*:111122223333:resource-data-sync/*",
"arn:aws:ssm:*:444455556666:resource-data-sync/*",
"arn:aws:ssm:*:123456789012:resource-data-sync/*",
"arn:aws:ssm:*:777788889999:resource-data-sync/*"
]
}
}
}
]
}
```
------
1. (Facoltativo) Per crittografare la sincronizzazione, devi aggiungere le seguenti condizioni alla policy riportata nel passaggio precedente. Aggiungila nella sezione `StringEquals`.
```
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
```
Ecco un esempio:
```
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "account-id",
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
}
```
1. 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).
1. (Facoltativo) Se desideri crittografare la sincronizzazione, esegui il comando seguente per verificare che la policy del bucket applichi il AWS KMS requisito chiave. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ \
--sse aws:kms \
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" \
--region region, for example, us-east-2
```
------
#### [ Windows ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ ^
--sse aws:kms ^
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" ^
--region region, for example, us-east-2
```
------
1. Eseguire questo comando per creare una configurazione della sincronizzazione dati risorsa per aggregare dati di inventario con il bucket Amazon S3 creato all'inizio di questa procedura. Questo comando crea una sincronizzazione dal momento in Regione AWS cui hai effettuato l'accesso.
**Nota**
Se la sincronizzazione e il bucket Amazon S3 di destinazione si trovano in regioni diverse, potrebbero essere applicati i prezzi per il trasferimento dei dati. Per ulteriori informazioni, consulta [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/).
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name a_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name a_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
È possibile utilizzare il parametro `region` per specificare la regione in cui creare la configurazione di sincronizzazione. Nell'esempio seguente, i dati di inventario dalla regione us-west-1 saranno sincronizzati nel bucket Amazon S3 nella regione us-west-2.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name InventoryDataWest \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2"
--region us-west-1
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name InventoryDataWest ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2" ^ --region us-west-1
```
------
(Facoltativo) Se desideri crittografare la sincronizzazione utilizzando AWS KMS, esegui il comando seguente per creare la sincronizzazione. Se crittografi la sincronizzazione, la AWS KMS chiave e il bucket Amazon S3 devono trovarsi nella stessa regione.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name sync_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" \
--region region
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name sync_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" ^
--region region
```
------
1. Eseguire questo comando per visualizzare lo stato della configurazione di sincronizzazione.
```
aws ssm list-resource-data-sync
```
Se la configurazione di sincronizzazione è stata creata in un'altra regione, è necessario specificare il parametro `region`, come mostrato nel seguente esempio.
```
aws ssm list-resource-data-sync --region us-west-1
```
1. Una volta creata la configurazione di sincronizzazione, esamina il bucket di destinazione in Amazon S3. I dati di inventario dovrebbero essere visualizzati entro pochi minuti.
**Utilizzo dei dati in Amazon Athena**
La sezione seguente descrive come visualizzare ed eseguire query sui dati in Amazon Athena. Prima di iniziare, ti consigliamo di familiarizzare con Athena. Per ulteriori informazioni, consulta [Che cos'è Amazon Athena?](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) e [Utilizzo dei dati](https://docs.aws.amazon.com/athena/latest/ug/work-with-data.html) nella *Guida per l'utente di Amazon Athena*.
**Per visualizzare ed eseguire query sui dati in Amazon Athena**
1. Apri la console Athena all'indirizzo [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home).
1. Copia e incolla la seguente istruzione nell'editor di query e scegli **Esegui query**.
```
CREATE DATABASE ssminventory
```
Il sistema crea un database denominato ssminventory.
1. Copia e incolla la seguente istruzione nell'editor di query e scegli **Esegui query**. Sostituisci amzn-s3-demo-bucket e con il *bucket\$1prefix* nome e il prefisso del target Amazon S3.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Application (
Name string,
ResourceId string,
ApplicationType string,
Publisher string,
Version string,
InstalledTime string,
Architecture string,
URL string,
Summary string,
PackageId string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket_prefix/AWS:Application/'
```
1. Copia e incolla la seguente istruzione nell'editor di query e scegli **Esegui query**.
```
MSCK REPAIR TABLE ssminventory.AWS_Application
```
Il sistema esegue la partizione della tabella.
**Nota**
Se crei sincronizzazioni dei dati delle risorse da un sistema operativo aggiuntivo Regioni AWS Account AWS, devi eseguire nuovamente questo comando per aggiornare le partizioni. Potrebbe anche essere necessario aggiornare la policy del bucket Amazon S3.
1. Per visualizzare un'anteprima dei dati, scegliere l'icona vista accanto alla tabella `AWS_Application`.
![\[L'icona dei dati di anteprima in Amazon Athena.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/sysman-inventory-resource-data-sync-walk.png)
1. Copia e incolla la seguente istruzione nell'editor di query e scegli **Esegui query**.
```
SELECT a.name, a.version, count( a.version) frequency
from aws_application a where
a.name = 'aws-cfn-bootstrap'
group by a.name, a.version
order by frequency desc
```
La query restituisce un conteggio di diverse versioni di`aws-cfn-bootstrap`, che è un' AWS applicazione presente sulle istanze Amazon Elastic Compute Cloud (Amazon EC2) per Linux, e. macOS Windows Server
1. **Copia e incolla singolarmente le seguenti istruzioni nell'editor di query, sostituisci amzn-s3-demo-bucket e *bucket-prefix* con informazioni per Amazon S3, quindi scegli Run Query.** Queste istruzioni configurano tabelle Inventory aggiuntive in Athena.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_AWSComponent (
`ResourceId` string,
`Name` string,
`ApplicationType` string,
`Publisher` string,
`Version` string,
`InstalledTime` string,
`Architecture` string,
`URL` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:AWSComponent/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_AWSComponent
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_WindowsUpdate (
`ResourceId` string,
`HotFixId` string,
`Description` string,
`InstalledTime` string,
`InstalledBy` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:WindowsUpdate/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_WindowsUpdate
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_InstanceInformation (
`AgentType` string,
`AgentVersion` string,
`ComputerName` string,
`IamRole` string,
`InstanceId` string,
`IpAddress` string,
`PlatformName` string,
`PlatformType` string,
`PlatformVersion` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:InstanceInformation/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_InstanceInformation
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Network (
`ResourceId` string,
`Name` string,
`SubnetMask` string,
`Gateway` string,
`DHCPServer` string,
`DNSServer` string,
`MacAddress` string,
`IPV4` string,
`IPV6` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:Network/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_Network
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_PatchSummary (
`ResourceId` string,
`PatchGroup` string,
`BaselineId` string,
`SnapshotId` string,
`OwnerInformation` string,
`InstalledCount` int,
`InstalledOtherCount` int,
`NotApplicableCount` int,
`MissingCount` int,
`FailedCount` int,
`OperationType` string,
`OperationStartTime` string,
`OperationEndTime` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:PatchSummary/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_PatchSummary
```
**Utilizzo dei dati in Amazon Quick**
La sezione seguente fornisce una panoramica con collegamenti per la creazione di una visualizzazione in Amazon Quick.
**Per creare una visualizzazione in Amazon Quick**
1. Registrati ad [Amazon Quick](https://quicksight.aws/) e accedi alla console Quick.
1. Creare un set di dati dalla tabella `AWS_Application` e da tutte le altre tabelle create. Per ulteriori informazioni, consulta [Creazione di un set di dati utilizzando i dati di Amazon Athena](https://docs.aws.amazon.com/quicksuite/latest/userguide/create-a-data-set-athena.html) nella *Amazon Quick* User Guide.
1. Unire le tabelle. Ad esempio, è possibile unire la colonna `instanceid` dalla tabella `AWS_InstanceInformation` poiché corrisponde alla colonna `resourceid` di altre tabelle di inventario. Per ulteriori informazioni sull'unione delle tabelle, consulta [Joining data](https://docs.aws.amazon.com/quicksuite/latest/userguide/joining-data.html) nella *Amazon Quick User Guide*.
1. Creare una visualizzazione. Per ulteriori informazioni, consulta [Analisi e report: visualizzazione dei dati in Amazon Quick Sight nella Amazon Quick](https://docs.aws.amazon.com/quicksuite/latest/userguide/working-with-visuals.html) User *Guide*.
# Risoluzione dei problemi di Inventory Systems Manager
Questo argomento include informazioni su come risolvere errori o problemi comuni relativi a Inventory. AWS Systems Manager In caso di problemi nella visualizzazione dei nodi in Systems Manager, consulta [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md).
**Topics**
+ [
## Non sono supportate tutte le associazioni in applicazione multipla con il documento '`AWS-GatherSoftwareInventory`'
](#systems-manager-inventory-troubleshooting-multiple)
+ [
## Lo stato di esecuzione dell'inventario non risulta mai in sospeso
](#inventory-troubleshooting-pending)
+ [
## L'esecuzione del documento `AWS-ListWindowsInventory` fallisce
](#inventory-troubleshooting-ListWindowsInventory)
+ [
## La console non visualizza il pannello di controllo di Inventory \$1 Visualizzazione dettagliata \$1 Schede Impostazioni
](#inventory-troubleshooting-tabs)
+ [
## UnsupportedAgent
](#inventory-troubleshooting-unsupported-agent)
+ [
## Saltato
](#inventory-troubleshooting-skipped)
+ [
## Non riuscito
](#inventory-troubleshooting-failed)
+ [
## Conformità dell'inventario non riuscita per un'istanza Amazon EC2
](#inventory-troubleshooting-ec2-compliance)
+ [
## L'oggetto bucket S3 contiene vecchi dati
](#systems-manager-inventory-troubleshooting-s3)
## Non sono supportate tutte le associazioni in applicazione multipla con il documento '`AWS-GatherSoftwareInventory`'
Un errore `Multiple apply all associations with document 'AWS-GatherSoftwareInventory' are not supported` significa che una o più Regioni AWS in cui stai tentando di configurare un'associazione Inventory *per tutti i nodi* sono già configurate con un'associazione Inventory per tutti i nodi. Se necessario, puoi eliminare l'associazione di inventario esistente per tutti i nodi e crearne una nuova. Per visualizzare le associazioni Inventory esistenti, scegli **State Manager** nella console di Systems Manager e quindi individua le associazioni che utilizzano il documento SSM di `AWS-GatherSoftwareInventory`. Se l'associazione Inventory esistente per tutti i nodi è stata creata in più regioni e si desidera crearne una nuova, è necessario eliminare l'associazione esistente da ogni regione in cui è presente.
## Lo stato di esecuzione dell'inventario non risulta mai in sospeso
Ci sono due motivi per cui la raccolta dell'inventario non è mai in stato `Pending`.
+ Nessun nodo tra quelli selezionati: Regione AWS
Se si crea un'associazione di inventario globale utilizzando Quick Setup Systems Manager, lo stato dell'associazione di inventario (documento `AWS-GatherSoftwareInventory`) mostra `Pending` se non ci sono nodi disponibili nella regione selezionata ****.
+ Autorizzazioni insufficienti:
Un'associazione di inventario mostra `Pending` se uno o più nodi non dispongono dell'autorizzazione per eseguire Inventory di Systems Manager. Verifica che il profilo dell'istanza AWS Identity and Access Management (IAM) includa la policy SSMManaged InstanceCore gestita da **Amazon**. Per informazioni su come aggiungere questa policy a un profilo dell'istanza, consulta [Configurazione alternativa per le autorizzazioni delle istanze EC2](setup-instance-permissions.md#instance-profile-add-permissions).
Al minimo, il profilo dell'istanza deve disporre delle autorizzazioni IAM descritte di seguito.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation",
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": "*"
}
]
}
```
------
## L'esecuzione del documento `AWS-ListWindowsInventory` fallisce
Il documento `AWS-ListWindowsInventory` è obsoleto. Non utilizzare questo documento per raccogliere l'inventario. Utilizza invece uno dei processi descritti in [Configurazione della raccolta dell'inventario](inventory-collection.md).
## La console non visualizza il pannello di controllo di Inventory \$1 Visualizzazione dettagliata \$1 Schede Impostazioni
La pagina **Detailed View (Visualizzazione dettagliata)** di Inventory è disponibile solo in Regioni AWS che offrono Amazon Athena. Se le seguenti schede non sono visualizzate nella pagina Inventory, significa che Athena non è disponibile nella regione e non è possibile utilizzare la **Detailed View (Visualizzazione dettagliata)** per eseguire query sui dati.
![\[Visualizzazione del pannello di controllo Inventario | Visualizzazione dettagliata | Schede Impostazioni\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
## UnsupportedAgent
Se lo stato dettagliato di un'associazione di inventario viene **UnsupportedAgent**visualizzato e lo **stato dell'associazione** mostra **Fallito**, la versione di AWS Systems Manager SSM Agent sul nodo gestito non è corretta. Per creare un'associazione di inventario globale (per inventariare tutti i nodi del tuo Account AWS), ad esempio, devi utilizzare la SSM Agent versione 2.0.790.0 o successiva. Puoi visualizzare la versione dell'agente in esecuzione su ciascuno dei tuoi nodi nella pagina **Istanze gestite** nella colonna **Versione agente**. Per informazioni su come aggiornare l'SSM Agent sui tuoi nodi, consulta [Aggiornamento di SSM Agent utilizzando Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
## Saltato
Se lo stato dell'associazione di inventario per un nodo mostra **Saltato**, questo indica che un'associazione di inventario con priorità più alta è già in esecuzione in quel nodo. Systems Manager segue un ordine di priorità specifico quando è possibile applicare molteplici associazioni di inventario allo stesso nodo gestito.
### Ordine di priorità dell'associazione di inventario
Systems Manager applica le associazioni di inventario nel seguente ordine di priorità:
1. **Associazioni di inventario Quick Setup**: associazioni create utilizzando Quick Setup e la console unificata. Queste associazioni hanno nomi che iniziano con `AWS-QuickSetup-SSM-CollectInventory-` e sono diretti a tutti i nodi gestiti.
1. **Associazioni di inventario esplicite**: associazioni che hanno come destinazione nodi gestiti specifici utilizzando:
+ Istanza IDs
+ Coppie chiave-valore del tag
+ AWS gruppi di risorse
1. **Associazioni di inventario globali**: associazioni che hanno come destinazione tutti i nodi gestiti (utilizzando `--targets "Key=InstanceIds,Values=*"`), ma **non** sono state create tramite Quick Setup.
### Scenari comuni
**Scenario 1: l'associazione Quick Setup ha la precedenza sull'associazione esplicita**
+ Hai un'associazione di inventario Quick Setup destinata a tutte le istanze
+ Crei un'associazione manuale destinata a nodi gestiti specifici per tag
+ Risultato: l'associazione manuale viene visualizzata come `Skipped` con uno stato `OverriddenByExplicitInventoryAssociation` dettagliato
+ L'associazione Quick Setup continua a raccogliere l'inventario di tutte le istanze
**Scenario 2: l'associazione esplicita ha la precedenza sull'associazione globale**
+ Hai un'associazione di inventario globale destinata a tutte le istanze (non creata da Quick Setup)
+ Crei un'associazione destinata a istanze specifiche
+ Risultato: l'associazione globale viene visualizzata come `Skipped` per le istanze con destinazione specifica
+ L'associazione esplicita viene eseguita sulle istanze di destinazione
### Passaggi di risoluzione
**Se desideri utilizzare la tua associazione di inventario invece di Quick Setup:**
1. **Identifica le associazioni Quick Setup**: nella console Systems Manager, vai a State Manager e cerca le associazioni con nomi che iniziano con `AWS-QuickSetup-SSM-CollectInventory-`.
1. **Rimuovi la configurazione di Quick Setup**:
+ Vai a Quick Setup nella console di Systems Manager.
+ Trova la configurazione della tua collezione di inventario.
+ Elimina la configurazione Quick Setup (questo operazione rimuove l'associazione di inventario associata).
**Nota**
Non è necessario eliminare manualmente l'associazione creata da Quick Setup.
1. **Verifica che l'associazione funzioni**: dopo aver rimosso la configurazione Quick Setup, l'associazione di inventario esplicita dovrebbe iniziare a funzionare correttamente.
**Se desideri modificare il comportamento esistente:**
+ Per visualizzare le associazioni Inventory esistenti, scegli **State Manager** nella console di Systems Manager e quindi individua le associazioni che utilizzano il documento SSM di `AWS-GatherSoftwareInventory`.
+ Ricorda che ogni nodo gestito può avere una sola associazione di inventario alla volta.
**Importante**
I dati di inventario vengono comunque raccolti dai nodi ignorati quando viene eseguita l'associazione di inventario assegnata (con priorità più alta).
Le associazioni di inventario Quick Setup hanno la precedenza su tutti gli altri tipi, anche su quelle con targeting esplicito.
Il messaggio `OverriddenByExplicitInventoryAssociation` di stato dettagliato viene visualizzato quando un'associazione è sostituita da un'altra con priorità più alta, indipendentemente dal tipo di associazione.
## Non riuscito
Se lo stato dell'associazione di inventario per un nodo mostra **Non riuscito**, il nodo potrebbe essere assegnata a più associazioni di inventario. Un nodo può essere assegnato a una sola associazione di inventario alla volta. Un'associazione di inventario utilizza il `AWS-GatherSoftwareInventory` AWS Systems Manager documento (documento SSM). È possibile eseguire il comando seguente utilizzando AWS Command Line Interface (AWS CLI) per visualizzare un elenco di associazioni per un nodo.
```
aws ssm describe-instance-associations-status --instance-id instance-ID
```
## Conformità dell'inventario non riuscita per un'istanza Amazon EC2
La conformità dell'inventario per un'istanza Amazon Elastic Compute Cloud (Amazon EC2) può fallire se si assegnano più associazioni di inventario all'istanza.
Per risolvere questo problema, elimina una o più associazioni di inventario assegnate all'istanza. Per ulteriori informazioni, consulta [Eliminazione di un'associazione](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html).
**Nota**
Tenere presente il comportamento seguente se si creano più associazioni di inventario per un nodo gestito.
A ogni nodo può essere assegnata un'associazione di inventario destinata a *tutti i* nodi (--targets «Key=InstanceIds, Values=\$1»).
A ogni nodo può anche essere assegnata un'associazione specifica che utilizza coppie chiave-valore di tag o un gruppo di risorse. AWS
Se a un nodo vengono assegnate più associazioni d'inventario, lo stato mostra *Saltato* per l'associazione che non è stata eseguita. L'associazione eseguita più di recente visualizza lo stato effettivo dell'associazione d'inventario.
Se a un nodo vengono assegnate più associazioni d'inventario e ognuna utilizza una coppia chiave-valore di tag, le associazioni d'inventario non vengono eseguite sul nodo a causa del conflitto di tag. L'associazione viene ancora eseguita su nodi che non hanno il conflitto chiave-valore di tag.
## L'oggetto bucket S3 contiene vecchi dati
I dati all'interno dell'oggetto bucket Amazon S3 vengono aggiornati quando l'associazione di inventario ha esito positivo e vengono scoperti nuovi dati. L'oggetto bucket Amazon S3 viene aggiornato per ogni nodo quando l'associazione viene eseguita e ha esito negativo, ma in questo caso i dati all'interno dell'oggetto non vengono aggiornati. I dati all'interno dell'oggetto bucket Amazon S3 verranno aggiornati solo quando l'associazione viene eseguita correttamente. Quando l'associazione di inventario non riesce, vengono visualizzati vecchi dati nell'oggetto bucket Amazon S3.
# 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`
# AWS Systems Manager Run Command
Utilizzando uno strumento in Run Command AWS Systems Manager, è possibile gestire in remoto e in modo sicuro la configurazione dei nodi gestiti. Un *nodo gestito* è qualsiasi istanza o non EC2 macchina di Amazon Elastic Compute Cloud (Amazon EC2) nell'ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) configurata per Systems Manager. Run Commandconsente di automatizzare le attività amministrative più comuni ed eseguire modifiche di configurazione una tantum su larga scala. È possibile utilizzare Run Command from Console di gestione AWS, the AWS Command Line Interface (AWS CLI) o. AWS Tools for Windows PowerShell AWS SDKs Run Commandè offerto senza costi aggiuntivi. Per cominciare a utilizzare Run Command, apri la [console di Systems Manager](https://console.aws.amazon.com//systems-manager/run-command). Nel pannello di navigazione, scegli **Run Command**.
Gli amministratori usano Run Command per eseguire l'installazione o il bootstrap delle applicazioni, creazione di una pipeline di implementazione, acquisizione di file di log quando un'istanza viene chiusa da un gruppo Auto Scaling e unione delle istanze a un dominio Windows.
L'API Run Command segue un modello di consistenza finale dovuto alla natura distribuita del sistema che supporta l'API. Ciò significa che il risultato di un comando API eseguito che influisce sulle risorse non è immediatamente visibile a tutti i comandi successivi eseguiti. È necessario tenerlo a mente quando si esegue un comando API che segue immediatamente un comando API precedente.
**Nozioni di base**
La tabella seguente include informazioni utili per iniziare a usare Run Command.
****
| Topic | Informazioni |
| --- | --- |
| [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md) | Verifica di aver completato i requisiti di configurazione per le tue istanze e non EC2 macchine Amazon Elastic Compute Cloud (Amazon EC2) in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). |
| [Gestione dei nodi in ambienti ibridi e multicloud con Systems Manager](systems-manager-hybrid-multicloud.md) | (Facoltativo) Registra i server locali e in AWS questo modo potrai VMs gestirli utilizzando. Run Command |
| [Gestione dei dispositivi edge con Systems Manager](systems-manager-setting-up-edge-devices.md) | (Facoltativo) Configura i dispositivi edge in modo da poterli gestire utilizzando Run Command. |
| [Esecuzione di comandi su nodi gestiti](running-commands.md) | Scopri come eseguire un comando rivolto a uno o più nodi gestiti utilizzando il Console di gestione AWS. |
| [Spiegazioni passo per passo di Run Command](run-command-walkthroughs.md) | Scopri come eseguire i comandi utilizzando Tools for Windows PowerShell o. AWS CLI |
**EventBridge supporto**
Questo strumento Systems Manager è supportato sia come tipo di *evento* che come tipo di *destinazione* nelle EventBridge regole di Amazon. Per informazioni, consulta [Monitoraggio degli eventi di Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md) e [Riferimento: modelli e tipi di EventBridge eventi Amazon per Systems Manager](reference-eventbridge-events.md).
**Ulteriori informazioni**
+ [Run CommandIn remoto su un' EC2 istanza (tutorial di 10 minuti)](https://aws.amazon.com/getting-started/hands-on/remotely-run-commands-ec2-instance-systems-manager/)
+ [Service Quotas di Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#limits_ssm) nella *Riferimenti generali di Amazon Web Services*
+ [AWS Systems Manager Documentazione di riferimento delle API](https://docs.aws.amazon.com/systems-manager/latest/APIReference/)
**Topics**
+ [
# Configurazione di Run Command
](run-command-setting-up.md)
+ [
# Esecuzione di comandi su nodi gestiti
](running-commands.md)
+ [
# Utilizzo dei codici di uscita nei comandi
](run-command-handle-exit-status.md)
+ [
# Informazioni sugli stati dei comandi
](monitor-commands.md)
+ [
# Spiegazioni passo per passo di Run Command
](run-command-walkthroughs.md)
+ [
# Risoluzione dei problemi di Systems Manager
](troubleshooting-remote-commands.md)
# Configurazione di Run Command
Prima di poter gestire i nodi utilizzandoRun Command, uno strumento in AWS Systems Manager, configura una policy AWS Identity and Access Management (IAM) per qualsiasi utente che eseguirà i comandi. Quando utilizzi delle chiavi di condizione globali per l'azione `SendCommand` nelle policy IAM, è necessario includere la chiave di condizione `aws:ViaAWSService` e impostare il valore booleano su `true`. Di seguito è riportato un esempio di :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/YourDocument"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": [
"vpce-1234567890abcdef0"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/YourDocument"
],
"Condition": {
"Bool": {
"aws:ViaAWSService": "true"
}
}
}
]
}
```
------
È necessario anche configurare i nodi per Systems Manager. Per ulteriori informazioni, consulta [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md).
Ti consigliamo di completare le seguenti attività di configurazione opzionali per ridurre al minimo il livello di sicurezza e la day-to-day gestione dei nodi gestiti.
Monitora l'esecuzione dei comandi con Amazon EventBridge
Puoi utilizzarlo EventBridge per registrare le modifiche allo stato di esecuzione dei comandi. È possibile scegliere di creare una regola che venga eseguita ogni volta che si verifica una transizione di stato o quando si verifica una transizione verso uno o più stati di interesse. È inoltre possibile specificare Run Command come azione target quando si verifica un EventBridge evento. Per ulteriori informazioni, consulta [Configurazione EventBridge per gli eventi di Systems Manager](monitoring-systems-manager-events.md).
Monitora l'esecuzione dei comandi utilizzando Amazon Logs CloudWatch
Puoi Run Command configurare l'invio periodico di tutti gli output dei comandi e i log degli errori a un gruppo di CloudWatch log Amazon. È possibile monitorare i log di output in tempo quasi reale, cercare locuzioni, valori o modelli specifici e creare allarmi in base alla ricerca. Per ulteriori informazioni, consulta [Configurazione di Amazon CloudWatch Logs per Run Command](sysman-rc-setting-up-cwlogs.md).
Restrict Run Command accesso a nodi gestiti specifici
Puoi limitare la capacità di un utente di eseguire comandi su nodi gestiti utilizzando AWS Identity and Access Management (IAM). In particolare, è possibile creare una policy IAM con una condizione in base alla quale l'utente può eseguire i comandi solo sui nodi gestiti contrassegnati con tag specifici. Per ulteriori informazioni, consulta [Limitazione dell'accesso Run Command in base ai tag](#tag-based-access).
## Limitazione dell'accesso Run Command in base ai tag
Questa sezione descrive come limitare la capacità di un utente di eseguire comandi sui nodi gestiti specificando una condizione di tag in una policy IAM. I nodi gestiti includono EC2 istanze Amazon e non EC2 nodi in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) configurato per Systems Manager. Sebbene le informazioni non siano presentate in modo esplicito, puoi anche limitare l'accesso ai dispositivi principali gestiti. AWS IoT Greengrass Per iniziare, devi tagging dei dispositivi AWS IoT Greengrass . Per ulteriori informazioni, consulta [Applicazione di tag alle risorse di AWS IoT Greengrass Version 2](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) nella *Guida per gli sviluppatori di AWS IoT Greengrass Version 2 *.
È possibile limitare l'esecuzione dei comandi a nodi gestiti specifici creando una policy IAM che include una condizione in base alla quale l'utente può eseguire i comandi solo sui nodi a cui sono applicati tag specifici. Nell'esempio seguente, l'utente può utilizzare Run Command (`Effect: Allow, Action: ssm:SendCommand`) utilizzando qualsiasi documento SSM () su qualsiasi nodo (`Resource: arn:aws:ssm:*:*:document/*``Resource: arn:aws:ec2:*:*:instance/*`) a condizione che il nodo sia un Finance WebServer (`ssm:resourceTag/Finance: WebServer`). Se l'utente invia un comando a un nodo privo di tag o con un tag diverso da `Finance: WebServer`, i risultati dell'esecuzione mostrano `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:*:*:document/*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ec2:*:*:instance/*"
],
"Condition":{
"StringLike":{
"ssm:resourceTag/Finance":[
"WebServers"
]
}
}
}
]
}
```
------
È possibile creare policy IAM che permettono a un utente di eseguire comandi su nodi gestiti contrassegnati con più tag. La policy seguente consente all'utente di eseguire comandi su nodi gestiti che dispongono di due tag. Se l'utente invia un comando a un nodo non contrassegnato con questi due tag, i risultati dell'esecuzione mostrano `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key1":[
"tag_value1"
],
"ssm:resourceTag/tag_key2":[
"tag_value2"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:us-west-1::document/AWS-*",
"arn:aws:ssm:us-east-2::document/AWS-*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:UpdateInstanceInformation",
"ssm:ListCommands",
"ssm:ListCommandInvocations",
"ssm:GetDocument"
],
"Resource":"*"
}
]
}
```
------
È anche possibile creare policy IAM che consentono a un utente di eseguire comandi su più gruppi di nodi gestiti con tag. La policy di esempio seguente consente all'utente di eseguire comandi su uno o su entrambi i gruppi di nodi con tag.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key1":[
"tag_value1"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key2":[
"tag_value2"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:us-west-1::document/AWS-*",
"arn:aws:ssm:us-east-2::document/AWS-*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:UpdateInstanceInformation",
"ssm:ListCommands",
"ssm:ListCommandInvocations",
"ssm:GetDocument"
],
"Resource":"*"
}
]
}
```
------
Per ulteriori informazioni sulla creazione di policy IAM, consulta la pagina [Policy gestite e policy in linea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) nella *Guida per l'utente IAM*. Per ulteriori informazioni sull'aggiunta di tag ai nodi gestiti, consulta [Editor di tag](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) nella *AWS Resource Groups Guida per l'utente di*.
# Esecuzione di comandi su nodi gestiti
Questa sezione include informazioni su come inviare i comandi dalla console AWS Systems Manager a nodi gestiti. Questa sezione include anche informazioni su come annullare un comando.
Nota che se il tuo nodo è configurato con l'opzione `noexec` mount per la directory var, non Run Command è in grado di eseguire correttamente i comandi.
**Importante**
Quando si invia un comando utilizzando Run Command, non includere informazioni riservate formattate come testo normale, ad esempio password, dati di configurazione o altri segreti. Tutte le attività dell'API Systems Manager nel tuo account vengono registrate in un bucket S3 per i log. AWS CloudTrail Ciò significa che qualsiasi utente con accesso a quel bucket S3 può visualizzare i valori in testo normale di quei segreti. Per questo motivo, si consiglia vivamente di creare e utilizzare parametri `SecureString` per crittografare i dati sensibili utilizzati nelle operazioni di Systems Manager.
Per ulteriori informazioni, consulta [Limitazione dell'accesso ai parametri Parameter Store mediante policy IAM](sysman-paramstore-access.md).
**La cronologia di esecuzione dell'esecuzione**
La cronologia di ciascun comando è disponibile per 30 giorni. Inoltre è possibile archiviare una copia di tutti i file di log in Amazon Simple Storage Service o ottenere un percorso di verifica di tutte le chiamate API in AWS CloudTrail.
**Informazioni correlate**
Per informazioni sull'invio di comandi tramite altri strumenti, consulta i seguenti argomenti:
+ [Procedura dettagliata: utilizzare con AWS Tools for Windows PowerShell Run Command](walkthrough-powershell.md)o gli esempi nella [AWS Systems Manager sezione del AWS Strumenti per PowerShell Cmdlet Reference](https://docs.aws.amazon.com/powershell/latest/reference/items/AWS_Systems_Manager_cmdlets.html).
+ [Procedura dettagliata: utilizzare con AWS CLI Run Command](walkthrough-cli.md)o gli esempi nel riferimento alla CLI di riferimento di [SSM](https://docs.aws.amazon.com/cli/latest/reference/ssm/)
**Topics**
+ [
# Esecuzione di comandi dalla console
](running-commands-console.md)
+ [
# Esecuzione di comandi utilizzando una versione specifica del documento
](run-command-version.md)
+ [
# Esecuzione di comandi su vasta scala
](send-commands-multiple.md)
+ [
# Annullamento di un comando
](cancel-run-command.md)
# Esecuzione di comandi dalla console
È possibile utilizzareRun Command, uno strumento in AWS Systems Manager, Console di gestione AWS per configurare i nodi gestiti senza dover accedere a essi. Questo argomento include un esempio che mostra come [aggiornare SSM Agent](run-command-tutorial-update-software.md#rc-console-agentexample) su un nodo gestito utilizzando Run Command.
**Prima di iniziare**
Prima di inviare un comando utilizzando Run Command verifica che i nodi gestiti soddisfino tutti i [requisiti di configurazione](systems-manager-setting-up-nodes.md) di Systems Manager.
**Per inviare un comando utilizzando Run Command**
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 **Run Command**.
1. Selezionare **Run command (Esegui comando)**.
1. Nell'elenco **Command document (Documento comando)**, scegliere un documento di Systems Manager.
1. Nella sezione **Command parameters (Parametri di comando)** specificare i valori per i parametri necessari.
1. In **Targets (Destinazioni)**, scegliere i nodi gestiti in cui si desidera eseguire questa operazione specificando i tag, selezionando le istanze o i dispositivi edge manualmente o indicando un gruppo di risorse.
**Suggerimento**
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.
1. In **Other parameters (Altri parametri)**:
+ In **Comment (Commento)** digitare le informazioni su questo comando.
+ In **Timeout (seconds) (Timeout [secondi])**, specificare il numero di secondi che il sistema dovrà attendere prima di generare un errore per l'intera esecuzione del comando.
1. Per **Rate control (Controllo velocità)**:
+ In **Concurrency (Simultaneità)**, specificare un numero o una percentuale di nodi gestiti su cui eseguire contemporaneamente il comando.
**Nota**
Se hai selezionato le destinazioni specificando i tag applicati ai nodi gestiti o specificando i gruppi di AWS risorse e non sei sicuro del numero di nodi gestiti come target, limita il numero di destinazioni che possono eseguire il documento contemporaneamente specificando una percentuale.
+ Per **Error threshold (Soglia di errore)** specificare quando interrompere l'esecuzione del comando sulle altri nodi gestiti dopo un errore su un numero o una percentuale di nodi. Se ad esempio si specificano 3 errori, Systems Manager interrompe l'invio del comando quando riceve il quarto errore. Anche i nodi gestiti che stanno ancora elaborando il comando potrebbero inviare errori.
1. (Facoltativo) Scegliete un CloudWatch allarme da applicare al comando di monitoraggio. Per allegare un CloudWatch allarme al tuo comando, il principale IAM che esegue il comando deve disporre dell'autorizzazione per l'`iam:createServiceLinkedRole`azione. Per ulteriori informazioni sugli CloudWatch allarmi, consulta [Using Amazon CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Si noti che se l'allarme si attiva, qualsiasi chiamata di comando in sospeso non viene eseguita.
1. (Opzionale) Nella sezione **Output options (Opzioni di output)**, per salvare l'output del comando in un file, selezionare la casella **Write command output to an S3 bucket (Scrivi l'output del comando in un bucket S3)**. Digita i nomi del bucket e del prefisso (cartella) nelle caselle.
**Nota**
Le autorizzazioni S3 che garantiscono la possibilità di scrivere i dati in un bucket S3 sono quelle del profilo dell'istanza (per le EC2 istanze) o del ruolo di servizio IAM (macchine ad attivazione ibrida) assegnato all'istanza, non quelle dell'utente IAM che esegue questa attività. 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 su un Account AWS diverso, assicurarsi che il profilo dell'istanza o il ruolo di servizio IAM associato al nodo gestito disponga delle autorizzazioni necessarie per scrivere su quel bucket.
1. Se si desidera che vengano inviate notifiche sullo stato dell'esecuzione del comando, nella sezione **SNS notifications (Notifiche SNS)** selezionare la casella di controllo **Enable SNS notifications (Abilita notifiche SNS)**.
Per ulteriori informazioni sulla configurazione delle notifiche Amazon SNS per Run Command, consulta [Monitoraggio delle modifiche di stato di Systems Manager utilizzando le notifiche Amazon SNS](monitoring-sns-notifications.md).
1. Selezionare **Esegui**.
Per informazioni su come annullare un comando, consulta [Annullamento di un comando](cancel-run-command.md).
## Riesecuzione dei comandi
Systems Manager include due opzioni che consentono di eseguire nuovamente un comando dalla pagina **Esegui comando** nella console Systems Manager.
+ **Rieseguire**: questo pulsante consente di eseguire lo stesso comando senza apportare modifiche.
+ **Copia su nuovo**: questo pulsante copia le impostazioni di un comando in un nuovo comando e ti dà la possibilità di modificare tali impostazioni prima di eseguirlo.
**Per eseguire nuovamente un comando**
1. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)Apri la console all'indirizzo.
1. Nel pannello di navigazione, scegliere **Run Command**.
1. Scegliere un comando da eseguire nuovamente. È possibile eseguire nuovamente un comando immediatamente dopo averlo eseguito dalla pagina dei dettagli del comando. In alternativa, è possibile scegliere un comando eseguito in precedenza dalla scheda **Cronologia comandi** .
1. Scegliere **Rieseguire** per eseguire lo stesso comando senza modifiche oppure scegliere **Copia in nuovo** per modificare le impostazioni dei comandi prima di eseguirli.
# Esecuzione di comandi utilizzando una versione specifica del documento
Il parametro document-version consente di specificare quale versione di un documento AWS Systems Manager utilizzare quando viene eseguito il comando. È possibile specificare una delle seguenti opzioni per questo parametro:
+ \$1DEFAULT
+ \$1LATEST
+ Numero di versione
Usa la procedura seguente per eseguire un comando utilizzando il parametro document-version.
------
#### [ Linux ]
**Per eseguire comandi utilizzando AWS CLI le macchine Linux locali**
1. 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).
1. Creare un elenco di tutti i documenti disponibili
Questo comando elenca tutti i documenti disponibili per il tuo account in base alle autorizzazioni AWS Identity and Access Management (IAM).
```
aws ssm list-documents
```
1. Esegui il comando seguente per visualizzare le diverse versioni di un documento. *document name*Sostituiscili con le tue informazioni.
```
aws ssm list-document-versions \
--name "document name"
```
1. Esegui il comando seguente per eseguire un comando che usa una versione del documento SSM. Sostituisci ogni *example resource placeholder* con le tue informazioni.
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--parameters commands="echo Hello" \
--instance-ids instance-ID \
--document-version '$LATEST'
```
------
#### [ Windows ]
**Per eseguire comandi utilizzando i AWS CLI computer Windows locali**
1. 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).
1. Creare un elenco di tutti i documenti disponibili
Questo comando elenca tutti i documenti disponibili per il tuo account in base alle autorizzazioni AWS Identity and Access Management (IAM).
```
aws ssm list-documents
```
1. Esegui il comando seguente per visualizzare le diverse versioni di un documento. *document name*Sostituiscili con le tue informazioni.
```
aws ssm list-document-versions ^
--name "document name"
```
1. Esegui il comando seguente per eseguire un comando che usa una versione del documento SSM. Sostituisci ogni *example resource placeholder* con le tue informazioni.
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--parameters commands="echo Hello" ^
--instance-ids instance-ID ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
**Per eseguire comandi utilizzando gli strumenti per PowerShell**
1. Installa e configura AWS Strumenti per PowerShell (Strumenti per Windows PowerShell), se non l'hai già fatto.
Per informazioni, consulta la pagina [Installazione di AWS Strumenti per PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Creare un elenco di tutti i documenti disponibili
Questo comando elenca tutti i documenti disponibili per il tuo account in base alle autorizzazioni AWS Identity and Access Management (IAM).
```
Get-SSMDocumentList
```
1. Esegui il comando seguente per visualizzare le diverse versioni di un documento. *document name*Sostituiscili con le tue informazioni.
```
Get-SSMDocumentVersionList `
-Name "document name"
```
1. Esegui il comando seguente per eseguire un comando che usa una versione del documento SSM. Sostituisci ogni *example resource placeholder* con le tue informazioni.
```
Send-SSMCommand `
-DocumentName "AWS-RunShellScript" `
-Parameter @{commands = "echo helloWorld"} `
-InstanceIds "instance-ID" `
-DocumentVersion $LATEST
```
------
# Esecuzione di comandi su vasta scala
È possibile utilizzareRun Command, uno strumento in AWS Systems Manager, per eseguire comandi su una flotta di nodi gestiti utilizzando il`targets`. Il parametro `targets` accetta una combinazione `Key,Value` in base ai tag specificati per i nodi gestiti. Quando si esegue il comando, il sistema individua e tenta di eseguire il comando su tutti i nodi gestiti che corrispondono ai tag specificati. Per ulteriori informazioni sull'etichettatura delle istanze gestite, consulta [Tagging your AWS resources nella Tagging](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-editor.html) Resources User * AWS Guide*. Per informazioni sull'etichettatura dei dispositivi IoT gestiti, consulta [Etichettare le AWS IoT Greengrass Version 2 risorse](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) nella *Guida per gli AWS IoT Greengrass Version 2 sviluppatori*.
Puoi anche utilizzare il `targets` parametro per indirizzare un elenco di nodi gestiti specifici IDs, come descritto nella sezione successiva.
Per controllare l'esecuzione del comando su centinaia o migliaia di nodi gestiti, Run Command include anche i parametri per limitare il numero di nodi che possono elaborare contemporaneamente una richiesta e il numero di errori che possono essere generati da un comando prima che venga terminato.
**Topics**
+ [
## Impostare come destinazione più nodi gestiti
](#send-commands-targeting)
+ [
## Utilizzo dei controlli di velocità
](#send-commands-rate)
## Impostare come destinazione più nodi gestiti
È possibile eseguire un comando e scegliere come target i nodi gestiti specificando tag, nomi di gruppi di AWS risorse o nodi IDs gestiti.
Gli esempi seguenti mostrano il formato del comando quando si utilizza Run Command from the AWS Command Line Interface (AWS CLI ). Sostituisci ogni *example resource placeholder* con le tue informazioni. I comandi di esempio in questa sezione sono troncati utilizzando `[...]`.
**Esempio 1: definizione di tag come target**
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:tag-name,Values=tag-value \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:tag-name,Values=tag-value ^
[...]
```
------
**Esempio 2: Individuazione di un gruppo di AWS risorse in base al nome**
Puoi specificare un massimo di un nome del gruppo di risorse per comando. Quando crei un gruppo di risorse, ti consigliamo di includere `AWS::SSM:ManagedInstance` e `AWS::EC2::Instance` come tipi di risorse nei criteri di raggruppamento.
**Nota**
Per inviare comandi destinati a un gruppo di risorse, è necessario disporre delle autorizzazioni AWS Identity and Access Management (IAM) per elencare o visualizzare le risorse che appartengono a quel gruppo. Per ulteriori informazioni, consulta [Impostazione delle autorizzazioni](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions) nella *Guida per l'utente di AWS Resource Groups *.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=resource-groups:Name,Values=resource-group-name \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=resource-groups:Name,Values=resource-group-name ^
[...]
```
------
**Esempio 3: Individuazione di un gruppo di risorse per tipo di AWS risorsa**
Puoi specificare un massimo di un nome del gruppo di risorse per comando. Quando crei un gruppo di risorse, ti consigliamo di includere `AWS::SSM:ManagedInstance` e `AWS::EC2::Instance` come tipi di risorse nei criteri di raggruppamento.
**Nota**
Per inviare comandi destinati a un gruppo di risorse, è necessario disporre di autorizzazioni IAM per elencare o visualizzare le risorse che appartengono a tale gruppo. Per ulteriori informazioni, consulta [Impostazione delle autorizzazioni](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions) nella *Guida per l'utente di AWS Resource Groups *.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=resource-groups:ResourceTypeFilters,Values=resource-type-1,resource-type-2 \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=resource-groups:ResourceTypeFilters,Values=resource-type-1,resource-type-2 ^
[...]
```
------
**Esempio 4: istanza di targeting IDs**
Gli esempi seguenti mostrano come destinazione i nodi gestiti utilizzando il `instanceids` Chiave con il parametro `targets`. È possibile utilizzare questa chiave per indirizzare i dispositivi AWS IoT Greengrass core gestiti perché a ciascun dispositivo viene assegnato un mi-*ID\$1number*. È possibile visualizzare il dispositivo IDs inFleet Manager, uno strumento in AWS Systems Manager.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=instanceids,Values=instance-ID-1,instance-ID-2,instance-ID-3 \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=instanceids,Values=instance-ID-1,instance-ID-2,instance-ID-3 ^
[...]
```
------
Se hai aggiunto tag ai nodi gestiti per diversi ambienti usando una `Key` denominata `Environment` e `Values` pari a `Development`, `Test`, `Pre-production` e `Production`, puoi inviare un comando a tutti i nodi gestiti in *uno* degli ambienti utilizzando il parametro `targets` con la seguente sintassi.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Environment,Values=Development \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
------
Puoi definire altri nodi gestiti come destinazione in altri ambienti aggiungendo voci all'elenco `Values`. Separa gli elementi con le virgole.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Environment,Values=Development,Test,Pre-production \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Environment,Values=Development,Test,Pre-production ^
[...]
```
------
**Variazione**: perfezionamento dei target utilizzando più criteri `Key`
È possibile perfezionare il numero di target per il comando includendo più criteri `Key`. Se si includono più criteri `Key`, vengono definite come destinazioni i nodi gestiti che soddisfano *tutti* i criteri. Il comando seguente definisce come destinazione tutti i nodi gestiti taggati per il reparto finanze *e* taggati per il ruolo server di database.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database ^
[...]
```
------
**Variazione**: utilizzo di più criteri `Key` e `Value`
Espandendo l'esempio precedente, è possibile definire più reparti e più ruoli server come target includendo altri elementi nei criteri `Values`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database ^
[...]
```
------
**Variazione**: definizione di nodi gestiti con tag come destinazione utilizzando più criteri `Values`
Se hai applicato tag a nodi gestiti per diversi ambienti usando un oggetto `Key` denominato `Department` e `Values` corrispondente a `Sales` e `Finance`, puoi inviare un comando a tutti i nodi gestiti in questi ambienti utilizzando il parametro `targets` con la sintassi seguente.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Sales,Finance \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Sales,Finance ^
[...]
```
------
È possibile specificare un massimo di cinque chiavi e cinque valori per ogni chiave.
Se una chiave tag (il nome del tag) o un valore tag include spazi, devi racchiudere tra virgolette la chiave o il valore tag, come mostrato nei seguenti esempi.
**Esempio**: spazi nel tag `Value`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:OS,Values="Windows Server 2016" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:OS,Values="Windows Server 2016" ^
[...]
```
------
**Esempio**: spazi nella chiave `tag` e `Value`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key="tag:Operating System",Values="Windows Server 2016" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key="tag:Operating System",Values="Windows Server 2016" ^
[...]
```
------
**Esempio**: spazi in un elemento in un elenco di `Values`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values="Sales","Finance","Systems Mgmt" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values="Sales","Finance","Systems Mgmt" ^
[...]
```
------
## Utilizzo dei controlli di velocità
Puoi controllare la velocità con cui i comandi vengono inviati ai nodi gestiti di un gruppo utilizzando *controlli di concorrenza * e *controlli di errore*.
**Topics**
+ [
### Utilizzo di controlli di concorrenza
](#send-commands-velocity)
+ [
### Utilizzo dei controlli degli errori
](#send-commands-maxerrors)
### Utilizzo di controlli di concorrenza
Puoi controllare il numero di nodi gestiti che eseguono il comando contemporaneamente utilizzando il parametro `max-concurrency` (le opzioni **Simultaneità** nella pagina **Esegui un comando**). Puoi specificare un numero assoluto di nodi gestiti, ad esempio **10**, oppure una percentuale del set di target, ad esempio **10%**. Il sistema di accodamento invia il comando a un singolo nodo e attende il completamento dell'invocazione iniziale prima di inviare il comando ad altri due nodi. Il sistema invia comandi ad altri nodi in modo esponenziale fino al raggiungimento del valore `max-concurrency`. Il valore predefinito per `max-concurrency` è 50. Gli esempi seguenti mostrano come specificare valori per il parametro `max-concurrency`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 10 \
--targets Key=tag:Environment,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 10% \
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 10 ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 10% ^
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database ^
[...]
```
------
### Utilizzo dei controlli degli errori
Puoi anche controllare l'esecuzione di un comando su centinaia o migliaia di nodi gestiti impostando un limite di errori usando i parametri `max-errors` (il campo **Soglia di errore** nella pagina **Esegui un comando**). Il parametro specifica il numero di errori consentiti prima che il sistema smetta di inviare il comando ad altri nodi gestiti. Puoi specificare un numero assoluto di errori, ad esempio **10**, oppure una percentuale della serie di target, ad esempio **10%**. Se ad esempio specifichi **3**, il sistema smette di inviare il comando quando riceve il quarto errore. Se specifichi **0**, il sistema smette di inviare il comando ad altri nodi gestiti non appena viene restituito il primo risultato di errore. Se invii un comando a 50 nodi gestiti e imposti `max-errors` su **10%**, il sistema smette di inviare il comando ad altri nodi quando riceve il sesto errore.
Per le invocazioni che stanno già eseguendo un comando quando viene raggiunto il valore `max-errors`, viene consentito il completamento dell'operazione, ma alcune di queste invocazioni potrebbero non riuscire. Per evitare che si verifichino più di `max-errors` invocazioni non riuscite, imposta `max-concurrency` su **1** in modo che le invocazioni procedano una alla volta. Il valore predefinito per max-errors è 0. Gli esempi seguenti mostrano come specificare valori per il parametro `max-errors`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--max-errors 10 \
--targets Key=tag:Database,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-errors 10% \
--targets Key=tag:Environment,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 1 \
--max-errors 1 \
--targets Key=tag:Environment,Values=Production \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--max-errors 10 ^
--targets Key=tag:Database,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-errors 10% ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 1 ^
--max-errors 1 ^
--targets Key=tag:Environment,Values=Production ^
[...]
```
------
# Annullamento di un comando
Puoi tentare di annullare un comando finché il servizio mostra che il suo stato è in attesa o in esecuzione. Anche se un comando si trova in uno di questi stati, però, non siamo in grado di garantire che verrà terminato e che il processo sottostante verrà arrestato.
**Per annullare un comando usando la 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. Selezionare l'invocazione del comando da annullare.
1. Scegliere **Cancel command (Annulla comando)**.
**Per annullare un comando usando l'AWS CLI**
Esegui il comando seguente. Sostituisci ciascun *segnaposto delle risorse di esempio* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm cancel-command \
--command-id "command-ID" \
--instance-ids "instance-ID"
```
------
#### [ Windows ]
```
aws ssm cancel-command ^
--command-id "command-ID" ^
--instance-ids "instance-ID"
```
------
Per ulteriori informazioni sullo stato di un comando annullato, consulta [Informazioni sugli stati dei comandi](monitor-commands.md).
# Utilizzo dei codici di uscita nei comandi
In alcuni casi, potrebbe essere necessario controllare la modalità di gestione dei comandi utilizzando i codici di uscita.
## Specifica dei codici di uscita nei comandi
Utilizzando Run Command, uno strumento di AWS Systems Manager, è possibile specificare i codici di uscita per determinare il modo in cui vengono gestiti i comandi. Per impostazione predefinita, il codice di uscita dell'ultimo comando eseguito in uno script viene segnalato come codice di uscita per l'intero script. Ad esempio, si dispone di uno script che contiene tre comandi. Il primo non riesce, ma i seguenti riescono. Poiché il comando finale è riuscito, lo stato dell'esecuzione viene segnalato come `succeeded`.
**Script di shell**
Per chiudere con esito negativo l'intero comando al primo errore, è possibile includere un'istruzione condizionale della shell per uscire dallo script se un comando precedente a quello finale non riesce. Utilizzare l'approccio seguente.
```
if [ $? != 0 ]
then
exit
fi
```
Nell'esempio seguente, l'intero script ha esito negativo se il primo comando non riesce.
```
cd /test
if [ $? != 0 ]
then
echo "Failed"
exit 1
fi
date
```
**Script di PowerShell**
PowerShell richiede di richiamare esplicitamente `exit` negli script affinché Run Command possa acquisire correttamente il codice di uscita.
```
if ($?) {}
else {exit }
exit
```
Ecco un esempio:
```
cd C:\
if ($?) {echo "Success"}
else {exit 1}
date
```
# Gestione di riavvii durante l'esecuzione dei comandi
Se utilizziRun Command, uno strumento in AWS Systems Manager, per eseguire script che riavviano i nodi gestiti, ti consigliamo di specificare un codice di uscita nello script. Se tenti di riavviare un nodo da uno script utilizzando altri meccanismi, lo stato di esecuzione di script potrebbe non essere aggiornato correttamente, anche se il riavvio è l'ultimo passaggio nel tuo script. Per i nodi gestiti da Windows, è necessario specificare `exit 3010` nello script. Per i nodi gestiti Linux e macOS, è necessario specificare `exit 194`. Il codice di uscita indica ad AWS Systems Manager Agent (SSM Agent) di riavviare il nodo gestito e quindi di riavviare lo script al termine del riavvio. Prima di iniziare il riavvio,SSM Agent notifica al servizio Systems Manager nel cloud che le comunicazioni verranno interrotte durante il riavvio dei server.
**Nota**
Lo script di riavvio non può fare parte di un`aws:runDocument`. Se un documento contiene lo script di riavvio e un altro documento tenta di eseguirlo tramite il plug-in `aws:runDocument`, SSM Agent causerà un errore.
**Creare script idempotenti**
Quando sviluppi script che riavviano i nodi gestiti, rendi idempotenti gli script in modo che la loro esecuzione prosegua dal punto in cui si è interrotta dopo il riavvio. Gli script idempotenti gestiscono lo stato e verificano se l'operazione è stata eseguita o meno. Questo evita che una fase venga eseguita più volte quando è concepita per un'esecuzione singola.
Ecco un esempio generale di script idempotente che riavvia il nodo gestito più volte.
```
$name = Get current computer name
If ($name –ne $desiredName)
{
Rename computer
exit 3010
}
$domain = Get current domain name
If ($domain –ne $desiredDomain)
{
Join domain
exit 3010
}
If (desired package not installed)
{
Install package
exit 3010
}
```
**Esempi**
I seguenti esempi di script usano codici di uscita per riavviare i nodi gestiti. L'esempio Linux installa gli aggiornamenti del pacchetto in e riavvia il nodo. L'esempio di Windows Server installa l'applicazione Hyper-V sul nodo e quindi lo riavvia.
------
#### [ Amazon Linux 2 ]
```
#!/bin/bash
yum -y update
needs-restarting -r
if [ $? -eq 1 ]
then
exit 194
else
exit 0
fi
```
------
#### [ Windows ]
```
$telnet = Get-WindowsFeature -Name Telnet-Client
if (-not $telnet.Installed)
{
# Install Telnet and then send a reboot request to SSM Agent.
Install-WindowsFeature -Name "Telnet-Client"
exit 3010
}
```
------
# Informazioni sugli stati dei comandi
Run Command, uno strumento in AWS Systems Manager, riporta informazioni dettagliate sullo stato dei diversi stati sperimentati da un comando durante l'elaborazione e per ogni nodo gestito che ha elaborato il comando. È possibile monitorare lo stato dei comando usando i metodi seguenti.
+ Scegli l'icona **Refresh** (Aggiorna) della scheda **Commands** (Comandi) nell'interfaccia della console Run Command.
+ Chiama [list-commands](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-commands.html) o [list-command-invocations](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-command-invocations.html)usa il AWS Command Line Interface ()AWS CLI. Oppure chiama [Get- SSMCommand](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommand.html) o [Get- SSMCommand Invocation usando](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommandInvocation.html). AWS Tools for Windows PowerShell
+ Configura Amazon EventBridge per rispondere ai cambiamenti di stato o di stato.
+ Configura Amazon Simple Notification Service (Amazon SNS) per l'invio di notifiche relative a tutte le modifiche di stato o a stati specifici come `Failed` o `TimedOut`.
## Stato di Run Command
Run Command indica dettagli di stato per tre aree: plugin, invocazioni e stato generale dei comandi. Un *plugin* è un blocco di esecuzione di codice definito nel documento del comando. Per ulteriori informazioni sui plugin , consulta [Documentazione di riferimento del plugin per i documenti di comando](documents-command-ssm-plugin-reference.md).
Quando si invia un comando a più nodi gestiti contemporaneamente, ogni copia del documento destinata a ogni nodo è denominata *invocazione di comando*. Ad esempio, se usi il documento `AWS-RunShellScript` e invii un comando `ifconfig` a 20 istanze, quel comando ha 20 invocazioni. Ogni invocazione di comando segnala lo stato individualmente. Anche i plugin per una determinata invocazione di comando segnalano lo stato individualmente.
Infine, Run Command include uno stato di comando aggregato per tutti i plugin e le invocazioni. Lo stato di comando aggregato può essere diverso rispetto allo stato segnalato dai plugin o dalle invocazioni, come mostrato nelle tabelle seguenti.
**Nota**
Se si eseguono comandi su un numero elevato di nodi gestiti utilizzando i parametri `max-concurrency` o `max-errors`, lo stato dei comandi riflette le limitazioni imposte da quei parametri, come descritto nelle tabelle seguenti. Per ulteriori informazioni su questi parametri, consultare [Esecuzione di comandi su vasta scala](send-commands-multiple.md).
**Stato dettagliato per i plugin e le invocazioni dei comandi**
| Status | Informazioni |
| --- | --- |
| Pending (In attesa) | Il comando non è stato ancora inviato al nodo gestito o non è stato ricevuto da SSM Agent. Se il comando non viene ricevuto dall'agente prima che passi il tempo che è uguale alla somma delTimeout (secondi)e il parametroExecution timeout (Timeout di esecuzione)Parametro, lo stato cambia inDelivery Timed Out. |
| InProgress | Systems Manager sta tentando di inviare il comando al nodo gestito oppure il comando è stato ricevuto da SSM Agent e ha iniziato a funzionare sull'istanza. A seconda del risultato di tutti i plugin dei comandi, lo stato passerà a Success, Failed, Delivery Timed Out o Execution Timed Out. Eccezione: se l'agente non è in esecuzione o è disponibile nel nodo, lo stato del comando rimane in In Progress finché l'agente non è nuovamente disponibile o fino al raggiungimento del limite di timeout di esecuzione. Lo stato passerà quindi a uno stato terminale. |
| Ritardato | Il sistema ha tentato di inviare il comando al nodo gestito, ma non è riuscito. Il sistema riprova. |
| Completato | Questo stato viene restituito in diverse condizioni. Questo stato non significa che il comando è stato elaborato correttamente sul nodo. Ad esempio, il comando può essere ricevuto dal SSM Agent nodo gestito e restituire un codice di uscita pari a zero come risultato dell' PowerShell ExecutionPolicyimpossibilità dell'esecuzione del comando. Si tratta di uno stato terminale. Le condizioni che determinano la restituzione di uno stato Success da un comando sono: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/monitor-commands.html) Le stesse condizioni si applicano quando si sceglie come destinazione i gruppi di risorse. Per risolvere gli errori o ottenere ulteriori informazioni sull'esecuzione del comando, invia un comando che gestisce gli errori o le eccezioni restituendo codici di uscita appropriati (codici di uscita diversi da zero in caso di errore del comando). |
| DeliveryTimedOut | Il comando non è stato recapitato al nodo gestito prima della scadenza del timeout complessivo. I timeout complessivi non vengono conteggiati per il limite max-errors del comando padre, ma sono rilevanti per la definizione dello stato del comando come Success, Incomplete o Delivery Timed Out. Si tratta di uno stato terminale. |
| ExecutionTimedOut | L'esecuzione del comando è iniziata sul nodo gestito, ma non è stata completata prima della scadenza. I timeout di esecuzione contano come un errore che invierà una risposta diversa da zero e Systems Manager interromperà il tentativo di esecuzione dell'automazione dei comandi, segnalando lo stato di errore. |
| Non riuscito | Il comando non è riuscito sul nodo gestito. Per un plugin, questo indica che il codice del risultato non era zero. Per un'invocazione del comando, questo indica che il codice del risultato per uno o più plugin non era zero. Le invocazioni non riuscite vengono conteggiate per il limite max-errors del comando padre. Si tratta di uno stato terminale. |
| Annullato | Il comando è stato terminato prima del completamento. Si tratta di uno stato terminale. |
| Non consegnabile | Il comando non può essere recapitato al nodo gestito. Il nodo potrebbe non esistere o non rispondere. Le invocazioni non consegnabili non vengono conteggiate per il limite max-errors del comando padre e non sono rilevanti per la definizione dello stato del comando come Success o Incomplete. Ad esempio, se tutte le invocazioni in un comando dispongono dello stato Undeliverable, lo stato del comando restituito è Failed. Tuttavia, se un comando dispone di cinque chiamate, quattro delle quali restituiscono lo stato Undeliverable e una restituisce lo stato Success, lo stato del comando padre è Success. Si tratta di uno stato terminale. |
| Terminato | Il comando padre ha superato il limite max-errors e le successive invocazioni del comando sono state annullate dal sistema. Si tratta di uno stato terminale. |
| InvalidPlatform | Il comando è stato inviato a un nodo gestito che non corrisponde alle piattaforme richieste specificate dal documento scelto. Invalid Platform non viene conteggiato per il limite massimo di errori del comando padre, ma contribuisce a determinare lo stato del comando come Successo o Failed. Ad esempio, se tutte le invocazioni in un comando dispongono dello stato Invalid Platform, lo stato del comando restituito è Failed. Tuttavia, se un comando dispone di cinque chiamate, quattro delle quali restituiscono lo stato Invalid Platform e una restituisce lo stato Success, lo stato del comando padre è Success. Si tratta di uno stato terminale. |
| AccessDenied | L'utente o il ruolo AWS Identity and Access Management (IAM) che avvia il comando non ha accesso al nodo gestito di destinazione. Access Deniednon viene conteggiato nel max-errors limite del comando principale, ma contribuisce a determinare se lo stato del comando principale è Success oFailed. Ad esempio, se tutte le invocazioni in un comando dispongono dello stato Access Denied, lo stato del comando restituito è Failed. Tuttavia, se un comando dispone di cinque chiamate, quattro delle quali restituiscono lo stato Access Denied e una restituisce lo stato Success, lo stato del comando padre è Success. Si tratta di uno stato terminale. |
**Stato dettagliato per un comando**
| Status | Informazioni |
| --- | --- |
| Pending (In attesa) | Il comando non è ancora stato ricevuto da un agente su qualsiasi nodo gestito. |
| InProgress | Il comando è stato inviato ad almeno un'istanza, ma non ha raggiunto lo stato finale su ogni nodo gestito. |
| Ritardato | Il sistema ha tentato di inviare il comando al nodo, ma non è riuscito. Il sistema riprova. |
| Completato | Il comando è stato ricevuto da SSM Agent su tutti i nodi gestiti specificati o destinazione e ha restituito un codice di uscita zero. Tutte le invocazioni di comando hanno raggiunto uno stato terminale e non è stato raggiunto il valore max-errors. Questo stato non significa che il comando è stato elaborato correttamente su tutti i nodi gestiti specificati o destinazione. Si tratta di uno stato terminale. Per risolvere gli errori o ottenere ulteriori informazioni sull'esecuzione del comando, invia un comando che gestisce gli errori o le eccezioni restituendo codici di uscita appropriati (codici di uscita diversi da zero in caso di errore del comando). |
| DeliveryTimedOut | Il comando non è stato recapitato al nodo gestito prima della scadenza del timeout complessivo. I valore di max-errors o altre invocazioni del comando mostra lo stato Delivery Timed Out. Si tratta di uno stato terminale. |
| Non riuscito | Il comando non è riuscito sul nodo gestito. I valore di `max-errors` o altre invocazioni del comando mostra lo stato `Failed`. Si tratta di uno stato terminale. |
| Incomplete (Incompleto) | Il comando è stato tentato su tutti i nodi gestiti e una o più invocazioni non hanno il valore Success. Il numero delle invocazioni non riuscite, però, non è sufficiente perché lo stato sia Failed. Si tratta di uno stato terminale. |
| Annullato | Il comando è stato terminato prima del completamento. Si tratta di uno stato terminale. |
| RateExceeded | Il numero di nodi gestiti definiti come target dal comando ha superato la quota dell'account per le invocazioni in attesa. Il sistema ha annullato il comando prima di eseguirlo su qualsiasi nodo. Si tratta di uno stato terminale. |
| AccessDenied | L'utente o il ruolo che avvia il comando non dispone dell'accesso al gruppo di risorse target. AccessDenied non viene conteggiato ai fini del limite di max-errors del comando padre, ma contribuisce a stabilire se lo stato del comando padre è Success o Failed. Ad esempio, se tutte le invocazioni in un comando dispongono dello statoAccessDenied, lo stato del comando restituito èFailed. Tuttavia, se un comando dispone di 5 invocazioni, 4 delle quali restituiscono lo statoAccessDeniede 1 dei quali restituisce lo statoSuccess, lo stato del comando genitore èSuccess.) Si tratta di uno stato terminale. |
| Nessuna istanza nel tag | Il valore del tag chiave-coppia o il gruppo di risorse cui fa riferimento il comando non corrisponde ad alcun nodo gestito. Si tratta di uno stato terminale. |
## Informazioni sui valori di timeout dei comandi
Systems Manager applica i seguenti valori di timeout durante l'esecuzione dei comandi.
**Timeout totale**
Nella console Systems Manager, specifica il valore di timeout nel campo **Timeout (secondi)**. Dopo l'invio di un comando, Run Command controlla se il comando è scaduto o meno. Se un comando raggiunge il limite di scadenza del comando (timeout totale), lo stato viene modificato in `DeliveryTimedOut` per tutte le chiamate che hanno lo stato`InProgress`, `Pending` o `Delayed`.
![\[Il campo Timeout (secondi) nella console di Systems Manager\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/run-command-delivery-time-out-time-out-seconds.png)
A livello più tecnico, il timeout complessivo, ossia **Timeout (secondi)**, è una combinazione di due valori di timeout, come illustrato di seguito:
`Total timeout = "Timeout(seconds)" from the console + "timeoutSeconds": "{{ executionTimeout }}" from your SSM document`
Ad esempio, il valore predefinito di **Timeout (secondi)**Nella console Systems Manager è di 600 secondi. Se si esegue un comando utilizzando il comando `AWS-RunShellScript` SSM, il valore predefinito di **"timeoutSeconds": "\$1\$1 executionTimeout \$1\$1"** è di 3.600 secondi, come mostrato nell'esempio del documento seguente:
```
"executionTimeout": {
"type": "String",
"default": "3600",
"runtimeConfig": {
"aws:runShellScript": {
"properties": [
{
"timeoutSeconds": "{{ executionTimeout }}"
```
Ciò significa che il comando viene eseguito per 4.200 secondi (70 minuti) prima che il sistema imposti lo stato del comando su `DeliveryTimedOut`.
**Timeout di esecuzione**
Nella console Systems Manager specificare il valore di timeout di esecuzione nel campo **Timeout di esecuzione**, se disponibile. Non tutti i documenti SSM richiedono di specificare un timeout di esecuzione. Il campo **Timeout di esecuzione** viene visualizzato solo quando un parametro di input corrispondente è stato definito nel documento SSM. Se specificato, il comando deve essere completato entro questo periodo di tempo.
**Nota**
Run Command si basa sulla risposta terminale del documento SSM Agent per determinare se il comando è stato recapitato o meno all'agente. SSM Agent deve inviare un segnale `ExecutionTimedOut` per una chiamata o un comando da contrassegnare come `ExecutionTimedOut`.
![\[Il campo Timeout di esecuzione nella console Systems Manager\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/run-command-execution-timeout-console.png)
**Timeout di esecuzione predefinito**
Se un documento SSM non richiede di specificare esplicitamente un valore di timeout di esecuzione, Systems Manager applica il timeout di esecuzione predefinito hard-coded.
**Come Systems Manager segnala i timeout**
Se Systems Manager riceve una risposta `execution timeout` da SSM Agent su una destinazione, Systems Manager contrassegna la chiamata del comando come `executionTimeout`.
Se Run Command non riceve una risposta terminale di documenti da SSM Agent, l'invocazione del comando è contrassegnata come `deliveryTimeout`.
Per determinare lo stato di timeout su una destinazione, SSM Agent combina tutti i parametri e il contenuto del documento SSM da calcolare per `executionTimeout`. Quando SSM Agent determina che un comando è scaduto, invia `executionTimeout` al servizio.
Il valore predefinito per **Timeout (secondi)** è 3.600 secondi. Il valore predefinito per **Timeout di esecuzione** è anche 3.600 secondi. Pertanto, il timeout predefinito totale per un comando è 7200 secondi.
**Nota**
SSM Agent elabora `executionTimeout` in modo diverso a seconda del tipo di documento SSM e della versione del documento.
# Spiegazioni passo per passo di Run Command
Le procedure guidate presenti in questa sezione illustrano come eseguire comandi con Run Command, uno strumento di AWS Systems Manager, utilizzando sia il AWS Command Line Interface (AWS CLI) che AWS Tools for Windows PowerShell.
**Topics**
+ [
# Aggiornamento del software utilizzando Run Command
](run-command-tutorial-update-software.md)
+ [
# Procedura dettagliata: utilizzare con AWS CLI Run Command
](walkthrough-cli.md)
+ [
# Procedura dettagliata: utilizzare con AWS Tools for Windows PowerShell Run Command
](walkthrough-powershell.md)
I comandi di esempio sono disponibili anche nei seguenti riferimenti.
+ [Systems ManagerAWS CLIRiferimento del](https://docs.aws.amazon.com/cli/latest/reference/ssm/)
+ [AWS Tools for Windows PowerShell - AWS Systems Manager](https://docs.aws.amazon.com/powershell/latest/reference/items/SimpleSystemsManagement_cmdlets.html)
# Aggiornamento del software utilizzando Run Command
Le procedure seguenti descrivono come aggiornare il software nei nodi gestiti.
## Aggiornamento di SSM Agent utilizzando Run Command
La procedura seguente descrive come aggiornare rapidamente SSM Agent in esecuzione sui tuoi nodi gestiti. È possibile eseguire l'aggiornamento alla versione più recente di SSM Agent o il downgrade a una versione precedente. Quando si esegue il comando, il sistema scarica la versione da AWS, la installa e quindi disinstalla la versione esistente prima dell'esecuzione del comando. Se si verifica un errore durante il processo, il sistema torna alla versione presente sul server prima dell'esecuzione di questo comando e lo stato del comando indica che il comando non è riuscito.
**Nota**
Se un'istanza sta eseguendo la versione 13.0 (Ventura) o successiva di macOS, l'istanza deve avere la versione SSM Agent 3.1.941.0 o successiva per eseguire il documento AWS-UpdateSSMAgent. Se l'istanza esegue una versione di SSM Agent precedente alla 3.1.941.0, è possibile aggiornare il tuo SSM Agent per eseguire il documento AWS-UpdateSSMAgent eseguendo i comandi `brew update` e `brew upgrade amazon-ssm-agent`.
Per ricevere notifiche sugli aggiornamenti dell'SSM Agent, iscriviti alla pagina [Note di rilascio dell'SSM Agent](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) su GitHub.
**Per aggiornare SSM Agent utilizzando Run Command**
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 **Run Command**.
1. Seleziona **Esegui comando**.
1. Nell'elenco **Command document (Documento comando)** scegliere **`AWS-UpdateSSMAgent`**.
1. Nella sezione **Command parameters (Parametri comando)** specificare i valori per i parametri seguenti, se necessario:
1. (Facoltativo) Per **Versione**, digita la versione di SSM Agent da installare. È possibile installare [versioni precedenti](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) dell'agente. Se non si specifica una versione, viene installata quella più recente.
1. (Facoltativo) Per **Consenti downgrade**, scegli **true** per installare una versione precedente di SSM Agent. Se si seleziona questa opzione, è necessario specificare il numero della versione [precedente](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md). Scegliere **false** per installare solo la versione più recente del servizio.
1. In **Targets (Destinazioni)**, scegliere i nodi gestiti in cui si desidera eseguire questa operazione specificando i tag, selezionando le istanze o i dispositivi edge manualmente o indicando un gruppo di risorse.
**Suggerimento**
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.
1. In **Altri parametri**:
+ In **Commento**, digita le informazioni su questo comando.
+ In **Timeout (secondi)**, specifica il numero di secondi che il sistema dovrà attendere prima di generare un errore per l'intera esecuzione del comando.
1. Per **Controllo velocità**:
+ In **Simultaneità**, specifica un numero o una percentuale di nodi gestiti su cui eseguire contemporaneamente il comando.
**Nota**
Se hai selezionato le destinazioni specificando i tag applicati ai nodi gestiti o specificando i gruppi di AWS risorse e non sei sicuro del numero di nodi gestiti come target, limita il numero di destinazioni che possono eseguire il documento contemporaneamente specificando una percentuale.
+ Per **Soglia di errore**, specificare quando interrompere l'esecuzione del comando sulle altri nodi gestiti dopo un errore su un numero o una percentuale di nodi. Se, ad esempio, si specificano tre errori, Systems Manager interrompe l'invio del comando quando riceve il quarto errore. Anche i nodi gestiti che stanno ancora elaborando il comando potrebbero inviare errori.
1. (Facoltativo) Nella sezione **Opzioni di output**, per salvare l'output del comando in un file, seleziona la casella **Scrivi l'output del comando in un bucket S3**. Digita i nomi del bucket e del prefisso (cartella) nelle caselle.
**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 per un ambiente ibrido](hybrid-multicloud-service-role.md). Inoltre, se il bucket S3 specificato si trova su un Account AWS diverso, assicurarsi che il profilo dell'istanza o il ruolo di servizio IAM associato al nodo gestito disponga delle autorizzazioni necessarie per scrivere su quel bucket.
1. Se vuoi che vengano inviate notifiche sullo stato dell'esecuzione del comando, nella sezione **Notifiche SNS** selezionara la casella di controllo **Abilita notifiche SNS**.
Per ulteriori informazioni sulla configurazione delle notifiche Amazon SNS per Run Command, consulta [Monitoraggio delle modifiche di stato di Systems Manager utilizzando le notifiche Amazon SNS](monitoring-sns-notifications.md).
1. Scegli **Esegui**.
## Aggiornamento tramite PowerShell Run Command
La procedura seguente descrive come eseguire l'aggiornamento PowerShell alla versione 5.1 sui nodi gestiti Windows Server 2012 e 2012 R2. Lo script fornito in questa procedura scarica l'aggiornamento 5.1 di Windows Management Framework (WMF) e avvia l'installazione dell'aggiornamento. Il nodo si riavvia durante questo processo perché questo è necessario durante l'installazione di WMF 5.1. Il download e l'installazione dell'aggiornamento richiedono circa cinque minuti.
**Per eseguire l'aggiornamento utilizzando PowerShell Run Command**
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 **Esegui comando**.
1. Nell'elenco **Command document (Documento comando)** scegliere **`AWS-RunPowerShellScript`**.
1. Nella**Comandi**Incollare i comandi seguenti per il sistema operativo in uso.
------
#### [ Windows Server 2012 R2 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839516" -OutFile "Win8.1AndW2K12R2-KB3191564-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('Win8.1AndW2K12R2-KB3191564-x64.msu', '/quiet')
```
------
#### [ Windows Server 2012 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839513" -OutFile "W2K12-KB3191565-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('W2K12-KB3191565-x64.msu', '/quiet')
```
------
1. In **Targets (Destinazioni)**, scegliere i nodi gestiti in cui si desidera eseguire questa operazione specificando i tag, selezionando le istanze o i dispositivi edge manualmente o indicando un gruppo di risorse.
**Suggerimento**
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.
1. In **Altri parametri**:
+ In **Commento**, digita le informazioni su questo comando.
+ In **Timeout (secondi)**, specifica il numero di secondi che il sistema dovrà attendere prima di generare un errore per l'intera esecuzione del comando.
1. Per **Controllo velocità**:
+ In **Simultaneità**, specifica un numero o una percentuale di nodi gestiti su cui eseguire contemporaneamente il comando.
**Nota**
Se hai selezionato le destinazioni specificando i tag applicati ai nodi gestiti o specificando i gruppi di AWS risorse e non sei sicuro del numero di nodi gestiti come target, limita il numero di destinazioni che possono eseguire il documento contemporaneamente specificando una percentuale.
+ Per **Soglia di errore**, specificare quando interrompere l'esecuzione del comando sulle altri nodi gestiti dopo un errore su un numero o una percentuale di nodi. Se, ad esempio, si specificano tre errori, Systems Manager interrompe l'invio del comando quando riceve il quarto errore. Anche i nodi gestiti che stanno ancora elaborando il comando potrebbero inviare errori.
1. (Facoltativo) Nella sezione **Opzioni di output**, per salvare l'output del comando in un file, seleziona la casella **Scrivi l'output del comando in un bucket S3**. Digita i nomi del bucket e del prefisso (cartella) nelle caselle.
**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 per un ambiente ibrido](hybrid-multicloud-service-role.md). Inoltre, se il bucket S3 specificato si trova su un Account AWS diverso, assicurarsi che il profilo dell'istanza o il ruolo di servizio IAM associato al nodo gestito disponga delle autorizzazioni necessarie per scrivere su quel bucket.
1. Se vuoi che vengano inviate notifiche sullo stato dell'esecuzione del comando, nella sezione **Notifiche SNS** selezionara la casella di controllo **Abilita notifiche SNS**.
Per ulteriori informazioni sulla configurazione delle notifiche Amazon SNS per Run Command, consulta [Monitoraggio delle modifiche di stato di Systems Manager utilizzando le notifiche Amazon SNS](monitoring-sns-notifications.md).
1. Scegli **Esegui**.
Dopo il riavvio del nodo gestito e il completamento dell'installazione dell'aggiornamento, connettiti al nodo per confermare che l'aggiornamento alla versione 5.1 è PowerShell stato eseguito correttamente. Per verificare la versione di PowerShell sul tuo nodo, apri PowerShell e accedi. `$PSVersionTable` Il valore `PSVersion` nella tabella di output mostra 5.1, se l'aggiornamento è riuscito.
Se il valore di `PSVersion` è diverso da 5.1, ad esempio 3.0 o 4.0, rivedi i log di **configurazione** nel Visualizzatore eventi in **Log di Windows**. Questi log indicano perché l'installazione dell'aggiornamento non è riuscita.
# Procedura dettagliata: utilizzare con AWS CLI Run Command
La procedura dettagliata di esempio seguente mostra come utilizzare il comando AWS Command Line Interface (AWS CLI) per visualizzare informazioni su comandi e parametri dei comandi, come eseguire comandi e come visualizzare lo stato di tali comandi.
**Importante**
Solo gli amministratori attendibili dovrebbero essere autorizzati a utilizzare i documenti AWS Systems Manager preconfigurati mostrati in questo argomento. I comandi o gli script specificati nei documenti Systems Manager vengono eseguiti con privilegi amministrativi sui nodi gestiti. Se un utente è autorizzato a eseguire uno dei documenti Systems Manager predefiniti (qualsiasi documento che inizia con `AWS-`), lo stesso utente avrà anche accesso al nodo come amministratore. Per tutti gli altri utenti, è consigliabile creare documenti restrittivi e condividerli con utenti specifici.
**Topics**
+ [
## Fase 1. Nozioni di base
](#walkthrough-cli-settings)
+ [
## Fase 2: esecuzione di script di shell per visualizzare i dettagli delle risorse
](#walkthrough-cli-run-scripts)
+ [
## Fase 3: invio di comandi semplici utilizzando il documento `AWS-RunShellScript`
](#walkthrough-cli-example-1)
+ [
## Fase 4: esecuzione di un semplice script Python usando Run Command
](#walkthrough-cli-example-2)
+ [
## Fase 5: esecuzione di uno script Bash usandoRun Command
](#walkthrough-cli-example-3)
## Fase 1. Nozioni di base
Devi disporre dei privilegi di amministratore sui nodi gestiti da configurare oppure delle autorizzazioni appropriate in AWS Identity and Access Management (IAM). Si noti inoltre che questo esempio utilizza la regione Stati Uniti orientali (Ohio) (us-east-2). Run Commandè disponibile negli [endpoint del servizio Systems Manager Regioni AWS](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) elencati in. *Riferimenti generali di Amazon Web Services* Per ulteriori informazioni, consulta [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Per eseguire comandi utilizzando AWS CLI**
1. 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).
1. Creare un elenco di tutti i documenti disponibili
Questo comando elenca tutti i documenti disponibili per il tuo account in base alle (IAM) autorizzazioni.
```
aws ssm list-documents
```
1. Verificare che un nodo gestito sia pronto a ricevere comandi
L'output del comando seguente mostra se i nodi gestiti sono online.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--output text --query "InstanceInformationList[*]"
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--output text --query "InstanceInformationList[*]"
```
------
1. Utilizzare il comando seguente per visualizzare i dettagli su uno determinato nodo gestito.
**Nota**
Per eseguire i comandi in questa procedura dettagliata, sostituisci l'istanza e il comando. IDs Per i dispositivi AWS IoT Greengrass core gestiti, utilizzate l'ID mi- *ID\$1number* for instance. L'ID comando viene restituito come risposta a **send-command**. IDs Le istanze sono disponibili pressoFleet Manager, uno strumento in AWS Systems Manager..
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--instance-information-filter-list key=InstanceIds,valueSet=instance-ID
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--instance-information-filter-list key=InstanceIds,valueSet=instance-ID
```
------
## Fase 2: esecuzione di script di shell per visualizzare i dettagli delle risorse
Se utilizzi Run Command e il documento `AWS-RunShellScript`, puoi eseguire qualsiasi comando o script su un nodo gestito come se fossi connesso localmente.
**Visualizzare la descrizione e i parametri disponibili**
Usa il comando seguente per visualizzare una descrizione del documento JSON .
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "[Document.Name,Document.Description]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "[Document.Name,Document.Description]"
```
------
Usa il comando seguente per visualizzare i parametri disponibili e i dettagli su tali parametri.
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "Document.Parameters[*]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "Document.Parameters[*]"
```
------
## Fase 3: invio di comandi semplici utilizzando il documento `AWS-RunShellScript`
Usa il comando seguente per ottenere le informazioni IP per un nodo gestito.
Se prendi come target un nodo gestito Windows Server, cambia il `document-name` a `AWS-RunPowerShellScript` e cambia il `command` da `ifconfig` a `ipconfig`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "IP config" \
--parameters commands=ifconfig \
--output text
```
------
#### [ Windows ]
```
aws ssm send-command ^
--instance-ids "instance-ID" ^
--document-name "AWS-RunShellScript" ^
--comment "IP config" ^
--parameters commands=ifconfig ^
--output text
```
------
**Ottenere informazioni sul comando con i dati di risposta**
Il comando seguente usa l'ID comando restituito dal comando precedente per ottenere i dettagli e i dati di risposta dell'esecuzione del comando. Il sistema restituisce i dati di risposta se il comando è stato completato. Se l'esecuzione del comando mostra `"Pending"` o `"InProgress"`, esegui di nuovo il comando per visualizzare i dati di risposta.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id $sh-command-id \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id $sh-command-id ^
--details
```
------
**Identificazione dell'utente**
Il comando seguente mostra l'utente predefinito che esegue i comandi.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux managed node" \
--parameters commands=whoami \
--output text \
--query "Command.CommandId")
```
------
**Ottenere lo stato del comando**
Il comando seguente usa l'ID comando per ottenere lo stato di esecuzione del comando sul nodo gestito. Questo esempio usa l'ID di comando restituito nel comando precedente.
------
#### [ Linux & macOS ]
```
aws ssm list-commands \
--command-id "command-ID"
```
------
#### [ Windows ]
```
aws ssm list-commands ^
--command-id "command-ID"
```
------
**Ottenere i dettagli del comando**
Il comando seguente usa l'ID comando del comando precedente per ottenere lo stato di esecuzione del comando per singoli nodo gestito.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id "command-ID" ^
--details
```
------
**Ottenere informazioni sul comando con i dati di risposta per un nodo gestito specifico**
Il comando seguente restituisce l'output della richiesta `aws ssm send-command` originale per un nodo gestito specifico.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--instance-id instance-ID \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--instance-id instance-ID ^
--command-id "command-ID" ^
--details
```
------
**Visualizzare la versione Python**
Il comando seguente restituisce la versione di Python in esecuzione su un nodo.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux Instances" \
--parameters commands='python -V' \
--output text --query "Command.CommandId") \
sh -c 'aws ssm list-command-invocations \
--command-id "$sh_command_id" \
--details \
--query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}"'
```
------
## Fase 4: esecuzione di un semplice script Python usando Run Command
Il seguente comando esegue un semplice script Python "Hello World" utilizzando Run Command.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux Instances" \
--parameters '{"commands":["#!/usr/bin/python","print \"Hello World from python\""]}' \
--output text \
--query "Command.CommandId") \
sh -c 'aws ssm list-command-invocations \
--command-id "$sh_command_id" \
--details \
--query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}"'
```
------
## Fase 5: esecuzione di uno script Bash usandoRun Command
Gli esempi in questa sezione mostrano come eseguire il seguente script bash usandoRun Command.
Per esempi di utilizzo diRun Commandper eseguire script archiviati in posizioni remote, vedere[Esecuzione di script da Amazon S3](integration-s3.md)e[Esecuzione di script da GitHub](integration-remote-scripts.md).
```
#!/bin/bash
yum -y update
yum install -y ruby
cd /home/ec2-user
curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install
chmod +x ./install
./install auto
```
*Questo script installa l' AWS CodeDeploy agente su Amazon Linux e Red Hat Enterprise Linux (RHEL) istanze, come descritto in [Creare un'istanza Amazon EC2](https://docs.aws.amazon.com/codedeploy/latest/userguide/instances-ec2-create.html) per la Guida CodeDeploy per l'utente.AWS CodeDeploy *
Lo script installa l' CodeDeploy agente da un bucket S3 AWS gestito nella regione Stati Uniti orientali (Ohio) (us-east-2),. `aws-codedeploy-us-east-2`
**Esegui uno script bash in un comando AWS CLI **
Nell'esempio seguente viene illustrato come includere lo script bash in un comando CLI utilizzando l'opzione `--parameters`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets '[{"Key":"InstanceIds","Values":["instance-id"]}]' \
--parameters '{"commands":["#!/bin/bash","yum -y update","yum install -y ruby","cd /home/ec2-user","curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install","chmod +x ./install","./install auto"]}'
```
------
**Esegui uno script bash in un file JSON**
Nell'esempio seguente, il contenuto dello script bash viene archiviato in un file JSON e il file viene incluso nel comando usando l'`--cli-input-json`opzione.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets "Key=InstanceIds,Values=instance-id" \
--cli-input-json file://installCodeDeployAgent.json
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--cli-input-json file://installCodeDeployAgent.json
```
------
Il comando `installCodeDeployAgent.json` che fa riferimento al file JSON viene visualizzato nell'esempio seguente.
```
{
"Parameters": {
"commands": [
"#!/bin/bash",
"yum -y update",
"yum install -y ruby",
"cd /home/ec2-user",
"curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install",
"chmod +x ./install",
"./install auto"
]
}
}
```
# Procedura dettagliata: utilizzare con AWS Tools for Windows PowerShell Run Command
Negli esempi seguenti viene illustrato come utilizzare AWS Tools for Windows PowerShell per visualizzare informazioni su comandi e parametri dei comandi, come eseguire comandi e come visualizzare lo stato di tali comandi. Questa procedura guidata include un esempio per ognuno dei documenti AWS Systems Manager predefiniti.
**Importante**
Solo gli amministratori fidati dovrebbero essere autorizzati a usare i documenti Systems Manager preconfigurati mostrati in questo argomento. I comandi o gli script specificati nei documenti Systems Manager vengono eseguiti con privilegi amministrativi sui nodi gestiti. Se un utente è autorizzato a eseguire uno qualsiasi dei documenti predefiniti di Systems Manager (qualsiasi documento che inizia con AWS), allora quell'utente ha anche l'accesso come amministratore al nodo. Per tutti gli altri utenti, è consigliabile creare documenti restrittivi e condividerli con utenti specifici.
**Topics**
+ [
## Configura le impostazioni AWS Tools for Windows PowerShell della sessione
](#walkthrough-powershell-settings)
+ [
## Creare un elenco di tutti i documenti disponibili
](#walkthrough-powershell-all-documents)
+ [
## Esegue PowerShell comandi o script
](#walkthrough-powershell-run-script)
+ [
## Installare un'applicazione usando`AWS-InstallApplication`documento
](#walkthrough-powershell-install-application)
+ [
## Installa un PowerShell modulo utilizzando il documento `AWS-InstallPowerShellModule` JSON
](#walkthrough-powershell-install-module)
+ [
## Aggiungere un nodo gestito a un dominio usando il Documento JSON `AWS-JoinDirectoryServiceDomain`
](#walkthrough-powershell-domain-join)
+ [
## Invia i parametri di Windows ad Amazon CloudWatch Logs utilizzando il documento `AWS-ConfigureCloudWatch`
](#walkthrough-powershell-windows-metrics)
+ [
## Attivare o disattivare l'aggiornamento automatico di Windows utilizzando il`AWS-ConfigureWindowsUpdate`documento
](#walkthrough-powershell-enable-windows-update)
+ [
## Gestire gli aggiornamenti di Windows usando Run Command
](#walkthough-powershell-windows-updates)
## Configura le impostazioni AWS Tools for Windows PowerShell della sessione
**Specificare le credenziali**
Apri **Tools for Windows PowerShell** sul tuo computer locale ed esegui il comando seguente per specificare le tue credenziali. È necessario disporre delle autorizzazioni di amministratore sui nodi gestiti che si desidera configurare oppure è necessario disporre dell'autorizzazione appropriata in AWS Identity and Access Management (IAM). Per ulteriori informazioni, consulta [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md).
```
Set-AWSCredentials –AccessKey key-name –SecretKey key-name
```
**Imposta un valore predefinito Regione AWS**
Esegui il comando seguente per impostare la regione per la PowerShell sessione. L'esempio utilizza la regione degli Stati Uniti orientali (Ohio) (us-east-2). Run Commandè disponibile negli [endpoint del servizio Systems Manager Regioni AWS](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) elencati in. *Riferimenti generali di Amazon Web Services*
```
Set-DefaultAWSRegion `
-Region us-east-2
```
## Creare un elenco di tutti i documenti disponibili
Questo comando elenca tutti i documenti disponibili per il tuo account:
```
Get-SSMDocumentList
```
## Esegue PowerShell comandi o script
Se utilizzi Run Command e il documento `AWS-RunPowerShell`, è possibile eseguire qualsiasi comando o script su un nodo gestito come se fossi connesso localmente. È possibile inviare comandi o digitare il percorso di uno script locale per eseguire il comando.
**Nota**
Per ulteriori informazioni sul riavvio dei nodi gestiti quando usi Run Command per chiamare gli script, consulta [Gestione di riavvii durante l'esecuzione dei comandi](send-commands-reboot.md).
**Visualizzare la descrizione e i parametri disponibili**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript"
```
**Visualizzare ulteriori informazioni sui parametri**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript" | Select -ExpandProperty Parameters
```
### Invia comandi utilizzando il documento `AWS-RunPowerShellScript`
Il comando seguente mostra il contenuto della directory `"C:\Users"` e il contenuto della directory `"C:\"` su due nodi gestiti.
```
$runPSCommand = Send-SSMCommand `
-InstanceIds @("instance-ID-1", "instance-ID-2") `
-DocumentName "AWS-RunPowerShellScript" `
-Comment "Demo AWS-RunPowerShellScript with two instances" `
-Parameter @{'commands'=@('dir C:\Users', 'dir C:\')}
```
**Ottenere i dettagli della richiesta del comando**
Il comando seguente usa `CommandId` per ottenere lo stato di esecuzione del comando su entrambi i nodi gestiti. Questo esempio usa `CommandId` restituito nel comando precedente.
```
Get-SSMCommand `
-CommandId $runPSCommand.CommandId
```
Lo stato del comando in questo esempio può essere Success, Pending o. InProgress
**Ottenere informazioni sul comando per nodo gestito**
Il comando seguente usa `CommandId` del comando precedente per ottenere lo stato di esecuzione del comando per singoli nodi gestiti.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId
```
**Ottenere informazioni sul comando con i dati di risposta per un nodo gestito specifico**
Il comando seguente restituisce l'output del comando `Send-SSMCommand` originale per un nodo gestito specifico.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### Annullare un comando
Il comando seguente annulla `Send-SSMCommand` per il documento `AWS-RunPowerShellScript`.
```
$cancelCommand = Send-SSMCommand `
-InstanceIds @("instance-ID-1","instance-ID-2") `
-DocumentName "AWS-RunPowerShellScript" `
-Comment "Demo AWS-RunPowerShellScript with two instances" `
-Parameter @{'commands'='Start-Sleep –Seconds 120; dir C:\'}
Stop-SSMCommand -CommandId $cancelCommand.CommandId
```
**Controllare lo stato del comando**
Il comando seguente controlla lo stato del comando `Cancel`
```
Get-SSMCommand `
-CommandId $cancelCommand.CommandId
```
## Installare un'applicazione usando`AWS-InstallApplication`documento
Utilizzando Run Command e il documento `AWS-InstallApplication`, è possibile installare, riparare o disinstallare applicazioni su nodi gestiti. Il comando richiede il percorso o l'indirizzo di un file MSI.
**Nota**
Per ulteriori informazioni sul riavvio dei nodi gestiti quando usi Run Command per chiamare gli script, consulta [Gestione di riavvii durante l'esecuzione dei comandi](send-commands-reboot.md).
**Visualizzare la descrizione e i parametri disponibili**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication"
```
**Visualizzare ulteriori informazioni sui parametri**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication" | Select -ExpandProperty Parameters
```
### Invia comandi utilizzando il documento `AWS-InstallApplication`
Il comando seguente installa una versione di Python nel nodo gestito in modalità automatica e registra l'output in un file di testo locale nell'unità `C:`.
```
$installAppCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallApplication" `
-Parameter @{'source'='https://www.python.org/ftp/python/2.7.9/python-2.7.9.msi'; 'parameters'='/norestart /quiet /log c:\pythoninstall.txt'}
```
**Ottenere informazioni sul comando per nodo gestito**
Il comando seguente usa `CommandId` per ottenere lo stato di esecuzione del comando.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true
```
**Ottenere informazioni sul comando con i dati di risposta per un nodo gestito specifico**
Il comando seguente restituisce i risultati dell'installazione di Python.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
## Installa un PowerShell modulo utilizzando il documento `AWS-InstallPowerShellModule` JSON
È possibile utilizzare Run Command per installare PowerShell moduli su nodi gestiti. Per ulteriori informazioni sui PowerShell moduli, consulta [ PowerShell Moduli di Windows](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_modules?view=powershell-6).
**Visualizzare la descrizione e i parametri disponibili**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule"
```
**Visualizzare ulteriori informazioni sui parametri**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule" | Select -ExpandProperty Parameters
```
### Installa un PowerShell modulo
Il comando seguente scarica il file EZOut con estensione zip, lo installa e quindi esegue un comando aggiuntivo per installare il visualizzatore XPS. Infine, l'output di questo comando viene caricato in un bucket S3 denominato “amzn-s3-demo-bucket”.
```
$installPSCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallPowerShellModule" `
-Parameter @{'source'='https://gallery.technet.microsoft.com/EZOut-33ae0fb7/file/110351/1/EZOut.zip';'commands'=@('Add-WindowsFeature -name XPS-Viewer -restart')} `
-OutputS3BucketName amzn-s3-demo-bucket
```
**Ottenere informazioni sul comando per nodo gestito**
Il comando seguente usa `CommandId` per ottenere lo stato di esecuzione del comando.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true
```
**Ottenere informazioni sul comando con i dati di risposta per il nodo gestito**
Il comando seguente restituisce l'output del comando `Send-SSMCommand` originale per il `CommandId` specifico.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## Aggiungere un nodo gestito a un dominio usando il Documento JSON `AWS-JoinDirectoryServiceDomain`
UtilizzandoRun Command, è possibile aggiungere rapidamente un nodo gestito a un dominio. AWS Directory Service Prima di eseguire il comando, è necessario [creare una directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html). Ti consigliamo anche di consultare Directory Service. Per ulteriori informazioni, consulta la [Guida di amministrazione di AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/).
Al momento è possibile solo aggiungere un nodo gestito a un dominio. Non è possibile rimuovere un nodo gestito da un dominio.
**Nota**
Per informazioni sui nodi gestiti durante l'utilizzo di Run Command per chiamare script, vedi [Gestione di riavvii durante l'esecuzione dei comandi](send-commands-reboot.md).
**Visualizzare la descrizione e i parametri disponibili**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain"
```
**Visualizzare ulteriori informazioni sui parametri**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain" | Select -ExpandProperty Parameters
```
### Unisci un nodo gestito a un dominio
Il comando seguente unisce un nodo gestito al Directory Service dominio specificato e carica qualsiasi output generato nel bucket di esempio Amazon Simple Storage Service (Amazon S3).
```
$domainJoinCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-JoinDirectoryServiceDomain" `
-Parameter @{'directoryId'='d-example01'; 'directoryName'='ssm.example.com'; 'dnsIpAddresses'=@('192.168.10.195', '192.168.20.97')} `
-OutputS3BucketName amzn-s3-demo-bucket
```
**Ottenere informazioni sul comando per nodo gestito**
Il comando seguente usa `CommandId` per ottenere lo stato di esecuzione del comando.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true
```
**Ottenere informazioni sul comando con i dati di risposta per il nodo gestito**
Questo comando restituisce l'output dell'originale `Send-SSMCommand` per lo specifico `CommandId`.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## Invia i parametri di Windows ad Amazon CloudWatch Logs utilizzando il documento `AWS-ConfigureCloudWatch`
Puoi inviare Windows Server messaggi nei log di applicazione, sistema, sicurezza ed Event Tracing for Windows (ETW) ad Amazon Logs. CloudWatch Quando abiliti la registrazione per la prima volta, invia tutti i log generati entro un (1) minuto dal momento in cui inizi il caricamento per i log applicazioni, di sistema, di sicurezza e di ETW. I log precedenti a questo intervallo non sono inclusi. Se disabiliti la registrazione e la riattivi in seguito, Systems Manager invia i log dal momento che è stata interrotta. Per tutti i file di log personalizzati e log IIS (Internet Information Services), Systems Manager legge i file di log dall'inizio. Inoltre, Systems Manager può anche inviare i dati del contatore delle prestazioni ai CloudWatch registri.
Se in precedenza hai attivato CloudWatch l'integrazione in EC2 Config, le impostazioni di Systems Manager sostituiscono tutte le impostazioni archiviate localmente sul nodo gestito nel file. `C:\Program Files\Amazon\EC2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json` *Per ulteriori informazioni sull'utilizzo di EC2 Config per gestire i contatori delle prestazioni e i log su un singolo nodo gestito, consulta [Raccolta di metriche e log dalle istanze Amazon EC2 e dai server locali con l'agente nella Amazon User](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) Guide. CloudWatch CloudWatch *
**Visualizzare la descrizione e i parametri disponibili**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch"
```
**Visualizzare ulteriori informazioni sui parametri**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch" | Select -ExpandProperty Parameters
```
### Invia i log delle applicazioni a CloudWatch
Il comando seguente configura il nodo gestito e sposta i registri delle applicazioni Windows in. CloudWatch
```
$cloudWatchCommand = Send-SSMCommand `
-InstanceID instance-ID `
-DocumentName "AWS-ConfigureCloudWatch" `
-Parameter @{'properties'='{"engineConfiguration": {"PollInterval":"00:00:15", "Components":[{"Id":"ApplicationEventLog", "FullName":"AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"LogName":"Application", "Levels":"7"}},{"Id":"CloudWatch", "FullName":"AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch", "Parameters":{"Region":"region", "LogGroup":"my-log-group", "LogStream":"instance-id"}}], "Flows":{"Flows":["ApplicationEventLog,CloudWatch"]}}}'}
```
**Ottenere informazioni sul comando per nodo gestito**
Il comando seguente usa `CommandId` per ottenere lo stato di esecuzione del comando.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true
```
**Ottenere informazioni sul comando con i dati di risposta per un nodo gestito specifico**
Il comando seguente restituisce i risultati della CloudWatch configurazione di Amazon.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### Invia i contatori delle prestazioni all' CloudWatch utilizzo del documento `AWS-ConfigureCloudWatch`
Il seguente comando dimostrativo carica i contatori delle prestazioni su. CloudWatch Per ulteriori informazioni, consulta la *[Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)*.
```
$cloudWatchMetricsCommand = Send-SSMCommand `
-InstanceID instance-ID `
-DocumentName "AWS-ConfigureCloudWatch" `
-Parameter @{'properties'='{"engineConfiguration": {"PollInterval":"00:00:15", "Components":[{"Id":"PerformanceCounter", "FullName":"AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"CategoryName":"Memory", "CounterName":"Available MBytes", "InstanceName":"", "MetricName":"AvailableMemory", "Unit":"Megabytes","DimensionName":"", "DimensionValue":""}},{"Id":"CloudWatch", "FullName":"AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"AccessKey":"", "SecretKey":"","Region":"region", "NameSpace":"Windows-Default"}}], "Flows":{"Flows":["PerformanceCounter,CloudWatch"]}}}'}
```
## Attivare o disattivare l'aggiornamento automatico di Windows utilizzando il`AWS-ConfigureWindowsUpdate`documento
Con Run Command e il documento `AWS-ConfigureWindowsUpdate` è possibile abilitare o disabilitare gli aggiornamenti automatici di Windows nei nodi gestiti Windows Server. Questo comando configura l'agente di aggiornamento di Windows in modo da scaricare e installare gli aggiornamenti di Windows nel giorno e all'ora specificati. Se un aggiornamento richiede il riavvio, il nodo gestito si riavvia automaticamente 15 minuti dopo l'installazione degli aggiornamenti. Con questo comando è possibile anche configurare Windows Update in modo da controllare la disponibilità di aggiornamenti senza installarli. Il documento `AWS-ConfigureWindowsUpdate` è ufficialmente supportato in Windows Server 2012 e nelle versioni successive.
**Visualizzare la descrizione e i parametri disponibili**
```
Get-SSMDocumentDescription `
–Name "AWS-ConfigureWindowsUpdate"
```
**Visualizzare ulteriori informazioni sui parametri**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureWindowsUpdate" | Select -ExpandProperty Parameters
```
### Attivare l'aggiornamento automatico di Windows
Il comando seguente configura Windows Update in modo da scaricare e installare automaticamente gli aggiornamenti ogni giorno alle 10:00.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='InstallUpdatesAutomatically'; 'scheduledInstallDay'='Daily'; 'scheduledInstallTime'='22:00'}
```
**Visualizzare lo stato del comando per abilitare l'aggiornamento automatico di Windows**
Il comando seguente usa `CommandId` per ottenere lo stato di esecuzione del comando e abilitare l'aggiornamento automatico di Windows.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
### Disabilitare l'aggiornamento automatico di Windows
Il comando seguente riduce il livello della notifica di Windows Update in modo che il sistema verifichi la disponibilità di aggiornamenti senza aggiornare automaticamente il nodo gestito.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='NeverCheckForUpdates'}
```
**Visualizzare lo stato del comando per disabilitare l'aggiornamento automatico di Windows**
Il comando seguente usa `CommandId` per ottenere lo stato di esecuzione del comando e abilitare l'aggiornamento automatico di Windows.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
## Gestire gli aggiornamenti di Windows usando Run Command
Utilizzando Run Command e il documento `AWS-InstallWindowsUpdates` è possibile gestire gli aggiornamenti per i nodi gestiti Windows Server. Questo comando analizza o installa gli aggiornamenti mancanti sui nodi gestiti e, facoltativamente, si riavvia dopo l'installazione. È possibile anche specificare le classificazioni e i livelli di gravità appropriati per gli aggiornamenti da installare nell'ambiente.
**Nota**
Per ulteriori informazioni sul riavvio dei nodi gestiti quando usi Run Command per chiamare gli script, consulta [Gestione di riavvii durante l'esecuzione dei comandi](send-commands-reboot.md).
Gli esempi seguenti dimostrano come eseguire le attività di gestione di Windows Update specificate.
### Cercare tutti gli aggiornamenti di Windows mancanti
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Scan'}
```
### Installare specifici aggiornamenti di Windows
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'IncludeKbs'='kb-ID-1,kb-ID-2,kb-ID-3';'AllowReboot'='True'}
```
### Installare importanti aggiornamenti di Windows mancanti
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'SeverityLevels'='Important';'AllowReboot'='True'}
```
### Installare gli aggiornamenti di Windows mancanti con specifiche esclusioni
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'ExcludeKbs'='kb-ID-1,kb-ID-2';'AllowReboot'='True'}
```
# Risoluzione dei problemi di Systems Manager
Run Command, uno strumento in AWS Systems Manager, fornisce dettagli sullo stato di ogni esecuzione di comando. Per ulteriori informazioni sui dettagli degli stati dei comandi, consulta [Informazioni sugli stati dei comandi](monitor-commands.md). Puoi usare anche le informazioni in questo argomento per la risoluzione dei problemi relativi a Run Command.
**Topics**
+ [
## Alcuni dei miei nodi gestiti mancano
](#where-are-instances)
+ [
## Una fase nel mio script non è riuscita, ma lo stato generale è "riuscito"
](#ts-exit-codes)
+ [
## SSM Agent non funziona correttamente
](#ts-ssmagent-linux)
## Alcuni dei miei nodi gestiti mancano
Nella pagina **Esegui un comando**, dopo avere scelto un documento SSM da eseguire e aver selezionato **Selezione manuale delle istanze)** nella sezione **Destinazioni**, viene visualizzato un elenco dei nodi gestiti su cui puoi decidere di eseguire il comando.
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.
Dopo aver creato, attivato, riavviato o riavviato un nodo gestito, installato Run Command su un nodo o collegato un profilo di istanza AWS Identity and Access Management (IAM) a un nodo, possono essere necessari alcuni minuti prima che il nodo gestito venga aggiunto all'elenco.
## Una fase nel mio script non è riuscita, ma lo stato generale è "riuscito"
È possibile utilizzare Run Command per definire come i codici di uscita vengono gestiti dagli script. Per impostazione predefinita, il codice di uscita dell'ultimo comando eseguito in uno script viene segnalato come codice di uscita per l'intero script. È tuttavia possibile includere un'istruzione condizionale per uscire dallo script se un comando precedente a quello finale non riesce. Per maggiori informazioni ed esempi, consulta [Specifica dei codici di uscita nei comandi](run-command-handle-exit-status.md#command-exit-codes).
## SSM Agent non funziona correttamente
Se si verificano problemi durante l'esecuzione di comandi con Run Command, è possibile che sia presente un problema relativo a SSM Agent. Per informazioni su come indagare i problemi con SSM Agent, consulta [Risoluzione dei problemi relativi a SSM Agent](troubleshooting-ssm-agent.md).
# AWS Systems Manager Session Manager
Session Managerè uno AWS Systems Manager strumento completamente gestito. ConSession Manager, puoi gestire istanze Amazon Elastic Compute Cloud (Amazon EC2), dispositivi edge, server locali e macchine virtuali (). VMs Puoi utilizzare una shell interattiva basata su browser con un solo clic o il (). AWS Command Line Interface AWS CLISession Managerfornisce una gestione sicura dei nodi senza la necessità di aprire le porte in entrata, mantenere gli host bastion o gestire le chiavi SSH. Session Managerconsente inoltre di rispettare le politiche aziendali che richiedono l'accesso controllato ai nodi gestiti, pratiche di sicurezza rigorose e log con i dettagli di accesso ai nodi, fornendo al contempo agli utenti finali un semplice accesso multipiattaforma con un clic ai nodi gestiti. Per cominciare a utilizzare Session Manager, apri la [console di Systems Manager](https://console.aws.amazon.com/systems-manager/session-manager). Nel pannello di navigazione, scegli **Session Manager**.
## Quali sono i vantaggi di Session Manager per la mia organizzazione?
Session Manager offre questi vantaggi:
+ **Controllo degli accessi centralizzato ai nodi che utilizzano policy IAM**
Gli amministratori dispongono di un'unica posizione da cui concedere e revocare l'accesso ai nodi gestiti. Utilizzando solo le policy AWS Identity and Access Management (IAM), puoi controllare quali singoli utenti o gruppi dell'organizzazione possono utilizzare Session Manager e a quali nodi gestiti possono accedere.
+ **Nessuna porta in entrata aperta e nessuna necessità di gestire bastion host o chiavi SSH**
Lasciando le porte PowerShell remote o SSH in entrata aperte sui nodi gestiti aumenta notevolmente il rischio che le entità eseguano comandi non autorizzati o dannosi sui nodi gestiti. Session Manager ti aiuta a migliorare la tua posizione di sicurezza consentendoti di chiudere le porte in entrata e liberandoti quindi dalla gestione di certificati e chiavi SSH, host bastione e jumpbox.
+ **Accesso con un clic ai nodi gestiti dalla console e dall'interfaccia a riga di comando (CLI)**
Utilizzando la AWS Systems Manager console o la console Amazon EC2, puoi avviare una sessione con un solo clic. Utilizzando AWS CLI, puoi anche avviare una sessione che esegue un singolo comando o una sequenza di comandi. Poiché le autorizzazioni ai nodi gestiti vengono fornite tramite le policy IAM anziché le chiavi SSH o altri meccanismi, il tempo di connessione viene notevolmente ridotto.
+ **Connessione sia alle istanze Amazon EC2 che ai nodi gestiti non EC2 in ambienti [ibridi e multicloud](operating-systems-and-machine-types.md#supported-machine-types)**
È possibile connetterti sia alle istanze Amazon Elastic Compute Cloud (Amazon EC2) che ai nodi non EC2 nell’ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types).
Per connettersi a nodi non EC2 utilizzando Session Manager, è necessario innanzitutto attivare il piano istanze avanzate. **Viene addebitato un costo per l'utilizzo del livello dei parametri avanzati.** Non sono però previsti costi aggiuntivi per la connessione alle istanze EC2 tramite Session Manager. Per informazioni, consulta [Configurazione dei livelli di istanza](fleet-manager-configure-instance-tiers.md).
+ **Inoltro alla porta**
Reindirizzare qualsiasi porta all'interno del nodo gestito a una porta locale su un client. Successivamente, connettersi alla porta locale e accedere all'applicazione server in esecuzione all'interno del nodo.
+ **Supporto multipiattaforma per Windows, Linux e macOS**
Session Manager fornisce supporto per Windows, Linux e macOS da un unico strumento. Ad esempio, non è necessario utilizzare un client SSH per i nodi gestiti Linux e macOS o una connessione RDP per i nodi gestiti Windows Server.
+ **Attività di registrazione delle sessioni**
Per soddisfare i requisiti operativi o di sicurezza della tua organizzazione, potresti dover fornire un registro delle connessioni effettuate ai nodi gestiti e dei comandi che sono stati eseguiti su di essi. È possibile anche ricevere notifiche quando un utente nella tua organizzazione inizia o termina un'attività della sessione.
Le funzionalità di registrazione vengono fornite tramite l'integrazione con i seguenti Servizi AWS:
+ **AWS CloudTrail**— AWS CloudTrail acquisisce informazioni sulle chiamate Session Manager API effettuate nel tuo Account AWS e le scrive in file di log archiviati in un bucket Amazon Simple Storage Service (Amazon S3) da te specificato. Un bucket viene utilizzato per tutti i CloudTrail log del tuo account. Per ulteriori informazioni, consulta [Registrazione delle chiamate AWS Systems Manager API con AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **Amazon Simple Storage Service**: è possibile decidere di archiviare i dati di log delle sessioni in un bucket Amazon S3 di tua scelta a scopi di debug e risoluzione dei problemi. I dati di log possono essere inviati al tuo bucket Amazon S3 con o senza crittografia utilizzando la tua chiave AWS KMS key. Per ulteriori informazioni, consulta [Registrazione dei dati delle sessioni mediante Amazon S3 (console)](session-manager-logging-s3.md).
+ **Amazon CloudWatch Logs**: CloudWatch Logs ti consente di monitorare, archiviare e accedere a file di registro da diversi. Servizi AWS Puoi inviare i dati dei log di sessione a un gruppo di log CloudWatch Logs per scopi di debug e risoluzione dei problemi. I dati di registro possono essere inviati al gruppo di log con o senza AWS KMS crittografia utilizzando la chiave KMS. Per ulteriori informazioni, consulta [Registrazione dei dati della sessione tramite Amazon CloudWatch Logs (console)](session-manager-logging-cloudwatch-logs.md).
+ **Amazon EventBridge** e **Amazon Simple Notification Service**: ti EventBridge consente di configurare regole per rilevare quando vengono apportate modifiche alle AWS risorse specificate. È possibile creare una regola per rilevare quando un utente della tua organizzazione avvia o arresta una sessione e quindi ricevere una notifica tramite Amazon SNS (ad esempio, un testo o un messaggio e-mail) sull'evento. Puoi anche configurare un CloudWatch evento per avviare altre risposte. Per ulteriori informazioni, consulta [Monitoraggio dell'attività della sessione tramite Amazon EventBridge (console)](session-manager-auditing.md#session-manager-auditing-eventbridge-events).
**Nota**
La registrazione non è disponibile per sessioni Session Manager che si connettono tramite port forwarding o SSH. Questo perché SSH crittografa tutti i dati della sessione all'interno della connessione TLS sicura stabilita tra gli Session Manager endpoint AWS CLI e funge Session Manager solo da tunnel per le connessioni SSH.
## A chi è consigliato l'uso di Session Manager?
+ Qualsiasi AWS cliente che desideri migliorare il proprio livello di sicurezza, ridurre il sovraccarico operativo centralizzando il controllo degli accessi sui nodi gestiti e ridurre l'accesso ai nodi in entrata.
+ Gli esperti di sicurezza delle informazioni che desiderano monitorare e tracciare l'accesso e le attività dei nodi e chiudere le porte in entrata sui nodi gestiti o permettere le connessioni ai nodi gestiti che non dispongono di un indirizzo IP pubblico.
+ Gli amministratori che desiderano concedere e revocare l'accesso da una singola postazione e fornire agli utenti una soluzione per i nodi gestiti Linux, macOS e Windows Server.
+ Utenti che desiderano connettersi a un nodo gestito con un solo clic dal browser o AWS CLI senza dover fornire chiavi SSH.
## Quali sono le funzionalità principali di Session Manager?
+ **Supporto per i nodi gestiti Windows Server, Linux e macOS**
Session Managerti consente di stabilire connessioni sicure alle istanze Amazon Elastic Compute Cloud (EC2), ai dispositivi edge, ai server locali e alle macchine virtuali (). VMs Per un elenco dei tipi di sistema operativo dell'istanza supportati, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
**Nota**
Il supporto Session Manager per server on-premises è fornito solo per il piano istanze avanzate. Per informazioni, consulta [Attivazione del piano istanze avanzate](fleet-manager-enable-advanced-instances-tier.md).
+ **Accesso alle funzionalità del Session Manager tramite console, interfaccia a riga di comando (CLI) e SDK**
È possibile utilizzare Session Manager nei modi seguenti:
La **console AWS Systems Manager ** include l'accesso a tutte le funzionalità del Session Manager sia per gli amministratori sia per gli utenti finali. Tramite la console Systems Manager, è possibile eseguire qualsiasi processo correlato alle tue sessioni.
La console Amazon EC2 consente agli utenti finali di connettersi alle istanze EC2 per le quali sono state concesse autorizzazioni di sessione.
**AWS CLI** include l'accesso alle funzionalità del Session Manager per gli utenti finali. Puoi avviare una sessione, visualizzare un elenco di sessioni e terminare definitivamente una sessione utilizzando. AWS CLI
**Nota**
Per utilizzare i comandi AWS CLI to run session, devi utilizzare la versione 1.16.12 della CLI (o successiva) e devi aver installato il Session Manager plug-in sul tuo computer locale. Per informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md). Per visualizzare il plugin suGitHub, vedi. [session-manager-plugin](https://github.com/aws/session-manager-plugin)
+ **Controllo degli accessi IAM**
Mediante le policy IAM, è possibile controllare quali membri della tua organizzazione possono avviare sessioni ai nodi gestiti e a quali nodi possono accedere. È possibile anche fornire un accesso temporaneo ai tuoi nodi gestiti. Ad esempio, è possibile assegnare a un tecnico reperibile (o a un gruppo di tecnici reperibili) l'accesso al server di produzione solo per la durata della loro rotazione.
+ **Supporto per la registrazione**
Session Manager fornisce le opzioni per la registrazione delle cronologie delle sessioni nell' Account AWS , attraverso l'integrazione con diversi altri Servizi AWS. Per ulteriori informazioni, consultare [Attività di registrazione delle sessioni](session-manager-auditing.md) e [Abilitazione e disabilitazione della registrazione di sessione](session-manager-logging.md).
+ **Profili della shell configurabili**
Session Manager fornisce opzioni per configurare le preferenze all'interno delle sessioni. Questi profili personalizzabili permettono di definire preferenze quali le preferenze della shell, le variabili di ambiente, le directory di lavoro ed eseguire più comandi all'avvio di una sessione.
+ **Supporto per la crittografia dei dati della chiave del cliente**
Puoi configurare Session Manager la crittografia dei log dei dati di sessione che invii a un bucket Amazon Simple Storage Service (Amazon S3) o trasmetti in streaming a un gruppo di log Logs. CloudWatch È possibile anche configurare Session Manager per crittografare ulteriormente i dati trasmessi tra computer client e i tuoi nodi gestiti durante le sessioni. Per informazioni, consulta [Abilitazione e disabilitazione della registrazione di sessione](session-manager-logging.md) e [Configurare le preferenze delle sessioni](session-manager-getting-started-configure-preferences.md).
+ **AWS PrivateLink supporto per nodi gestiti senza indirizzi IP pubblici**
Puoi anche configurare VPC Endpoints for Systems Manager utilizzando AWS PrivateLink per proteggere ulteriormente le tue sessioni. AWS PrivateLink limita tutto il traffico di rete tra i nodi gestiti, Systems Manager e Amazon EC2 alla rete Amazon. Per ulteriori informazioni, consulta [Migliora la sicurezza delle istanze EC2 utilizzando gli endpoint VPC per Systems Manager](setup-create-vpc.md).
+ **Tunneling**
In una sessione, usa un documento di tipo sessione AWS Systems Manager (SSM) per effettuare il tunneling del traffico, ad esempio http o un protocollo personalizzato, tra una porta locale su un computer client e una porta remota su un nodo gestito.
+ **Comandi interattivi**
Crea un documento SSM di tipo sessione che utilizza una sessione per eseguire in modo interattivo un singolo comando, offrendo un modo per gestire ciò che gli utenti possono eseguire su un nodo gestito.
## Che cos'è una sessione?
Una sessione è una connessione effettuata a un nodo gestito utilizzando Session Manager. Le sessioni si basano su un canale di comunicazione bidirezionale sicuro tra il client (l'utente) e il nodo gestito remoto che trasmette input e output per i comandi. Il traffico tra un client e un nodo gestito viene crittografato utilizzando TLS 1.2 e le richieste per creare la connessione sono firmate utilizzando Sigv4. Questa comunicazione bidirezionale consente una bash interattiva e PowerShell l'accesso ai nodi gestiti. Puoi anche utilizzare una chiave AWS Key Management Service (AWS KMS) per crittografare ulteriormente i dati oltre alla crittografia TLS predefinita.
Ad esempio, supponi che John sia un tecnico reperibile del tuo reparto IT. Riceve una notifica di un problema che richiede di connettersi da remoto a un nodo gestito, ad esempio un errore che richiede la risoluzione del problema o una direttiva per modificare una semplice opzione di configurazione su un nodo gestito. Utilizzando la AWS Systems Manager console, la console Amazon EC2 o John avvia una sessione collegandolo al nodo gestito, esegue i comandi sul nodo necessari per completare l'attività e quindi termina la sessione. AWS CLI
Quando John invia il primo comando per avviare la sessione, il servizio Session Manager autentica il suo ID, verifica le autorizzazioni concesse da una policy IAM, controlla le impostazioni di configurazione (ad esempio verifica i limiti consentiti per le sessioni) e invia un messaggio all'SSM Agent per aprire il collegamento bidirezionale. Una volta stabilita la connessione e dopo aver digitato il comando successivo, l'output del comando da parte dell'SSM Agent viene caricato su questo canale di comunicazione e inviato nuovamente al computer locale di John.
**Topics**
+ [
## Quali sono i vantaggi di Session Manager per la mia organizzazione?
](#session-manager-benefits)
+ [
## A chi è consigliato l'uso di Session Manager?
](#session-manager-who)
+ [
## Quali sono le funzionalità principali di Session Manager?
](#session-manager-features)
+ [
## Che cos'è una sessione?
](#what-is-a-session)
+ [
# Configurazione di Session Manager
](session-manager-getting-started.md)
+ [
# Utilizzo di Session Manager
](session-manager-working-with.md)
+ [
# Attività di registrazione delle sessioni
](session-manager-auditing.md)
+ [
# Abilitazione e disabilitazione della registrazione di sessione
](session-manager-logging.md)
+ [
# Schema documento di sessione
](session-manager-schema.md)
+ [
# Risoluzione dei problemi relativi a Session Manager
](session-manager-troubleshooting.md)
# Configurazione di Session Manager
Prima di utilizzare il AWS Systems Manager Session Manager per connetterti ai nodi gestiti nel tuo account, completa le fasi descritte nei seguenti argomenti.
**Topics**
+ [
# Fase 1: completamento dei prerequisiti Session Manager
](session-manager-prerequisites.md)
+ [
# Fase 2: Verifica o aggiungi le autorizzazioni delle istanze per Session Manager
](session-manager-getting-started-instance-profile.md)
+ [
# Fase 3: Controlla l'accesso della sessione ai nodi gestiti
](session-manager-getting-started-restrict-access.md)
+ [
# Fase 4: configurazione delle preferenze delle sessioni
](session-manager-getting-started-configure-preferences.md)
+ [
# Fase 5: (facoltativo) limitazione dell'accesso ai comandi in una sessione
](session-manager-restrict-command-access.md)
+ [
# Fase 6: (Facoltativo) Utilizzare AWS PrivateLink per configurare un endpoint VPC per Session Manager
](session-manager-getting-started-privatelink.md)
+ [
# Fase 7 (facoltativo): abilitazione o disabilitazione delle autorizzazioni amministrative dell'account ssm-account
](session-manager-getting-started-ssm-user-permissions.md)
+ [
# Fase 8: (facoltativo) abilitazione e controllo delle autorizzazioni per le connessioni SSH tramite Session Manager
](session-manager-getting-started-enable-ssh-connections.md)
# Fase 1: completamento dei prerequisiti Session Manager
Prima di utilizzare il Session Manager, verifica che il tuo ambiente soddisfi i requisiti seguenti.
**Prerequisiti di Session Manager**
| Requisito | Description |
| --- | --- |
| Sistemi operativi supportati | Session Manager supporta la connessione alle istanze Amazon Elastic Compute Cloud (Amazon EC2), nonché alle macchine non EC2 nell'ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) che utilizzano il livello *istanze avanzate*. Session Manager supporta le seguenti versioni dei sistemi operativi: Session Manager*supporta istanze EC2, dispositivi edge, server e macchine virtuali locali (VMs) nel tuo ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) che utilizza il livello di istanze avanzate.* Per ulteriori informazioni sulle istanze avanzate, consulta [Configurazione dei livelli di istanza](fleet-manager-configure-instance-tiers.md). **Linux e **macOS**** Session Managersupporta tutte le versioni di e che sono supportate da. Linux macOS AWS Systems Manager Per informazioni, consulta [Sistemi operativi e tipi di macchine supportati](operating-systems-and-machine-types.md). ** Windows ** Session Manager supporta la versione Windows Server 2012 e le successive. Microsoft Windows Server 2016 Nano non è supportato. |
| SSM Agent | È necessario installare almeno la AWS Systems Manager SSM Agent versione 2.3.68.0 o successiva sui nodi gestiti a cui si desidera connettersi tramite sessioni. Per utilizzare l'opzione per crittografare i dati della sessione utilizzando una chiave creata in AWS Key Management Service (AWS KMS), è necessario installare sul nodo gestito la versione 2.3.539.0 o successiva diSSM Agent. Per utilizzare i profili di shell in una sessione, la versione 3.0.161.0 o successiva di SSM Agent deve essere installata sul nodo gestito. Per avviare un Port forwarding o una sessione SSH su Session Manager, la versione 3.0.222.0 o successiva di SSM Agent deve essere installata sul nodo gestito. Per eseguire lo streaming dei dati della sessione utilizzando Amazon CloudWatch Logs, è necessario installare la SSM Agent versione 3.0.284.0 o successiva sul nodo gestito. Per informazioni su come determinare il numero di versione in esecuzione su un'istanza, consulta [Verifica del numero di versione di SSM Agent](ssm-agent-get-version.md). Per informazioni sull'installazione o l'aggiornamento di SSM Agent, consulta [Utilizzo di SSM Agent](ssm-agent.md). Informazioni sull'account ssm-user A partire dalla versione 2.3.50.0 di SSM Agent, l'agente crea un account utente nel nodo gestito, con autorizzazioni di amministratore o root, denominato `ssm-user`. (Nelle versioni precedenti alla 2.3.612.0, l'account viene creato quando SSM Agent viene avviato o riavviato. Nella versione 2.3.612.0 e successive, `ssm-user` viene creato la prima volta che si avvia una sessione sul nodo gestito). Le sessioni vengono avviate utilizzando le credenziali amministrative di questo account utente. Per informazioni su come limitare il controllo amministrativo per questo account, consulta [Disattivare o attivare le autorizzazioni amministrative dell'account ssm-user](session-manager-getting-started-ssm-user-permissions.md). ssm-user su controller di dominio Windows Server A partire dalla versione 2.3.612.0 di SSM Agent, l'account `ssm-user` non viene creato automaticamente su nodi gestiti utilizzate come controller di dominio Windows Server. Per utilizzare Session Manager su un sistema Windows Server utilizzato come controller di dominio, è necessario creare l'account `ssm-user` manualmente, se non è già presente, e assegnare le autorizzazioni di amministratore di dominio all'utente. In Windows Server, SSM Agent imposta una nuova password per l'account `ssm-user` ogni volta che viene avviata una sessione, pertanto non è necessario specificare una password quando si crea l'account. |
| Connettività agli endpoint | In questo caso, i nodi gestiti devono consentire anche il traffico in uscita HTTPS (porta 443) verso i seguenti endpoint: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/session-manager-prerequisites.html) Per ulteriori informazioni, consulta i seguenti argomenti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/session-manager-prerequisites.html) In alternativa, è possibile connettersi agli endpoint richiesti utilizzando gli endpoint di interfaccia. Per ulteriori informazioni, consulta [Fase 6: (Facoltativo) Utilizzare AWS PrivateLink per configurare un endpoint VPC per Session Manager](session-manager-getting-started-privatelink.md). |
| AWS CLI | (Facoltativo) Se utilizzi AWS Command Line Interface (AWS CLI) per avviare le sessioni (anziché utilizzare la AWS Systems Manager console o la console Amazon EC2), la versione 1.16.12 o successiva della CLI deve essere installata sul computer locale. È possibile chiamare `aws --version` per controllare la versione. Se devi installare o aggiornare la CLI, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) di AWS Command Line Interface nella Guida per l' AWS Command Line Interface utente. 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. Inoltre, per utilizzare la CLI per gestire i tuoi nodi con il Session Manager, devi prima installare il plug-in Session Manager sul computer locale. Per informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md). |
| Attivazione del piano istanze avanzate (ambienti [ibridi e multicloud](operating-systems-and-machine-types.md#supported-machine-types)) | Per connetterti a macchine non EC2 utilizzandoSession Manager, devi attivare il livello Advanced-Instances nel Regione AWS quale creare attivazioni ibride per Account AWS registrare macchine non EC2 come nodi gestiti. Viene addebitato un costo per l'utilizzo del piano istanze avanzate. Per ulteriori informazioni sul livello istanze avanzate, consulta [Configurazione dei livelli di istanza](fleet-manager-configure-instance-tiers.md). |
| Verifica delle autorizzazioni del ruolo di servizio IAM (ambienti [ibridi e multicloud](operating-systems-and-machine-types.md#supported-machine-types)) | I nodi attivati in modalità ibrida utilizzano il ruolo di servizio AWS Identity and Access Management (IAM) specificato nell'attivazione ibrida per comunicare con le operazioni dell'API Systems Manager. Questo ruolo di servizio deve contenere le autorizzazioni necessarie per connettersi alle macchine [ibride e multicloud](operating-systems-and-machine-types.md#supported-machine-types) utilizzando Session Manager. Se il ruolo di servizio contiene la policy AWS gestita`AmazonSSMManagedInstanceCore`, le autorizzazioni richieste per Session Manager sono già state fornite. Se si scopre che il ruolo di servizio non contiene le autorizzazioni richieste, è necessario annullare la registrazione dell'istanza gestita e registrarla con una nuova attivazione ibrida che utilizza un ruolo di servizio IAM con le autorizzazioni richieste. Per ulteriori informazioni sull'annullamento delle registrazioni delle istanze gestite, consulta [Annullamento della registrazione dei nodi gestiti in un ambiente ibrido e multicloud](fleet-manager-deregister-hybrid-nodes.md). Per ulteriori informazioni sulla creazione di policy IAM con autorizzazioni Session Manager, vedi [Fase 2: Verifica o aggiungi autorizzazioni di istanze per Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-instance-profile.html). |
# Fase 2: Verifica o aggiungi le autorizzazioni delle istanze per Session Manager
Per impostazione predefinita, AWS Systems Manager non dispone dell'autorizzazione per eseguire azioni sulle tue istanze. È possibile fornire le autorizzazioni di istanza a livello di account utilizzando un ruolo AWS Identity and Access Management (IAM) o a livello di istanza utilizzando un profilo dell'istanza. Se il caso d'uso lo consente, ti consigliamo di concedere l'accesso a livello di account utilizzando la configurazione di gestione host predefinita. Se hai già impostato la configurazione di gestione host predefinita per il tuo account utilizzando la policy `AmazonSSMManagedEC2InstanceDefaultPolicy`, è possibile procedere con il passaggio successivo. Per ulteriori informazioni sulla configurazione di gestione host predefinita, consulta [Gestione automatica delle istanze EC2 con la configurazione di gestione host predefinita](fleet-manager-default-host-management-configuration.md).
In alternativa, è possibile utilizzare i profili di istanza per fornire le autorizzazioni necessarie alle tue istanze. Un profilo dell'istanza passa un ruolo IAM a un'istanza Amazon EC2. È possibile collegare un profilo dell'istanza IAM a un'istanza Amazon EC2 all'avvio o a un'istanza avviata in precedenza. Per ulteriori informazioni, consulta [Utilizzo dei profili dell'istanza](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-usingrole-instanceprofile.html).
Per i server locali o le macchine virtuali (VMs), le autorizzazioni sono fornite dal ruolo del servizio IAM associato all'attivazione ibrida utilizzata per registrare i server locali e con Systems VMs Manager. Server locali e VMs non utilizzano profili di istanza.
Se utilizzi già altri strumenti di Systems Manager, ad esempio Run Command o Parameter Store, un profilo dell'istanza con le autorizzazioni di base richieste per il Session Manager potrebbe essere già associato alle tue istanze Amazon EC2. Se un profilo di istanza che contiene la policy AWS gestita `AmazonSSMManagedInstanceCore` è già associato alle istanze, le autorizzazioni richieste per Session Manager sono già state fornite. Ciò vale anche se il ruolo di servizio IAM utilizzato nell'attivazione ibrida contiene la policy gestita `AmazonSSMManagedInstanceCore`.
Tuttavia, in alcuni casi, potrebbe essere necessario modificare le autorizzazioni collegate al profilo dell'istanza. Ad esempio, desideri fornire un set più ristretto di autorizzazioni per l'istanza, hai creato una policy personalizzata per il tuo profilo di istanza o desideri utilizzare le opzioni di crittografia o () di crittografia di Amazon Simple Storage Service (Amazon S3) AWS Key Management Service o AWS KMS() per proteggere i dati della sessione. Per questi casi, procedi in uno dei seguenti modi per consentire l'esecuzione di operazioni Session Manager sulle istanze:
+ **Incorpora autorizzazioni per azioni Session Manager in un ruolo IAM personalizzato**
Per aggiungere Session Manager autorizzazioni per azioni a un ruolo IAM esistente che non si basa sulla policy predefinita AWS fornita, segui la procedura riportata di seguito. `AmazonSSMManagedInstanceCore` [Aggiunta di autorizzazioni Session Manager per un ruolo IAM esistente](getting-started-add-permissions-to-existing-profile.md)
+ **Crea un ruolo IAM personalizzato solo con le autorizzazioni del Session Manager**
Per creare un ruolo IAM che contenga solo le autorizzazioni per le operazioni del Session Manager, segui i passaggi riportati in [Creare un ruolo IAM personalizzato per Session Manager](getting-started-create-iam-instance-profile.md).
+ **Crea e utilizza un nuovo ruolo IAM con le autorizzazioni per tutte le operazioni di Systems Manager**
Per creare un ruolo IAM per le istanze gestite di Systems Manager che utilizza una policy predefinita fornita da AWS per concedere tutte le autorizzazioni di Systems Manager, segui i passaggi in [Configurare le autorizzazioni delle istanze richieste per Systems Manager](setup-instance-permissions.md).
**Topics**
+ [
# Aggiunta di autorizzazioni Session Manager per un ruolo IAM esistente
](getting-started-add-permissions-to-existing-profile.md)
+ [
# Creare un ruolo IAM personalizzato per Session Manager
](getting-started-create-iam-instance-profile.md)
# Aggiunta di autorizzazioni Session Manager per un ruolo IAM esistente
Utilizza la procedura seguente per aggiungere autorizzazioni Session Manager a un ruolo AWS Identity and Access Management (IAM) esistente. Aggiungendo autorizzazioni a un ruolo esistente, è possibile migliorare la sicurezza dell'ambiente informatico senza dover utilizzare la AWS `AmazonSSMManagedInstanceCore` policy, ad esempio le autorizzazioni.
**Nota**
Prendi nota delle seguenti informazioni:
Questa procedura presuppone che il tuo ruolo esistente includa già altre autorizzazioni di Systems Manager `ssm` per le operazioni a cui desideri permettere l'accesso. Questa policy da sola non è sufficiente per l'utilizzo di Session Manager.
Il seguente esempio di policy include un'azione `s3:GetEncryptionConfiguration`. Questa azione è necessaria se hai scelto l'opzione **Applica crittografia dei log S3** nelle preferenze di registrazione di Session Manager.
Se l'`ssmmessages:OpenControlChannel`autorizzazione viene rimossa dalle policy allegate al profilo dell'istanza IAM o al ruolo del servizio IAM, SSM Agent sul nodo gestito perde la connettività al servizio Systems Manager nel cloud. Tuttavia, può essere necessaria fino a 1 ora prima che una connessione venga interrotta dopo la rimozione dell'autorizzazione. Si tratta dello stesso comportamento che si verifica quando il ruolo dell'istanza IAM o il ruolo del servizio IAM vengono eliminati.
**Per aggiungere le autorizzazioni Session Manager per il ruolo dell'istanza per un ruolo esistente (console)**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel riquadro di navigazione, seleziona **Ruoli**.
1. Seleziona il nome del ruolo al quale desideri aggiungere le autorizzazioni.
1. Scegli la scheda **Autorizzazioni**.
1. Scegli **Aggiungi autorizzazioni**, quindi scegli **Aggiungi policy inline**.
1. Scegli la scheda **JSON**.
1. Sostituisci il contenuto predefinito della policy con il seguente. Sostituisci *key-name* con l'Amazon Resource Name (ARN) della AWS Key Management Service chiave (AWS KMS key) che desideri utilizzare.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
Per ulteriori informazioni sull'utilizzo di una chiave KMS per crittografare i dati della sessione, consulta [Attiva la crittografia delle chiavi KMS per i dati delle sessioni (console)](session-preferences-enable-encryption.md).
Se non intendi utilizzare la AWS KMS crittografia per i dati della sessione, puoi rimuovere i seguenti contenuti dalla policy.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. Scegli **Successivo: Tag**.
1. (Facoltativo) Aggiungi i tag scegliendo **Aggiungi tag** e inserendo i tag preferiti per la policy.
1. Seleziona **Next: Revisione**.
1. Nella pagina **Rivedi policy**, per l'opzione **Nome** specifica un nome per la policy inline, ad esempio **SessionManagerPermissions**.
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per la policy.
Scegli **Crea policy**.
Per informazioni sulle operazioni `ssmmessages`, consulta [Referenza: ec2messages, ssmmessages e altre operazioni API](systems-manager-setting-up-messageAPIs.md).
# Creare un ruolo IAM personalizzato per Session Manager
Puoi creare un ruolo AWS Identity and Access Management (IAM) che conceda Session Manager l'autorizzazione a eseguire azioni sulle istanze gestite di Amazon EC2. Puoi anche includere una politica per concedere le autorizzazioni necessarie per l'invio dei log di sessione ad Amazon Simple Storage Service (Amazon S3) e Amazon Logs. CloudWatch
Dopo aver creato il ruolo IAM, per informazioni su come associare il ruolo a un'istanza, consulta [Allega o sostituisci un profilo di istanza](https://aws.amazon.com/premiumsupport/knowledge-center/attach-replace-ec2-instance-profile/) sul sito Web. AWS re:Post Per ulteriori informazioni sui profili e i ruoli delle istanze IAM, consulta [Utilizzo di profili di istanze](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) nella *Guida per l'utente IAM* e [Ruoli IAM per Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) nella *Guida per l’utente di Amazon Elastic Compute Cloud per istanze Linux*. Per ulteriori informazioni sulla creazione di un ruolo di servizio IAM per macchine on-premises, consulta [Creazione di un ruolo di servizio IAM richiesto per System Manager in ambiente ibrido e multicloud](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-multicloud-service-role.html).
**Topics**
+ [
## Creazione di un ruolo IAM con le autorizzazioni minime per il Session Manager (console)
](#create-iam-instance-profile-ssn-only)
+ [
## Creazione di un ruolo IAM con autorizzazioni per Amazon S3 Session Manager CloudWatch e Logs (console)
](#create-iam-instance-profile-ssn-logging)
## Creazione di un ruolo IAM con le autorizzazioni minime per il Session Manager (console)
Utilizza la procedura seguente per creare un ruolo IAM personalizzato con una policy che fornisce solo le autorizzazioni per le operazioni del Session Manager sulle tue istanze.
**Per creare un profilo dell'istanza con autorizzazioni minime per il Session Manager (console)**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel pannello di navigazione, scegli **Policy** e **Crea policy**. (Se viene visualizzato il pulsante **Inizia**, sceglierlo, quindi scegli **Crea policy**).
1. Scegli la scheda **JSON**.
1. Sostituire il contenuto di default con la seguente policy. Per crittografare i dati della sessione utilizzando AWS Key Management Service (AWS KMS), sostituiscili *key-name* con l'Amazon Resource Name (ARN) che desideri utilizzare. AWS KMS key
**Nota**
Se l'`ssmmessages:OpenControlChannel`autorizzazione viene rimossa dalle policy allegate al profilo dell'istanza IAM o al ruolo del servizio IAM, SSM Agent sul nodo gestito perde la connettività al servizio Systems Manager nel cloud. Tuttavia, può essere necessaria fino a 1 ora prima che una connessione venga interrotta dopo la rimozione dell'autorizzazione. Si tratta dello stesso comportamento che si verifica quando il ruolo dell'istanza IAM o il ruolo del servizio IAM vengono eliminati.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceInformation",
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
Per ulteriori informazioni sull'utilizzo di una chiave KMS per crittografare i dati della sessione, consulta [Attiva la crittografia delle chiavi KMS per i dati delle sessioni (console)](session-preferences-enable-encryption.md).
Se non intendi utilizzare la AWS KMS crittografia per i dati della sessione, puoi rimuovere i seguenti contenuti dalla policy.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. Scegli **Successivo: Tag**.
1. (Facoltativo) Aggiungi i tag scegliendo **Aggiungi tag** e inserendo i tag preferiti per la policy.
1. Seleziona **Next: Revisione**.
1. Nella pagina **Rivedi policy**, per l'opzione **Nome** specifica un nome per la policy inline, ad esempio **SessionManagerPermissions**.
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per la policy.
1. Scegliere **Create Policy (Crea policy)**.
1. Nel pannello di navigazione, scegli **Ruoli** e quindi **Crea ruolo**.
1. Sulla pagina **Crea ruolo**, scegli **AWS servizio**, e per **Caso d'uso**, scegli **EC2**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Aggiungi autorizzazioni**, seleziona la casella di controllo a sinistra del nome della policy appena creata, ad esempio **SessionManagerPermissions**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rinomina, revisione e creazione**, per **Nome ruolo** immettere un nome per il ruolo IAM, ad esempio **MySessionManagerRole**.
1. (Facoltativo) Per **Descrizione ruolo**, immetti una descrizione per il profilo dell'istanza.
1. (Facoltativo) Aggiungi i tag scegliendo **Aggiungi tag** e inserendo i tag preferiti per il ruolo.
Scegli **Crea ruolo**.
Per informazioni sulle operazioni di `ssmmessages`, consulta [Referenza: ec2messages, ssmmessages e altre operazioni API](systems-manager-setting-up-messageAPIs.md).
## Creazione di un ruolo IAM con autorizzazioni per Amazon S3 Session Manager CloudWatch e Logs (console)
Utilizza la procedura seguente per creare un ruolo IAM personalizzato con una policy che fornisce le autorizzazioni per le operazioni del Session Manager sulle tue istanze. La policy fornisce anche le autorizzazioni necessarie per l'archiviazione dei log di sessione nei bucket Amazon Simple Storage Service (Amazon S3) e nei gruppi di log Amazon Logs. CloudWatch
**Importante**
Per eseguire l'output dei log di sessione su un bucket Amazon S3 appartenente a un Account AWS diverso, devi aggiungere l'autorizzazione `s3:PutObjectAcl` alla policy del ruolo IAM. Inoltre, devi assicurarti che la policy del bucket conceda l'accesso multi-account al ruolo IAM utilizzato dall'account proprietario per concedere le autorizzazioni di Systems Manager per le istanze gestite. Se il bucket utilizza la crittografia Key Management Service (KMS), anche la policy KMS del bucket deve concedere questo accesso multi-account. Per ulteriori informazioni sulla configurazione di autorizzazioni del bucket multi-account in Amazon S3, consulta [Concessione di autorizzazioni del bucket multi-account](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) nella *Guida per l'utente di Amazon Simple Storage Service*. Se queste autorizzazioni multi-account non vengono aggiunte, l'account proprietario del bucket Amazon S3 non è in grado di accedere ai log di output della sessione.
Per informazioni su come specificare le preferenze di archiviazione per i log delle sessioni, consulta [Abilitazione e disabilitazione della registrazione di sessione](session-manager-logging.md).
**Per creare un ruolo IAM con autorizzazioni per Amazon S3 Session Manager CloudWatch e Logs (console)**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nel pannello di navigazione, scegli **Policy** e **Crea policy**. (Se viene visualizzato il pulsante **Inizia**, sceglierlo, quindi scegli **Crea policy**).
1. Scegli la scheda **JSON**.
1. Sostituire il contenuto di default con la seguente policy. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/s3-prefix/*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
},
{
"Effect": "Allow",
"Action": "kms:GenerateDataKey",
"Resource": "*"
}
]
}
```
------
1. Scegli **Successivo: Tag**.
1. (Facoltativo) Aggiungi i tag scegliendo **Aggiungi tag** e inserendo i tag preferiti per la policy.
1. Seleziona **Next: Revisione**.
1. Nella pagina **Rivedi policy**, per l'opzione **Nome** specifica un nome per la policy inline, ad esempio **SessionManagerPermissions**.
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per la policy.
1. Scegliere **Create Policy (Crea policy)**.
1. Nel pannello di navigazione, scegli **Ruoli** e quindi **Crea ruolo**.
1. Sulla pagina **Crea ruolo**, scegli **AWS servizio**, e per **Caso d'uso**, scegli **EC2**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Aggiungi autorizzazioni**, seleziona la casella di controllo a sinistra del nome della policy appena creata, ad esempio **SessionManagerPermissions**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rinomina, revisione e creazione**, per **Nome ruolo** immettere un nome per il ruolo IAM, ad esempio **MySessionManagerRole**.
1. (Facoltativo) In **Descrizione del ruolo**, immetti una descrizione per il nuovo ruolo.
1. (Facoltativo) Aggiungi i tag scegliendo **Aggiungi tag** e inserendo i tag preferiti per il ruolo.
1. Scegli **Crea ruolo**.
# Fase 3: Controlla l'accesso della sessione ai nodi gestiti
Puoi concedere o revocare Session Manager l'accesso ai nodi gestiti utilizzando le policy AWS Identity and Access Management (IAM). È possibile creare una policy e collegarla a un utente o gruppo IAM che specifichi a quali nodi gestiti l'utente o il gruppo può connettersi. È possibile anche specificare le operazioni API Session Manager che l'utente o i gruppi possono eseguire su tali nodi gestiti.
Per aiutarti a iniziare a usare le policy di autorizzazione IAM per Session Manager, abbiamo creato policy di esempio per un utente finale e un utente amministratore. È possibile utilizzare queste policy solo con modifiche minori. Oppure è possibile usarle come guida per creare policy IAM personalizzate. Per ulteriori informazioni, consulta [Policy IAM di esempio per Session Manager](getting-started-restrict-access-quickstart.md). Per informazioni su come creare policy IAM e collegarle a utenti o gruppi, consulta le pagine [Creazione di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) e [Aggiunta e rimozione di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) nella *Guida per l'utente di IAM*.
**Informazioni sui formati ARN degli ID di sessione**
Quando crei una policy IAM per l'accesso di Session Manager, specifichi un ID di sessione come parte del nome della risorsa Amazon (ARN). L'ID di sessione include il nome utente come variabile. A scopo illustrativo, ecco il formato di un ARN di Session Manager e un esempio:
```
arn:aws:ssm:region-id:account-id:session/session-id
```
Esempio:
```
arn:aws:ssm:us-east-2:123456789012:session/JohnDoe-1a2b3c4d5eEXAMPLE
```
Per ulteriori informazioni sull'utilizzo delle variabili nelle policy IAM, consulta [Elementi delle policy IAM: variabili](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html).
**Topics**
+ [
# Avviare una sessione di shell predefinita specificando il documento di sessione predefinito nelle policy IAM
](getting-started-default-session-document.md)
+ [
# Avviare una sessione con un documento specificando i documenti di sessione nelle policy IAM
](getting-started-specify-session-document.md)
+ [
# Policy IAM di esempio per Session Manager
](getting-started-restrict-access-quickstart.md)
+ [
# Altre policy IAM di esempio per Session Manager
](getting-started-restrict-access-examples.md)
# Avviare una sessione di shell predefinita specificando il documento di sessione predefinito nelle policy IAM
Quando si configura Session Manager per Account AWS o quando si modificano le preferenze di sessione nella console Systems Manager, il sistema crea un documento di sessione SSM chiamato`SSM-SessionManagerRunShell`. Questo è il documento di sessione predefinito. Session Manager utilizza questo documento per memorizzare le preferenze di sessione, che includono informazioni come le seguenti:
+ Una posizione in cui desideri salvare i dati della sessione, ad esempio un bucket Amazon Simple Storage Service (Amazon S3) o un gruppo di log CloudWatch Amazon Logs.
+ Un ID chiave AWS Key Management Service (AWS KMS) per crittografare i dati della sessione.
+ Se il supporto Run As è consentito o meno per le sessioni.
Ecco un esempio delle informazioni contenute nel documento sulle preferenze di sessione `SSM-SessionManagerRunShell`.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyCWLogGroup",
"cloudWatchEncryptionEnabled": false,
"kmsKeyId": "1a2b3c4d",
"runAsEnabled": true,
"runAsDefaultUser": "RunAsUser"
}
}
```
Per impostazione predefinita, Session Manager utilizza il documento di sessione predefinito quando un utente avvia una sessione dalla Console di gestione AWS. Questo vale Fleet Manager sia Session Manager per la console Systems Manager che per EC2 Connect nella console Amazon EC2. Session Managerutilizza anche il documento di sessione predefinito quando un utente avvia una sessione utilizzando un AWS CLI comando come nell'esempio seguente:
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
Per accedere alla sessione di shell predefinita, è necessario specificare il documento di sessione predefinito nella policy IAM, come mostrato nell'esempio seguente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnableSSMSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/instance-id",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"*"
]
}
]
}
```
------
# Avviare una sessione con un documento specificando i documenti di sessione nelle policy IAM
Se utilizzi il comando [start-session](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) della AWS CLI utilizzando il documento di sessione predefinito, puoi omettere il nome del documento. Il sistema richiama automaticamente il documento di sessione `SSM-SessionManagerRunShell`.
In tutti gli altri casi, devi specificare un valore per il parametro `document-name`. Quando un utente specifica il nome di un documento di sessione in un comando, i sistemi controllano la policy IAM per verificare che dispongano dell'autorizzazione ad accedere al documento. Se non dispongono dell'autorizzazione, la richiesta di connessione non riesce. Gli esempi seguenti includono il parametro `document-name` con il documento di sessione `AWS-StartPortForwardingSession`.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
Per un esempio di come specificare un documento di sessione Session Manager in una policy IAM, consulta [Policy di avvio rapido per utenti finali per Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
**Nota**
Per avviare una sessione con SSH, le fasi di configurazione devono essere completate sul nodo gestito di destinazione *e* sul computer locale dell'utente. Per informazioni, consulta [(Facoltativo) Abilitare e controllare le autorizzazioni per le connessioni SSH tramite Session Manager](session-manager-getting-started-enable-ssh-connections.md).
# Policy IAM di esempio per Session Manager
Usa gli esempi in questa sezione per aiutarti a creare policy AWS Identity and Access Management (IAM) che forniscano le autorizzazioni di Session Manager accesso più comunemente necessarie.
**Nota**
Puoi anche utilizzare una AWS KMS key policy per controllare a quali entità IAM (utenti o ruoli) Account AWS viene concesso l'accesso alla tua chiave KMS. Per informazioni, consulta [Panoramica sulla gestione dell'accesso alle AWS KMS risorse](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) e sull'[utilizzo delle politiche chiave AWS KMS nella](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) *Guida per gli AWS Key Management Service sviluppatori*.
**Topics**
+ [
## Policy di avvio rapido per utenti finali per Session Manager
](#restrict-access-quickstart-end-user)
+ [
## Policy di avvio rapido per amministratori per Session Manager
](#restrict-access-quickstart-admin)
## Policy di avvio rapido per utenti finali per Session Manager
Utilizzare gli esempi seguenti per creare policy IAM per l'utente finale per Session Manager.
Puoi creare una policy che consenta agli utenti di avviare sessioni solo dalla Session Manager console e AWS Command Line Interface (AWS CLI), solo dalla console Amazon Elastic Compute Cloud (Amazon EC2) o da tutte e tre.
Queste policy offrono agli utenti finali la possibilità di avviare una sessione per una determinato nodo gestito nonché la possibilità di terminare solo le proprie sessioni. Per alcuni esempi di personalizzazioni che potresti applicare alla policy, fai riferimento a [Altre policy IAM di esempio per Session Manager](getting-started-restrict-access-examples.md).
Nei seguenti esempi di policy, sostituisci ognuna *example resource placeholder* con le tue informazioni.
Scegliere una delle seguenti schede per visualizzare e policy di esempio per l'intervallo di accesso alla sessione che si desidera fornire.
------
#### [ Session Manager and Fleet Manager ]
Utilizzare questa policy di esempio per fornire agli utenti la possibilità di avviare e riprendere sessioni solo dalle console Session Manager e Fleet Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
------
#### [ Amazon EC2 ]
Utilizzare questa policy di esempio per fornire agli utenti la possibilità di avviare e riprendere sessioni solo dalla console Amazon EC2. Questa policy non fornisce tutte le autorizzazioni necessarie per avviare le sessioni dalla console Session Manager e dall' AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
------
#### [ AWS CLI ]
Utilizzare questa policy di esempio per fornire agli utenti la possibilità di avviare e riprendere sessioni solo da AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
------
**Nota**
`SSM-SessionManagerRunShell` è il nome predefinito del documento SSM creato da Session Manager per archiviare le preferenze di configurazione della sessione. Puoi creare un documento di sessione personalizzato e specificarlo in questa policy. Puoi anche specificare il documento `AWS-StartSSHSession` fornito da AWS per gli utenti che avviano le sessioni mediante SSH. Per informazioni sui passi di configurazione necessari per supportare le sessioni utilizzando SSH, consulta [(Facoltativo) Permettere e controllare le autorizzazioni per le connessioni SSH tramite Session Manager](session-manager-getting-started-enable-ssh-connections.md).
L'autorizzazione `kms:GenerateDataKey` consente la creazione di una chiave di crittografia dei dati che verrà utilizzata per crittografare i dati delle sessioni. Se utilizzerai la crittografia AWS Key Management Service (AWS KMS) per i dati della sessione, *key-name* sostituiscila con l'Amazon Resource Name (ARN) della chiave KMS che desideri utilizzare, nel formato. `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE` Se non utilizzi la crittografia delle chiavi KMS per i dati delle sessioni, rimuovi i seguenti contenuti dalla policy:
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "key-name"
}
```
Per informazioni sull'utilizzo AWS KMS per crittografare i dati della sessione, consulta. [Attiva la crittografia delle chiavi KMS per i dati delle sessioni (console)](session-preferences-enable-encryption.md)
L'autorizzazione per [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) è necessaria nei casi in cui un utente tenta di avviare una sessione dalla console Amazon EC2, ma bisogna prima aggiornare l'SSM Agent alla versione minima richiesta per Session Manager. Run Command viene utilizzato per inviare un comando all'istanza per aggiornare l'agente.
## Policy di avvio rapido per amministratori per Session Manager
Utilizzare gli esempi seguenti per creare policy di amministratore IAM per Session Manager.
Queste policy offrono agli amministratori la possibilità di avviare una sessione per i nodi gestiti contrassegnati con il tag `Key=Finance,Value=WebServers`, l'autorizzazione di creare, aggiornare ed eliminare le preferenze nonché l'autorizzazione di terminare solo le proprie sessioni. Per alcuni esempi di personalizzazioni che potresti applicare alla policy, fai riferimento a [Altre policy IAM di esempio per Session Manager](getting-started-restrict-access-examples.md).
Puoi creare una policy che consenta agli amministratori di eseguire queste attività solo dalla Session Manager console e AWS CLI, solo dalla console Amazon EC2, o da tutte e tre.
Nei seguenti esempi di policy, sostituisci ognuna *example resource placeholder* con le tue informazioni.
Scegliere una delle seguenti schede per visualizzare le policy di esempio per lo scenario di accesso che si desidera supportare.
------
#### [ Session Manager and CLI ]
Utilizzare questa policy di esempio per fornire agli amministratori del provider la possibilità di eseguire processi correlati alla sessione solo dalla console Session Manager e dall' AWS CLI. Questa policy non fornisce tutte le autorizzazioni necessarie per eseguire processi correlati alla sessione dalla console Amazon EC2.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/Finance": [
"WebServers"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:GetDocument",
"ssm:StartSession"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
#### [ Amazon EC2 ]
Utilizzare questa policy di esempio per fornire agli amministratori del provider la possibilità di eseguire processi correlati alla sessione solo dalla console Amazon EC2 Questa policy non fornisce tutte le autorizzazioni necessarie per eseguire attività correlate alla sessione dalla console Session Manager e dall' AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag-key": [
"tag-value"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
#### [ Session Manager, CLI, and Amazon EC2 ]
Utilizzare questa policy di esempio per fornire agli amministratori del provider la possibilità di eseguire processi relativi alla sessione dalla console Session Manager, dall' AWS CLI e dalla console Amazon EC2.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag-key": [
"tag-value"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:GetDocument",
"ssm:StartSession"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
**Nota**
L'autorizzazione per [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) è necessaria nei casi in cui un utente tenta di avviare una sessione dalla console Amazon EC2, ma prima bisogna inviare un comando per aggiornare SSM Agent.
# Altre policy IAM di esempio per Session Manager
Fai riferimento alle seguenti policy di esempio per creare una policy IAM AWS Identity and Access Management personalizzata per qualunque scenario di accesso utente al Session Manager che desideri supportare.
**Topics**
+ [
## Esempio 1: concedere l'accesso ai documenti nella console
](#grant-access-documents-console-example)
+ [
## Esempio 2: limitare l'accesso a nodi gestiti specifici
](#restrict-access-example-instances)
+ [
## Esempio 3: limitazione dell'accesso in base ai tag
](#restrict-access-example-instance-tags)
+ [
## Esempio 4: consentire agli utenti di terminare solo le sessioni da essi avviate
](#restrict-access-example-user-sessions)
+ [
## Esempio 5: consentire l'accesso (amministrativo) completo a tutte le sessioni
](#restrict-access-example-full-access)
## Esempio 1: concedere l'accesso ai documenti nella console
Puoi consentire agli utenti di specificare un documento personalizzato quando avviano una sessione utilizzando la console di Session Manager. Nel seguente esempio, la policy IAM concede l'autorizzazione ad accedere ai documenti con nomi che iniziano con **SessionDocument-** nella Regione AWS e nell’ Account AWS specificati.
Per utilizzare questa politica, sostituisci ognuna *example resource placeholder* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:ListDocuments"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SessionDocument-*"
]
}
]
}
```
------
**Nota**
La console di Session Manager supporta solo i documenti di sessione che hanno un `sessionType` di `Standard_Stream` e che vengono utilizzati per definire le preferenze di sessione. Per ulteriori informazioni, consulta [Schema documento di sessione](session-manager-schema.md).
## Esempio 2: limitare l'accesso a nodi gestiti specifici
È possibile creare una policy IAM che definisca a quali nodi gestiti un utente può connettersi utilizzando Session Manager. Ad esempio, la seguente policy concede a un utente il permesso di avviare, terminare e riprendere le sessioni su tre nodi specifici. La policy impedisce all'utente di connettersi a nodi diversi da quelli specificati.
**Nota**
Per utenti federati, consulta [Esempio 4: consentire agli utenti di terminare solo le sessioni da essi avviate](#restrict-access-example-user-sessions).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-1234567890EXAMPLE",
"arn:aws:ec2:us-east-1:111122223333:instance/i-abcdefghijEXAMPLE",
"arn:aws:ec2:us-east-1:111122223333:instance/i-0e9d8c7b6aEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
------
## Esempio 3: limitazione dell'accesso in base ai tag
Puoi limitare l'accesso ai nodi gestiti in base a tag specifici. Nell'esempio seguente, l'utente può avviare e riprendere le sessioni (`Effect: Allow, Action: ssm:StartSession, ssm:ResumeSession`) su qualsiasi nodo gestito (`Resource: arn:aws:ec2:region:987654321098:instance/*`) a condizione che il nodo sia Finance WebServer (`ssm:resourceTag/Finance: WebServer`). Se l'utente invia un comando a un nodo gestito senza tag o con un tag diverso da `Finance: WebServer`, il risultato del comando includerà `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/Finance": [
"WebServers"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
Puoi creare policy IAM che permettono a un utente di avviare sessioni su nodi gestiti contrassegnati con più tag. La seguente policy consente all'utente di avviare sessioni su nodi gestiti a cui sono applicati entrambi i tag specificati. Se l'utente invia un comando a un nodo gestito non contrassegnato con questi due tag, il risultato del comando includerà `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:StartSession"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag-key1":[
"tag-value1"
],
"ssm:resourceTag/tag-key2":[
"tag-value2"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
Per ulteriori informazioni sulla creazione di policy IAM, consulta la pagina [Policy gestite e policy inline](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) nella *Guida per l'utente di IAM*. Per ulteriori informazioni sull'applicazione di tag a nodi gestiti, consulta [Applicazione di tag a risorse Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) nella *Guida per l'utente di Amazon EC2* (il contenuto si applica ai nodi gestiti di Windows e Linux). Per ulteriori informazioni su come aumentare la posizione di sicurezza rispetto ai comandi non autorizzati a livello di root nei nodi gestiti, consulta [Limitare l'accesso ai comandi a livello di root tramite SSM Agent](ssm-agent-restrict-root-level-commands.md)
## Esempio 4: consentire agli utenti di terminare solo le sessioni da essi avviate
Session Managerfornisce due metodi per controllare quali sessioni può terminare un utente federato dell'utente. Account AWS
+ Utilizza la variabile `{aws:userid}` in una politica di autorizzazioni AWS Identity and Access Management (IAM). Gli utenti federati possono terminare solo le sessioni da essi avviate. Per gli utenti non federati, utilizzare il Metodo 1. Per gli utenti federati, utilizzare il Metodo 2.
+ Utilizza i tag forniti dai AWS tag in una politica di autorizzazioni IAM. Nella policy deve essere inclusa una condizione che consenta agli utenti di terminare solo le sessioni contrassegnate con tag specifici forniti da AWS. Questo metodo funziona per tutti gli account, compresi quelli che utilizzano federated IDs per concedere l'accesso a. AWS
### Metodo 1: concedere TerminateSession i privilegi utilizzando la variabile `{aws:username}`
La seguente policy IAM consente a un utente IDs di visualizzare tutte le sessioni del tuo account. Tuttavia, gli utenti possono interagire con i nodi gestiti solo attraverso le sessioni da loro avviate. Un utente a cui è assegnata la seguente policy non può terminare o connettersi alle sessioni di altri utenti. A tale scopo, la policy utilizza la variabile `{aws:username}`.
**Nota**
Questo metodo non funziona per gli account che concedono l'accesso all' AWS utilizzo di federated. IDs
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:DescribeSessions"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Action": [
"ssm:TerminateSession"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
### Metodo 2: concedere TerminateSession i privilegi utilizzando i tag forniti da AWS
È possibile controllare le sessioni che un utente può terminare includendo variabili di chiave tag condizionali in una policy IAM. La condizione specifica che l'utente può terminare solo le sessioni che sono contrassegnate con una o entrambe queste specifiche variabili chiave tag e un valore specificato.
Quando un utente Account AWS inizia una sessione, Session Manager applica due tag di risorsa alla sessione. Il primo tag risorsa è `aws:ssmmessages:target-id`, con il quale si specifica l'ID della destinazione che l'utente può terminare. L'altro tag risorsa è `aws:ssmmessages:session-id`, con un valore nel formato di `role-id:caller-specified-role-name`.
**Nota**
Session Manager non supporta i tag personalizzati per questa policy di controllo dell'accesso IAM. È necessario utilizzare i tag di risorsa forniti da AWS, descritti di seguito.
** `aws:ssmmessages:target-id` **
Con questa chiave di tag, è possibile includere l'ID del nodo gestito come valore nella policy. Nel seguente blocco della policy, l'istruzione di condizione consente a un utente di terminare solo il nodo i-02573cafcfEXAMPLE.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:target-id": [
"i-02573cafcfEXAMPLE"
]
}
}
}
]
}
```
Se l'utente tenta di terminare una sessione per la quale non è stata concessa questa autorizzazione `TerminateSession`, viene visualizzato un errore `AccessDeniedException`.
** `aws:ssmmessages:session-id` **
Questa chiave tag include una variabile per l'ID di sessione come valore nella richiesta di avviare una sessione.
Nell'esempio seguente viene illustrata una policy per i casi in cui il tipo di chiamante è `User`. Il valore fornito per `aws:ssmmessages:session-id` è l'ID dell'utente. In questo esempio, `AIDIODR4TAW7CSEXAMPLE` rappresenta l'ID di un utente nel tuo Account AWS. Per recuperare l'ID di un utente nel tuo Account AWS, usa il comando IAM,`get-user`. Per informazioni, consulta [get-user](https://docs.aws.amazon.com/IAM/latest/UserGuide/get-user.html) nella AWS Identity and Access Management sezione della *IAM* User Guide.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"AIDIODR4TAW7CSEXAMPLE"
]
}
}
}
]
}
```
Nell'esempio seguente viene illustrata una policy per i casi in cui il tipo di chiamante è `AssumedRole`. Puoi utilizzare la variabile `{aws:userid}` per il valore da fornire per `aws:ssmmessages:session-id`. In alternativa, è possibile codificare un ID ruolo per il valore specificato per `aws:ssmmessages:session-id`. Se codifichi un ID ruolo, devi specificare il valore nel formato `role-id:caller-specified-role-name`. Ad esempio, `AIDIODR4TAW7CSEXAMPLE:MyRole`.
Per applicare i tag di sistema, l'ID ruolo fornito può contenere solo i seguenti caratteri: lettere Unicode, 0-9, spazio, `_`, `.`, `:`, `/`, `=`, `+`, `-`, `@` e `\`.
Per recuperare l'ID del ruolo per un ruolo nel tuo Account AWS, usa il comando. `get-caller-identity` Per informazioni, consulta [get-caller-identity](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html)la sezione AWS CLI Command Reference.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}*"
]
}
}
}
]
}
```
Se un utente tenta di terminare una sessione per la quale non è stata concessa questa autorizzazione `TerminateSession`, viene visualizzato un errore `AccessDeniedException`.
**`aws:ssmmessages:target-id`** e **`aws:ssmmessages:session-id`**
È inoltre possibile creare policy IAM che permettono a un utente di terminare sessioni contrassegnate con entrambi i tag di sistema, come illustrato in questo esempio.
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:TerminateSession"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/aws:ssmmessages:target-id":[
"i-02573cafcfEXAMPLE"
],
"ssm:resourceTag/aws:ssmmessages:session-id":[
"${aws:userid}*"
]
}
}
}
]
}
```
## Esempio 5: consentire l'accesso (amministrativo) completo a tutte le sessioni
La seguente policy IAM consente a un utente di interagire con tutti i nodi gestiti e tutte le sessioni create da tutti gli utenti per tutti i nodi. Dovrebbe essere concessa solo a un amministratore che ha bisogno del controllo completo sulle attività del Session Manager della tua organizzazione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:StartSession",
"ssm:TerminateSession",
"ssm:ResumeSession",
"ssm:DescribeSessions",
"ssm:GetConnectionStatus"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
------
# Fase 4: configurazione delle preferenze delle sessioni
Gli utenti a cui sono state concesse le autorizzazioni amministrative nella propria policy AWS Identity and Access Management (IAM) possono configurare le preferenze di sessione, tra cui:
+ Attiva il supporto Esegui come per i nodi gestiti Linux. In questo modo è possibile avviare sessioni utilizzando le credenziali di un utente del sistema operativo specificato anziché le credenziali di un `ssm-user` account generato dal sistema che è AWS Systems Manager Session Manager possibile creare su un nodo gestito.
+ Configura Session Manager l'utilizzo della AWS KMS key crittografia per fornire una protezione aggiuntiva ai dati trasmessi tra le macchine client e i nodi gestiti.
+ Configura Session Manager per creare e inviare i log della cronologia delle sessioni a un bucket Amazon Simple Storage Service (Amazon S3) o a un gruppo di log Amazon Logs. CloudWatch I dati di log archiviati si utilizzano quindi per fornire rapporti sulle connessioni di sessione effettuate ai nodi gestiti e sui comandi eseguiti su di esse durante le sessioni.
+ Configura i timeout delle sessioni. È possibile utilizzare questa impostazione per specificare quando terminare una sessione dopo un periodo di inattività.
+ Configura Session Manager per utilizzare profili di shell configurabili. Questi profili personalizzabili permettono di definire le preferenze all'interno di sessioni quali le preferenze della shell, le variabili di ambiente, le directory di lavoro ed eseguire più comandi all'avvio di una sessione.
Per ulteriori informazioni sulle autorizzazioni necessarie per configurare le preferenze di Session Manager, consulta [Concedere o negare a un utente le autorizzazioni per aggiornare le preferenze del Session Manager](preference-setting-permissions.md).
**Topics**
+ [
# Concedere o negare a un utente le autorizzazioni per aggiornare le preferenze del Session Manager
](preference-setting-permissions.md)
+ [
# Specificare un valore di timeout della sessione di inattività
](session-preferences-timeout.md)
+ [
# Specifica la durata massima della sessione
](session-preferences-max-timeout.md)
+ [
# Consenti profili shell configurabili
](session-preferences-shell-config.md)
+ [
# Attiva Esegui come supporto per i nodi gestiti da Linux and macOS
](session-preferences-run-as.md)
+ [
# Attiva la crittografia delle chiavi KMS per i dati delle sessioni (console)
](session-preferences-enable-encryption.md)
+ [
# Creare un documento di preferenze di Session Manager (riga di comando)
](getting-started-create-preferences-cli.md)
+ [
# Aggiornamento delle preferenze Session Manager (riga di comando)
](getting-started-configure-preferences-cli.md)
Per informazioni sull'utilizzo della console di Systems Manager per configurare le opzioni per la registrazione dei dati di sessione, consulta i seguenti argomenti.
+ [Registrazione dei dati delle sessioni mediante Amazon S3 (console)](session-manager-logging-s3.md)
+ [Streaming dei dati delle sessioni tramite Amazon CloudWatch Logs (console)](session-manager-logging-cwl-streaming.md)
+ [Registrazione dei dati della sessione tramite Amazon CloudWatch Logs (console)](session-manager-logging-cloudwatch-logs.md)
# Concedere o negare a un utente le autorizzazioni per aggiornare le preferenze del Session Manager
Le preferenze dell'account vengono archiviate come documenti AWS Systems Manager (SSM) per ciascuno Regione AWS di essi. Prima che un utente possa aggiornare le preferenze dell'account per le sessioni nel tuo account, deve disporre delle autorizzazioni necessarie per accedere al tipo di documento SSM in cui sono archiviate tali preferenze. Queste autorizzazioni vengono concesse tramite una policy AWS Identity and Access Management (IAM).
**Policy di amministratore per consentire la creazione e l'aggiornamento delle preferenze**
Un amministratore può disporre della seguente policy per creare e aggiornare le preferenze in qualsiasi momento. La seguente policy concede l'autorizzazione per accedere e aggiornare il documento `SSM-SessionManagerRunShell` nell'account us-east-2 123456789012.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
**Policy utente per impedire che le preferenze vengano aggiornate**
Utilizza la seguente policy per impedire agli utenti finali nel tuo account di aggiornare o sostituire le preferenze del Session Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Deny",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
# Specificare un valore di timeout della sessione di inattività
Session Manager, uno strumento in AWS Systems Manager, consente di specificare il periodo di tempo necessario per consentire a un utente di rimanere inattivo prima che il sistema termini una sessione. Per impostazione predefinita, le sessioni scadono dopo 20 minuti di inattività. È possibile modificare questa impostazione per specificare il timeout di una sessione tra 1 e 60 minuti di inattività. Alcune agenzie di sicurezza informatica professionali consigliano di impostare i timeout delle sessioni inattive su un massimo di 15 minuti.
Il timer di timeout della sessione inattiva si reimposta quando riceve input dal lato client. Session Manager Questi input includono, a titolo esemplificativo ma non esaustivo:
+ Inserimento da tastiera nel terminale
+ Eventi di ridimensionamento della finestra del terminale o del browser
+ Riconnessione della sessione (ResumeSession), che può verificarsi a causa di interruzioni di rete, gestione delle schede del browser o disconnessioni WebSocket
Poiché questi eventi reimpostano il timer di inattività, una sessione potrebbe rimanere attiva più a lungo del periodo di timeout configurato anche senza comandi diretti dal terminale.
Se i requisiti di sicurezza impongono limiti rigorosi di durata delle sessioni indipendentemente dall'attività, utilizza l'impostazione *Durata massima della sessione* oltre al timeout di inattività. Per ulteriori informazioni, consulta [Specifica la durata massima della sessione](session-preferences-max-timeout.md).
**Per consentire il timeout della sessione inattiva (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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Specificare il periodo di tempo necessario per consentire a un utente di rimanere inattivo prima che una sessione finisca nel campo **minuti** in **tempo di inattività della sessione**.
1. Scegli **Save** (Salva).
# Specifica la durata massima della sessione
Session Manager, uno strumento in AWS Systems Manager, consente di specificare la durata massima di una sessione prima che termini. Per impostazione predefinita, le sessioni non hanno una durata massima. Il valore specificato per la durata massima della sessione deve essere compreso tra 1 e 1.440 minuti.
**Per specificare la durata massima della sessione (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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Selezionare la casella di controllo accanto ad **Abilita la durata massima della sessione**.
1. Specificare la durata massima della sessione prima che finisca nel campo **minuti** sotto **Durata massima sessione**.
1. Scegli **Save** (Salva).
# Consenti profili shell configurabili
Per impostazione predefinita, le sessioni sulle istanze EC2 per Linux iniziano utilizzando la shell Bourne (sh). Tuttavia, potresti usare un'altra shell come bash. Consentendo i profili di shell configurabili, è possibile personalizzare le preferenze all'interno di sessioni quali le preferenze della shell, le variabili di ambiente, le directory di lavoro ed eseguire più comandi all'avvio di una sessione.
**Importante**
Systems Manager non controlla i comandi o gli script nel profilo della shell per vedere quali modifiche apporterebbero a un'istanza prima dell'esecuzione. Per limitare la capacità di un utente di modificare i comandi o gli script immessi nel profilo della shell, si consiglia quanto segue:
Creare un documento personalizzato di tipo sessione per gli utenti e i ruoli AWS Identity and Access Management (IAM). Modificare quindi la policy IAM per questi utenti e ruoli in modo che l'operazione API `StartSession` possa utilizzare solo il documento di tipo sessione creato per loro. Per informazioni, consulta [Creare un documento di preferenze di Session Manager (riga di comando)](getting-started-create-preferences-cli.md) e [Policy di avvio rapido per utenti finali per Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
Modifica la policy IAM per gli utenti e i ruoli IAM per negare l'accesso all'operazione API `UpdateDocument` per la risorsa documento di tipo sessione creata. Ciò consente agli utenti e ai ruoli di utilizzare il documento creato per le preferenze di sessione senza consentire loro di modificare alcuna delle impostazioni.
**Per attivare i profili di shell configurabili**
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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Specifica le variabili di ambiente, le preferenze della shell o i comandi che si desidera eseguire all'avvio della sessione nei campi relativi ai sistemi operativi applicabili.
1. Scegli **Save** (Salva).
Di seguito sono riportati alcuni comandi di esempio che possono essere aggiunti al profilo della shell.
Passa alla shell bash e passa alla directory /usr sulle istanze Linux.
```
exec /bin/bash
cd /usr
```
Invia un timestamp e un messaggio di benvenuto all'avvio di una sessione.
------
#### [ Linux & macOS ]
```
timestamp=$(date '+%Y-%m-%dT%H:%M:%SZ')
user=$(whoami)
echo $timestamp && echo "Welcome $user"'!'
echo "You have logged in to a production instance. Note that all session activity is being logged."
```
------
#### [ Windows ]
```
$timestamp = (Get-Date).ToString("yyyy-MM-ddTH:mm:ssZ")
$splitName = (whoami).Split("\")
$user = $splitName[1]
Write-Host $timestamp
Write-Host "Welcome $user!"
Write-Host "You have logged in to a production instance. Note that all session activity is being logged."
```
------
Visualizzare l'attività dinamica del sistema all'avvio di una sessione.
------
#### [ Linux & macOS ]
```
top
```
------
#### [ Windows ]
```
while ($true) { Get-Process | Sort-Object -Descending CPU | Select-Object -First 30; `
Start-Sleep -Seconds 2; cls
Write-Host "Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName";
Write-Host "------- ------ ----- ----- ----- ------ -- -----------"}
```
------
# Attiva Esegui come supporto per i nodi gestiti da Linux and macOS
Per impostazione predefinita, Session Manager autentica le connessioni utilizzando le credenziali di un account `ssm-user` generato dal sistema che viene creato su un nodo gestito. (Su computer Linux e macOS, l'account viene aggiunto a `/etc/sudoers/`). Se lo desideri, è possibile invece autenticare le sessioni utilizzando le credenziali di un account utente del sistema operativo (OS), oppure un utente di dominio per le istanze connesse a una Active Directory. In questo caso, Session Manager verifica che l'account dell'OS specificato esista nel nodo o nel dominio prima di iniziare la sessione. Se tenti di avviare una sessione utilizzando un account dell'OS che non esiste nel nodo, o in un dominio, la connessione non viene stabilita.
**Nota**
Session Manager non supporta l'utilizzo di un account utente `root` del sistema operativo per autenticare le connessioni. Per le sessioni autenticate utilizzando un account utente del sistema operativo, le policy a livello di sistema operativo e di directory del nodo, come le restrizioni di accesso o le restrizioni sull'utilizzo delle risorse di sistema, potrebbero non essere applicabili.
**Come funziona**
Se attivi il supporto Esegui come per le sessioni, il sistema controlla le autorizzazioni di accesso come segue:
1. Per l'utente che avvia la sessione, all'entità IAM (utente o ruolo) è stato assegnato il tag `SSMSessionRunAs = os user account name`?
Se Sì, il nome utente dell'OS esiste sul nodo gestito? In tal caso, avviare la sessione. In caso negativo, non consentire l'avvio di una sessione.
Se l'entità IAM *non* è stata contrassegnata con `SSMSessionRunAs = os user account name`, continua con il passaggio 2.
1. Se l'entità IAM non è stata etichettata con`SSMSessionRunAs = os user account name`, è stato specificato un nome utente Account AWS del sistema operativo nelle Session Manager preferenze?
Se Sì, il nome utente dell'OS esiste sul nodo gestito? In tal caso, avviare la sessione. In caso negativo, non consentire l'avvio di una sessione.
**Nota**
Quando attivi il supporto Esegui come, esso impedisce a Session Manager di avviare sessioni utilizzando l'account `ssm-user` su un nodo gestito. Ciò significa che se Session Manager non riesce a connettersi utilizzando l'account utente del sistema operativo specificato, non ricorre alla connessione utilizzando il metodo predefinito.
Se attivi Esegui come senza specificare un account del sistema operativo o assegnare tag a un'entità IAM e non hai specificato un account del sistema operativo nelle preferenze di Session Manager, i tentativi di connessione alla sessione falliranno.
**Per attivare il supporto Esegui come per i nodi gestiti Linux e 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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Seleziona la casella di controllo accanto a **Abilita supporto Esegui come per le istanze Linux**.
1. Esegui una delle seguenti operazioni:
+ **Opzione 1**: nel campo **Nome utente del sistema operativo**, inserisci il nome dell'account utente del sistema operativo che desideri utilizzare per avviare le sessioni. Utilizzando questa opzione, tutte le sessioni vengono eseguite dallo stesso utente del sistema operativo per tutti gli utenti del sistema operativo Account AWS che si connettono tramiteSession Manager.
+ **Opzione 2** (consigliata): scegli il collegamento **Apri la console IAM**. Nel riquadro di navigazione, scegli **Utenti** o **Ruoli**. Scegliere l'entità (utente o ruolo) cui aggiungere tag e quindi selezionare la scheda **Tags (Tag)**. Inserire `SSMSessionRunAs` per il nome chiave. Inserisci il nome di un account utente del sistema operativo per il valore della chiave. Scegli **Salva modifiche**.
Utilizzando questa opzione, è possibile specificare utenti univoci dell'OS per diverse entità IAM, se lo desideri. Per ulteriori informazioni sull'applicazione di tag alle entità IAM (utenti o ruoli), consulta la pagina [Applicazione di tag alle risorse IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *Guida per l'utente IAM*.
Di seguito è riportato un esempio di :
![\[Screenshot di come specificare i tag per l'autorizzazione Esegui come di Session Manager.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/ssn-run-as-tags.png)
1. Scegli **Save** (Salva).
# Attiva la crittografia delle chiavi KMS per i dati delle sessioni (console)
Usa AWS Key Management Service (AWS KMS) per creare e gestire le chiavi di crittografia. Con AWS KMS, puoi controllare l'uso della crittografia in un'ampia gamma di applicazioni Servizi AWS e all'interno delle tue applicazioni. È possibile specificare che i dati di sessione trasmessi tra i nodi gestiti e le macchine locali degli utenti del sistema Account AWS siano crittografati utilizzando la crittografia a chiave KMS. (Questa crittografia si aggiunge alla crittografia TLS 1.2/1.3 AWS già fornita di default). Per crittografare i dati Session Manager della sessione, crea una chiave KMS *simmetrica* utilizzando. AWS KMS
AWS KMS la crittografia è disponibile per e per i tipi `Standard_Stream` di sessione`InteractiveCommands`. `NonInteractiveCommands` Per utilizzare l'opzione per crittografare i dati della sessione utilizzando una chiave creata in AWS KMS, è AWS Systems Manager SSM Agent necessario installare la versione 2.3.539.0 o successiva di sul nodo gestito.
**Nota**
È necessario consentire AWS KMS la crittografia per reimpostare le password sui nodi gestiti dalla console. AWS Systems Manager Per ulteriori informazioni, consulta [Reimpostazione di una password su un nodo gestito](fleet-manager-reset-password.md#managed-instance-reset-a-password).
Puoi usare una chiave che hai creato nel tuo Account AWS. Inoltre, è possibile utilizzare una chiave che è stata creata in un account Account AWS diverso. Il creatore della chiave in un'altra chiave Account AWS deve fornirti le autorizzazioni necessarie per utilizzare la chiave.
Dopo aver abilitato la crittografia delle chiavi KMS per i dati delle sessioni, gli utenti che avviano le sessioni e i nodi gestiti a cui si connettono devono entrambi disporre dell'autorizzazione per utilizzare la chiave. Fornisci l'autorizzazione a utilizzare la chiave KMS Session Manager tramite politiche AWS Identity and Access Management (IAM). Per informazioni, consultare gli argomenti seguenti:
+ Aggiungi AWS KMS le autorizzazioni per gli utenti del tuo account:. [Policy IAM di esempio per Session Manager](getting-started-restrict-access-quickstart.md)
+ Aggiungi AWS KMS le autorizzazioni per i nodi gestiti nel tuo account:. [Fase 2: Verifica o aggiungi le autorizzazioni delle istanze per Session Manager](session-manager-getting-started-instance-profile.md)
Per ulteriori informazioni sulla creazione di una chiave KMS, consulta la [https://docs.aws.amazon.com/kms/latest/developerguide/](https://docs.aws.amazon.com/kms/latest/developerguide/).
Per informazioni sull'utilizzo della AWS CLI crittografia con chiave KMS dei dati di sessione nel tuo account, vedi [Creare un documento di preferenze di Session Manager (riga di comando)](getting-started-create-preferences-cli.md) o. [Aggiornamento delle preferenze Session Manager (riga di comando)](getting-started-configure-preferences-cli.md)
**Nota**
C'è un addebito per l'utilizzo delle chiavi KMS. Per informazioni, consulta [Prezzi di AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
**Attivare la crittografia delle chiavi KMS per i dati delle sessioni (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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Selezionare la casella di controllo accanto ad **Abilita la crittografia KMS**.
1. Esegui una delle seguenti operazioni:
+ Scegliere il pulsante accanto a **Seleziona una chiave KMS nel mio account corrente**, quindi seleziona una chiave dall'elenco.
oppure
Scegliere il pulsante accanto a **Enter a KMS key alias or KMS key ARN (Immetti un alias della chiave o un ARN della chiave KMS)**. Immettere manualmente un alias della chiave KMS per una chiave creata nell'account corrente o immettere l'Amazon Resource Name (ARN) della chiave per una chiave in un altro account. Di seguito vengono mostrati gli esempi:
+ Alias della chiave: `alias/my-kms-key-alias`
+ ARN della chiave: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE`
oppure
Scegli **Crea nuova chiave** per creare una nuova KMS nel tuo account. Una volta creata la nuova chiave, torna alla scheda **Preferenze** e seleziona la chiave per crittografare i dati della sessione nel tuo account.
Per ulteriori informazioni sulla condivisione delle chiavi, consulta [Consentire Account AWS agli esterni di accedere a una chiave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html#key-policy-modifying-external-accounts) nella *Guida per gli AWS Key Management Service sviluppatori*.
1. Scegli **Save** (Salva).
# Creare un documento di preferenze di Session Manager (riga di comando)
Utilizza la seguente procedura per creare documenti SSM che definiscono le tue preferenze per le sessioni. AWS Systems Manager Session Manager Puoi utilizzare il documento per configurare le opzioni della sessione, tra cui la crittografia dei dati, la durata della sessione e la registrazione. Ad esempio, puoi specificare se archiviare i dati di log della sessione in un bucket Amazon Simple Storage Service (Amazon S3) o in un gruppo di log Amazon CloudWatch Logs. Puoi creare documenti che definiscono le preferenze generali per tutte le sessioni per un Account AWS and Regione AWS o che definiscono le preferenze per le singole sessioni.
**Nota**
Puoi inoltre configurare le preferenze generali di sessione utilizzando la console di Session Manager.
I documenti utilizzati per impostare le preferenze di Session Manager devono avere un `sessionType` di `Standard_Stream`. Per ulteriori informazioni sui documenti di sessione, consulta [Schema documento di sessione](session-manager-schema.md).
Per informazioni sull'utilizzo della riga di comando per aggiornare le preferenze Session Manager esistenti, consulta [Aggiornamento delle preferenze Session Manager (riga di comando)](getting-started-configure-preferences-cli.md).
Per un esempio di come creare preferenze di sessione utilizzando CloudFormation, vedere [Create a Systems Manager document for Session Manager preferences](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-document.html#aws-resource-ssm-document--examples) nella *Guida per l'AWS CloudFormation utente*.
**Nota**
Questa procedura descrive come creare documenti per impostare Session Manager le preferenze a Account AWS livello. Per creare documenti che verranno utilizzati per impostare le preferenze a livello di sessione, specifica un valore diverso da `SSM-SessionManagerRunShell` per il nome file relativo agli input dei comandi.
Per utilizzare il documento per impostare le preferenze per le sessioni avviate dalla AWS Command Line Interface (AWS CLI), fornisci il nome del documento come valore del parametro `--document-name`. Per impostare le preferenze per le sessioni avviate dalla console di Session Manager, puoi digitare o selezionare il nome del documento da un elenco.
**Per creare preferenze Session Manager (riga di comando)**
1. Sul proprio computer locale creare un file JSON denominato ad esempio `SessionManagerRunShell.json`, quindi incollarvi i seguenti contenuti:
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "",
"runAsEnabled": false,
"runAsDefaultUser": "",
"idleSessionTimeout": "",
"maxSessionDuration": "",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
Puoi anche passare i valori alle preferenze delle sessioni utilizzando i parametri invece di codificare i valori come illustrato nell'esempio seguente.
```
{
"schemaVersion":"1.0",
"description":"Session Document Parameter Example JSON Template",
"sessionType":"Standard_Stream",
"parameters":{
"s3BucketName":{
"type":"String",
"default":""
},
"s3KeyPrefix":{
"type":"String",
"default":""
},
"s3EncryptionEnabled":{
"type":"Boolean",
"default":"false"
},
"cloudWatchLogGroupName":{
"type":"String",
"default":""
},
"cloudWatchEncryptionEnabled":{
"type":"Boolean",
"default":"false"
}
},
"inputs":{
"s3BucketName":"{{s3BucketName}}",
"s3KeyPrefix":"{{s3KeyPrefix}}",
"s3EncryptionEnabled":"{{s3EncryptionEnabled}}",
"cloudWatchLogGroupName":"{{cloudWatchLogGroupName}}",
"cloudWatchEncryptionEnabled":"{{cloudWatchEncryptionEnabled}}",
"kmsKeyId":""
}
}
```
1. Specificare dove inviare i dati delle sessioni. È possibile specificare un nome di bucket S3 (con un prefisso opzionale) o un nome di gruppo di CloudWatch log Logs. Per crittografare ulteriormente i dati tra client locale e i nodi gestiti, fornisci la chiave KMS da utilizzare per la crittografia. Di seguito è riportato un esempio di :
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyLogGroupName",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "MyKMSKeyID",
"runAsEnabled": true,
"runAsDefaultUser": "MyDefaultRunAsUser",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "MyCommands",
"linux": "MyCommands"
}
}
}
```
**Nota**
Se non si desidera crittografare i dati di log della sessione, modifica `true` in `false` per `s3EncryptionEnabled`.
Se non invii log a un bucket Amazon S3 o a CloudWatch un gruppo di log Logs, non desideri crittografare i dati delle sessioni attive o non desideri attivare il supporto RunAs per le sessioni del tuo account, puoi eliminare le righe relative a tali opzioni. Assicurarsi che l'ultima riga nella sezione `inputs` non termini con una virgola.
Se si aggiunge un ID della chiave KMS per crittografare i dati della sessione, gli utenti che avviano le sessioni e i nodi gestiti a cui si collegano devono entrambi disporre dell'autorizzazione per utilizzare la chiave. Fornire l'autorizzazione a utilizzare la chiave KMS con il Session Manager tramite le policy IAM. Per informazioni, consultare gli argomenti seguenti:
Aggiungi le AWS KMS autorizzazioni per gli utenti del tuo account: [Policy IAM di esempio per Session Manager](getting-started-restrict-access-quickstart.md)
Aggiungi AWS KMS le autorizzazioni per i nodi gestiti nel tuo account: [Fase 2: Verifica o aggiungi le autorizzazioni delle istanze per Session Manager](session-manager-getting-started-instance-profile.md)
1. Salvare il file.
1. Nella directory in cui è stato creato il file JSON, eseguire il comando seguente.
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--name SSM-SessionManagerRunShell \
--content "file://SessionManagerRunShell.json" \
--document-type "Session" \
--document-format JSON
```
------
#### [ Windows ]
```
aws ssm create-document ^
--name SSM-SessionManagerRunShell ^
--content "file://SessionManagerRunShell.json" ^
--document-type "Session" ^
--document-format JSON
```
------
#### [ PowerShell ]
```
New-SSMDocument `
-Name "SSM-SessionManagerRunShell" `
-Content (Get-Content -Raw SessionManagerRunShell.json) `
-DocumentType "Session" `
-DocumentFormat JSON
```
------
Se il comando viene eseguito correttamente, verrà visualizzato un output simile al seguente:
```
{
"DocumentDescription": {
"Status": "Creating",
"Hash": "ce4fd0a2ab9b0fae759004ba603174c3ec2231f21a81db8690a33eb66EXAMPLE",
"Name": "SSM-SessionManagerRunShell",
"Tags": [],
"DocumentType": "Session",
"PlatformTypes": [
"Windows",
"Linux"
],
"DocumentVersion": "1",
"HashType": "Sha256",
"CreatedDate": 1547750660.918,
"Owner": "111122223333",
"SchemaVersion": "1.0",
"DefaultVersion": "1",
"DocumentFormat": "JSON",
"LatestVersion": "1"
}
}
```
# Aggiornamento delle preferenze Session Manager (riga di comando)
La procedura seguente descrive come utilizzare lo strumento da riga di comando preferito per apportare modifiche alle AWS Systems Manager Session Manager preferenze del gruppo selezionato Regione AWS. Account AWS Utilizza Session Manager le preferenze per specificare le opzioni per la registrazione dei dati della sessione in un bucket Amazon Simple Storage Service (Amazon S3) o in un gruppo di log Amazon Logs. CloudWatch Puoi anche utilizzare le preferenze del Session Manager per crittografare i dati delle sessioni.
**Per aggiornare le preferenze Session Manager (riga di comando)**
1. Sul proprio computer locale creare un file JSON denominato ad esempio `SessionManagerRunShell.json`, quindi incollarvi i seguenti contenuti.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "",
"runAsEnabled": true,
"runAsDefaultUser": "",
"idleSessionTimeout": "",
"maxSessionDuration": "",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
1. Specificare dove inviare i dati delle sessioni. Puoi specificare un nome di bucket S3 (con un prefisso opzionale) o un nome di gruppo di log Logs. CloudWatch Se desideri crittografare ulteriormente i dati tra client locale e nodi gestiti, fornisci il codice da utilizzare per la AWS KMS key crittografia. Di seguito è riportato un esempio di :
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyLogGroupName",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "MyKMSKeyID",
"runAsEnabled": true,
"runAsDefaultUser": "MyDefaultRunAsUser",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "MyCommands",
"linux": "MyCommands"
}
}
}
```
**Nota**
Se non si desidera crittografare i dati di log della sessione, modifica `true` in `false` per `s3EncryptionEnabled`.
Se non invii log a un bucket Amazon S3 o a CloudWatch un gruppo di log Logs, non desideri crittografare i dati delle sessioni attive o non desideri attivare il supporto RunAs per le sessioni del tuo account, puoi eliminare le righe relative a tali opzioni. Assicurarsi che l'ultima riga nella sezione `inputs` non termini con una virgola.
Se si aggiunge un ID della chiave KMS per crittografare i dati della sessione, gli utenti che avviano le sessioni e i nodi gestiti a cui si collegano devono entrambi disporre dell'autorizzazione per utilizzare la chiave. Fornisci l'autorizzazione a utilizzare la chiave KMS tramite policy (IAM). Session Manager AWS Identity and Access Management Per informazioni, consultare gli argomenti seguenti:
Aggiungi AWS KMS le autorizzazioni per gli utenti del tuo account:. [Policy IAM di esempio per Session Manager](getting-started-restrict-access-quickstart.md)
Aggiungi AWS KMS le autorizzazioni per i nodi gestiti nel tuo account:. [Fase 2: Verifica o aggiungi le autorizzazioni delle istanze per Session Manager](session-manager-getting-started-instance-profile.md)
1. Salvare il file.
1. Nella directory in cui è stato creato il file JSON, eseguire il comando seguente.
------
#### [ Linux & macOS ]
```
aws ssm update-document \
--name "SSM-SessionManagerRunShell" \
--content "file://SessionManagerRunShell.json" \
--document-version "\$LATEST"
```
------
#### [ Windows ]
```
aws ssm update-document ^
--name "SSM-SessionManagerRunShell" ^
--content "file://SessionManagerRunShell.json" ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
```
Update-SSMDocument `
-Name "SSM-SessionManagerRunShell" `
-Content (Get-Content -Raw SessionManagerRunShell.json) `
-DocumentVersion '$LATEST'
```
------
Se il comando viene eseguito correttamente, verrà visualizzato un output simile al seguente:
```
{
"DocumentDescription": {
"Status": "Updating",
"Hash": "ce4fd0a2ab9b0fae759004ba603174c3ec2231f21a81db8690a33eb66EXAMPLE",
"Name": "SSM-SessionManagerRunShell",
"Tags": [],
"DocumentType": "Session",
"PlatformTypes": [
"Windows",
"Linux"
],
"DocumentVersion": "2",
"HashType": "Sha256",
"CreatedDate": 1537206341.565,
"Owner": "111122223333",
"SchemaVersion": "1.0",
"DefaultVersion": "1",
"DocumentFormat": "JSON",
"LatestVersion": "2"
}
}
```
# Fase 5: (facoltativo) limitazione dell'accesso ai comandi in una sessione
È possibile limitare i comandi che un utente può eseguire in una AWS Systems Manager Session Manager sessione utilizzando un documento `Session` di tipo personalizzato AWS Systems Manager (SSM). Nel documento, puoi definire il comando che viene eseguito quando l'utente avvia una sessione e i parametri che l’utente può fornire al comando. Il documento `Session` `schemaVersion` deve essere 1.0 e il `sessionType` del documento deve essere `InteractiveCommands`. Puoi quindi creare policy AWS Identity and Access Management (IAM) che consentano agli utenti di accedere solo ai documenti `Session` definiti. Per ulteriori informazioni sull'utilizzo delle policy IAM per limitare l'accesso ai comandi in una sessione, consulta [Esempi di policy IAM per comandi interattivi](#interactive-command-policy-examples).
I documenti con `sessionType` of `InteractiveCommands` sono supportati solo per le sessioni iniziate da AWS Command Line Interface (AWS CLI). L'utente fornisce il nome del documento personalizzato come valore del parametro `--document-name` e specifica tutti i valori dei parametri del comando utilizzando l'opzione `--parameters`. Per ulteriori informazioni sull'esecuzione di comandi interattivi, consulta [Avvio di una sessione (comandi interattivi e non interattivi)](session-manager-working-with-sessions-start.md#sessions-start-interactive-commands).
Utilizza la procedura seguente per creare un documento SSM di tipo `Session` personalizzato che definisce il comando che un utente può eseguire.
## Limitare l'accesso ai comandi in una sessione (console)
**Per limitare i comandi che un utente può eseguire in una sessione Session Manager (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 **Documenti**.
1. Scegli **Crea comando o sessione**.
1. Per **Nome**, inserisci un nome descrittivo per il documento.
1. Per **Tipo di documento**, scegli **Documento di sessione**.
1. Immettere il contenuto del documento che definisce il comando che un utente può eseguire in una sessione Session Manager utilizzando JSON o YAML, come illustrato nell'esempio seguente.
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
1. Scegli **Crea documento**.
## Limitare l'accesso ai comandi in una sessione (riga di comando)
**Prima di iniziare**
Se non l'hai già fatto, installa e configura AWS Command Line Interface (AWS CLI) o AWS Strumenti per PowerShell. Per informazioni, consulta le pagine [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Installazione di AWS Strumenti per PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
**Per limitare i comandi che un utente può eseguire in una sessione Session Manager (riga di comando)**
1. Creare un file JSON o YAML per il contenuto del documento che definisce il comando che un utente può eseguire in una sessione Session Manager, come illustrato nell'esempio seguente.
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
1. Eseguire i comandi seguenti per creare un documento SSM utilizzando il contenuto che definisce il comando che un utente può eseguire in una sessione Session Manager.
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--content file://path/to/file/documentContent.json \
--name "exampleAllowedSessionDocument" \
--document-type "Session"
```
------
#### [ Windows ]
```
aws ssm create-document ^
--content file://C:\path\to\file\documentContent.json ^
--name "exampleAllowedSessionDocument" ^
--document-type "Session"
```
------
#### [ PowerShell ]
```
$json = Get-Content -Path "C:\path\to\file\documentContent.json" | Out-String
New-SSMDocument `
-Content $json `
-Name "exampleAllowedSessionDocument" `
-DocumentType "Session"
```
------
## Parametri di comando interattivi e AWS CLI
È possibile fornire parametri di comando interattivi quando si utilizza la AWS CLI. A seconda del sistema operativo (OS) del computer client utilizzato per la connessione ai nodi gestiti con AWS CLI, la sintassi fornita per i comandi che contengono caratteri speciali o di escape potrebbe essere diversa. Gli esempi seguenti mostrano alcuni dei diversi modi in cui è possibile fornire i parametri di comando quando si AWS CLI utilizza e come gestire caratteri speciali o di escape.
Parameter StoreÈ possibile fare riferimento ai parametri memorizzati in nei parametri del AWS CLI comando, come illustrato nell'esempio seguente.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["{{ssm:mycommand}}"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["{{ssm:mycommand}}"]}'
```
------
L'esempio seguente mostra come puoi utilizzare una sintassi abbreviata con la AWS CLI per passare i parametri.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters command="ifconfig"
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters command="ipconfig"
```
------
Puoi anche fornire parametri facoltativi in JSON , come mostrato nel seguente esempio.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["ifconfig"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["ipconfig"]}'
```
------
I parametri possono anche essere memorizzati in un file JSON e forniti AWS CLI come illustrato nell'esempio seguente. Per ulteriori informazioni sull'utilizzo di parametri AWS CLI da un file, consulta [Caricamento di parametri AWS CLI da un file](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-file.html) nella *Guida per l'utente di AWS Command Line Interface *.
```
{
"command": [
"my command"
]
}
```
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters file://complete/path/to/file/parameters.json
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters file://complete/path/to/file/parameters.json
```
------
È inoltre possibile generare AWS CLI uno scheletro da un file di input JSON, come illustrato nell'esempio seguente. *Per ulteriori informazioni sulla generazione di AWS CLI scheletri da file di input JSON, consulta [Generazione di AWS CLI scheletri e parametri di input da un file di input JSON o YAML](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-skeleton.html) nella Guida per l'utente.AWS Command Line Interface *
```
{
"Target": "instance-id",
"DocumentName": "MyInteractiveCommandDocument",
"Parameters": {
"command": [
"my command"
]
}
}
```
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--cli-input-json file://complete/path/to/file/parameters.json
```
------
#### [ Windows ]
```
aws ssm start-session ^
--cli-input-json file://complete/path/to/file/parameters.json
```
------
Per eseguire l'escape dei caratteri all'interno delle virgolette, è necessario aggiungere ulteriori barre rovesciate ai caratteri di escape, come illustrato nell'esempio seguente.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["printf \"abc\\\\tdef\""]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["printf \"abc\\\\tdef\""]}'
```
------
Per ulteriori informazioni sulla citazione con parametri di comando nella AWS CLI, consulta [Utilizzo di virgolette con stringhe nella AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-quoting-strings.html) nella *Guida per l'utente della AWS Command Line Interface *.
## Esempi di policy IAM per comandi interattivi
Puoi creare policy IAM che consentono agli utenti di accedere solo ai documenti `Session` definiti. Ciò limita i comandi che un utente può eseguire in una sessione Session Manager ai soli comandi definiti nei documenti SSM di tipo `Session` personalizzati.
**Consentire a un utente di eseguire un comando interattivo su un singolo nodo**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
**Consentire a un utente di eseguire un comando interattivo su tutti i nodi gestiti**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/*",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
**Consentire a un utente di eseguire più comandi interattivi su tutti i nodi gestiti**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/*",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document-2"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
# Fase 6: (Facoltativo) Utilizzare AWS PrivateLink per configurare un endpoint VPC per Session Manager
È possibile migliorare ulteriormente la posizione di sicurezza dei tuoi nodi gestiti configurando AWS Systems Manager in modo che utilizzi un endpoint di interfaccia di cloud privato virtuale (VPC) (VPC). Gli endpoint di interfaccia sono basati su una tecnologia che consente di accedere in modo privato ad Amazon Elastic Compute Cloud (Amazon EC2) e Systems Manager APIs utilizzando indirizzi IP privati. AWS PrivateLink
AWS PrivateLink limita tutto il traffico di rete tra i nodi gestiti, Systems Manager e Amazon EC2 alla rete Amazon. (I nodi gestiti non hanno accesso a Internet.) Inoltre, non hai bisogno di un gateway Internet, di un dispositivo NAT o di un gateway privato virtuale.
Per informazioni su come creare un endpoint VPC, consulta [Migliora la sicurezza delle istanze EC2 utilizzando gli endpoint VPC per Systems Manager](setup-create-vpc.md).
L'alternativa all'utilizzo di un endpoint VPC è l'abilitazione dell'accesso a Internet in uscita sui nodi gestiti. In questo caso, i nodi gestiti devono permettere anche il traffico in uscita HTTPS (porta 443) verso i seguenti endpoint:
+ `ec2messages.region.amazonaws.com`
+ `ssm.region.amazonaws.com`
+ `ssmmessages.region.amazonaws.com`
Systems Manager utilizza l'ultimo di questi endpoint, `ssmmessages.region.amazonaws.com` per effettuare chiamate da SSM Agent al servizio Session Manager nel cloud.
Per utilizzare funzionalità opzionali come la crittografia AWS Key Management Service (AWS KMS), lo streaming dei log su Amazon CloudWatch Logs (CloudWatch Logs) e l'invio di log ad Amazon Simple Storage Service (Amazon S3), devi consentire il traffico HTTPS (porta 443) in uscita ai seguenti endpoint:
+ `kms.region.amazonaws.com`
+ `logs.region.amazonaws.com`
+ `s3.region.amazonaws.com`
Per ulteriori informazioni sugli endpoint richiesti per Systems Manager, consultare [Referenza: ec2messages, ssmmessages e altre operazioni API](systems-manager-setting-up-messageAPIs.md).
# Fase 7 (facoltativo): abilitazione o disabilitazione delle autorizzazioni amministrative dell'account ssm-account
A partire dalla versione 2.3.50.0 di AWS Systems Manager SSM Agent, l'agente crea un account utente locale chiamato `ssm-user` e lo aggiunge a `/etc/sudoers` (LinuxandmacOS) o al gruppo Administrators (). Windows Nelle versioni dell'agente precedenti alla 2.3.612.0, l'account viene creato la prima volta che SSM Agent viene avviato o riavviato dopo l'installazione. Nella versione 2.3.612.0 e successive, l'account `ssm-user` viene creato la prima volta che una sessione viene avviata su un nodo. Si `ssm-user` tratta dell'utente predefinito del sistema operativo (OS) all'avvio di una AWS Systems Manager Session Manager sessione. SSM Agentla versione 2.3.612.0 è stata rilasciata l'8 maggio 2019.
Se desideri impedire agli utenti Session Manager di eseguire comandi amministrativi su un nodo, puoi aggiornare le autorizzazioni dell'account `ssm-user`. Puoi anche ripristinare queste autorizzazioni dopo che sono state rimosse.
**Topics**
+ [
## Gestione delle autorizzazioni sudo per l'account ssm-user su Linux e macOS
](#ssm-user-permissions-linux)
+ [
## Gestione delle autorizzazioni di amministratore per l'account ssm-user su Windows Server
](#ssm-user-permissions-windows)
## Gestione delle autorizzazioni sudo per l'account ssm-user su Linux e macOS
Utilizza una delle seguenti procedure per abilitare o disabilitare le autorizzazioni sudo per l'account ssm-user sui nodi gestiti Linux e macOS.
**Utilizza Run Command per modificare le autorizzazioni sudo di ssm-user (console)**
+ Utilizza la procedura descritta in [Esecuzione di comandi dalla console](running-commands-console.md) con i seguenti valori:
+ Per **Documenti di comando**, scegli `AWS-RunShellScript`.
+ Per rimuovere l'accesso sudo, nell'area **Parametri di comando**, incolla quanto segue nella casella **Comandi**.
```
cd /etc/sudoers.d
echo "#User rules for ssm-user" > ssm-agent-users
```
oppure
Per ripristinare l'accesso sudo, nell'area **Parametri di comando**, incolla quanto segue nella casella **Comandi**.
```
cd /etc/sudoers.d
echo "ssm-user ALL=(ALL) NOPASSWD:ALL" > ssm-agent-users
```
**Utilizza la riga di comando per modificare le autorizzazioni sudo di ssm-user (AWS CLI)**
1. Connettersi al nodo master ed eseguire il comando seguente.
```
sudo -s
```
1. Cambiare la directory di lavoro utilizzando il comando seguente.
```
cd /etc/sudoers.d
```
1. Aprire il file denominato `ssm-agent-users` per la modifica.
1. Per rimuovere l'accesso sudo, eliminare la riga seguente.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
oppure
Per ripristinare l'accesso sudo, aggiungere la riga seguente.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
1. Salvare il file.
## Gestione delle autorizzazioni di amministratore per l'account ssm-user su Windows Server
Utilizza una delle seguenti procedure per abilitare o disabilitare le autorizzazioni di amministratore per l'account ssm-user sui nodi gestiti Windows Server:
**Utilizza Run Command per modificare le autorizzazioni di amministratore (console)**
+ Utilizza la procedura descritta in [Esecuzione di comandi dalla console](running-commands-console.md) con i seguenti valori:
Per **Documenti di comando**, scegli `AWS-RunPowerShellScript`.
Per rimuovere l'accesso amministrativo, nell'area **Parametri di comando**, incolla quanto segue nella casella **Comandi**.
```
net localgroup "Administrators" "ssm-user" /delete
```
oppure
Per ripristinare l'accesso amministrativo, nell'area **Parametri di comando**, incolla quanto segue nella casella **Comandi**.
```
net localgroup "Administrators" "ssm-user" /add
```
**Utilizza PowerShell o la finestra del prompt dei comandi per modificare le autorizzazioni di amministratore**
1. Connettiti al nodo gestito e apri PowerShell o la finestra del prompt dei comandi.
1. Per rimuovere l'accesso amministrativo, eseguire il comando riportato di seguito.
```
net localgroup "Administrators" "ssm-user" /delete
```
oppure
Per ripristinare l'accesso amministrativo, eseguire il comando riportato di seguito.
```
net localgroup "Administrators" "ssm-user" /add
```
**Utilizza la console Windows per modificare le autorizzazioni di amministratore**
1. Connettiti al nodo gestito e apri PowerShell o la finestra del prompt dei comandi.
1. Dalla riga di comando, esegui `lusrmgr.msc` per aprire la console **Utenti e gruppi locali**.
1. Apri la directory **Utenti**, quindi apri **ssm-user**.
1. Nella scheda **Membro di**, esegui una delle seguenti operazioni:
+ Per rimuovere l'accesso amministrativo, seleziona **Amministratori**, quindi scegli **Rimuovi**.
oppure
Per ripristinare l'accesso amministrativo, inserire **Administrators** nella casella di testo, quindi scegli **Aggiungi**.
1. Scegli **OK**.
# Fase 8: (facoltativo) abilitazione e controllo delle autorizzazioni per le connessioni SSH tramite Session Manager
Puoi consentire agli utenti del tuo account Account AWS di utilizzare il AWS Command Line Interface (AWS CLI) per stabilire connessioni Secure Shell (SSH) ai nodi gestiti utilizzando. AWS Systems Manager Session Manager Gli utenti che si connettono utilizzando SSH possono anche copiare i file tra i loro computer locali e gli nodi gestiti usando SCP (Secure Copy Protocol). È possibile usare questa funzionalità per connetterti ai nodi gestiti senza aprire porte in entrata o gestire host bastion.
Quando stabilisci connessioni SSH tramiteSession Manager, SSM Agent crei AWS CLI WebSocket connessioni sicure tramite TLS agli endpoint. Session Manager La sessione SSH viene eseguita all'interno di questo tunnel crittografato, che fornisce un ulteriore livello di sicurezza senza richiedere l'apertura delle porte in ingresso sui nodi gestiti.
Dopo aver consentito le connessioni SSH, puoi utilizzare le policy AWS Identity and Access Management (IAM) per consentire o negare esplicitamente a utenti, gruppi o ruoli di effettuare connessioni SSH. Session Manager
**Nota**
La registrazione non è disponibile per sessioni Session Manager che si connettono tramite inoltro porta o SSH. Questo perché SSH crittografa tutti i dati della sessione all'interno della connessione TLS sicura stabilita tra gli Session Manager endpoint AWS CLI e funge Session Manager solo da tunnel per le connessioni SSH.
**Topics**
+ [
## Consentire connessioni SSH per Session Manager
](#ssh-connections-enable)
+ [
## Controllo delle autorizzazioni utente per le connessioni SSH tramite Session Manager
](#ssh-connections-permissions)
## Consentire connessioni SSH per Session Manager
Attenersi alla seguente procedura per abilitare le connessioni SSH tramite Session Manager su un nodo gestito.
**Per consentire connessioni SSH per Session Manager**
1. Nel nodo gestito per cui si desidera permettere le connessioni SSH, procedere nel modo seguente:
+ Accertarsi che SSH sia in esecuzione sul nodo gestito. (È possibile chiudere le porte in entrata sul nodo.)
+ Accertarsi che SSM Agent versione 2.3.672.0 o successiva sia installata sul nodo gestito.
Per informazioni su come installare e aggiornare SSM Agent su un nodo gestito, consulta i seguenti argomenti:
+ [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Windows Server](manually-install-ssm-agent-windows.md).
+ [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Linux](manually-install-ssm-agent-linux.md)
+ [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per macOS](manually-install-ssm-agent-macos.md)
+ [Come installare SSM Agent su nodi Windows ibridi](hybrid-multicloud-ssm-agent-install-windows.md)
+ [Come installare SSM Agent su nodi Linux ibridi](hybrid-multicloud-ssm-agent-install-linux.md)
**Nota**
Per utilizzarli Session Manager con server locali, dispositivi periferici e macchine virtuali (VMs) attivati come nodi gestiti, è necessario utilizzare il livello Advanced-Instances. Per ulteriori informazioni sulle istanze avanzate, consulta [Configurazione dei livelli di istanza](fleet-manager-configure-instance-tiers.md).
1. Sul computer locale da cui si desidera connettersi a un nodo gestito tramite SSH, procedi nel modo seguente:
+ Accertarsi che la versione 1.1.23.0 o successiva del plugin Session Manager sia installata.
Per informazioni sull'istallazione del plugin Session Manager, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
+ Aggiornare il file di configurazione SSH per permettere l'esecuzione di un comando proxy che avvia una sessione Session Manager e trasferire tutti i dati tramite la connessione.
**Linux e macOS**
**Suggerimento**
Il file di configurazione SSH si trova in genere nel percorso `~/.ssh/config`.
Aggiungere quanto segue al file di configurazione sul computer locale.
```
# SSH over Session Manager
Host i-* mi-*
ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
User ec2-user
```
** Windows **
**Suggerimento**
Il file di configurazione SSH si trova in genere nel percorso `C:\Users\\.ssh\config`.
Aggiungere quanto segue al file di configurazione sul computer locale.
```
# SSH over Session Manager
Host i-* mi-*
ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p"
```
+ Creare o verificare di disporre di un certificato Privacy Enhanced Mail Certificate (un file PEM) o almeno una chiave pubblica, da utilizzare quando si stabiliscono connessioni a nodi gestiti. Questa deve essere una chiave già associata al nodo gestito. Le autorizzazioni del file di chiavi private devono essere impostate in modo che tu sia l'unico a poterlo leggere. È possibile utilizzare il seguente comando per impostare le autorizzazioni del file di chiavi private in modo che tu sia l'unico a poterlo leggere.
```
chmod 400 .pem
```
Ad esempio, per un'istanza Amazon Elastic Compute Cloud (Amazon EC2), il file della coppia di chiavi creata o selezionata al momento della creazione dell'istanza. (Specificare il percorso al certificato o alla chiave come parte del comando per avviare una sessione. Per informazioni sull'avvio di una sessione tramite SSH, consultare ) [Avvio di una sessione (SSH)](session-manager-working-with-sessions-start.md#sessions-start-ssh).)
## Controllo delle autorizzazioni utente per le connessioni SSH tramite Session Manager
Dopo aver abilitato le connessioni SSH tramite Session Manager su un nodo gestito, è possibile utilizzare le policy IAM per consentire o impedire a utenti, gruppi o ruoli la possibilità di effettuare connessioni SSH tramite Session Manager.
**Per utilizzare una policy IAM per consentire le connessioni SSH tramite Session Manager**
+ Utilizza una delle opzioni seguenti:
+ **Opzione 1**: apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
Nel riquadro di navigazione, scegli **Policy** e quindi aggiorna le policy di autorizzazioni per l'utente o il ruolo che desideri possa avviare le connessioni SSH tramite Session Manager.
Ad esempio, aggiungi il seguente elemento alla policy di avvio rapido creata in [Policy di avvio rapido per utenti finali per Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user). Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/instance-id",
"arn:aws:ssm:*:*:document/AWS-StartSSHSession"
]
},
{
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
}
]
}
```
------
+ **Opzione 2**: collega una politica in linea a una politica utente utilizzando l' Console di gestione AWS AWS CLI, l'o l' AWS API.
Utilizzando il metodo che preferisci, allega la dichiarazione sulla politica dell'**Opzione 1** alla politica per un AWS utente, gruppo o ruolo.
Per informazioni, consulta [Aggiunta e rimozione di autorizzazioni per identità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) nella *Guida per l'utente di IAM*.
**Per utilizzare una policy IAM che neghi le connessioni SSH tramite Session Manager**
+ Utilizza una delle opzioni seguenti:
+ **Opzione 1**: apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). Nel riquadro di navigazione, scegli **Policy** e quindi aggiorna le policy di autorizzazione per l'utente o il ruolo per bloccare l'avvio delle sessioni Session Manager.
Ad esempio, aggiungi il seguente elemento alla policy di avvio rapido creata in [Policy di avvio rapido per utenti finali per Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ssm:StartSession",
"Resource": "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
},
{
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
}
]
}
```
------
+ **Opzione 2**: collega una politica in linea a una politica utente utilizzando l' Console di gestione AWS AWS CLI, l'o l' AWS API.
Utilizzando il metodo che preferisci, allega la dichiarazione sulla politica dell'**Opzione 1** alla politica per un AWS utente, gruppo o ruolo.
Per informazioni, consulta [Aggiunta e rimozione di autorizzazioni per identità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) nella *Guida per l'utente di IAM*.
# Utilizzo di Session Manager
Puoi utilizzare la console AWS Systems Manager la console Amazon Elastic Compute Cloud (Amazon EC2) o la AWS Command Line Interface (AWS CLI) per avviare sessioni che ti connettono ai nodi gestiti cui l'amministratore ti ha garantito l'accesso utilizzando le Policy (IAM) AWS Identity and Access Management. A seconda delle autorizzazioni, puoi anche visualizzare le informazioni sulle sessioni, riprendere le sessioni inattive non ancora scadute e terminare le sessioni. Una volta stabilita, la sessione non è influenzata dalla durata della sessione del ruolo IAM. Per informazioni sulla limitazione della durata della sessione con Session Manager, consulta le sezioni [Specificare un valore di timeout della sessione di inattività](session-preferences-timeout.md) e [Specifica la durata massima della sessione](session-preferences-max-timeout.md).
Per ulteriori informazioni sulle sessioni, consulta [Che cos'è una sessione?](session-manager.md#what-is-a-session)
**Topics**
+ [
# Installa il Session Manager plugin per AWS CLI
](session-manager-working-with-install-plugin.md)
+ [
# Avvio di una sessione
](session-manager-working-with-sessions-start.md)
+ [
# Terminare una sessione
](session-manager-working-with-sessions-end.md)
+ [
# Visualizzazione della cronologia delle sessioni
](session-manager-working-with-view-history.md)
# Installa il Session Manager plugin per AWS CLI
Per avviare sessioni di Session Manager con i nodi gestiti utilizzando la AWS Command Line Interface (AWS CLI), è necessario installare il *plugin di Session Manager* sul computer locale. È possibile installare il plug-in su versioni supportate di Microsoft Windows Server, macOS, Linux e Ubuntu Server.
**Nota**
Per utilizzare il Session Manager plugin, devi avere la AWS CLI versione 1.16.12 o successiva installata sul tuo computer locale. Per ulteriori informazioni, consulta [Installare o aggiornare la versione più recente della AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Topics**
+ [
# Cronologia delle versioni e versione più recente del plug-in Session Manager
](plugin-version-history.md)
+ [
# Installa il plugin Session Manager su Windows
](install-plugin-windows.md)
+ [
# Installa il plugin Session Manager su macOS
](install-plugin-macos-overview.md)
+ [
# Installa il plug-in di Session Manager su Linux
](install-plugin-linux-overview.md)
+ [
# Verificare l'installazione del plugin Session Manager
](install-plugin-verify.md)
+ [
# Plugin di Session Manager su GitHub
](plugin-github.md)
+ [
# (Facoltativo) Attivare la registrazione del plug-in Session Manager
](install-plugin-configure-logs.md)
# Cronologia delle versioni e versione più recente del plug-in Session Manager
Il computer locale deve eseguire una versione supportata del plug-in Session Manager. La versione minima attualmente supportata è 1.1.17.0. Se esegui una versione precedente, le operazioni del plug-in Session Manager potrebbero non andare a buon fine.
Per vedere se hai la versione più recente, esegui il comando riportato di seguito in AWS CLI.
**Nota**
Il comando restituisce risultati solo se il plug-in si trova nella directory di installazione di default per il tuo tipo di sistema operativo. È possibile anche controllare la versione nel contenuto del file `VERSION` nella directory in cui è stato installato il plugin.
```
session-manager-plugin --version
```
La tabella seguente elenca tutte le release del plug-in Session Manager, nonché le funzionalità e i miglioramenti inclusi in ciascuna versione.
**Importante**
Consigliamo di eseguire sempre la versione più recente. L'ultima versione include miglioramenti che migliorano l'esperienza di utilizzo del plug-in.
| Versione | Data di rilascio | Informazioni |
| --- | --- | --- |
| 1,2,792,0 | 17 marzo 2026 | Correzione di **bug**: Aggiunto il supporto internazionale per tastiera per Windows. |
| 1.2.779.0 | 12 febbraio 2026 | **Miglioramento**: aggiorna la versione Go alla 1.25 in Dockerfile. **Correzione di bug**: aggiungi le righe shebang agli script di pacchettizzazione di Debian. |
| 1.2.764.0 | 19 novembre 2025 | **Miglioramento**: è stato aggiunto il supporto per la richiesta di firma. OpenDataChannel Correzione di **bug: correggi** i problemi di checkstyle per supportare la nuova versione di Go. |
| 1.2.707.0 | 6 febbraio 2025 | **Miglioramento**: aggiornamento della versione Go alla 1.23 nel Dockerfile. Aggiornamento della fase di configurazione della versione nel README. |
| 1,2,694,0 | 20 novembre 2024 | Correzione di **bug**: modifica annullata che aggiungeva credenziali alle richieste. OpenDataChannel |
| 1.2.688.0 | 6 novembre 2024 | **Questa versione è stata resa obsoleta il 20 novembre 2024.** **Miglioramenti**:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/plugin-version-history.html) |
| 1.2.6770 | 10 ottobre 2024 | **Miglioramento**: aggiunto il supporto per il passaggio della versione del plugin con richieste. OpenDataChannel |
| 1.2.650.0 | 2 luglio 2024 | **Miglioramento: aggiornato** a 1.54.10. aws-sdk-go**Correzione di bug**: riformati commenti per gofmt check. |
| 1.2.633,0 | 30 maggio 2024 | Miglioramento: è stato aggiornato il Dockerfile per utilizzare un'immagine Amazon Elastic Container Registry (Amazon ECR). |
| 1,2553,0 | 10 gennaio 2024 | Miglioramento: pacchetti Golang aggiornati aws-sdk-go e dipendenti. |
| 1.2,536,0 | 04 dicembre 2023 | Miglioramento: è stato aggiunto il supporto per il passaggio di una risposta [StartSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html)API come variabile di ambiente a. session-manager-plugin |
| 1.2.497.0 | 1° agosto 2023 | Miglioramento: Go SDK aggiornato alla versione 1.44.302. |
| 1,2,463,0 | 15 marzo 2023 | Miglioramento: aggiunto il supporto Mac with Apple silicon per Apple Mac (M1) nel programma di installazione del bundle macOS e nel programma di installazione firmato. |
| 1,2398,0 | 14 ottobre 2022 | Miglioramento: supporto per la versione golang 1.17. Aggiorna il session-manager-plugin runner predefinito per macOS per usare python3. Aggiorna il percorso di importazione da SSMCLI a. session-manager-plugin |
| 1.2.339.0 | 16 giugno 2022 | Correzione di bug: correzione del timeout della sessione inattiva per le sessioni di porta. |
| 1,2331,0 | 27 maggio 2022 | Correzione di bug: correzione della chiusura prematura delle sessioni della porta quando il server locale non si connette prima del timeout. |
| 1,2,323,0 | 19 maggio 2022 | Correzione di bug: disabilita smux keep alive per utilizzare la funzione di timeout della sessione inattiva. |
| 1,2312,0 | 31 marzo 2022 | Miglioramento: supporta più tipi di payload dei messaggi di output. |
| 1,2295,0 | 12 gennaio 2022 | Correzione di bug: sessioni sospese causate dal client che invia nuovamente i dati del flusso quando l'agente diventa inattivo e i log errati per i messaggi di start\$1publication e pause\$1publication. |
| 1,2279,0 | 27 ottobre 2021 | Miglioramento: packaging in formato zip per la piattaforma Windows. |
| 1,2245,0 | 19 agosto 2021 | Miglioramento: Aggiornamento di aws-sdk-go alla versione più recente (v1.40.17) per supportare AWS IAM Identity Center. |
| 1,2234,0 | 26 luglio 2021 | Risoluzione dei bug: Gestione dello scenario di una sessione terminata improvvisamente nel tipo di sessione interattiva. |
| 12,205,0 | 10 giugno 2021 | Miglioramento: è stato aggiunto il supporto per il programma di installazione firmato macOS. |
| 1,2,54,0 | 29 gennaio 2021 | Miglioramento: è stato aggiunto il supporto per l'esecuzione di sessioni in modalità di esecuzione. NonInteractiveCommands |
| 1.2.30.0 | 24 novembre 2020 | **Miglioramento**: (solo le sessioni di inoltro delle porte) Miglioramento delle prestazioni complessive. |
| 1.2.7.0 | 15 ottobre 2020 | **Miglioramento**: (solo le sessioni di inoltro delle porte) latenza ridotta e prestazioni complessive migliorate. |
| 1.1.61.0 | 17 aprile 2020 | **Miglioramento**: aggiunto il supporto ARM per Linux e Ubuntu Server. |
| 1.1.54.0 | 6 gennaio 2020 | **Correzione di bug**: gestione dello scenario di race condition dei pacchetti che vengono rilasciati quando il plug-in Session Manager non è pronto. |
| 1.1.50.0 | 19 novembre 2019 | **Miglioramento**: Aggiunto il supporto per l'inoltro di una porta a un socket unix locale. |
| 1.1.35.0 | 7 novembre 2019 | **Miglioramento**: (solo sessioni di port forwarding) Invia un TerminateSession comando a quando l'utente locale preme. SSM Agent `Ctrl+C` |
| 1.1.33.0 | 26 settembre 2019 | Miglioramento: (solo sessioni di inoltro alla porta) invia un segnale di disconnessione al server quando il client rimuove la connessione TCP. |
| 1.1.31.0 | 6 settembre 2019 | Miglioramento: aggiorna per mantenere aperta la sessione di inoltro alla porta finché il server remoto non chiude la connessione. |
| 1.1.26.0 | 30 luglio 2019 | **Miglioramento**: aggiornamento per limitare la velocità di trasferimento dei dati durante una sessione. |
| 1.1.23.0 | 09 luglio 2019 | **Miglioramento**: aggiunta del supporto per l'esecuzione di sessioni SSH utilizzando Session Manager. |
| 1.1.17.0 | 4 aprile 2019 | **Miglioramento**: aggiunta del supporto per ulteriore crittografia dei dati delle sessioni utilizzando AWS Key Management Service (AWS KMS). |
| 1.0.37.0 | 20 settembre 2018 | **Miglioramento**: correzione di bug per la versione Windows. |
| 1.0.0.0 | 11 settembre 2018 | Versione iniziale del plug-in Session Manager. |
# Installa il plugin Session Manager su Windows
Puoi installare il plugin di Session Manager su Windows Vista o versione successiva utilizzando il programma di installazione autonomo.
Quando vengono rilasciati gli aggiornamenti, è necessario ripetere il processo di installazione per ottenere la versione più recente del plug-in Session Manager.
**Nota**
Osservare le seguenti informazioni.
Il programma di installazione del plugin di Session Manager necessita dei diritti di amministratore per installare il plug-in.
Per ottenere risultati ottimali, ti consigliamo di avviare sessioni sui client Windows utilizzando Windows PowerShell versione 5 o successiva. In alternativa, puoi utilizzare la shell Command in Windows 10. Il plugin Session Manager supporta solo PowerShell e la shell Command. Gli strumenti a riga di comando di terze parti potrebbero non essere compatibili con il plug-in.
**Per installare il plug-in Session Manager utilizzando il programma di installazione EXE**
1. Scaricare il programma di installazione utilizzando l'URL seguente.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPluginSetup.exe
```
In alternativa, è possibile scaricare una versione compressa del programma di installazione utilizzando il seguente URL.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPlugin.zip
```
1. Esegui il programma di installazione scaricato e segui le istruzioni sullo schermo. Se hai scaricato la versione compressa del programma di installazione, devi prima decomprimere il programma di installazione.
Lasciare vuota la casella del percorso di installazione per installare il plug-in nella directory di default.
+ `%PROGRAMFILES%\Amazon\SessionManagerPlugin\bin\`
1. Verificare che l'installazione sia stata effettuata correttamente. Per informazioni, consulta [Verificare l'installazione del plugin Session Manager](install-plugin-verify.md).
**Nota**
Se Windows non è in grado di trovare l'eseguibile, potrebbe essere necessario aprire nuovamente il prompt dei comandi o aggiungere manualmente la directory di installazione alla variabile di ambiente `PATH`. Per ulteriori informazioni relative alla risoluzione di problemi, consultare [Il plug-in di Session Manager non viene aggiunto automaticamente al percorso della riga di comando (Windows)](session-manager-troubleshooting.md#windows-plugin-env-var-not-set).
# Installa il plugin Session Manager su macOS
Scegli uno dei seguenti argomenti per installare il plug-in di Session Manager su macOS.
**Nota**
Il programma di installazione firmato è un file `.pkg` firmato. Il programma di installazione in bundle utilizza un file `.zip`. Una volta decompresso il file, puoi installare il plug-in utilizzando il file binario.
## Installazione di plug-in Session Manager su macOS con il programma di installazione firmato
Questa sezione descrive come installare il plugin di Session Manager su macOS utilizzando il programma di installazione firmato.
**Per installare il plug-in Session Manager utilizzando il programma di installazione firmato (macOS)**
1. Scaricare il programma di installazione firmato.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
#### [ Mac con processore Apple ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
1. Esegui i comandi di installazione. Se il comando fa errore, verifica che la cartella `/usr/local/bin` esista. In caso contrario, creala ed esegui nuovamente il comando.
```
sudo installer -pkg session-manager-plugin.pkg -target /
sudo ln -s /usr/local/sessionmanagerplugin/bin/session-manager-plugin /usr/local/bin/session-manager-plugin
```
1. Verificare che l'installazione sia stata effettuata correttamente. Per informazioni, consulta [Verificare l'installazione del plugin Session Manager](install-plugin-verify.md).
## Installa il plugin Session Manager su macOS
Questa sezione descrive come installare il plugin di Session Manager su macOS utilizzando il programma di installazione in bundle.
**Importante**
Prendi nota delle seguenti informazioni importanti.
Per impostazione predefinita, il programma di installazione richiede l'accesso sudo per l'esecuzione, poiché lo script installa il plug-in nella directory di sistema di `/usr/local/sessionmanagerplugin`. Se non vuoi installare il plugin usando sudo, aggiorna manualmente lo script di installazione per installare il plugin in una directory che non richiede l'accesso sudo.
Non supporta l’installazione in percorsi che contengono spazi.
**Per installare il plug-in Session Manager mediante il programma di installazione in bundle (macOS)**
1. Scarica il programma di installazione in bundle.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
#### [ Mac con processore Apple ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
1. Decomprimi il pacchetto.
```
unzip sessionmanager-bundle.zip
```
1. Eseguire il comando di installazione.
```
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
**Nota**
Il plugin richiede Python 3.10 o successivo. Per default, lo script di installazione viene eseguito con la versione di Python di default del sistema. Se è installata una versione alternativa di Python e si intende utilizzare questa per installare il Session Manager, eseguire lo script del programma di installazione con tale versione dal percorso assoluto dell'eseguibile di Python. Di seguito è riportato un esempio di :
```
sudo /usr/local/bin/python3.11 sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
Il programma di installazione installa il Session Manager in `/usr/local/sessionmanagerplugin` e crea il collegamento simbolico `session-manager-plugin` nella directory `/usr/local/bin`. Ciò elimina la necessità di specificare la directory di installazione nella variabile `$PATH` dell'utente.
Per vedere una spiegazione delle opzioni `-i` e `-b`, usa l'opzione `-h`.
```
./sessionmanager-bundle/install -h
```
1. Verificare che l'installazione sia stata effettuata correttamente. Per informazioni, consulta [Verificare l'installazione del plugin Session Manager](install-plugin-verify.md).
**Nota**
Per disinstallare il plugin, esegui i due comandi riportati di seguito nell'ordine visualizzato.
```
sudo rm -rf /usr/local/sessionmanagerplugin
```
```
sudo rm /usr/local/bin/session-manager-plugin
```
# Installa il plug-in di Session Manager su Linux
Questa sezione include informazioni sulla verifica della firma del pacchetto del programma di installazione del plug-in di Session Manager e sull'installazione del plug-in nelle seguenti distribuzioni Linux:
+ Amazon Linux 2
+ AL2023
+ RHEL
+ Debian Server
+ Ubuntu Server
**Topics**
+ [
# Verifica la firma del plug-in di Session Manager
](install-plugin-linux-verify-signature.md)
+ [
# Installa il plug-in di Session Manager su Amazon Linux 2, Amazon Linux 2023 e distribuzioni Red Hat Enterprise Linux
](install-plugin-linux.md)
+ [
# Installazione del plug-in Session Manager su Debian Server e Ubuntu Server
](install-plugin-debian-and-ubuntu.md)
# Verifica la firma del plug-in di Session Manager
I pacchetti del programma di installazione RPM e Debian del plug-in di Session Manager per le istanze Linux sono firmati crittograficamente. È possibile utilizzare una chiave pubblica per verificare che il plug-in binario e il pacchetto siano originali e non modificati. Se i file sono in qualche modo danneggiati o alterati, la verifica non va a buon fine. È possibile verificare la firma del programma di installazione tramite lo strumento GNU Privacy Guard (GPG). Le seguenti informazioni sono relative alle versioni 1.2.707.0 o successive del plug-in di Session Manager.
Completa i seguenti passaggi, per verificare la firma del pacchetto del programma di installazione del plug-in di Session Manager.
**Topics**
+ [
## Passaggio 1: scarica il pacchetto del programma di installazione del plug-in diSession Manager
](#install-plugin-linux-verify-signature-installer-packages)
+ [
## Passaggio 2: scarica il file di firma associato
](#install-plugin-linux-verify-signature-packages)
+ [
## Passaggio 3: installa lo strumento GPG
](#install-plugin-linux-verify-signature-packages-gpg)
+ [
## Passaggio 4: verifica il pacchetto del programma di installazione del plug-in di Session Manager in un server Linux
](#install-plugin-linux-verify-signature-packages)
## Passaggio 1: scarica il pacchetto del programma di installazione del plug-in diSession Manager
Scarica il pacchetto del programma di installazione del plug-in di Session Manager che desideri verificare.
**Amazon Linux 2 AL2023 e pacchetti RHEL RPM**
------
#### [ x86\$164 ]
```
curl -o "session-manager-plugin.rpm" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm"
```
------
#### [ ARM64 ]
```
curl -o "session-manager-plugin.rpm" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm"
```
------
**Pacchetti Debian Server e Deb Ubuntu Server**
------
#### [ x86\$164 ]
```
curl -o "session-manager-plugin.deb" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb"
```
------
#### [ ARM64 ]
```
curl -o "session-manager-plugin.deb" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb"
```
------
## Passaggio 2: scarica il file di firma associato
Dopo aver scaricato il pacchetto del programma di installazione, scarica il file di firma associato per la verifica del pacchetto. Per fornire un ulteriore livello di protezione contro la copia o l'uso non autorizzati del file session-manager-plugin binario all'interno del pacchetto, offriamo anche firme binarie, che puoi utilizzare per convalidare singoli file binari. Puoi scegliere di utilizzare queste firme binarie in base alle tue esigenze di sicurezza.
**Amazon Linux 2 AL2023 e pacchetti di RHEL firma**
------
#### [ x86\$164 ]
Pacchetto:
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm.sig"
```
File binario:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
Pacchetto:
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm.sig"
```
File binario:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.sig"
```
------
**Debian Server e pacchetti di firma Deb Ubuntu Server**
------
#### [ x86\$164 ]
Pacchetto:
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb.sig"
```
File binario:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
Pacchetto:
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb.sig"
```
File binario:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.sig"
```
------
## Passaggio 3: installa lo strumento GPG
Per verificare la firma del plug-in di Session Manager, è necessario che sul sistema sia installato lo strumento GNU Privacy Guard (GPG). Il processo di verifica richiede la versione 2.1 o successiva di GPG. Puoi verificare la tua versione GPG eseguendo il comando seguente:
```
gpg --version
```
Se la tua versione di GPG è precedente alla 2.1, aggiornala prima di continuare con il processo di verifica. Per la maggior parte dei sistemi, puoi aggiornare lo strumento GPG usando il tuo gestore di pacchetti. Ad esempio, su versioni di Amazon e RHEL supportate, puoi utilizzare i seguenti comandi:
```
sudo yum update
sudo yum install gnupg2
```
Sui sistemi Ubuntu Server e Debian Server supportati, puoi utilizzare i seguenti comandi:
```
sudo apt-get update
sudo apt-get install gnupg2
```
Assicurati di avere la versione GPG richiesta prima di continuare con il processo di verifica.
## Passaggio 4: verifica il pacchetto del programma di installazione del plug-in di Session Manager in un server Linux
Utilizza la procedura seguente per verificare il pacchetto del programma di installazione del plug-in di Session Manager in un server Linux.
**Nota**
Amazon Linux 2 non supporta la versione 2.1 o successiva dello strumento GPG. Se la seguente procedura non funziona sulle tue istanze Amazon Linux 2, verifica la firma su una piattaforma diversa prima di installarla sulle tue istanze Amazon Linux 2.
1. Copia la seguente chiave pubblica e salvala in un file denominato session-manager-plugin .gpg.
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mFIEZ5ERQxMIKoZIzj0DAQcCAwQjuZy+IjFoYg57sLTGhF3aZLBaGpzB+gY6j7Ix
P7NqbpXyjVj8a+dy79gSd64OEaMxUb7vw/jug+CfRXwVGRMNtIBBV1MgU1NNIFNl
c3Npb24gTWFuYWdlciA8c2Vzc2lvbi1tYW5hZ2VyLXBsdWdpbi1zaWduZXJAYW1h
em9uLmNvbT4gKEFXUyBTeXN0ZW1zIE1hbmFnZXIgU2Vzc2lvbiBNYW5hZ2VyIFBs
dWdpbiBMaW51eCBTaWduZXIgS2V5KYkBAAQQEwgAqAUCZ5ERQ4EcQVdTIFNTTSBT
ZXNzaW9uIE1hbmFnZXIgPHNlc3Npb24tbWFuYWdlci1wbHVnaW4tc2lnbmVyQGFt
YXpvbi5jb20+IChBV1MgU3lzdGVtcyBNYW5hZ2VyIFNlc3Npb24gTWFuYWdlciBQ
bHVnaW4gTGludXggU2lnbmVyIEtleSkWIQR5WWNxJM4JOtUB1HosTUr/b2dX7gIe
AwIbAwIVCAAKCRAsTUr/b2dX7rO1AQCa1kig3lQ78W/QHGU76uHx3XAyv0tfpE9U
oQBCIwFLSgEA3PDHt3lZ+s6m9JLGJsy+Cp5ZFzpiF6RgluR/2gA861M=
=2DQm
-----END PGP PUBLIC KEY BLOCK-----
```
1. Importa la chiave pubblica nel tuo keyring. Il valore della chiave restituito dovrebbe essere `2C4D4AFF6F6757EE`.
```
$ gpg --import session-manager-plugin.gpg
gpg: key 2C4D4AFF6F6757EE: public key "AWS SSM Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)" imported
gpg: Total number processed: 1
gpg: imported: 1
```
1. Per verificare l'impronta digitale, esegui il seguente comando.
```
gpg --fingerprint 2C4D4AFF6F6757EE
```
L'impronta digitale per l'output dell'impronta digitale deve corrispondere a quanto riportato di seguito.
```
7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
```
```
pub nistp256 2025-01-22 [SC]
7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
uid [ unknown] AWS SSM Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)
```
Se l'impronta digitale non corrisponde, non installare il plug-in. Contatto. Supporto AWS
1. Verificare la firma del pacchetto di installazione. Sostituisci *signature-filename* e *downloaded-plugin-filename* con i valori specificati durante il download del file della firma e session-manager-plugin, come indicato nella tabella precedente di questo argomento.
```
gpg --verify signature-filename downloaded-plugin-filename
```
Ad esempio, per l'architettura x86\$164 in Amazon Linux 2, il comando è il seguente:
```
gpg --verify session-manager-plugin.rpm.sig session-manager-plugin.rpm
```
Questo comando restituisce un output simile al seguente.
```
gpg: Signature made Mon Feb 3 20:08:32 2025 UTC gpg: using ECDSA key 2C4D4AFF6F6757EE
gpg: Good signature from "AWS Systems Manager Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
```
Se l'output include la frase `BAD signature`, controllare di avere eseguito la procedura correttamente. Se continui a ricevere questa risposta, contatta Supporto AWS e non installare il pacchetto. Il messaggio di avviso relativo all'attendibilità non indica che la firma non sia valida, ma soltanto che la chiave pubblica non è stata verificata. Una chiave è considerata attendibile solo se è stata firmata dall'utente o da un firmatario fidato. Se l'output include la frase `Can't check signature: No public key`, verifica di aver scaricato il plug-in di Session Manager con la versione 1.2.707.0 o successiva.
# Installa il plug-in di Session Manager su Amazon Linux 2, Amazon Linux 2023 e distribuzioni Red Hat Enterprise Linux
Utilizza la seguente procedura per installare il Session Manager plug-in su Amazon Linux 2, Amazon Linux 2023 (AL2023) e RHEL distribuzioni.
1. Scarica e installa il pacchetto RPM del plugin Session Manager.
------
#### [ x86\$164 ]
Su Amazon Linux 2 e RHEL 7 eseguire il seguente comando:
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
Nelle AL2023 versioni RHEL 8 e 9, esegui il seguente comando:
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
------
#### [ ARM64 ]
Su Amazon Linux 2 e RHEL 7 eseguire il seguente comando:
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
Nei AL2023 giorni RHEL 8 e 9, esegui il seguente comando:
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
------
1. Verificare che l'installazione sia stata effettuata correttamente. Per informazioni, consulta [Verificare l'installazione del plugin Session Manager](install-plugin-verify.md).
**Nota**
Se desideri disinstallare il plugin, esegui `sudo yum erase session-manager-plugin -y`
# Installazione del plug-in Session Manager su Debian Server e Ubuntu Server
1. Scaricare il pacchetto deb del plug-in Session Manager:
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
```
------
#### [ ARM64 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb" -o "session-manager-plugin.deb"
```
------
1. Eseguire il comando di installazione.
```
sudo dpkg -i session-manager-plugin.deb
```
1. Verificare che l'installazione sia stata effettuata correttamente. Per informazioni, consulta [Verificare l'installazione del plugin Session Manager](install-plugin-verify.md).
**Nota**
Se si desidera disinstallare il plugin, eseguire `sudo dpkg -r session-manager-plugin`
# Verificare l'installazione del plugin Session Manager
Per verificare che il plug-in Session Manager sia stato installato, esegui il comando riportato di seguito.
```
session-manager-plugin
```
Se l'installazione è stata completata, viene restituito il seguente messaggio.
```
The Session Manager plugin is installed successfully. Use the AWS CLI to start a session.
```
È anche possibile testare l'installazione eseguendo il comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) riportato di seguito in [AWS Command Line Interface](https://aws.amazon.com/cli/) (AWS CLI). Nel comando seguente, sostituisci *instance-id* con le tue informazioni.
```
aws ssm start-session --target instance-id
```
Questo comando funzionerà solo se hai installato e configurato e se l' AWS CLISession Manageramministratore ti ha concesso le autorizzazioni IAM necessarie per accedere al nodo gestito di destinazione utilizzandoSession Manager.
# Plugin di Session Manager su GitHub
Il codice sorgente per il plug-in di Session Manager è disponibile su [https://github.com/aws/session-manager-plugin](https://github.com/aws/session-manager-plugin) in modo da adattare il plug-in per soddisfare le proprie esigenze. Ti consigliamo di inviare le [richieste pull](https://github.com/aws/session-manager-plugin/blob/mainline/CONTRIBUTING.md) per le modifiche da includere. Tuttavia, Amazon Web Services attualmente non fornisce il supporto per eseguire copie modificate di questo software.
# (Facoltativo) Attivare la registrazione del plug-in Session Manager
Il plug-in Session Manager include un'opzione per abilitare la registrazione per le sessioni che esegui. Per impostazione predefinita, la registrazione è disattivata.
Se abiliti la registrazione, il plug-in Session Manager crea un file di log sia per le attività dell'applicazione (`session-manager-plugin.log`) sia per gli errori (`errors.log`) sul tuo computer locale.
**Topics**
+ [
## Attivare la registrazione per il plug-in Session Manager (Windows)
](#configure-logs-windows)
+ [
## Abilitazione della registrazione per il plug-in Session Manager (Linux e macOS)
](#configure-logs-linux)
## Attivare la registrazione per il plug-in Session Manager (Windows)
1. Individuare il file `seelog.xml.template` per il plugin.
Il percorso predefinito è `C:\Program Files\Amazon\SessionManagerPlugin\seelog.xml.template`.
1. Modificare il nome del file in `seelog.xml`.
1. Aprire il file e modificare `minlevel="off"` in `minlevel="info"` o `minlevel="debug"`.
**Nota**
Per impostazione predefinita, le voci di log relative all'apertura di un canale di dati e alla riconnessione delle sessioni sono registrate nel livello **INFO**. Le voci del flusso di dati (pacchetti e relativa conferma) sono registrate nel livello **DEBUG**.
1. Modificare altre opzioni di configurazione in base alle proprie esigenze. Le opzioni che è possibile modificare includono:
+ **Livello di debug**: è possibile modificare il livello di debug da `formatid="fmtinfo"` a `formatid="fmtdebug"`.
+ **Opzioni relative ai file di log**: è possibile modificare le opzioni relative ai file di log, inclusa la posizione in cui vengono archiviati i log, ad eccezione dei nomi dei file.
**Importante**
Non modificare i nomi dei file, altrimenti la registrazione non funzionerà correttamente.
```
```
1. Salvare il file.
## Abilitazione della registrazione per il plug-in Session Manager (Linux e macOS)
1. Individuare il file `seelog.xml.template` per il plugin.
Il percorso predefinito è `/usr/local/sessionmanagerplugin/seelog.xml.template`.
1. Modificare il nome del file in `seelog.xml`.
1. Aprire il file e modificare `minlevel="off"` in `minlevel="info"` o `minlevel="debug"`.
**Nota**
Per impostazione predefinita, le voci di log relative all'apertura di canali di dati e alla riconnessione delle sessioni sono registrate nel livello **INFO**. Le voci del flusso di dati (pacchetti e relativa conferma) sono registrate nel livello **DEBUG**.
1. Modificare altre opzioni di configurazione in base alle proprie esigenze. Le opzioni che è possibile modificare includono:
+ **Livello di debug**: è possibile modificare il livello di debug da `formatid="fmtinfo"` a `outputs formatid="fmtdebug"`.
+ **Opzioni relative ai file di log**: è possibile modificare le opzioni relative ai file di log, inclusa la posizione in cui vengono archiviati i log, ad eccezione dei nomi dei file.
**Importante**
Non modificare i nomi dei file, altrimenti la registrazione non funzionerà correttamente.
```
```
**Importante**
Se si utilizza la directory di default specificata per l'archiviazione dei log, è necessario eseguire i comandi di sessione utilizzando **sudo** o fornire l'accesso completo in lettura e scrittura alla directory in cui è installato il plugin. Per by-passare queste limitazioni, modifica il percorso in cui vengono archiviati i log.
1. Salvare il file.
# Avvio di una sessione
Puoi utilizzare la AWS Systems Manager console, la console Amazon Elastic Compute Cloud (Amazon EC2), AWS Command Line Interface il AWS CLI() o SSH per avviare una sessione.
**Topics**
+ [
## Avvio di una sessione (console Systems Manager)
](#start-sys-console)
+ [
## Avvio di una sessione (console Amazon EC2 )
](#start-ec2-console)
+ [
## Avvio di una sessione (AWS CLI)
](#sessions-start-cli)
+ [
## Avvio di una sessione (SSH)
](#sessions-start-ssh)
+ [
## Avvio di una sessione (inoltro alla porta)
](#sessions-start-port-forwarding)
+ [
## Avvio di una sessione (inoltro alla porta a un host remoto)
](#sessions-remote-port-forwarding)
+ [
## Avvio di una sessione (comandi interattivi e non interattivi)
](#sessions-start-interactive-commands)
## Avvio di una sessione (console Systems Manager)
Puoi utilizzare la AWS Systems Manager console per avviare una sessione con un nodo gestito nel tuo account.
**Nota**
Prima di avviare una sessione, assicurati di aver completato la procedura di configurazione per Session Manager. Per informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
**Per avviare una sessione (console 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 **Session Manager**.
1. Scegliere **Start session (Avvia sessione)**.
1. (Facoltativo) Inserisci una descrizione della sessione nel campo **Motivo della sessione**.
1. Per **Istanze di destinazione**, scegli il pulsante di opzione a sinistra del nodo gestito a cui desideri connetterti.
Se il nodo che desideri non è presente nell'elenco o se selezioni un nodo e ricevi un errore di configurazione, consulta [Nodo gestito non disponibile o non configurato per Session Manager](session-manager-troubleshooting.md#session-manager-troubleshooting-instances) per la procedura di risoluzione dei problemi.
1. Scegli **Avvia sessione** per avviare immediatamente la sessione.
oppure
Scegli **Avanti** per le opzioni di sessione.
1. (Facoltativo) Per **Documento di sessione**, seleziona il documento che desideri eseguire all'inizio della sessione. Se il documento supporta i parametri di runtime, è possibile inserire uno o più valori separati da virgole in ogni campo dei parametri.
1. Scegli **Next (Successivo)**.
1. Scegliere **Start session (Avvia sessione)**.
Una volta creata la connessione, è possibile eseguire i comandi bash (Linux e macOS) o i comandi PowerShell (Windows) come per qualsiasi altro tipo di connessione.
**Importante**
Se desideri consentire agli utenti di specificare un documento all'avvio delle sessioni nella console di Session Manager, tieni presente quanto segue:
Devi concedere agli utenti le autorizzazioni `ssm:GetDocument` e `ssm:ListDocuments` nella loro policy IAM. Per ulteriori informazioni, consulta [Concedere l'accesso ai documenti di sessione personalizzati nella console](getting-started-restrict-access-examples.md#grant-access-documents-console-example).
La console supporta solo i documenti di sessione il cui `sessionType` è definito come `Standard_Stream`. Per ulteriori informazioni, consulta [Schema documento di sessione](session-manager-schema.md).
## Avvio di una sessione (console Amazon EC2 )
È possibile utilizzare la console Amazon Elastic Compute Cloud (Amazon EC2) per avviare una sessione con un'istanza nel tuo account.
**Nota**
Se ricevi un errore che indica che non sei autorizzato a eseguire una o più operazioni Systems Manager (`ssm:command-name`), devi contattare il tuo amministratore per ricevere assistenza. L’amministratore è colui che ti ha fornito le credenziali di accesso. Chiedere a tale persona di aggiornare le policy per consentire l'avvio delle sessioni dalla console Amazon EC2. Se sei un amministratore, consulta [Policy IAM di esempio per Session Manager](getting-started-restrict-access-quickstart.md) per ulteriori informazioni.
**Avvio di una sessione (console Amazon EC2)**
1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Nel riquadro di navigazione, scegliere **Instances (Istanze)**.
1. Selezionare l’istanza, quindi scegliere **Collegarsi**.
1. Per **Connection Method (Metodo di connessione)**, scegliere **Session Manager**.
1. Scegli **Connetti**.
Una volta creata la connessione, è possibile eseguire i comandi bash (Linux e macOS) o i comandi PowerShell (Windows) come per qualsiasi altro tipo di connessione.
## Avvio di una sessione (AWS CLI)
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).
Prima di avviare una sessione, assicurati di aver completato la procedura di configurazione per Session Manager. Per informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
Per utilizzare i comandi AWS CLI to run session, il Session Manager plugin deve essere installato anche sul computer locale. Per informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
Per avviare una sessione utilizzando il AWS CLI, esegui il comando seguente sostituendolo *instance-id* con le tue informazioni.
```
aws ssm start-session \
--target instance-id
```
Per informazioni sulle altre opzioni utilizzabili con il **start-session** comando, [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)consultate la AWS Systems Manager sezione del AWS CLI Command Reference.
## Avvio di una sessione (SSH)
Per avviare una sessione SSH Session Manager, la versione 2.3.672.0 o successiva di SSM Agent deve essere installata sul nodo gestito.
**Requisiti di connessione SSH**
Prendi nota dei seguenti requisiti e limitazioni per le connessioni di sessione che utilizzano SSH tramiteSession Manager:
+ Il tuo nodo gestito di destinazione deve essere configurato per supportare le connessioni SSH. Per ulteriori informazioni, consulta [(Facoltativo) Abilitare e controllare le autorizzazioni per le connessioni SSH tramite Session Manager](session-manager-getting-started-enable-ssh-connections.md).
+ È necessario connettere l'utente sull'account del nodo gestito associato al certificato PEM (Privacy Enhanced Mail), non l'account `ssm-user` utilizzato per altri tipi di connessioni di sessione. Ad esempio, nelle istanze EC2 per Linux e macOS, l'utente predefinito è `ec2-user`. Per informazioni sull'identificazione dell'utente di default per ogni tipo di istanza, consulta [Ottenere informazioni sull'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connection-prereqs.html#connection-prereqs-get-info-about-instance) nella *Guida per l'utente di Amazon EC2*.
+ La registrazione non è disponibile per sessioni Session Manager che si connettono tramite inoltro porta o SSH. Questo perché SSH crittografa tutti i dati della sessione all'interno della connessione TLS sicura stabilita tra gli Session Manager endpoint AWS CLI e funge Session Manager solo da tunnel per le connessioni SSH.
**Nota**
Prima di avviare una sessione, assicurati di aver completato la procedura di configurazione per Session Manager. Per informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
Per avviare una sessione tramite SSH, esegui il comando riportato di seguito. Sostituisci ogni *example resource placeholder* con le tue informazioni.
```
ssh -i /path/my-key-pair.pem username@instance-id
```
**Suggerimento**
Quando avvii una sessione tramite SSH, è possibile copiare i file locali nel nodo gestito di destinazione usando il formato di comando seguente.
```
scp -i /path/my-key-pair.pem /path/ExampleFile.txt username@instance-id:~
```
Per informazioni sulle altre opzioni che è possibile utilizzare con il **start-session** comando, vedere la AWS Systems Manager sezione del Command [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)Reference. AWS CLI
## Avvio di una sessione (inoltro alla porta)
Per avviare una sessione di inoltro porta Session Manager, la versione 2.3.672.0 o successiva di SSM Agent deve essere installata sul nodo gestito.
**Nota**
Prima di avviare una sessione, assicurati di aver completato la procedura di configurazione per Session Manager. Per informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
Per utilizzare i comandi AWS CLI per eseguire la sessione, è necessario installare il Session Manager plug-in sul computer locale. Per informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
A seconda del sistema operativo e dello strumento da riga di comando, il posizionamento delle virgolette può variare e potrebbero essere necessari caratteri di escape.
Per avviare una sessione di inoltro alla porta, esegui il comando seguente dalla CLI: Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name AWS-StartPortForwardingSession ^
--parameters portNumber="3389",localPortNumber="56789"
```
------
`portNumber` rappresenta la porta remota sul nodo gestito a cui desideri reindirizzare il traffico della sessione. Ad esempio, è possibile specificare la porta `3389` per connetterti a un nodo Windows utilizzando il protocollo RDP (Remote Desktop Protocol). Se non specifichi il parametro `portNumber`, Session Manager utilizza `80` come valore predefinito.
`localPortNumber` è la porta del computer locale da cui inizia il traffico, ad esempio `56789`. Questo valore è ciò che immetti quando ti connetti a un nodo gestito utilizzando un client. Ad esempio, **localhost:56789**.
Per informazioni sulle altre opzioni utilizzabili con il **start-session** comando, [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)consultate la AWS Systems Manager sezione del AWS CLI Command Reference.
Per ulteriori informazioni sulle sessioni di inoltro delle porte, consulta [Inoltro della porta tramite AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/) nel *Blog di notizie AWS *.
## Avvio di una sessione (inoltro alla porta a un host remoto)
Per avviare una sessione di inoltro alla porta Session Manager a un host remoto, sul nodo gestito deve essere installata la versione 3.1.1374.0 o successiva di SSM Agent. Non è necessario che l'host remoto sia gestito da Systems Manager.
**Nota**
Prima di avviare una sessione, assicurati di aver completato la procedura di configurazione per Session Manager. Per informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
Per utilizzare i comandi AWS CLI per eseguire la sessione, è necessario installare il Session Manager plug-in sul computer locale. Per informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
A seconda del sistema operativo e dello strumento da riga di comando, il posizionamento delle virgolette può variare e potrebbero essere necessari caratteri di escape.
Per avviare una sessione di inoltro alla porta, esegui il comando seguente dalla AWS CLI: Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["mydb.example.us-east-2.rds.amazonaws.com"],"portNumber":["3306"], "localPortNumber":["3306"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name AWS-StartPortForwardingSessionToRemoteHost ^
--parameters host="mydb.example.us-east-2.rds.amazonaws.com",portNumber="3306",localPortNumber="3306"
```
------
Il valore `host` rappresenta il nome host o l'indirizzo IP dell'host remoto a cui vuoi connetterti. I requisiti generali di connettività e risoluzione dei nomi tra il nodo gestito e l'host remoto continuano a essere validi.
`portNumber` rappresenta la porta remota sul nodo gestito a cui desideri reindirizzare il traffico della sessione. Ad esempio, è possibile specificare la porta `3389` per connetterti a un nodo Windows utilizzando il protocollo RDP (Remote Desktop Protocol). Se non specifichi il parametro `portNumber`, Session Manager utilizza `80` come valore predefinito.
`localPortNumber` è la porta del computer locale da cui inizia il traffico, ad esempio `56789`. Questo valore è ciò che immetti quando ti connetti a un nodo gestito utilizzando un client. Ad esempio, **localhost:56789**.
Per informazioni sulle altre opzioni utilizzabili con il **start-session** comando, [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)consultate la AWS Systems Manager sezione del AWS CLI Command Reference.
### Avvio di una sessione con un'attività Amazon ECS
Session Manager supporta l'avvio di una sessione di inoltro della porta con un'attività all'interno di un cluster Amazon Elastic Container Service (Amazon ECS). Per farlo, abilita ECS Exec. Per ulteriori informazioni, consulta [Monitoraggio dei container del servizio Amazon Elastic Container con ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) nella *Guida per gli sviluppatori del servizio Amazon Elastic Container*.
A tale scopo, è necessario aggiornare il ruolo dell'attività in IAM per includere le seguenti autorizzazioni:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
```
------
Per avviare una sessione di inoltro alla porta con un'attività Amazon ECS, esegui il comando seguente dalla AWS CLI. Sostituisci ogni *example resource placeholder* con le tue informazioni.
**Nota**
Rimuovi i simboli < e > dal parametro `target`. Questi simboli vengono forniti solo a scopo di chiarimento per il lettore.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target ecs:__ \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["URL"],"portNumber":["port_number"], "localPortNumber":["port_number"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target ecs:__ ^
--document-name AWS-StartPortForwardingSessionToRemoteHost ^
--parameters host="URL",portNumber="port_number",localPortNumber="port_number"
```
------
## Avvio di una sessione (comandi interattivi e non interattivi)
Prima di avviare una sessione, assicurati di aver completato la procedura di configurazione per Session Manager. Per informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
Per utilizzare i comandi AWS CLI per eseguire la sessione, il Session Manager plug-in deve essere installato anche sul computer locale. Per informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
Per avviare una sessione di comando interattivo, esegui il comando seguente: Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name CustomCommandSessionDocument \
--parameters '{"logpath":["/var/log/amazon/ssm/amazon-ssm-agent.log"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name CustomCommandSessionDocument ^
--parameters logpath="/var/log/amazon/ssm/amazon-ssm-agent.log"
```
------
Per informazioni sulle altre opzioni utilizzabili con il **start-session** comando, [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)consultate la AWS Systems Manager sezione del AWS CLI Command Reference.
**Ulteriori informazioni**
+ [Usa l'inoltro della porta in AWS Systems Manager Session Manager per connetterti a host remoti](https://aws.amazon.com/blogs/mt/use-port-forwarding-in-aws-systems-manager-session-manager-to-connect-to-remote-hosts/)
+ [Inoltro delle porte delle istanze Amazon EC2 con AWS Systems Manager](https://aws.amazon.com/blogs/mt/amazon-ec2-instance-port-forwarding-with-aws-systems-manager/)
+ [Gestisci le risorse Microsoft AD AWS gestite con il Session Manager port forwarding](https://aws.amazon.com/blogs/mt/manage-aws-managed-microsoft-ad-resources-with-session-manager-port-forwarding/)
+ [Inoltro porta utilizzando AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/) sul *Blog di notizie AWS *.
# Terminare una sessione
È possibile terminare una sessione iniziata nel proprio account utilizzando la console AWS Systems Manager o la AWS Command Line Interface (AWS CLI). [Se si fa clic sul pulsante **Termina** per una sessione nella console o si richiama l'azione API TerminateSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TerminateSession.html) utilizzando la AWS CLI, Session Manager termina definitivamente la sessione e chiude la connessione dati tra il client di Session Manager e l'SSM Agent sul nodo gestito. Non è possibile riprendere una sessione terminata.
Se non vi è alcuna attività utente in una sessione aperta per 20 minuti, lo stato di inattività attiva un timeout. non richiama TerminateSession, ma chiude il canale sottostante. Non è possibile riprendere una sessione chiusa a causa di un timeout di inattività.
Si consiglia sempre di terminare una sessione in modo esplicito utilizzando il `terminate-session` comando, quando si utilizza ilAWS CLI, o il pulsante **Termina** quando si utilizza la console. (I pulsanti **Termina** si trovano sia nella finestra della sessione che nella pagina principale Session Manager della console). Se chiudi solo un browser o una finestra di comando, la sessione rimane elencata come **Attiva** nella console per 30 giorni. Quando non si termina esplicitamente una sessione o quando una sessione scade, tutti i processi in esecuzione sul nodo gestito in quel momento continueranno a essere eseguiti.
**Topics**
+ [
## Per terminare una sessione (console)
](#stop-sys-console)
+ [
## Terminare una sessione (AWS CLI)
](#stop-cli)
## Per terminare una sessione (console)
È possibile utilizzare la console AWS Systems Manager per terminare una sessione nel tuo account.
**Per terminare una sessione (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 **Session Manager**.
1. Per **Sessions (Sessioni)**, scegliere il pulsante di opzione a sinistra della sessione da terminare.
1. Scegliere **Terminate (Termina)**.
## Terminare una sessione (AWS CLI)
Per terminare una sessione tramite AWS CLI, esegui il comando riportato di seguito. Sostituisci *session-id* con le tue informazioni.
```
aws ssm terminate-session \
--session-id session-id
```
Per ulteriori informazioni sul comando **terminate-session**, vedi [https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html) nella sezione AWS Systems Manager della Guida di riferimento ai comandi di AWS CLI.
# Visualizzazione della cronologia delle sessioni
È possibile utilizzare la AWS Systems Manager console o il AWS Command Line Interface (AWS CLI) per visualizzare le informazioni sulle sessioni nel proprio account. Nella console, puoi visualizzare i dettagli della sessione come i seguenti:
+ L'ID della sessione
+ Quale utente si è connesso a un nodo gestito attraverso una sessione
+ L'ID del nodo gestito
+ Quando è iniziata e terminata la sessione
+ Lo stato della sessione
+ Il percorso specificato per l'archiviazione dei log delle sessioni (se abilitata)
Utilizzando AWS CLI, puoi visualizzare un elenco di sessioni nel tuo account, ma non i dettagli aggiuntivi disponibili nella console.
Per informazioni sul controllo e delle informazioni relative alla cronologia della sessione, consulta [Abilitazione e disabilitazione della registrazione di sessione](session-manager-logging.md).
**Topics**
+ [
## Visualizzazione della cronologia delle sessioni (console)
](#view-console)
+ [
## Visualizzazione della cronologia delle sessioni (AWS CLI)
](#view-history-cli)
## Visualizzazione della cronologia delle sessioni (console)
Puoi utilizzare la AWS Systems Manager console per visualizzare i dettagli sulle sessioni del tuo account.
**Visualizzazione della cronologia delle sessioni (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 **Session Manager**.
1. Scegli la scheda **Cronologia delle sessioni**.
oppure
Se la home page si apre per prima Session Manager, scegli **Configura preferenze**, quindi scegli la scheda **Cronologia delle sessioni**.
## Visualizzazione della cronologia delle sessioni (AWS CLI)
Per visualizzare un elenco di sessioni nel tuo account utilizzando il AWS CLI, esegui il comando seguente.
```
aws ssm describe-sessions \
--state History
```
**Nota**
Questo comando restituisce solo i risultati per le connessioni alle destinazioni avviate utilizzando Session Manager. Non elenca le connessioni effettuate tramite altri mezzi, ad esempio Remote Desktop Protocol (RDP) o Secure Shell Protocol (SSH).
Per informazioni sulle altre opzioni che è possibile utilizzare con il **describe-sessions** comando, vedere [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html)la AWS Systems Manager sezione della Guida ai AWS CLI comandi.
# Attività di registrazione delle sessioni
Oltre a fornire informazioni sulle sessioni correnti e completate nella console Systems Manager, Session Manager fornisce le opzioni per la verifica e la registrazione dell'attività delle sessioni nell' Account AWS tramite AWS CloudTrail.
CloudTrail acquisisce le chiamate API di sessione tramite la console Systems Manager, AWS Command Line Interface (AWS CLI) e Systems Manager SDK. Puoi visualizzare le informazioni sulla CloudTrail console o archiviarle in un bucket Amazon Simple Storage Service (Amazon S3) specificato. Un bucket Amazon S3 viene utilizzato per tutti i CloudTrail log del tuo account. Per ulteriori informazioni, consulta [Registrazione delle chiamate AWS Systems Manager API con AWS CloudTrail](monitoring-cloudtrail-logs.md).
**Nota**
[Per un'analisi ricorrente, storica e analitica dei tuoi file di registro, prendi in considerazione la possibilità di interrogare i CloudTrail log utilizzando CloudTrail Lake o una tabella gestita da te.](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) *Per ulteriori informazioni, consulta [Interrogare i AWS CloudTrail log](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html) nella Guida per l'utente.AWS CloudTrail *
## Monitoraggio dell'attività della sessione tramite Amazon EventBridge (console)
Con EventBridge, puoi configurare regole per rilevare quando avvengono modifiche alle AWS risorse. È possibile creare una regola per rilevare quando un utente della tua organizzazione avvia o termina una sessione e quindi, ad esempio, ricevere una notifica sull'evento tramite Amazon SNS.
EventBridge il supporto per Session Manager si basa sui record delle operazioni API che sono stati registrati da CloudTrail. (È possibile utilizzare l' CloudTrail integrazione con EventBridge per rispondere alla maggior parte AWS Systems Manager degli eventi.) Le azioni eseguite all'interno di una sessione, ad esempio un `exit` comando, che non effettuano una chiamata API non vengono rilevate da EventBridge.
La procedura seguente illustra come avviare le notifiche tramite Amazon Simple Notification Service (Amazon SNS) quando si verifica un evento API Session Manager, ad esempio **StartSession**.
**Per monitorare l'attività della sessione utilizzando Amazon EventBridge (console)**
1. Creare un argomento Amazon SNS da utilizzare per l'invio di notifiche quando si verifica l'evento del Session Manager che si desidera monitorare.
Per ulteriori informazioni, consulta la pagina [Creazione di un argomento](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html) nella *Guida per gli sviluppatori di Amazon Simple Notification Service*.
1. Crea una EventBridge regola per richiamare il target Amazon SNS per il tipo Session Manager di evento che desideri monitorare.
Per informazioni su come creare la regola, consulta la sezione [Creazione di EventBridge regole Amazon che reagiscono agli eventi](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) nella *Amazon EventBridge User Guide*.
Durante la procedura per la creazione della regola, effettuare le selezioni seguenti:
+ Per **AWS **, scegli **Systems Manager**.
+ Per il **tipo di evento**, scegli **AWS API Call through CloudTrail**.
+ Scegli **Operazioni specifiche**, quindi immetti i comandi del Session Manager (uno alla volta) per cui si desidera ricevere le notifiche. Puoi scegliere **StartSession****ResumeSession**, e**TerminateSession**. (EventBridge non supporta `Get*` ` List*` i `Describe*` comandi e.)
+ Per **Seleziona una destinazione**, scegli **Argomento SNS**. Per **Argomento**, scegli il nome dell'argomento Amazon SNS creato nella Fase 1.
Per ulteriori informazioni, consulta la *[Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/)* e la *[Amazon Simple Notification Service Getting Started Guide](https://docs.aws.amazon.com/sns/latest/gsg/)*.
# Abilitazione e disabilitazione della registrazione di sessione
La registrazione di sessione registra le informazioni sulle sessioni correnti e completate nella console di Systems Manager. È inoltre possibile registrare nell' Account AWS i dettagli sui comandi eseguiti durante le sessioni. Registrare le sessione consente di:
+ Creare e memorizzare i log delle sessioni a scopo di archiviazione.
+ Generare un report che mostra i dettagli di ogni connessione effettuata ai tuoi nodi gestiti tramite il Session Manager negli ultimi 30 giorni.
+ Genera notifiche per la registrazione della sessione nelle tue notifiche Account AWS, come quelle di Amazon Simple Notification Service (Amazon SNS).
+ Avvia automaticamente un'altra azione su una AWS risorsa come risultato di azioni eseguite durante una sessione, come l'esecuzione di una AWS Lambda funzione, l'avvio di una AWS CodePipeline pipeline o l'esecuzione di un documento. AWS Systems Manager Run Command
**Importante**
Tieni presenti i seguenti requisiti e limitazioni su Session Manager:
Session Manager registra i comandi immessi e il loro output durante una sessione a seconda delle preferenze di sessione. Per evitare che i dati sensibili, ad esempio le password, vengano visualizzati nei registri di sessione, è consigliabile utilizzare i seguenti comandi quando si immettono dati sensibili durante una sessione.
```
stty -echo; read passwd; stty echo;
```
```
$Passwd = Read-Host -AsSecureString
```
Se utilizzi Windows Server 2012 o versione precedente, i dati nei log potrebbero non essere formattati in modo ottimale. Ti consigliamo di usare Windows Server 2012 R2 o versione successiva per ottimizzare il formato dei log.
Se utilizzi i nodi gestiti Linux o macOS, assicurati che sia installata l'utilità schermo. In caso contrario, i dati di registro potrebbero essere troncati. Su Amazon Linux AL2 2.023 eUbuntu Server, l'utilità screen è installata per impostazione predefinita. Per installare lo schermo manualmente, a seconda della versione di Linux, esegui `sudo yum install screen` o `sudo apt-get install screen`.
La registrazione non è disponibile per sessioni Session Manager che si connettono tramite port forwarding o SSH. Questo perché SSH crittografa tutti i dati della sessione all'interno della connessione TLS sicura stabilita tra gli Session Manager endpoint AWS CLI e gli endpoint e funge Session Manager solo da tunnel per le connessioni SSH.
Per ulteriori informazioni sulle autorizzazioni necessarie per utilizzare Amazon S3 o CloudWatch Amazon Logs per la registrazione dei dati della sessione, consulta. [Creazione di un ruolo IAM con autorizzazioni per Amazon S3 Session Manager CloudWatch e Logs (console)](getting-started-create-iam-instance-profile.md#create-iam-instance-profile-ssn-logging)
Per ulteriori informazioni sulle opzioni di controllo e registrazione per il Session Manager, consulta i seguenti argomenti.
**Topics**
+ [
# Streaming dei dati delle sessioni tramite Amazon CloudWatch Logs (console)
](session-manager-logging-cwl-streaming.md)
+ [
# Registrazione dei dati delle sessioni mediante Amazon S3 (console)
](session-manager-logging-s3.md)
+ [
# Registrazione dei dati della sessione tramite Amazon CloudWatch Logs (console)
](session-manager-logging-cloudwatch-logs.md)
+ [
# Configurazione della registrazione di sessione su disco
](session-manager-logging-disk.md)
+ [
# Impostazione della durata di archiviazione del log temporaneo di Session Manager su disco
](session-manager-logging-disk-retention.md)
+ [
# Disabilitazione della Session Manager registrazione in CloudWatch Logs e Amazon S3
](session-manager-enable-and-disable-logging.md)
# Streaming dei dati delle sessioni tramite Amazon CloudWatch Logs (console)
Puoi inviare un flusso continuo di log dei dati di sessione ad Amazon CloudWatch Logs. I dettagli essenziali, come i comandi che un utente ha eseguito in una sessione, l'ID dell'utente che ha eseguito i comandi e i timestamp di quando i dati della sessione vengono trasmessi in streaming a CloudWatch Logs, vengono inclusi durante lo streaming dei dati della sessione. Durante lo streaming dei dati di sessione, i log sono formattati in JSON per consentire l'integrazione con le soluzioni di registrazione esistenti. I dati della sessione di streaming non sono supportati per i comandi interattivi.
**Nota**
Per trasmettere i dati di sessione da nodi gestiti Windows Server, è necessario disporre di PowerShell 5.1 o versione successiva installata. Per impostazione predefinita, Windows Server 2016 e versioni successive hanno installato la versione di PowerShell richiesta. Tuttavia, Windows Server 2012 e 2012 R2 non hanno la versione di PowerShell richiesta installata per impostazione predefinita. Se PowerShell non è stato ancora aggiornato nei nodi gestiti Windows Server 2012 o 2012 R2, è possibile farlo utilizzando Run Command. Per informazioni sull'aggiornamento di PowerShell utilizzando Run Command, consulta [Aggiornamento tramite PowerShell Run Command](run-command-tutorial-update-software.md#rc-console-pwshexample).
**Importante**
Se hai configurato l'impostazione dei criteri di **PowerShell trascrizione** sui nodi Windows Server gestiti, non sarai in grado di trasmettere in streaming i dati della sessione.
**Per trasmettere i dati della sessione utilizzando Amazon CloudWatch Logs (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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Seleziona la casella di controllo accanto a **Abilita** nella sezione **CloudWatch Registrazione.**
1. Seleziona l'opzione **Log delle sessioni di streaming**.
1. (Consigliato) Seleziona la casella di controllo accanto a **Consenti solo gruppi di CloudWatch log crittografati**. Se questa opzione è attivata, i dati di log vengono crittografati utilizzando la chiave di crittografia lato server specificata per il gruppo di log. Se non desideri crittografare i dati di registro inviati ai CloudWatch registri, deseleziona la casella di controllo. È inoltre necessario deselezionare la casella di controllo se la crittografia non è abilitata nel gruppo di log.
1. Per **CloudWatch i log**, per specificare il gruppo di log CloudWatch Logs esistente nel gruppo in cui Account AWS caricare i log delle sessioni, seleziona una delle seguenti opzioni:
+ Immetti il nome di un gruppo di log nella casella di testo che è già stato creato nell'account per archiviare i dati di log della sessione.
+ **Esplora gruppi di log**: seleziona un gruppo di log che è già stato creato nel tuo account per archiviare i dati di log della sessione.
1. Scegli **Save** (Salva).
# Registrazione dei dati delle sessioni mediante Amazon S3 (console)
Puoi scegliere di archiviare i dati di log delle sessioni in un bucket Amazon Simple Storage Service (Amazon S3) di tua scelta a scopi di debug e risoluzione dei problemi. L'opzione predefinita comporta l'invio dei log a un bucket Amazon S3 crittografato. La crittografia viene eseguita utilizzando la chiave specificata per il bucket, una AWS KMS key chiave Amazon S3 Server-Side Encryption (SSE) (AES-256).
**Importante**
Quando si utilizzano bucket in stile hosting virtuale con Secure Sockets Layer (SSL), il certificato jolly SSL confronta solo i bucket che non contengono punti. Per risolvere questo problema, utilizzare HTTP o scrivere una logica di verifica del certificato personalizzata. Consigliamo di non utilizzare punti (".") nei nomi dei bucket quando si utilizzano bucket in stile hosting virtuale.
**Crittografia bucket Amazon S3**
Per inviare i log al tuo bucket Amazon S3 con la crittografia, nel bucket deve essere abilitata la crittografia. Per ulteriori informazioni sulla crittografia del bucket Amazon S3, consulta [Crittografia di default di Amazon S3 per bucket S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html).
**Chiave gestita dal cliente**
Se utilizzi una chiave KMS da te gestita per crittografare il tuo bucket, il profilo dell'istanza IAM collegato alle tue istanze deve disporre di autorizzazioni esplicite per leggere la chiave. Se utilizzi una Chiave gestita da AWS, l'istanza non richiede questa autorizzazione esplicita. Per ulteriori informazioni su come fornire al profilo dell'istanza l'accesso a utilizzare la chiave, consulta [Consenti agli utenti della chiave di utilizzare la chiave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) nella *Guida per sviluppatori AWS Key Management Service *.
Segui questa procedura per configurare il Session Manager per archiviare i registri delle sessioni in un bucket Amazon S3.
**Nota**
Puoi anche utilizzare il AWS CLI per specificare o modificare il bucket Amazon S3 a cui vengono inviati i dati della sessione. Per informazioni, consulta [Aggiornamento delle preferenze Session Manager (riga di comando)](getting-started-configure-preferences-cli.md).
**Per registrare i dati delle sessioni mediante Amazon S3 (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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Seleziona la casella di controllo accanto ad **Abilitazione** sotto **Registrazione S3**.
1. (Opzione consigliata) Selezionare la casella di controllo accanto a **Consenti solo bucket S3 crittografati**. Se questa opzione è attivata, i dati di log vengono crittografati utilizzando la chiave di crittografia lato server specificata per il bucket. Se non si desidera crittografare i dati di log inviati a Amazon S3, deselezionare la casella di controllo. Se la crittografia non è abilitata nel bucket S3, è necessario anche deselezionare la casella di controllo.
1. Per **Nome bucket S3**, seleziona una delle opzioni seguenti:
**Nota**
Consigliamo di non utilizzare punti (".") nei nomi dei bucket quando si utilizzano bucket in stile hosting virtuale. Per ulteriori informazioni su come formattare i nomi dei bucket Amazon S3, consulta [Restrizioni e limitazioni dei bucket](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules) nella *Guida per gli utenti di Amazon Simple Storage Service*.
+ **Scegli un bucket nell'elenco**: seleziona un bucket Amazon S3 che è già stato creato nel proprio account per archiviare i dati di log delle sessioni.
+ **Immetti un nome di bucket nella casella di testo**: immetti il nome del bucket Amazon S3 che è già stato creato nell'account per archiviare i dati di log delle sessioni.
1. (Facoltativo) Per **Prefisso della chiave S3**, immetti il nome di una cartella nuova o esistente per archiviare i log nel bucket selezionato.
1. Scegli **Salva**.
Per ulteriori informazioni su Simple Storage Service (Amazon S3) e i bucket Amazon S3, consulta *[Guida per l'utente di Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)* e *[Guida per l'utente di Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)*.
# Registrazione dei dati della sessione tramite Amazon CloudWatch Logs (console)
Con Amazon CloudWatch Logs, puoi monitorare, archiviare e accedere a file di registro da diversi Servizi AWS file. Puoi inviare i dati dei log di sessione a un gruppo di log CloudWatch Logs per scopi di debug e risoluzione dei problemi. L'opzione predefinita comporta l'invio dei dati di log con la crittografia utilizzando la chiave KMS, ma puoi trasmettere i dati al gruppo di log con o senza crittografia.
Segui questi passaggi per configurare AWS Systems Manager Session Manager l'invio dei dati del registro di sessione a un gruppo di log di CloudWatch Logs al termine delle sessioni.
**Nota**
È inoltre possibile utilizzare il AWS CLI per specificare o modificare il gruppo di log CloudWatch Logs a cui vengono inviati i dati della sessione. Per informazioni, consulta [Aggiornamento delle preferenze Session Manager (riga di comando)](getting-started-configure-preferences-cli.md).
**Per registrare i dati della sessione utilizzando Amazon CloudWatch Logs (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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Seleziona la casella di controllo accanto a **Abilita** nella sezione **CloudWatch Registrazione.**
1. Seleziona l'opzione **Carica log della sessione**.
1. (Consigliato) Seleziona la casella di controllo accanto a **Consenti solo gruppi di CloudWatch log crittografati**. Se questa opzione è attivata, i dati di log vengono crittografati utilizzando la chiave di crittografia lato server specificata per il gruppo di log. Se non desideri crittografare i dati di registro inviati ai CloudWatch registri, deseleziona la casella di controllo. È inoltre necessario deselezionare la casella di controllo se la crittografia non è abilitata nel gruppo di log.
1. Per **CloudWatch i log**, per specificare il gruppo di log CloudWatch Logs esistente nel gruppo in cui Account AWS caricare i log delle sessioni, seleziona una delle seguenti opzioni:
+ **Scegli un gruppo di log nell'elenco**: seleziona un gruppo di log che è già stato creato nel tuo account per archiviare i dati di log della sessione.
+ **Immetti un nome di bucket nella casella di testo**: immetti il nome di un gruppo di log che è già stato creato nell'account per archiviare i dati di log della sessione.
1. Scegli **Save** (Salva).
Per ulteriori informazioni sull'utilizzo dei CloudWatch log, consulta la *[Amazon CloudWatch Logs User](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)* Guide.
# Configurazione della registrazione di sessione su disco
Dopo aver abilitato Session Manager la registrazione su Amazon S3, tutti i comandi eseguiti durante una sessione (e l'output risultante da tali comandi) vengono registrati in un file temporaneo sul disco dell'istanza di destinazione. CloudWatch Il file temporaneo è denominato `ipcTempFile.log`.
`ipcTempFile.log` è controllato dal parametro `SessionLogsDestination` nel file di configurazione dell'SSM Agent. Questo parametro accetta i seguenti valori:
+ **disco***: se specifichi questo parametro e la registrazione della sessione su Amazon S3 è abilitataSSM Agent, crea `ipcTempFile.log` il file di registro temporaneo e registra i comandi e l'output della sessione su disco. CloudWatch * Session Managercarica questo registro su S3 o durante CloudWatch o dopo la sessione, a seconda della configurazione di registrazione. Il log viene quindi eliminato in base alla durata specificata per il parametro di configurazione `SessionLogsRetentionDurationHours` di SSM Agent.
*Se specifichi questo parametro e la registrazione della sessione su Amazon S3 è disabilitataSSM Agent, registra comunque la cronologia dei comandi e l'output nel file. CloudWatch * `ipcTempFile.log` Il file verrà eliminato in base alla durata specificata per il parametro di configurazione `SessionLogsRetentionDurationHours` di SSM Agent.
+ **none***: se specifichi questo parametro e la registrazione della sessione su Amazon S3 è abilitata, la registrazione su disco funziona esattamente come se avessi specificato il parametro. CloudWatch * `disk` SSM Agentrichiede il file temporaneo quando la registrazione della sessione su Amazon S3 CloudWatch o Amazon S3 è abilitata.
*Se specifichi questo parametro e la registrazione della sessione su Amazon S3 è disabilitataSSM Agent, non crea `ipcTempFile.log` il file. CloudWatch *
Utilizza la seguente procedura per abilitare o disabilitare la creazione del file di log `ipcTempFile.log` temporaneo su disco all'avvio di una sessione.
**Per abilitare o disabilitare la creazione del file di log temporaneo di Session Manager su disco**
1. Installa l'SSM Agent sull'istanza o esegui l'aggiornamento alla versione 3.2.2086 o successiva. Per informazioni su come verificare il numero della versione dell'agente, consulta [Verifica del numero di versione di SSM Agent](ssm-agent-get-version.md). Per informazioni su come installare manualmente l'agente, individua la procedura per il sistema operativo nelle seguenti sezioni:
+ [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Linux](manually-install-ssm-agent-linux.md)
+ [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per macOS](manually-install-ssm-agent-macos.md)
+ [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Windows Server](manually-install-ssm-agent-windows.md)
1. Connettiti all'istanza e individua il file `amazon-ssm-agent.json` nella seguente posizione.
+ **Linux:/**/etc/amazon/ssm
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
Se il file `amazon-ssm-agent.json` non esiste, copia i contenuti di `amazon-ssm-agent.json.template` in un nuovo file nella stessa directory. Assegna un nome al nuovo file `amazon-ssm-agent.json`.
1. Specifica tra `none` or `disk` per il parametro `SessionLogsDestination`. Salvare le modifiche.
1. [Riavviare](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html) SSM Agent.
Se si specifica `disk` per il parametro `SessionLogsDestination`, è possibile verificare che l'SSM Agent crei il file di log temporaneo avviando una nuova sessione, per poi posizionare `ipcTempFile.log` nella seguente posizione:
+ **Linux**://var/lib/amazon/ssm*target ID*/sessione/orchestrazione/ /Standard\$1Stream/ *session ID* .log ipcTempFile
+ **macOS**: opt/aws/ssm/data*target ID*/*session ID*/sessione/orchestrazione/ ipcTempFile /Standard\$1Stream/ .log
+ **Windows Server**: C:\$1\$1 AmazonProgramData\$1 SSM\$1\$1\$1 sessioneInstanceData\$1 orchestrazione*target ID*\$1\$1 Standard\$1Stream*session ID*\$1 .log ipcTempFile
**Nota**
Per impostazione predefinita, il file di log temporaneo viene salvato sull'istanza per 14 giorni.
Per aggiornare il parametro `SessionLogsDestination` su più istanze, è consigliato creare un documento SSM che specifichi la nuova configurazione. È quindi possibile utilizzare Systems Manager Run Command per implementare la modifica sulle istanze. Per ulteriori informazioni, consulta [Scrivere i propri](https://aws.amazon.com/blogs/mt/writing-your-own-aws-systems-manager-documents/) documenti (blog) e. AWS Systems Manager [Esecuzione di comandi su nodi gestiti](running-commands.md)
# Impostazione della durata di archiviazione del log temporaneo di Session Manager su disco
Dopo aver abilitato Session Manager la registrazione su Amazon S3, tutti i comandi eseguiti durante una sessione (e l'output risultante da tali comandi) vengono registrati in un file temporaneo sul disco dell'istanza di destinazione. CloudWatch Il file temporaneo è denominato `ipcTempFile.log`. Durante una sessione o dopo il suo completamento, Session Manager carica questo registro temporaneo su uno o su S3. CloudWatch Il log temporaneo viene quindi eliminato in base alla durata specificata per il parametro di configurazione SSM Agent `SessionLogsRetentionDurationHours`. Per impostazione predefinita, il file di log temporaneo viene salvato sull'istanza per 14 giorni nella seguente posizione:
+ **Linux**://sessione/orchestrazione/ var/lib/amazon/ssm /Standard\$1Stream/ *target ID* .log *session ID* ipcTempFile
+ **macOS**: opt/aws/ssm/data*target ID*/*session ID*/sessione/orchestrazione/ ipcTempFile /Standard\$1Stream/ .log
+ **Windows Server**: C:\$1\$1 AmazonProgramData\$1 SSM\$1\$1\$1 sessioneInstanceData\$1 orchestrazione*target ID*\$1\$1 Standard\$1Stream*session ID*\$1 .log ipcTempFile
Utilizza la procedura seguente per modificare la durata di archiviazione del file di log temporaneo di Session Manager su disco.
**Per regolare la durata di archiviazione del file `ipcTempFile.log` su disco**
1. Connettiti all'istanza e individua il file `amazon-ssm-agent.json` nella seguente posizione.
+ **etc/amazon/ssmLinux://**
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
Se il file `amazon-ssm-agent.json` non esiste, copia i contenuti di `amazon-ssm-agent.json.template` in un nuovo file nella stessa directory. Assegna un nome al nuovo file `amazon-ssm-agent.json`.
1. Modifica il valore di `SessionLogsRetentionDurationHours` nel numero di ore desiderato. Se `SessionLogsRetentionDurationHours` è impostato su 0, il file di log temporaneo viene creato durante la sessione ed eliminato al termine della stessa. Questa impostazione dovrebbe garantire che il file di log non persista dopo la fine della sessione.
1. Salvare le modifiche.
1. [Riavviare](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html) SSM Agent.
# Disabilitazione della Session Manager registrazione in CloudWatch Logs e Amazon S3
È possibile utilizzare la console Systems Manager o AWS CLI disabilitare la registrazione delle sessioni nel proprio account.
**Per disabilitare la registrazione di sessione (console)**
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 **Session Manager**.
1. Scegli la scheda **Preferenze**, quindi seleziona **Modifica**.
1. Per disabilitare CloudWatch la registrazione, nella sezione **CloudWatch Registrazione**, deseleziona la casella di controllo **Abilita.**
1. Per disabilitare la registrazione di S3, nella sezione **Registrazione di S3**, deseleziona la casella di controllo **Abilita**.
1. Scegli **Save** (Salva).
**Per disabilitare la registrazione di sessione (AWS CLI)**
Per disabilitare la registrazione delle sessioni utilizzando il AWS CLI, segui le istruzioni riportate in. [Aggiornamento delle preferenze Session Manager (riga di comando)](getting-started-configure-preferences-cli.md)
Nel file JSON, assicurati che gli input `s3BucketName` e `cloudWatchLogGroupName` non contengano valori. Esempio:
```
"inputs": {
"s3BucketName": "",
...
"cloudWatchLogGroupName": "",
...
}
```
In alternativa, per disabilitare la registrazione, è possibile rimuovere tutti gli input `S3*` e `cloudWatch*` dal file JSON.
**Nota**
A seconda della configurazione, dopo la disattivazione CloudWatch di S3, è possibile che su disco venga ancora generato un file di registro temporaneo da. SSM Agent Per informazioni su come disabilitare la registrazione su disco, consulta [Configurazione della registrazione di sessione su disco](session-manager-logging-disk.md).
# Schema documento di sessione
Le informazioni seguenti descrivono gli elementi dello schema di un documento di sessione .AWS Systems Manager Session Managerutilizza i documenti di sessione per determinare quale tipo di sessione avviare, ad esempio una sessione standard, una sessione di inoltro alla porta o una sessione per eseguire un comando interattivo.
[schemaVersion](#version)
Versione dello schema del documento di sessione. I documenti delle sessioni supportano solo la versione 1.0.
Tipo: string
Campo obbligatorio: sì
[description](#descript)
Descrizione specificata per il documento di sessione. Ad esempio, «Documento per avviare la sessione di inoltro della porta con Session Manager>>.
Tipo: string
Campo obbligatorio: no
[sessionType](#type)
Il tipo di sessione che il documento di sessione viene utilizzato per stabilire.
Tipo: string
Campo obbligatorio: sì
Valori validi: `InteractiveCommands`\$1 `NonInteractiveCommands`\$1 `Port`\$1 `Standard_Stream`
[inputs](#in)
Preferenze di sessione da utilizzare per le sessioni stabilite utilizzando questo documento di sessione. Questo elemento è necessario per i documenti di sessione utilizzati per creare sessioni `Standard_Stream`.
Tipo: StringMap
Campo obbligatorio: no
[s3BucketName](#bucket)
Il bucket Amazon Simple Storage Service (Amazon S3) a cui desideri inviare i registri delle sessioni al termine delle sessioni.
Tipo: string
Campo obbligatorio: no
[s3KeyPrefix](#prefix)
Il prefisso da utilizzare quando si inviano i registri al bucket Amazon S3 specificato nell'input `s3BucketName`. Per ulteriori informazioni sull'utilizzo di un prefisso condiviso con gli oggetti archiviati in Amazon S3, consulta [Come si utilizzano le cartelle in un bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/using-folders.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
Tipo: string
Campo obbligatorio: no
[s3EncryptionEnabled](#s3Encrypt)
Se impostato su `true`, il bucket Amazon S3 specificato nell'input `s3BucketName` deve essere crittografato.
Tipo: Booleano
Campo obbligatorio: sì
[cloudWatchLogGroupName](#logGroup)
Il nome del gruppo Amazon CloudWatch Logs (CloudWatch Logs) a cui si desidera inviare i registri di sessione al termine delle sessioni.
Tipo: string
Campo obbligatorio: no
[cloudWatchEncryptionEnabled](#cwEncrypt)
Se impostato su `true`, il gruppo di registro specificato nell'input `cloudWatchLogGroupName` deve essere crittografato.
Tipo: Booleano
Campo obbligatorio: sì
[cloudWatchStreamingEnabled](#cwStream)
Se impostato su `true`, un flusso continuo di registri di dati delle sessioni viene inviato al gruppo di registro specificato nell'input `cloudWatchLogGroupName`. Se impostati su`false`, i registri delle sessioni vengono inviati al gruppo di registri specificato nella `cloudWatchLogGroupName` alla fine delle sessioni.
Tipo: Booleano
Campo obbligatorio: sì
[kmsKeyId](#kms)
L'ID del AWS KMS key da utilizzare per crittografare ulteriormente i dati tra i computer client locali e i nodi gestiti Amazon Elastic Compute Cloud (Amazon EC2) a cui ti connetti.
Tipo: string
Campo obbligatorio: no
[runAsEnabled](#run)
Se impostato su `true`, è necessario specificare un account utente esistente nei nodi gestiti a cui ci si connetterà nell'input `runAsDefaultUser`. In caso contrario, le sessioni non verranno avviate. Per impostazione predefinita, le sessioni vengono avviate utilizzando `ssm-user` creato dall'account AWS Systems Manager SSM Agent. La funzionalità Esegui come è supportata solo per la connessione ai nodi gestiti .
Tipo: Booleano
Campo obbligatorio: sì
[runAsDefaultUser](#runUser)
Il nome dell'account utente con cui avviare le sessioni sui nodi gestiti Linux quando l'input macOS è impostato su . L'account utente specificato per questo input deve esistere nei nodi gestiti a cui ci si connetterà; in caso contrario, le sessioni non verranno avviate.
Tipo: string
Campo obbligatorio: no
[idleSessionTimeout](#timeout)
La quantità di tempo di inattività che si desidera consentire prima del termine di una sessione. Questo input viene misurato in minuti.
Tipo: string
Valori validi: 1-60
Campo obbligatorio: no
[maxSessionDuration](#maxDuration)
La quantità di tempo che si desidera permettere prima del termine di una sessione. Questo input viene misurato in minuti.
Tipo: string
Valori validi: 1-1440
Campo obbligatorio: no
[shellProfile](#shell)
Le preferenze specificate per il sistema operativo da applicare alle sessioni quali le preferenze della shell, le variabili di ambiente, le directory di lavoro e l'esecuzione di più comandi all'avvio di una sessione.
Tipo: StringMap
Campo obbligatorio: no
[windows](#win)
Le preferenze della shell, le variabili di ambiente, le directory di lavoro e i comandi specificati per le sessioni sui nodi gestiti Windows Server.
Tipo: string
Campo obbligatorio: no
[linux](#lin)
Le preferenze della shell, le variabili di ambiente, le directory di lavoro e i comandi specificati per le sessioni sui nodi gestiti .
Tipo: string
Campo obbligatorio: no
[parameters](#param)
Una struttura che definisce i parametri accettati dal documento. ì Per ulteriori informazioni su come specificare i parametri del documento, consulta **Parametri di definizione del processo** nella [Elementi di dati di primo livello](documents-syntax-data-elements-parameters.md#top-level). Per i parametri a cui fai spesso riferimento, è consigliabile archiviare questi parametri in Systems Manager Parameter Store e farvi riferimento. Puoi fare riferimento ai parametri `String`, `StringList` e Parameter Store in questa sezione di un documento. Puoi fare riferimento ai parametri Parameter Store `SecureString` in questa sezione di un documento. È possibile fare riferimento a un parametro Parameter Store utilizzando il seguente formato.
```
{{ssm:parameter-name}}
```
Per ulteriori informazioni su Parameter Store, consulta [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md).
Tipo: StringMap
Campo obbligatorio: no
[properties](#props)
Un oggetto i cui valori specificati vengono utilizzati nell' operazione API `StartSession`.
Per i documenti di sessione utilizzati per sessioni `InteractiveCommands`, l'oggetto proprietà include i comandi da eseguire nei sistemi operativi specificati. Puoi inoltre determinare se i comandi vengono eseguiti come `root` utilizzando la proprietà booleana `runAsElevated`. Per ulteriori informazioni consulta [Limitare l'accesso ai comandi in una sessione](session-manager-restrict-command-access.md).
Per i documenti di sessione utilizzati per sessioni `Port`, l'oggetto proprietà contiene il numero di porta verso cui deve essere reindirizzato il traffico. Per un esempio, consulta il documento di Sessione tipo `Port` più avanti in questo argomento.
Tipo: StringMap
Campo obbligatorio: no
Esempio di documento di sessione tipo `Standard_Stream`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to hold regional settings for Session Manager
sessionType: Standard_Stream
inputs:
s3BucketName: ''
s3KeyPrefix: ''
s3EncryptionEnabled: true
cloudWatchLogGroupName: ''
cloudWatchEncryptionEnabled: true
cloudWatchStreamingEnabled: true
kmsKeyId: ''
runAsEnabled: true
runAsDefaultUser: ''
idleSessionTimeout: '20'
maxSessionDuration: '60'
shellProfile:
windows: ''
linux: ''
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": true,
"kmsKeyId": "",
"runAsEnabled": true,
"runAsDefaultUser": "",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
------
Esempio di documento di sessione tipo `InteractiveCommands`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
Esempio di documento di sessione tipo `Port`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to open given port connection over Session Manager
sessionType: Port
parameters:
paramExample:
type: string
description: document parameter
properties:
portNumber: anyPortNumber
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to open given port connection over Session Manager",
"sessionType": "Port",
"parameters": {
"paramExample": {
"type": "string",
"description": "document parameter"
}
},
"properties": {
"portNumber": "anyPortNumber"
}
}
```
------
Esempio di documento di sessione con caratteri speciali
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Example document with quotation marks
sessionType: InteractiveCommands
parameters:
Test:
type: String
description: Test Input
maxChars: 32
properties:
windows:
commands: |
$Test = '{{ Test }}'
$myVariable = \"Computer name is $env:COMPUTERNAME\"
Write-Host "Test variable: $myVariable`.`nInput parameter: $Test"
runAsElevated: false
```
------
#### [ JSON ]
```
{
"schemaVersion":"1.0",
"description":"Test document with quotation marks",
"sessionType":"InteractiveCommands",
"parameters":{
"Test":{
"type":"String",
"description":"Test Input",
"maxChars":32
}
},
"properties":{
"windows":{
"commands":[
"$Test = '{{ Test }}'",
"$myVariable = \\\"Computer name is $env:COMPUTERNAME\\\"",
"Write-Host \"Test variable: $myVariable`.`nInput parameter: $Test\""
],
"runAsElevated":false
}
}
}
```
------
# Risoluzione dei problemi relativi a Session Manager
Utilizza le informazioni seguenti per risolvere i problemi relativi a AWS Systems Manager Session Manager.
**Topics**
+ [
## AccessDeniedException quando si chiama l' TerminateSession operazione
](#session-manager-troubleshooting-access-denied-exception)
+ [
## Il processo documentale è fallito improvvisamente: l'operatore documentale è scaduto
](#session-manager-troubleshooting-document-worker-timed-out)
+ [
## Session Manager non si connette dalla console Amazon EC2
](#session-manager-troubleshooting-EC2-console)
+ [
## Nessuna autorizzazione ad avviare una sessione
](#session-manager-troubleshooting-start-permissions)
+ [
## SSM Agent non online
](#session-manager-troubleshooting-agent-not-online)
+ [
## Nessuna autorizzazione a modificare le preferenze delle sessioni
](#session-manager-troubleshooting-preferences-permissions)
+ [
## Nodo gestito non disponibile o non configurato per Session Manager
](#session-manager-troubleshooting-instances)
+ [
## Plug-in Session Manager non trovato
](#plugin-not-found)
+ [
## Il plug-in di Session Manager non viene aggiunto automaticamente al percorso della riga di comando (Windows)
](#windows-plugin-env-var-not-set)
+ [
## Il plug-in Session Manager non risponde
](#plugin-unresponsive)
+ [
## TargetNotConnected
](#ssh-target-not-connected)
+ [
## Dopo l'avvio di una sessione viene visualizzata una schermata vuota
](#session-manager-troubleshooting-start-blank-screen)
+ [
## Il nodo gestito non risponde durante le sessioni di esecuzione prolungata
](#session-manager-troubleshooting-log-retention)
+ [
## Si è verificato un errore (InvalidDocument) durante la chiamata dell'operazione StartSession
](#session-manager-troubleshooting-invalid-document)
## AccessDeniedException quando si chiama l' TerminateSession operazione
**Problema**: quando si tenta di terminare una sessione, Systems Manager restituisce il seguente errore:
```
An error occurred (AccessDeniedException) when calling the TerminateSession operation:
User: is not authorized to perform: ssm:TerminateSession on resource:
because no identity-based policy allows the ssm:TerminateSession action.
```
**Soluzione A: verifica che la [versione più recente del Session Manager plugin](https://docs.aws.amazon.com/systems-manager/latest/userguide/plugin-version-history.html) sia installata sul nodo**
Immetti il seguente comando nel terminale e premi Invio.
```
session-manager-plugin --version
```
**Soluzione B: installa o reinstalla l'ultima versione del plug-in**
Per ulteriori informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
**Soluzione C: tentativo di ristabilire una connessione al nodo**
Verifica che il nodo risponda alle richieste. Prova a ristabilire la sessione. Oppure, se necessario, apri la console Amazon EC2 e verifica lo stato dell'istanza è in esecuzione.
## Il processo documentale è fallito improvvisamente: l'operatore documentale è scaduto
**Problema**: quando si avvia una sessione su un host Linux, Systems Manager restituisce il seguente errore:
```
document process failed unexpectedly: document worker timed out,
check [ssm-document-worker]/[ssm-session-worker] log for crash reason
```
Se è stata configurata la registrazione dell'SSM Agent, come descritto in [Visualizzazione dei log di SSM Agent](ssm-agent-logs.md), è possibile visualizzare maggiori dettagli nel log di debug. Per questo problema, Session Manager mostra la seguente voce di log:
```
failed to create channel: too many open files
```
Questo errore indica in genere che ci sono troppi processi di lavoro Session Manager in esecuzione e che il sistema operativo sottostante ha raggiunto un limite. Sono disponibili due opzioni per la risoluzione di questo problema.
**Soluzione A: aumenta il limite di notifica dei file del sistema operativo**
È possibile aumentare il limite eseguendo il comando seguente da un host Linux separato. Questo comando utilizza Systems Manager Run Command. Il valore specificato fa aumentare `max_user_instances` fino a 8192. Questo valore è notevolmente superiore al valore predefinito di 128, ma non affaticherà le risorse dell'host:
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
"commands=sudo sysctl fs.inotify.max_user_instances=8192"
```
**Soluzione B: diminuire le notifiche relative ai file utilizzate da Session Manager nell'host di destinazione **
Esegui il comando seguente da un host Linux separato per elencare le sessioni in esecuzione sull'host di destinazione:
```
aws ssm describe-sessions --state Active --filters key=Target,value=i-02573cafcfEXAMPLE
```
Esamina l'output del comando per identificare le sessioni che non sono più necessarie. È possibile terminare tali sessioni eseguendo il comando seguente da un host Linux separato:
```
aws ssm terminate-session —session-id session ID
```
Facoltativamente, quando non ci sono più sessioni in esecuzione sul server remoto, è possibile liberare risorse aggiuntive eseguendo il comando seguente da un host Linux separato. Questo comando termina tutti i processi di Session Manager in esecuzione sull'host remoto e, di conseguenza, tutte le sessioni sull'host remoto. Prima di eseguire questo comando, verifica che non ci siano sessioni in corso che desideri mantenere:
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
'{"commands":["sudo kill $(ps aux | grep ssm-session-worker | grep -v grep | awk '"'"'{print $2}'"'"')"]}'
```
## Session Manager non si connette dalla console Amazon EC2
**Problema**: dopo aver creato una nuova istanza, il pulsante **Connettiti** > **Session Manager** nella console Amazon Elastic Compute Cloud (Amazon EC2) non ti offre la possibilità di connetterti.
**Soluzione A: crea un profilo di istanza**: se non l'hai già fatto (come indicato nelle informazioni nella scheda **Session Manager** nella console EC2), crea un profilo di istanza AWS Identity and Access Management (IAM) utilizzando. Quick Setup Quick Setupè uno strumento in. AWS Systems Manager
Session Manager richiede un profilo dell'istanza IAM per connettersi all'istanza. È possibile creare un profilo dell'istanza e assegnarlo all'istanza creando una [configurazione di gestione dell'host](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html) con Quick Setup. Una *configurazione di gestione dell'host* crea un profilo dell'istanza con le autorizzazioni richieste e lo assegna all'istanza. Una configurazione di gestione dell'host abilita anche altri strumenti di Systems Manager e crea ruoli IAM per l'esecuzione di tali strumenti. L'utilizzo di Quick Setup o degli strumenti abilitati dalla configurazione di gestione dell'host è gratuito. [Apri Quick Setup e crea una configurazione di gestione dell'host](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt).
**Importante**
Dopo aver creato la configurazione di gestione dell'host, Amazon EC2 può impiegare alcuni minuti per registrare la modifica e aggiornare la scheda **Session Manager**. Se la scheda non mostra il pulsante **Connetti** dopo due o tre minuti, riavvia l'istanza. Dopo il riavvio, se ancora non vedi l'opzione per la connessione, apri [Configurazione rapida](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt) e verifica che esista una sola configurazione di gestione dell'host. Se ne esistono due, elimina la configurazione precedente e attendi qualche minuto.
Se non riesci ancora a connetterti dopo aver creato una configurazione di gestione dell'host o se ricevi un errore, incluso un errore relativo a SSM Agent, consulta una delle seguenti soluzioni:
+ [Soluzione B: nessun errore, ma non riesci ancora a connetterti](#session-manager-troubleshooting-EC2-console-no-error)
+ [Soluzione C: errore relativo alla mancanza di SSM Agent](#session-manager-troubleshooting-EC2-console-no-agent)
### Soluzione B: nessun errore, ma non riesci ancora a connetterti
Se hai creato la configurazione di gestione dell'host, hai aspettato diversi minuti prima di provare a connetterti e non riesci ancora a connetterti, potrebbe essere necessario applicare manualmente la configurazione di gestione dell'host all'istanza. Utilizza la procedura seguente per aggiornare una configurazione di gestione dell'host di Quick Setup e applicare le modifiche a un'istanza.
**Per aggiornare una configurazione di gestione dell'host utilizzando Quick Setup**
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 **Quick Setup**.
1. Nell'elenco **Configurazioni**, scegli la configurazione **Gestione host** che hai creato.
1. Scegli **Operazioni**, quindi **Modifica configurazione**.
1. Nella parte inferiore della sezione **Destinazioni**, in **Scegli come destinare le istanze**, scegli **Manuale**.
1. Nella sezione **Istanze**, scegli l'istanza che hai creato.
1. Scegli **Aggiorna**.
Attendi qualche minuto che EC2 aggiorni la scheda **Session Manager**. Se ancora non riesci a connetterti o se ricevi un errore, esamina le soluzioni rimanenti per questo problema.
### Soluzione C: errore relativo alla mancanza di SSM Agent
Se non sei riuscito a creare una configurazione di gestione dell'host utilizzando Quick Setup o se hai ricevuto un errore relativo alla SSM Agent mancata installazione, potresti dover eseguire l'installazione manualmente SSM Agent sull'istanza. SSM Agentè un software Amazon che consente a Systems Manager di connettersi alla tua istanza utilizzandoSession Manager. SSM Agentè installato per impostazione predefinita sulla maggior parte delle Amazon Machine Images (AMIs). Se l'istanza è stata creata da un'AMI non standard o da un'AMI precedente, potrebbe essere necessario installare manualmente l'agente. Per la procedura di installazione di SSM Agent, consulta il seguente argomento che corrisponde al sistema operativo dell'istanza.
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
+ [AlmaLinux](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-alma.html)
+ [Amazon Linux 2 e AL2023](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-al2.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-oracle.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-oracle.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rhel.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rhel.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rocky.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rocky.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-ubuntu.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-ubuntu.html)
Per problemi con SSM Agent, vedi [Risoluzione dei problemi relativi a SSM Agent](troubleshooting-ssm-agent.md).
## Nessuna autorizzazione ad avviare una sessione
**Problema**: tenti di avviare una sessione, ma il sistema indica che non disponi delle autorizzazioni necessarie.
+ **Soluzione**: un amministratore di sistema non ti ha concesso le autorizzazioni relative alle policy AWS Identity and Access Management (IAM) per l'avvio delle Session Manager sessioni. Per informazioni, consulta [Controllo dell'accesso della sessione utente alle istanze](session-manager-getting-started-restrict-access.md).
## SSM Agent non online
**Problema**: compare un messaggio nella scheda dell'istanza Amazon EC2 **Session Manager** che indica: ''SSM Agent non è online. L'SSM Agent non è riuscito a connettersi a un endpoint di Systems Manager per registrarsi con il servizio.''
**Soluzione**: SSM Agent è il software Amazon che viene eseguito su istanze Amazon EC2 in modo da consentire a Session Manager di connettersi. Se viene visualizzato questo errore, significa che l'SSM Agent non è in grado di stabilire una connessione con l'endpoint di Systems Manager. È possibile che l'origine del problema sia costituita da restrizioni del firewall, problemi di routing o mancanza di connessione Internet. Per risolvere il problema, esaminare i problemi di connettività di rete. Per ulteriori informazioni, consultare [Risoluzione dei problemi relativi a SSM Agent](troubleshooting-ssm-agent.md) e [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md). Per informazioni sugli endpoint di Systems Manager, consulta [Endpoint e quote di AWS Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html) nel Documento di riferimento generale ad AWS .
## Nessuna autorizzazione a modificare le preferenze delle sessioni
**Problema**: tenti di aggiornare le preferenze globali delle sessioni della tua organizzazione, ma il sistema indica che non disponi delle autorizzazioni necessarie.
+ **Soluzione**: un amministratore di sistema non ti ha concesso le autorizzazioni di policy IAM per l'impostazione delle preferenze del Session Manager. Per informazioni, consulta [Concedere o negare a un utente le autorizzazioni per aggiornare le preferenze del Session Manager](preference-setting-permissions.md).
## Nodo gestito non disponibile o non configurato per Session Manager
**Problema 1**: desideri avviare una sessione dalla pagina della console **Start a session (Avvia una sessione)**, ma non sono presenti nodi gestiti nell'elenco.
+ **Soluzione A**: il nodo gestito a cui desideri connetterti potrebbe non essere stato configurato AWS Systems Manager. Per ulteriori informazioni, consulta [Configurazione della console unificata di Systems Manager per un'organizzazione](systems-manager-setting-up-organizations.md).
**Nota**
Se AWS Systems Manager SSM Agent è già in esecuzione su un nodo gestito quando colleghi il profilo dell'istanza IAM, potrebbe essere necessario riavviare l'agente prima che l'istanza venga elencata nella pagina **Avvia una console di sessione**.
+ **Soluzione B**: la configurazione proxy applicata al SSM Agent sul tuo nodo gestito potrebbe essere corretta Se la configurazione del proxy non è corretta, il nodo gestito non sarà in grado di raggiungere gli endpoint del servizio necessari oppure il nodo potrebbe fare riferimento a un sistema operativo diverso a Systems Manager. Per ulteriori informazioni, consultare [Configurazione di SSM Agent per l'utilizzo di un proxy sui nodi Linux](configure-proxy-ssm-agent.md) e [Configurazione di SSM Agent per utilizzare un proxy per le istanze Windows Server](configure-proxy-ssm-agent-windows.md).
**Problema 2**: un nodo gestito che desideri connettere si trova nell'elenco nella pagina della console **Avvia una sessione**, ma la pagina segnala che "L'istanza selezionata non è configurata per l'uso di Session Manager."
+ **Soluzione A**: il nodo gestito è stato configurato per l'uso con il servizio di Systems Manager, ma il profilo dell'istanza IAM collegato al nodo potrebbe non includere le autorizzazioni per lo strumento di Session Manager. Per informazioni, consulta la sezione [Verifica o creazione di un profilo dell'istanza IAM con autorizzazioni Session Manager](session-manager-getting-started-instance-profile.md).
+ **Soluzione B**: il nodo gestito non esegue una versione dell'SSM Agent che supporta il Session Manager. Aggiorna l'SSM Agent sul nodo alla versione 2.3.68.0 o successiva.
Aggiorna l'SSM Agent manualmente su un nodo gestito seguendo la procedura descritta nei passi [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Windows Server](manually-install-ssm-agent-windows.md), [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Linux](manually-install-ssm-agent-linux.md) o [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per macOS](manually-install-ssm-agent-macos.md), a seconda del sistema operativo in uso.
In alternativa, utilizza il documento Run Command `AWS-UpdateSSMAgent` per aggiornare la versione dell'agente su uno o più nodi gestiti alla volta. Per informazioni, consulta [Aggiornamento di SSM Agent utilizzando Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
**Suggerimento**
Per mantenere sempre aggiornato l'agente, consigliamo di aggiornare SSM Agent alla versione più recente in base a una pianificazione automatizzata che potrai definire attraverso uno dei metodi seguenti:
Esegui `AWS-UpdateSSMAgent` nell'ambito di un'associazione State Manager. Per informazioni, consulta [Procedura dettagliata: aggiorna SSM Agent automaticamente con AWS CLI](state-manager-update-ssm-agent-cli.md).
Esegui `AWS-UpdateSSMAgent` all'interno di una finestra di manutenzione. Per ulteriori informazioni sull'uso delle finestre di manutenzione, consulta [Crea e gestisci finestre di manutenzione utilizzando la console](sysman-maintenance-working.md) e [Tutorial: Creare e configurare una finestra di manutenzione utilizzando il AWS CLI](maintenance-windows-cli-tutorials-create.md).
+ **Soluzione C**: il nodo gestito non può raggiungere gli endpoint del servizio necessari. È possibile migliorare il livello di sicurezza dei nodi gestiti utilizzando gli endpoint di interfaccia forniti da AWS PrivateLink per connettersi agli endpoint Systems Manager. L'alternativa all'utilizzo di un endpoint di interfaccia è l'abilitazione dell'accesso a Internet in uscita sui nodi gestiti. Per ulteriori informazioni, consulta [Utilizzare PrivateLink per configurare un endpoint VPC](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html) per. Session Manager
+ **Soluzione D**: il nodo gestito dispone di risorse di memoria o CPU limitate. Sebbene il nodo gestito possa essere funzionale, se non dispone di risorse sufficienti, non è possibile stabilire una sessione. Per ulteriori informazioni, consulta [Risoluzione di problemi relativi a un'istanza irraggiungibile](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html).
## Plug-in Session Manager non trovato
Per utilizzare i comandi AWS CLI per eseguire la sessione, il Session Manager plug-in deve essere installato anche sul computer locale. Per informazioni, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
## Il plug-in di Session Manager non viene aggiunto automaticamente al percorso della riga di comando (Windows)
Quando installi il plug-in di Session Manager su Windows, l'eseguibile `session-manager-plugin` dovrebbe essere aggiunto automaticamente alla variabile di ambiente `PATH` del sistema operativo. Se il comando ha esito negativo quando lo esegui per verificare se il plug-in Session Manager è stato installato correttamente (`aws ssm start-session --target instance-id`), potrebbe essere necessario impostarlo manualmente utilizzando la seguente procedura.
**Modifica della variabile PATH (Windows)**
1. Premi il tasto Windows e immetti **environment variables**.
1. Scegli **Modifica variabili di ambiente per l'account**.
1. Scegli **PATH** e quindi **Modifica**.
1. Aggiungi percorsi al campo **Valore variabile**, separati da punti e virgola, come illustrato in questo esempio: *`C:\existing\path`*;*`C:\new\path`*
*`C:\existing\path`*rappresenta il valore già presente nel campo. *`C:\new\path`*rappresenta il percorso da aggiungere, come illustrato nell'esempio seguente.
+ **Computer a 64 bit**: `C:\Program Files\Amazon\SessionManagerPlugin\bin\`
1. Fai doppio clic su **OK** per applicare le nuove impostazioni.
1. Chiudi gli eventuali prompt di comando in esecuzione e riapri.
## Il plug-in Session Manager non risponde
Durante una sessione di inoltro della porta, il traffico potrebbe interrompere l'inoltro se nel computer locale è installato un software antivirus. In alcuni casi, il software antivirus interferisce con il plug-in Session Manager che causa deadlock del processo. Per risolvere il problema, consentire o escludere il plug-in Session Manager dal software antivirus. Per informazioni sul percorso di installazione predefinito del plug-in Session Manager, consulta [Installa il Session Manager plugin per AWS CLI](session-manager-working-with-install-plugin.md).
## TargetNotConnected
**Problema**: si tenta di avviare una sessione, ma il sistema restituisce il messaggio di errore «Si è verificato un errore (TargetNotConnected) durante la chiamata all' StartSession operazione: *InstanceID* non è connesso».
+ **Soluzione A**: questo errore viene restituito quando il nodo gestito di destinazione specificato per la sessione non è completamente configurato per l'utilizzo con Session Manager. Per informazioni, consulta [Configurazione di Session Manager](session-manager-getting-started.md).
+ **Soluzione B**: questo errore viene restituito anche se si tenta di avviare una sessione su un nodo gestito che si trova in un altro Account AWS o Regione AWS.
## Dopo l'avvio di una sessione viene visualizzata una schermata vuota
**Problema**: avvii una sessione e Session Manager visualizza una schermata vuota.
+ **Soluzione A**: questo problema può verificarsi quando il volume principale del nodo gestito è pieno. A causa della mancanza di spazio su disco, SSM Agent sul nodo gestito smette di funzionare. Per risolvere questo problema, usa Amazon CloudWatch per raccogliere metriche e log dai sistemi operativi. Per informazioni, consulta [Raccogli metriche, log e tracce con l' CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) nella *Amazon CloudWatch User* Guide.
+ **Soluzione B**: se è stato effettuato l'accesso alla console utilizzando un collegamento che include una coppia endpoint e regione non corrispondente, potrebbe essere visualizzata una schermata vuota. Ad esempio, nel seguente URL della console, `us-west-2` è l'endpoint specificato, ma `us-west-1` è la Regione AWS specificata:
```
https://us-west-2.console.aws.amazon.com/systems-manager/session-manager/sessions?region=us-west-1
```
+ **Soluzione C**: il nodo gestito si connette a Systems Manager tramite endpoint VPC e Session Manager le tue preferenze scrivono l'output della sessione su un bucket Amazon S3 o un gruppo di log CloudWatch Amazon Logs, ma nel VPC non esiste un endpoint gateway `logs` o `s3` un endpoint di interfaccia. Un endpoint `s3` nel formato **`com.amazonaws.region.s3`** è necessario se i nodi gestiti si connettono a Systems Manager utilizzando gli endpoint VPC e le preferenze Session Manager scrivono l'output di sessione in un bucket Amazon S3. In alternativa, **`com.amazonaws.region.logs`**è necessario un `logs` endpoint in questo formato se i nodi gestiti si connettono a Systems Manager utilizzando endpoint VPC e le Session Manager preferenze scrivono l'output della sessione in CloudWatch un gruppo di log Logs. Per ulteriori informazioni, consulta [Creazione degli endpoint VPC per Systems Manager](setup-create-vpc.md#create-vpc-endpoints).
+ **Soluzione D**: il gruppo di log o il bucket Amazon S3 specificato nelle preferenze di sessione è stato eliminato. Per risolvere questo problema, aggiornare le preferenze di sessione con un gruppo di log valido o un bucket S3.
+ **Soluzione E**: il gruppo di log o il bucket Amazon S3 specificato nelle preferenze di sessione non è crittografato, ma hai impostato la proprietà`cloudWatchEncryptionEnabled` o input `s3EncryptionEnabled` a `true`. Per risolvere questo problema, aggiorna le preferenze di sessione con un gruppo di log o un bucket Amazon S3 crittografato oppure imposta la proprietà `cloudWatchEncryptionEnabled` o input `s3EncryptionEnabled` a `false`. Questo scenario è applicabile solo ai clienti che creano preferenze di sessione utilizzando gli strumenti a riga di comando.
## Il nodo gestito non risponde durante le sessioni di esecuzione prolungata
**Problema**: il nodo gestito non risponde o si arresta in modo anomalo durante una sessione di esecuzione prolungata.
**Soluzione**: riduci la durata di conservazione dei log SSM Agent di Session Manager.
**Riduzione della durata di conservazione dei log SSM Agent delle sessioni**
1. Individua il plug-in `amazon-ssm-agent.json.template` nella directory `/etc/amazon/ssm/` per Linux o `C:\Program Files\Amazon\SSM` per Windows.
1. Copia il contenuto di `amazon-ssm-agent.json.template` in un nuovo file nella stessa directory denominata `amazon-ssm-agent.json`.
1. Ridurre il valore di default del valore `SessionLogsRetentionDurationHours` nella proprietà `SSM` e salva il file.
1. Riavvia l'SSM Agent.
## Si è verificato un errore (InvalidDocument) durante la chiamata dell'operazione StartSession
**Problema**: quando avvii una sessione utilizzando la AWS CLI, visualizzi l'errore seguente.
```
An error occurred (InvalidDocument) when calling the StartSession operation: Document type: 'Command' is not supported. Only type: 'Session' is supported for Session Manager.
```
**Soluzione**: il documento SSM specificato per il parametro `--document-name` non è un documento di *Sessione*. Utilizza la procedura seguente per visualizzare un elenco di documenti di sessione nella Console di gestione AWS.
**Visualizzazione di un elenco di documenti di sessione**
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 riquadro di navigazione, scegli **Documenti**.
1. Nell'elenco **Categorie**, scegli **Documenti di sessione**.
# AWS Systems Manager State Manager
State Manager, uno strumento in AWS Systems Manager, è un servizio di gestione della configurazione sicuro e scalabile che automatizza il processo di mantenimento dei nodi gestiti e AWS delle altre risorse in uno stato definito dall'utente. Per cominciare a utilizzare State Manager, apri la [console di Systems Manager](https://console.aws.amazon.com//systems-manager/state-manager). Nel pannello di navigazione, scegli **State Manager**.
**Nota**
State Manager e Maintenance Windows sono in grado di eseguire alcuni tipi di aggiornamenti simili sui nodi gestiti. La scelta dipende dalla necessità di automatizzare la conformità del sistema o di eseguire attività ad alta priorità e sensibili al tempo durante i periodi specificati.
Per ulteriori informazioni, consulta [Scelta tra State Manager e Maintenance Windows](state-manager-vs-maintenance-windows.md).
## Quali sono i vantaggi di State Manager per la mia organizzazione?
Utilizzando documenti Systems Manager preconfigurati (documenti SSM), State Manageroffre i seguenti vantaggi per la gestione dei nodi:
+ Bootstrap di nodi con software specifico all'avvio
+ Download e aggiornamento di agenti in base a una pianificazione definita, tra cui SSM Agent
+ Configurazione delle impostazioni di rete.
+ Consente di aggiungere nodi a un dominio Microsoft Active Directory.
+ Esecuzione di script sui nodi gestiti di Linux, macOS e Windows Server per tutto il loro ciclo di vita.
Per gestire la deriva della configurazione tra altre AWS risorse, è possibile utilizzare Automation, uno strumento di Systems Manager, che consente di State Manager eseguire i seguenti tipi di attività:
+ Assegna un ruolo Systems Manager alle istanze di Amazon Elastic Compute Cloud (Amazon EC2) per renderle *nodi gestiti*.
+ applica le regole di ingresso e di uscita desiderate per un gruppo di sicurezza;
+ crea o elimina i backup di Amazon DynamoDB;
+ crea o elimina gli snapshot di Amazon Elastic Block Store (Amazon EBS);
+ Disattiva le autorizzazioni di lettura e scrittura per i bucket Amazon Simple Storage Service (Amazon S3);
+ Avvia, riavvia o arresta i nodi gestiti e le istanze di Amazon Relational Database Service (Amazon RDS);
+ applicare patch a Linux, macOS e alla finestra AMIs;
Per informazioni sull’uso di State Manager con i runbook di automazione, consulta [Pianificazione di automazioni con associazioni State Manager](scheduling-automations-state-manager-associations.md).
## A chi è consigliato l'uso di State Manager?
State Managerè adatto a qualsiasi AWS cliente che desideri migliorare la gestione e la governance delle proprie AWS risorse e ridurre le differenze di configurazione.
## Quali sono le funzionalità di State Manager?
Le funzionalità principali di State Manager comprendono:
+
**Associazioni di State Manager**
Un'State Manager*associazione* è una configurazione che assegni alle tue AWS risorse. La configurazione definisce lo stato che desideri mantenere sulle risorse. Ad esempio, un'associazione può specificare che il software antivirus debba essere installato ed eseguito su un nodo gestito o che determinate porte debbano essere chiuse.
Un'associazione specifica una pianificazione per quando applicare la configurazione e le destinazioni per l'associazione. Ad esempio, un'associazione per il software antivirus potrebbe essere eseguita una volta al giorno su tutti i nodi gestiti in un account Account AWS. Se il software non è installato su un nodo, l'associazione potrebbe istruire State Manager per installarlo. Se il software è installato, ma il servizio non è in esecuzione, l'associazione potrebbe indicare a State Manager di avviare il servizio.
+
**Opzioni di pianificazione flessibili**
State Manager offre le seguenti opzioni per la pianificazione quando viene eseguita un'associazione:
+ **Elaborazione immediata o posticipata**
Quando si crea un'associazione , per impostazione predefinita, il sistema la esegue immediatamente sulle istanze o destinazioni specificate. Dopo l'esecuzione iniziale, l'associazione viene eseguita a intervalli in base alla pianificazione definita.
È possibile istruire State Manager a non eseguire immediatamente un'associazione utilizzando l’associazione **Applica associazione solo all'opzione intervallo Cron specificata successiva** nella console o nel parametro `ApplyOnlyAtCronInterval` dalla riga di comando.
+ **Espressioni Cron e della frequenza**
Quando crei un'associazione, specifica una pianificazione per quando State Manager applica la configurazione. State Manager supporta espressioni Cron e della frequenza standard per pianificare quando eseguire un'associazione. State Manager supporta anche espressioni Cron che includono un giorno della settimana e il segno numerico (\$1) per designare il giorno *n* del mese per l'esecuzione di un'associazione e il segno (L) per indicare l'ultimo giorno *X* del mese.
**Nota**
State Manager attualmente non supporta la specifica di mesi nelle espressioni cron per le associazioni.
Per controllare ulteriormente l'esecuzione di un'associazione, ad esempio se si desidera eseguire un'associazione due giorni dopo la patch di martedì, è possibile specificare un offset. Un record *offset* definisce quanti giorni attendere dopo il giorno programmato per eseguire un'associazione.
Per ulteriori informazioni sulla creazione di espressioni Cron/della frequenza, consulta [Riferimento: espressioni Cron e della frequenza per Systems Manager](reference-cron-and-rate-expressions.md).
+
**Diverse opzioni di targeting**
Un'associazione specifica anche gli obiettivi dell'associazione. State Managersupporta il targeting AWS delle risorse utilizzando tag AWS Resource Groups, singoli nodi IDs o tutti i nodi gestiti nella versione corrente Regione AWS e. Account AWS
+
**Supporto Amazon S3**
Archivia l'output dei comandi dall'associazione in esecuzione in un bucket Amazon S3 di tua scelta. Per ulteriori informazioni, consulta [Utilizzo delle associazioni in Systems Manager](state-manager-associations.md).
+
**EventBridge supporto**
Questo strumento Systems Manager è supportato sia come tipo di *evento* che come tipo di *destinazione* nelle EventBridge regole di Amazon. Per informazioni, consulta [Monitoraggio degli eventi di Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md) e [Riferimento: modelli e tipi di EventBridge eventi Amazon per Systems Manager](reference-eventbridge-events.md).
## C'è un addebito per l'utilizzo di State Manager?
State Manager è disponibile senza costi aggiuntivi.
**Topics**
+ [
## Quali sono i vantaggi di State Manager per la mia organizzazione?
](#state-manager-benefits)
+ [
## A chi è consigliato l'uso di State Manager?
](#state-manager-who)
+ [
## Quali sono le funzionalità di State Manager?
](#state-manager-features)
+ [
## C'è un addebito per l'utilizzo di State Manager?
](#state-manager-cost)
+ [
# Introduzione al funzionamento di State Manager
](state-manager-about.md)
+ [
# Utilizzo delle associazioni in Systems Manager
](state-manager-associations.md)
+ [
# Creazione di associazioni che eseguono file MOF
](systems-manager-state-manager-using-mof-file.md)
+ [
# Creazione di associazioni che eseguono playbook Ansible
](systems-manager-state-manager-ansible.md)
+ [
# Creazione di associazioni che eseguono ricette di Chef
](systems-manager-state-manager-chef.md)
+ [
# Procedura dettagliata: aggiorna SSM Agent automaticamente con AWS CLI
](state-manager-update-ssm-agent-cli.md)
+ [
# Spiegazione passo per passo: aggiornare automaticamente i driver PV sulle istanze EC2 per Windows Server
](state-manager-update-pv-drivers.md)
**Ulteriori informazioni**
+ [Combattere la deriva della configurazione utilizzando Amazon EC2 Systems Manager e Windows DSC PowerShell ](https://aws.amazon.com/blogs/mt/combating-configuration-drift-using-amazon-ec2-systems-manager-and-windows-powershell-dsc/)
+ [Configurare istanze Amazon EC2 in un gruppo Auto Scaling tramite State Manager](https://aws.amazon.com/blogs/mt/configure-amazon-ec2-instances-in-an-auto-scaling-group-using-state-manager/)
# Introduzione al funzionamento di State Manager
State Manager, a tool in AWS Systems Manager, è un servizio sicuro e scalabile che automatizza il processo di mantenimento dei nodi gestiti in un'infrastruttura [ibrida e multicloud](operating-systems-and-machine-types.md#supported-machine-types) in uno stato definito dall'utente.
Ecco come funziona State Manager:
**1. Determina lo stato che desideri applicare alle tue risorse. AWS **
Vuoi assicurarti che i nodi gestiti siano configurato con applicazioni specifiche, ad esempio applicazioni antivirus o malware? Vuoi automatizzare il processo di aggiornamento dell'SSM Agent o di altri pacchetti AWS , come ad esempio `AWSPVDriver`? Vuoi accertarti che determinate porte siano aperte o chiuse? Per iniziareState Manager, determina lo stato che desideri applicare alle tue AWS risorse. Lo stato che desideri applicare determinerà quale documento SSM utilizzerai per creare un'associazione di State Manager.
Un'State Manager*associazione* è una configurazione che assegni alle tue AWS risorse. La configurazione definisce lo stato che desideri mantenere sulle risorse. Ad esempio, un'associazione può specificare che il software antivirus debba essere installato ed eseguito su un nodo gestito o che determinate porte debbano essere chiuse.
Un'associazione specifica una pianificazione per quando applicare la configurazione e le destinazioni per l'associazione. Ad esempio, un'associazione per il software antivirus potrebbe essere eseguita una volta al giorno su tutti i nodi gestiti in un account Account AWS. Se il software non è installato su un nodo, l'associazione potrebbe istruire State Manager per installarlo. Se il software è installato, ma il servizio non è in esecuzione, l'associazione potrebbe indicare a State Manager di avviare il servizio.
**2. Determina se un documento SSM preconfigurato può aiutarti a creare lo stato desiderato sulle tue risorse. AWS **
Systems Manager include decine di documenti SSM preconfigurati che è possibile utilizzare per creare un'associazione. I documenti preconfigurati sono pronti per eseguire attività comuni come l'installazione di applicazioni, la configurazione di Amazon CloudWatch, l'esecuzione di AWS Systems Manager automazioni, l'esecuzione di script Shell PowerShell e l'aggiunta di nodi gestiti a un dominio di servizi di directory per Active Directory.
È possibile visualizzare tutti i documenti SSM nella [console di Systems Manager](https://console.aws.amazon.com/systems-manager/documents). Scegliere il nome di un documento per scoprire ulteriori informazioni su ciascuno di essi. Di seguito, sono riportati due esempi: [https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description](https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description) e [https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description](https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description).
**3. Creazione di un'associazione**
È possibile creare un'associazione utilizzando la console Systems Manager, AWS Command Line Interface (AWS CLI), AWS Tools for Windows PowerShell (Tools for Windows PowerShell) o l'API Systems Manager. Quando viene creata l'associazione, si specifica quanto segue:
+ Un nome per l'associazione.
+ I parametri per il documento SSM (ad esempio, il percorso dell'applicazione da installare o lo script da eseguire sui nodi).
+ I target per l'associazione. È possibile scegliere come target i nodi gestiti specificando i tag, scegliendo un singolo nodo IDs o selezionando un gruppo in AWS Resource Groups. Puoi anche scegliere come target *tutti i* nodi gestiti nell'attuale Regione AWS e Account AWS. Se le tue destinazioni includono più di 1.000 nodi, il sistema utilizza un meccanismo di limitazione (della larghezza di banda della rete). Ciò significa che potresti riscontrare imprecisioni nel conteggio dell'aggregazione dello stato, poiché il processo di aggregazione viene eseguito ogni ora e solo quando lo stato di esecuzione di un nodo cambia.
+ Ruolo utilizzato dall'associazione per intraprendere azioni per conto dell'utente. State Manager assumerà questo ruolo e la chiamata richiesta per l' APIs invio delle configurazioni ai nodi. Per informazioni sulla configurazione del ruolo fornito personalizzato, vedere. [Imposta i ruoli per `AssociationDispatchAssumeRole`](#setup-assume-role) Se non viene fornito alcun ruolo, verrà utilizzato il [ruolo collegato al servizio per Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/using-service-linked-roles.html).
**Nota**
Si consiglia di definire un ruolo IAM personalizzato in modo da avere il pieno controllo delle autorizzazioni di cui dispone State Manager quando intraprende azioni per conto dell'utente.
Il supporto dei ruoli collegati ai servizi in State Manager viene gradualmente eliminato. Le associazioni che si basano sul ruolo collegato al servizio potrebbero richiedere aggiornamenti in futuro per continuare a funzionare correttamente.
Per informazioni sulla gestione dell'utilizzo del ruolo fornito dall'utente, vedere. [Gestisci l'utilizzo di AssociationDispatchAssumeRole con `ssm:AssociationDispatchAssumeRole`](#context-key-assume-role)
+ Una pianificazione per il momento o la frequenza di applicazione dello stato. È possibile specificare un'espressione Cron o della frequenza. Per ulteriori informazioni sulla creazione di pianificazioni utilizzando espressioni Cron e della frequenza, consulta [Espressioni Cron e della frequenza per le associazioni](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association).
**Nota**
State Manager attualmente non supporta la specifica di mesi nelle espressioni cron per le associazioni.
Quando si esegue il comando per creare l'associazione, Systems Manager associa le informazioni specificate (pianificazione, target, documento SSM e parametri) alle risorse target. Lo stato dell'associazione inizialmente mostra "Pending" (In sospeso) mentre il sistema tenta di raggiungere tutti i target e applica *immediatamente* lo stato specificato nell'associazione.
Se si crea una nuova associazione pianificata per essere eseguita mentre un'associazione precedente è ancora in esecuzione, la prima associazione viene messa in timeout e viene eseguita la nuova associazione.
Systems Manager indica lo stato della richiesta di creazione di associazioni sulle risorse. È possibile visualizzare i dettagli sullo stato nella console o (per i nodi gestiti) utilizzando l'operazione [DescribeInstanceAssociationsStatus](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceAssociationsStatus.html)API. Se si sceglie di scrivere l'output del comando in Amazon Simple Storage Service (Amazon S3) quando si crea un'associazione, è possibile anche visualizzare l'output nel bucket Amazon S3 specificato.
Per ulteriori informazioni, consulta [Utilizzo delle associazioni in Systems Manager](state-manager-associations.md).
Le operazioni API avviate dal documento SSM durante un'esecuzione di associazione non vengono registrate in AWS CloudTrail.
**4. Monitorare e aggiornare.**
Una volta creata l'associazione, State Manager riapplica la configurazione in base alla pianificazione definita nell'associazione. È possibile visualizzare lo stato delle associazioni nella [pagina di State Manager](https://console.aws.amazon.com/systems-manager/state-manager) nella console oppure chiamando direttamente l'ID di associazione generato da Systems Manager quando è stata creata l'associazione. Per ulteriori informazioni, consulta [Visualizzazione della cronologia delle associazioni](state-manager-associations-history.md). È possibile aggiornare i documenti delle associazioni e riapplicarli come necessario. È possibile inoltre creare più versioni di un'associazione. Per ulteriori informazioni, consulta [Modifica e creazione di una nuova versione di un'associazione](state-manager-associations-edit.md).
## Capire quando le associazioni vengono applicate alle risorse
Quando crei un'associazione, specifichi un documento SSM che definisce la configurazione, un elenco di risorse target e una pianificazione per l'applicazione della configurazione. Per impostazione predefinita, State Manager esegue l'associazione al momento della creazione e quindi in base alla pianificazione specificata. State Manager prova inoltre a eseguire l'associazione nelle seguenti situazioni:
+ **Modifica associazione**: State Manager esegue l'associazione dopo che un utente ha modificato e salvato le modifiche in uno dei seguenti campi di associazione: `DOCUMENT_VERSION`, `PARAMETERS`, `SCHEDULE_EXPRESSION`, `OUTPUT_S3_LOCATION`.
+ **Modifica documento**: State Manager esegue l'associazione dopo che un utente ha modificato e salvato le modifiche al documento SSM che definisce lo stato di configurazione dell'associazione. In particolare, l'associazione viene eseguita dopo le seguenti modifiche al documento:
+ Un utente specifica una nuova versione del documento `$DEFAULT` e l'associazione era stata creata utilizzando la versione `$DEFAULT`.
+ Un utente aggiorna un documento e l'associazione era stata creata utilizzando la versione `$LATEST`.
+ Un utente elimina il documento specificato al momento della creazione dell'associazione.
+ **Avvio manuale**: State Manager esegue l'associazione quando viene avviata dall'utente dalla console di Systems Manager o a livello di programmazione.
+ **Modifiche alla destinazione**: State Manager esegue l'associazione dopo che si è verificata una delle seguenti attività su un nodo di destinazione:
+ Un nodo gestito passa online per la prima volta.
+ Un nodo gestito passa online dopo la mancata esecuzione di un'associazione pianificata.
+ Un nodo gestito passa online dopo essere stato arrestato per più di 30 giorni.
**Nota**
State Manager non monitora i documenti o i pacchetti utilizzati nelle associazioni all'interno degli Account AWS. Se aggiorni un documento o un pacchetto in un account, l'aggiornamento non causerà l'esecuzione dell'associazione nel secondo account. È necessario eseguire manualmente l'associazione nel secondo account.
**Impedire l'esecuzione delle associazioni quando una destinazione cambia**
In alcuni casi, potresti non voler eseguire un'associazione quando una destinazione composta da nodi gestiti cambia, ma solo in base alla pianificazione specificata.
**Nota**
L'esecuzione di un runbook di automazione comporta un costo. Se un'associazione a un runbook di automazione è diretta a tutte le istanze del tuo account e avvii regolarmente un gran numero di istanze, il runbook viene eseguito su ciascuna istanza al momento dell'avvio. Ciò può comportare costi di automazione elevati.
Per evitare che un'associazione venga eseguita quando le destinazioni di quell'associazione cambiano, seleziona la **casella di controllo Applica l'associazione solo al successivo intervallo cron specificato**. Questa casella di controllo si trova nell'area **Specifica pianificazione** delle pagine **Crea associazione** e **Modifica associazione**.
Questa opzione si applica alle associazioni che incorporano sia un runbook di automazione che un documento SSM.
## Informazioni sugli aggiornamenti di destinazione con i runbook Automation
Affinché le associazioni create con i runbook Automation vengano applicate quando vengono rilevati nuovi nodi di destinazione, è necessario che vengano soddisfatte le seguenti condizioni:
+ È necessario che l'associazione sia creata da una configurazione [Quick Setup](systems-manager-quick-setup.md). Quick Setup è uno strumento di AWS Systems Manager. Le associazioni create da altri processi non sono attualmente supportate.
+ È necessario che il runbook Automation indirizzi esplicitamente il tipo di risorsa `AWS::EC2::Instance` o `AWS::SSM::ManagedInstance`.
+ È necessario che l'associazione specifichi parametri e destinazioni.
Nella console, i campi **Parametro** e **Destinazioni** vengono visualizzati quando si sceglie un'esecuzione per il controllo della velocità.
![\[Le opzioni relative ai parametri e alle destinazioni sono presentate nella console per le esecuzioni di controllo della velocità\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/sm_Rate_control_execution_options.png)
Quando si utilizzano le azioni di API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociation.html), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociationBatch.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociationBatch.html) o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html), è possibile specificare questi valori utilizzando gli input `AutomationTargetParameterName` e `Targets`. In ognuna di queste azioni di API, puoi anche impedire l'esecuzione dell'associazione ogni volta che una destinazione cambia impostando il parametro `ApplyOnlyAtCronInterval` su `true`.
Per informazioni sull'utilizzo della console per controllare quando vengono eseguite le associazioni, compresi i dettagli per evitare costi inaspettatamente elevati per le esecuzioni di automazione, consulta [Capire quando le associazioni vengono applicate alle risorse](#state-manager-about-scheduling).
## Imposta i ruoli per `AssociationDispatchAssumeRole`
Per configurare un invio personalizzato, si presupponga che State Manager assuma per eseguire azioni per conto dell'utente, che i ruoli siano affidabili `ssm.amazonaws.com` e abbiano l'autorizzazione necessaria per la chiamata `ssm:SendCommand` o in `ssm:StartAutomationExecution` base ai casi d'uso dell'associazione.
Esempio di politica di fiducia:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Gestisci l'utilizzo di AssociationDispatchAssumeRole con `ssm:AssociationDispatchAssumeRole`
Per gestire l'utilizzo dell'invio personalizzato, assumi i ruoli che State Manager assume per eseguire azioni per tuo conto, usa la chiave `ssm:AssociationDispatchAssumeRole` condition. Questa condizione controlla se le associazioni possono essere create o aggiornate senza specificare un ruolo di invio personalizzato.
Nella seguente politica di esempio, l'`"Allow"`istruzione concede le autorizzazioni per la creazione e l'aggiornamento dell'associazione APIs solo quando viene specificato il `AssociationDispatchAssumeRole` parametro. Senza questo parametro nelle richieste API, la policy non concede l'autorizzazione a creare o aggiornare associazioni:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:CreateAssociation",
"ssm:UpdateAssociation",
"ssm:CreateAssociationBatch"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:AssociationDispatchAssumeRole": "*"
}
}
}
]
}
```
# Utilizzo delle associazioni in Systems Manager
In questa sezione viene illustrato come creare e gestire le associazioni State Manager utilizzando la console AWS Systems Manager, il AWS Command Line Interface (AWS CLI), e AWS Strumenti per PowerShell.
**Topics**
+ [
# Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager
](systems-manager-state-manager-targets-and-rate-controls.md)
+ [
# Creazione di associazioni
](state-manager-associations-creating.md)
+ [
# Modifica e creazione di una nuova versione di un'associazione
](state-manager-associations-edit.md)
+ [
# Eliminazione di associazioni
](systems-manager-state-manager-delete-association.md)
+ [
# Esecuzione dei gruppi Auto Scaling con associazioni
](systems-manager-state-manager-asg.md)
+ [
# Visualizzazione della cronologia delle associazioni
](state-manager-associations-history.md)
+ [
# Utilizzo delle associazioni tramite IAM
](systems-manager-state-manager-iam.md)
# Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager
Questo argomento descrive la funzionalità di State Manager, utile per implementare al meglio un'associazione a decine o centinaia di nodi, controllando al tempo stesso il numero di nodi che eseguono l'associazione nell'ora pianificata. State Manager è uno strumento di AWS Systems Manager.
## Utilizzare le destinazioni
Quando si crea un'associazione State Manager, si scelgono i nodi da configurare con l'associazione nella sezione **Destinazioni** della console di Systems Manager, come illustrato di seguito.
![\[Opzioni diverse per l'individuazione dei nodi durante la creazione di un'associazione di State Manager\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/state-manager-targets.png)
Se crei un'associazione utilizzando uno strumento a riga di comando, ad esempio AWS Command Line Interface (AWS CLI), devi specificare il parametro `targets`. Il targeting dei nodi consente di configurare decine, centinaia o migliaia di nodi con un'associazione senza dover specificare o scegliere un singolo nodo IDs.
Ogni nodo gestito può essere scelto come destinazione da un massimo di 20 associazioni.
State Manager include le seguenti opzioni di destinazione in fase di creazione di un'associazione.
**Specificare i tag.**
Utilizzare questa opzione per specificare una chiave di tag e (facoltativamente) un valore di tag assegnati ai nodi. Quando si esegue la richiesta, il sistema individua e tenta di creare l'associazione su tutti i nodi che corrispondono alla chiave e al valore di tag specificati. Se sono stati specificati più valori di tag, l'associazione si rivolge a qualsiasi nodo con almeno uno di questi valori di tag. Quando il sistema crea inizialmente l'associazione, la esegue. Dopo questa esecuzione iniziale, il sistema esegue l'associazione in base alla pianificazione specificata.
Se si creano nuove nodi e si assegnano la chiave e il valore di tag specificati a tali nodi, il sistema applica automaticamente l'associazione, la esegue immediatamente e quindi la esegue in base alla pianificazione. Ciò vale quando l'associazione utilizza un documento di Comando o Policy e non vale se l'associazione utilizza un runbook di Automazione. Se elimini i tag specificati da un nodo, il sistema non esegue più l'associazione su tali nodi.
**Nota**
Se utilizzi i runbook di Automation con State Manager e la limitazione dei tag ti impedisce di raggiungere un obiettivo specifico, prendi in considerazione l'utilizzo dei runbook di Automation con Amazon. EventBridge Per ulteriori informazioni, consulta [Esegui automazioni basate su eventi EventBridge](running-automations-event-bridge.md). Per informazioni sull'uso dei runbook con State Manager, consulta [Pianificazione di automazioni con associazioni State Manager](scheduling-automations-state-manager-associations.md).
Come procedura consigliata, si consiglia di utilizzare i tag durante la creazione di associazioni che utilizzano un documento di Comando o Policy. Si consiglia inoltre di utilizzare i tag durante la creazione di associazioni per eseguire gruppi Auto Scaling Per ulteriori informazioni, consulta [Esecuzione dei gruppi Auto Scaling con associazioni](systems-manager-state-manager-asg.md).
**Nota**
Osserva le seguenti informazioni.
Quando crei un'associazione nei nodi Console di gestione AWS che utilizza i tag, puoi specificare solo una chiave di tag per un'associazione di automazione e cinque chiavi di tag per un'associazione di comandi. *Tutte* le chiavi di tag specificate nell'associazione devono essere attualmente assegnate al nodo. In caso contrario, State Manager non riesce a scegliere il nodo come destinazione per un'associazione.
Se desideri utilizzare la console *e* desideri indirizzare i tuoi nodi utilizzando più di una chiave di tag per un'associazione di automazione e cinque chiavi di tag per un'associazione di comandi, assegna le chiavi di tag a un AWS Resource Groups gruppo e aggiungi i nodi ad esso. È possibile quindi scegliere l'opzione **Gruppo di risorse** nell'elenco **Destinazioni** quando crei l'associazione State Manager.
È possibile specificare un massimo di cinque chiavi di tag utilizzando la AWS CLI. Se si utilizza il AWS CLI, *tutte le* chiavi tag specificate nel `create-association` comando devono essere attualmente assegnate al nodo. In caso contrario, State Manager non riesce a scegliere il nodo come destinazione per un'associazione.
**Scelta manuale dei nodi**
Utilizzare questa opzione per selezionare manualmente i nodi in cui si desidera creare l'associazione. Il riquadro **Istanze** mostra tutti i nodi gestiti da Systems Manager nella versione corrente Account AWS e Regione AWS. È possibile selezionare manualmente tutti i nodi desiderati. Quando il sistema crea inizialmente l'associazione, la esegue. Dopo questa esecuzione iniziale, il sistema esegue l'associazione in base alla pianificazione specificata.
**Nota**
Se un nodo gestito Amazon EC2 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.
**Scelta di un gruppo di risorse**
Utilizzate questa opzione per creare un'associazione su tutti i nodi restituiti da una query AWS Resource Groups basata su tag o AWS CloudFormation stack.
Seguono dettagli sull'individuazione dei gruppi di risorse per un'associazione.
+ Se si aggiungono nuovi nodi a un gruppo, il sistema mappa automaticamente i nodi all'associazione che ha come destinazione il gruppo di risorse. Il sistema applica l'associazione ai nodi quando rileva la modifica. Dopo questa esecuzione iniziale, il sistema esegue l'associazione in base alla pianificazione specificata.
+ Se crei un'associazione destinata a un gruppo di risorse e il tipo di `AWS::SSM::ManagedInstance` risorsa è stato specificato per quel gruppo, in base alla progettazione, l'associazione viene eseguita sia su istanze Amazon Elastic Compute Cloud (Amazon EC2) che su non EC2 nodi in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types).
È vero anche il contrario. Se crei un'associazione destinata a un gruppo di risorse e il tipo di `AWS::EC2::Instance` risorsa è stato specificato per quel gruppo, in base alla progettazione, l'associazione viene eseguita sia su non EC2 nodi in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) che su istanze EC2 (Amazon).
+ Se crei un'associazione destinata a un gruppo di risorse, al gruppo di risorse non devono essere assegnate più di cinque chiavi di tag o più di cinque valori specificati per ciascuna chiave di tag. Se una di queste condizioni si applica ai tag e alle chiavi assegnati al gruppo di risorse, l'associazione non viene eseguita e restituisce un errore `InvalidTarget`.
+ Quando si crea un'associazione destinata a un gruppo di risorse utilizzando i tag, non è possibile scegliere l'opzione **(valore vuoto)** per il valore del tag.
+ Se elimini un gruppo di risorse, tutte le istanze del gruppo non eseguono più l'associazione. Come best practice, è consigliabile eliminare le associazioni che hanno come destinazione il gruppo.
+ Al massimo è possibile assegnare come destinazione un singolo gruppo di risorse per un'associazione. I gruppi multipli o nidificati non sono supportati.
+ Dopo aver creato un'associazione, State Manager la aggiorna periodicamente con le informazioni sulle risorse del gruppo di risorse. Se aggiungi nuove risorse a un gruppo di risorse, la pianificazione di quando il sistema applica l'associazione alle nuove risorse dipende da diversi fattori. È possibile determinare lo stato dell'associazione nella pagina di State Manager della console Systems Manager.
**avvertimento**
Un utente, gruppo o ruolo AWS Identity and Access Management (IAM) con l'autorizzazione a creare un'associazione destinata a un gruppo di risorse di EC2 istanze Amazon ha automaticamente il controllo a livello di root di tutte le istanze del gruppo. Solo gli amministratori attendibili dovrebbero essere autorizzati a creare le associazioni.
Per ulteriori informazioni sui gruppi di risorse, consulta [Che cos'è AWS Resource Groups?](https://docs.aws.amazon.com/ARG/latest/userguide/) nella *Guida per l'utente di AWS Resource Groups *.
**Scelta di tutti i nodi**
Usa questa opzione per indirizzare tutti i nodi dell'attuale e. Account AWS Regione AWS Quando si esegue la richiesta, il sistema individua e tenta di creare l'associazione su tutti i nodi dell'attuale Account AWS e Regione AWS. Quando il sistema crea inizialmente l'associazione, la esegue. Dopo questa esecuzione iniziale, il sistema esegue l'associazione in base alla pianificazione specificata. Se si creano nuovi nodi, il sistema applica automaticamente l'associazione, la esegue immediatamente e quindi la esegue in base alla pianificazione.
## Utilizzo dei controlli di velocità
È possibile controllare l'esecuzione di un'associazione sui nodi specificando un valore di simultaneità e una soglia di errore. Il valore di simultaneità specifica il numero di nodi autorizzati a eseguire contemporaneamente l'associazione. Una soglia di errore specifica il numero di esecuzioni dell'associazione che possono avere esito negativo prima che Systems Manager invii un comando a ogni nodo configurato con tale associazione per arrestare l'esecuzione della stessa. Il comando interrompe l'esecuzione dell'associazione fino all'esecuzione pianificata successiva. Le funzionalità di simultaneità e soglia di errore vengono definite collettivamente *controlli di velocità*.
![\[Le diverse opzioni di controllo di velocità in fase di creazione di un'associazione State Manager\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/state-manager-rate-controls.png)
**Concurrency (Simultaneità)**
La simultaneità aiuta a limitare l'impatto sui nodi, poiché consente di specificare che solo un determinato numero di nodi può elaborare un'associazione contemporaneamente. È possibile specificare un numero assoluto di nodi gestiti, ad esempio 20, oppure una percentuale del set di target, ad esempio 10%.
La simultaneità di State Manager prevede le seguenti restrizioni e limitazioni:
+ Se si sceglie di creare un'associazione utilizzando i target, ma non si specifica un valore di simultaneità, State Manager applica automaticamente un valore di simultaneità massimo di 50 nodi.
+ Se nuovi nodi che soddisfano i criteri di target vanno online mentre un'associazione che utilizza la simultaneità è in esecuzione, i nuovi nodi eseguono l'associazione se il valore di simultaneità non viene superato. Se il valore di simultaneità viene superato, i nodi vengono ignoratiq durante l'intervallo corrente di esecuzione dell'associazione. I nodi eseguiranno l'associazione durante il successivo intervallo pianificato se sono conformi ai requisiti di simultaneità.
+ Se si aggiorna un'associazione che utilizza la simultaneità e uno o più nodi stanno elaborando tale associazione quando viene aggiornata, qualsiasi nodo che esegue l'associazione può essere completato. Le associazioni non avviate vengono arrestate. Dopo il completamento dell'esecuzione delle associazioni, tutti i nodi target eseguono immediatamente di nuovo l'associazione perché è stata aggiornata. Quando l'associazione viene eseguita di nuovo, il valore di simultaneità viene applicato.
**Soglie di errore**
Una soglia di errore specifica il numero di esecuzioni dell'associazione che possono avere esito negativo prima che Systems Manager invii un comando a ogni nodo configurato con tale associazione. Il comando interrompe l'esecuzione dell'associazione fino all'esecuzione pianificata successiva. È possibile specificare un numero assoluto di errori, ad esempio 10, oppure una percentuale della serie di target, ad esempio 10%.
Se specifichi un numero assoluto pari, ad esempio, a tre errori, State Manager invia un comando di arresto alla restituzione del quarto errore. Se specifichi 0, State Manager invia il comando di arresto alla restituzione del primo risultato di errore.
Se specifichi una soglia di errore pari al 10% per 50 associazioni, State Manager invia il comando di arresto alla restituzione del sesto errore. Sarà consentito il completamento delle associazioni già in esecuzione una volta raggiunta la soglia di errore. Tuttavia, è possibile che alcune di tali associazioni abbiano esito negativo. Per garantire che non venga restituito un numero di errori maggiore rispetto al numero specificato per la soglia di errore, imposta il valore di **Simultaneità** su 1, in modo che la progressione delle associazioni avvenga un'unità alla volta.
Le soglie di errore di State Manager prevedono le seguenti restrizioni e limitazioni:
+ Le soglie di errore vengono applicate per l'intervallo corrente.
+ Le informazioni su ogni errore, inclusi i dettagli a livello di fase, vengono registrate nella cronologia dell'associazione.
+ Se scegli di creare un'associazione utilizzando destinazioni, ma non specifichi una soglia di errore, State Manager applica automaticamente una soglia pari al 100% di errori.
# Creazione di associazioni
State Manager, uno strumento in AWS Systems Manager, consente di mantenere le AWS risorse in uno stato definito dall'utente e di ridurre le variazioni di configurazione. Per farlo, State Manager utilizza associazioni. Un' *associazione* è una configurazione che assegni alle risorse AWS . La configurazione definisce lo stato che desideri mantenere sulle risorse. Ad esempio, un'associazione può specificare che il software antivirus debba essere installato ed eseguito su un nodo gestito o che determinate porte debbano essere chiuse.
Un'associazione specifica una pianificazione per quando applicare la configurazione e le destinazioni per l'associazione. Ad esempio, un'associazione per il software antivirus potrebbe essere eseguita una volta al giorno su tutti i nodi gestiti in un account Account AWS. Se il software non è installato su un nodo, l'associazione potrebbe istruire State Manager per installarlo. Se il software è installato, ma il servizio non è in esecuzione, l'associazione potrebbe indicare a State Manager di avviare il servizio.
**avvertimento**
Quando si crea un'associazione, è possibile scegliere un gruppo di AWS risorse di nodi gestiti come destinazione dell'associazione. Se un utente, gruppo o ruolo AWS Identity and Access Management (IAM) è autorizzato a creare un'associazione destinata a un gruppo di risorse di nodi gestiti, tale utente, gruppo o ruolo dispone automaticamente del controllo a livello di root di tutti i nodi del gruppo. Solo gli amministratori attendibili devono essere autorizzati a creare le associazioni.
**Target di associazione e controlli di velocità**
Un'associazione specifica quali nodi gestiti, oppure target, devono ricevere l'associazione. State Manager include diverse funzionalità per aiutarti a scegliere come target i nodi gestiti e controllare come l'associazione viene implementata su tali target. Per ulteriori informazioni sulle destinazioni e sui controlli di velocità, consulta [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
**Associazione dei tag**
È possibile assegnare tag a un'associazione quando la si crea utilizzando uno strumento da riga di comando come o. AWS CLI AWS Strumenti per PowerShell Aggiunta di tag a un'associazione utilizzando la console Systems Manager non è supportata.
**Esecuzione delle associazioni**
Per impostazione predefinita, State Manager esegue un'associazione subito dopo averla creata e successivamente in base alla pianificazione definita.
Il sistema esegue le associazioni anche secondo le seguenti regole:
+ State Manager tenta di eseguire l'associazione su tutte le istanze specificate o di destinazione durante un intervallo.
+ Se un'associazione non viene eseguita durante un intervallo (ad esempio, perché un valore di simultaneità ha limitato il numero di istanze che possono elaborare l'associazione contemporaneamente), State Manager tenta di eseguire l'associazione nell'intervallo successivo.
+ State Manager esegue l'associazione dopo le modifiche alla configurazione, ai nodi target, ai documenti o ai parametri dell'associazione. Per ulteriori informazioni, consulta [Capire quando le associazioni vengono applicate alle risorse](state-manager-about.md#state-manager-about-scheduling)
+ State Manager registra la cronologia per tutti gli intervalli ignorati. È possibile visualizzare la cronologia nella scheda **Cronologia di esecuzione**.
## Pianificazione delle associazioni
È possibile pianificare l'esecuzione delle associazioni a intervalli di base, ad esempio *ogni 10 ore*, oppure creare pianificazioni più avanzate utilizzando espressioni Cron e della frequenza personalizzate. È inoltre possibile impedire l'esecuzione delle associazioni durante la rispettiva creazione.
**Utilizzo di espressioni Cron e della frequenza per pianificare esecuzioni di associazioni**
Oltre alle espressioni Cron o della frequenza standard, State Manager supporta anche le espressioni Cron che includono un giorno della settimana e il segno numerico (\$1), per designare il giorno *n* di un mese necessario per l'esecuzione di un'associazione. Ecco un esempio che esegue un programma cron il terzo martedì di ogni mese alle 23:30 UTC:
`cron(30 23 ? * TUE#3 *)`
Ecco un esempio che viene eseguito il secondo giovedì di ogni mese a mezzanotte UTC:
`cron(0 0 ? * THU#2 *)`
State Manager supporta anche il segno (L) per indicare l'ultimo giorno *X* del mese. Ecco un esempio che esegue un programma cron il terzo martedì di ogni mese a mezzanotte UTC:
`cron(0 0 ? * 3L *)`
Per controllare ulteriormente l'esecuzione di un'associazione, ad esempio se si desidera eseguire un'associazione due giorni dopo la patch di martedì, è possibile specificare un offset. Un record *offset* definisce quanti giorni attendere dopo il giorno programmato per eseguire un'associazione. Ad esempio, se hai specificato un programma cron di `cron(0 0 ? * THU#2 *)`, è possibile specificare il numero 3 nel campo **Offset di pianificazione** per eseguire l'associazione ogni domenica dopo il secondo giovedì del mese.
**Nota**
Per utilizzare gli offset, è necessario scegliere **Applica associazione solo all'intervallo cron specificato successivo** nella console oppure specificare l'uso del parametro `ApplyOnlyAtCronInterval` dalla linea di comando. Quando una di queste opzioni è attivata, State Manager non esegue l'associazione immediatamente dopo la creazione.
Per ulteriori informazioni sulle espressioni Cron e della frequenza, consulta [Riferimento: espressioni Cron e della frequenza per Systems Manager](reference-cron-and-rate-expressions.md).
## Creazione di un'associazione (console)
La procedura seguente descrive come utilizzare la console di Systems Manager per creare un'associazione di State Manager.
**Nota**
Osservare le seguenti informazioni.
Questa procedura descrive come creare un'associazione che utilizza un documento `Command` o `Policy` per i nodi gestiti di destinazione. Per informazioni sulla creazione di un'associazione che utilizza un runbook Automation per indirizzare i nodi o altri tipi di risorse AWS , consulta [Pianificazione di automazioni con associazioni State Manager](scheduling-automations-state-manager-associations.md).
Durante la creazione di un'associazione, è possibile specificare un massimo di cinque chiavi di tag utilizzando la Console di gestione AWS. *Tutte* le chiavi dei tag specificate per l'associazione devono essere attualmente assegnate al nodo. In caso contrario, State Manager non riesce a scegliere il nodo come destinazione per l'associazione.
**Per creare un'associazione di State 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 **State Manager**.
1. Selezionare **Create association (Crea associazione)**.
1. Nel campo **Name (Nome)**, specifica un nome.
1. Nell'elenco **Document (Documenti)**, scegliere l'opzione disponibile accanto al nome del documento. Prendere nota del tipo di documento. Questa procedura si applica solo a documenti `Command` e `Policy`. Per informazioni su come creare un'associazione che utilizza un runbook Automation, consultare [Pianificazione di automazioni con associazioni State Manager](scheduling-automations-state-manager-associations.md).
**Importante**
State Manager non supporta associazioni in esecuzione che utilizzano una nuova versione di un documento se tale documento è condiviso da un altro account. State Manager gestisce sempre la versione `default` di un documento se condivisa da un altro account, anche se la console di Systems Manager mostra che è stata elaborata una nuova versione. Se si desidera eseguire un'associazione utilizzando una nuova versione di un documento condiviso da un altro account, è necessario impostare la versione del documento su `default`.
1. Per **Parameters (Parametri)**, specificare i parametri di input necessari.
1. (Facoltativo) Per **Association Dispatch Assume Role**, seleziona un ruolo dal menu a discesa. State Manager intraprenderà azioni utilizzando questo ruolo per vostro conto. Per informazioni sulla configurazione del ruolo fornito personalizzato, consulta [Imposta i ruoli per `AssociationDispatchAssumeRole`](state-manager-about.md#setup-assume-role)
**Nota**
Si consiglia di definire un ruolo IAM personalizzato in modo da avere il pieno controllo delle autorizzazioni di cui dispone State Manager quando intraprende azioni per conto dell'utente.
Il supporto dei ruoli collegati ai servizi in State Manager viene gradualmente eliminato. Le associazioni che si basano sul ruolo collegato al servizio potrebbero richiedere aggiornamenti in futuro per continuare a funzionare correttamente.
Per informazioni sulla gestione dell'utilizzo del ruolo fornito dall'utente, vedere. [Gestisci l'utilizzo di AssociationDispatchAssumeRole con `ssm:AssociationDispatchAssumeRole`](state-manager-about.md#context-key-assume-role)
1. (Facoltativo) Scegliete un CloudWatch allarme da applicare alla vostra associazione per il monitoraggio.
**Nota**
Prendi nota delle seguenti informazioni importanti relative a questa fase.
L'elenco degli allarmi riporta un massimo di 100 allarmi. Se non vedi il tuo allarme nell'elenco, usa AWS Command Line Interface per creare l'associazione. Per ulteriori informazioni, consulta [Creazione di un'associazione (riga di comando)](#create-state-manager-association-commandline).
Per allegare un CloudWatch allarme al tuo comando, il responsabile IAM che crea l'associazione deve avere l'autorizzazione per l'`iam:createServiceLinkedRole`azione. Per ulteriori informazioni sugli CloudWatch allarmi, consulta [Usare gli CloudWatch allarmi Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Tenere presente che se l'allarme si attiva, qualsiasi automazione o invocazione di comando in sospeso non viene eseguita.
1. Per **Destinazioni**, scegli un'opzione. Per informazioni sull'utilizzo delle destinazioni, consulta [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
**Nota**
Affinché le associazioni create con i runbook Automation vengano applicate quando vengono rilevati nuovi nodi di destinazione, è necessario che vengano soddisfatte determinate condizioni. Per informazioni, consulta [Informazioni sugli aggiornamenti di destinazione con i runbook Automation](state-manager-about.md#runbook-target-updates).
1. Nella sezione **Specify schedule (Specifica pianificazione)**, scegliere **On Schedule (Conforme a pianificazione)** oppure **No schedule (Nessuna pianificazione)**. Se si sceglie **On Schedule (Conforme a pianificazione)**, utilizzare i pulsanti disponibili per creare una pianificazione cron o rate per l'associazione.
Se non si desidera che l'associazione venga eseguita immediatamente dopo averla creata, scegli **Applica associazione solo all'intervallo Cron specificato successivo**.
1. (Facoltativo) Nel campo **Pianificazione offset**, specificare un numero compreso tra 1 e 6.
1. Nella sezione **Advanced options (Opzioni avanzate)** usare **Compliance severity (Gravità della conformità)** per scegliere un livello di gravità per l'associazione e utilizzare **Change Calendars (Modificare i calendari)** per scegliere un calendario di modifica per l'associazione.
Il report di conformità indica se l'associazione è conforme o non conforme e il livello di gravità specificato qui. Per ulteriori informazioni, consulta [Informazioni sulla conformità delle associazioni State Manager](compliance-about.md#compliance-about-association).
Il calendario delle modifiche determina quando l'associazione viene eseguita. Se il calendario è chiuso, l'associazione non viene applicata. Se il calendario è aperto, l'associazione viene di conseguenza eseguita. Per ulteriori informazioni, consulta [AWS Systems Manager Change Calendar](systems-manager-change-calendar.md).
1. Nella sezione **Rate control (Controllo della velocità)** scegli le opzioni per controllare l'esecuzione dell'associazione su più nodi gestiti. 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).
Nella sezione **Simultaneità**, scegli un'opzione:
+ Scegli **destinazioni** per immettere il numero assoluto di destinazioni che possono eseguire contemporaneamente l'associazione.
+ Scegli **percentuale** per immettere la percentuale del set di destinazione che può eseguire contemporaneamente l'associazione.
Nella sezione **Soglia di errore**. scegli un'opzione:
+ Scegli **errori** per immettere il numero assoluto di errori consentiti prima che State Manager arresti l'esecuzione delle associazioni su altre destinazioni.
+ Scegli **percentuale** per immettere una percentuale di errori consentiti prima che State Manager arresti l'esecuzione delle associazioni su altre destinazioni.
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.
Di seguito sono riportate le autorizzazioni minime necessarie per attivare l'output di Amazon S3 per un'associazione. È possibile limitare ulteriormente l'accesso collegando policy IAM a utenti o ruoli all'interno di un account. Come minimo, un profilo dell'istanza Amazon EC2 deve avere un ruolo IAM con la policy gestita `AmazonSSMManagedInstanceCore` e la seguente policy in linea.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
------
Per le autorizzazioni minime, il bucket di Amazon S3 in cui esporti deve disporre delle impostazioni di default definite dalla console di Amazon S3. Per ulteriori informazioni sulla creazione di bucket di Amazon S3, consultare [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) nella *Guida per l'utente di Amazon S3*.
**Nota**
Le operazioni API avviate dal documento SSM durante un'esecuzione di associazione non vengono registrate in AWS CloudTrail.
1. Scegli **Crea associazione**.
**Nota**
Se si elimina l'associazione creata, l'associazione non viene più eseguita sulle destinazioni di tale associazione.
## Creazione di un'associazione (riga di comando)
La procedura seguente descrive come utilizzare AWS CLI (su Linux oWindows Server) o Tools per PowerShell creare un'State Managerassociazione. In questa sezione sono inclusi diversi esempi che illustrano come utilizzare le destinazioni e i controlli di velocità. Le destinazioni e i controlli di velocità consentono di assegnare un'associazione a decine o centinaia di istanze controllando al contempo l'esecuzione di tali associazioni. Per ulteriori informazioni sulle destinazioni e sui controlli di velocità, consulta [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
**Importante**
Questa procedura descrive come creare un'associazione che utilizza un documento `Command` o `Policy` per i nodi gestiti di destinazione. Per informazioni sulla creazione di un'associazione che utilizza un runbook di automazione per indirizzare nodi o altri tipi di AWS risorse, vedere[Pianificazione di automazioni con associazioni State Manager](scheduling-automations-state-manager-associations.md).
**Prima di iniziare**
Il parametro `targets` è un array di criteri di ricerca che definisce le istanze come destinazioni mediante una combinazione `Key``Value` specificata. Se si prevede di creare un'associazione su decine o centinaia di istanze utilizzando il parametro `targets`, esaminare le seguenti opzioni di destinazione prima di iniziare la procedura.
Indirizza nodi specifici specificando IDs
```
--targets Key=InstanceIds,Values=instance-id-1,instance-id-2,instance-id-3
```
```
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE,i-07782c72faEXAMPLE
```
Definire come destinazione le istanze utilizzando i tag
```
--targets Key=tag:tag-key,Values=tag-value-1,tag-value-2,tag-value-3
```
```
--targets Key=tag:Environment,Values=Development,Test,Pre-production
```
Indirizza i nodi utilizzando AWS Resource Groups
```
--targets Key=resource-groups:Name,Values=resource-group-name
```
```
--targets Key=resource-groups:Name,Values=WindowsInstancesGroup
```
Scegli come target tutte le istanze nella versione corrente Account AWS e Regione AWS
```
--targets Key=InstanceIds,Values=*
```
**Nota**
Osservare le seguenti informazioni.
State Manager non supporta associazioni in esecuzione che utilizzano una nuova versione di un documento se tale documento è condiviso da un altro account. State Manager gestisce sempre la versione `default` di un documento se condivisa da un altro account, anche se la console di Systems Manager mostra che è stata elaborata una nuova versione. Se si desidera eseguire un'associazione utilizzando una nuova versione di un documento condiviso da un altro account, è necessario impostare la versione del documento su `default`.
State Managernon supporta`IncludeChildOrganizationUnits`,`ExcludeAccounts`,`TargetsMaxErrors`, `TargetsMaxConcurrency``Targets`, `TargetLocationAlarmConfiguration` parametri per [TargetLocation](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TargetLocation.html).
È possibile specificare un massimo di cinque chiavi di tag utilizzando la AWS CLI. Se si utilizza AWS CLI, *tutte le* chiavi dei tag specificate nel `create-association` comando devono essere attualmente assegnate al nodo. In caso contrario, State Manager non riesce a scegliere il nodo come destinazione per un'associazione.
Quando crei un'associazione, specifica quando eseguire la pianificazione. Specificare la pianificazione utilizzando un'espressione Cron o della frequenza. Per ulteriori informazioni sulle espressioni Cron e della frequenza, consulta [Espressioni Cron e della frequenza per le associazioni](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association).
Affinché le associazioni create con i runbook Automation vengano applicate quando vengono rilevati nuovi nodi di destinazione, è necessario che vengano soddisfatte determinate condizioni. Per informazioni, consulta [Informazioni sugli aggiornamenti di destinazione con i runbook Automation](state-manager-about.md#runbook-target-updates).
**Per creare un'associazione**
1. Installa e configura il AWS CLI o il AWS Strumenti per PowerShell, se non l'hai già fatto.
Per informazioni, consulta le pagine [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Installazione di AWS Strumenti per PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Usa il seguente formato per creare un comando che crea un'associazione State Manager. Sostituisci ogni *example resource placeholder* con le tue informazioni.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name document_name \
--document-version version_of_document_applied \
--instance-id instances_to_apply_association_on \
--parameters (if any) \
--targets target_options \
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations \
--schedule-expression "cron_or_rate_expression" \
--apply-only-at-cron-interval required_parameter_for_schedule_offsets \
--schedule-offset number_between_1_and_6 \
--output-location s3_bucket_to_store_output_details \
--association-name association_name \
--max-errors a_number_of_errors_or_a_percentage_of_target_set \
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set \
--compliance-severity severity_level \
--calendar-names change_calendar_names \
--target-locations aws_region_or_account \
--tags "Key=tag_key,Value=tag_value"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name document_name ^
--document-version version_of_document_applied ^
--instance-id instances_to_apply_association_on ^
--parameters (if any) ^
--targets target_options ^
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations ^
--schedule-expression "cron_or_rate_expression" ^
--apply-only-at-cron-interval required_parameter_for_schedule_offsets ^
--schedule-offset number_between_1_and_6 ^
--output-location s3_bucket_to_store_output_details ^
--association-name association_name ^
--max-errors a_number_of_errors_or_a_percentage_of_target_set ^
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set ^
--compliance-severity severity_level ^
--calendar-names change_calendar_names ^
--target-locations aws_region_or_account ^
--tags "Key=tag_key,Value=tag_value"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-Name document_name `
-DocumentVersion version_of_document_applied `
-InstanceId instances_to_apply_association_on `
-Parameters (if any) `
-Target target_options `
-AssociationDispatchAssumeRole arn_of_role_to_be_used_when_dispatching_configurations `
-ScheduleExpression "cron_or_rate_expression" `
-ApplyOnlyAtCronInterval required_parameter_for_schedule_offsets `
-ScheduleOffSet number_between_1_and_6 `
-OutputLocation s3_bucket_to_store_output_details `
-AssociationName association_name `
-MaxError a_number_of_errors_or_a_percentage_of_target_set
-MaxConcurrency a_number_of_instances_or_a_percentage_of_target_set `
-ComplianceSeverity severity_level `
-CalendarNames change_calendar_names `
-TargetLocations aws_region_or_account `
-Tags "Key=tag_key,Value=tag_value"
```
------
L'esempio seguente crea un'associazione sulle istanze con il tag `"Environment,Linux"`. L'associazione usa il documento `AWS-UpdateSSMAgent` per aggiornare SSM Agent sui nodi target alle 2:00 ogni domenica mattina. Questa associazione viene eseguita contemporaneamente su un massimo di 10 nodi in qualsiasi momento. Inoltre, l'esecuzione dell'associazione viene arrestata su più nodi durante un determinato intervallo di esecuzione se il conteggio degli errori restituiti supera 5. Per la creazione di report di conformità, a questa associazione viene assegnato un livello di gravità Medium (Medio).
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--targets Key=tag:Environment,Values=Linux \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN *)" \
--max-errors "5" \
--max-concurrency "10"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--targets Key=tag:Environment,Values=Linux ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--max-errors "5" ^
--max-concurrency "10"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_Linux `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="tag:Environment"
"Values"="Linux"
} `
-ComplianceSeverity MEDIUM `
-ScheduleExpression "cron(0 2 ? * SUN *)" `
-MaxConcurrency 10 `
-MaxError 5
```
------
L'esempio seguente si rivolge al nodo IDs specificando un valore jolly (\$1). Ciò consente a Systems Manager di creare un'associazione su *tutti* i nodi dell'attuale Account AWS e Regione AWS. Questa associazione viene eseguita contemporaneamente su un massimo di 10 nodi in qualsiasi momento. Inoltre, l'esecuzione dell'associazione viene arrestata su più nodi durante un determinato intervallo di esecuzione se il conteggio degli errori restituiti supera 5. Per la creazione di report di conformità, a questa associazione viene assegnato un livello di gravità Medium (Medio). Questa associazione utilizza un offset di pianificazione, il che significa che viene eseguito due giorni dopo la pianificazione cron specificata. Include anche il parametro `ApplyOnlyAtCronInterval`, che è necessario per utilizzare l'offset della pianificazione e il che significa che l'associazione non verrà eseguita immediatamente dopo la creazione.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--name "AWS-UpdateSSMAgent" \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--targets "Key=instanceids,Values=*" \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN#2 *)" \
--apply-only-at-cron-interval \
--schedule-offset 2 \
--max-errors "5" \
--max-concurrency "10" \
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--name "AWS-UpdateSSMAgent" ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--targets "Key=instanceids,Values=*" ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN#2 *)" ^
--apply-only-at-cron-interval ^
--schedule-offset 2 ^
--max-errors "5" ^
--max-concurrency "10" ^
--apply-only-at-cron-interval
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_All `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="InstanceIds"
"Values"="*"
} `
-ScheduleExpression "cron(0 2 ? * SUN#2 *)" `
-ApplyOnlyAtCronInterval `
-ScheduleOffset 2 `
-MaxConcurrency 10 `
-MaxError 5 `
-ComplianceSeverity MEDIUM `
-ApplyOnlyAtCronInterval
```
------
L'esempio seguente crea un'associazione sui nodi in Resource Groups. Il gruppo è denominato "HR-Department". L'associazione usa il documento `AWS-UpdateSSMAgent` per aggiornare SSM Agent sui nodi target alle 2:00 ogni domenica mattina. Questa associazione viene eseguita contemporaneamente su un massimo di 10 nodi in qualsiasi momento. Inoltre, l'esecuzione dell'associazione viene arrestata su più nodi durante un determinato intervallo di esecuzione se il conteggio degli errori restituiti supera 5. Per la creazione di report di conformità, a questa associazione viene assegnato un livello di gravità Medium (Medio). Questa associazione viene eseguita nella pianificazione Cron specificata. Non viene eseguita immediatamente dopo la creazione dell'associazione.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--targets Key=resource-groups:Name,Values=HR-Department \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN *)" \
--max-errors "5" \
--max-concurrency "10" \
--apply-only-at-cron-interval
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--targets Key=resource-groups:Name,Values=HR-Department ^
--name AWS-UpdateSSMAgent ^
-association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--max-errors "5" ^
--max-concurrency "10" ^
--apply-only-at-cron-interval
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_Linux `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="resource-groups:Name"
"Values"="HR-Department"
} `
-ScheduleExpression "cron(0 2 ? * SUN *)" `
-MaxConcurrency 10 `
-MaxError 5 `
-ComplianceSeverity MEDIUM `
-ApplyOnlyAtCronInterval
```
------
Nell'esempio seguente viene creata un'associazione che viene eseguita sui nodi con il tag di un ID di nodo specifico. L'associazione utilizza il documento di SSM Agent per aggiornare SSM Agent sui nodi di destinazione una volta quando il calendario delle modifiche è aperto. L'associazione controlla lo stato del calendario durante l'esecuzione. Se il calendario viene chiuso al momento dell'avvio e l'associazione viene eseguita una sola volta, non verrà eseguito più perché la finestra di esecuzione dell'associazione è passata. Se il calendario è aperto, l'associazione viene di conseguenza eseguita.
**Nota**
Se si aggiungono nuovi nodi ai tag o ai gruppi di risorse su cui agisce un'associazione quando il calendario delle modifiche è chiuso, l'associazione viene applicata a tali nodi una volta aperto il calendario delle modifiche.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name CalendarAssociation \
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" \
--schedule-expression "rate(1day)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name CalendarAssociation ^
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" ^
--schedule-expression "rate(1day)"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName CalendarAssociation `
-Target @{
"Key"="tag:instanceids"
"Values"="i-0cb2b964d3e14fd9f"
} `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" `
-ScheduleExpression "rate(1day)"
```
------
Nell'esempio seguente viene creata un'associazione che viene eseguita sui nodi con il tag di un ID di nodo specifico. L'associazione usa il documento SSM Agent per aggiornare SSM Agent sui nodi target ogni domenica mattina alle 2:00. Questa associazione viene eseguita solo nella pianificazione Cron specificata quando il calendario delle modifiche è aperto. Quando viene creata, l'associazione controlla lo stato del calendario. Se il calendario è chiuso, l'associazione non viene applicata. Quando l'intervallo di applicazione dell'associazione inizia alle 2:00 di domenica, l'associazione verifica se il calendario è aperto. Se il calendario è aperto, l'associazione viene di conseguenza eseguita.
**Nota**
Se si aggiungono nuovi nodi ai tag o ai gruppi di risorse su cui agisce un'associazione quando il calendario delle modifiche è chiuso, l'associazione viene applicata a tali nodi una volta aperto il calendario delle modifiche.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name MultiCalendarAssociation \
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name MultiCalendarAssociation ^
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName MultiCalendarAssociation `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="tag:instanceids"
"Values"="i-0cb2b964d3e14fd9f"
} `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" `
-ScheduleExpression "cron(0 2 ? * SUN *)"
```
------
**Nota**
Se si elimina l'associazione creata, l'associazione non viene più eseguita sulle destinazioni di tale associazione. Inoltre, se è stato specificato il parametro `apply-only-at-cron-interval`, è possibile reimpostare questa opzione. A tale scopo, specificare il parametro `no-apply-only-at-cron-interval` quando si aggiorna l'associazione dalla riga di comando. Questo parametro forza l'esecuzione dell'associazione immediatamente dopo l'aggiornamento dell'associazione e in base all'intervallo specificato.
# Modifica e creazione di una nuova versione di un'associazione
È possibile modificare un'associazione di State Manager per specificare un nome, una pianificazione, un livello di gravità, destinazioni e nuovi valori. Per le associazioni basate su documenti di tipo SSM Command, è inoltre possibile scegliere di scrivere l'output del comando in un bucket Amazon Simple Storage Service (Amazon S3). Dopo la modifica di un'associazione, State Manager crea una nuova versione. È possibile visualizzare diverse versioni dopo la modifica, come descritto nelle procedure seguenti.
**Nota**
Affinché le associazioni create con i runbook Automation vengano applicate quando vengono rilevati nuovi nodi di destinazione, è necessario che vengano soddisfatte determinate condizioni. Per informazioni, consulta [Informazioni sugli aggiornamenti di destinazione con i runbook Automation](state-manager-about.md#runbook-target-updates).
Le procedure seguenti descrivono come modificare e creare una nuova versione di un'associazione utilizzando la console Systems Manager, AWS Command Line Interface (AWS CLI) e AWS Strumenti per PowerShell (Tools for PowerShell).
**Importante**
State Manager non supporta associazioni in esecuzione che utilizzano una nuova versione di un documento se tale documento è condiviso da un altro account. State Manager gestisce sempre la versione `default` di un documento se condivisa da un altro account, anche se la console di Systems Manager mostra che è stata elaborata una nuova versione. Se si desidera eseguire un'associazione utilizzando una nuova versione di un documento condiviso da un altro account, è necessario impostare la versione del documento su `default`.
## Modifica di un'associazione (console)
La procedura seguente descrive come utilizzare la console di Systems Manager per modificare e creare una nuova versione di un'associazione.
**Nota**
Per le associazioni che utilizzano documenti SSM Command e non runbook Automation, per svolgere questa procedura è necessario disporre dell'accesso in scrittura a un bucket Amazon S3 esistente. Se non hai mai utilizzato Amazon S3, tieni presente che ti saranno addebitati costi per l'utilizzo. Per informazioni su come creare un bucket, consulta [Crea un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html).
**Per modificare un'associazione di State Manager**
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 **State Manager**.
1. Scegliere un'associazione esistente, quindi **Modifica**.
1. Riconfigurare l'associazione per soddisfare i requisiti correnti.
Per informazioni sulle opzioni di associazione sui documenti `Command` e `Policy`, consulta [Creazione di associazioni](state-manager-associations-creating.md). Per informazioni sulle opzioni di associazione con i runbook Automation, consulta [Pianificazione di automazioni con associazioni State Manager](scheduling-automations-state-manager-associations.md).
1. Scegli **Salva modifiche**.
1. (Facoltativo) Per visualizzare le informazioni sull'associazione, nella pagina **Associations (Associazioni)**, scegliere il nome dell'associazione modificata, quindi selezionare la scheda **Versions (Versioni)**. Il sistema elenca tutte le versioni dell'associazione create e modificate.
1. (Facoltativo) Per visualizzare l'output delle associazioni basate su documenti SSM `Command`, procedi come segue:
1. Apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Scegliere il nome del bucket Amazon S3 specificato per archiviare l'output del comando, quindi selezionare la cartella denominata con l'ID del nodo che ha eseguito l'associazione. Se è stato scelto di archiviare l'output in una cartella del bucket, aprire innanzitutto tale cartella.
1. Eseguire il drill-down su diversi livelli nella cartella `awsrunPowerShell` fino al file `stdout`.
1. Per visualizzare il nome host, scegliere **Open (Apri)** o **Download (Scarica)**.
## Modifica di un'associazione (riga di comando)
La procedura seguente descrive come utilizzare AWS CLI (su Linux oWindows Server) o AWS Strumenti per PowerShell modificare e creare una nuova versione di un'associazione.
**Per modificare un'associazione di State Manager**
1. Installa e configura il AWS CLI o il AWS Strumenti per PowerShell, se non l'hai già fatto.
Per informazioni, consulta le pagine [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Installazione di AWS Strumenti per PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Utilizza il formato seguente per creare un comando per modificare e creare una nuova versione di un'associazione State Manager esistente. Sostituisci ogni *example resource placeholder* con le tue informazioni.
**Importante**
Quando chiami `[https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html)`, il sistema elimina tutti i parametri opzionali dalla richiesta e sovrascrive l'associazione con valori nulli per tali parametri. Si tratta di un'impostazione predefinita. È necessario specificare tutti i parametri opzionali nella chiamata, anche se non si modificano i parametri. Questo include il parametro `--name`. Prima di chiamare questa azione, consigliamo di chiamare l'operazione `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html)` e prendere nota di tutti i parametri opzionali richiesti per la chiamata `update-association`.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--name document_name \
--document-version version_of_document_applied \
--instance-id instances_to_apply_association_on \
--parameters (if any) \
--targets target_options \
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations \
--schedule-expression "cron_or_rate_expression" \
--schedule-offset "number_between_1_and_6" \
--output-location s3_bucket_to_store_output_details \
--association-name association_name \
--max-errors a_number_of_errors_or_a_percentage_of_target_set \
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set \
--compliance-severity severity_level \
--calendar-names change_calendar_names \
--target-locations aws_region_or_account
```
------
#### [ Windows ]
```
aws ssm update-association ^
--name document_name ^
--document-version version_of_document_applied ^
--instance-id instances_to_apply_association_on ^
--parameters (if any) ^
--targets target_options ^
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations ^
--schedule-expression "cron_or_rate_expression" ^
--schedule-offset "number_between_1_and_6" ^
--output-location s3_bucket_to_store_output_details ^
--association-name association_name ^
--max-errors a_number_of_errors_or_a_percentage_of_target_set ^
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set ^
--compliance-severity severity_level ^
--calendar-names change_calendar_names ^
--target-locations aws_region_or_account
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-Name document_name `
-DocumentVersion version_of_document_applied `
-InstanceId instances_to_apply_association_on `
-Parameters (if any) `
-Target target_options `
-AssociationDispatchAssumeRole arn_of_role_to_be_used_when_dispatching_configurations `
-ScheduleExpression "cron_or_rate_expression" `
-ScheduleOffset "number_between_1_and_6" `
-OutputLocation s3_bucket_to_store_output_details `
-AssociationName association_name `
-MaxError a_number_of_errors_or_a_percentage_of_target_set
-MaxConcurrency a_number_of_instances_or_a_percentage_of_target_set `
-ComplianceSeverity severity_level `
-CalendarNames change_calendar_names `
-TargetLocations aws_region_or_account
```
------
L'esempio seguente aggiorna un'associazione esistente per modificare il nome in `TestHostnameAssociation2`. La nuova versione di associazione viene eseguita ogni ora e scrive l'output dei comandi nel bucket Amazon S3 specificato.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name TestHostnameAssociation2 \
--parameters commands="echo Association" \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--schedule-expression "cron(0 */1 * * ? *)"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name TestHostnameAssociation2 ^
--parameters commands="echo Association" ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--schedule-expression "cron(0 */1 * * ? *)"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName TestHostnameAssociation2 `
-Parameter @{"commands"="echo Association"} `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-S3Location_OutputS3KeyPrefix logs `
-S3Location_OutputS3Region us-east-1 `
-ScheduleExpression "cron(0 */1 * * ? *)"
```
------
L'esempio seguente aggiorna un'associazione esistente per modificare il nome in `CalendarAssociation`. La nuova associazione viene eseguita quando il calendario è aperto e scrive l'output del comando nel bucket Amazon S3 specificato.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name CalendarAssociation \
--parameters commands="echo Association" \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name CalendarAssociation ^
--parameters commands="echo Association" ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName CalendarAssociation `
-AssociationName OneTimeAssociation `
-Parameter @{"commands"="echo Association"} `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
L'esempio seguente aggiorna un'associazione esistente per modificare il nome in `MultiCalendarAssociation`. La nuova associazione viene eseguita quando i calendari sono aperti e scrive l'output del comando nel bucket Amazon S3 specificato.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name MultiCalendarAssociation \
--parameters commands="echo Association" \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name MultiCalendarAssociation ^
--parameters commands="echo Association" ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName MultiCalendarAssociation `
-Parameter @{"commands"="echo Association"} `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
1. Per visualizzare la nuova versione dell'associazione, esegui il comando seguente.
------
#### [ Linux & macOS ]
```
aws ssm describe-association \
--association-id b85ccafe-9f02-4812-9b81-01234EXAMPLE
```
------
#### [ Windows ]
```
aws ssm describe-association ^
--association-id b85ccafe-9f02-4812-9b81-01234EXAMPLE
```
------
#### [ PowerShell ]
```
Get-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE | Select-Object *
```
------
Il sistema restituisce informazioni simili alle seguenti.
------
#### [ Linux & macOS ]
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 */1 * * ? *)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "logs",
"OutputS3BucketName": "amzn-s3-demo-bucket",
"OutputS3Region": "us-east-1"
}
},
"Name": "AWS-RunPowerShellScript",
"Parameters": {
"commands": [
"echo Association"
]
},
"LastExecutionDate": 1559316400.338,
"Overview": {
"Status": "Success",
"DetailedStatus": "Success",
"AssociationStatusAggregatedCount": {}
},
"AssociationId": "b85ccafe-9f02-4812-9b81-01234EXAMPLE",
"DocumentVersion": "$DEFAULT",
"LastSuccessfulExecutionDate": 1559316400.338,
"LastUpdateAssociationDate": 1559316389.753,
"Date": 1559314038.532,
"AssociationVersion": "2",
"AssociationName": "TestHostnameAssociation2",
"Targets": [
{
"Values": [
"Windows"
],
"Key": "tag:Environment"
}
]
}
}
```
------
#### [ Windows ]
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 */1 * * ? *)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "logs",
"OutputS3BucketName": "amzn-s3-demo-bucket",
"OutputS3Region": "us-east-1"
}
},
"Name": "AWS-RunPowerShellScript",
"Parameters": {
"commands": [
"echo Association"
]
},
"LastExecutionDate": 1559316400.338,
"Overview": {
"Status": "Success",
"DetailedStatus": "Success",
"AssociationStatusAggregatedCount": {}
},
"AssociationId": "b85ccafe-9f02-4812-9b81-01234EXAMPLE",
"DocumentVersion": "$DEFAULT",
"LastSuccessfulExecutionDate": 1559316400.338,
"LastUpdateAssociationDate": 1559316389.753,
"Date": 1559314038.532,
"AssociationVersion": "2",
"AssociationName": "TestHostnameAssociation2",
"Targets": [
{
"Values": [
"Windows"
],
"Key": "tag:Environment"
}
]
}
}
```
------
#### [ PowerShell ]
```
AssociationId : b85ccafe-9f02-4812-9b81-01234EXAMPLE
AssociationName : TestHostnameAssociation2
AssociationVersion : 2
AutomationTargetParameterName :
ComplianceSeverity :
Date : 5/31/2019 2:47:18 PM
DocumentVersion : $DEFAULT
InstanceId :
LastExecutionDate : 5/31/2019 3:26:40 PM
LastSuccessfulExecutionDate : 5/31/2019 3:26:40 PM
LastUpdateAssociationDate : 5/31/2019 3:26:29 PM
MaxConcurrency :
MaxErrors :
Name : AWS-RunPowerShellScript
OutputLocation : Amazon.SimpleSystemsManagement.Model.InstanceAssociationOutputLocation
Overview : Amazon.SimpleSystemsManagement.Model.AssociationOverview
Parameters : {[commands, Amazon.Runtime.Internal.Util.AlwaysSendList`1[System.String]]}
ScheduleExpression : cron(0 */1 * * ? *)
Status :
Targets : {tag:Environment}
```
------
# Eliminazione di associazioni
Utilizza la procedura seguente per eliminare un'associazione mediante la console AWS Systems Manager .
**Per eliminare un'associazione**
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 **State Manager**.
1. Seleziona un'associazione e scegli **Elimina**.
È possibile eliminare più associazioni in un'unica operazione eseguendo un'automazione dalla AWS Systems Manager console. Quando si selezionano più associazioni da eliminare, State Manager avvia la pagina iniziale del runbook di automazione con l'associazione IDs inserita come valori dei parametri di input.
**Per eliminare più associazioni in un'unica operazione**
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 **State Manager**.
1. Selezionare ogni associazione che si desidera eliminare e scegliere **Elimina**.
1. (Facoltativo) Nell'area **Parametri di input aggiuntivi**, seleziona il nome della risorsa Amazon (ARN) per il *ruolo di assunzione* che desideri venga utilizzato dall'automazione durante l'esecuzione. Per creare un nuovo ruolo, selezionare **Crea**.
1. Seleziona **Invia**.
# Esecuzione dei gruppi Auto Scaling con associazioni
La best practice nell'utilizzo di associazioni per l'esecuzione di gruppi Auto Scaling è utilizzare destinazioni con tag. Il mancato utilizzo di tag potrebbe causare il raggiungimento del limite di associazione.
Se tutti i nodi sono contrassegnati con la stessa chiave e lo stesso valore, è necessaria una sola associazione per eseguire il gruppo Auto Scaling. La procedura seguente descrive come creare tale associazione.
**Per creare un'associazione che esegua gruppi Auto Scaling**
1. Assicurati che tutti i nodi del gruppo Auto Scaling siano contrassegnati con la stessa chiave e lo stesso valore. Per ulteriori istruzioni su come assegnare tag ai nodi, consulta [Assegnazione dei tag ai gruppi Auto Scaling e alle istanze](https://docs.aws.amazon.com//autoscaling/ec2/userguide/autoscaling-tagging.html) nella *Guida per l'utente di AWS Auto Scaling *.
1. Creare un'associazione utilizzando la procedura descritta in [Utilizzo delle associazioni in Systems Manager](state-manager-associations.md).
Se si sta lavorando nella console, scegliere **Specifica tag delle istanze** nel campo **Targets (Destinazioni)**. In **Tag di istanza**, immetti la chiave e il valore del **tag** per il gruppo Auto Scaling.
Se stai usando il AWS Command Line Interface (AWS CLI), specifica `--targets Key=tag:tag-key,Values=tag-value` dove la chiave e il valore corrispondono a ciò con cui hai taggato i tuoi nodi.
# Visualizzazione della cronologia delle associazioni
È possibile visualizzare tutte le esecuzioni per un ID di associazione specifico utilizzando l'operazione [DescribeAssociationExecutions](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutions.html)API. Utilizzare questa operazione per vedere lo stato e i relativi dettagli, i risultati, l'ora dell'ultima esecuzione e altre informazioni per un'associazione State Manager. State Manager è uno strumento di AWS Systems Manager. L'operazione API include inoltre filtri che consentono di individuare le associazioni in base ai criteri specificati. Ad esempio, è possibile specificare una data e un'ora esatte e utilizzare il filtro GREATER\$1THAN per visualizzare le esecuzioni elaborate dopo la data e l'ora specificate.
Se, ad esempio, l'esecuzione di un'associazione non è riuscita, puoi approfondire i dettagli di un'esecuzione specifica utilizzando l'operazione [DescribeAssociationExecutionTargets](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutionTargets.html)API. Questa operazione mostra le risorse, ad esempio il nodo IDs, in cui è stata eseguita l'associazione e i vari stati dell'associazione. Puoi quindi visualizzare la risorsa o il nodo che non è riuscito a eseguire un'associazione. Mediante l'ID risorsa puoi visualizzare i dettagli di esecuzione del comando per vedere quale passaggio del comando ha avuto esito negativo.
Gli esempi in questa sezione includono anche informazioni su come utilizzare l'operazione [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html)API per eseguire un'associazione una sola volta al momento della creazione. Puoi utilizzare questa operazione API per esaminare le esecuzioni di associazioni con esito negativo. Se vedi un'associazione non riuscita, puoi modificare la risorsa ed eseguire immediatamente l'associazione per verificare se la modifica alla risorsa consente la corretta esecuzione dell'associazione.
**Nota**
Le operazioni API avviate dal documento SSM durante un'esecuzione di associazione non vengono registrate in AWS CloudTrail.
## Visualizzazione della cronologia delle associazioni (console)
Segui la procedura riportata sotto per visualizzare la cronologia delle esecuzioni di un ID associazione specifico e visualizzare i dettagli delle esecuzioni per una o più risorse.
**Per visualizzare la cronologia di esecuzioni per un ID associazione specifico**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Scegli **State Manager**.
1. Nel campo **ID associazione**, scegli un'associazione di cui si desidera visualizzare la cronologia.
1. Selezionare il pulsante **View details (Visualizza dettagli)**.
1. Scegliere la scheda **Cronologia delle esecuzioni**.
1. Scegliere un'associazione di cui si desidera visualizzare i dettagli delle esecuzioni a livello di risorsa. Ad esempio, scegliere un'associazione che mostri uno stato **Failed (Non riuscito)**. È possibile quindi visualizzare i dettagli delle esecuzioni per i nodi che non sono riusciti a eseguire l'associazione.
Utilizzare i filtri della casella di ricerca per individuare l'esecuzione di cui visualizzare i dettagli.
![\[Filtraggio dell'elenco delle esecuzioni di associazioni State Manager\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/sysman-state-executions-filter.png)
1. Scegliere un ID di esecuzione. Viene aperta la pagina **Association execution targets (Target di esecuzione dell'associazione**. In questa pagina sono mostrate tutte le risorse che hanno eseguito l'associazione.
1. Scegliere un ID risorsa per visualizzare informazioni specifiche sulla risorsa.
Utilizzare i filtri della casella di ricerca per individuare la risorsa di cui visualizzare i dettagli.
![\[Filtraggio dell'elenco di target delle esecuzioni di associazioni State Manager.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/sysman-state-executions-targets-filter.png)
1. Se si sta esaminando un'associazione che non è stato possibile eseguire, è possibile utilizzare il pulsante **Apply association now (Applica associazione)** per eseguire un'associazione una volta al momento della creazione. Dopo avere effettuato le modifiche alla risorsa in cui non è stato possibile eseguire l'associazione, scegliere il collegamento **Association ID (ID associazione)** nel percorso di navigazione.
1. Scegliere il pulsante **Apply association now (Applica associazione)**. Dopo il completamento dell'esecuzione, verificare che l'associazione sia stata eseguita correttamente.
## Visualizzazione della cronologia delle associazioni (riga di comando)
La procedura seguente descrive come utilizzare AWS Command Line Interface (AWS CLI) (su Linux oWindows Server) o AWS Strumenti per PowerShell visualizzare la cronologia di esecuzione per un ID di associazione specifico. In seguito, la procedura descrive come visualizzare i dettagli di esecuzione per una o più risorse.
**Per visualizzare la cronologia di esecuzioni per un ID associazione specifico**
1. Installa e configura il AWS CLI o il AWS Strumenti per PowerShell, se non l'hai già fatto.
Per informazioni, consulta le pagine [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Installazione di AWS Strumenti per PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Eseguire il comando riportato sotto per visualizzare un elenco di esecuzioni per un ID associazione specifico.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**Nota**
Questo comando include un filtro per limitare i risultati solo alle esecuzioni che si sono verificate dopo una data e un'ora specifiche. Per visualizzare tutte le esecuzioni per un determinato ID associazione, rimuovere il parametro `--filters` e il valore ` Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN`.
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**Nota**
Questo comando include un filtro per limitare i risultati solo alle esecuzioni che si sono verificate dopo una data e un'ora specifiche. Per visualizzare tutte le esecuzioni per un determinato ID associazione, rimuovere il parametro `--filters` e il valore ` Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN`.
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId ID `
-Filter @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}
```
**Nota**
Questo comando include un filtro per limitare i risultati solo alle esecuzioni che si sono verificate dopo una data e un'ora specifiche. Per visualizzare tutte le esecuzioni per un determinato ID associazione, rimuovere il parametro `-Filter` e il valore ` @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}`.
------
Il sistema restituisce informazioni simili alle seguenti.
------
#### [ Linux & macOS ]
```
{
"AssociationExecutions":[
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"76a5a04f-caf6-490c-b448-92c02EXAMPLE",
"CreatedTime":1523986028.219,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"791b72e0-f0da-4021-8b35-f95dfEXAMPLE",
"CreatedTime":1523984226.074,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"ecec60fa-6bb0-4d26-98c7-140308EXAMPLE",
"CreatedTime":1523982404.013,
"AssociationVersion":"1"
}
]
}
```
------
#### [ Windows ]
```
{
"AssociationExecutions":[
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"76a5a04f-caf6-490c-b448-92c02EXAMPLE",
"CreatedTime":1523986028.219,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"791b72e0-f0da-4021-8b35-f95dfEXAMPLE",
"CreatedTime":1523984226.074,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"ecec60fa-6bb0-4d26-98c7-140308EXAMPLE",
"CreatedTime":1523982404.013,
"AssociationVersion":"1"
}
]
}
```
------
#### [ PowerShell ]
```
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/18/2019 2:00:50 AM
DetailedStatus : Success
ExecutionId : 76a5a04f-caf6-490c-b448-92c02EXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/11/2019 2:00:54 AM
DetailedStatus : Success
ExecutionId : 791b72e0-f0da-4021-8b35-f95dfEXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/4/2019 2:01:00 AM
DetailedStatus : Success
ExecutionId : ecec60fa-6bb0-4d26-98c7-140308EXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
```
------
È possibile limitare i risultati utilizzando uno o più filtri. L'esempio seguente restituisce tutte le associazioni eseguite prima di una data e un'ora specifiche.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=LESS_THAN
```
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=LESS_THAN
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-Filter @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="LESS_THAN"}
```
------
L'esempio seguente restituisce tutte le associazioni eseguite *correttamente* dopo una data e un'ora specifiche.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN Key=Status,Value=Success,Type=EQUAL
```
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN Key=Status,Value=Success,Type=EQUAL
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-Filter @{
"Key"="CreatedTime";
"Value"="2019-06-01T19:15:38.372Z";
"Type"="GREATER_THAN"
},
@{
"Key"="Status";
"Value"="Success";
"Type"="EQUAL"
}
```
------
1. Eseguire il comando riportato seguente per visualizzare tutti i target in cui l'associazione specifica è stata eseguita.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE
```
------
È possibile limitare i risultati utilizzando uno o più filtri. L'esempio seguente restituisce informazioni su tutti i target in cui l'associazione specifica non è stata eseguita.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID \
--filters Key=Status,Value="Failed"
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID ^
--filters Key=Status,Value="Failed"
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE `
-Filter @{
"Key"="Status";
"Value"="Failed"
}
```
------
L'esempio seguente restituisce informazioni su un nodo gestito specifico in cui un'associazione non è stata eseguita.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID \
--filters Key=Status,Value=Failed Key=ResourceId,Value="i-02573cafcfEXAMPLE" Key=ResourceType,Value=ManagedInstance
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID ^
--filters Key=Status,Value=Failed Key=ResourceId,Value="i-02573cafcfEXAMPLE" Key=ResourceType,Value=ManagedInstance
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE `
-Filter @{
"Key"="Status";
"Value"="Success"
},
@{
"Key"="ResourceId";
"Value"="i-02573cafcfEXAMPLE"
},
@{
"Key"="ResourceType";
"Value"="ManagedInstance"
}
```
------
1. Se stai esaminando un'associazione che non è riuscita a funzionare, puoi utilizzare l'operazione [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html)API per eseguire un'associazione immediatamente e solo una volta. Dopo aver modificato la risorsa in cui non è stato possibile eseguire l'associazione, eseguire il comando riportato sotto per eseguire l'associazione immediatamente e una sola volta.
------
#### [ Linux & macOS ]
```
aws ssm start-associations-once \
--association-id ID
```
------
#### [ Windows ]
```
aws ssm start-associations-once ^
--association-id ID
```
------
#### [ PowerShell ]
```
Start-SSMAssociationsOnce `
-AssociationId ID
```
------
# Utilizzo delle associazioni tramite IAM
State Manager, uno strumento in AWS Systems Manager, utilizza [gli obiettivi](systems-manager-state-manager-targets-and-rate-controls.md#systems-manager-state-manager-targets-and-rate-controls-about-targets) per scegliere con quali istanze configurare le associazioni. Originariamente, le associazioni venivano create specificando un nome di documento (`Name`) e un ID di istanza (`InstanceId`). In questo modo è stata creata un'associazione tra un documento e un'istanza o nodo gestito. Le associazioni erano identificate da questi parametri. Questi parametri sono ora obsoleti, ma sono comunque supportati. Le risorse`instance`e`managed-instance`sono stati aggiunti come risorse alle azioni con`Name`e`InstanceId`.
AWS Identity and Access Management (IAM) il comportamento di applicazione delle policy dipende dal tipo di risorsa specificata. Le risorse per operazioni di State Manager vengono applicate solo in base alla richiesta inoltrata. State Manager non esegue un controllo approfondito delle proprietà delle risorse nell'account. Una richiesta viene convalidata in base alle risorse di policy solo se il parametro della richiesta contiene le risorse di policy specificate. Ad esempio, se si specifica un'istanza nel blocco di risorse, la policy viene applicata se la richiesta utilizza il parametro `InstanceId`. Il parametro `Targets` per ogni risorsa nell'account non viene controllato per questo `InstanceId`.
Di seguito sono riportati alcuni casi con comportamento confuso:
+ [DescribeAssociation[DeleteAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DeleteAssociation.html)](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DescribeActivations.html), e [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html)utilizza `instance` e `document` risorse per specificare il modo obsoleto di fare riferimento alle associazioni. `managed-instance` Ciò include tutte le associazioni create con il parametro obsoleto `InstanceId`.
+ [CreateAssociation[CreateAssociationBatch](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociationBatch.html)](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociation.html), e [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html)use `instance` and `managed-instance` resources per specificare il modo obsoleto di fare riferimento alle associazioni. Ciò include tutte le associazioni create con il parametro obsoleto `InstanceId`. Il tipo di risorsa `document` fa parte del modo obsoleto di riferirsi alle associazioni ed è proprietà effettiva di un'associazione. Ciò significa che è possibile creare policy IAM con autorizzazioni `Allow` o `Deny` per entrambe le azioni `Create` e `Update` in base al nome del documento.
Per ulteriori informazioni sull'uso delle policy IAM con Systems Manager, consultare [Gestione delle identità e degli accessi per l’ AWS Systems Manager](security-iam.md) oppure [Operazioni, risorse e chiavi di condizione per AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html) nella *Guida all'autorizzazione dei servizi*.
# Creazione di associazioni che eseguono file MOF
È possibile eseguire file MOF (Managed Object Format) per imporre uno stato di destinazione sui nodi Windows Server gestiti conState Manager, uno strumento in AWS Systems Manager, utilizzando il documento `AWS-ApplyDSCMofs` SSM. Il documento `AWS-ApplyDSCMofs` è caratterizzato da due modalità di esecuzione. La prima consente di configurare l'associazione per analizzare e segnalare se i nodi gestiti sono nello stato desiderato definito nei file MOF specificati. La seconda consente di eseguire i file MOF e modificare la configurazione dei nodi in base alle risorse e ai relativi valori definiti nei file MOF. Il documento `AWS-ApplyDSCMofs` consente di scaricare ed eseguire i file di configurazione MOF da Amazon Simple Storage Service (Amazon S3), una condivisione locale o un sito Web sicuro con un dominio HTTPS.
State Manager registra e indica lo stato di ciascuna esecuzione di file MOF durante l'esecuzione di ogni associazione. State Manager, inoltre, indica l'output di ogni esecuzione di file MOF come evento di conformità che è possibile visualizzare nella pagina [Conformità di AWS Systems Manager](https://console.aws.amazon.com/systems-manager/compliance).
L'esecuzione dei file MOF si basa su Windows PowerShell Desired State Configuration (DSC). PowerShell PowerShell DSC è una piattaforma dichiarativa utilizzata per la configurazione, la distribuzione e la gestione dei sistemi Windows. PowerShell DSC consente agli amministratori di descrivere, in semplici documenti di testo chiamati configurazioni DSC, come desiderano configurare un server. Una configurazione PowerShell DSC è uno PowerShell script specializzato che indica cosa fare, ma non come farlo. L'esecuzione della configurazione produce un file MOF. Il file MOF può essere applicato a uno o più server per ottenere la configurazione desiderata per tali server. PowerShell Le risorse DSC si occupano effettivamente dell'applicazione della configurazione. Per ulteriori informazioni, vedere Panoramica della [configurazione dello stato PowerShell desiderato di Windows](https://download.microsoft.com/download/4/3/1/43113F44-548B-4DEA-B471-0C2C8578FBF8/Quick_Reference_DSC_WS12R2.pdf).
**Topics**
+ [
## Utilizzo di Amazon S3 per archiviare gli artefatti
](#systems-manager-state-manager-using-mof-file-S3-storage)
+ [
## Risoluzione delle credenziali nei file MOF
](#systems-manager-state-manager-using-mof-file-credentials)
+ [
## Utilizzo di token nei file MOF
](#systems-manager-state-manager-using-mof-file-tokens)
+ [
## Prerequisiti per la creazione di associazioni che eseguono file MOF
](#systems-manager-state-manager-using-mof-file-prereqs)
+ [
## Creazione di un'associazione che esegue i file MOF
](#systems-manager-state-manager-using-mof-file-creating)
+ [
## Risoluzione dei problemi relativi alla creazione di associazioni che eseguono file MOF
](#systems-manager-state-manager-using-mof-file-troubleshooting)
+ [
## Visualizzazione dei dettagli di conformità delle risorse DSC
](#systems-manager-state-manager-viewing-mof-file-compliance)
## Utilizzo di Amazon S3 per archiviare gli artefatti
Se utilizzi Amazon S3 per archiviare PowerShell moduli, file MOF, report di conformità o report sullo stato, allora il ruolo AWS Identity and Access Management (IAM) utilizzato da AWS Systems Manager SSM Agent must have `GetObject` e `ListBucket` le autorizzazioni nel bucket. Se non disponi di queste autorizzazioni, il sistema restituisce un errore *Accesso negato*. Ecco informazioni importanti sulla memorizzazione degli artefatti in Amazon S3.
+ Se il bucket si trova in un altro Account AWS, crea una policy relativa alle risorse del bucket che conceda l'account (o il ruolo IAM) e le autorizzazioni. `GetObject` `ListBucket`
+ Se desideri utilizzare le risorse DSC personalizzate, è possibile scaricarle da un bucket Amazon S3. Puoi anche installarli automaticamente dalla galleria. PowerShell
+ Se utilizzi Amazon S3 come sorgente del modulo, carica il modulo come file Zip nel seguente formato con distinzione tra maiuscole e minuscole: \$1 .zip. *ModuleName* *ModuleVersion* Ad esempio: \$11.0.0.zip. MyModule
+ Tutti i file devono trovarsi nella radice del bucket. Le strutture di cartella non sono supportate.
## Risoluzione delle credenziali nei file MOF
Le credenziali vengono risolte utilizzando [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) o [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md). In questo modo è possibile configurare la rotazione automatica delle credenziali. Ciò consente inoltre a DSC di propagare automaticamente le credenziali ai server senza ridistribuirle. MOFs
Per utilizzare un Gestione dei segreti AWS segreto in una configurazione, crea un PSCredential oggetto in cui il nome utente è il SecretId o SecretArn del segreto contenente la credenziale. È possibile specificare qualsiasi valore per la password. Il valore viene ignorato. Di seguito è riportato un esempio.
```
Configuration MyConfig
{
$ss = ConvertTo-SecureString -String 'a_string' -AsPlaintext -Force
$credential = New-Object PSCredential('a_secret_or_ARN', $ss)
Node localhost
{
File file_name
{
DestinationPath = 'C:\MyFile.txt'
SourcePath = '\\FileServer\Share\MyFile.txt'
Credential = $credential
}
}
}
```
Compila il tuo MOF utilizzando l'impostazione nei dati di configurazione PsAllowPlaintextPassword . Questo è consentito perché la credenziale contiene solo un'etichetta.
In Secrets Manager, assicurati che il nodo abbia GetSecretValue accesso a una IAM Managed Policy e, facoltativamente, alla Secret Resource Policy, se esistente. Per funzionare con DSC, il segreto deve essere nel formato seguente.
```
{ 'Username': 'a_name', 'Password': 'a_password' }
```
Il segreto può avere altre proprietà (ad esempio, proprietà utilizzate per la rotazione), ma deve avere almeno le proprietà del nome utente e della password.
Ti consigliamo di utilizzare un metodo di rotazione multiutente, in cui hai due nomi utente e password diversi e la AWS Lambda funzione di rotazione passa da uno all'altro. Questo metodo consente di avere più account attivi, eliminando il rischio di bloccare un utente durante la rotazione.
## Utilizzo di token nei file MOF
I token offrono la possibilità di modificare i valori di proprietà della risorsa *dopo* la compilazione del file MOF. In questo modo è possibile riutilizzare i file MOF comuni su più server che richiedono configurazioni simili.
La sostituzione dei token funziona solo per le proprietà della risorsa di tipo `String`. Tuttavia, se la risorsa ha una proprietà del nodo CIM nidificata, risolverà anche i token delle proprietà `String` in tale nodo CIM. Non è possibile usare la sostituzione dei token per numeri o array.
Ad esempio, si consideri uno scenario in cui si utilizza la xComputerManagement risorsa e si desidera rinominare il computer utilizzando DSC. In genere avresti bisogno di un file MOF dedicato per quel computer. Tuttavia, con il supporto dei token, è possibile creare un singolo file MOF e applicarlo a tutti i nodi. Nella proprietà `ComputerName`, invece dell'hard coding del nome del computer nel MOF, è possibile utilizzare un token del tipo tag di istanza. Il valore viene risolto durante l'analisi del file MOF. Guarda l'esempio seguente.
```
Configuration MyConfig
{
xComputer Computer
{
ComputerName = '{tag:ComputerName}'
}
}
```
È possibile quindi impostare un tag sul nodo gestito nella console Systems Manager oppure un tag Amazon Elastic Compute Cloud (Amazon EC2) nella console Amazon EC2. Quando esegui il documento, lo script sostituisce il token \$1tag:ComputerName\$1 al valore del tag di istanza.
Inoltre, è possibile combinare più tag in una singola proprietà, come mostrato nell'esempio che segue:
```
Configuration MyConfig
{
File MyFile
{
DestinationPath = '{env:TMP}\{tag:ComputerName}'
Type = 'Directory'
}
}
```
È possibile utilizzare 5 diversi tipi di token:
+ **tag**: tag di Amazon EC2 o di nodi gestiti.
+ **tagb64**: è uguale a tag, ma il sistema utilizza base64 per decodificare il valore. In questo modo è possibile utilizzare caratteri speciali nei valori di tag.
+ **env**: risolve variabili di ambiente.
+ **ssm**: valori di Parameter Store (archivio parametri). Sono supportati solo i tipi String e Secure String.
+ **tagssm**: è uguale al tag, ma se il tag non è impostato sul nodo, il sistema cerca di risolvere il valore da un parametro di Systems Manager con lo stesso nome. È utile in situazioni in cui si desidera un valore predefinito globale, ma si vuole sovrascriverlo su un singolo nodo (per esempio, distribuzioni one-box).
Ecco un esempio di Parameter Store (archivio parametri) che usa il tipo di token `ssm`.
```
File MyFile
{
DestinationPath = "C:\ProgramData\ConnectionData.txt"
Content = "{ssm:%servicePath%/ConnectionData}"
}
```
I token giocano un ruolo importante nel ridurre il codice ridondante, rendendo i file MOF generici e riutilizzabili. Se è possibile evitare file MOF specifici del server, non è necessario un servizio di creazione di file MOF. Un servizio di costruzione MOF aumenta i costi, rallenta i tempi di provisioning e aumenta il rischio di variazioni della configurazione tra i nodi raggruppati a causa delle diverse versioni dei moduli installate sul server di build al momento della compilazione. MOFs
## Prerequisiti per la creazione di associazioni che eseguono file MOF
Prima di creare un'associazione che esegue i file MOF, verifica che sui nodi gestiti siano installati i seguenti prerequisiti:
+ Windows versione 5.0 o successiva. PowerShell Per ulteriori informazioni, vedi [Requisiti di PowerShell sistema di Windows](https://docs.microsoft.com/en-us/powershell/scripting/install/windows-powershell-system-requirements?view=powershell-6) su Microsoft.com.
+ [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/) 3.3.261.0 o versioni successive
+ SSM Agent 2.2 o versione successiva.
## Creazione di un'associazione che esegue i file MOF
**Per creare un'associazione che esegue i file MOF**
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 **State Manager**.
1. Selezionare **State Manager** poi **Crea associazione**.
1. Nel campo **Name (Nome)**, specifica un nome. Questo passaggio è facoltativo, ma è consigliato. Un nome può aiutare a comprendere lo scopo dell'associazione al momento della creazione. Gli spazi non sono consentiti nel nome.
1. Nell'elenco **Document (Documento)** scegliere **`AWS-ApplyDSCMofs`**.
1. Nella sezione **Parameters (Parametri)**, specificare le proprie scelte per i parametri di input obbligatori e opzionali.
1. **Mofs To Apply (MOF da applicare)**: specificare uno o più file MOF da eseguire durante l'esecuzione dell'associazione. Utilizzare le virgole per separare un elenco di file MOF. Systems Manager itera attraverso l'elenco dei file MOF e li esegue nell'ordine specificato dall'elenco separato da virgole.
+ Un nome del bucket Amazon S3. I nomi di bucket devono utilizzare lettere minuscole. Specificare queste informazioni nel seguente formato.
```
s3:amzn-s3-demo-bucket:MOF_file_name.mof
```
Se desideri specificare un Regione AWS, utilizza il seguente formato.
```
s3:bucket_Region:amzn-s3-demo-bucket:MOF_file_name.mof
```
+ Un sito web sicuro. Specificare queste informazioni nel seguente formato.
```
https://domain_name/MOF_file_name.mof
```
Ecco un esempio.
```
https://www.example.com/TestMOF.mof
```
+ Un file system su una condivisione locale. Specificare queste informazioni nel seguente formato.
```
\server_name\shared_folder_name\MOF_file_name.mof
```
Ecco un esempio.
```
\StateManagerAssociationsBox\MOFs_folder\MyMof.mof
```
1. **Service Path (Percorso del servizio)**: (facoltativo) un percorso del servizio è un prefisso di bucket Amazon S3 in cui si desidera scrivere i report e le informazioni sullo stato. In alternativa, un percorso del servizio è un percorso per i tag basati sul parametro Parameter Store. Durante la risoluzione di tag basati su parametri, il sistema utilizza \$1ssm: %ServicePath%/*parameter\$1name*\$1 per inserire il valore ServicePath nel nome del parametro. Ad esempio, se il percorso del servizio è "/. WebServers/Production" then the systems resolves the parameter as: WebServers/Production *parameter\$1name* Questa funzione è utile quando si eseguono più ambienti nello stesso account.
1. **Report Bucket Name (Nome bucket per report)**: (facoltativo) immettere il nome di un bucket Amazon S3 in cui si desidera scrivere i dati di conformità. I report vengono salvati in questo bucket in formato JSON.
**Nota**
È possibile aggiungere come prefisso al nome del bucket una regione in cui si trova il bucket. Ecco un esempio: MOFBucket US-West-2:my. Se si sta usando un proxy per gli endpoint Amazon S3 in una determinata regione che non include us-east-1, aggiungere come prefisso al nome del bucket una regione. Se al nome del bucket non viene applicato un prefisso, troverà automaticamente la regione del bucket utilizzando l'endpoint us-east-1.
1. **Mof Operation Mode (Modalità operazione MOF)**: scegliere il comportamento di State Manager durante l'esecuzione dell'associazione **`AWS-ApplyDSCMofs`**:
+ **Apply (Applica)**: correggere le configurazioni non conformi dei nodi.
+ **ReportOnly**: Non correggi le configurazioni dei nodi, ma registra invece tutti i dati di conformità e segnala i nodi che non sono conformi.
1. **Status Bucket Name (Nome bucket stato)**: (facoltativo) immettere il nome di un bucket Amazon S3 in cui si desidera scrivere le informazioni sullo stato di esecuzione del file MOF. Questi report di stato sono riepiloghi singleton dell'esecuzione di conformità più recente di un nodo Ciò significa che il report verrà sovrascritto la volta successiva che l'associazione eseguirà i file MOF.
**Nota**
È possibile aggiungere come prefisso al nome del bucket una regione in cui si trova il bucket. Ecco un esempio: `us-west-2:amzn-s3-demo-bucket`. Se si sta usando un proxy per gli endpoint Amazon S3 in una determinata regione che non include us-east-1, aggiungere come prefisso al nome del bucket una regione. Se al nome del bucket non viene applicato un prefisso, troverà automaticamente la regione del bucket utilizzando l'endpoint us-east-1.
1. **Nome del bucket di origine del modulo**: (facoltativo) Inserisci il nome di un bucket Amazon S3 che PowerShell contiene i file del modulo. Se si specifica **None (Nessuno)**, scegliere **True (Vero)** come opzione successiva, **Allow PS Gallery Module Source (Consenti origine del modulo della galleria PS)**.
**Nota**
È possibile aggiungere come prefisso al nome del bucket una regione in cui si trova il bucket. Ecco un esempio: `us-west-2:amzn-s3-demo-bucket`. Se si sta usando un proxy per gli endpoint Amazon S3 in una determinata regione che non include us-east-1, aggiungere come prefisso al nome del bucket una regione. Se al nome del bucket non viene applicato un prefisso, troverà automaticamente la regione del bucket utilizzando l'endpoint us-east-1.
1. **Consenti l'origine del modulo PS Gallery**[: (Facoltativo) Scegli **True** per scaricare i PowerShell moduli da/. https://www.powershellgallery.com](https://www.powershellgallery.com/) Se scegli **False**, specifica una fonte per l'opzione precedente, **ModuleSourceBucketName**.
1. **Proxy Uri (Uri proxy)**: (facoltativo) utilizzare questa opzione per scaricare i file MOF da un server proxy.
1. **Reboot Behavior (Comportamento di riavvio)**: (facoltativo) specificare uno dei seguenti comportamenti di riavvio se l'esecuzione del file MOF richiede il riavvio:
+ **AfterMof**: riavvia il nodo dopo che tutte le esecuzioni MOF sono state completate. Anche se più esecuzioni di file MOF richiedono il riavvio, il sistema attende che tutte le esecuzioni vengano completate prima di riavviare.
+ **Immediately (Immediatamente)**: riavvia il nodo ogni volta che un'esecuzione di file MOF lo richiede. Se si eseguono più file MOF che richiedono il riavvio, i nodi saranno riavviati più volte.
+ **Never (Mai)**: i nodi non vengono riavviati, neanche se l'esecuzione di file MOF lo richiede esplicitamente.
1. **Use Computer Name For Reporting (Usa nome computer per il reporting)**: (facoltativo) abilitare questa opzione per utilizzare il nome del computer per il reporting delle informazioni di conformità. Il valore predefinito è **false (falso)**: ciò significa che il sistema utilizza l'ID nodo per il reporting delle informazioni di conformità.
1. **Abilita registrazione dettagliata**: (facoltativo) si consiglia di abilitare la registrazione dettagliata quando si distribuiscono i file MOF per la prima volta.
**Importante**
Se abilitata, la registrazione dettagliata scrive più dati sul bucket Amazon S3 rispetto alla registrazione standard dell'esecuzione di un'associazione. Questo può comportare un rallentamento delle prestazioni e costi di archiviazione maggiori per Amazon S3. Per ridurre i problemi di dimensioni dell'archiviazione, si consiglia di abilitare le policy del ciclo di vita del bucket Amazon S3. Per ulteriori informazioni, consulta [ Come creare una policy del ciclo di vita per un bucket S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) nella *Guida per l'utente Amazon Simple Storage Service*.
1. **Abilita registrazione di debug**: (facoltativo) si consiglia di abilitare la registrazione di debug se si desidera risolvere gli errori dei file MOF. È inoltre consigliabile disattivare questa opzione per l'uso normale.
**Importante**
Quando è abilitata, la registrazione di debug scrive più dati nel bucket Amazon S3 rispetto alla registrazione standard di esecuzione dell'associazione. Questo può comportare un rallentamento delle prestazioni e costi di archiviazione maggiori per Amazon S3. Per ridurre i problemi di dimensioni dell'archiviazione, si consiglia di abilitare le policy del ciclo di vita del bucket Amazon S3. Per ulteriori informazioni, consulta [ Come creare una policy del ciclo di vita per un bucket S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) nella *Guida per l'utente Amazon Simple Storage Service*.
1. **Compliance Type (Tipo di conformità)**: (facoltativo) specificare il tipo di conformità da utilizzare per il reporting delle informazioni di conformità. Il tipo di conformità predefinito è **Custom: DSC**. Se si creano più associazioni che eseguono i file MOF, assicurarsi di specificare un tipo di conformità diverso per ogni associazione. In caso contrario, ogni ulteriore associazione che usa **Custom: DSC** sovrascriverà i dati di conformità esistenti.
1. **Pre Reboot Script (Script di pre-riavvio)**: (facoltativo) specificare uno script da eseguire se la configurazione ha indicato la necessità di un riavvio. Lo script viene eseguito prima del riavvio. Lo script deve essere una singola riga. Separare le righe aggiuntive utilizzando il punto e virgola.
1. Nella sezione **Destinazioni**, scegli **Specifica di tag** o **Selezione manuale delle istanze**. Se si sceglie di definire le risorse come target mediante i tag, immettere una chiave e un valore del tag nei campi disponibili. Per ulteriori informazioni sull'utilizzo di target, consultare [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
1. Nella sezione **Specify schedule (Specifica pianificazione)**, scegliere **On Schedule (Conforme a pianificazione)** oppure **No schedule (Nessuna pianificazione)**. Se si sceglie **Pianificato**, utilizzare i pulsanti disponibili per creare una pianificazione Cron o della frequenza per l'associazione.
1. Nella sezione **Opzioni avanzate**:
+ In **Gravità conformità**, scegli un livello di gravità per l'associazione. Il report di conformità indica se l'associazione è conforme o non conforme e il livello di gravità specificato qui. Per ulteriori informazioni, consulta [Informazioni sulla conformità delle associazioni State Manager](compliance-about.md#compliance-about-association).
1. Nella sezione **Controllo velocità**, configurare le opzioni per l'esecuzione delle associazioni di State Manager in tutto il parco istanze di nodi gestiti. Per ulteriori informazioni su queste opzioni, consulta [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
Nella sezione **Simultaneità**, scegli un'opzione:
+ Scegli **destinazioni** per immettere il numero assoluto di destinazioni che possono eseguire contemporaneamente l'associazione.
+ Scegli **percentuale** per immettere la percentuale del set di destinazione che può eseguire contemporaneamente l'associazione.
Nella sezione **Soglia di errore**. scegli un'opzione:
+ Scegliere **errors (errori)** per immettere il numero assoluto di errori consentiti prima che State Manager arresti l'esecuzione delle associazioni su altri target.
+ Scegliere **percentage (percentuale)** per immettere una percentuale di errori consentiti prima che State Manager arresti l'esecuzione delle associazioni su altri target.
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**.
State Manager crea ed esegue immediatamente l'associazione sui nodi o sulle destinazioni specificate. Dopo l'esecuzione iniziale, l'associazione viene eseguita a intervalli in base alla pianificazione definita e in base alle regole seguenti:
+ State Manager esegue associazioni sui nodi che sono online quando inizia l'intervallo e salta i nodi non in linea.
+ State Manager tenta di eseguire l'associazione su tutti i nodi configurati durante un intervallo.
+ Se un'associazione non viene eseguita durante un intervallo (ad esempio, perché un valore di simultaneità ha limitato il numero di nodi che possono elaborare l'associazione contemporaneamente), State Manager tenta di eseguire l'associazione nell'intervallo successivo.
+ State Manager registra la cronologia per tutti gli intervalli ignorati. È possibile visualizzare la cronologia nella scheda **Cronologia di esecuzione**.
**Nota**
L'`AWS-ApplyDSCMofs` è un documento Command di Systems Manager Ciò significa che è anche possibile eseguire questo documento utilizzando Run Command, uno strumento di AWS Systems Manager. Per ulteriori informazioni, consulta [AWS Systems Manager Run Command](run-command.md).
## Risoluzione dei problemi relativi alla creazione di associazioni che eseguono file MOF
Questa sezione include informazioni utili per la risoluzione dei problemi di creazione delle associazioni che eseguono file MOF.
**Attiva la registrazione migliorata**
Come primo passo per la risoluzione dei problemi, abilita la registrazione migliorata. Nello specifico, svolgi le seguenti operazioni:
1. Verifica che l'associazione sia configurata per scrivere l'output dei comandi su Amazon S3 o Amazon CloudWatch Logs (). CloudWatch
1. Imposta il parametro **Abilita registrazione dettagliata** su True.
1. Imposta il parametro **Abilita registrazione di debug** su True.
Quando abiliti la registrazione dettagliata e di debug, il file di output **Stdout** include informazioni sull'esecuzione dello script. Questo file di output può aiutarti a identificare gli esiti negativi dello script. Il file di output **Stderr** contiene gli errori che si sono verificati durante l'esecuzione di uno script.
**Problemi comuni nella creazione di associazioni che eseguono file MOF**
Questa sezione include informazioni sui problemi comuni che possono verificarsi durante la creazione di associazioni in grado di eseguire i file MOF e la procedura per risolvere questi problemi.
**Il file MOF non è stato applicato**
Se State Manager non riesce ad applicare l'associazione ai nodi, inizia a esaminare il file di output **Stderr**. Questo file può aiutarti a comprendere la causa principale del problema. Inoltre, verifica quanto segue:
+ Il nodo ha le autorizzazioni di accesso necessarie per tutti i bucket Amazon S3 correlati al file MOF. Nello specifico:
+ **s3: GetObject autorizzazioni**: sono necessarie per i file MOF nei bucket Amazon S3 privati e i moduli personalizzati nei bucket Amazon S3.
+ **s3: PutObject autorizzazione**: è necessaria per scrivere report di conformità e stato di conformità nei bucket Amazon S3.
+ Se stai utilizzando i tag, assicurati che il nodo disponga della policy IAM obbligatoria. L'utilizzo di tag richiede che il ruolo IAM dell'istanza abbia una policy che consenta le operazioni `ec2:DescribeInstances` e `ssm:ListTagsForResource`.
+ Verifica che il nodo disponga dei tag previsti o dei parametri SSM assegnati.
+ Verifica che nei tag o nei parametri SSM non vi siano errori di battitura.
+ Prova ad applicare il file MOF localmente sul nodo per assicurarti che non vi sia un problema con il file MOF.
**Sembrava che il file MOF avesse esito negativo, ma l'esecuzione di Systems Manager è andata a buon fine**
Se il documento `AWS-ApplyDSCMofs` è stato eseguito correttamente, lo stato dell'esecuzione di Systems Manager risulta **Success (Riuscito)**. Questo stato non riflette lo stato di conformità del nodo in rapporto ai requisiti di configurazione nel file MOF. Per visualizzare lo stato di conformità dei nodi, visualizza i report di conformità. È possibile visualizzare un report JSON nel bucket per i report di Amazon S3. Questo si applica alle esecuzioni di Run Command e State Manager. Inoltre, per State Manager è possibile visualizzare i dettagli di conformità nella pagina Conformità di Systems Manager.
**Stati Stderr: errore di risoluzione del nome durante il raggiungimento del servizio**
Questo errore indica che lo script non è in grado di raggiungere un servizio remoto. Molto probabilmente lo script non è in grado di raggiungere Amazon S3. Questo problema si verifica il più delle volte quando lo script tenta di scrivere i report di conformità o lo stato di conformità nel bucket Amazon S3 fornito nei parametri del documento. In genere, questo errore si verifica quando un ambiente di elaborazione utilizza un firewall o un proxy trasparente che include una lista dei permessi. Per risolvere il problema:
+ Utilizzare una sintassi del bucket specifica per la regione per tutti i parametri del bucket Amazon S3. Ad esempio, il parametro **Mofs to Apply (MOF da applicare)** deve avere il seguente formato:
s3:: .mof*bucket-region*. *amzn-s3-demo-bucket* *mof-file-name*
Ecco un esempio:` s3:us-west-2:amzn-s3-demo-bucket:my-mof.mof`
I nomi di report, stato e bucket dell'origine del modulo devono avere il seguente formato.
*bucket-region**amzn-s3-demo-bucket*:. Ecco un esempio: `us-west-1:amzn-s3-demo-bucket;`
+ Se la sintassi specifica della regione non risolve il problema, assicurarsi che i nodi target possano accedere ad Amazon S3 nella regione desiderata. Per verificare ciò:
1. Trova il nome dell'endpoint per Amazon S3 nella regione Amazon S3 appropriata. Per ulteriori informazioni, consulta [ service endpoints](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_region) (Enpoint del servizio della console) nei *Riferimenti generali di Amazon Web Services*.
1. Accedi al nodo di destinazione ed esegui il seguente comando ping.
```
ping s3.s3-region.amazonaws.com
```
Se il ping non è riuscito, significa che Amazon S3 non funziona o che un firewall/transparent proxy sta bloccando l'accesso alla regione Amazon S3 oppure che il nodo non può accedere a Internet.
## Visualizzazione dei dettagli di conformità delle risorse DSC
Systems Manager acquisisce informazioni relative alla conformità sugli errori delle risorse DSC nello **Status Bucket (bucket dello stato)** di Amazon S3 specificato quando è stato eseguito il documento `AWS-ApplyDSCMofs`. La ricerca di informazioni sugli errori delle risorse DSC in un bucket Amazon S3 può essere dispendiosa in termini di tempo. È invece possibile visualizzare queste informazioni nella pagina **Compliance (Conformità)** di Systems Manager.
Nella sezione **Riepilogo risorse di conformità** è visualizzato il conteggio delle risorse non riuscite. Nell'esempio seguente, **ComplianceType**è **Custom:DSC** e una risorsa non è conforme.
**Nota**
Custom:DSC è il valore predefinito nel documento. **ComplianceType**`AWS-ApplyDSCMofs` Il valore è personalizzabile.
![\[Visualizzazione dei conteggi nella sezione Riepilogo risorse di conformità della pagina Conformità.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-3.png)
La sezione **Panoramica dei dettagli delle risorse** mostra informazioni sulla AWS risorsa con la risorsa DSC non conforme. Questa sezione include inoltre il nome MOF, le fasi dell'esecuzione dello script e (se applicabile) un link **View output (Visualizza output)** per visualizzare informazioni dettagliate sullo stato.
![\[Visualizzazione dei dettagli di conformità per un errore delle risorse di esecuzione MOF\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-1.png)
Il link **Visualizzazione dell'output** mostra gli ultimi 4.000 caratteri dello stato dettagliato. Systems Manager inizia con l'eccezione come primo elemento, quindi esegue un'analisi a ritroso nei messaggi dettagliati e aggiunge caratteri come prefisso fino a raggiungere la quota 4.000. Questo processo mostra i messaggi di log generati prima dell'eccezione ovvero i messaggi più rilevanti per la risoluzione dei problemi.
![\[Visualizzazione dell'output dettagliato per il problema di conformità delle risorse MOF\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-2.png)
Per informazioni su come visualizzare le informazioni di conformità, consulta [ConformitàAWS Systems Manager](systems-manager-compliance.md).
**Situazioni che influiscono sulla creazione di report sulla conformità**
Se l'associazione State Manager ha esito negativo, non viene creato alcun report sui dati di conformità. Più precisamente, se l'elaborazione di un MOF non riesce, Systems Manager non crea report sui problemi di conformità, in quanto le associazioni hanno esito negativo. Ad esempio, se Systems Manager tenta di scaricare un MOF da un bucket Amazon S3 per il cui accesso il nodo non dispone di autorizzazione, l'associazione ha esito negativo e non viene creato alcun report sui dati di conformità.
Se una risorsa in un secondo MOF ha esito negativo, Systems Manager *invece* crea un report sui dati di conformità. Ad esempio, se un MOF cerca di creare un file su un'unità che non esiste, Systems Manager crea report di conformità in quanto il documento `AWS-ApplyDSCMofs` è in grado di eseguire un'elaborazione completa, il che significa che l'associazione viene eseguita correttamente.
# Creazione di associazioni che eseguono playbook Ansible
È possibile creare associazioni State Manager che eseguono playbook Ansible utilizzando il documento SSM `AWS-ApplyAnsiblePlaybooks`. State Manager è uno strumento di AWS Systems Manager. Questo documento offre i seguenti vantaggi per l'esecuzione di playbook:
+ Supporto per l'esecuzione di playbook complessi
+ Supporto per il download di playbook da GitHub e Amazon Simple Storage Service (Amazon S3)
+ Supporto per la struttura di playbook compressa
+ Registrazione migliorata
+ Possibilità di specificare quale playbook eseguire quando i playbook sono raggruppati
**Nota**
Systems Manager include due documenti SSM che consentono di creare associazioni State Manager che eseguono playbook Ansible: `AWS-RunAnsiblePlaybook` e `AWS-ApplyAnsiblePlaybooks`. Il documento `AWS-RunAnsiblePlaybook` è obsoleto. Rimane disponibile in Systems Manager per scopi di legacy. Ti consigliamo di utilizzare il documento `AWS-ApplyAnsiblePlaybooks` come conseguenza dei miglioramenti descritti qui.
Le associazioni che eseguono playbook Ansible non sono supportate in macOS.
**Supporto per l'esecuzione di playbook complessi**
Il documento `AWS-ApplyAnsiblePlaybooks` supporta playbook complessi, raggruppati perché copia l'intera struttura di file in una directory locale prima di eseguire il playbook principale specificato. È possibile fornire playbook di origine in file zip o in una struttura di directory. Il file Zip o la directory sono archiviabili in GitHub o Amazon S3.
**Supporto per il download di playbook da GitHub**
Il documento `AWS-ApplyAnsiblePlaybooks` utilizza il plugin `aws:downloadContent` per scaricare i file di playbook. I file sono archiviabili in GitHub in un singolo file o come un set combinato di file di playbook. Per scaricare contenuti da GitHub, specificare le informazioni sul repository GitHub in formato JSON. Ecco un esempio.
```
{
"owner":"TestUser",
"repository":"GitHubTest",
"path":"scripts/python/test-script",
"getOptions":"branch:master",
"tokenInfo":"{{ssm-secure:secure-string-token}}"
}
```
**Supporto per il download di playbook da Amazon S3**
È possibile anche archiviare e scaricare playbook Ansible in Amazon S3 come singolo file .zip o una struttura di directory. Per scaricare contenuti da Amazon S3, specificare il percorso del file. Qui di seguito sono riportati due esempi.
**Esempio 1: download di un file di playbook specifico**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml"
}
```
**Esempio 2: download dei contenuti di una directory**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/ansible/webservers/"
}
```
**Importante**
Se specifichi Amazon S3, il profilo dell'istanza AWS Identity and Access Management (IAM) sui nodi gestiti deve includere le autorizzazioni per il bucket S3. Per ulteriori informazioni, consulta la pagina [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md).
**Supporto per la struttura di playbook compressa**
Il documento `AWS-ApplyAnsiblePlaybooks` consente di eseguire file .zip compressi nel bundle scaricato. Il documento verifica se i file scaricati contengono un file compresso in formato .zip. Quando viene trovato un file .zip, il documento decomprime automaticamente il file e quindi esegue l'automazione Ansible specificata.
**Registrazione migliorata**
Il documento `AWS-ApplyAnsiblePlaybooks` include un parametro facoltativo per specificare diversi livelli di registrazione. Specifica -v per basso livello di dettaglio, -vv o -vvv per medio livello di dettaglio e -vvvv per la registrazione a livello di debug. Queste opzioni sono mappate direttamente alle opzioni di livello di dettaglio Ansible.
**Possibilità di specificare quale playbook eseguire quando i playbook sono raggruppati**
Il documento `AWS-ApplyAnsiblePlaybooks` include un parametro obbligatorio per specificare quale playbook eseguire quando più playbook vengono raggruppati. Questa opzione offre flessibilità per l'esecuzione di playbook per supportare diversi casi d'uso.
## Comprensione delle dipendenze installate
Se si specifica **True** per il **InstallDependencies**parametro, Systems Manager verifica che nei nodi siano installate le seguenti dipendenze:
+ **Ubuntu Server/Debian Server**: Apt-get (gestione pacchetto), Python 3, Ansible, Unzip
+ Versioni supportate da **Amazon Linux**: Ansible
+ **RHEL**: Python 3, Ansible, Unzip
Se una o più di queste dipendenze non vengono trovate, Systems Manager le installa automaticamente.
## Creazione di un'associazione che esegue playbook Ansible (console)
La procedura seguente descrive come utilizzare la console di Systems Manager per creare un'associazione State Manager che esegua playbook Ansibleutilizzando il documento `AWS-ApplyAnsiblePlaybooks`.
**Per creare un'associazione che esegue playbook Ansible (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 **State Manager**.
1. Selezionare **State Manager** poi **Crea associazione**.
1. Per **Nome**, specifica un nome che consente di ricordare lo scopo dell'associazione.
1. Nell'elenco **Documento**, scegli **`AWS-ApplyAnsiblePlaybooks`**.
1. Nella sezione **Parametri**, per **Tipo di sorgente**, scegli uno dei due **GitHub**o **S3**.
**GitHub**
Se si sceglie **GitHub**, immetti le informazioni sul repository nel formato seguente.
```
{
"owner":"user_name",
"repository":"name",
"path":"path_to_directory_or_playbook_to_download",
"getOptions":"branch:branch_name",
"tokenInfo":"{{(Optional)_token_information}}"
}
```
**S3**
Se si sceglie **S3**, immetti le informazioni sul percorso nel formato seguente.
```
{
"path":"https://s3.amazonaws.com/path_to_directory_or_playbook_to_download"
}
```
1. Per **Installa dipendenze**, scegli un'opzione.
1. (Facoltativo) Per **F0ile di playbook**, immetti un nome file. Se il playbook è contenuto in un file Zip, specificare un percorso relativo al file Zip.
1. (Facoltativo) Per **Variabili extra**, immetti le variabili per l'invio da State Manager ad Ansible in fase di runtime.
1. (Facoltativo) Per **Verifica**, scegli un'opzione.
1. (Facoltativo) Per **Modalità dettagliata**, scegli un'opzione.
1. Per **Destinazioni**, scegli un'opzione. Per informazioni sull'utilizzo delle destinazioni, consulta [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
1. Nella sezione **Specifica pianificazione**, scegli **Conforme a pianificazione** o **Nessuna pianificazione**. Se si sceglie **Conforme a pianificazione**, utilizzare i pulsanti disponibili per creare una pianificazione Cron o rate per l'associazione.
1. Nella sezione **Opzioni avanzate**, per **Gravità conformità**, scegliere un livello di gravità per l'associazione. Il report di conformità indica se l'associazione è conforme o non conforme e il livello di gravità specificato qui. Per ulteriori informazioni, consulta [Informazioni sulla conformità delle associazioni State Manager](compliance-about.md#compliance-about-association).
1. Nella sezione **Controllo velocità**, configura le opzioni per eseguire le associazioni di State Manager in tutto il parco istanze nodi gestiti. Per informazioni sull'utilizzo dei controlli di velocità, consulta [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
Nella sezione **Simultaneità**, scegli un'opzione:
+ Scegli **destinazioni** per immettere il numero assoluto di destinazioni che possono eseguire contemporaneamente l'associazione.
+ Scegli **percentuale** per immettere la percentuale del set di destinazione che può eseguire contemporaneamente l'associazione.
Nella sezione **Soglia di errore**. scegli un'opzione:
+ Scegli **errori** per immettere il numero assoluto di errori consentiti prima che State Manager arresti l'esecuzione delle associazioni su altre destinazioni.
+ Scegli **percentuale** per immettere una percentuale di errori consentiti prima che State Manager arresti l'esecuzione delle associazioni su altre destinazioni.
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**.
**Nota**
Se utilizzi i tag per creare un'associazione su uno o più nodi di destinazione e quindi rimuovi i tag da un nodo, tale nodo non eseguirà più l'associazione. Il nodo viene dissociato dal documento di State Manager.
## Creazione di un'associazione che esegue playbook Ansible (CLI)
La procedura seguente descrive come utilizzare AWS Command Line Interface (AWS CLI) per creare un'State Managerassociazione che esegua Ansible playbook utilizzando il `AWS-ApplyAnsiblePlaybooks` documento.
**Per creare un'associazione che esegue playbook Ansible (CLI)**
1. 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).
1. Esegui uno dei seguenti comandi per creare un'associazione che esegue playbook Ansible eseguendo il targeting dei nodi tramite tag. Sostituisci ogni *example resource placeholder* con le tue informazioni. Il comando (A) specifica GitHub come tipo di origine. Il comando (B) specifica Amazon S3 come tipo di origine.
**(A) GitHub fonte**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner_name\", \"repository\": \"name\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"],"TimeoutSeconds":["3600"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner_name\", \"repository\": \"name\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"], "TimeoutSeconds":["3600"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
Ecco un esempio.
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets "Key=tag:OS,Values=Linux" \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ansibleDocumentTest\", \"repository\": \"Ansible\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True"],"PlaybookFile":["hello-world-playbook.yml"],"ExtraVariables":["SSM=True"],"Check":["False"],"Verbose":["-v"]}' \
--association-name "AnsibleAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
**(B) Origine S3**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_playbook_to_download\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_playbook_to_download\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
Ecco un esempio.
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets "Key=tag:OS,Values=Linux" \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml\"}"],"InstallDependencies":["True"],"PlaybookFile":["playbook.yml"],"ExtraVariables":["SSM=True"],"Check":["False"],"Verbose":["-v"]}' \
--association-name "AnsibleAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
**Nota**
Le associazioni di State Manager non supportano tutte le espressioni Cron e della frequenza. Per ulteriori informazioni sulla creazione di espressioni Cron e della frequenza per le associazioni, consulta [Riferimento: espressioni Cron e della frequenza per Systems Manager](reference-cron-and-rate-expressions.md).
Il sistema tenta di creare l'associazione sui nodi e di applicare immediatamente lo stato.
1. Eseguire il comando riportato sotto per visualizzare uno stato aggiornato dell'associazione appena creata.
```
aws ssm describe-association --association-id "ID"
```
# Creazione di associazioni che eseguono ricette di Chef
È possibile creare associazioni State Manager che eseguono ricette Chef utilizzando il documento SSM `AWS-ApplyChefRecipes`. State Manager è uno strumento di AWS Systems Manager. È possibile definire come destinazione i nodi di Systems Manager gestiti basati su Linux con il documento SSM `AWS-ApplyChefRecipes`. Questo documento offre i seguenti vantaggi per l'esecuzione di ricette Chef:
+ Supporta più versioni di Chef (da Chef 11 a Chef 18).
+ Installa automaticamente il software client Chef nei nodi di destinazione.
+ Facoltativamente esegue [controlli di conformità Systems Manager](systems-manager-compliance.md) su nodi di destinazione e memorizza i risultati dei controlli di conformità in un bucket Amazon Simple Storage Service (Amazon S3).
+ Esegue più cookbook e ricette in un'unica esecuzione del documento.
+ Facoltativamente esegue le ricette in modalità `why-run`, per mostrare quali ricette cambieranno nei nodi di destinazione senza apportare modifiche.
+ Facoltativamente applica attributi JSON personalizzati alle esecuzioni `chef-client`.
+ Facoltativamente, applica attributi JSON personalizzati da un file di origine archiviato in una posizione specificata dall'utente.
È possibile utilizzare i bucket [Git](#state-manager-chef-git), [GitHub](#state-manager-chef-github), [HTTP](#state-manager-chef-http), o [Amazon S3](#state-manager-chef-s3) come origini di download per i cookbook e le ricette Chef specificate in un documento `AWS-ApplyChefRecipes`.
**Nota**
Le associazioni che eseguono ricette Chef non sono supportate su macOS.
## Nozioni di base
Prima di creare un documento `AWS-ApplyChefRecipes`, prepara i cookbook Chef e il relativo repository. Se non hai già un Chef libro di cucina che desideri utilizzare, puoi iniziare utilizzando un `HelloWorld` ricettario di prova che AWS ha preparato per te. Il documento `AWS-ApplyChefRecipes` punta già a questo cookbook per impostazione predefinita. I tuoi cookbook dovrebbero essere impostati in modo simile alla seguente struttura di directory. Nell'esempio seguente, `jenkins` e `nginx` sono esempi di cookbook Chef disponibili su [https://supermarket.chef.io/](https://supermarket.chef.io/) sul sito web Chef.
Sebbene non sia AWS possibile supportare ufficialmente i libri di cucina sul [https://supermarket.chef.io/](https://supermarket.chef.io/)sito Web, molti di essi funzionano con il documento. `AWS-ApplyChefRecipes` Di seguito sono riportati esempi di criteri per stabilire quando si sta testando un cookbook della community:
+ Il cookbook dovrebbe supportare i sistemi operativi basati su Linux dei nodi di Systems Manager gestiti individuati come destinazione.
+ Il cookbook è valido per la versione client Chef (Chef Chef 11 a Chef 18) che utilizzi.
+ Il cookbook è compatibile con Chef Infra Client e non richiede un server Chef.
Verifica di avere la possibilità di accedere al sito web `Chef.io`, in modo che tutti i cookbook specificati nell'elenco di esecuzione siano installati quando viene eseguito il documento di Systems Manager (documento SSM). L'utilizzo di una cartella `cookbooks` nidificata è supportato, ma non obbligatorio; è possibile memorizzare i cookbook direttamente sotto il livello radice.
```
└── cookbooks (optional level)
├── jenkins
│ ├── metadata.rb
│ └── recipes
└── nginx
├── metadata.rb
└── recipes
```
**Importante**
Prima di creare un'associazione State Manager che esegua ricette Chef, è necessario tenere presente che l'esecuzione del documento installa il software client Chef nei nodi gestiti di Systems Manager, a meno che non si imposti i valori della **versione client Chef** a `None`. Questa operazione utilizza uno script di installazione Chef per installare i componenti Chef per conto dell'utente. Prima di eseguire un documento `AWS-ApplyChefRecipes`, assicurati che l'azienda sia in grado di soddisfare tutti i requisiti legali applicabili, incluse le condizioni di licenza applicabili all'uso del software Chef. Per ulteriori informazioni, consulta il [sito web Chef](https://www.chef.io/).
Systems Manager può fornire report di conformità a un bucket S3, alla console di Systems Manager o rendere disponibili i risultati di conformità in risposta ai comandi dell'API Systems Manager. Per eseguire report di conformità di Systems Manager, il profilo dell'istanza collegato con i nodi Systems Manager gestiti deve disporre delle autorizzazioni per scrivere nel bucket S3. Il profilo dell'istanza deve disporre delle autorizzazioni per utilizzare l'API `PutComplianceItem` Systems Manager. Per ulteriori informazioni sulla conformità di Systems Manager, consultare [ConformitàAWS Systems Manager](systems-manager-compliance.md).
### Registrazione dell'esecuzione del documento
Quando esegui un documento Systems Manager (documento SSM) utilizzando un'State Managerassociazione, puoi configurare l'associazione per scegliere l'output dell'esecuzione del documento e puoi inviare l'output ad Amazon S3 o CloudWatch Amazon Logs (LogsCloudWatch ). Per facilitare la risoluzione dei problemi al termine dell'esecuzione di un'associazione, verifica che l'associazione sia configurata per scrivere l'output dei comandi su un bucket Amazon S3 o su Logs. CloudWatch Per ulteriori informazioni, consulta [Utilizzo delle associazioni in Systems Manager](state-manager-associations.md).
## Applicazione degli attributi JSON alle destinazioni durante l'esecuzione di una ricetta
È possibile specificare gli attributi JSON che il client Chef applica ai nodi di destinazione durante l'esecuzione di un'associazione. Durante la configurazione dell'associazione, è possibile fornire un formato JSON non elaborato o specificare il percorso di un file JSON archiviato in Amazon S3.
Usa gli attributi JSON quando desideri personalizzare il modo in cui viene eseguita la ricetta senza dover modificare la ricetta stessa, ad esempio:
+ **Sovrascrivere un numero limitato di attributi**
Utilizza un formato JSON personalizzato per evitare di dover mantenere più versioni di una ricetta per adattarla a piccole differenze.
+ **Fornire valori variabili**
Usa un codice JSON personalizzato per specificare i valori che potrebbero cambiare da. run-to-run Ad esempio, se i cookbook Chef configurano un'applicazione di terze parti che accetta pagamenti, è possibile utilizzare un formato JSON personalizzato per specificare l'URL dell'endpoint di pagamento.
**Definizione degli attributi in formato JSON non elaborato**
Di seguito è riportato un esempio del formato da utilizzare per specificare attributi JSON personalizzati per la ricetta Chef.
```
{"filepath":"/tmp/example.txt", "content":"Hello, World!"}
```
**Definizione di un percorso per un file JSON**
Di seguito è riportato un esempio del formato da utilizzare per specificare il percorso degli attributi JSON personalizzati per la ricetta Chef.
```
{"sourceType":"s3", "sourceInfo":"someS3URL1"}, {"sourceType":"s3", "sourceInfo":"someS3URL2"}
```
## Utilizzo di Git come origine di un cookbook
Il documento `AWS-ApplyChefRecipes` utilizza il plug-in [aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent) per scaricare cookbook Chef. Per scaricare contenuti da Git, specifica le informazioni sul repository Git in formato JSON come nel seguente esempio. Sostituisci ogni *example-resource-placeholder* con le tue informazioni.
```
{
"repository":"GitCookbookRepository",
"privateSSHKey":"{{ssm-secure:ssh-key-secure-string-parameter}}",
"skipHostKeyChecking":"false",
"getOptions":"branch:refs/head/main",
"username":"{{ssm-secure:username-secure-string-parameter}}",
"password":"{{ssm-secure:password-secure-string-parameter}}"
}
```
## Utilizzo di GitHub come fonte di cookbook
Il documento `AWS-ApplyChefRecipes` utilizza il plug-in [aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent) per scaricare cookbook. Per scaricare contenuti da GitHub, specifica le informazioni sul repository GitHub in formato JSON come nel seguente esempio. Sostituisci ogni *example-resource-placeholder* con le tue informazioni.
```
{
"owner":"TestUser",
"repository":"GitHubCookbookRepository",
"path":"cookbooks/HelloWorld",
"getOptions":"branch:refs/head/main",
"tokenInfo":"{{ssm-secure:token-secure-string-parameter}}"
}
```
## Utilizzo di HTTP come origine di un cookbook
È possibile archiviare i cookbook Chef in una posizione HTTP personalizzata come singolo file `.zip` o `tar.gz` oppure come struttura di directory. Per scaricare contenuti da HTTP, specifica il percorso del file o della directory in formato JSON, come nell'esempio seguente. Sostituisci ogni *example-resource-placeholder* con le tue informazioni.
```
{
"url":"https://my.website.com/chef-cookbooks/HelloWorld.zip",
"allowInsecureDownload":"false",
"authMethod":"Basic",
"username":"{{ssm-secure:username-secure-string-parameter}}",
"password":"{{ssm-secure:password-secure-string-parameter}}"
}
```
## Utilizzo di Amazon S3 come fonte di cookbook
È possibile anche archiviare e scaricare i cookbook Chef in Amazon S3 come singolo file `.zip` o `tar.gz` oppure come struttura di directory. Per scaricare contenuti da Amazon S3, specifica il percorso del file in formato JSON, come negli esempi seguenti. Sostituisci ogni *example-resource-placeholder* con le tue informazioni.
**Esempio 1: Scaricare un cookbook**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks/HelloWorld.zip"
}
```
**Esempio 2: download dei contenuti di una directory**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks-test/HelloWorld"
}
```
**Importante**
Se specifichi Amazon S3, il profilo dell'istanza AWS Identity and Access Management (IAM) sui nodi gestiti deve essere configurato con la `AmazonS3ReadOnlyAccess` policy. Per ulteriori informazioni, consulta la pagina [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md).
## Creazione di un'associazione che esegue le ricette Chef (console)
La procedura seguente descrive come utilizzare la console di Systems Manager per creare un'associazione State Manager che esegua i cookbook Chef utilizzando il documento `AWS-ApplyChefRecipes`.
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 **State Manager**.
1. Selezionare **State Manager** poi **Crea associazione**.
1. Per **Name (Nome)**, specificare un nome che consente di ricordare lo scopo dell'associazione.
1. Nell'elenco **Document (Documento)** scegliere **`AWS-ApplyChefRecipes`**.
1. In **Parametri**, per **Tipo di origine**, seleziona **Git**, **GitHub**, **HTTP**, oppure **S3**.
1. Per **informazioni origine**, inserisci le informazioni sull'origine del cookbook utilizzando il formato appropriato per **Tipo di origine** selezionato nel passaggio 6. Per ulteriori informazioni, consulta i seguenti argomenti:
+ [Utilizzo di Git come origine di un cookbook](#state-manager-chef-git)
+ [Utilizzo di GitHub come fonte di cookbook](#state-manager-chef-github)
+ [Utilizzo di HTTP come origine di un cookbook](#state-manager-chef-http)
+ [Utilizzo di Amazon S3 come fonte di cookbook](#state-manager-chef-s3)
1. In **Esegui elenco**, elencare le ricette che si desidera eseguire nel formato seguente, separando ogni ricetta con una virgola come mostrato. Non includere uno spazio dopo la virgola. Sostituisci ogni *example-resource-placeholder* con le tue informazioni.
```
recipe[cookbook-name1::recipe-name],recipe[cookbook-name2::recipe-name]
```
1. (Facoltativo) Specifica gli attributi JSON personalizzati che desideri che il client Chef passi ai nodi di destinazione.
1. In **Contenuto degli attributi JSON**, aggiungi qualsiasi attributo che desideri che il client Chef passi ai nodi di destinazione.
1. In **Origini degli attributi JSON**, aggiungi i percorsi degli attributi che desideri che il client Chef passi ai nodi di destinazione.
Per ulteriori informazioni, consulta [Applicazione degli attributi JSON alle destinazioni durante l'esecuzione di una ricetta](#apply-custom-json-attributes).
1. Per la **versione client Chef**, specificare una versione Chef. I valori validi sono compresi tra `11` e `18` o `None`. Se si specifica un numero compreso tra `11` e `18` (incluso), Systems Manager installa la versione client Chef corretta nei nodi di destinazione. Se si specifica `None`, Systems Manager non installa il client Chef nei nodi di destinazione prima di eseguire le ricette del documento.
1. (Facoltativo) In **Argomenti del client Chef**, specificare argomenti aggiuntivi supportati per la versione di Chef utilizzata. Per ulteriori informazioni sugli argomenti supportati, eseguire `chef-client -h` su un nodo che esegue il client Chef.
1. (Facoltativo) Abilitare **Why-run** per mostrare le modifiche apportate ai nodi di destinazione se vengono eseguite le ricette, senza modificare effettivamente i nodi di destinazione.
1. In **Gravità della conformità**, scegliere la gravità dei risultati della conformità di Systems Manager che si desidera segnalare. Il report di conformità indica se l'associazione è conforme o non conforme e il livello di gravità specificato qui. I report di conformità vengono archiviati in un bucket S3 specificato come valore del parametro **Compliance report bucket (bucket del report di conformità)** (passaggio 14). Per ulteriori informazioni sulla conformità, consultare [Scopri i dettagli sulla conformità](compliance-about.md) in questa guida.
Le scansioni di conformità misurano la differenza tra la configurazione specificata nelle ricette Chef e le risorse di nodo. I valori validi sono `Critical`, `High`, `Medium`, `Low`, `Informational`, `Unspecified` o `None`. Per ignorare la segnalazione di conformità, scegliere `None`.
1. Per **Tipo di conformità**, specificare il tipo di conformità per il quale si desidera segnalare i risultati. I valori validi sono `Association` per State Manager le associazioni, o `Custom:`*custom-type*. Il valore predefinito è `Custom:Chef`.
1. Per **Bucket del report di conformità**, immettere il nome di un bucket S3 in cui memorizzare le informazioni su ogni esecuzione Chef effettuata da questo documento, inclusi i risultati della configurazione delle risorse e della conformità.
1. Nella sezione **Controllo velocità**, configurare le opzioni per eseguire le associazioni di State Manager in tutto il parco istanze nodi gestiti. Per informazioni sull'utilizzo dei controlli di velocità, consulta [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
In **Convaluta**, scegli un'opzione:
+ Scegli **destinazioni** per immettere il numero assoluto di destinazioni che possono eseguire contemporaneamente l'associazione.
+ Scegli **percentuale** per immettere la percentuale del set di destinazione che può eseguire contemporaneamente l'associazione.
In **Soglia di errore**, scegli un'opzione:
+ Scegli **errori** per immettere il numero assoluto di errori consentiti prima che State Manager arresti l'esecuzione delle associazioni su altre destinazioni.
+ Scegli **percentuale** per immettere una percentuale di errori consentiti prima che State Manager arresti l'esecuzione delle associazioni su altre destinazioni.
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**.
## Creazione di un'associazione che esegue le ricette Chef (CLI)
La procedura seguente descrive come utilizzare AWS Command Line Interface (AWS CLI) per creare un'State Managerassociazione che esegua i libri di cucina Chef utilizzando il `AWS-ApplyChefRecipes` documento.
1. 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).
1. Esegui uno dei seguenti comandi per creare un'associazione che esegue cookbook Chef sui nodi di destinazione che presentano i tag specificati. Usa il comando appropriato per il tipo di origine del cookbook e il sistema operativo. Sostituisci ogni *example-resource-placeholder* con le tue informazioni.
1. **Origine Git**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["Git"],"SourceInfo":["{\"repository\":\"repository-name\", \"getOptions\": \"branch:branch-name\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["Git"],"SourceInfo":["{\"repository\":\"repository-name\", \"getOptions\": \"branch:branch-name\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' ^
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
1. **GitHub source (origine)**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner-name\", \"repository\": \"name\", \"path\": \"path-to-directory-or-cookbook-to-download\", \"getOptions\": \"branch:branch-name\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner-name\", \"repository\": \"name\", \"path\": \"path-to-directory-or-cookbook-to-download\", \"getOptions\": \"branch:branch-name\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' ^
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
Ecco un esempio.
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:OS,Values=Linux \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ChefRecipeTest\", \"repository\": \"ChefCookbooks\", \"path\": \"cookbooks/HelloWorld\", \"getOptions\": \"branch:master\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' \
--association-name "MyChefAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:OS,Values=Linux ^
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ChefRecipeTest\", \"repository\": \"ChefCookbooks\", \"path\": \"cookbooks/HelloWorld\", \"getOptions\": \"branch:master\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' ^
--association-name "MyChefAssociation" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
1. **Origine HTTP**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["HTTP"],"SourceInfo":["{\"url\":\"url-to-zip-file|directory|cookbook\", \"authMethod\": \"auth-method\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["HTTP"],"SourceInfo":["{\"url\":\"url-to-zip-file|directory|cookbook\", \"authMethod\": \"auth-method\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
1. **Origine Amazon S3**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_cookbook_to_download\"}"], "RunList":["{\"recipe[cookbook_name1::recipe_name]\", \"recipe[cookbook_name2::recipe_name]\"}"], "JsonAttributesContent": ["{Custom_JSON}"], "ChefClientVersion": ["version_number"], "ChefClientArguments":["{chef_client_arguments}"], "WhyRun": true_or_false, "ComplianceSeverity": ["severity_value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["amzn-s3-demo-bucket"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_cookbook_to_download\"}"], "RunList":["{\"recipe[cookbook_name1::recipe_name]\", \"recipe[cookbook_name2::recipe_name]\"}"], "JsonAttributesContent": ["{Custom_JSON}"], "ChefClientVersion": ["version_number"], "ChefClientArguments":["{chef_client_arguments}"], "WhyRun": true_or_false, "ComplianceSeverity": ["severity_value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["amzn-s3-demo-bucket"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
Ecco un esempio.
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets "Key=tag:OS,Values= Linux" \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/HelloWorld\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' \
--association-name "name" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets "Key=tag:OS,Values= Linux" ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/HelloWorld\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' ^
--association-name "name" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
Il sistema crea l'associazione e, a meno che l'espressione Cron o della frequenza specificata non lo impedisca, esegue l'associazione sui nodi di destinazione.
**Nota**
Le associazioni di State Manager non supportano tutte le espressioni Cron e della frequenza. Per ulteriori informazioni sulla creazione di espressioni Cron e della frequenza per le associazioni, consulta [Riferimento: espressioni Cron e della frequenza per Systems Manager](reference-cron-and-rate-expressions.md).
1. Esegui il comando riportato sotto per visualizzare lo stato dell'associazione appena creata.
```
aws ssm describe-association --association-id "ID"
```
## Visualizzazione dei dettagli di conformità delle risorse Chef
Systems Manager acquisisce le informazioni di conformità sulle risorse gestite da Chef nel valore del **Compliance report bucket (bucket del report di conformità)** di Amazon S3 specificato durante l'esecuzione del documento `AWS-ApplyChefRecipes`. La ricerca di informazioni sugli errori delle risorse Chef in un bucket S3 richiede del tempo. È invece possibile visualizzare queste informazioni nella pagina **Compliance (Conformità)** di Systems Manager.
Un'analisi della conformità di Systems Manager raccoglie informazioni sulle risorse dei nodi gestiti create o controllate nell'esecuzione Chef più recente. Le risorse possono includere file, directory, servizi `systemd`, pacchetti `yum`, file con modelli, pacchetti `gem` e cookbook dipendenti, tra gli altri.
Nella sezione **(Riepilogo risorse di conformità** è visualizzato il conteggio delle risorse non riuscite. Nell'esempio seguente, **ComplianceType**è **Custom: Chef** e una risorsa non è conforme.
**Nota**
`Custom:Chef`è il **ComplianceType**valore predefinito nel documento. `AWS-ApplyChefRecipes` Il valore è personalizzabile.
![\[Visualizzazione dei conteggi nella sezione Riepilogo risorse di conformità della pagina Conformità.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/state-manager-chef-compliance-summary.png)
La sezione **Panoramica dei dettagli delle risorse** mostra le informazioni sulla AWS risorsa che non è conforme. Questa sezione include anche il tipo di risorsa Chef per cui è stata eseguita la conformità, la gravità del problema, lo stato di conformità e i collegamenti a ulteriori informazioni, se applicabile.
![\[Visualizzazione dei dettagli di conformità per un errore di risorse gestito da Chef\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/state-manager-chef-compliance-details.png)
**View output (Visualizzazione dell'output)** mostra gli ultimi 4.000 caratteri dello stato dettagliato. Systems Manager inizia con l'eccezione come primo elemento, trova messaggi dettagliati e li mostra fino a raggiungere la quota di 4.000 caratteri. Questo processo mostra i messaggi di log generati prima dell'eccezione ovvero i messaggi più rilevanti per la risoluzione dei problemi.
Per informazioni su come visualizzare le informazioni di conformità, consulta [ConformitàAWS Systems Manager](systems-manager-compliance.md).
**Importante**
Se l'associazione State Manager ha esito negativo, non viene creato alcun report sui dati di conformità. Ad esempio, se Systems Manager tenta di scaricare un cookbook Chef da un bucket S3 per il cui accesso il nodo non dispone di autorizzazione, l'associazione non va a buon fine e Systems Manager non crea alcun report dei dati di conformità.
# Procedura dettagliata: aggiorna SSM Agent automaticamente con AWS CLI
La procedura seguente ti guiderà attraverso il processo di creazione di un'associazione di State Manager utilizzando AWS Command Line Interface. L'associazione aggiorna automaticamente l'SSM Agent in base a una pianificazione da te specificata. Per ulteriori informazioni su SSM Agent, consultare [Utilizzo di SSM Agent](ssm-agent.md). Per personalizzare la pianificazione degli aggiornamenti per SSM Agent tramite la console, consulta [Aggiornamento automatico di SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console).
Per ricevere notifiche sugli aggiornamenti dell'SSM Agent, iscriviti alla pagina [Note di rilascio dell'SSM Agent](https://github.com/aws/amazon-ssm-agent/blob/master/RELEASENOTES.md) su GitHub.
**Prima di iniziare**
Prima di completare la procedura seguente, verificare di disporre di almeno un'istanza Amazon Elastic Compute Cloud (Amazon EC2) in esecuzione per Linux, macOS o Windows Server configurata per Systems Manager. Per ulteriori informazioni, consulta [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md).
Se create un'associazione utilizzando AWS CLI o AWS Tools for Windows PowerShell, utilizzate il `--Targets` parametro per indirizzare le istanze, come illustrato nell'esempio seguente. Non utilizzare il parametro `--InstanceID`. Il parametro `--InstanceID` è un parametro legacy.
**Per creare un'associazione per aggiornare automaticamente l'SSM Agent**
1. 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).
1. Esegui il comando seguente per creare un'associazione scegliendo come destinazione le istanze tramite i tag Amazon Elastic Compute Cloud (Amazon EC2). Sostituisci ogni *example resource placeholder* con le tue informazioni. Il parametro `Schedule` imposta una pianificazione per eseguire l'associazione ogni domenica mattina alle 2:00 (UTC).
Le associazioni di State Manager non supportano tutte le espressioni Cron e della frequenza. Per ulteriori informazioni sulla creazione di espressioni Cron e della frequenza per le associazioni, consulta [Riferimento: espressioni Cron e della frequenza per Systems Manager](reference-cron-and-rate-expressions.md).
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=tag:tag_key,Values=tag_value \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=tag:tag_key,Values=tag_value ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
Puoi scegliere come target più istanze specificando le istanze IDs in un elenco separato da virgole.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
È possibile specificare la versione dell'SSM Agent a cui desideri aggiornare.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)" \
--parameters version=ssm_agent_version_number
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--parameters version=ssm_agent_version_number
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 2 ? * SUN *)",
"Name": "AWS-UpdateSSMAgent",
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "123..............",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1504034257.98,
"Date": 1504034257.98,
"AssociationVersion": "1",
"Targets": [
{
"Values": [
"TagValue"
],
"Key": "tag:TagKey"
}
]
}
}
```
Il sistema tenta di creare l'associazione sulla/e istanza/e e applica lo stato dopo la creazione. L'associazione presenta lo stato `Pending`.
1. Eseguire il comando seguente per visualizzare uno stato aggiornato dell'associazione creata.
```
aws ssm list-associations
```
Se le istanze *non* stanno eseguendo attualmente la versione più recente dell'SSM Agent, lo stato mostra `Failed`. Quando viene pubblicata una nuova versione dell'SSM Agent, l'associazione installa automaticamente il nuovo agente e lo stato mostra `Success`.
# Spiegazione passo per passo: aggiornare automaticamente i driver PV sulle istanze EC2 per Windows Server
Le Windows Server Amazon Machine Images (AMIs) di Amazon contengono un insieme di driver per consentire l'accesso all'hardware virtualizzato. Questi driver vengono utilizzati da Amazon Elastic Compute Cloud (Amazon EC2) per mappare i volumi di archivio istanze e Amazon Elastic Block Store (Amazon EBS) ai rispettivi dispositivi. Ti consigliamo di installare i driver più recenti per migliorare la stabilità e le prestazioni delle istanze EC2 per Windows Server. Per ulteriori informazioni sui driver PV, consulta [Driver PV di AWS](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/xen-drivers-overview.html#xen-driver-awspv).
La procedura dettagliata seguente mostra come configurare un'State Managerassociazione per scaricare e installare automaticamente nuovi driver AWS PV non appena i driver diventano disponibili. State Managerè uno strumento in. AWS Systems Manager
**Prima di iniziare**
Prima di completare la procedura seguente, verificare di disporre di almeno un'istanza Amazon EC2 per un'esecuzione in Windows Server configurata per Systems Manager. Per ulteriori informazioni, consulta [Configurazione di nodi gestiti per AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Per creare un'associazione di State Manager che aggiorna automaticamente i driver PV**
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 **State Manager**.
1. Selezionare **Create association (Crea associazione)**.
1. Nel campo **Name**, immettere un nome descrittivo per l'associazione.
1. Nell'elenco **Documento**, scegli `AWS-ConfigureAWSPackage`.
1. Nell'area **Parameters** (Parametri), eseguire le operazioni seguenti:
+ Per **Action (Operazione)**, selezionare **Install (Installa)**.
+ In **Installation type (Tipo di installazione)**, scegliere **Uninstall and reinstall (Disinstalla e reinstalla)**.
**Nota**
Gli aggiornamenti locali non sono supportati per questo pacchetto. È necessario disinstallarlo e reinstallarlo.
+ In **Nome**, inserisci **AWSPVDriver**.
Non è necessario inserire nulla nei campi **Versione** e **Argomenti aggiuntivi**.
1. Nella sezione **Destinazioni**, identificare i nodi in cui si desidera eseguire questa operazione specificando i tag, selezionando manualmente le istanze, i dispositivi edge o indicando un gruppo di risorse.
**Suggerimento**
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.
**Nota**
Se si sceglie di indirizzare le istanze mediante i tag e si specificano tag che mappano per istanze di Linux, l'associazione viene completata sull'istanza di Windows Server, ma non su quelle di Linux. Lo stato globale dell'associazione mostra **Failed (Non riuscito)**.
1. Nell'area **Specifica la pianificazione**, scegli se eseguire l'associazione in base a una pianificazione configurata dall'utente, oppure solo una volta. I driver PV aggiornati vengono distribuiti più volte all'anno, perciò è possibile pianificare l'esecuzione dell'associazione una volta al mese, se si desidera.
1. Nell'area**Advanced options (Opzioni avanzate)**, per **Compliance severity (Gravità conformità)**, scegliere un livello di gravità per l'associazione. Il report di conformità indica se l'associazione è conforme o non conforme e il livello di gravità specificato qui. Per ulteriori informazioni, consulta [Informazioni sulla conformità delle associazioni State Manager](compliance-about.md#compliance-about-association).
1. In **Controllo velocità**:
+ In **Simultaneità**, specifica un numero o una percentuale di nodi gestiti su cui eseguire contemporaneamente il comando.
**Nota**
Se hai selezionato le destinazioni specificando i tag applicati ai nodi gestiti o specificando i gruppi di AWS risorse e non sei sicuro del numero di nodi gestiti come target, limita il numero di destinazioni che possono eseguire il documento contemporaneamente specificando una percentuale.
+ Per **Soglia di errore**, specificare quando interrompere l'esecuzione del comando sulle altri nodi gestiti dopo un errore su un numero o una percentuale di nodi. Se, ad esempio, si specificano tre errori, Systems Manager interrompe l'invio del comando quando riceve il quarto errore. Anche i nodi gestiti che stanno ancora elaborando il comando potrebbero inviare errori.
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. (Facoltativo) Nella sezione **CloudWatch Allarme**, per **Nome allarme**, scegliete un CloudWatch allarme da applicare all'associazione per il monitoraggio.
**Nota**
Prendi nota delle seguenti informazioni importanti relative a questa fase.
L'elenco degli allarmi riporta un massimo di 100 allarmi. Se non vedi il tuo allarme nell'elenco, usa AWS Command Line Interface per creare l'associazione. Per ulteriori informazioni, consulta [Creazione di un'associazione (riga di comando)](state-manager-associations-creating.md#create-state-manager-association-commandline).
Per allegare un CloudWatch allarme al tuo comando, il responsabile IAM che crea l'associazione deve avere l'autorizzazione per l'`iam:createServiceLinkedRole`azione. Per ulteriori informazioni sugli CloudWatch allarmi, consulta [Usare gli CloudWatch allarmi Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Tenere presente che se l'allarme si attiva, qualsiasi automazione o invocazione di comando in sospeso non viene eseguita.
1. Selezionare **Create association (Crea associazione)**, poi **Close (Chiudi)**. Il sistema tenta di creare l'associazione sulle istanze e di applicare immediatamente lo stato.
Una volta creata l'associazione su una o più istanze Amazon EC2 per Windows Server, lo stato diventa **Riuscito**. Se le istanze non sono configurate per Systems Manager, oppure se sono state inavvertitamente definite come istanze Linux di destinazione, lo stato mostra **Non riuscito**.
Se lo stato è **Non riuscito**, selezionare l'ID associazione, seleziona la scheda **Risorse** e poi verifica che l'associazione sia stata creata correttamente nelle istanze EC2 per Windows Server. Se le istanze EC2 per Windows Server mostrano lo stato **Failed**, verifica che SSM Agent sia in esecuzione sull'istanza e verifica che l'istanza sia configurata con un ruolo AWS Identity and Access Management (IAM) per Systems Manager. Per ulteriori informazioni, consulta [Configurazione della console unificata di Systems Manager per un'organizzazione](systems-manager-setting-up-organizations.md).