• 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à. # Gestione dei nodi in ambienti ibridi e multicloud con Systems Manager Puoi utilizzare AWS Systems Manager per gestire sia istanze Amazon Elastic Compute Cloud (EC2) che diversi tipi di macchine non EC2. Questa sezione descrive le attività di configurazione che gli amministratori di account e di sistema eseguono per gestire macchine non EC2 utilizzando Systems Manager in un ambiente *[ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types)*. Una volta completati questi passaggi, gli utenti a cui sono state concesse le autorizzazioni dall' Account AWS amministratore possono utilizzare Systems Manager per configurare e gestire i computer non EC2 della propria organizzazione. Qualsiasi macchina che è stata configurata per l'uso con Systems Manager è chiamata *nodo gestito*. **Nota** È possibile registrare i dispositivi edge come nodi gestiti utilizzando gli stessi passaggi di attivazione ibrida utilizzati per altre macchine non EC2. Questi tipi di dispositivi periferici includono sia AWS IoT dispositivi che dispositivi diversi dai dispositivi. AWS IoT Utilizza il processo descritto in questa sezione per configurare questi tipi di dispositivi edge. Systems Manager supporta anche i dispositivi edge che utilizzano il software AWS IoT Greengrass Core. Il processo di configurazione e i requisiti per i dispositivi AWS IoT Greengrass core sono diversi da quelli per AWS IoT i dispositivi periferici diversi dai dispositivi AWS edge. Per informazioni sulla registrazione AWS IoT Greengrass dei dispositivi da utilizzare con Systems Manager, vedere[Gestione dei dispositivi edge con Systems Manager](systems-manager-setting-up-edge-devices.md). Le macchine macOS non EC2 non sono supportate per gli ambienti ibridi e multicloud di Systems Manager. Se prevedi di utilizzare Systems Manager per gestire le istanze Amazon Elastic Compute Cloud (Amazon EC2) o di utilizzare sia le istanze Amazon EC2 che le macchine non EC2 in un ambiente ibrido e multicloud, segui prima la procedura riportata in [Gestire le istanze EC2 con Systems Manager](systems-manager-setting-up-ec2.md). Dopo aver configurato l'ambiente ibrido e multicloud per Systems Manager, potrai eseguire le seguenti operazioni: + Creare un modo coerente e sicuro per gestire in remoto carichi di lavoro ibridi e multicloud da una posizione utilizzando gli stessi strumenti o script. + Centralizza il controllo degli accessi per le azioni che possono essere eseguite sulle macchine utilizzando AWS Identity and Access Management (IAM). + Centralizzare il controllo delle operazioni eseguite sulle macchine visualizzando l'attività API registrata in AWS CloudTrail. Per informazioni sull'utilizzo per CloudTrail monitorare le azioni di Systems Manager, vedere[Registrazione delle chiamate AWS Systems Manager API con AWS CloudTrail](monitoring-cloudtrail-logs.md). + Centralizza il monitoraggio configurando Amazon e EventBridge Amazon Simple Notification Service (Amazon SNS) per inviare notifiche sul successo dell'esecuzione del servizio. Per informazioni sull'utilizzo per EventBridge monitorare gli eventi di Systems Manager, vedere[Monitoraggio degli eventi di Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md). **Informazioni sui nodi gestiti** *Dopo aver completato la configurazione delle macchine non EC2 per Systems Manager come descritto in questa sezione, le macchine attivate in modalità ibrida vengono elencate Console di gestione AWS e descritte come nodi gestiti.* Nella console, gli ID dei nodi gestiti attivati da sistemi ibridi sono distinti dalle istanze Amazon EC2 tramite il prefisso "mi-". Le istanze Amazon EC2 IDs utilizzano il prefisso «i-». Un nodo gestito è un computer configurato per l'uso con Systems Manager. In precedenza, i nodi gestiti erano tutti indicati come istanze gestite. Il termine *istanza* ora si riferisce solo alle istanze EC2. Il [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html)comando è stato denominato prima di questa modifica terminologica. Per ulteriori informazioni, consulta [Utilizzo dei nodi gestiti](fleet-manager-managed-nodes.md). **Importante** Si consiglia 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. **Informazioni sui livelli di istanza** Systems Manager offre un piano istanze standard e un piano istanze avanzate per i nodi gestiti non EC2 nel tuo ambiente ibrido e multicloud. Il piano istanze standard consente di registrare un massimo di 1.000 macchine attivate da sistemi ibridi per Account AWS per Regione AWS. Se devi registrare più di 1.000 macchine non-EC2 in un singolo account e Regione, utilizza il piano istanze avanzate. Le istanze avanzate consentono inoltre di connettersi a macchine non EC2 utilizzando. AWS Systems Manager Session Manager Session Managerfornisce l'accesso interattivo tramite shell ai nodi gestiti. Per ulteriori informazioni, consulta [Configurazione dei livelli di istanza](fleet-manager-configure-instance-tiers.md). **Topics** + [ # Creazione di un ruolo di servizio IAM richiesto per System Manager in ambiente ibrido e multicloud ](hybrid-multicloud-service-role.md) + [ # Crea un'attivazione ibrida per registrare i nodi con Systems Manager ](hybrid-activation-managed-nodes.md) + [ # Installare SSM Agent su nodi Linux ibridi ](hybrid-multicloud-ssm-agent-install-linux.md) + [ # Installazione di SSM Agent su nodi ibridi di Windows Server ](hybrid-multicloud-ssm-agent-install-windows.md) # Creazione di un ruolo di servizio IAM richiesto per System Manager in ambiente ibrido e multicloud Le macchine non EC2 (Amazon Elastic Compute Cloud) in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) richiedono un ruolo di servizio AWS Identity and Access Management (IAM) per comunicare con il servizio. AWS Systems Manager Il ruolo concede AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) attendibile al servizio Systems Manager. Il ruolo di servizio per un ambiente ibrido e multicloud deve essere creato una sola volta per ogni Account AWS. Tuttavia, è possibile scegliere di creare più ruoli di servizio per diverse attivazioni ibride se le macchine dell'ambiente ibrido e multicloud richiedono autorizzazioni diverse. Le procedure seguenti descrivono come creare il ruolo di servizio necessario utilizzando la console di Systems Manager o lo strumento a riga di comando preferito. ## Utilizzo Console di gestione AWS di per creare un ruolo di servizio IAM per le attivazioni ibride di Systems Manager La seguente procedura consente di creare un ruolo di servizio per un'attivazione ibrida. Questa procedura utilizza la policy `AmazonSSMManagedInstanceCore` per la funzionalità di base di Systems Manager. A seconda del caso d'uso, potrebbe essere necessario aggiungere ulteriori policy al ruolo di servizio per le macchine on-premises, in modo che tu possa accedere ad altri strumenti di Systems Manager o ai Servizi AWS. Ad esempio, senza l'accesso ai bucket Patch Manager Amazon Simple Storage Service (Amazon S3) AWS gestiti richiesti, le operazioni di patching falliscono. **Per creare un ruolo di servizio (console)** 1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Nel pannello di navigazione, scegli **Ruoli** e quindi **Crea ruolo**. 1. Per **Seleziona un'entità attendibile**, effettua le seguenti selezioni: 1. Per **Tipo di entità attendibile**, seleziona **Servizio AWS**. 1. Per **casi d'uso per altri Servizi AWS**, scegli **Systems Manager**. 1. Scegli **Systems Manager**. L'immagine seguente evidenzia la posizione dell'opzione Systems Manager. ![\[Systems Manager è una delle opzioni per Caso d'uso.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/iam_use_cases_for_MWs.png) 1. Scegli **Successivo**. 1. Nella pagina **Add permissions** (Aggiungi autorizzazioni), esegui le operazioni seguenti: + Utilizza il campo **di ricerca** per individuare la SSMManaged InstanceCore politica di **Amazon**. Seleziona la casella di controllo accanto al relativo nome, come illustrato nella figura seguente. ![\[La casella di controllo è selezionata nella SSMManaged InstanceCore riga Amazon.\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/setup-instance-profile-2.png) **Nota** La console mantiene la selezione anche se cerchi altre policy. + Se nella procedura [(Facoltativo) Creazione di una policy personalizzata per l'accesso al bucket S3](setup-instance-permissions.md#instance-profile-custom-s3-policy) hai creato una policy di bucket S3 personalizzata, cercala e seleziona la casella accanto al suo nome. + Se intendi aggiungere macchine non EC2 a un Active Directory gestito da Directory Service, cerca **Amazon SSMDirectory ServiceAccess** e seleziona la casella di controllo accanto al suo nome. + Se intendi utilizzare EventBridge or CloudWatch Logs per gestire o monitorare il nodo gestito, cerca **CloudWatchAgentServerPolicy**e seleziona la casella di controllo accanto al suo nome. 1. Scegli **Next (Successivo)**. 1. Per **Nome ruolo**, inserisci un nome per il nuovo ruolo del server IAM, ad esempio **SSMServerRole**. **Nota** Prendi nota del nome del ruolo. Potrai scegliere questo ruolo quando registri nuove macchine che desideri gestire utilizzando Systems Manager. 1. (Facoltativo) Per **Descrizione ruolo**, aggiorna la descrizione di questo ruolo del server IAM. 1. (Facoltativo) In **Tag**, aggiungi una o più coppie tag chiave-valore per organizzare, monitorare o controllare l'accesso per questo ruolo. 1. Scegliere **Crea ruolo**. Il sistema visualizza di nuovo la pagina **Ruoli**. ## Utilizzo AWS CLI di per creare un ruolo di servizio IAM per le attivazioni ibride di Systems Manager La seguente procedura consente di creare un ruolo di servizio per un'attivazione ibrida. Questa procedura utilizza la policy `AmazonSSMManagedInstanceCore` per la funzionalità di base di Systems Manager. A seconda del caso d'uso, potrebbe essere necessario aggiungere ulteriori policy al ruolo di servizio per le macchine non EC2 in un ambiente [ibrido e multi-cloud](operating-systems-and-machine-types.md#supported-machine-types), in modo che tu possa accedere ad altri strumenti o ai Servizi AWS. **Requisito delle policy di bucket S3** Se uno dei seguenti casi è true, è necessario creare una policy di autorizzazione IAM personalizzata per i bucket Amazon Simple Storage Service (Amazon S3) prima di completare questa procedura: + **Caso 1**: stai utilizzando un endpoint VPC per connettere privatamente il tuo VPC a servizi endpoint VPC supportati Servizi AWS e basati su. AWS PrivateLink + **Caso 2**: prevedi di utilizzare un bucket Amazon S3 che hai creato durante le operazioni di Systems Manager, ad esempio per archiviare l'output per i comandi Run Command o le sessioni Session Manager in un bucket S3. Prima di procedere, segui i passaggi descritti in [Creare una policy di bucket S3 personalizzata per un profilo dell'istanza](setup-instance-permissions.md#instance-profile-custom-s3-policy). Le informazioni sulle policy dei bucket S3 fornite in quell'argomento sono valide anche per il ruolo di servizio. ------ #### [ AWS CLI ] **Per creare un ruolo di servizio IAM per un ambiente ibrido e multicloud (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 file di testo con un nome, ad esempio `SSMService-Trust.json` con la seguente policy di attendibilità. Salvare il file con l'estensione `.json`. Assicurati di specificare il tuo Account AWS e il Regione AWS nell'ARN in cui hai creato l'attivazione ibrida. Sostituisci *placeholder values* l'ID e la regione dell'account con le tue informazioni. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"", "Effect":"Allow", "Principal":{ "Service":"ssm.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"123456789012" }, "ArnEquals":{ "aws:SourceArn":"arn:aws:ssm:us-east-1:111122223333:*" } } } ] } ``` ------ 1. Apri e AWS CLI, nella directory in cui hai creato il file JSON, esegui il comando [create-role per creare il ruolo](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) di servizio. Questo esempio crea un ruolo denominato `SSMServiceRole`. È possibile scegliere un nome diverso. ------ #### [ Linux & macOS ] ``` aws iam create-role \ --role-name SSMServiceRole \ --assume-role-policy-document file://SSMService-Trust.json ``` ------ #### [ Windows ] ``` aws iam create-role ^ --role-name SSMServiceRole ^ --assume-role-policy-document file://SSMService-Trust.json ``` ------ 1. Esegui il [attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)comando come segue per consentire al ruolo di servizio appena creato di creare un token di sessione. Il token della sessione concede al nodo gestito l'autorizzazione di eseguire comandi utilizzando Systems Manager. **Nota** Le policy aggiunte per un profilo del servizio per i nodi gestiti in un ambiente ibrido e multicloud sono le stesse policy utilizzate per la creazione di un profilo dell'istanza per Amazon Elastic Compute Cloud (Amazon EC2). Per ulteriori informazioni sulle policy AWS utilizzate nei seguenti comandi, consulta [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md). (Obbligatorio) Esegui il comando seguente per consentire a un nodo gestito di utilizzare le funzionalità AWS Systems Manager di base del servizio. ------ #### [ Linux & macOS ] ``` aws iam attach-role-policy \ --role-name SSMServiceRole \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore ``` ------ #### [ Windows ] ``` aws iam attach-role-policy ^ --role-name SSMServiceRole ^ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore ``` ------ Se hai creato una policy personalizzata per i bucket S3 per il tuo ruolo di servizio, esegui il comando seguente per consentire ad AWS Systems Manager Agent (SSM Agent) di accedere ai bucket specificati nella policy. Sostituisci *account-id* e *amzn-s3-demo-bucket* con il tuo Account AWS ID e il nome del tuo bucket. ------ #### [ Linux & macOS ] ``` aws iam attach-role-policy \ --role-name SSMServiceRole \ --policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket ``` ------ #### [ Windows ] ``` aws iam attach-role-policy ^ --role-name SSMServiceRole ^ --policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket ``` ------ (Facoltativo) Esegui il comando seguente SSM Agent per consentire l'accesso per tuo Directory Service conto alle richieste di aggiunta al dominio da parte del nodo gestito. Il ruolo di servizio necessita di questa policy solo se aggiungi i nodi a una directory Microsoft AD. ------ #### [ Linux & macOS ] ``` aws iam attach-role-policy \ --role-name SSMServiceRole \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess ``` ------ #### [ Windows ] ``` aws iam attach-role-policy ^ --role-name SSMServiceRole ^ --policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess ``` ------ (Facoltativo) Esegui il comando seguente per consentire all' CloudWatch agente di funzionare sui tuoi nodi gestiti. Questo comando consente di leggere le informazioni su un nodo e scriverle su CloudWatch. Il tuo profilo di servizio necessita di questa politica solo se utilizzerai servizi come Amazon EventBridge o Amazon CloudWatch Logs. ``` aws iam attach-role-policy \ --role-name SSMServiceRole \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy ``` ------ #### [ Tools for PowerShell ] **Per creare un ruolo di servizio IAM per un ambiente ibrido e multicloud (AWS Tools for Windows 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 file di testo con un nome, ad esempio `SSMService-Trust.json` con la seguente policy di attendibilità. Salvare il file con l'estensione `.json`. Assicurati di specificare il tuo Account AWS e il Regione AWS nell'ARN in cui hai creato l'attivazione ibrida. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ssm.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": "arn:aws:ssm:us-east-1:123456789012:*" } } } ] } ``` ------ 1. Apri PowerShell in modalità amministrativa e nella directory in cui hai creato il file JSON, esegui [New- IAMRole](https://docs.aws.amazon.com//powershell/latest/reference/items/Register-IAMRolePolicy.html) come segue per creare un ruolo di servizio. Questo esempio crea un ruolo denominato `SSMServiceRole`. È possibile scegliere un nome diverso. ``` New-IAMRole ` -RoleName SSMServiceRole ` -AssumeRolePolicyDocument (Get-Content -raw SSMService-Trust.json) ``` 1. Utilizzate [Register- IAMRole Policy](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-IAMRolePolicy.html) come segue per consentire al ruolo di servizio creato di creare un token di sessione. Il token della sessione concede al nodo gestito l'autorizzazione di eseguire comandi utilizzando Systems Manager. **Nota** Le policy aggiunte per un profilo del servizio per i nodi gestiti in un ambiente ibrido e multicloud sono le stesse policy utilizzate per la creazione di un profilo dell'istanza per EC2. Per ulteriori informazioni sulle AWS politiche utilizzate nei seguenti comandi, vedere [Configurazione delle autorizzazioni di istanza richieste per Systems Manager](setup-instance-permissions.md). (Obbligatorio) Esegui il comando seguente per consentire a un nodo gestito di utilizzare le funzionalità AWS Systems Manager di base del servizio. ``` Register-IAMRolePolicy ` -RoleName SSMServiceRole ` -PolicyArn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore ``` Se è stata creata una policy di bucket S3 personalizzata per il ruolo di servizio, esegui il comando seguente per abilitare SSM Agent per l'accesso al bucket specificato nella policy. Sostituisci *account-id* e *my-bucket-policy-name* con il tuo Account AWS ID e il nome del tuo bucket. ``` Register-IAMRolePolicy ` -RoleName SSMServiceRole ` -PolicyArn arn:aws:iam::account-id:policy/my-bucket-policy-name ``` (Facoltativo) Esegui il comando seguente SSM Agent per consentire l'accesso per tuo Directory Service conto alle richieste di aggiunta al dominio da parte del nodo gestito. Il ruolo del server necessita di questa policy solo se aggiungi i nodi a una directory Microsoft AD. ``` Register-IAMRolePolicy ` -RoleName SSMServiceRole ` -PolicyArn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess ``` (Facoltativo) Esegui il comando seguente per consentire all' CloudWatch agente di funzionare sui tuoi nodi gestiti. Questo comando consente di leggere le informazioni su un nodo e scriverle su CloudWatch. Il tuo profilo di servizio necessita di questa politica solo se utilizzerai servizi come Amazon EventBridge o Amazon CloudWatch Logs. ``` Register-IAMRolePolicy ` -RoleName SSMServiceRole ` -PolicyArn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy ``` ------ Continua su [Crea un'attivazione ibrida per registrare i nodi con Systems Manager](hybrid-activation-managed-nodes.md). # Crea un'attivazione ibrida per registrare i nodi con Systems Manager Per configurare macchine diverse dalle istanze Amazon Elastic Compute Cloud (EC2) come nodi gestiti per un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types), devi creare e applicare un’*attivazione ibrida*. Una volta completata l'attivazione, ricevi *immediatamente* un codice e un ID di attivazione nella parte superiore della pagina della console. Specificate questa combinazione di codice e ID quando installate AWS Systems Manager SSM Agent su macchine non EC2 per il vostro ambiente ibrido e multicloud. Il codice e l'ID forniscono accesso sicuro al servizio Systems Manager dai nodi gestiti. **Importante** Systems Manager restituisce immediatamente il codice e l’ID di attivazione alla console o finestra di comando, a seconda di come è stato creata l’attivazione. Copia queste informazioni e archiviale in un luogo sicuro. Se esci dalla console o chiudi la finestra di comando, potresti perdere queste informazioni. Se le smarrisci, devi creare una nuova attivazione. **Informazioni sulle scadenze dell'attivazione** Una *scadenza dell'attivazione* è una finestra temporale durante la quale è possibile registrare macchine on-premises su Systems Manager. Un'attivazione scaduta non ha alcun impatto sui server o VMs sulla registrazione precedente con Systems Manager. Se un'attivazione scade, non è possibile registrare più server o VMs con Systems Manager utilizzando quella specifica attivazione. È necessario crearne una nuova. Ogni server e macchina virtuale (VM) on-premises registrata in precedenza rimane registrata come nodo gestito di Systems Manager, fino a quando annulli la registrazione esplicitamente. Puoi annullare la registrazione di un nodo gestito non EC2 nei seguenti modi: + Utilizza la scheda **Nodi gestiti** in Fleet Manager nella console Systems Manager + Usa il comando AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) + Utilizza l'azione API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html). Per ulteriori informazioni, consulta 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) + [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) **Informazioni sui nodi gestiti** Un nodo gestito è qualsiasi macchina configurata per AWS Systems Manager. AWS Systems Manager supporta istanze Amazon Elastic Compute Cloud (Amazon EC2), dispositivi edge e server VMs locali o, anche in altri ambienti cloud. VMs In precedenza, i nodi gestiti erano tutti indicati come istanze gestite. Il termine *istanza* ora si riferisce solo alle istanze EC2. Il [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html)comando è stato denominato prima di questa modifica terminologica. **Informazioni sui tag di attivazione** Se si crea un'attivazione utilizzando AWS Command Line Interface (AWS CLI) o AWS Tools for Windows PowerShell, è possibile specificare i tag. 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. Di seguito è AWS CLI riportato un comando di esempio da eseguire nella regione Stati Uniti orientali (Ohio) su un computer Linux locale che include tag opzionali. ``` aws ssm create-activation \ --default-instance-name MyWebServers \ --description "Activation for Finance department webservers" \ --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \ --registration-limit 10 \ --region us-east-2 \ --tags "Key=Department,Value=Finance" ``` Se specifichi i tag durante la creazione di un'attivazione, tali tag vengono automaticamente assegnati ai nodi gestiti al momento della loro attivazione. Non puoi aggiungere o eliminare tag da un'attivazione esistente. Se non desideri assegnare automaticamente i tag ai tuoi server locali e VMs utilizzare un'attivazione, puoi aggiungerli in un secondo momento. In particolare, è possibile etichettare i server locali e VMs dopo che si connettono a Systems Manager per la prima volta. Dopo la connessione, gli viene assegnato un ID nodo gestito elencato nella console Systems Manager con un ID preceduto da "mi-". **Nota** Non puoi assegnare tag a un'attivazione se questa viene creata utilizzando la console Systems Manager. È necessario crearlo utilizzando AWS CLI o Tools for Windows PowerShell. Se non desideri più gestire un server on-premises o una macchina virtuale (VM) con Systems Manager puoi annullare la registrazione. Per informazioni, consulta [Annullamento della registrazione dei nodi gestiti in un ambiente ibrido e multicloud](fleet-manager-deregister-hybrid-nodes.md). **Topics** + [ ## Utilizzo Console di gestione AWS di per creare un'attivazione per la registrazione dei nodi gestiti con Systems Manager ](#create-managed-node-activation-console) + [ ## Utilizzo della riga di comando per creare un'attivazione per la registrazione dei nodi gestiti con Systems Manager ](#create-managed-node-activation-command-line) ## Utilizzo Console di gestione AWS di per creare un'attivazione per la registrazione dei nodi gestiti con Systems Manager **Per creare un'attivazione di un nodo gestito** 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, selezionare**Attivazioni ibride**. 1. Scegli **Create activation (Crea attivazione)**. oppure Se accedi ad **Hybrid Activations** per la prima volta nella versione corrente Regione AWS, scegli **Crea un'attivazione**. 1. (Facoltativo) Per **Activation description** (Descrizione attivazione), inserisci una descrizione per questa attivazione. Ti consigliamo di inserire una descrizione se prevedi di attivare un numero elevato di server e VMs. 1. Ad **esempio Limite** di istanza, specifica il numero totale di nodi con cui desideri registrarti AWS come parte di questa attivazione. Il valore predefinito è una istanza. 1. Per il **ruolo IAM**, scegli un'opzione di ruolo di servizio che VMs consenta ai tuoi server di comunicare con loro AWS Systems Manager nel cloud: + **Opzione 1**: scegli **Use the default role created by the system** (Usa il ruolo predefinito creato dal sistema) per utilizzare un ruolo e una policy gestita fornita da AWS. + **Opzione 2**: scegli **Seleziona un ruolo IAM personalizzato esistente con le autorizzazioni necessarie** per utilizzare il ruolo personalizzato facoltativo che hai creato in precedenza. A tale ruolo deve essere associato una policy di relazione di trust che specifichi `"Service": "ssm.amazonaws.com"`. Se il ruolo IAM non specifica questo principio in una policy di relazione di trust, viene visualizzato il seguente errore: ``` An error occurred (ValidationException) when calling the CreateActivation operation: Not existing role: arn:aws:iam:::role/SSMRole ``` Per ulteriori informazioni sulla creazione di questo ruolo, consultare [Creazione di un ruolo di servizio IAM richiesto per System Manager in ambiente ibrido e multicloud](hybrid-multicloud-service-role.md). 1. Per **Activation expiry date** (Data di scadenza dell'attivazione), specifica una data di scadenza per l'attivazione. La data di scadenza deve essere in futuro e non più di 30 giorni in futuro. Il valore predefinito è 24 ore. **Nota** Se vuoi registrare nodi gestiti aggiuntivi dopo la scadenza, devi creare una nuova attivazione. La data di scadenza non ha alcun impatto sui nodi registrati e in esecuzione. 1. (Facoltativo) Nel campo **Default instance name** (Nome predefinito dell'istanza), specifica un valore di nome identificativo da visualizzare per tutti i nodi gestiti associati a questa attivazione. 1. Scegli **Create activation (Crea attivazione)**. Systems Manager restituisce immediatamente il codice di attivazione e l'ID alla console. ## Utilizzo della riga di comando per creare un'attivazione per la registrazione dei nodi gestiti con Systems Manager La procedura seguente descrive come utilizzare AWS Command Line Interface (AWS CLI) (su Linux oWindows Server) o AWS Strumenti per PowerShell creare un'attivazione gestita del nodo. **Per creare un'attivazione** 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 seguente per creare un'attivazione. **Nota** Nel comando seguente, sostituiscilo *region* con le tue informazioni. 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* Il ruolo specificato per il *iam-role* parametro deve avere una politica di relazione di fiducia che specifichi`"Service": "ssm.amazonaws.com"`. Se il tuo ruolo AWS Identity and Access Management (IAM) non specifica questo principio in una politica di relazione di fiducia, ricevi il seguente errore: ``` An error occurred (ValidationException) when calling the CreateActivation operation: Not existing role: arn:aws:iam:::role/SSMRole ``` Per ulteriori informazioni sulla creazione di questo ruolo, consultare [Creazione di un ruolo di servizio IAM richiesto per System Manager in ambiente ibrido e multicloud](hybrid-multicloud-service-role.md). Per `--expiration-date`, fornire una data in formato timestamp, ad esempio `"2021-07-07T00:00:00"`, per quando scade il codice di attivazione. È possibile specificare una data fino a 30 giorni di anticipo. Se non fornisci una data di scadenza, il codice di attivazione scade tra 24 ore. ------ #### [ Linux & macOS ] ``` aws ssm create-activation \ --default-instance-name name \ --iam-role iam-service-role-name \ --registration-limit number-of-managed-instances \ --region region \ --expiration-date "timestamp" \\ --tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2" ``` ------ #### [ Windows ] ``` aws ssm create-activation ^ --default-instance-name name ^ --iam-role iam-service-role-name ^ --registration-limit number-of-managed-instances ^ --region region ^ --expiration-date "timestamp" ^ --tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2" ``` ------ #### [ PowerShell ] ``` New-SSMActivation -DefaultInstanceName name ` -IamRole iam-service-role-name ` -RegistrationLimit number-of-managed-instances ` –Region region ` -ExpirationDate "timestamp" ` -Tag @{"Key"="key-name-1";"Value"="key-value-1"},@{"Key"="key-name-2";"Value"="key-value-2"} ``` ------ Ecco un esempio. ------ #### [ Linux & macOS ] ``` aws ssm create-activation \ --default-instance-name MyWebServers \ --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \ --registration-limit 10 \ --region us-east-2 \ --expiration-date "2021-07-07T00:00:00" \ --tags "Key=Environment,Value=Production" "Key=Department,Value=Finance" ``` ------ #### [ Windows ] ``` aws ssm create-activation ^ --default-instance-name MyWebServers ^ --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances ^ --registration-limit 10 ^ --region us-east-2 ^ --expiration-date "2021-07-07T00:00:00" ^ --tags "Key=Environment,Value=Production" "Key=Department,Value=Finance" ``` ------ #### [ PowerShell ] ``` New-SSMActivation -DefaultInstanceName MyWebServers ` -IamRole service-role/AmazonEC2RunCommandRoleForManagedInstances ` -RegistrationLimit 10 ` –Region us-east-2 ` -ExpirationDate "2021-07-07T00:00:00" ` -Tag @{"Key"="Environment";"Value"="Production"},@{"Key"="Department";"Value"="Finance"} ``` ------ Se l'attivazione viene creata correttamente, il sistema restituisce immediatamente un codice e un ID di attivazione. # Installare SSM Agent su nodi Linux ibridi Questo argomento descrive come installare AWS Systems Manager SSM Agent su macchine Linux non EC2 (Amazon Elastic Compute Cloud) in un ambiente [ibrido e](operating-systems-and-machine-types.md#supported-machine-types) multicloud. Per informazioni sull'installazione di SSM Agent su istanze EC2 per Linux, consulta [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Linux](manually-install-ssm-agent-linux.md). Prima di iniziare, individua il codice e l'ID di attivazione generati durante il processo di attivazione ibrida, come descritto in [Crea un'attivazione ibrida per registrare i nodi con Systems Manager](hybrid-activation-managed-nodes.md). È possibile specificare il codice e l'ID nella procedura seguente. **Per installare SSM Agent su macchine non EC2 in un ambiente ibrido e multicloud** 1. Accedi a un server o una macchina virtuale all'interno dell'ambiente ibrido e multicloud. 1. Se si utilizza un proxy HTTP o HTTPS, è necessario impostare l'`http_proxy`o`https_proxy`nella sessione della shell corrente. Se non utilizzi un proxy, questa fase può essere ignorata. Per un server proxy HTTP, immettere i comandi seguenti nella riga di comando: ``` export http_proxy=http://hostname:port export https_proxy=http://hostname:port ``` Per un server proxy HTTPS, immettere i comandi seguenti nella riga di comando: ``` export http_proxy=http://hostname:port export https_proxy=https://hostname:port ``` 1. Copia e incolla uno dei seguenti blocchi di comandi in SSH. Sostituisci i valori segnaposto con il Codice di attivazione e l'ID di attivazione generati durante il processo di attivazione ibrida e con l'identificatore del file da Regione AWS cui desideri scaricare, quindi premi. SSM Agent `Enter` **Importante** Tieni presenti queste importanti informazioni relative a questo processo: L'utilizzo di `ssm-setup-cli` per installazioni non EC2 massimizza la sicurezza dell'installazione e della configurazione di Systems Manager. `sudo`non è necessario se sei un utente root. Effettua il download `ssm-setup-cli` dalla Regione AWS stessa pagina in cui è stata creata l'attivazione ibrida. La `ssm-setup-cli` supporta un'opzione `manifest-url` che determina l'origine da cui viene scaricato l'agente. Non specificare un valore per questa opzione a meno che non sia richiesto dall'organizzazione. Durante la registrazione delle istanze, utilizza solo il link per il download fornito per la `ssm-setup-cli`. La `ssm-setup-cli` non deve essere conservata separatamente per usi futuri. Utilizza lo script fornito [qui](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_linux.sh) per convalidare la firma di `ssm-setup-cli`. *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* Inoltre, la `ssm-setup-cli` include le seguenti opzioni: + `version`: i valori validi sono `latest` e `stable`. + `downgrade`: consente il downgrade di SSM Agent a una versione precedente. Specifica `true` per installare una versione precedente dell'agente. + `skip-signature-validation`: ignora la convalida della firma durante il download e l'installazione dell'agente. ## Amazon Linux 2, RHEL 7.x e Oracle Linux ``` mkdir /tmp/ssm curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli sudo chmod +x /tmp/ssm/ssm-setup-cli sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region" ``` ## RHEL 8.x ``` mkdir /tmp/ssm curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli sudo chmod +x /tmp/ssm/ssm-setup-cli sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region" ``` ## Debian Server ``` mkdir /tmp/ssm curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli sudo chmod +x /tmp/ssm/ssm-setup-cli sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region" ``` ## Ubuntu Server + **Utilizzo dei pacchetti .deb** ``` mkdir /tmp/ssm curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli sudo chmod +x /tmp/ssm/ssm-setup-cli sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region" ``` + **Utilizzo dei pacchetti Snap** Non è necessario specificare un URL per il download, perché il comando `snap` scarica automaticamente l'agente dall'[app store Snap](https://snapcraft.io/amazon-ssm-agent) all'indirizzo [https://snapcraft.io](https://snapcraft.io). Su Ubuntu Server 20.4, 18.04 e 16.04 LTS, i file del programma di installazione di SSM Agent, compresi i file binari dell'agente e i file di configurazione, vengono archiviati nella seguente directory: `/snap/amazon-ssm-agent/current/`. Se apporti modifiche ai file di configurazione in questa directory, devi copiare questi file dalla cartella `/snap` nella cartella `/etc/amazon/ssm/`. I file di log e della libreria non sono cambiati (`/var/lib/amazon/ssm`, `/var/log/amazon/ssm`). ``` sudo snap install amazon-ssm-agent --classic sudo systemctl stop snap.amazon-ssm-agent.amazon-ssm-agent.service sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region" sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service ``` **Importante** La*candidato*nell'archivio Snap contiene l'ultima versione diSSM Agent; non il canale stabile. Se desideri tenere traccia delle informazioni sulla versione SSM Agent sul canale candidato, esegui il comando seguente sui nodi gestiti 18.04 e 16.04 LTS a 64 bit di Ubuntu Server. ``` sudo snap switch --channel=candidate amazon-ssm-agent ``` Il comando scarica e installa SSM Agent sulla macchina attivata da sistemi ibridi nell'ambiente ibrido e multicloud. Il comando interrompe SSM Agent e quindi registra la macchina con il servizio Systems Manager. La macchina è ora un nodo gestito. Le istanze Amazon EC2 configurate per Systems Manager sono anche nodi gestiti. Nella console di Systems Manager, tuttavia, i nodi attivati da sistemi ibridi si distinguono dalle istanze Amazon EC2 tramite il prefisso "mi-". Continua su [Installazione di SSM Agent su nodi ibridi di Windows Server](hybrid-multicloud-ssm-agent-install-windows.md). ## Impostazione della rotazione automatica della chiave privata Per rafforzare il tuo livello di sicurezza, puoi configurare AWS Systems Manager Agent (SSM Agent) in modo che ruoti automaticamente la chiave privata per il tuo ambiente ibrido e multicloud. È possibile accedere a questa funzionalità utilizzandoSSM Agent3.0.1031.0 o versioni successive Attivare questa funzionalità seguendo la procedura seguente. **Per configurare SSM Agent per ruotare la chiave privata di un ambiente ibrido e multicloud** 1. Accedi a `/etc/amazon/ssm/` su una macchina Linux o `C:\Program Files\Amazon\SSM` per una macchina Windows. 1. Copiare il contenuto di`amazon-ssm-agent.json.template`In un nuovo file denominato`amazon-ssm-agent.json`. Save (Salva)`amazon-ssm-agent.json`nella stessa directory dove`amazon-ssm-agent.json.template`si trova. 1. Trova `Profile`, `KeyAutoRotateDays`. Immettere il numero di giorni desiderato tra le rotazioni automatiche della chiave privata. 1. Riavviare SSM Agent. Ogni volta che si modifica la configurazione, riavviareSSM Agent. È possibile personalizzare altre funzionalità di SSM Agent utilizzando la stessa procedura. Per un up-to-date elenco delle proprietà di configurazione disponibili e dei relativi valori predefiniti, vedere [Config Property](https://github.com/aws/amazon-ssm-agent#config-property-definitions) Definitions. ## Annullamento della registrazione e nuova registrazione di un nodo gestito (Linux) È possibile annullare la registrazione di un nodo gestito ad attivazione ibrida richiamando l'operazione [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html)API da o Tools for Windows. AWS CLI PowerShell Di seguito è illustrato un esempio di comando CLI: `aws ssm deregister-managed-instance --instance-id "mi-1234567890"` Per rimuovere le informazioni di registrazione rimanenti per l'agente, rimuovi la chiave `IdentityConsumptionOrder` dal file `amazon-ssm-agent.json`. Quindi, a seconda del tipo di installazione, esegui uno dei seguenti comandi. Sui nodi Ubuntu Server in cui è stato installato SSM Agent utilizzando i pacchetti Snap: ``` sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -clear ``` Su tutte le altre installazioni Linux: ``` amazon-ssm-agent -register -clear ``` **Nota** Puoi registrare nuovamente un server on-premises, un dispositivo edge 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 istanza per un codice e un ID di attivazione chiamando l'API [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) utilizzando il AWS CLI. Dopo aver eseguito il comando, verifica che il valore di `RegistrationCount` non sia superiore a `RegistrationLimit`. Se è maggiore, è necessario utilizzare un codice e un ID di attivazione diversi. **Per registrare nuovamente un nodo gestito su una macchina Linux non EC2** 1. Connettiti alla macchina. 1. Eseguire il seguente comando seguente. Assicurati di sostituire i valori segnaposto con il codice e l'ID di attivazione generati quando hai creato un'attivazione del nodo gestito e con l'identificativo della Regione da cui desideri scaricare l'SSM Agent. ``` echo "yes" | sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region ``` ## Risoluzione dei problemi di installazione di SSM Agent su macchine Linux non EC2 Usa le informazioni seguenti per risolvere i problemi relativi all'installazione di SSM Agent su macchine Linux attivate da sistemi ibridi in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). ### DeliveryTimedOut Viene visualizzato un errore **Problema**: durante la configurazione di una macchina in una macchina Account AWS come nodo gestito per un altro nodo Account AWS, si ricevono `DeliveryTimedOut` dopo aver eseguito i comandi da installare SSM Agent sul computer di destinazione. **Soluzione**:`DeliveryTimedOut`è il codice di risposta previsto per questo scenario. Il comando per installare SSM Agent sul nodo target modifica l'ID del nodo di origine. Poiché l'ID nodo è stato modificato, il nodo di origine non è in grado di comunicare al nodo di destinazione che il comando non è riuscito, completato o scaduto durante l'esecuzione. ### Impossibile caricare le associazioni del nodo **Problema**: dopo aver eseguito i comandi di installazione, viene visualizzato il seguente errore nei log di errore dell'SSM Agent: `Unable to load instance associations, unable to retrieve associations unable to retrieve associations error occurred in RequestManagedInstanceRoleToken: MachineFingerprintDoesNotMatch: Fingerprint doesn't match` Questo errore viene visualizzato quando l'ID macchina non persiste dopo un riavvio. **Soluzione**: Per risolvere questo problema, eseguire il comando seguente. Questo comando costringe l'ID macchina a mantenere l'aspetto persistente dopo un riavvio. ``` umount /etc/machine-id systemd-machine-id-setup ``` # Installazione di SSM Agent su nodi ibridi di Windows Server Questo argomento descrive come eseguire l'installazione AWS Systems Manager SSM Agent su Windows Server macchine in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). Per informazioni sull'installazione di SSM Agent su istanze EC2 per Windows Server consultare [Installazione e disinstallazione manuale di SSM Agent su istanze EC2 per Windows Server](manually-install-ssm-agent-windows.md). Prima di iniziare, individua il codice e l'ID di attivazione generati durante il processo di attivazione ibrida, come descritto in [Crea un'attivazione ibrida per registrare i nodi con Systems Manager](hybrid-activation-managed-nodes.md). È possibile specificare il codice e l'ID nella procedura seguente. **Per installare SSM Agent su macchine Windows Server non EC2 in un ambiente ibrido e multicloud** 1. Accedi a un server o una macchina virtuale all'interno dell'ambiente ibrido e multicloud. 1. Se si utilizza un proxy HTTP o HTTPS, è necessario impostare l'`http_proxy`o`https_proxy`nella sessione della shell corrente. Se non utilizzi un proxy, questa fase può essere ignorata. Per un server proxy HTTP, impostare la variabile seguente: ``` http_proxy=http://hostname:port https_proxy=http://hostname:port ``` Per un server proxy HTTPS, impostare questa variabile: ``` http_proxy=http://hostname:port https_proxy=https://hostname:port ``` Per PowerShell, configura le impostazioni del INet proxy Win: ``` [System.Net.WebRequest]::DefaultWebProxy $proxyServer = "http://hostname:port" $proxyBypass = "169.254.169.254" $WebProxy = New-Object System.Net.WebProxy($proxyServer,$true,$proxyBypass) [System.Net.WebRequest]::DefaultWebProxy = $WebProxy ``` **Nota** La configurazione INet del proxy Win è necessaria per PowerShell le operazioni. Per ulteriori informazioni, consulta [Impostazioni del proxy di SSM Agent e servizi di Systems Manager](configure-proxy-ssm-agent-windows.md#ssm-agent-proxy-services). 1. Apri Windows PowerShell come amministratore. 1. Copia e incolla il seguente blocco di comandi in Windows PowerShell. Sostituisci ogni *example resource placeholder* con le tue informazioni. Ad esempio, il codice di attivazione e l'ID di attivazione generati quando si crea un'attivazione ibrida e con l'identificatore SSM Agent da Regione AWS cui si desidera effettuare il download. **Importante** Tieni presenti queste importanti informazioni relative a questo processo: L'utilizzo di `ssm-setup-cli` per installazioni non EC2 massimizza la sicurezza dell'installazione e della configurazione di Systems Manager. La `ssm-setup-cli` supporta un'opzione `manifest-url` che determina l'origine da cui viene scaricato l'agente. Non specificare un valore per questa opzione a meno che non sia richiesto dall'organizzazione. Utilizza lo script fornito [qui](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_windows.ps1) per convalidare la firma di `ssm-setup-cli`. Durante la registrazione delle istanze, utilizza solo il link per il download fornito per la `ssm-setup-cli`. La `ssm-setup-cli` non deve essere conservata separatamente per usi futuri. *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* Inoltre, la `ssm-setup-cli` include le seguenti opzioni: + `version`: i valori validi sono `latest` e `stable`. + `downgrade`: riporta l'agente a una versione precedente. + `skip-signature-validation`: ignora la convalida della firma durante il download e l'installazione dell'agente. ------ #### [ 64-bit ] ``` [System.Net.ServicePointManager]::SecurityProtocol = 'TLS12' $code = "activation-code" $id = "activation-id" $region = "us-east-1" $dir = $env:TEMP + "\ssm" New-Item -ItemType directory -Path $dir -Force cd $dir (New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.$region.amazonaws.com/latest/windows_amd64/ssm-setup-cli.exe", $dir + "\ssm-setup-cli.exe") ./ssm-setup-cli.exe -register -activation-code="$code" -activation-id="$id" -region="$region" Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration") Get-Service -Name "AmazonSSMAgent" ``` ------ 1. Premi `Enter`. **Nota** Se il comando ha esito negativo, verificare che sia in esecuzione la versione più recente di AWS Strumenti per PowerShell. Il comando esegue quanto segue: + Scarica e installa SSM Agent sulla macchina. + Registra la macchina con il servizio Systems Manager. + Restituisce una risposta alla richiesta simile a quella riportata di seguito: ``` Directory: C:\Users\ADMINI~1\AppData\Local\Temp\2 Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 07/07/2018 8:07 PM ssm {"ManagedInstanceID":"mi-008d36be46EXAMPLE","Region":"us-east-2"} Status : Running Name : AmazonSSMAgent DisplayName : Amazon SSM Agent ``` La macchina è ora un *nodo gestito*. Questi nodi gestiti ora vengono identificati con il prefisso "mi-". È possibile visualizzare i nodi **gestiti nella pagina Nodo gestito** inFleet Manager, utilizzando il AWS CLI comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html)o utilizzando il comando [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html)API. ## Impostazione della rotazione automatica della chiave privata Per rafforzare il tuo livello di sicurezza, puoi configurare AWS Systems Manager Agent (SSM Agent) in modo che ruoti automaticamente la chiave privata per un ambiente ibrido e multicloud. È possibile accedere a questa funzionalità utilizzandoSSM Agent3.0.1031.0 o versioni successive Attivare questa funzionalità seguendo la procedura seguente. **Per configurare SSM Agent per ruotare la chiave privata di un ambiente ibrido e multicloud** 1. Accedi a `/etc/amazon/ssm/` su una macchina Linux o `C:\Program Files\Amazon\SSM` per una macchina Windows Server. 1. Copiare il contenuto di`amazon-ssm-agent.json.template`In un nuovo file denominato`amazon-ssm-agent.json`. Save (Salva)`amazon-ssm-agent.json`nella stessa directory dove`amazon-ssm-agent.json.template`si trova. 1. Trova `Profile`, `KeyAutoRotateDays`. Immettere il numero di giorni desiderato tra le rotazioni automatiche della chiave privata. 1. Riavviare SSM Agent. Ogni volta che si modifica la configurazione, riavviareSSM Agent. È possibile personalizzare altre funzionalità di SSM Agent utilizzando la stessa procedura. Per un up-to-date elenco delle proprietà di configurazione disponibili e dei relativi valori predefiniti, vedere [Config Property](https://github.com/aws/amazon-ssm-agent#config-property-definitions) Definitions. ## Annullamento della registrazione e nuova registrazione di un nodo gestito (Windows Server) È possibile annullare la registrazione di un nodo gestito richiamando l'operazione [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html)API da AWS CLI o Tools for Windows. PowerShell Di seguito è illustrato un esempio di comando CLI: `aws ssm deregister-managed-instance --instance-id "mi-1234567890"` Per rimuovere le informazioni di registrazione rimanenti per l'agente, rimuovi la chiave `IdentityConsumptionOrder` dal file `amazon-ssm-agent.json`. Quindi, esegui il comando riportato di seguito: `amazon-ssm-agent -register -clear` **Nota** Puoi registrare nuovamente un server on-premises, un dispositivo edge 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 istanza per un codice e un ID di attivazione chiamando l'API [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) utilizzando il AWS CLI. Dopo aver eseguito il comando, verifica che il valore di `RegistrationCount` non sia superiore a `RegistrationLimit`. Se è maggiore, è necessario utilizzare un codice e un ID di attivazione diversi. **Per registrare nuovamente un nodo gestito su una macchina ibrida Windows Server** 1. Connettiti alla macchina. 1. Eseguire il seguente comando seguente. Assicurati di sostituire i valori segnaposto con il codice e l'ID di attivazione generati, quando hai creato un'attivazione ibrida e con l'identificativo della Regione da cui desideri scaricare l'SSM Agent. ``` $dir = $env:TEMP + "\ssm" cd $dir Start-Process ./ssm-setup-cli.exe -ArgumentList @( "-register", "-activation-code=$code", "-activation-id=$id", "-region=$region" ) -Wait -NoNewWindow ```