• 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à.
# Esecuzione di attività di gestione dei nodi con AWS Systems Manager
I seguenti argomenti descrivono come completare le attività dei nodi comuni utilizzando la AWS Systems Manager console unificata per un' AWS Organizations organizzazione e per un singolo Account AWS utente.
**Topics**
+ [Esaminare approfondimenti nodo](review-node-insights.md)
+ [Esplorazione dei nodi](view-aggregated-node-details.md)
+ [Just-in-time accesso al nodo tramite Systems Manager](systems-manager-just-in-time-node-access.md)
+ [Diagnosi e correzione](diagnose-and-remediate.md)
+ [Regolazione delle impostazioni di Systems Manager](settings-overview.md)
# Esaminare approfondimenti nodo
È possibile ottenere informazioni sullo stato generale dei nodi gestiti e delle EC2 istanze non gestite nell'organizzazione o nell'account utilizzando la console unificata Systems Manager.
Systems Manager offre una panoramica visiva dei nodi e EC2 delle istanze gestiti che non sono ancora gestiti da Systems Manager. (Un nodo gestito è qualsiasi macchina configurata per l'utilizzo con Systems Manager in ambienti [ibridi e multicloud](operating-systems-and-machine-types.md#supported-machine-types). Per informazione sui tipi di macchine supportate, consulta [Tipi di macchine supportati in ambienti ibridi e multicloud](operating-systems-and-machine-types.md#supported-machine-types).)
Questa panoramica viene fornita tramite singole caselle di rapporto, chiamate *widget*, che presentano grafici a torta interattivi e altri elementi grafici.
**Prima di iniziare**
Per esaminare le informazioni sui nodi, devi prima effettuare l'onboarding della tua organizzazione o del tuo account nella console unificata Systems Manager. Per ulteriori informazioni, consulta [Configurazione di AWS Systems Manager](systems-manager-setting-up-console.md).
Dopo l'onboarding, apri la [console Systems Manager](https://console.aws.amazon.com/systems-manager/explorer) e scegli **Esamina approfondimenti nodo**.
L'immagine seguente mostra le singole caselle di report, chiamate *widget*, disponibili nella pagina **Esamina approfondimenti nodo**.
![\[Dati dei nodi visualizzati nella pagina Systems Manager Esamina approfondimenti nodo\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/SYS2-Dashboard-Nodes.png)
Il display supporta widget che forniscono le seguenti informazioni.
**Riepilogo nodo**
Indica quante EC2 istanze dell'organizzazione o dell'account non sono attualmente nodi gestiti e quanti nodi gestiti sono presenti nel parco macchine dell'organizzazione o dell'account.
**Cos'è un'istanza non gestita?**
Quando si arresta un' EC2 istanza gestita, questa viene segnalata come «Non gestita» nella console Systems Manager. Si tratta di un comportamento previsto perché SSM Agent non dispone di una connessione attiva al servizio.
Questo è diverso dal modo in cui si AWS Config definisce un'istanza come non gestita. Se un'istanza è attualmente interrotta, AWS Config riporta lo stato dell'istanza l'ultima volta che è stata effettuata una connessione «heartbeat» tra SSM Agent l'istanza e il servizio Systems Manager.
Al riavvio, l'istanza si riconnette automaticamente al servizio Systems Manager e il suo stato nella console unificata viene ripristinato su «Gestito» entro cinque minuti. Non è richiesto alcun intervento manuale e tutte le configurazioni di Systems Manager per l'istanza vengono conservate durante il Stop/Start ciclo.
Tuttavia, se l'istanza non viene ancora segnalata come «Gestita» diversi minuti dopo l'avvio, è probabile che non sia configurata correttamente per la gestione di Systems Manager. In questo caso, consigliamo di eseguire una diagnosi per identificare il motivo per cui l'istanza rimane in uno stato non gestito. Per ulteriori informazioni, consulta [Diagnostica e correzione di istanze Amazon EC2 non gestite in Systems Manager](remediating-unmanaged-instances.md).
Se la scansione diagnostica non è in grado di determinare il problema, consulta i seguenti argomenti per verificare che i requisiti per SSM Agent i ruoli AWS Identity and Access Management (IAM) e i prerequisiti di Systems Manager siano stati tutti soddisfatti:
+ [Risoluzione dei problemi relativi a SSM Agent](troubleshooting-ssm-agent.md)
+ [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md)
+ [Risoluzione dei problemi relativi alla disponibilità dei nodi gestiti](fleet-manager-troubleshooting-managed-nodes.md)
**Tipi di nodi gestiti**
Indica quanti nodi gestiti del tuo parco sono EC2 istanze e quanti sono altri tipi di server, inclusi i server in sede (server locali), i dispositivi AWS IoT Greengrass principali e i dispositivi non AWS periferici AWS IoT e le macchine virtuali (VMs), anche VMs in altri ambienti cloud. È possibile consultare la grafica dei **Tipi di nodo** per accedere ai link a maggiori dettagli nella pagina **Esplora i nodi**.
Per ulteriori informazioni sul AWS supporto per ambienti ibridi e multicloud, consulta [AWS Soluzioni per](https://aws.amazon.com/hybrid-multicloud/) ambienti ibridi e multicloud.
**Versioni SSM Agent**
Fornisce informazioni sulle installazioni di AWS Systems Manager Agent (SSM Agent) nella tua flotta. SSM Agentè un software Amazon che viene eseguito sui tuoi nodi gestiti. SSM Agentconsente a Systems Manager di aggiornare, gestire e configurare queste risorse. L'agente elabora le richieste dal servizio Systems Manager in Cloud AWS, quindi le esegue come specificato nella richiesta.
Per i nodi gestiti nel parco istanze, questo widget riporta le versioni SSM Agent del parco istanze, dalla più recente alla meno recente. È possibile consultare la grafica delle **versioni SSM Agent** per accedere ai link a maggiori dettagli nella pagina **Esplora i nodi**.
Per ulteriori informazioni su SSM Agent, consultare [Utilizzo di SSM Agent](ssm-agent.md).
**Sistemi operativi a nodi gestiti**
Fornisce una suddivisione della percentuale di ciascun sistema operativo sui nodi gestiti nel parco istanze. È possibile consultare la grafica dei **Nodi gestiti dal sistema operativo** per accedere ai collegamenti a maggiori dettagli nella pagina **Esplora i nodi**.
È possibile personalizzare il layout dei widget nella pagina **Review node Insights** utilizzando una drag-and-drop funzionalità e rimuovendo e aggiungendo widget al display.
Utilizza le informazioni nei seguenti argomenti per lavorare al meglio con i widget Systems Manager sull'approfondimento dei nodi.
**Topics**
+ [Aggiungere o rimuovere widget dalla pagina **Esamina approfondimenti nodi**](review-node-insights-add-and-remove-widgets.md)
+ [Riorganizzazione dei widget nella pagina **Esamina approfondimenti nodi**](review-node-insights-rearrange-widgets.md)
# Aggiungere o rimuovere widget dalla pagina **Esamina approfondimenti nodi**
È possibile personalizzare il layout nella pagina Systems Manager **Esamina approfondimenti nodi** aggiungendo e rimuovendo i widget.
**Nota**
Per impostazione predefinita, nella pagina sono visualizzati tutti i widget disponibili.
**Per aggiungere o rimuovere widget dalla pagina **Esamina approfondimenti nodi****
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dal riquadro di navigazione a sinistra, scegli **Esamina approfondimenti nodi**.
1. Per rimuovere un widget dal display, procedi come segue:
1. Scegli il menu Altre opzioni (![\[The More options menu\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/more-options-menu-widgets.png)) per il widget.
1. Scegli **Remove widget** (Rimuovi widget).
1. Per aggiungere un widget al display, procedi come segue:
1. Seleziona **Add widget** (Aggiungi widget).
1. Nel pannello **Aggiungi widget**, fai clic e tieni premuta la maniglia di trascinamento (![\[The drag handle\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) del widget per aggiungerlo allo schermo.
1. Trascina il widget e rilascialo nel riquadro principale.
# Riorganizzazione dei widget nella pagina **Esamina approfondimenti nodi**
È possibile personalizzare il layout nella pagina **Esamina approfondimenti nodi** riorganizzando i widget.
**Per riorganizzare i widget nella pagina **Esamina approfondimenti nodi****
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 **Esamina approfondimenti nodi**.
1. Per personalizzare il layout del widget, scegli un widget che desideri spostare. Fai clic e tieni premuta la maniglia di trascinamento del widget (![\[The drag handle\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/drag-handle-dashboard.png)), quindi trascinalo nella nuova posizione.
1. Ripeti questo processo per ogni widget che desideri riposizionare.
Se il nuovo layout non piace, scegliere **Ripristina il layout predefinito** per spostare tutti i widget nella loro posizione originale.
# Esplorazione dei nodi
È possibile utilizzare la pagina **Esplora nodi** su Systems Manager per esaminare i dettagli dei nodi gestiti nell'organizzazione o nell'account in base ai criteri specificati nei filtri. Inoltre, è possibile utilizzare l'integrazione di Systems Manager con Amazon Q Developer (Amazon Q), una soluzione di IA generativa AWS, per effettuare ricerche utilizzando prompt di testo.
**Prima di iniziare**
Per utilizzare la funzionalità **Esplora nodi**, è necessario prima integrare la propria organizzazione o l'account nella console unificata di Systems Manager. Per ulteriori informazioni, consulta [Configurazione della console unificata di Systems Manager per un'organizzazione](systems-manager-setting-up-organizations.md).
Dopo l'onboarding, apri la [Console di Systems Manager](https://console.aws.amazon.com/systems-manager/) e scegli **Esplora nodi**.
**Nota**
Quando si crea un indice di aggregazione per Resource Explorer in una regione diversa dalla propria regione di origine, Systems Manager riduce di livello l'indice corrente. Quindi, Systems Manager promuove l'indice locale nella regione di origine come nuovo indice di aggregazione. Durante questo periodo, vengono visualizzati solo i nodi della regione di origine. Il processo richiede fino a 24 ore per essere completato.
**Topics**
+ [Esplorazione dei nodi utilizzando i filtri della console](view-aggregated-node-details-console.md)
+ [Esplorazione dei nodi utilizzando prompt di testo in Amazon Q](view-aggregated-node-details-Q.md)
+ [Visualizzazione dei dettagli dei singoli nodi e operazioni intraprese su un nodo](node-detail-actions.md)
+ [Effettuare il download o l’esportazione di un report sui nodi gestiti](explore-nodes-download-report.md)
+ [Gestione del contenuto e dell'aspetto dei report dei nodi](explore-nodes-manage-report-display.md)
# Esplorazione dei nodi utilizzando i filtri della console
Nella console Systems Manager, è quindi possibile raggruppare i nodi gestiti in base alle seguenti visualizzazioni:
------
#### [ All nodes (No filter) ]
Elenca tutti i nodi gestiti nell'organizzazione o nell'account.
![\[Un elenco di nodi gestiti nella pagina Esplora i nodi\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/2-explore-nodes-managed-nodes.png)
------
#### [ Node types ]
Fornisce schede per la visualizzazione separata dei dati per le istanze Amazon Elastic Compute Cloud (Amazon EC2) e altri tipi di macchine, inclusi server in sede (server locali AWS IoT Greengrass ), AWS IoT dispositivi core e dispositivi AWS non edge e VMs macchine virtuali (), anche in altri ambienti cloud. VMs
![\[Elenchi di nodi gestiti in schede di tipo nodo\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/2-explore-nodes-node-types.png)
------
#### [ Operating systems ]
Fornisce una scheda per ogni tipo di sistema operativo dell'organizzazione o dell'account, come **Amazon Linux** e **Microsoft Windows Server 2022 Datacenter**. In ogni scheda, è possibile filtrare ulteriormente l'elenco selezionando solo versioni specifiche dei sistemi operativi, come *Amazon Linux 2* e *Amazon Linux 2023*.
![\[Elenchi di nodi gestiti nelle schede del sistema operativo\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/2-explore-nodes-operating-system.png)
------
#### [ Agente SSM versions ]
Fornisce una scheda per ogni versione dell'SSM Agent installata sui nodi gestiti del parco istanze. In ogni scheda, è possibile filtrare ulteriormente l'elenco selezionando solo sistemi operativi specifici, come **Amazon Linux** e **Microsoft Windows Server 2022 Datacenter**.
![\[Elenchi di nodi gestiti nelle schede degli agenti\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/2-explore-nodes-agent-versions.png)
------
Inoltre, per ognuna di queste viste, è possibile rifinire ulteriormente l'elenco dei nodi segnalati scegliendo di visualizzare solo i nodi per una determinata proprietà, come lo stato del nodo, l'ID dell' Account AWS , l'ID dell'unità organizzativa e altro ancora.
È possibile personalizzare la visualizzazione del rapporto scegliendo quali delle colonne di dati disponibili vengono visualizzate nella pagina **Esplora nodi**. Inoltre, è possibile scaricare rapporti in formato `CSV` o `JSON`, oppure esportarli in Amazon S3 in formato `CSV`.
**Topics**
+ [Scelta di una visualizzazione dei filtri per i riepiloghi dei nodi gestiti](explore-nodes-filter-view.md)
# Scelta di una visualizzazione dei filtri per i riepiloghi dei nodi gestiti
La pagina **Esplora nodi** in Systems Manager consente di visualizzare i dati aggregati sul parco in base a una serie di visualizzazioni di filtro disponibili.
**Per scegliere una visualizzazione filtrante per i riepiloghi dei 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 riquadro di navigazione, scegli **Esplora nodi**.
1. Per la **visualizzazione Filtro**, seleziona una delle opzioni di filtro e, facoltativamente, rifinisci ulteriormente il rapporto:
+ **Nodi gestiti**: nella casella di ricerca (![\[The search icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)), seleziona una proprietà e un delimitatore, ad esempio `Node type = Managed EC2 instances`.
+ **Sistemi operativi**: nell'elenco **Filtra versioni del sistema operativo**, è possibile selezionare un numero di versione del sistema operativo. Nella casella di ricerca (![\[The search icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)), è possibile selezionare una proprietà e un delimitatore, ad esempio `Node type = Managed EC2 instances`.
+ **Versioni di SSM Agent**: nell'elenco **Filtra versioni del sistema operativo**, è possibile selezionare un nome di sistema operativo. Nella casella di ricerca (![\[The search icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)), è possibile selezionare una proprietà e un delimitatore, ad esempio `Node type = Managed EC2 instances`.
+ **Tipi di nodi**: nell'elenco **Filtra versioni del sistema operativo**, è possibile selezionare un nome di sistema operativo. Nella casella di ricerca (![\[The search icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)), è possibile selezionare una proprietà e un delimitatore, ad esempio `Node type = Managed EC2 instances`.
Dopo aver filtrato facoltativamente l'elenco, è possibile visualizzare i dettagli su uno specifico nodo gestito scegliendone l'ID nella colonna **ID nodo**. Da questa visualizzazione dettagliata, è possibile eseguire una serie di operazioni sul nodo.
# Esplorazione dei nodi utilizzando prompt di testo in Amazon Q
Utilizzando l'integrazione di Systems Manager con Amazon Q Developer, è possibile utilizzare prompt di testo per visualizzare le informazioni create dall'IA generativa sui nodi gestiti.
Amazon Q Developer è un assistente conversazionale generativo basato sull'intelligenza artificiale che può aiutarti a comprendere, creare, estendere e utilizzare le applicazioni. AWS Per accelerare la tua crescita AWS, il modello alla base di Amazon Q è arricchito con AWS contenuti di alta qualità per produrre risposte più complete, utilizzabili e referenziate. Per ulteriori informazioni, consulta [Cos'è Amazon Q Developer?](https://docs.aws.amazon.com/amazonq/latest/aws-builder-use-ug/what-is.html) nella *Guida per l'utente di Amazon Q Developer*.
L'integrazione tra Systems Manager e Amazon Q consente di ottenere rapidamente visibilità e controllo su ambienti distribuiti di grandi dimensioni in più Account AWS regioni. È possibile utilizzare il sistema di query in linguaggio naturale per cercare rapidamente i dati dei nodi, quindi identificare i problemi e agire più rapidamente.
Quando fai una domanda in linguaggio naturale su nodi o istanze gestite, Amazon Q utilizza l'azione Systems Manager `ListNodes` e crea filtri in base all'input testuale per recuperare i risultati.
Ad esempio, supponi di fornire ad Amazon Q il seguente prompt:
**List my managed nodes running Red Hat Enterprise Linux 9.2**
Amazon Q determina quali filtri includere in una richiesta, quindi esegue una query simile alla seguente:
```
aws ssm list-nodes \
--filters Key=PlatformName,Values='Red Hat Enterprise Linux',Type=Equal Key=PlatformVersion,Values=9.2,Type=Equal
```
Amazon Q genera quindi un report sulle Red Hat Enterprise Linux istanze presenti nel tuo account, elencando informazioni come il numero di istanze, le relative regioni e le relative IDs regioni.
È possibile anche visualizzare un riepilogo JSON dei dettagli di ciascuna istanza, nonché aprire un link per visualizzare gli elenchi completi delle istanze EC2 o dei nodi gestiti nella pagina Systems Manager **Esplora nodi**. La pagina **Esplora nodi** mostra i risultati che corrispondono ai criteri di filtro inclusi nel prompt. Da lì, è possibile modificare o perfezionare i filtri per la richiesta, come descritto in [Esplorazione dei nodi](view-aggregated-node-details.md).
**Topics**
+ [Impara a creare prompt efficaci per chiedere informazioni sul parco istanze ad Amazon Q](view-aggregated-node-details-Q-prompts.md)
+ [Esplorazione dei nodi gestiti utilizzando Amazon Q](explore-managed-nodes-using-Q.md)
# Impara a creare prompt efficaci per chiedere informazioni sul parco istanze ad Amazon Q
Migliore è la qualità della domanda o del prompt che invii ad Amazon Q, migliori saranno i risultati che otterrai.
**Suggerimenti per i prompt di query**
Tieni presente i seguenti suggerimenti quando richiedi ad Amazon Q informazioni sul parco istanze:
1. Per migliorare l'accuratezza dei risultati, utilizza i termini "nodi gestiti" e "istanze gestite" nei prompt, anziché solo "nodi" e "istanze".
1. Per ottenere risultati su più account che fanno parte di un'*organizzazione*, come configurato in AWS Organizations, è necessario accedere all'account amministratore delegato nella regione di residenza designata.
1. Nell'account amministratore delegato, utilizza termini per aiutare Amazon Q a capire che stai chiedendo informazioni su nodi e istanze all'interno dell'organizzazione, scegliendo specificamente termini come "nella mia organizzazione" o "nel mio account 123456789012".
**Topics**
+ [Esempi di domande per Amazon Q](#sample-questions-Q)
+ [Nomi e versioni dei sistemi operativi supportati per i prompt](#supported-os-names-Q)
## Esempi di domande per Amazon Q
Nella tabella seguente, forniamo domande di esempio che illustrano alcuni modi in cui è possibile creare query su Amazon Q che portino a risultati migliori.
Forniamo anche esempi dei filtri che Amazon Q applicherà all'esecuzione del [ListNodes](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListNodes.html)comando, generati dal contenuto del prompt.
| Esempio di domanda in linguaggio naturale | Filtri applicati di Amazon Q |
| --- | --- |
| Show me my Windows managed nodes. | PlatformType = Windows
|
| List my managed instances in account 123456789012. | AccountId = 123456789012
|
| Show me all managed nodes running Amazon Linux 2 across my organization. | PlatformName = Amazon Linux
PlatformVersion = 2
|
| Show me all managed instances running Microsoft Windows Server 2019 Datacenter in my organization. | PlatformName = Microsoft Windows Server 2019 Datacenter
|
| Can you show me all managed nodes with SSM Agent version 3.3.1142.0? | AgentType = amazon-ssm-agent
AgentVersion = 3.3.1142.0
|
| List all Amazon Linux 2 managed instances in account 123456789012 that have SSM Agent version 3.3.1230.0. | PlatformName = Amazon Linux
PlatformVersion = 2
AccountId = 123456789012
AgentType = amazon-ssm-agent
AgentVersion = 3.3.1230.0
|
| What Microsoft Windows Server 2012 R2 Enterprise managed nodes are running in the eu-central-1 region across my entire organization? | PlatformName = Microsoft Windows Server 2012 R2 Enterprise
Region = eu-central-1
|
| Show me all managed instances running Red Hat Linux 7 in ou-d6ty-gxdma6vm. | PlatformName = RHEL Linux
PlatformVersion = 7
OrganizationalUnitId = ou-d6ty-gxdma6vm
|
| What Ubuntu managed instances are in account 123456789012? | PlatformName = Ubuntu
AccountId = 123456789012
|
| List my Linux managed instances. | PlatformType = Linux
|
| Find my macOS managed nodes. | PlatformType = macOS
|
| Show me all versions of Amazon Linux managed nodes in my org. | PlatformName = Amazon Linux
|
| List managed nodes running Amazon Linux 2. | PlatformName = Amazon Linux
PlatformVersion = 2
|
| List the managed nodes with Ubuntu 16.04 in account 123456789012. | PlatformName = Ubuntu
PlatformVersion = 16.04
AccountId = 123456789012
|
| Find all managed nodes that have an SSM Agent version that is not 3.3.987.0. | AgentType = amazon-ssm-agent
AgentVersion != 3.3.987.0
|
| List all managed instances that are not running a Linux operating system. | PlatformType != Linux
|
## Nomi e versioni dei sistemi operativi supportati per i prompt
Quando chiedi ad Amazon Q informazioni sui nodi gestiti dell'account, è utile fornire il nome di un sistema operativo così come indicato su Systems Manager. È possibile anche fornire numeri di versione per restringere ulteriormente i risultati. Ad esempio, come illustrato nelle tabelle seguenti, è possibile richiedere risultati specifici su **macOS 14.5**, **Microsoft Windows Server 2019 Datacenter**, and **AlmaLinux 9.2 through 9.4**, per citare solo alcuni esempi.
Questi elenchi sono da considerarsi non esaustivi e vengono proposti solo a titolo esemplificativo.
**macOS**
| Nome piattaforma | Numeri di versione |
| --- | --- |
| macOS | 13.2, 13.4, 13.7, 14.1, 14.5, 14.6.1, 15.0 |
**Windows**
| Rilasci | Numeri di versione |
| --- | --- |
| Microsoft Windows Server 2012 R2 Datacenter | 6,3,9600 |
| Microsoft Windows Server 2012 R2 Standard | 6,3,9600 |
| Microsoft Windows Server 2012 Standard | 6,2,9200 |
| Microsoft Windows Server 2016 Datacenter | N/D |
| Microsoft Windows Server 2016 Standard | 10,0,14393 |
| Microsoft Windows Server 2019 Datacenter | N/D |
| Microsoft Windows Server 2019 Standard | N/D |
| Microsoft Windows Server 2022 Datacenter | N/D |
| Microsoft Windows Server 2022 Standard | 100,20348 |
**Linux**
| Nomi della piattaforma | Numeri di versione |
| --- | --- |
| AlmaLinux | 8.10, 9.2, 9.3, 9.4 |
| Amazon Linux 2 | 2.0 e versioni successive |
| Amazon Linux 2023 | 2023.0.20230315.0 e versioni successive |
| BottleRocket | 1.14.3, 1.16.1, 1.18.0, 1.19.1, 1.19.2, 1.19.5, 1.20.0, 1.20.1, 1.20.2, 1.20.3, 1.20.5, 1.21.1, 1.23.0, 1.24.0, 1.24.1, 1.25.0, 1.26.1, |
| CentOS Stream | 9 |
| Debian GNU/Linux | 11-12 |
| Oracle Linux Server | 7.8, 8.2, 8.3, 8.8, 8.9, 8.10, 9.4 |
| Red Hat Enterprise Linux | 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9, 8.10, 9.2, 9.3, 9.4 |
| Server Red Hat Enterprise Linux | 17.3, 7.6, 7.7, 7.8, 7.9 |
| Rocky Linux | 8.6, 8.7, 8.8, 8.9, 8.10, 9.1, 9.2, 9.3, 9.4 |
| Ubuntu Server | 16.04, 18.04, 20.04, 22.04, 24.04 |
# Esplorazione dei nodi gestiti utilizzando Amazon Q
L'integrazione di Systems Manager con Amazon Q Developer ti consente di porre domande sui nodi gestiti della tua flotta da qualsiasi punto in Console di gestione AWS cui è disponibile l'interfaccia Amazon Q.
Per ulteriori informazioni sull'interazione con Amazon Q, consulta [Parlando di AWS con un Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html) nella *Guida per l’utente di Amazon Q Developer*.
**Per esplorare i nodi gestiti utilizzando Amazon Q**
1. Da qualsiasi punto del Console di gestione AWS, scegli l'icona Amazon Q (![\[The Amazon Q icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/q-icon-white.png)).
1. Nel campo prompt nella parte inferiore del riquadro Amazon Q, fare una domanda sui nodi gestiti nell’account o nell’organizzazione.
**Suggerimento**
Per suggerimenti su come creare prompt efficaci, consulta le informazioni contenute in [Impara a creare prompt efficaci per chiedere informazioni sul parco istanze ad Amazon Q](view-aggregated-node-details-Q-prompts.md).
1. Esaminare le informazioni su nodi specifici o scegliere **Apri la console AWS Systems Manager ** per continuare l'esplorazione.
# Visualizzazione dei dettagli dei singoli nodi e operazioni intraprese su un nodo
Da un elenco nella pagina **Esplora nodi** in Systems Manager, seleziona un singolo nodo per visualizzare dettagli completi sulla macchina o eseguire una serie di operazioni sul nodo. **Generale**, nella pagina dei dettagli, presenta informazioni complete sul nodo.
**Per visualizzare i dettagli dei singoli nodi e intraprendere operazioni su un nodo**
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 **Esplora nodi**.
1. (Facoltativo) Segui i passaggi indicati in [Scelta di una visualizzazione dei filtri per i riepiloghi dei nodi gestiti](explore-nodes-filter-view.md) per rifinire l'elenco dei nodi gestiti visualizzati per l'organizzazione o l'account.
1. Nella colonna **ID nodo**, scegli l'ID collegato di un nodo.
1. Per visualizzare ulteriori dettagli sul nodo, nella barra di navigazione a sinistra, nell'elenco **Proprietà**, scegli una proprietà per visualizzare ulteriori informazioni su:
+ **Tag**: visualizza un elenco di tag applicati al nodo. È anche possibile aggiungere o rimuovere tag.
+ **Inventario**: scegli un tipo di inventario, ad esempio **AWS:Application** o **AWS:Network**, per visualizzare i dettagli dell'inventario per il nodo.
+ **Associazioni**: visualizza i dettagli su tutte le associazioni State Manager applicate al nodo, inclusi dettagli come lo stato e il nome del documento SSM associato.
+ **Patch**: visualizza informazioni di riepilogo sulle patch e sullo stato delle patch per il nodo.
+ **Conformità della configurazione**: visualizza i dettagli di conformità per il nodo, come lo stato di conformità e la gravità dei problemi di conformità.
Per ulteriori informazioni sui dettagli sulle schede, consulta [Che cos'è la console unificata?](systems-manager-unified-console.md).
1. Per eseguire operazioni sul nodo, è possibile utilizzare le seguenti opzioni nel menu **Operazioni del nodo**:
**Nota**
Queste operazioni sono disponibili solo per i nodi gestiti nell’ Account AWS e nella Regione in cui si sta lavorando attualmente. Per i nodi gestiti a cui potresti avere accesso in altri account o regioni, è invece possibile accedere a un elenco di **proprietà**.
+ **Connettiti, avvia sessione terminale**: connettiti al nodo utilizzando [AWS Systems Manager Session Manager](session-manager.md).
+ **Strumenti**
+ **Visualizza il file system**: sfoglia il contenuto della struttura di directory del nodo. Aggiungi, rinomina e rimuovi le directory. Taglia o copia e incolla file.
+ **Visualizza i contatori delle prestazioni**: visualizza le informazioni sulle prestazioni del nodo come l'utilizzo della CPU, il traffico di rete e altri tipi di utilizzo.
+ **Processi gestiti**: visualizza le informazioni sull'utilizzo delle risorse nel nodo. Avvia o arresta i processi sul nodo.
+ **Gestisci utenti e gruppi**: visualizza, aggiungi o elimina account utente e gruppi di utenti sul nodo.
+ **Esegui comando run**: [AWS Systems Manager Run Command](run-command.md) da utilizzare per gestire la configurazione del nodo. Run Commandutilizza i [documenti Systems Manager](documents.md) per eseguire modifiche su richiesta, come l'aggiornamento delle applicazioni o l'esecuzione di script di shell Linux e comandi Windows PowerShell .
+ **Nodi di patch**: utilizza la funzionalità **Applica patch ora** di [AWS Systems Manager Patch Manager](patch-manager.md) per eseguire un'operazione di applicazione di patch on-demand sul nodo dalla console.
**Nota**
Le attività precedenti possono essere avviate anche dal menu **Strumenti** nella barra di navigazione a sinistra.
+ **Impostazioni dei nodi**
+ **Aggiungere tag**: applica coppie chiave-valore del tag aggiuntive al nodo.
+ **Reimposta la password utente del nodo**: imposta una nuova password per un utente specificato sul nodo.
+ **Modifica il ruolo IAM**: modifica il ruolo IAM associato al nodo. Creare un nuovo ruolo IAM da collegare al nodo.
# Effettuare il download o l’esportazione di un report sui nodi gestiti
È possibile utilizzare la funzionalità Systems Manager **Explore nodes** per visualizzare elenchi filtrati o non filtrati di nodi gestiti per AWS l'organizzazione o l'account nella console Systems Manager. Nei casi in cui si desidera visualizzare i dati offline o elaborarli in un'altra applicazione, è possibile salvare il rapporto come file `CSV` o `JSON`.
A seconda delle dimensioni del report, viene richiesto di scaricarlo sul computer locale o esportarlo in un bucket Amazon S3. I report vengono salvati nei bucket S3 solo in formato `CSV`.
**Per scaricare o esportare un report sul nodo gestito**
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, scegli **Esplora nodi**.
1. (Facoltativo) Segui i passaggi indicati in [Scelta di una visualizzazione dei filtri per i riepiloghi dei nodi gestiti](explore-nodes-filter-view.md) per rifinire l'elenco dei nodi gestiti visualizzati per l'organizzazione o l'account.
1. Scegli **Segnala** (![\[The download report icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/download-arrow-icon.png)).
1. Se viene visualizzata la finestra di dialogo **Scarica rapporto**, esegui le seguenti operazioni:
1. In **Nome file**, immettere un nome per il file. È consigliabile specificare un nome che rappresenti l'ambito del rapporto, ad esempio `all-organization-nodes` o `ec2-instances-out-of-date-agent`.
1. Per **Colonne incluse**, specificare se includere le colonne per tutti i dettagli dei nodi disponibili o solo quelle selezionate per la visualizzazione corrente.
**Suggerimento**
Per informazioni sulla gestione delle colonne nella visualizzazione del rapporto, consulta [Gestione del contenuto e dell'aspetto dei report dei nodi](explore-nodes-manage-report-display.md).
1. Per **Formato file**, seleziona **CSV** o **JSON**, a seconda di come verrà utilizzato il file.
1. Per **Intestazione del foglio di calcolo**, per includere una riga di intestazioni di colonna in un file `CSV`, seleziona **Includi nomi di righe di colonne**.
1. Scegli **Scarica**.
Il rapporto viene salvato nella posizione di download predefinita in base alle impostazioni del browser.
1. Se viene visualizzata la finestra di dialogo **Esporta in Amazon S3**, procedi come segue:
1. Per l'**URI S3**, inserisci l'URI del bucket in cui esportare il report.
**Suggerimento**
Per visualizzare un elenco dei bucket nella console Amazon S3, scegli **Visualizza.** Scegli **Sfoglia S3** per selezionarlo da un elenco di bucket nell’account.
1. Come **metodo di autorizzazione**, va specificato il ruolo di servizio da utilizzare per fornire le autorizzazioni per l'esportazione del report nel bucket.
Se viene scelto di lasciare che Systems Manager crei il ruolo per conto dell’utente, fornirà tutte le autorizzazioni e le dichiarazioni di fiducia necessarie per l'operazione.
Per utilizzare o creare il proprio ruolo, questo deve includere le autorizzazioni e le dichiarazioni di attendibilità richieste. Per ulteriori informazioni sulla creazione di questo ruolo, consulta [Creazione di un ruolo di servizio personalizzato per esportare i report di diagnosi in S3](create-s3-export-role.md).
1. Seleziona **Invia**.
# Creazione di un ruolo di servizio personalizzato per esportare i report di diagnosi in S3
Quando si visualizzano elenchi filtrati o non filtrati di nodi gestiti per l’organizzazione o l’account AWS nella pagina **Esplora nodi** di Systems Manager, è possibile esportare l'elenco come report in un bucket Amazon S3 come file `CSV`.
A tale scopo, è necessario specificare un ruolo di servizio con le autorizzazioni e la policy di fiducia necessarie per l'operazione. È possibile selezionare l’opzione per cui Systems Manager creerà il ruolo durante il processo di download del report. In alternativa, è possibile creare autonomamente il ruolo e la relativa policy richiesta.
**Per creare un ruolo di servizio personalizzato per l'esportazione dei report di diagnosi in S3**
1. Segui i passaggi descritti in [Creazione di policy tramite l'editor JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) nella *Guida per l’utente IAM*.
+ Utilizza quanto segue per il contenuto della politica, assicurandoti di sostituirlo *placeholder values* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "111122223333"
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketAcl",
"s3:ListBucket",
"s3:PutLifecycleConfiguration",
"s3:GetLifecycleConfiguration"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "111122223333"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:ListNodes"
],
"Resource": "*"
}
]
}
```
------
+ Assegna un nome alla policy per riconoscerla facilmente nel passaggio successivo.
1. Segui i passaggi descritti in [Creazione di un ruolo IAM tramite una policy di fiducia personalizzata (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) nella *Guida per l'utente IAM*.
+ Per il passaggio 4, inserisci la seguente politica di attendibilità, assicurandoti di sostituirla *placeholder values* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMAssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
1. Per il passaggio 10, scegli **Passaggio 2: aggiungi autorizzazioni** e seleziona il nome della policy creata nella fase precedente.
Dopo aver creato il ruolo, è possibile selezionarlo seguendo i passaggi in [Effettuare il download o l’esportazione di un report sui nodi gestiti](explore-nodes-download-report.md).
# Gestione del contenuto e dell'aspetto dei report dei nodi
È possibile utilizzare la funzionalità Systems Manager **Explore nodes** per visualizzare elenchi filtrati o non filtrati di nodi gestiti per AWS l'organizzazione o l'account nella console Systems Manager. È possibile scegliere tra più di una dozzina di campi da includere negli elenchi di nodi, ad esempio **ID nodo**, **Nome del sistema operativo**, **Regione** e altro ancora. È anche possibile riordinare le colonne degli elenchi e dei report e modificare la modalità di visualizzazione dell'elenco nella console.
**Per gestire il contenuto e l'aspetto dei report del nodo**
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, scegli **Esplora nodi**.
1. Nell’area **Nodi** scegli l'icona a ingranaggio delle preferenze (![\[The preferences gear icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/preferences-icon.png)).
1. Nella finestra di dialogo **Preferenze** procedi come segue:
1. Per **Dimensioni della pagina**, scegli quante righe includere in ogni display di visualizzazione della console, **10**, **25** o **50**.
1. Per **A capo automatico**, seleziona la casella per visualizzare tutto il contenuto di una cella nella larghezza di colonna disponibile.
1. Per **Righe alternate** seleziona la casella per visualizzare righe alternate di sfondi chiari e ombreggiati.
1. Per **Seleziona contenuto visibile** procedi come segue:
+ Attiva o disattiva le singole colonne per la visualizzazione dell'elenco e i report.
+ Per modificare l'ordine delle colonne, fai clic e tieni premuta la maniglia di trascinamento (![\[The drag handle\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) del nome di una colonna e trascinala verso l'alto o verso il basso nell'elenco.
1. Scegli **Conferma**.
# Just-in-time accesso al nodo tramite Systems Manager
Systems Manager consente di migliorare la sicurezza dei nodi supportando *just-in-time*l'accesso. Just-in-timel'accesso ai nodi consente agli utenti di richiedere un accesso temporaneo e limitato nel tempo ai nodi, che è possibile approvare solo quando l'accesso è veramente necessario. Ciò elimina la necessità di fornire un accesso duraturo ai nodi gestiti dalle policy IAM. Inoltre, Systems Manager fornisce la registrazione delle sessioni RDP sui Windows Server nodi per aiutarvi a soddisfare i requisiti di conformità, eseguire l'analisi delle cause principali e altro ancora. Per utilizzare l'accesso ai just-in-time nodi, è necessario configurare la console unificata Systems Manager.
Con l'accesso ai just-in-time nodi, puoi creare policy IAM granulari per garantire che solo gli utenti autorizzati possano inviare richieste di accesso ai tuoi nodi. Quindi crei *policy di approvazione* che definiscono le approvazioni necessarie per la connessione ai tuoi nodi. Per l'accesso ai just-in-time nodi, esistono politiche di *approvazione automatica* e politiche di *approvazione manuale*. Una policy di approvazione automatica definisce a quali nodi gli utenti possono connettersi automaticamente. Le policy di approvazione manuale definiscono il numero e i livelli di approvazioni manuali da fornire per accedere ai nodi specificati. Inoltre, puoi creare una policy di *negazione dell'accesso*. Una policy di negazione dell'accesso impedisce esplicitamente l'approvazione automatica delle richieste di accesso ai nodi specificati. Una politica di negazione dell'accesso si applica a tutti gli account di un'organizzazione. AWS Organizations Le politiche di approvazione automatica e manuale si applicano solo al Regioni AWS luogo in cui sono state create. Account AWS
Quando un utente tenta di connettersi a un nodo, gli viene richiesto di inserire un motivo per l'accesso al nodo. Quindi, vengono valutate le tue policy di approvazione. A seconda delle policy, gli utenti o si connettono automaticamente al nodo di destinazione o Systems Manager crea automaticamente una richiesta di approvazione manuale per conto del richiedente. Gli approvatori specificati nella policy di approvazione manuale applicabile al nodo ricevono quindi una notifica della richiesta di accesso e possono approvare o rifiutare la richiesta. Gli approvatori e i richiedenti possono ricevere notifiche via e-mail o tramite Amazon Q Developer nell'integrazione delle applicazioni di chat con Slack o Microsoft Teams. Systems Manager concede l'accesso ai nodi richiesti, solo quando gli approvatori specificati forniscono tutte le approvazioni richieste. Una volta ricevute tutte le approvazioni richieste, l'utente può avviare tutte le sessioni sul nodo necessarie per la durata della finestra di accesso specificata nella policy di approvazione. Systems Manager non termina automaticamente le sessioni di accesso ai just-in-time nodi. Come best practice, è necessario specificare i valori per la *durata massima della sessione* e le preferenze del *timeout della sessione inattiva*. Queste preferenze impediscono agli utenti di rimanere connessi ai nodi oltre la finestra di accesso approvata.
Si consiglia di utilizzare una combinazione di policy di approvazione per aiutarti a proteggere i nodi con dati più critici, consentendo al contempo agli utenti di connettersi a nodi meno critici senza alcun intervento. Ad esempio, puoi richiedere approvazioni manuali per le richieste di accesso ai nodi del database e approvare automaticamente le sessioni per i nodi di livello di presentazione non persistenti.
Systems Manager supporta l'accesso ai just-in-time nodi per gli utenti federati con IAM Identity Center o IAM. Quando un utente federato invia una richiesta di accesso, specifica il nodo di destinazione e il motivo per cui è necessario connettersi al nodo. Systems Manager confronta l'identità dell'utente con i parametri definiti nelle policy di approvazione dell'organizzazione. Quando vengono soddisfatte le condizioni della policy di approvazione automatica o gli approvatori forniscono manualmente le approvazioni, il richiedente è in grado di connettersi al nodo di destinazione. Quando un utente tenta di connettersi a un nodo approvato, Systems Manager crea e utilizza un token temporaneo per stabilire la sessione.
Poiché il servizio di Systems Manager gestisce l'autenticazione per le richieste di accesso e la creazione di sessioni, non è necessario utilizzare le policy IAM per gestire l'accesso ai nodi. Utilizzando l'accesso ai just-in-time nodi, Systems Manager aiuta l'organizzazione ad avvicinarsi ai privilegi zero, poiché è sufficiente consentire agli utenti di creare richieste di accesso anziché consentire loro di avviare sessioni con autorizzazioni permanenti per i nodi. Per aiutarti a soddisfare i requisiti di conformità, Systems Manager mantiene tutte le richieste di accesso per un anno. Systems Manager emette anche EventBridge eventi per l'accesso ai just-in-time nodi in caso di richieste di accesso non riuscite e aggiornamenti di stato per accedere alle richieste di approvazioni manuali. Per ulteriori informazioni, consultare [Monitoraggio degli eventi di Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md).
**Topics**
+ [Configurazione dell' just-in-timeaccesso con Systems Manager](systems-manager-just-in-time-node-access-setting-up.md)
+ [Avvia una sessione di accesso al just-in-time nodo](systems-manager-just-in-time-node-access-start-session.md)
+ [Gestione delle richieste di just-in-time accesso](systems-manager-just-in-time-node-access-manage-requests.md)
+ [Passaggio all'accesso al just-in-time nodo da Session Manager](systems-manager-just-in-time-node-access-moving-from-session-manager.md)
+ [Disabilitazione dell' just-in-timeaccesso con Systems Manager](systems-manager-just-in-time-node-access-disable.md)
+ [Just-in-time domande frequenti sull'accesso al nodo](just-in-time-node-access-faq.md)
# Configurazione dell' just-in-timeaccesso con Systems Manager
La configurazione dell'accesso ai just-in-time nodi con Systems Manager ha richiesto diversi passaggi. Innanzitutto, si scelgono le *destinazioni* in cui si desidera configurare l'accesso ai just-in-time nodi. Gli obiettivi sono costituiti da unità AWS Organizations organizzative (OUs) e Regioni AWS. Per impostazione predefinita, gli stessi obiettivi scelti durante la configurazione della console unificata Systems Manager sono selezionati per l'accesso ai just-in-time nodi. È possibile scegliere di configurare l'accesso ai just-in-time nodi per tutte le stesse destinazioni o per un sottoinsieme delle destinazioni specificate durante la configurazione della console unificata Systems Manager. L'aggiunta di nuove destinazioni che non erano state selezionate durante la configurazione della console unificata Systems Manager non è supportata.
Successivamente, creerai *policy di approvazione* per determinare quando le connessioni dei nodi richiedono l'approvazione manuale e vengono approvate automaticamente. Le policy di approvazione sono gestite da ogni account dell'organizzazione. Puoi anche condividere una policy dell'account amministratore delegato per negare esplicitamente l'approvazione automatica delle connessioni a nodi specifici.
**Nota**
La configurazione dell'accesso ai just-in-time nodi non influisce sulle politiche o sulle preferenze IAM esistenti per le quali hai configurato. Session Manager È necessario rimuovere l'autorizzazione all'azione `StartSession` API dalle policy IAM per garantire che venga utilizzato solo l'accesso ai just-in-time nodi quando gli utenti tentano di connettersi ai nodi. Dopo aver configurato l'accesso ai just-in-time nodi, ti consigliamo di testare le tue politiche di approvazione con un sottoinsieme di utenti e nodi per verificare che le politiche funzionino come desiderato prima di rimuovere le autorizzazioni a. Session Manager
**Supporto dell'autenticazione**
Nota i seguenti dettagli sul supporto di autenticazione utilizzato per l'accesso ai just-in-time nodi:
+ Just-in-time l'accesso al nodo non supporta il tipo di autenticazione Single Sign-On quando ci si connette a Windows Server istanze con Remote Desktop.
+ Sono supportate solo AWS Security Token Service (AWS STS) credenziali di sicurezza `AssumeRole` temporanee. Per ulteriori informazioni, consulta gli argomenti seguenti nella *Guida per l'utente IAM*:
+
+ [Credenziali di sicurezza temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [Confronto AWS STS delle credenziali](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html)
+ [Richiesta di credenziali di sicurezza temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)
Le seguenti policy IAM descrivono le autorizzazioni necessarie per amministrare e consentire agli utenti di creare richieste di accesso ai just-in-time nodi con Systems Manager. Dopo aver verificato di disporre delle autorizzazioni necessarie per utilizzare l'accesso ai just-in-time nodi con Systems Manager, è possibile continuare il processo di configurazione. Sostituisci ogni *example resource placeholder* con le tue informazioni.
## Politica IAM per abilitare l'accesso ai nodi just-in-time
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:CreateConfigurationManager",
"ssm-quicksetup:DeleteConfigurationManager",
"ssm-quicksetup:GetConfiguration",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:GetServiceSettings",
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:ListTagsForResource",
"ssm-quicksetup:TagResource",
"ssm-quicksetup:UntagResource",
"ssm-quicksetup:UpdateConfigurationDefinition",
"ssm-quicksetup:UpdateConfigurationManager",
"ssm-quicksetup:UpdateServiceSettings"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:DescribeStackSetOperation",
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackResources",
"cloudformation:ListStackSetOperations",
"cloudformation:ListStackInstances",
"cloudformation:DescribeStackSet",
"cloudformation:ListStackSets",
"cloudformation:DescribeStackInstance",
"cloudformation:DescribeOrganizationsAccess",
"cloudformation:ActivateOrganizationsAccess",
"cloudformation:GetTemplate",
"cloudformation:ListStackSetOperationResults",
"cloudformation:DescribeStackEvents",
"cloudformation:UntagResource",
"ssm:DescribeAutomationExecutions",
"ssm:GetAutomationExecution",
"ssm:ListAssociations",
"ssm:DescribeAssociation",
"ssm:GetDocument",
"ssm:ListDocuments",
"ssm:DescribeDocument",
"ssm:GetOpsSummary",
"organizations:DeregisterDelegatedAdministrator",
"organizations:DescribeAccount",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators",
"organizations:ListRoots",
"organizations:ListParents",
"organizations:ListOrganizationalUnitsForParent",
"organizations:DescribeOrganizationalUnit",
"organizations:ListAWSServiceAccessForOrganization",
"iam:ListRoles",
"iam:ListRolePolicies",
"iam:GetRole",
"iam:CreatePolicy",
"cloudformation:TagResource"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudformation:RollbackStack",
"cloudformation:CreateStack",
"cloudformation:UpdateStack",
"cloudformation:DeleteStack"
],
"Resource": [
"arn:aws:cloudformation:*:*:stack/StackSet-AWS-QuickSetup-JITNA*",
"arn:aws:cloudformation:*:*:stack/AWS-QuickSetup-*",
"arn:aws:cloudformation:*:*:type/resource/*",
"arn:aws:cloudformation:*:*:stack/StackSet-SSMQuickSetup"
]
},
{
"Sid": "StackSetOperations",
"Effect": "Allow",
"Action": [
"cloudformation:CreateStackSet",
"cloudformation:UpdateStackSet",
"cloudformation:DeleteStackSet",
"cloudformation:DeleteStackInstances",
"cloudformation:CreateStackInstances",
"cloudformation:StopStackSetOperation"
],
"Resource": [
"arn:aws:cloudformation:*:*:stackset/AWS-QuickSetup-JITNA*",
"arn:aws:cloudformation:*:*:type/resource/*",
"arn:aws:cloudformation:*:*:stackset-target/AWS-QuickSetup-JITNA*:*"
]
},
{
"Sid": "IamRolesMgmt",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetRole",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:DetachRolePolicy",
"iam:GetRolePolicy",
"iam:ListRolePolicies"
],
"Resource": [
"arn:aws:iam::*:role/AWS-QuickSetup-JITNA*",
"arn:aws:iam::*:role/service-role/AWS-QuickSetup-JITNA*"
]
},
{
"Sid": "IamPassRole",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/AWS-QuickSetup-JITNA*",
"arn:aws:iam::*:role/service-role/AWS-QuickSetup-JITNA*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com",
"ssm-quicksetup.amazonaws.com",
"cloudformation.amazonaws.com"
]
}
}
},
{
"Sid": "SSMAutomationExecution",
"Effect": "Allow",
"Action": "ssm:StartAutomationExecution",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/AWS-EnableExplorer",
"arn:aws:ssm:us-east-1:111122223333:automation-execution/*"
]
},
{
"Sid": "SSMAssociationPermissions",
"Effect": "Allow",
"Action": [
"ssm:DeleteAssociation",
"ssm:CreateAssociation",
"ssm:StartAssociationsOnce"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:association/*"
},
{
"Sid": "SSMResourceDataSync",
"Effect": "Allow",
"Action": [
"ssm:CreateResourceDataSync",
"ssm:UpdateResourceDataSync"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:resource-data-sync/AWS-QuickSetup-*"
},
{
"Sid": "ListResourceDataSync",
"Effect": "Allow",
"Action": [
"ssm:ListResourceDataSync"
],
"Resource": "*"
},
{
"Sid": "CreateServiceLinkedRoles",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"accountdiscovery.ssm.amazonaws.com",
"ssm.amazonaws.com",
"ssm-quicksetup.amazonaws.com",
"stacksets.cloudformation.amazonaws.com"
]
}
},
"Resource": "*"
},
{
"Sid": "CreateStackSetsServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/stacksets.cloudformation.amazonaws.com/AWSServiceRoleForCloudFormationStackSetsOrgAdmin"
},
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:UpdateDocumentDefaultVersion",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:DeleteDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-JustInTimeAccessDenyAccessOrgPolicy"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowAccessRequestOpsItemOperations",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:DeleteOpsItem",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "IdentityCenterPermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"identitystore:ListGroupMembershipsForMember"
],
"Resource": "*"
}
]
}
```
------
## Policy IAM per la configurazione dell'accesso ai just-in-time nodi
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:UpdateDocumentDefaultVersion",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:DeleteDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/SSM-JustInTimeAccessTokenRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"justintimeaccess.ssm.amazonaws.com"
]
}
}
},
{
"Sid": "AllowAccessRequestOpsItemOperations",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:DeleteOpsItem",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "AllowSessionManagerPreferencesOperation",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell",
"Condition": {
"StringEquals": {
"ssm:DocumentType": "Session"
}
}
},
{
"Sid": "AllowSessionManagerOperations",
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:TerminateSession"
],
"Resource": "*"
},
{
"Sid": "AllowRDPConnectionRecordingOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:UpdateConnectionRecordingPreferences",
"ssm-guiconnect:GetConnectionRecordingPreferences",
"ssm-guiconnect:DeleteConnectionRecordingPreferences"
],
"Resource": "*"
},
{
"Sid": "AllowRDPConnectionRecordingKmsOperation",
"Effect": "Allow",
"Action": [
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
},
"StringLike": {
"kms:ViaService": "ssm-guiconnect.*.amazonaws.com"
},
"Bool": {
"aws:ViaAWSService": "true"
}
}
},
{
"Sid": "AllowFleetManagerOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
},
{
"Sid": "SNSTopicManagement",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:SetTopicAttributes"
],
"Resource": [
"arn:aws:sns:us-east-1:111122223333:SSM-JITNA*"
]
},
{
"Sid": "SNSListTopics",
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": "*"
},
{
"Sid": "EventBridgeRuleManagement",
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:PutTargets"
],
"Resource": [
"arn:aws:events:us-east-1::rule/SSM-JITNA*"
]
},
{
"Sid": "ChatbotSlackManagement",
"Effect": "Allow",
"Action": [
"chatbot:CreateSlackChannelConfiguration",
"chatbot:UpdateSlackChannelConfiguration",
"chatbot:DescribeSlackChannelConfigurations",
"chatbot:DescribeSlackWorkspaces",
"chatbot:DeleteSlackChannelConfiguration",
"chatbot:RedeemSlackOauthCode",
"chatbot:DeleteSlackWorkspaceAuthorization",
"chatbot:GetSlackOauthParameters"
],
"Resource": "*"
},
{
"Sid": "ChatbotTeamsManagement",
"Effect": "Allow",
"Action": [
"chatbot:ListMicrosoftTeamsChannelConfigurations",
"chatbot:CreateMicrosoftTeamsChannelConfiguration",
"chatbot:UpdateMicrosoftTeamsChannelConfiguration",
"chatbot:ListMicrosoftTeamsConfiguredTeams",
"chatbot:DeleteMicrosoftTeamsChannelConfiguration",
"chatbot:RedeemMicrosoftTeamsOauthCode",
"chatbot:DeleteMicrosoftTeamsConfiguredTeam",
"chatbot:GetMicrosoftTeamsOauthParameters",
"chatbot:TagResource"
],
"Resource": "*"
},
{
"Sid": "SSMEmailSettings",
"Effect": "Allow",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:GetServiceSetting"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/access-request/email-role-mapping",
"arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/access-request/enabled-email-notifications"
]
},
{
"Sid": "AllowViewingJitnaCloudWatchMetrics",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/SSM/JustInTimeAccess"
}
}
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration",
"ssm-quicksetup:GetConfigurationManager"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "ManualPolicy",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"ssm:GetServiceSetting",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Sid": "SessionPreference",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Sid": "AllowIamListForKMS",
"Effect": "Allow",
"Action": [
"iam:ListUsers"
],
"Resource": "arn:aws:iam::111122223333:user/*"
},
{
"Sid": "KMSPermission",
"Effect": "Allow",
"Action": [
"kms:TagResource",
"kms:ListAliases",
"kms:CreateAlias"
],
"Resource": "*"
},
{
"Sid": "KMSCreateKey",
"Effect": "Allow",
"Action": [
"kms:CreateKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"SystemsManagerJustInTimeNodeAccessManaged"
]
}
}
},
{
"Sid": "AllowIamRoleForChatbotAction",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/role name",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"chatbot.amazonaws.com"
]
}
}
},
{
"Sid": "AllowIamServiceRoleForChat",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/management.chatbot.amazonaws.com/AWSServiceRoleForAWSChatbot"
},
{
"Sid": "CloudWatchLogs",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": "arn:aws:logs:*:111122223333:log-group::log-stream:"
},
{
"Sid": "IdentityStorePermissions",
"Effect": "Allow",
"Action": [
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"sso-directory:SearchUsers",
"sso-directory:SearchGroups",
"identitystore:DescribeGroup",
"identitystore:DescribeUser"
],
"Resource": "*"
}
]
}
```
------
## Policy IAM per approvatori di richieste di accesso
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessRequestDescriptions",
"Effect": "Allow",
"Action": [
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "AllowGetSpecificAccessRequest",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:opsitem/*"
},
{
"Sid": "AllowApprovalRejectionSignal",
"Effect": "Allow",
"Action": [
"ssm:SendAutomationSignal"
],
"Resource": "arn:aws:ssm:*:*:automation-execution/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
}
}
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Sid": "IDCPermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"identitystore:ListGroupMembershipsForMember"
],
"Resource": "*"
}
]
}
```
------
## Policy IAM per gli utenti di accesso ai just-in-time nodi
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowJITNAOperations",
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken"
],
"Resource": "*"
},
{
"Sid": "AllowOpsItemCreationAndRetrieval",
"Effect": "Allow",
"Action": [
"ssm:CreateOpsItem",
"ssm:GetOpsItem"
],
"Resource": "arn:aws:ssm:*:*:opsitem/*"
},
{
"Sid": "AllowListAccessRequests",
"Effect": "Allow",
"Action": [
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:ListOpsItemEvents",
"ssm:DescribeSessions"
],
"Resource": "*"
},
{
"Sid": "RequestManualApprovals",
"Action": "ssm:StartAutomationExecution",
"Effect": "Allow",
"Resource": "arn:aws:ssm:*:*:document/*",
"Condition": {
"StringEquals": {
"ssm:DocumentType": "ManualApprovalPolicy"
}
}
},
{
"Sid": "StartManualApprovalsAutomationExecution",
"Effect": "Allow",
"Action": "ssm:StartAutomationExecution",
"Resource": "arn:aws:ssm:*:*:automation-execution/*"
},
{
"Sid": "CancelAccessRequestManualApproval",
"Effect": "Allow",
"Action": "ssm:StopAutomationExecution",
"Resource": "arn:aws:ssm:*:*:automation-execution/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
}
}
},
{
"Sid": "DescribeEC2Instances",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "AllowListSSMManagedNodesAndTags",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceInformation",
"ssm:ListTagsForResource"
],
"Resource": "*"
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration"
],
"Resource": "*"
},
{
"Sid": "AllowSessionManagerOperations",
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus"
],
"Resource": "*"
},
{
"Sid": "AllowRDPOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:ListConnections",
"ssm:GetConnectionStatus"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "AllowSsmJitnaPoliciesReadOnly",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": [
"arn:aws:ssm:*:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Sid": "ExploreNodes",
"Effect": "Allow",
"Action": [
"ssm:ListNodesSummary",
"ssm:ListNodes",
"ssm:DescribeInstanceProperties"
],
"Resource": "*"
},
{
"Sid": "IdentityStorePermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup"
],
"Resource": "*"
}
]
}
```
------
**Nota**
Per limitare l'accesso alle operazioni API che creano, aggiornano o eliminano le policy di approvazione, utilizza la chiave di condizione `ssm:DocumentType` per la `AutoApprovalPolicy` i tipi di documento `ManualApprovalPolicy `. Le operazioni dell'API `StartAccessRequest` e `GetAccessToken` non supportano le seguenti chiavi di contesto globali:
`aws:SourceVpc`
`aws:SourceVpce`
`aws:VpcSourceIp`
`aws:UserAgent`
`aws:MultiFactorAuthPresent`
Per ulteriori informazioni sulle chiavi di contesto di condizione per Systems Manager, consulta [Chiavi di condizione per AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys) nelle *Informazioni di riferimento sull'autorizzazione del servizio*.
La procedura seguente descrive come completare la prima fase di configurazione per l'accesso al just-in-time nodo.
**Per configurare l'accesso al just-in-time nodo**
1. Accedi all'account amministratore delegato di Systems Manager della tua organizzazione.
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Seleziona **l'accesso al Just-in-time nodo** nel riquadro di navigazione.
1. Seleziona **Abilita la nuova esperienza**.
1. Scegli le regioni in cui desideri abilitare l'accesso ai just-in-time nodi. Per impostazione predefinita, le stesse regioni scelte durante la configurazione della console unificata Systems Manager sono selezionate per l'accesso ai just-in-time nodi. La scelta di nuove Regioni non selezionate durante la configurazione della console unificata di Systems Manager non è supportata.
1. Seleziona **Abilita l'accesso al just-in-time nodo**.
L'utilizzo dell'accesso al just-in-time nodo per 30 giorni dopo l'attivazione della funzionalità è gratuito. Dopo il periodo di prova di 30 giorni, l'utilizzo dell'accesso al just-in-time nodo è a pagamento. Per ulteriori informazioni, consultare [AWS Systems Manager Prezzi](https://aws.amazon.com/systems-manager/pricing/).
# Crea policy di approvazione per i tuoi nodi
Le policy di approvazione definiscono le approvazioni di cui gli utenti hanno bisogno per accedere a un nodo. Poiché l'accesso ai just-in-time nodi elimina la necessità di autorizzazioni di lunga durata ai nodi tramite le policy IAM, è necessario creare policy di approvazione per consentire l'accesso ai nodi. Se non esistono policy di approvazione applicabili a un nodo, gli utenti non possono richiedervi l'accesso.
Nell'accesso ai just-in-time nodi, esistono tre tipi di policy. I tipi di policy sono *approvazione automatica*, *negazione dell'accesso* e *approvazione manuale*.
**Just-in-time tipi di policy di accesso ai nodi**
+ Una policy di approvazione automatica definisce a quali nodi gli utenti possono connettersi automaticamente.
+ Le policy di approvazione manuale definiscono il numero e i livelli di approvazioni manuali da fornire per accedere ai nodi specificati.
+ Una policy di negazione dell'accesso impedisce esplicitamente l'approvazione automatica delle richieste di accesso ai nodi specificati.
Una politica di negazione dell'accesso si applica a tutti gli account di un' AWS Organizations organizzazione. Ad esempio, puoi negare esplicitamente le approvazioni automatiche per il gruppo `Intern` ai nodi contrassegnati con la chiave `Production`. Le politiche di approvazione automatica e manuale si applicano solo al Regioni AWS luogo in cui sono state create. Account AWS Ciascun account membro nella tua organizzazione gestisce le proprie policy di approvazione. Le policy di approvazione sono valutate nell'ordine seguente:
1. Negazione dell'accesso
1. Approvazione automatica
1. Manuale
Sebbene tu possa avere solo una policy di negazione dell'accesso per organizzazione e una di approvazione automatica per account e Regione, probabilmente avrai numerose policy di approvazione manuale in un account. Quando si valutano le politiche di approvazione manuale, l'accesso al just-in-time nodo predilige sempre la politica più specifica per un nodo. Le policy di approvazione manuale sono valutate nell'ordine seguente:
1. Destinazione specifica dei tag
1. Tutte le destinazioni del nodo
Ad esempio, hai un nodo etichettato con la chiave `Demo`. Nello stesso account, hai una policy di approvazione manuale che si rivolge a tutti i nodi e richiede un'approvazione da un livello. Hai anche una policy di approvazione manuale che richiede due approvazioni da due livelli per i nodi contrassegnati con la chiave `Demo`. Systems Manager applica la policy che ha come destinazione il tag `Demo` al nodo, poiché è più specifica di quella che è destinata a tutti i nodi. Ciò ti consente di creare una policy generale per tutti i nodi del tuo account, garantendo agli utenti la possibilità di inviare richieste di accesso, consentendoti di creare policy più granulari in base alle esigenze.
A seconda dell'organizzazione, potrebbero essere applicati più tag ai nodi. In questo scenario, se a un nodo si applicano più policy di approvazione manuale, le richieste di accesso hanno esito negativo. Ad esempio, un nodo viene contrassegnato con il `Database` e le chiavi `Production`. Nello stesso account, hai una policy di approvazione manuale che si applica ai nodi contrassegnati con la chiave `Production` e un'altra policy di approvazione manuale che si applica ai nodi contrassegnati con la chiave `Database`. Ciò si traduce in un conflitto per il nodo etichettato con entrambe le chiavi e le richieste di accesso hanno esito negativo. Systems Manager reindirizza l'utente alla richiesta non riuscita. Qui è possibile visualizzare i dettagli sulle policy e sui tag in conflitto, in modo che sia possibile apportare le modifiche necessarie, se si hanno le autorizzazioni richieste. In caso contrario, è possibile notificare a un collega della propria organizzazione le autorizzazioni necessarie per modificare le policy. I conflitti di policy che portano a richieste di accesso non riuscite generano EventBridge eventi che consentono la flessibilità necessaria per creare flussi di lavoro di risposta personalizzati. Inoltre, Systems Manager invia notifiche via e-mail per i conflitti di policy che comportano richieste di accesso non riuscite ai destinatari specificati. Per ulteriori informazioni sulla configurazione delle notifiche via e-mail per i conflitti delle policy, consulta [Configurare le notifiche per le richieste di just-in-time accesso](systems-manager-just-in-time-node-access-notifications.md).
In una policy di *negazione dell'accesso*, utilizzi il linguaggio delle policy Cedar per definire a quali nodi gli utenti non possono connettersi automaticamente nella tua organizzazione. Questa politica viene creata e condivisa dall'account amministratore delegato dell'organizzazione. La policy di negazione dell'accesso sostituisce tutte le politiche di approvazione automatica. È possibile avere una sola policy di negazione dell'accesso per organizzazione.
In una politica di *approvazione automatica*, si utilizza il linguaggio delle policy Cedar per definire quali utenti possono connettersi automaticamente ai nodi specificati senza approvazione manuale. La durata di accesso per una richiesta di accesso approvata automaticamente è di un'ora. Questo valore non può essere modificato. Puoi avere una sola policy di approvazione automatica per account e regione.
In una politica di approvazione *manuale*, si specifica la durata dell'accesso, il numero di livelli di approvazione richiesti, il numero di approvatori richiesti per livello e i nodi a cui possono approvare le richieste di accesso. just-in-time La durata dell'accesso per una policy di approvazione manuale deve essere compresa tra 1 e 336 ore. Se si specificano più livelli di approvazione, le approvazioni per il processo della richiesta di accesso vengono elaborate un livello alla volta. Ciò significa che tutte le approvazioni necessarie per un livello devono essere fornite prima che il processo di approvazione passi ai livelli successivi. Se si specificano più tag in una policy di approvazione manuale, questi vengono valutati come istruzioni `or` e non come istruzioni `and`. Ad esempio, se si crea una policy di approvazione manuale che include i tag `Application`, `Web` e `Test`, la policy si applica a qualsiasi nodo contrassegnato con una di queste chiavi. La policy non si applica solo ai nodi etichettati con tutte e tre le chiavi.
Ti consigliamo di utilizzare una combinazione di policy manuali con la tua policy di approvazione automatica per proteggere i nodi con dati più critici, consentendo al contempo agli utenti di connettersi ai nodi meno critici senza alcun intervento. Ad esempio, puoi richiedere approvazioni manuali per le richieste di accesso ai nodi del database e approvare automaticamente le sessioni per i nodi di livello di presentazione non persistenti.
Le procedure seguenti descrivono come creare politiche di approvazione per l'accesso ai nodi. just-in-time
**Topics**
+ [Crea politiche di approvazione manuali per l'accesso ai just-in-time nodi](systems-manager-just-in-time-node-access-create-manual-policies.md)
+ [Struttura dell'istruzione e operatori integrati per le policy di approvazione automatica e di negazione dell'accesso](auto-approval-deny-access-policy-statement-structure.md)
+ [Crea una politica di approvazione automatica per l'accesso ai just-in-time nodi](systems-manager-just-in-time-node-access-create-auto-approval-policies.md)
+ [Crea una politica di negazione dell'accesso per just-in-time l'accesso ai nodi](systems-manager-just-in-time-node-access-create-deny-access-policies.md)
+ [Crea politiche di approvazione per l'accesso ai just-in-time nodi con Amazon Q](systems-manager-just-in-time-node-access-create-approval-policies-q-ide-cli.md)
# Crea politiche di approvazione manuali per l'accesso ai just-in-time nodi
Le seguenti procedure descrivono come creare policy di approvazione manuale. Systems Manager consente di creare fino a 50 policy di approvazione Account AWS manuali per azienda Regione AWS.
**Per creare una policy di approvazione manuale**
1. Aprire la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Seleziona **Gestisci l'accesso al nodo** nel riquadro di navigazione.
1. Nella sezione **Dettagli della policy** del passaggio **Crea policy di approvazione manuale**, inserisci un nome e una descrizione per la policy di approvazione.
1. Inserisci un valore per la **durata dell'accesso**. Si tratta della quantità massima di tempo con cui un utente può avviare sessioni su un nodo dopo l'approvazione di una richiesta di accesso. Il valore deve essere compreso tra 1 e 336 ore.
1. Nella sezione **Destinazioni del nodo**, inserisci le coppie chiave-valore dei tag associate ai nodi a cui desideri applicare la policy. Se nessuno dei tag specificati nella policy è associato a un nodo, la policy non viene applicata al nodo.
1. Nella sezione **Approvatori delle richieste di accesso**, inserisci gli utenti o i gruppi a cui desideri approvare le richieste di accesso alle destinazioni dei nodi indicati nella policy. Gli approvatori delle richieste di accesso possono essere utenti e gruppi di IAM Identity Center o ruoli IAM. Puoi specificare fino a cinque approvatori per livello e fino a cinque livelli di approvatori.
1. Seleziona **Crea policy di approvazione manuale**.
# Struttura dell'istruzione e operatori integrati per le policy di approvazione automatica e di negazione dell'accesso
La tabella seguente mostra la struttura delle policy di approvazione automatica e negazione dell'accesso.
| Componente | Sintassi |
| --- | --- |
| effetto | `permit \| forbid` |
| scope | `(principal, action, resource)` |
| clausola condizionale | when {
principal or resource has attribute name
}; |
## Componenti della policy
Una policy di approvazione automatica o di negazione dell'accesso contiene i seguenti componenti:
+ **Effetto**: sia `permit` (consenti) che `forbid` (nega) l'accesso.
+ **Ambito**: i principali, le azioni e le risorse a cui si applica l'effetto. È possibile lasciare indefinito l'ambito in Cedar non identificando principali, azioni o risorse specifici. In questo caso, la policy si applica a tutti i possibili principali, operazioni e risorse. Per l'accesso ai just-in-time nodi, è sempre. `action` `AWS::SSM::Action::"getTokenForInstanceAccess"`
+ **Clausola condizionale**: il contesto in cui si applica l'effetto.
## Commenti
Puoi includere commenti nelle tue policy. I commenti sono definiti come una riga che inizia con `//` e termina con un carattere a capo.
Di seguito viene illustrato un esempio di commenti in una policy.
```
// Allows users in the Engineering group from the Platform org to automatically connect to nodes tagged with Engineering and Production keys.
permit (
principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
```
## Clausole multiple
Puoi utilizzare più clausole condizionali in un'istruzione di policy tramite l'operatore `&&`.
```
// Allow access if node has tag where the tag key is Environment
// & tag value is Development
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Development"
};
```
## Caratteri riservati
L'esempio seguente mostra come scrivere una policy, se una proprietà di contesto utilizza un `:` (punto e virgola), che è un carattere riservato nel linguaggio delle policy.
```
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
}
```
Per ulteriori esempi, consulta [Esempio di istruzioni di policy](#policy-statement-examples).
## Just-in-time schema di accesso al nodo
Di seguito è riportato lo schema Cedar per l'accesso ai just-in-time nodi.
```
namespace AWS::EC2 {
entity Instance tags String;
}
namespace AWS::IdentityStore {
entity Group;
entity User in [Group] {
employeeNumber?: String,
costCenter?: String,
organization?: String,
division?: String,
};
}
namespace AWS::IAM {
entity Role;
type AuthorizationContext = {
principalTags: PrincipalTags,
};
entity PrincipalTags tags String;
}
namespace AWS::SSM {
entity ManagedInstance tags String;
action "getTokenForInstanceAccess" appliesTo {
principal: [AWS::IdentityStore::User],
resource: [AWS::EC2::Instance, AWS::SSM::ManagedInstance],
context: {
"iam": AWS::IAM::AuthorizationContext
}
};
}
```
## Operatori integrati
Quando si crea il contesto di una policy di approvazione automatica o di negazione dell'accesso utilizzando varie condizioni, è possibile utilizzare l'operatore `&&`, per aggiungere ulteriori condizioni. Esistono anche molti altri operatori integrati che puoi utilizzare per aggiungere ulteriore forza espressiva alle condizioni della tua policy. La tabella seguente contiene tutti gli operatori integrati come riferimento.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/auto-approval-deny-access-policy-statement-structure.html)
## Esempio di istruzioni di policy
Di seguito sono mostrati esempi di istruzioni della policy.
```
// Users assuming IAM roles with a principal tag of "Elevated" can automatically access nodes tagged with the "Environment" key when the value equals "prod"
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
// Verify IAM role principal tag
context.iam.principalTags.getTag("AccessLevel") == "Elevated" &&
// Verify the node has a tag with "Environment" tag key and a tag value of "prod"
resource.hasTag("Environment") &&
resource.getTag("Environment") == "prod"
};
```
```
// Identity Center users in the "Contractor" division can automatically access nodes tagged with the "Environment" key when the value equals "dev"
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
// Verify that the user is part of the "Contractor" division
principal.division == "Contractor" &&
// Verify the node has a tag with "Environment" tag key and a tag value of "dev"
resource.hasTag("Environment") &&
resource.getTag("Environment") == "dev"
};
```
```
// Identity Center users in a specified group can automatically access nodes tagged with the "Environment" key when the value equals "Production"
permit(principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::getTokenForInstanceAccess,
resource)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Production"
};
```
# Crea una politica di approvazione automatica per l'accesso ai just-in-time nodi
In una policy di approvazione automatica, si utilizza il linguaggio di policy Cedar, per definire quali utenti possono connettersi automaticamente ai nodi specificati senza l'approvazione manuale. Una policy di approvazione automatica contiene molteplici istruzioni di `permit`, che specificano il `principal` e la `resource`. Ogni istruzione include una clausola `when`, che definisce le condizioni per l'approvazione automatica.
Di seguito è riportato un esempio di policy di approvazione automatica.
```
permit (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has costCenter && resource.hasTag("CostCenter") && principal.costCenter == resource.getTag("CostCenter")
};
permit (
principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
};
```
La procedura seguente descrive come creare una politica di approvazione automatica per l'accesso ai just-in-time nodi. La durata di accesso per una richiesta di accesso approvata automaticamente è di un'ora. Questo valore non può essere modificato. Puoi avere solo una politica di approvazione automatica per Account AWS volta. Regione AWS Per maggiori informazioni su come creare le istruzioni della policy, consulta [Struttura dell'istruzione e operatori integrati per le policy di approvazione automatica e di negazione dell'accesso](auto-approval-deny-access-policy-statement-structure.md).
**Per creare una policy di approvazione automatica**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Seleziona **Gestisci l'accesso al nodo** nel riquadro di navigazione.
1. Nella scheda **Policy di approvazione**, seleziona **Crea una policy di approvazione automatica**.
1. Inserisci la tua istruzione della policy per quella con l'approvazione automatica nella sezione **Istruzione per la policy**. Puoi utilizzare le **istruzioni di esempio** fornite per creare la tua policy.
1. Seleziona **Crea policy di approvazione automatica**.
# Crea una politica di negazione dell'accesso per just-in-time l'accesso ai nodi
In una policy di negazione dell'accesso, si utilizza il linguaggio di policy Cedar, per definire a quali nodi gli utenti non possono connettersi automaticamente senza l'approvazione manuale. Una policy di negazione dell'accesso contiene molteplici istruzioni di `forbid`, che specificano il `principal` e la `resource`. Ogni istruzione include una clausola `when`, che definisce le condizioni per l'approvazione automatica del diniego.
Di seguito è riportato un esempio di policy di negazione dell'accesso.
```
forbid (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
resource.hasTag("Environment") && resource.getTag("Environment") == "Production"
};
forbid (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has division && principal.division != "Finance" && resource.hasTag("DataClassification") && resource.getTag("DataClassification") == "Financial"
};
forbid (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "TEMP-*" && resource.hasTag("Criticality") && resource.getTag("Criticality") == "High"
};
```
La procedura seguente descrive come creare una politica di negazione dell'accesso per just-in-time l'accesso ai nodi. Per maggiori informazioni su come creare le istruzioni della policy, consulta [Struttura dell'istruzione e operatori integrati per le policy di approvazione automatica e di negazione dell'accesso](auto-approval-deny-access-policy-statement-structure.md).
**Nota**
Osservare le seguenti informazioni.
È possibile creare policy di negazione dell'accesso, mentre si è connessi all'account di gestione AWS o a quello dell'amministratore delegato. È possibile avere una sola policy di negazione dell'accesso per organizzazione AWS Organizations .
Just-in-time node access utilizza AWS Resource Access Manager (AWS RAM) per condividere la politica di negazione dell'accesso con gli account dei membri dell'organizzazione. Se desideri condividere la policy di negazione dell'accesso con gli account membri dell'organizzazione, devi abilitare la condivisione delle risorse dall'account di gestione della tua organizzazione. Per ulteriori informazioni, consulta [Abilitare la condivisione delle risorse con AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) nella *Guida per l'utente di AWS RAM *.
**Per creare una policy di negazione dell'accesso**
1. Apri la AWS Systems Manager console all'indirizzo. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Seleziona **Gestisci l'accesso al nodo** nel riquadro di navigazione.
1. Nella scheda **Policy di approvazione**, seleziona **Crea una policy di negazione dell'accesso**.
1. Inserisci l'istruzione per la policy di negazione dell'accesso nella sezione **Istruzione per la policy**. Puoi utilizzare le **istruzioni di esempio** fornite per creare la tua policy.
1. Seleziona **Crea policy di negazione dell'accesso**.
# Crea politiche di approvazione per l'accesso ai just-in-time nodi con Amazon Q
L'uso di Amazon Q Developer per la riga di comando fornisce indicazioni e supporto su vari aspetti dello sviluppo del software. Per l'accesso ai just-in-time nodi, Amazon Q ti aiuta a creare politiche di approvazione generando e aggiornando il codice per le politiche, analizzando le dichiarazioni delle politiche e altro ancora. Le seguenti informazioni descrivono come creare policy di approvazione utilizzando Amazon Q per la riga di comando.
## Identificazione del caso d'uso
Il primo passaggio nella creazione delle policy di approvazione consiste nella definizione chiara del caso d'uso. Ad esempio, nella tua organizzazione potresti voler approvare automaticamente le richieste di accesso ai nodi con un tag `Environment:Testing`. Potresti anche voler negare esplicitamente le approvazioni automatiche ai nodi con un tag `Environment:Production` , se l'ID di un dipendente inizia con `TEMP`. Per i nodi con un tag `Tier:Database`, potresti voler richiedere due livelli di approvazioni manuali.
In un determinato scenario, si potrebbe preferire una policy o una condizione piuttosto che un'altra. Pertanto, si consiglia di definire in modo chiaro i comportamenti della policy e le istruzioni più adatte al tuo caso d'uso e alle tue preferenze.
## Configurazione dell'ambiente di sviluppo
Installa Amazon Q per la riga di comando dove desideri sviluppare le tue policy di approvazione. Per informazioni sull'installazione di Amazon Q per la riga di comando, consulta [Installazione di Amazon Q per la riga di comando](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html) nella *Guida per l'utente di Amazon Q Developer*.
Consigliamo inoltre di installare il server MCP per la AWS documentazione. Questo server MCP collega Amazon Q per la riga di comando alle risorse di documentazione più recenti. Per informazioni sull'utilizzo di MCP con Amazon Q per la riga di comando, consulta [Utilizzare MCP con Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp.html) nella *Guida per l'utente di Amazon Q Developer*.
Per ulteriori informazioni sul server AWS Documentation MCP, vedete [AWS Documentation MCP](https://awslabs.github.io/mcp/servers/aws-documentation-mcp-server/) Server.
Installa e configura il AWS CLI, se non l'hai già fatto. Per informazioni, consulta [Installazione o aggiornamento della versione più recente del AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
## Sviluppa il contenuto della policy di approvazione
Con l'identificazione del caso d'uso e la configurazione dell'ambiente, puoi sviluppare il contenuto per le policy. Il caso d'uso e le preferenze determinano in gran parte il caso d'uso e le istruzioni utilizzate.
Se non sei sai come utilizzare una determinata policy o hai bisogno di ulteriori informazioni sul suo schema, consulta [Crea policy di approvazione per i tuoi nodi](systems-manager-just-in-time-node-access-approval-policies.md) e gli argomenti successivi. Questi argomenti spiegano in dettaglio come vengono valutate le policy e forniscono istruzioni di esempi funzionanti.
Le seguenti procedure descrivono come creare policy di approvazione utilizzando Amazon Q per la riga di comando.
**Nota**
Amazon Q Developer utilizza l'IA generativa. Potrebbe essere necessario verificare le risposte. Consulta la [Policy sull'IA AWS responsabile](https://aws.amazon.com/ai/responsible-ai/policy/).
**Per creare una policy di approvazione utilizzando Amazon Q per la riga di comando**
1. Apri il tuo terminale e avvia una sessione con Amazon Q.
```
$ q chat
```
1. Inserisci un prompt e descrivi il tipo di istruzione di policy che desideri creare. Ad esempio, utilizzando lo scenario precedente per una policy di approvazione, è possibile inserire il seguente prompt:
```
Create a Cedar policy statement that allows a principal to use the “getTokenForInstanceAccess" action for a resource
that has a tag key “Environment” and tag value of “Testing”. Use the following example statement for reference to verify the syntax.
permit (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
The Cedar policy statement you create must be valid. Validate the Cedar statement using the AWS documentation provided for just-in-time node access policy statement structure and make sure you abide by the schema.
```
1. L'immissione di questo prompt di esempio ha prodotto il seguente risultato:
```
Based on the AWS documentation for Cedar policy statements and the examples provided, I'll create a valid Cedar policy
statement that allows a principal to use the "getTokenForInstanceAccess" action for resources with the tag key "Environment" and tag value "Testing".
Here's the Cedar policy statement:
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Testing"
};
This policy statement:
1. Uses the permit effect to allow access
2. Applies to any principal (since no specific principal is defined)
3. Specifically targets the "getTokenForInstanceAccess" action
4. Applies to resources that have a tag with key "Environment" and value "Testing"
5. Uses the proper syntax for the condition clause with the hasTag() and getTag() operators
The statement follows the Cedar policy language structure as documented in the AWS Systems Manager documentation for just-in-time node access policies.
```
1. Per convalidare la sintassi, incolla l'istruzione della policy in un nuovo file Cedar. Puoi anche convalidare l'istruzione utilizzando lo [spazio di sviluppo Cedar](https://www.cedarpolicy.com/en/playground).
1. Dopo aver convalidato l'istruzione, salva il file Cedar.
1. Dal tuo terminale, esegui il seguente AWS CLI comando per creare un documento SSM utilizzando il contenuto della tua policy. Prima di utilizzare le politiche di approvazione in un ambiente di produzione, testate le politiche di approvazione con un sottoinsieme di identità e nodi in un unico file. Account AWS Regione AWS
**Nota**
Per una policy di approvazione automatica, il nome del documento deve essere `SSM-JustInTimeAccessAutoApprovalPolicy`. È possibile applicare una sola politica di approvazione automatica per Account AWS volta. Regione AWS Per una policy di negazione dell'accesso, il nome del documento deve essere `SSM-JustInTimeAccessDenyAccessOrgPolicy`. È possibile applicare un solo criterio di negazione dell'accesso per AWS Organizations organizzazione e il criterio deve essere creato nell'account amministratore delegato per Systems Manager. I vincoli di denominazione per le policy di approvazione manuale sono gli stessi degli altri documenti SSM. Per ulteriori informazioni, consulta [CreateDocument](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html#systemsmanager-CreateDocument-request-Name).
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--content file://path/to/file/policyContent.cedar \
--name "SSM-JustInTimeAccessAutoApprovalPolicy" \
--document-type "AutoApproval"
```
------
#### [ Windows ]
```
aws ssm create-document ^
--content file://C:\path\to\file\policyContent.cedar ^
--name "SSM-JustInTimeAccessAutoApprovalPolicy" ^
--document-type "AutoApproval"
```
------
#### [ PowerShell ]
```
$cedar = Get-Content -Path "C:\path\to\file\policyContent.cedar" | Out-String
New-SSMDocument `
-Content $cedar `
-Name "SSM-JustInTimeAccessAutoApprovalPolicy" `
-DocumentType "AutoApproval"
```
------
# Aggiorna le preferenze della sessione di accesso al just-in-time nodo
Con l'accesso ai just-in-time nodi, puoi specificare le preferenze generali di sessione e registrazione in ogni organizzazione Account AWS e Regione AWS nella tua organizzazione. In alternativa, puoi CloudFormation StackSets creare un documento sulle preferenze di sessione in più account e regioni per aiutarti ad avere preferenze di sessione coerenti. Per informazioni sullo schema per i documenti relativi alle preferenze di sessione, consulta [Schema documento di sessione](session-manager-schema.md).
Per scopi di registrazione, consigliamo di utilizzare l'opzione di streaming con Amazon CloudWatch Logs. Questa funzionalità consente di inviare un flusso continuo di log dei dati di sessione a Logs. CloudWatch 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 ai CloudWatch registri, vengono inclusi durante lo streaming dei dati della sessione. Durante lo streaming dei dati di sessione, i registri sono formattati in JSON per consentire l'integrazione con le soluzioni di registrazione esistenti.
Systems Manager non termina automaticamente le sessioni di accesso ai just-in-time nodi. Come best practice, è necessario specificare i valori per la *durata massima della sessione* e le impostazioni del *timeout della sessione inattiva*. L'utilizzo di queste impostazioni consente di impedire a un utente di rimanere connesso a un nodo più a lungo del periodo di tempo approvato in una richiesta di accesso. La procedura seguente descrive come aggiornare le preferenze di sessione per l'accesso ai just-in-time nodi.
**Importante**
È necessario etichettare le AWS KMS chiavi utilizzate per la Session Manager crittografia e la registrazione RDP nell'accesso al just-in-time nodo con la chiave del tag `SystemsManagerJustInTimeNodeAccessManaged` e il valore `true` del tag.
Per ulteriori informazioni sull'applicazione di tag alle chiavi KMS, consulta [Tag in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.
**Per aggiornare le preferenze della 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. Scegli **Impostazioni** nel pannello di navigazione.
1. Seleziona la scheda di **accesso al Just-in-time nodo**.
1. **Nella sezione **Preferenze di sessione**, seleziona Modifica**.
1. Aggiorna le preferenze generali e di registrazione in base alle esigenze e seleziona **Salva**.
# Configurare le notifiche per le richieste di just-in-time accesso
È possibile configurare Systems Manager per inviare notifiche quando un utente crea una richiesta di accesso al just-in-time nodo agli indirizzi e-mail o al client di chat per gli approvatori e il richiedente. La notifica contiene il motivo della richiesta di accesso fornita dal richiedente Account AWS Regione AWS, lo stato della richiesta e l'ID del nodo di destinazione. Attualmente, Systems Manager supporta i client Slack e Microsoft Teams tramite l'integrazione con Amazon Q Developer nelle applicazioni di chat. Quando si utilizzano le notifiche tramite client di chat, gli approvatori delle richieste di accesso possono interagire direttamente con le richieste di accesso. Ciò elimina la necessità di accedere alla console per intervenire sulle richieste di accesso.
**Prima di iniziare**
Prima di configurare un client di chat per le notifiche di accesso al just-in-time nodo, tieni presente il seguente requisito:
+ Se utilizzi i ruoli IAM per gestire le identità degli utenti nel tuo account, devi associare manualmente gli indirizzi e-mail degli approvatori o dei richiedenti a cui desideri inviare le notifiche con il ruolo associato. In caso contrario, i destinatari previsti non possono essere avvisati via e-mail.
Le seguenti procedure descrivono come configurare le notifiche per le richieste di accesso ai just-in-time nodi.
**Per configurare un client di chat per le notifiche di accesso al just-in-time nodo**
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 **Impostazioni** nel pannello di navigazione.
1. Seleziona la scheda di **accesso al Just-in-time nodo**.
1. Nella sezione **Chat**, seleziona **Configura nuovo client**.
1. Nel menu a discesa **Seleziona il tipo di client**, scegli il tipo di client di chat che desideri configurare e seleziona **Avanti**.
1. Ti viene richiesto di consentire ad Amazon Q Developer nelle applicazioni di chat di accedere al tuo client di chat. Seleziona **Consenti**.
1. Nella sezione **Configura canale**, inserisci le informazioni per il tuo canale client di chat e seleziona i tipi di notifiche che desideri ricevere.
1. Se stai configurando le notifiche Slack, invita "@Amazon Q" su ogni canale Slack in cui vengono configurate le notifiche.
1. Seleziona **Configura canale**.
**Nota**
Per consentire le richieste di approving/rejecting accesso direttamente da un canale Slack, assicurati che il ruolo IAM configurato con il canale Slack disponga delle `ssm:SendAutomationSignal` autorizzazioni e disponga di una politica di fiducia che includa il chatbot:
```
{
"Effect": "Allow",
"Principal": {
"Service": "chatbot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
```
**Per configurare le notifiche e-mail per le notifiche di accesso ai nodi just-in-time**
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 **Impostazioni** nel pannello di navigazione.
1. Seleziona la scheda di **accesso al Just-in-time nodo**.
1. Nella sezione **E-mail**, seleziona **Modifica**.
1. Seleziona **Aggiungi e-mail**, scegli il **ruolo IAM** a cui desideri associare manualmente gli indirizzi e-mail.
1. Inserisci un indirizzo e-mail nel campo **Indirizzo e-mail**. Ogni volta che viene creata una richiesta di accesso, che richiede l'approvazione del ruolo IAM specificato, gli indirizzi e-mail che associ al ruolo vengono notificati.
1. Seleziona **Aggiungi indirizzo e-mail**.
# Registrazione delle connessioni RDP
Just-in-time l'accesso al nodo include la possibilità di registrare le connessioni RDP effettuate ai Windows Server nodi. La registrazione delle connessioni RDP richiede un bucket S3 e una chiave AWS Key Management Service (AWS KMS) gestita dal cliente. AWS KMS key Viene utilizzato per crittografare temporaneamente i dati di registrazione mentre vengono generati e archiviati nelle risorse di Systems Manager. La chiave gestita dal cliente deve essere una chiave simmetrica con un utilizzo chiave di crittografia e decrittografia. È possibile utilizzare una chiave multiregionale per l'organizzazione oppure è necessario creare una chiave gestita dal cliente in ogni regione in cui è stato abilitato l'accesso ai just-in-time nodi.
Se hai abilitato la crittografia KMS sul bucket S3, in cui memorizzi le registrazioni, devi fornire l'accesso alla chiave gestita dal cliente utilizzata per la crittografia dei bucket al principale del servizio `ssm-guiconnect`. Questa chiave gestita dal cliente può essere diversa da quella specificata nelle impostazioni di registrazione, che devono includere la chiave per cui è richiesta l'autorizzazione `kms:CreateGrant` per stabilire connessioni.
## Configurazione della crittografia del bucket S3 per le registrazioni RDP
Le registrazioni delle connessioni vengono archiviate nel bucket S3, che specifichi quando abiliti la registrazione RDP.
Se utilizzi una chiave KMS come meccanismo di crittografia predefinito per il bucket S3 (SSE-KMS), è necessario consentire al principale del servizio `ssm-guiconnect` l'accesso all'azione `kms:GenerateDataKey` sulla chiave. Si consiglia di utilizzare una chiave gestita dal cliente durante l’utilizzo della crittografia SSE-KMS con il bucket S3. In questo modo, è possibile aggiornare la policy della chiave associata per una chiave gestita dal cliente. Non puoi aggiornare le politiche chiave per Chiavi gestite da AWS.
**Importante**
È necessario etichettare le AWS KMS chiavi utilizzate per la Session Manager crittografia e la registrazione RDP nell'accesso ai just-in-time nodi con la chiave del tag `SystemsManagerJustInTimeNodeAccessManaged` e il valore `true` del tag.
Per ulteriori informazioni sull'applicazione di tag alle chiavi KMS, consulta [Tag in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.
Utilizza la seguente policy della chiave gestita dal cliente per consentire al servizio `ssm-guiconnect` di accedere alla chiave KMS per l'archiviazione S3. Per informazioni sull'aggiornamento di una chiave gestita dal cliente, consulta [Modifica una policy della chiave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) nella *Guida per gli sviluppatori AWS Key Management Service *.
Sostituisci *example resource placeholder* ognuna con le tue informazioni:
+ *account-id*rappresenta l'ID di Account AWS chi avvia la connessione.
+ *region*rappresenta la posizione Regione AWS in cui si trova il bucket S3. (È possibile utilizzare `*`, se il bucket riceverà registrazioni da molteplici Regioni. Esempio: `s3.*.amazonaws.com`.)
**Nota**
Puoi utilizzare `aws:SourceOrgID` nella policy invece di `aws:SourceAccount`, se l'account appartiene a un'organizzazione di AWS Organizations.
```
{
"Sid": "Allow the GUI Connect service principal to access S3",
"Effect": "Allow",
"Principal": {
"Service": "ssm-guiconnect.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "account-id"
},
"StringLike": {
"kms:ViaService": "s3.region.amazonaws.com"
}
}
}
```
## Configurazione delle autorizzazioni IAM per la registrazione delle connessioni RDP
Oltre alle autorizzazioni IAM richieste per l'accesso al just-in-time nodo, all'utente o al ruolo utilizzato devono essere concesse le seguenti autorizzazioni in base all'attività da eseguire.
**Autorizzazioni per la configurazione della registrazione delle connessioni**
Per configurare la registrazione delle connessioni RDP, sono necessarie le seguenti autorizzazioni:
+ `ssm-guiconnect:UpdateConnectionRecordingPreferences`
+ `ssm-guiconnect:GetConnectionRecordingPreferences`
+ `ssm-guiconnect:DeleteConnectionRecordingPreferences`
+ `kms:CreateGrant`
**Autorizzazioni per l'avvio delle connessioni**
Per effettuare connessioni RDP con accesso al just-in-time nodo, sono necessarie le seguenti autorizzazioni:
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
+ `kms:CreateGrant`
**Prima di iniziare**
Per archiviare le registrazioni delle connessioni, devi prima creare un bucket S3 e aggiungere la seguente policy di bucket. Sostituisci ogni *example resource placeholder* con le tue informazioni.
Per informazioni sull'aggiunta di una policy di bucket, consulta [Aggiunta di una policy di bucket tramite l'utilizzo della console Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConnectionRecording",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm-guiconnect.amazonaws.com"
]
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition":{
"StringEquals":{
"aws:SourceAccount":"111122223333"
}
}
}
]
}
```
------
## Abilitazione e configurazione della registrazione delle connessioni RDP
La seguente procedura descrive come abilitare e configurare la registrazione delle connessioni RDP.
**Per abilitare e configurare la registrazione delle connessioni RDP**
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 **Impostazioni** nel pannello di navigazione.
1. Seleziona la scheda di **accesso al Just-in-time nodo**.
1. Nella sezione **Registrazione RDP**, seleziona Abilita registrazione RDP.
1. Scegli il bucket S3 in cui caricare le registrazioni delle sessioni.
1. Scegli la chiave gestita dal cliente da utilizzare per crittografare temporaneamente i dati di registrazione, mentre vengono generati e archiviati nelle risorse di Systems Manager. (Può trattarsi di una chiave gestita dal cliente diversa da quella utilizzata per crittografare il bucket.)
1. Seleziona **Salva**.
## Valori dello stato di registrazione della connessione RDP
I valori di stato validi per le registrazioni delle connessioni RPD includono i seguenti elementi:
+ `Recording` - La connessione è in fase di registrazione;
+ `Processing` - Il video viene elaborato dopo il termine della connessione;
+ `Finished` - Stato terminale completato: il video di registrazione della connessione è stato eseguito correttamente e caricato nel bucket specificato;
+ `Failed` - Stato terminale non eseguito. La registrazione della connessione non è eseguita.
+ `ProcessingError`- Durante l'elaborazione video failures/errors si sono verificati uno o più elementi intermedi. Le probabili cause includono errori di dipendenza dal servizio o autorizzazioni mancanti a causa di una configurazione errata del bucket S3 specificato per l'archiviazione delle registrazioni. Il servizio continua a tentare l'elaborazione, quando la registrazione è in questo stato.
**Nota**
`ProcessingError` può essere il risultato del mancato consenso del principale del servizio `ssm-guiconnect` a caricare oggetti nel bucket S3, dopo aver stabilito la connessione. Un'altra probabile causa è la mancanza delle autorizzazioni KMS sulla chiave KMS utilizzata per la crittografia dei bucket S3.
# Modifica delle destinazioni
Quando configuri l'accesso ai just-in-time nodi, scegli le *destinazioni* in cui desideri configurare l'accesso ai just-in-time nodi. Gli obiettivi sono costituiti da unità AWS Organizations organizzative (OUs) e Regioni AWS. Per impostazione predefinita, gli stessi obiettivi scelti durante la configurazione della console unificata Systems Manager sono selezionati per l'accesso ai just-in-time nodi. È possibile scegliere di configurare l'accesso ai just-in-time nodi per tutte le stesse destinazioni o per un sottoinsieme delle destinazioni specificate durante la configurazione della console unificata Systems Manager. L'aggiunta di nuove destinazioni che non erano state selezionate durante la configurazione della console unificata Systems Manager non è supportata. È possibile modificare le destinazioni selezionate dopo aver impostato l'accesso al just-in-time nodo.
La procedura seguente descrive come modificare le destinazioni per l'accesso ai just-in-time nodi.
**Per modificare le destinazioni**
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 **Impostazioni** nel pannello di navigazione.
1. Seleziona la scheda di **accesso al Just-in-time nodo**.
1. Nella sezione **Destinazioni**, seleziona **Modifica**.
1. Seleziona le **unità organizzative** e **le regioni** in cui desideri utilizzare l'accesso al just-in-time nodo.
1. Seleziona **Salva**.
# Modificare i provider di identità
Per impostazione predefinita, l'accesso ai just-in-time nodi utilizza IAM per un provider di identità. Dopo aver abilitato l'accesso ai just-in-time nodi, i clienti che utilizzano la console unificata con un'organizzazione possono modificare questa impostazione per utilizzare IAM Identity Center. Just-in-timel'accesso al nodo non supporta IAM Identity Center come provider di identità quando è configurato per un singolo account e regione.
La procedura seguente descrive come modificare il provider di identità per l'accesso al just-in-time nodo.
**Per modificare i provider di identità**
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 **Impostazioni** nel pannello di navigazione.
1. Seleziona la scheda di **accesso al Just-in-time nodo**.
1. Nella sezione **Identità utente**, seleziona **Modifica**.
1. Scegli **AWS IAM Identity Center**.
1. Seleziona **Salva**.
# Avvia una sessione di accesso al just-in-time nodo
Dopo aver abilitato e configurato l'accesso al just-in-time nodo e configurato le preferenze di sessione e notifica, gli utenti sono pronti per avviare le sessioni di accesso al just-in-time nodo. È possibile avviare le sessioni utilizzando l'accesso al just-in-time nodo dalla console Systems Manager o AWS Command Line Interface utilizzando il Session Manager plug-in. Just-in-timele sessioni di accesso ai nodi possono essere avviate su nodi dello stesso account e della stessa regione. Le procedure seguenti descrivono come avviare sessioni con accesso al just-in-time nodo.
**Nota**
Se in precedenza gli utenti si connettevano Session Manager ai nodi, è necessario rimuovere le Session Manager autorizzazioni, ad esempio`ssm:StartSession`, dalle politiche IAM per avviare sessioni utilizzando l'accesso ai just-in-time nodi. In caso contrario, continueranno a utilizzare Session Manager durante la connessione ai nodi.
**Per avviare una sessione con accesso al just-in-time nodo 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 riquadro di navigazione, seleziona **Esplora nodi**.
1. Scegli il nodo a cui desideri connetterti.
1. Nel menu a discesa **Azioni**, seleziona **Connettiti**.
Se le policy di approvazione della tua organizzazione non ti consentono di connetterti automaticamente al nodo, ti verrà richiesto di inviare una richiesta di accesso. Dopo aver compilato le informazioni richieste e inviato la richiesta di accesso, potrai avviare le sessioni sul nodo, una volta ricevute tutte le approvazioni richieste.
**Per avviare una sessione con accesso al just-in-time nodo utilizzando AWS CLI**
1. Esegui il comando seguente per avviare il flusso di lavoro delle richieste di accesso, assicurandoti di sostituirlo *placeholder values* con le tue informazioni.
```
aws ssm start-access-request \
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE
--reason "Troubleshooting networking performance issue"
```
A seconda delle policy di approvazione della tua organizzazione o verrai connesso automaticamente al nodo o verrà avviato il processo di approvazione manuale. Per le richieste che richiedono l'approvazione manuale, annota l'ID della richiesta di accesso restituita nella risposta.
1. Attendi che vengano fornite tutte le approvazioni richieste.
1. Dopo aver fornito tutte le approvazioni richieste, esegui il comando seguente per ottenere un token di accesso contenente credenziali temporanee. Sostituisci *placeholder values* con le informazioni appropriate.
```
aws ssm get-access-token \
--access-request-id oi-12345abcdef
```
Annota il token di accesso restituito nella risposta.
1. Esegui il comando seguente per utilizzare la credenziale temporanea presente in AWS CLI, assicurandoti di sostituirla *placeholder values* con le tue informazioni.
```
export AWS_SESSION_TOKEN=AQoDYXdzEJr...
```
1. Esegui il comando seguente per avviare una sessione sul nodo, assicurandoti di sostituirla *placeholder values* con le tue informazioni.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
# Gestione delle richieste di just-in-time accesso
Per una maggiore visibilità all'interno dell'organizzazione, Systems Manager replica le richieste di accesso all'account amministratore delegato dell'organizzazione. Per aiutarti a soddisfare i requisiti di conformità, Systems Manager mantiene tutte le richieste di accesso per un anno. I seguenti argomenti descrivono come gestire le richieste di accesso ai just-in-time nodi. Queste informazioni sono destinate agli approvatori delle richieste di accesso. Prima di iniziare, ti consigliamo di rivedere le tue politiche IAM e assicurarti di disporre delle autorizzazioni necessarie per amministrare just-in-time l'accesso ai nodi. Per ulteriori informazioni, consultare [Configurazione dell' just-in-timeaccesso con Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
**Topics**
+ [Approvazione e rifiuto delle richieste di accesso ai just-in-time nodi](systems-manager-just-in-time-node-access-approve-deny-requests.md)
# Approvazione e rifiuto delle richieste di accesso ai just-in-time nodi
Gli approvatori delle richieste di accesso possono approvare o rifiutare le richieste di accesso ai just-in-time nodi dalla console unificata Systems Manager o utilizzando lo strumento da riga di comando preferito. Queste informazioni sono destinate agli approvatori delle richieste di accesso. Se non disponi delle autorizzazioni necessarie per approvare o rifiutare le richieste di accesso, contatta l'amministratore. Le seguenti procedure descrivono come approvare o rifiutare le richieste di accesso ai nodi. just-in-time
**Per approvare o rifiutare le richieste di accesso al just-in-time nodo 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. Seleziona **Gestisci l'accesso al nodo** nel riquadro di navigazione.
1. Seleziona la scheda **Richieste di accesso**.
1. Seleziona l'interruttore **Richieste per me**.
1. Selezionare la casella di controllo accanto alla richiesta di accesso che desideri approvare o rifiutare.
1. Seleziona **Approva** o **Rifiuta**.
Dopo aver approvato una richiesta di accesso, puoi revocare l'approvazione in qualsiasi momento selezionando **Revoca**.
**Per approvare o rifiutare le richieste di accesso ai just-in-time nodi utilizzando la riga di comando**
1. Annota l'ID della richiesta di accesso dalla notifica. Ad esempio, *oi-12345abcdef*.
1. Esegui il comando seguente per restituire i dettagli sul flusso di lavoro di approvazione delle richieste di accesso, assicurandoti di sostituirli *placeholder values* con le tue informazioni.
```
aws ssm get-ops-item \
--ops-item-id oi-12345abcdef
```
Annota il valore `automationExecutionId` nel campo `/aws/accessrequest` per i `OperationalData`. Ad esempio, *9231944f-61c6-40be-8bce-8ee2bEXAMPLE*.
1. Esegui il comando seguente per approvare o rifiutare la richiesta di accesso. Utilizza il tipo di segnale `Approve`, per approvare la richiesta e `Deny` per rifiutarla. Assicurarsi di sostituire *placeholder values* con le proprie informazioni.
```
aws ssm send-automation-signal \
--automation-execution-id 9231944f-61c6-40be-8bce-8ee2bEXAMPLE \
--signal-type "Approve"
```
# Passaggio all'accesso al just-in-time nodo da Session Manager
Quando si abilita l'accesso ai just-in-time nodi, Systems Manager non apporta alcuna modifica alle risorse esistenti perSession Manager. Ciò garantisce che non si verifichino interruzioni dell'ambiente esistente e che gli utenti possano continuare ad avviare le sessioni, mentre creano e convalidano le policy di approvazione. Quando sei pronto a testare le tue politiche di approvazione, devi modificare le politiche IAM esistenti per completare la transizione all'accesso ai just-in-time nodi. Ciò include l'aggiunta delle autorizzazioni richieste per l'accesso ai just-in-time nodi alle identità e la rimozione dell'autorizzazione per il funzionamento dell'`StartSession`API per. Session Manager Consigliamo di testare le politiche di approvazione con un sottoinsieme di identità e nodi in un'unica soluzione. Account AWS Regione AWS
Per ulteriori informazioni sulle autorizzazioni richieste per l'accesso ai just-in-time nodi, consulta. [Configurazione dell' just-in-timeaccesso con Systems Manager](systems-manager-just-in-time-node-access-setting-up.md)
Per ulteriori informazioni sulla modifica e le autorizzazioni a un'identità IAM, consulta [Aggiunta e rimozione di autorizzazioni a identità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) nella *Guida per l'utente IAM*.
Di seguito viene descritto un metodo dettagliato per passare all'accesso al just-in-time nodo daSession Manager.
Il passaggio da Session Manager all'accesso ai just-in-time nodi richiede un'attenta pianificazione e test per garantire una transizione fluida senza interruzioni delle operazioni. Le sezioni seguenti descrivono come è possibile completare questo processo.
## Prerequisiti
Prima di iniziare, assicurati di aver completato le seguenti attività:
+ Configura la console unificata di Systems Manager.
+ Hai verificato di disporre delle autorizzazioni per modificare le policy IAM nel tuo account.
+ Ha identificato tutte le policy e i ruoli IAM che attualmente concedono le autorizzazioni a Session Manager.
+ Hai documentato l'attuale configurazione di Session Manager, incluse le preferenze di sessione e le impostazioni di registrazione.
## Valutazione
Valuta l'ambiente attuale e delinea i comportamenti di approvazione desiderati completando le seguenti attività:
1. **Effettua un inventario dei nodi**: identifica tutti i nodi a cui accedono attualmente gli utenti tramite Session Manager.
1. **Identifica i modelli di accesso degli utenti**: documenta quali utenti o ruoli devono accedere a quali nodi e in quali circostanze.
1. **Mappa i flussi di lavoro di approvazione**: stabilisci chi deve approvare le richieste di accesso per diversi tipi di nodi.
1. **Rivedi la strategia di etichettatura**: assicurati che i tuoi nodi siano etichettati correttamente per supportare le policy di approvazione pianificate.
1. **Verifica le policy IAM esistenti**: identifica tutte le policy che includono le autorizzazioni a Session Manager.
## Pianificazione
### Strategia graduale
Quando si passa dall'accesso Session Manager ai just-in-time nodi, si consiglia di utilizzare un approccio graduale come il seguente:
1. **Fase 1: installazione e configurazione**: abilita l'accesso al just-in-time nodo senza modificare le autorizzazioni esistentiSession Manager.
1. **Fase 2: sviluppo delle policy:** crea e testa le policy di approvazione per i nodi.
1. **Fase 3: migrazione pilota:** modifica di un piccolo gruppo di nodi e utenti o ruoli non critici dall'accesso Session Manager al just-in-time nodo.
1. **Fase 4: migrazione completa**: migra gradualmente tutti i nodi, gli utenti o i ruoli restanti.
### Considerazioni sulla cronologia
Considerate i seguenti fattori quando create la sequenza temporale per passare dall'accesso Session Manager ai just-in-time nodi:
+ Dedica del tempo alla formazione degli utenti e all'adattamento al nuovo flusso di lavoro di approvazione.
+ Pianifica le migrazioni durante periodi di minore attività operativa.
+ Includi il tempo di buffer per la risoluzione dei problemi e gli adattamenti.
+ Pianifica un periodo di funzionamento parallelo in cui entrambi i sistemi siano disponibili.
## Passaggi dell’implementazione
### Fase 1: installazione e configurazione
1. Abilita l'accesso ai just-in-time nodi nella console Systems Manager. Per informazioni dettagliate sulle fasi, consulta [Configurazione dell' just-in-timeaccesso con Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
1. Configura le preferenze di sessione per l'accesso ai just-in-time nodi in modo che corrispondano Session Manager alle impostazioni correnti. Per ulteriori informazioni, consulta [Aggiorna le preferenze della sessione di accesso al just-in-time nodo](systems-manager-just-in-time-node-access-session-preferences.md).
1. Configura le preferenze di notifica per le richieste di accesso. Per ulteriori informazioni, consulta [Configurare le notifiche per le richieste di just-in-time accesso](systems-manager-just-in-time-node-access-notifications.md).
1. Se utilizzi connessioni RDP ai nodi Windows Server, configura la registrazione RDP. Per ulteriori informazioni, consulta [Registrazione delle connessioni RDP](systems-manager-just-in-time-node-access-rdp-recording.md).
### Fase 2: sviluppo delle policy
1. Crea policy IAM per amministratori e utenti di accesso ai just-in-time nodi.
1. Sviluppa policy di approvazione basate sui tuoi requisiti di sicurezza e sui tuoi casi d'uso.
1. Testa le policy in un ambiente non di produzione per assicurarti che funzionino come previsto.
### Fase 3: migrazione del progetto pilota
1. Seleziona un piccolo gruppo di utenti e nodi non critici per il progetto pilota.
1. Crea nuove policy IAM per gli utenti pilota che includono le autorizzazioni di accesso ai just-in-time nodi.
1. Rimuovi le autorizzazioni a Session Manager (`ssm:StartSession`) dalle policy IAM degli utenti del progetto pilota.
1. Addestra gli utenti del progetto pilota sul nuovo flusso di lavoro per le richieste di accesso.
1. Monitora il progetto pilota per individuare eventuali problemi e raccogli feedback.
1. Adatta le policy e le procedure in base ai risultati del progetto pilota.
**Esempio di modifica della policy IAM per gli utenti del progetto pilota**
Policy originale con autorizzazioni a Session Manager:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
Policy modificata per l'accesso ai just-in-time nodi:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
### Fase 4: migrazione completa
Sviluppa una pianificazione per la migrazione degli utenti e dei nodi restanti in batch.
## Metodologia di effettuazione del test
Durante tutto il processo di migrazione, esegui i seguenti test:
+ **Convalida delle policy**: verifica che le policy di approvazione si applichino correttamente ai nodi e agli utenti previsti.
+ **Flusso di lavoro delle richieste di accesso**: testa il flusso di lavoro completo dalla richiesta di accesso alla creazione della sessione per scenari di approvazione automatica e manuale.
+ **Notifiche**: verifica che gli approvatori ricevano le notifiche tramite i canali configurati (e-mail, Slack, Microsoft Teams).
+ **Registrazione e monitoraggio**: verifica che i log delle sessioni e le richieste di accesso siano acquisiti e archiviati correttamente.
## Best practice per una migrazione di successo
+ **Comunica tempestivamente e spesso**: informa gli utenti sulla tempistica della migrazione e sui vantaggi dell'accesso ai just-in-time nodi.
+ **Inizia con sistemi non critici**: inizia la migrazione con ambienti di sviluppo o test prima di passare alla produzione.
+ **Documenta tutto**: conserva registrazioni dettagliate delle policy di approvazione, delle modifiche alle policy IAM e delle impostazioni di configurazione.
+ **Monitora e adatta**: monitora continuamente le richieste di accesso e i flussi di lavoro di approvazione, adattando le policy in base alle esigenze.
+ **Stabilisci la governance**: crea un processo per rivedere e aggiornare regolarmente le policy di approvazione, man mano che l'ambiente cambia.
# Disabilitazione dell' just-in-timeaccesso con Systems Manager
La procedura seguente descrive come disabilitare l'accesso ai just-in-time nodi. Dopo aver disabilitato l'accesso ai just-in-time nodi, gli utenti dell'organizzazione potrebbero non essere in grado di connettersi ai nodi a meno che non siano già stati implementati altri metodi di connessione.
**Per disabilitare l'accesso ai just-in-time nodi**
1. Accedi all'account amministratore delegato di Systems Manager della tua organizzazione.
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 **Impostazioni** nel pannello di navigazione.
1. Nella scheda di **accesso al Just-in-time nodo**, seleziona **Disabilita**.
# Just-in-time domande frequenti sull'accesso al nodo
## Come posso passare dall'accesso Session Manager al just-in-time nodo?
Dopo aver configurato la console unificata e abilitato l'accesso ai just-in-time nodi, è necessario modificare le policy IAM esistenti per completare il passaggio all'accesso ai just-in-time nodi. Ciò include l'aggiunta delle autorizzazioni richieste per l'accesso al just-in-time nodo e la rimozione dell'autorizzazione per il funzionamento dell'`StartSession`API per. Session Manager Per ulteriori informazioni sulle politiche IAM per l'accesso ai just-in-time nodi, consulta[Configurazione dell' just-in-timeaccesso con Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
## Devo configurare la console unificata per utilizzare l'accesso ai just-in-time nodi?
Sì, la configurazione della console unificata è un prerequisito per just-in-time l'accesso ai nodi. Tuttavia, dopo aver configurato la console unificata e abilitato l'accesso ai just-in-time nodi, esistono diversi metodi per connettersi ai nodi. Ad esempio, puoi avviare sessioni di accesso ai just-in-time nodi dalla console Amazon EC2 e dal. AWS CLI Per ulteriori informazioni sulla configurazione della console unificata, consulta [Configurazione della console unificata di Systems Manager per un'organizzazione](systems-manager-setting-up-organizations.md).
## Esistono costi associati all'accesso al just-in-time nodo?
Systems Manager offre una versione di prova gratuita di 30 giorni per l'accesso ai just-in-time nodi. Dopo il periodo di prova, l'accesso ai just-in-time nodi comporta dei costi. Per ulteriori informazioni, consulta la sezione [Prezzi di AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Qual è la precedenza per le politiche di approvazione dell'accesso ai just-in-time nodi?
Le policy di approvazione sono valutate nell'ordine seguente:
1. Negazione dell'accesso
1. Approvazione automatica
1. Manuale
## Come vengono valutate le policy di approvazione manuale?
Just-in-time l'accesso al nodo favorisce sempre la politica più specifica per un nodo. Le policy di approvazione manuale sono valutate nell'ordine seguente:
1. Destinazione specifica dei tag
1. Tutte le destinazioni del nodo
## Cosa succede se non c'è una policy di approvazione applicabile a un nodo?
Per connettersi a un nodo utilizzando l'accesso al just-in-time nodo, è necessario applicare una politica di approvazione al nodo. Se non esistono policy di approvazione applicabili a un nodo, gli utenti non possono richiedervi l'accesso.
## È possibile destinare molteplici policy di approvazione a un tag?
Un tag può essere designato una sola volta nelle tue policy di approvazione.
## Cosa succede se molteplici policy di approvazione manuale si applicano a un nodo a causa della sovrapposizione dei tag?
Quando a un nodo si applicano molteplici policy di approvazione manuale, si verifica un conflitto e gli utenti non sono in grado di richiedere l'accesso al nodo. Tienilo a mente quando crei le policy di approvazione manuale, poiché alcune istanze potrebbero avere molteplici tag, a seconda del caso.
## Posso utilizzare l'accesso al just-in-time nodo per richiedere l'accesso e avviare sessioni sui nodi tra account e regioni?
Just-in-time l'accesso al nodo supporta la richiesta di accesso e l'avvio di sessioni sui nodi nello stesso account e nella stessa regione del richiedente.
## Posso utilizzare l'accesso al just-in-time nodo per richiedere l'accesso e avviare sessioni sui nodi registrati con un'attivazione ibrida?
Sì, l'accesso ai just-in-time nodi supporta la richiesta di accesso e l'avvio di sessioni sui nodi registrati con un'attivazione ibrida. Il nodo deve essere registrato nello stesso account e nella stessa Regione del richiedente.
# Diagnosi e correzione
Tramite la console unificata di Systems Manager, è possibile identificare i problemi in tutto il parco in un'unica operazione di diagnosi. Per le organizzazioni, è quindi possibile tentare di risolverli su tutti gli obiettivi o solo su quelli selezionati attraverso un’unica operazione di automazione. Per un'organizzazione, in qualità di amministratore di account delegato, è possibile selezionare gli obiettivi in tutti gli account e le regioni. Se si utilizza un singolo account, è possibile selezionare gli obiettivi in una singola regione alla volta.
Systems Manager diagnostica e consente di risolvere al meglio diversi tipi di errori di implementazione, nonché deviazioni sulle configurazioni. Systems Manager, inoltre, identifica istanze Amazon Elastic Compute Cloud (Amazon EC2) nell'account o nell'organizzazione che Systems Manager non è in grado di trattare come *nodi gestiti.* Il processo di diagnosi delle istanze EC2 identifica problemi relativi a configurazioni errate in un cloud privato virtuale (VPC), in un'impostazione DNS (Domain Name Service) o in un gruppo di sicurezza Amazon Elastic Compute Cloud (Amazon EC2).
**Nota**
Systems Manager supporta sia istanze EC2 che altri tipi di macchine in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types) come *nodi gestiti*. Per essere un nodo gestito, l'agente AWS Systems Manager (SSM Agent) deve essere installato sulla macchina e Systems Manager deve disporre dell’autorizzazione per eseguire operazioni sulla macchina.
Per le istanze EC2, è possibile fornire questa autorizzazione a livello di account utilizzando un ruolo AWS Identity and Access Management (IAM) o a livello di istanza utilizzando un profilo dell'istanza. Per ulteriori informazioni, consulta [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md).
Per le macchine non EC2, questa autorizzazione viene fornita utilizzando un ruolo di servizio IAM. 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).
**Prima di iniziare**
Per utilizzare la funzionalità **Diagnosi e correzione**, al fine di rilevare istanze EC2 non gestite, è necessario prima integrare l’organizzazione o l’account nella console unificata di Systems Manager. Durante questo processo, occorre scegliere l'opzione per creare i ruoli IAM e le policy gestite necessarie per queste operazioni. Per ulteriori informazioni, consulta [Configurazione della console unificata di Systems Manager per un'organizzazione](systems-manager-setting-up-organizations.md).
Utilizza i seguenti argomenti per identificare e correggere alcuni tipi comuni di implementazioni non riuscite, configurazioni errate e istanze EC2 non gestite.
**Topics**
+ [Diagnosi e correzione delle implementazioni non riuscite](remediating-deployment-issues.md)
+ [Diagnostica e correzione di configurazioni deviate](remediating-configuration-drift.md)
+ [Diagnostica e correzione di istanze Amazon EC2 non gestite in Systems Manager](remediating-unmanaged-instances.md)
+ [Tipi di impatto delle operazioni del runbook sulla correzione](remediation-impact-type.md)
+ [Visualizzazione dello stato di avanzamento dell’esecuzione e della cronologia delle correzioni in Systems Manager](diagnose-and-remediate-execution-history.md)
# Diagnosi e correzione delle implementazioni non riuscite
Systems Manager diagnostica e, successivamente, aiuta a risolvere i seguenti tipi di installazioni non riuscite:
+ Configurazione di base per gli account membri dell'organizzazione
+ Configurazione di base per l'account di amministratore delegato
+ Configurazione di base per l'account
Utilizza la procedura seguente per tentare di risolvere questo tipo di problemi.
**Per diagnosticare e correggere le implementazioni non riuscite**
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 **Diagnostica e correggi**.
1. Scegli la scheda **Problemi di implementazione**.
1. Nella sezione **Implementazioni non riuscite**, esamina l'elenco dei relativi esiti.
1. Nella colonna **Fase di configurazione**, scegli il nome di un esito per esaminare ulteriori dettagli sul problema. Ad esempio: **configurazione di base per gli account dei membri dell'organizzazione**.
1. Nella pagina dei dettagli relativa all'implementazione non riuscita, è possibile visualizzare un elenco di account e il numero di regioni all'interno hanno subito errori di implementazione.
1. Seleziona un ID account per visualizzare le informazioni sul motivo degli errori in quell'account.
1. Nell'area **Regioni non riuscite**, esamina le informazioni fornite per il **Motivo dello stato**. Queste informazioni indicano il motivo della mancata implementazione, il che potrebbe fornire informazioni sulle modifiche alla configurazione da apportate.
1. Se desideri riprovare l'implementazione senza apportare modifiche alla configurazione, scegli **Ridistribuisci**.
# Diagnostica e correzione di configurazioni deviate
Systems Manager diagnostica e, successivamente, aiuta a correggere i seguenti tipi di configurazioni deviate:
+ Configurazione di base per gli account membri dell'organizzazione
+ Configurazione di base per l'account di amministratore delegato
+ Configurazione di base per l'account
Utilizza la seguente procedura per tentare di rimediare a questi tipi di configurazioni deviate.
**Per diagnosticare e correggere configurazioni deviate**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)Apri la console all'indirizzo. AWS Systems Manager
1. Nel riquadro di navigazione, scegli **Diagnostica e correggi**.
1. Scegli la scheda **Problemi di implementazione**.
1. Nella sezione **Implementazioni deviate**, esamina l'elenco degli esiti delle implimentazioni deviate.
oppure
Per eseguire una nuova diagnosi, scegli **Rileva la deviazione**.
1. Nella colonna **Fase di configurazione**, scegli il nome di un esito per esaminare ulteriori dettagli sul problema. Ad esempio: **configurazione di base per gli account dei membri dell'organizzazione**.
1. Nella pagina dei dettagli relativa all'implementazione non riuscita, è possibile visualizzare un elenco di account e indicare quante regioni di ciascuna hanno subito deviazioni di configurazione.
1. Seleziona un ID account per visualizzare le informazioni sul motivo delle deviazioni di configurazione in quell'account.
1. Nell'area **Risorse deviate**, la colonna **Risorse** riporta i nomi delle risorse che hanno subito una deviazione. La colonna **Tipo di deviazione** riporta se la risorsa è stata modificata o eliminata.
1. Per ridistribuire la configurazione desiderata, scegli **Ridistribuisci**.
# Diagnostica e correzione di istanze Amazon EC2 non gestite in Systems Manager
Per gestire al meglio le istanze Amazon Elastic Compute Cloud (Amazon EC2) con Systems Manager, è possibile utilizzare l'esperienza unificata della console di Systems Manager per effettuare le seguenti operazioni:
1. Esegui un processo di diagnosi manuale o pianificato per identificare quali istanze EC2 dell'account o dell'organizzazione non sono attualmente gestite da Systems Manager.
1. Identifica i problemi di rete o di altro tipo che impediscono a Systems Manager di assumere il controllo della gestione delle istanze.
1. Esegui un'esecuzione di automazione per risolvere automaticamente il problema, oppure accedi alle informazioni per risolvere il problema manualmente.
Utilizza le informazioni contenute nei seguenti argomenti per diagnosticare e risolvere i problemi che impediscono a Systems Manager di gestire le istanze EC2.
## In che modo Systems Manager conta i nodi interessati nell'elenco ''Problemi relativi alle istanze EC2 non gestite''
Il numero di nodi segnalati come non gestiti nella scheda **Problemi alle istanze EC2 non gestite** rappresenta il numero totale di istanze con uno dei seguenti valori di stato al momento della scansione della diagnosi:
+ `Running`
+ `Stopped`
+ `Stopping`
Questo numero è riportato come **Nodi interessati** nell'area di **Riepilogo del problema**. Nell'immagine seguente, il numero di nodi interessati non attualmente gestiti da Systems Manager è `40`.
![\[L'area “Riepilogo del problema” mostra 40 nodi interessati nella pagina Diagnosi e correzione\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/2-unmanaged-EC2-instance-count.png)
A differenza del rapporto sulle istanze EC2 non gestite nella pagina **Esamina approfondimenti nodi**, questo conteggio delle istanze EC2 non è dinamico. Rappresenta gli esiti ottenuti durante l'ultima scansione diagnostica segnalata, mostrati come valore del **tempo di scansione**. Consigliamo pertanto di eseguire una scansione diagnostica per le istanze EC2 non gestite a intervalli regolari per mantenere aggiornato il numero riportato di nodi interessati.
Per informazioni sui conteggi delle istanze non gestite nella pagina **Rivedi gli approfondimenti sui nodi**, consulta [Cos'è un'istanza non gestita](review-node-insights.md#unmanaged-instance-definition)? nell'argomento [Esaminare approfondimenti nodo](review-node-insights.md).
**Topics**
+ [In che modo Systems Manager conta i nodi interessati nell'elenco ''Problemi relativi alle istanze EC2 non gestite''](#unmanaged-instance-scan-count)
+ [Categorie di problemi diagnosticabili relativi alle istanze EC2 non gestite](diagnosing-ec2-category-types.md)
+ [Esecuzione di una diagnosi e di una riparazione opzionale per le istanze EC2 non gestite](running-diagnosis-execution-ec2.md)
+ [Pianificazione di una scansione ricorrente per istanze EC2 non gestite](schedule-recurring-ec2-diagnosis.md)
# Categorie di problemi diagnosticabili relativi alle istanze EC2 non gestite
Questo argomento elenca le principali categorie di problemi di gestione EC2 e i problemi specifici di ciascuna categoria che Systems Manager contribuisce a diagnosticare e risolvere. In alcuni casi, Systems Manager identifica il problema, ma non fornisce una correzione automatica. In questi casi, la console Systems Manager indirizza alle informazioni per risolvere manualmente un problema.
Il processo di diagnosi esamina ogni gruppo di istanze EC2 contemporaneamente in base al cloud privato virtuale (VPC) a cui appartengono.
**Topics**
+ [Categoria di problema: configurazione del gruppo di sicurezza e comunicazioni HTTPS](#unmanaged-ec2-issue-security-groups)
+ [Categoria di problema: configurazione DNS o nome host DNS](#unmanaged-ec2-issue-dns-configuration)
+ [Categoria di problema: configurazione dell'endpoint VPC](#unmanaged-ec2-issue-vpc-endpoint-configuration)
+ [Categoria di problema: configurazione ACL di rete](#unmanaged-ec2-issue-nacl-configuration)
## Categoria di problema: configurazione del gruppo di sicurezza e comunicazioni HTTPS
Un'operazione di diagnosi può rilevare che SSM Agent non è in grado di comunicare con il servizio Systems Manager tramite HTTPS. In questi casi, è possibile scegliere di eseguire un runbook Automation che tenti di aggiornare i gruppi di sicurezza collegati alle istanze.
**Nota**
A volte, Systems Manager può non essere in grado di risolvere automaticamente questi problemi, ma è possibile modificare manualmente i gruppi di sicurezza interessati.
**Tipi di problema supportati**
+ **Gruppo di sicurezza dell'istanza**: il traffico in uscita non è consentito sulla porta 443
+ **`ssm`Gruppo di sicurezza dell'endpoint VPC**: il traffico in entrata non è consentito sulla porta 443
+ **`ssmmessages`Gruppo di sicurezza dell'endpoint VPC**: il traffico in entrata non è consentito sulla porta 443
+ **`ec2messages`Gruppo di sicurezza dell'endpoint VPC**: il traffico in entrata non è consentito sulla porta 443
Per ulteriori informazioni, consulta [Verifica le regole di accesso sui gruppi di sicurezza degli endpoint](troubleshooting-ssm-agent.md#agent-ts-ingress-egress-rules) nell'argomento [Risoluzione dei problemi relativi a SSM Agent](troubleshooting-ssm-agent.md).
## Categoria di problema: configurazione DNS o nome host DNS
Un'operazione di diagnosi può rilevare che il Domain Name System (DNS) o i nomi host DNS non sono configurati correttamente per il VPC. In questi casi, si può scegliere di eseguire un runbook Automation che tenti di abilitare gli attributi `enableDnsSupport` e `enableDnsHostnames` del VPC interessato.
**Tipi di problema supportati**
+ Il supporto DNS è disabilitato in un VPC.
+ Un nome host DNS è disabilitato in un VPC.
Per ulteriori informazioni, consulta [Verifica gli attributi relativi al DNS del VPC](troubleshooting-ssm-agent.md#agent-ts-dns-attributes) nell'argomento [Risoluzione dei problemi relativi a SSM Agent](troubleshooting-ssm-agent.md).
## Categoria di problema: configurazione dell'endpoint VPC
Un'operazione di diagnosi può rilevare che gli endpoint VPC non sono configurati correttamente per il VPC.
Se gli endpoint VPC richiesti da SSM Agent non esistono, Systems Manager tenta di eseguire un runbook Automation per creare gli endpoint VPC e li associa a una sottorete in ogni zona di disponibilità (AZ) regionale pertinente. Se gli endpoint VPC richiesti esistono ma non sono associati a una sottorete in cui è stato rilevato il problema, il runbook associa gli endpoint VPC alla sottorete interessata.
**Nota**
Systems Manager non supporta la risoluzione di tutti i problemi dell'endpoint VPC non configurato correttamente. In questi casi, Systems Manager indirizza l’utente alle istruzioni manuali per la correzione anziché eseguire un runbook Automation.
**Tipi di problema supportati**
+ Non è PrivateLink stato trovato alcun `ssm.region.amazonaws.com` endpoint per.
+ Non è PrivateLink stato `ssmmessages.region.amazonaws.com` trovato alcun endpoint per.
+ Non è PrivateLink stato `ec2messages.region.amazonaws.com` trovato alcun endpoint per.
**Tipi di problemi diagnosticabili**
Systems Manager è in grado di diagnosticare i seguenti tipi di problemi, ma al momento non è disponibile alcun runbook per risolverli. È possibile modificare manualmente la configurazione per questi problemi.
+ La sottorete di un'istanza non è collegata a un endpoint `ssm.region.amazonaws.com`.
+ La sottorete di un'istanza non è collegata a un endpoint `ssmmessages.region.amazonaws.com`.
+ La sottorete di un'istanza non è collegata a un endpoint `ec2messages.region.amazonaws.com`.
Per ulteriori informazioni, consulta [Verifica la configurazione VPC](troubleshooting-ssm-agent.md#agent-ts-vpc-configuration) nell'argomento [Risoluzione dei problemi relativi a SSM Agent](troubleshooting-ssm-agent.md).
## Categoria di problema: configurazione ACL di rete
Un'operazione di diagnosi potrebbe rilevare che le liste di controllo degli accessi alla rete (NACLs) non sono configurate correttamente per il VPC, bloccando il traffico necessario per la comunicazione con Systems Manager. NACLs sono stateless, quindi sia le regole in uscita che quelle in entrata devono consentire il traffico di Systems Manager.
Systems Manager è in grado di identificare i problemi di configurazione NACL e fornire indicazioni per la correzione manuale.
**Tipi di problema supportati**
+ **Subnet di istanze NACL**: il traffico in uscita non è consentito sulla porta 443 verso gli endpoint Systems Manager
+ **Subnet di istanze NACL**: il traffico in entrata non è consentito sulle porte temporanee (1024-65535) per le risposte di Systems Manager
**Tipi di problemi diagnosticabili**
Systems Manager può diagnosticare i seguenti problemi di configurazione NACL, ma è necessaria una correzione manuale:
+ La sottorete NACL di un'istanza blocca il traffico HTTPS in uscita (porta 443) verso gli endpoint Systems Manager
+ Il NACL della sottorete di un'istanza blocca il traffico di porta effimero in entrata (1024-65535) necessario per le risposte di Systems Manager
Per ulteriori informazioni, consulta [Risoluzione dei problemi dell'agente SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html) e [della rete personalizzata ACLs per il tuo VPC](https://docs.aws.amazon.com/vpc/latest/userguide/custom-network-acl.html#nacl-ephemeral-ports).
# Esecuzione di una diagnosi e di una riparazione opzionale per le istanze EC2 non gestite
Utilizza la seguente procedura per diagnosticare i problemi relativi alla rete e al VPC che impediscono a Systems Manager di gestire le istanze EC2.
L'operazione di diagnosi rileva e raggruppa problemi dei seguenti tipi:
+ **Problemi di configurazione di rete**: tipi di problemi di rete che impediscono alle istanze EC2 di comunicare con il servizio Systems Manager nel cloud. Per questi problemi sono disponibili operazioni di correzione. Per ulteriori informazioni sui problemi di configurazioni di rete, consulta [Categorie di problemi diagnosticabili relativi alle istanze EC2 non gestite](diagnosing-ec2-category-types.md).
+ **Problemi non identificati**: un elenco degli esiti relativi ai casi in cui l'operazione di diagnostica non è riuscita a determinare il motivo per cui le istanze EC2 non sono in grado di comunicare con il servizio Systems Manager nel cloud.
**Per eseguire una diagnosi e una correzione per le istanze EC2 non gestite**
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 **Diagnostica e correggi**.
1. Scegli la scheda **Problemi alle istanze EC2 non gestite**.
1. Nella sezione **Riepilogo del problema**, scegli **Esegui nuova diagnosi**.
oppure
Se è la prima volta che diagnostichi problemi EC2 non gestiti, nella sezione **Diagnostica istanze EC2 non gestite**, scegli **Esegui**.
**Suggerimento**
Durante la diagnosi, scegli **Visualizza avanzamento** o **Visualizza esecuzioni** per monitorare lo stato corrente dell'esecuzione. Per ulteriori informazioni, consulta [Visualizzazione dello stato di avanzamento dell’esecuzione e della cronologia delle correzioni in Systems Manager](diagnose-and-remediate-execution-history.md).
1. Una volta completata la diagnosi, esegui le seguenti operazioni:
+ Per qualsiasi problema segnalato nella sezione **Problemi non identificati**, scegli il link **Ulteriori informazioni** per informazioni sulla risoluzione del problema.
+ Per i problemi segnalati nella sezione **Problemi sulla configurazioni di rete**, continua con il passaggio successivo.
1. Nell'elenco dei tipi di esito, nella colonna **Suggerimenti**, scegli il link per un problema specifico, ad esempio **2 suggerimenti**.
1. Nel riquadro **Suggerimenti** che si apre, scegli tra le mitigazioni disponibili:
+ **Ulteriori informazioni**: apri un argomento con informazioni su come risolvere un problema manualmente.
+ **Visualizza il runbook**: apri un riquadro con informazioni sul runbook Automation da eseguire per risolvere il problema con le istanze EC2, oltre alle opzioni per generare un'*anteprima* delle operazioni che il runbook intraprenderebbe. Passa alla fase successiva.
1. Nel riquadro del runbook, eseguire queste operazioni:
1. Per la **Descrizione del documento**, consulta il contenuto, che fornisce un'anteprima delle operazioni che il runbook intraprende per correggere i problemi relativi alle istanze EC2 non gestite. Scegli **Visualizza i passaggi** per visualizzare in anteprima le singole operazioni che il runbook intraprenderebbe.
1. Per **Destinazioni**, esegui queste operazioni:
+ Per gestire le riparazioni per un'organizzazione, per **Account**, specifica se questo runbook riguarderà tutti gli account o solo un sottoinsieme di account a scelta.
+ Per **le regioni**, specifica se questo runbook è destinato Regioni AWS a tutti gli utenti del tuo account o della tua organizzazione o solo a un sottoinsieme di regioni a tua scelta.
1. Per l'**Anteprima del runbook**, consulta attentamente le informazioni. Queste informazioni spiegano quale sarebbe l'ambito e l'impatto se si scegliesse di eseguire il runbook.
**Nota**
La scelta di eseguire il runbook comporterebbe dei costi, quindi esamina attentamente le informazioni di anteprima prima di decidere se procedere.
Il contenuto di **Anteprima del runbook** fornisce le seguenti informazioni:
+ In quante regioni verrebbe eseguita l'operazione del runbook.
+ (Solo organizzazioni) In quante unità organizzative (OUs) verrà eseguita l'operazione.
+ I tipi di operazioni che verrebbero intraprese e quante di ciascuna.
I tipi di operazioni includono quanto segue:
+ **Mutante**: una fase del runbook apporterebbe modifiche alle destinazioni tramite operazioni che creano, modificano o eliminano risorse.
+ **Non mutante**: una fase del runbook recupererebbe i dati sulle risorse, non apportandoci nessuna modifica. Questa categoria include generalmente `Describe*`, `List*`, `Get*` e simili operazioni API di sola lettura.
+ **Indeterminato**: un passaggio indeterminato richiama le esecuzioni eseguite da un altro servizio di orchestrazione come, o Run Command. AWS Lambda AWS Step Functions AWS Systems Manager Un passaggio indeterminato ha la possibilità di richiamare anche un'API di terze parti. Systems Manager Automation non conosce l'esito dei processi di orchestrazione o delle esecuzioni di API di terze parti, quindi i risultati delle fasi sono indeterminati.
1. In questo caso, è possibile scegliere una delle seguenti operazioni:
+ Arresta il runbook senza eseguirlo.
+ Scegli **Esegui** per eseguire il runbook con le opzioni che già selezionate.
Per scegliere di eseguire l'operazione, vai su **Visualizza avanzamento** o **Visualizza esecuzioni** per monitorare lo stato corrente dell'esecuzione. Per ulteriori informazioni, consulta [Visualizzazione dello stato di avanzamento dell’esecuzione e della cronologia delle correzioni in Systems Manager](diagnose-and-remediate-execution-history.md).
# Pianificazione di una scansione ricorrente per istanze EC2 non gestite
È possibile eseguire una scansione su richiesta per le istanze Amazon EC2 nell'account o organizzazione che Systems Manager non è in grado di gestire a causa di vari problemi di configurazione. È anche possibile pianificare questa scansione in modo che avvenga automaticamente a intervalli regolari.
**Per pianificare una scansione ricorrente per istanze EC2 non gestite**
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 **Diagnostica e correggi**.
1. Scegli la scheda **Problemi alle istanze EC2 non gestite**.
1. Nella sezione **Diagnostica istanze EC2 non gestite**, attiva **Pianifica diagnosi ricorrenti**.
1. Per **Frequenza diagnostica**, seleziona se eseguire la diagnosi una volta al giorno o una volta alla settimana.
1. (Facoltativo) In **Ora di inizio**, inserisci un'ora, in formato 24 ore, per l'inizio della diagnosi. Ad esempio, per le 20:15, inserisci **20:15**.
L'ora inserita si riferisce al fuso orario locale corrente.
Se non si specifica un orario, la scansione diagnostica verrà eseguita immediatamente. Systems Manager pianifica inoltre l'esecuzione della scansione in futuro all'ora corrente. Se si specifica un orario, Systems Manager attende l'esecuzione della scansione diagnostica all'ora specificata.
1. Scegli **Esegui**. La diagnosi viene eseguita immediatamente, ma verrà eseguita anche secondo la pianificazione specificata.
# Tipi di impatto delle operazioni del runbook sulla correzione
Systems Manager esegue operazioni di diagnosi che rilevano determinati tipi di implementazioni fallite e configurazioni deviate, nonché alcuni tipi di problemi di configurazione che impediscono a Systems Manager di gestire le istanze EC2. I risultati della diagnosi includono raccomandazioni per i runbook Automation da eseguire per tentare di risolvere un problema. Per ulteriori informazioni su queste operazioni di diagnosi, consulta i seguenti argomenti:
+ [Diagnosi e correzione delle implementazioni non riuscite](remediating-deployment-issues.md)
+ [Diagnostica e correzione di configurazioni deviate](remediating-configuration-drift.md)
+ [Diagnostica e correzione di istanze Amazon EC2 non gestite in Systems Manager](remediating-unmanaged-instances.md)
Quando Systems Manager identifica un problema da risolvere eseguendo un runbook Automation sulle risorse interessate, fornisce un'*anteprima di esecuzione*. L'anteprima di esecuzione fornisce informazioni sui *tipi* di modifiche che l'esecuzione del runbook apporterebbe agli obiettivi. Queste informazioni includono il numero di ciascuno dei tre tipi di modifiche identificati dalla diagnosi.
I tipi di modifiche consistono come segue:
+ `Mutating`: una fase di runbook apporterebbe modifiche alle destinazioni tramite operazioni che creano, modificano o eliminano risorse.
+ `Non-Mutating`: una fase del runbook recupererebbe i dati sulle risorse, non apportandoci nessuna modifica. Questa categoria include generalmente `Describe*`, `List*`, `Get*` e simili operazioni API di sola lettura.
+ `Undetermined`: un passaggio indeterminato richiama le esecuzioni eseguite da un altro servizio di orchestrazione come AWS Lambda, o AWS Step Functions, uno strumento in. Run Command AWS Systems Manager Un passaggio indeterminato potrebbe anche richiamare un'API di terze parti o eseguire un Python PowerShell o uno script. Systems Manager Automation non è in grado di rilevare quale sarebbe il risultato dei processi di orchestrazione o delle esecuzioni di API di terze parti, pertanto non li valuta. È necessario esaminare manualmente i risultati di tali fasi per determinarne l'impatto.
Consulta la tabella seguente per informazioni sul tipo di impatto delle operazioni di automazione supportate.
## Tipi di impatto delle operazioni di correzione supportate
La tabella presenta il tipo di impatto (mutante, non mutante e indeterminato) di varie operazioni incluse in un runbook di correzione.
| Azione¹ | Impact type (Tipo di impatto) |
| --- | --- |
| aws:approve | Non mutante |
| aws: Proprietà assertAwsResource | Non mutante |
| aws:branch | Non mutante |
| aws: changeInstanceState | Mutante |
| aws:copyImage | Mutante |
| aws:createImage | Mutante |
| aws:createStack | Mutante |
| aws:createTags | Mutante |
| aws:deleteImage | Mutante |
| aws:deleteStack | Mutante |
| aws:executeAutomation | Indeterminato |
| leggi: executeAwsApi | Indeterminato |
| aws:executeScript | Indeterminato |
| leggi: executeStateMachine | Indeterminato |
| leggi: invokeLambdaFunction | Indeterminato |
| aws:invokeWebhook | Indeterminato |
| aws:loop | Varia. Dipende dalle operazioni del loop. |
| aws:pause | Non mutante |
| aws:runCommand | Indeterminato |
| aws:runInstances | Mutante |
| aws:sleep | Non mutante |
| aws:updateVariable | Mutante |
| leggi: waitForAws ResourceProperty | Non mutante |
¹ Per ulteriori informazioni sulle operazioni di automazione, consultare [Riferimento alle operazioni del servizio di automazione di Systems Manager](automation-actions.md).
# Visualizzazione dello stato di avanzamento dell’esecuzione e della cronologia delle correzioni in Systems Manager
È possibile visualizzare un elenco di tutte le operazioni di correzione completate e in corso, eseguite tramite la funzionalità **Diagnosi e correzione** in Systems Manager.
I dati nell'elenco della cronologia di esecuzione riportano i seguenti tipi di informazioni:
+ Il tipo di esecuzione, `Diagnosis` o `Remediation`.
+ Lo stato di esecuzione, ad esempio `Success` o `Failed`.
+ Gli orari in cui l'esecuzione è iniziata e terminata.
**Per visualizzare lo stato di avanzamento dell'esecuzione e la cronologia delle correzioni**
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 **Diagnostica e correggi**.
1. Scegli **Visualizza esecuzioni**.
**Suggerimento**
Quando è in corso un'esecuzione, è inoltre possibile scegliere **Visualizza lo stato di avanzamento** per aprire la pagina della **cronologia delle esecuzioni**.
1. (Facoltativo) Nella barra di ricerca (![\[The search icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)), inserisci una frase per restringere l'elenco delle esecuzioni, ad esempio **EC2** o **VPC**.
1. (Facoltativo) Per visualizzare ulteriori dettagli su un'esecuzione, nella colonna **Nome esecuzione**, scegli un nome di operazione, ad esempio **AWS- DiagnoseUnmanaged EC2 NetworkIssues**.
Nel riquadro dei dettagli, è possibile esaminare le informazioni relative a tutti i passaggi per cui sono stati effettuati dei tentativi durante l'operazione e le informazioni relative a tutti gli input e output per l'esecuzione.
# Regolazione delle impostazioni di Systems Manager
Le opzioni nelle pagine delle **Impostazioni** abilitano e configurano le funzionalità nella console unificata di Systems Manager. Le opzioni visualizzate dipendono dall'account a cui è stato effettuato l'accesso e dal fatto che Systems Manager sia già stato configurato o meno.
**Nota**
Le opzioni nella pagina **Impostazioni** non influiscono sugli strumenti di Systems Manager (precedentemente denominati funzionalità).
## Impostazioni di configurazione dell'account
Se Systems Manager è abilitato e se è stato effettuato l'accesso a un account che non è membro di Organizzazioni, o se l'amministratore delegato non ha aggiunto l'account Organizzazioni a Systems Manager, la pagina **Impostazioni di configurazione** mostra l'opzione **Disabilita Systems Manager**. La disattivazione di Systems Manager implica che Systems Manager non visualizza la console unificata. Tutti gli strumenti di Systems Manager funzioneranno ancora.
## Impostazioni di configurazione organizzativa
Nella scheda **Configurazione organizzativa**, la sezione **Area di residenza** mostra la regione di residenza Regione AWS scelta durante la configurazione. Negli ambienti con più account e più regioni che utilizzano AWS Organizations, Systems Manager aggrega automaticamente i dati dei nodi da tutti gli account e le regioni alla regione di origine. L'aggregazione dei dati in questo modo consente di visualizzare i dati dei nodi tra account e regioni in un'unica posizione.
**Nota**
Se si desidera modificare la regione di origine, è necessario disattivare Systems Manager e, in seguito, riattivarlo. Per disabilitare Systems Manager, scegli **Disabilita**.
La sezione **Configurazione organizzativa** mostra le unità AWS organizzative Regioni AWS scelte durante la configurazione. Per modificare le unità organizzative e le regioni che visualizzano i dati dei nodi in Systems Manager, scegli **Modifica**. Per ulteriori informazioni sulla configurazione di Systems Manager per Organizations, consulta [Configurazione di AWS Systems Manager](systems-manager-setting-up-console.md).
## Configurazioni delle funzionalità
La sezione **Configurazioni delle funzionalità** consente di abilitare e configurare le funzionalità chiave di Systems Manager che migliorano la gestione dei nodi all'interno dell'organizzazione. Queste funzionalità interagiscono per fornire la gestione automatizzata, il monitoraggio della conformità e la manutenzione dei nodi gestiti.
È possibile configurare queste funzionalità durante la configurazione iniziale di Systems Manager o modificarle in un secondo momento tramite la pagina Impostazioni. Ogni funzionalità può essere abilitata o disabilitata indipendentemente in base ai requisiti dell'organizzazione.
### Configurazione di gestione host predefinita
La Configurazione di gestione host predefinita (Default Host Management Configuration, DHMC) configura automaticamente istanze Amazon Elastic Compute Cloud (Amazon EC2) nell'organizzazione per essere gestite da Systems Manager. Se abilitato, DHMC garantisce che le istanze EC2 nuove ed esistenti dispongano delle autorizzazioni e delle configurazioni AWS Identity and Access Management (IAM) necessarie per comunicare con i servizi Systems Manager.
DHMC offre i seguenti vantaggi:
+ **Assegnazione automatica dei ruoli IAM**: garantisce che le istanze EC2 abbiano i ruoli e le policy IAM necessari per funzionare come nodi gestiti
+ **Correzione delle deviazioni**: corregge automaticamente la deviazione della configurazione quando le istanze perdono lo stato di nodo gestito
+ **Onboarding semplificato**: riduce le fasi di configurazione manuale per le nuove istanze
+ **Configurazione coerente**: mantiene le impostazioni uniformi in tutto il parco EC2
#### Configurazione della frequenza di correzione della deviazione
La correzione della deviazione rileva e corregge automaticamente quando le istanze EC2 perdono la configurazione dei nodi gestiti. È possibile configurare la frequenza con cui Systems Manager verifica e corregge le deviazioni di configurazione.
**Per configurare la configurazione di gestione host predefinita**
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 **Impostazioni**.
1. Nella sezione **Configurazioni delle funzionalità**, individua la voce **Configurazione predefinita della gestione dell'host**.
1. Per abilitare DHMC, attiva l'interruttore di selezione.
1. Per la **frequenza di correzione della derivazione**, scegli con quale frequenza desideri che Systems Manager verifichi e corregga la deviazione della configurazione:
+ **Ogni giorno**: controlla e corregge la deviazione una volta al giorno
+ **Settimanale**: verifica e corregge la deriva una volta alla settimana
+ **Mensile**: verifica e corregge la deriva una volta al mese
1. Scegli **Save** (Salva).
**Nota**
Quando abiliti DHMC, Systems Manager crea i ruoli e le policy IAM necessari nel tuo account. Questi ruoli consentono alle istanze EC2 di comunicare con i servizi Systems Manager. Per ulteriori informazioni sulla creazione dei ruoli IAM tramite DHMC, consulta la sezione [Gestire le istanze EC2 con Systems Manager](systems-manager-setting-up-ec2.md).
### Raccolta dei metadati dell'inventario
La raccolta dei metadati dell'inventario raccoglie automaticamente informazioni dettagliate sui nodi gestiti, tra cui applicazioni installate, configurazioni di rete, aggiornamenti di sistema e altri metadati di sistema. Queste informazioni aiutano a mantenere la conformità, eseguire analisi di sicurezza e comprendere la composizione dell'infrastruttura.
La raccolta dell'inventario offre i seguenti vantaggi:
+ **Monitoraggio della conformità**: monitora il software e le configurazioni installati per i report di conformità
+ **Analisi della sicurezza**: identifica software obsoleti e potenziali vulnerabilità di sicurezza
+ **Gestione delle risorse**: mantieni un up-to-date inventario della tua infrastruttura
+ **Funzionalità di interrogazione**: utilizza i dati raccolti con Amazon Q Developer per query in linguaggio naturale
#### Tipi di dati di inventario raccolti
Quando la raccolta dei metadati dell'inventario è abilitata, Systems Manager raccoglie i seguenti tipi di informazioni dai nodi gestiti:
+ **Applicazioni**: pacchetti software e applicazioni installati
+ **Configurazioni di rete**: interfacce di rete, indirizzi IP e impostazioni di rete
+ **Aggiornamenti di sistema**: patch installate e aggiornamenti disponibili
+ **Proprietà del sistema**: specifiche hardware, dettagli del sistema operativo e configurazioni del sistema
+ **Servizi**: servizi in esecuzione e relative configurazioni
#### Configurazione della frequenza di raccolta dell'inventario
È possibile configurare la frequenza con cui Systems Manager raccoglie i metadati dell'inventario dai nodi gestiti. Una raccolta più frequente fornisce più up-to-date informazioni ma può aumentare l'utilizzo AWS del servizio.
**Per configurare la raccolta dei metadati 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 pannello di navigazione scegli **Impostazioni**.
1. Nella sezione **Configurazioni delle funzionalità**, individua la **raccolta dei metadati dell'inventario**.
1. Per abilitare la raccolta dell'inventario, attiva l'interruttore di selezione.
1. Per la **frequenza di raccolta**, scegli la frequenza con cui desideri che Systems Manager raccolga i dati di inventario:
+ **Ogni giorno**: raccoglie i dati di inventario una volta al giorno
+ **Settimanale**: raccoglie i dati di inventario una volta alla settimana
+ **Mensile**: raccoglie i dati di inventario una volta al mese
1. Scegli **Save** (Salva).
**Importante**
La raccolta dell'inventario richiede che i nodi gestiti dispongano delle autorizzazioni necessarie per raccogliere informazioni di sistema. Assicurati che i tuoi nodi gestiti abbiano i ruoli e le policy IAM appropriati. Per ulteriori informazioni sulle autorizzazioni richieste, consultare [AWS Systems Manager Inventory](systems-manager-inventory.md).
### Aggiornamenti di SSM Agent
Gli aggiornamenti SSM Agent automatici assicurano che i nodi gestiti eseguano la versione più recente dell'SSM Agent. Mantenere l'agente up-to-date consente di accedere alle funzionalità più recenti, ai miglioramenti della sicurezza e alle correzioni di bug.
SSM Agentgli aggiornamenti automatici offrono i seguenti vantaggi:
+ **Funzionalità più recenti**: accesso a nuove funzionalità e miglioramenti di Systems Manager
+ **Aggiornamenti di sicurezza**: installazione automatica di patch e correzioni di sicurezza
+ **Affidabilità migliorata**: correzioni di bug e miglioramenti dell'affidabilità
+ **Manutenzione ridotta**: elimina la necessità di aggiornamenti manuali degli agenti
#### Configurazione dell'aggiornamento automatico dell'agente
È possibile configurare la frequenza con cui Systems Manager verifica e installa gli aggiornamenti dell'SSM Agent sui nodi gestiti. Gli aggiornamenti regolari aiutano a garantire prestazioni e sicurezza ottimali.
**Per configurare gli aggiornamenti dell'SSM Agent**
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 **Impostazioni**.
1. Nella sezione **Configurazioni delle funzionalità**, individua **Aggiornamenti dell'**.
1. Per abilitare gli aggiornamenti automatici, attiva l'interruttore.
1. Per **Frequenza degli aggiornamenti**, scegli la frequenza con cui desideri che Systems Manager controlli e installi gli aggiornamenti degli agenti:
+ **Ogni giorno**: verifica la presenza di aggiornamenti una volta al giorno
+ **Settimanale**: verifica la presenza di aggiornamenti una volta alla settimana
+ **Mensile**: verifica la presenza di aggiornamenti una volta al mese
1. Scegli **Save** (Salva).
## Impostazioni di diagnosi e correzione
Le impostazioni **Diagnostica e correggi** determinano se Systems Manager esegue automaticamente la scansione dei nodi per garantire che comunichino con Systems Manager. Se abilitata, la funzionalità viene eseguita automaticamente in base a una pianificazione definita dall'utente. La funzionalità identifica quali nodi non sono in grado di connettersi a Systems Manager e perché. Questa funzionalità fornisce anche runbook consigliati per risolvere problemi di rete e altri problemi che impediscono la configurazione dei nodi come gestiti.
### Pianificazione di una scansione diagnostica ricorrente
Systems Manager diagnostica e consente di risolvere al meglio diversi tipi di errori di implementazione, nonché deviazioni sulle configurazioni. Systems Manager, inoltre, identifica istanze Amazon Elastic Compute Cloud (Amazon EC2) nell'account o nell'organizzazione che Systems Manager non è in grado di trattare come *nodi gestiti.* Il processo di diagnosi delle istanze EC2 identifica problemi relativi a configurazioni errate in un cloud privato virtuale (VPC), in un'impostazione DNS (Domain Name Service) o in un gruppo di sicurezza Amazon Elastic Compute Cloud (Amazon EC2).
Per semplificare il compito di identificare i nodi che non sono in grado di connettersi a Systems Manager, la funzionalità **Pianifica diagnosi ricorrente** consente di automatizzare, appunto, una scansione diagnostica ricorrente. Le scansioni consentono di identificare al meglio quali nodi non sono in grado di connettersi a Systems Manager e perché. Utilizza la seguente procedura per abilitare e configurare una scansione diagnostica ricorrente dei nodi.
**Per pianificare una scansione diagnostica ricorrente**
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 **Impostazioni**, quindi la scheda **Diagnostica e correggi**.
1. Attiva l'opzione **Pianifica diagnosi ricorrenti**.
1. Per **Periodo di scansione**, scegli la frequenza con cui desideri che venga eseguita la scansione.
1. (Facoltativo) In **Ora di inizio**, inserisci un'ora, in formato 24 ore, per l'inizio della diagnosi. Ad esempio, per le 20:15, inserisci **20:15**.
L'ora inserita si riferisce al fuso orario locale corrente.
Se non si specifica un orario, la scansione diagnostica verrà eseguita immediatamente. Systems Manager pianifica inoltre l'esecuzione della scansione in futuro all'ora corrente. Se si specifica un orario, Systems Manager attende l'esecuzione della scansione diagnostica all'ora specificata.
1. Scegli **Save** (Salva).
1. Al termine della scansione, visualizza i dettagli selezionando **Diagnostica e correggi** nel riquadro di navigazione a sinistra.
Per ulteriori informazioni sulla funzionalità **Diagnostica e correggi**, consulta [Diagnosi e correzione](diagnose-and-remediate.md).
### Aggiornamento della crittografia del bucket S3
Quando effettui l'onboard di Systems Manager, Quick Setup crea un bucket Amazon Simple Storage Service (Amazon S3) nell'account amministratore delegato per le configurazioni. AWS Organizations Per le configurazioni con account singolo, il bucket viene memorizzato nell'account da configurare. Questo bucket viene utilizzato per archiviare i metadati generati durante le scansioni diagnostiche.
Per ulteriori informazioni sulla configurazione della console unificata di Systems Manager, consulta [Configurazione di AWS Systems Manager](systems-manager-setting-up-console.md).
Per impostazione predefinita, i dati nel bucket sono crittografati utilizzando una chiave AWS Key Management Service (AWS KMS) che AWS possiede e gestisce per te.
Puoi scegliere di utilizzare una AWS KMS chiave diversa per la crittografia del bucket. In alternativa, è possibile utilizzare la crittografia lato server con AWS KMS keys (SSE-KMS) utilizzando una chiave gestita dal cliente (CMK). Per informazioni, consulta [Utilizzo dei bucket Amazon S3 e delle policy dei bucket per Systems Manager](systems-manager-diagnosis-metadata-bucket.md).
**Per utilizzare una chiave diversa per la crittografia dei bucket S3 AWS KMS**
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 **Impostazioni**, quindi la scheda **Diagnostica e correggi**.
1. Nell'area **Aggiorna la crittografia del bucket S3**, scegli **Modifica.**
1. Seleziona la casella di controllo **Personalizza le impostazioni di crittografia (avanzate)**.
1. Per **Scegli una AWS KMS chiave**, scegli o inserisci l'Amazon Resource Name (ARN) della chiave.
**Suggerimento**
Per creare una nuova chiave, scegli **Crea una chiave AWS KMS **.
1. Scegli **Save** (Salva).
# Utilizzo dei bucket Amazon S3 e delle policy dei bucket per Systems Manager
Durante il [processo di onboarding](systems-manager-setting-up-console.md) per AWS Systems Manager, Quick Setup crea un bucket Amazon Simple Storage Service (Amazon S3) nell'account amministratore delegato per le configurazioni dell'organizzazione. Per le configurazioni con account singolo, il bucket viene memorizzato nell'account da configurare.
È possibile utilizzare Systems Manager per eseguire operazioni di diagnostica sul parco istanze per identificare i casi di implementazioni fallite e configurazioni deviate. Systems Manager rileva anche i casi in cui i problemi di configurazione impediscono a Systems Manager di gestire le istanze EC2 nell'account o nell'organizzazione. I risultati di queste operazioni diagnostiche vengono archiviati in questo bucket Amazon S3, che è protetto sia da un metodo di crittografia che da una policy di bucket S3. Per informazioni sulle operazioni di diagnostica che inviano dati a questo bucket, consulta [Diagnosi e correzione](diagnose-and-remediate.md).
**Modifica del metodo di crittografia del bucket**
Per impostazione predefinita, il bucket S3 utilizza la crittografia lato server con le chiavi gestite da Amazon S3 (SSE-S3).
Puoi invece utilizzare la crittografia lato server con AWS KMS keys (SSE-KMS) utilizzando una chiave gestita dal cliente (CMK) come alternativa alle chiavi gestite di Amazon S3, come spiegato in. [Passaggio a una chiave gestita AWS KMS dal cliente per crittografare le risorse S3](remediate-s3-bucket-encryption.md)
**Contenuti della policy di bucket**
La policy di bucket impedisce l'individuazione reciproca degli account dei membri di un'organizzazione. Le autorizzazioni di lettura e scrittura per il bucket sono consentite solo per i ruoli di diagnosi e riparazione creati per Systems Manager. Il contenuto di queste policy generate dal sistema è presentato su [Policy di bucket S3 per la console di Systems Manager unificata](remediate-s3-bucket-policies.md).
**avvertimento**
La modifica della policy predefinita di bucket consente agli account membri di un'organizzazione di scoprirsi l'un l'altro oppure di leggere i risultati di diagnosi relativi alle istanze di un altro account. Consigliamo di utilizzare estrema cautela qualora si scegliesse di modificare questa policy.
**Topics**
+ [Passaggio a una chiave gestita AWS KMS dal cliente per crittografare le risorse S3](remediate-s3-bucket-encryption.md)
+ [Policy di bucket S3 per la console di Systems Manager unificata](remediate-s3-bucket-policies.md)
# Passaggio a una chiave gestita AWS KMS dal cliente per crittografare le risorse S3
Durante il processo di onboarding per la console unificata di Systems Manager, Quick Setup crea un bucket Amazon Simple Storage Service (Amazon S3) nell'account amministratore delegato. Questo bucket viene utilizzato per archiviare i dati di output della diagnosi generati durante le esecuzioni dei runbook di correzione. Per impostazione predefinita, il bucket utilizza la crittografia lato server con chiavi gestite da Amazon S3 (SSE-S3).
È possibile esaminare il contenuto di queste policy su [Policy di bucket S3 per la console di Systems Manager unificata](remediate-s3-bucket-policies.md).
Tuttavia, puoi invece utilizzare la crittografia lato server con AWS KMS keys (SSE-KMS) utilizzando una chiave gestita dal cliente (CMK) come alternativa a una. AWS KMS key
Completare le seguenti attività per configurare Systems Manager per l'utilizzo della CMK.
## Attività 1: aggiungere un tag a una CMK esistente
AWS Systems Manager utilizza la tua CMK solo se è etichettata con la seguente coppia chiave-valore:
+ Chiave: `SystemsManagerManaged`
+ Valore: `true`
Utilizza la seguente procedura per fornire l'accesso per la crittografia del bucket S3 con la CMK.
**Aggiungere un tag alla CMK esistente**
1. [Apri la AWS KMS console in /kms. https://console.aws.amazon.com](https://console.aws.amazon.com/kms)
1. Nella sezione di navigazione a sinistra, scegli **Chiavi gestite dal cliente**.
1. Seleziona il AWS KMS key da usare con. AWS Systems Manager
1. Seleziona la scheda **Tag**, quindi scegli **Modifica**.
1. Seleziona **Aggiungi tag**.
1. Esegui questa operazione:
1. In **Chiave di tag**, specifica **SystemsManagerManaged**.
1. In **Valore del tag**, inserisci **true**.
1. Scegli **Save** (Salva).
## Attività 2: modificare una policy della chiave CMK esistente
Utilizza la seguente procedura per aggiornare la [politica delle chiavi KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) della tua CMK per consentire ai AWS Systems Manager ruoli di crittografare il bucket S3 per tuo conto.
**Per modificare una policy della chiave CMK esistente**
1. [Apri la console in /kms. AWS KMS https://console.aws.amazon.com](https://console.aws.amazon.com/kms)
1. Nella sezione di navigazione a sinistra, scegli **Chiavi gestite dal cliente**.
1. Seleziona il AWS KMS key da usare con. AWS Systems Manager
1. Nella scheda **Policy della chiave**, seleziona **Modifica**.
1. Aggiungi la seguente istruzione JSON al `Statement` campo e sostituiscila *placeholder values* con le tue informazioni.
Assicurati di aggiungere sul campo tutto Account AWS IDs ciò che è presente nella tua organizzazione. AWS Systems Manager `Principal`
Per individuare il nome corretto del bucket nella console Amazon S3, nell'account amministratore delegato, individua il bucket nel formato `do-not-delete-ssm-operational-account-id-home-region-disambiguator`.
```
{
"Sid": "EncryptionForSystemsManagerS3Bucket",
"Effect": "Allow",
"Principal": {
"AWS": [
"account-id-1",
"account-id-2",
...
]
},
"Action": ["kms:Decrypt", "kms:GenerateDataKey"],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"StringLike": {
"kms:ViaService": "s3.*.amazonaws.com"
},
"ArnLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/AWS-SSM-*"
}
}
}
```
**Suggerimento**
In alternativa, puoi aggiornare la policy delle chiavi CMK utilizzando la chiave [aws: PrincipalOrg ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) condition per concedere AWS Systems Manager l'accesso alla tua CMK.
## Attività 3: specificare la CMK nelle impostazioni di Systems Manager
Dopo aver completato le due attività precedenti, utilizzare la procedura seguente per modificare la crittografia del bucket S3. Questa modifica garantisce che il processo di configurazione di Quick Setup associato aggiunga autorizzazioni affinché Systems Manager accetti la CMK.
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 **Impostazioni**.
1. Nella scheda **Diagnostica e correggi**, nella sezione **Aggiorna la crittografia del bucket S3**, scegli **Modifica**.
1. Seleziona la casella di controllo **Personalizza le impostazioni di crittografia (avanzate)**.
1. Nella casella di ricerca (![\[The search icon\]](http://docs.aws.amazon.com/it_it/systems-manager/latest/userguide/images/search-icon.png)), scegli l'ID di una chiave esistente, oppure incolla l'ARN di una chiave esistente.
1. Scegli **Salva**.
# Policy di bucket S3 per la console di Systems Manager unificata
Questo argomento include le policy di bucket di Amazon S3 create da Systems Manager quando si integra un'organizzazione o un singolo account nella console unificata di Systems Manager.
**avvertimento**
La modifica della policy di bucket predefinita consente agli account membri di un'organizzazione di scoprirsi l'un l'altro oppure di leggere i risultati di diagnosi relativi alle istanze di un altro account. Consigliamo di utilizzare estrema cautela qualora si scegliesse di modificare questa policy.
## Policy del bucket Amazon S3 per un'organizzazione
Il bucket di diagnosi viene creato con la seguente policy di bucket predefinita durante l'onboarding di un'organizzazione in Systems Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyHTTPRequests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyNonSigV4Requests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"StringNotEquals": {
"s3:SignatureVersion": "AWS4-HMAC-SHA256"
}
}
},
{
"Sid": "AllowAccessLog",
"Effect": "Allow",
"Principal": {
"Service": "logging.s3.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/access-logs/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "000000000000"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
},
{
"Sid": "AllowCrossAccountRead",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/actions/*/${aws:PrincipalAccount}/*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
}
}
},
{
"Sid": "AllowCrossAccountWrite",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::bucket-name/actions/*/${aws:PrincipalAccount}/*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/AWS-SSM-DiagnosisExecutionRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-DiagnosisAdminRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-RemediationExecutionRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-RemediationAdminRole-operational-123456789012-home-region"
]
}
}
},
{
"Sid": "AllowCrossAccountListUnderAccountOwnPrefix",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
},
"StringLike": {
"s3:prefix": "*/${aws:PrincipalAccount}/*"
}
}
},
{
"Sid": "AllowCrossAccountGetConfigWithinOrganization",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetEncryptionConfiguration",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
}
}
}
]
}
```
------
## Policy del bucket Amazon S3 per un singolo account
Il bucket di diagnosi viene creato con la seguente policy di bucket predefinita durante l'onboarding di un singolo account in Systems Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyHTTPRequests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyNonSigV4Requests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"StringNotEquals": {
"s3:SignatureVersion": "AWS4-HMAC-SHA256"
}
}
}
]
}
```
------