• O AWS Systems Manager CloudWatch Dashboard não estará mais disponível a partir de 30 de abril de 2026. Os clientes podem continuar usando o console do Amazon CloudWatch para visualizar, criar e gerenciar os painéis do Amazon CloudWatch exatamente como fazem hoje. Para obter mais informações, consulte a [documentação do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
# Executar tarefas de gerenciamento de nós com o AWS Systems Manager
Os tópicos a seguir descrevem como concluir tarefas em nós comuns usando o console unificado do AWS Systems Manager integrado para uma organização do AWS Organizations e Contas da AWS individuais.
**Topics**
+ [Como revisar insights de nós](review-node-insights.md)
+ [Explorando nós](view-aggregated-node-details.md)
+ [Acesso a nós just-in-time usando o Systems Manager](systems-manager-just-in-time-node-access.md)
+ [Diagnosticar e remediar](diagnose-and-remediate.md)
+ [Ajustar as configurações do Systems Manager](settings-overview.md)
# Como revisar insights de nós
É possível obter informações sobre o status geral dos nós gerenciados e das instâncias do EC2 não gerenciadas em sua organização ou conta usando o console unificado do Systems Manager.
O Systems Manager fornece uma visão geral visual dos nós gerenciados e das instâncias do EC2 que ainda não são gerenciadas pelo Systems Manager. (Um nó gerenciado é qualquer máquina configurada para uso com o Systems Manager em ambientes [híbridos e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). Para obter informações sobre os tipos de máquinas compatíveis, consulte [Tipos de máquinas compatíveis em ambientes híbridos e multinuvem](operating-systems-and-machine-types.md#supported-machine-types).)
Essa visão geral é fornecida por meio de caixas de relatórios individuais, chamadas de *widgets*, que apresentam gráficos de pizza interativos e outros tipos de gráficos.
**Antes de começar**
Para revisar insights do nó, primeiro é necessário integrar sua organização ou conta ao console unificado do Systems Manager. Para obter mais informações, consulte [Configurar o AWS Systems Manager](systems-manager-setting-up-console.md).
Após a integração, abra o [console do Systems Manager](https://console.aws.amazon.com/systems-manager/explorer) e escolha **Revisar insights do nó**.
A imagem a seguir mostra as caixas de relatório individuais, chamadas *widgets*, que estão disponíveis na página **Revisar insigths do nó**.
![\[Dados do nó exibidos na página Revisar insights do nó do Systems Manager\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/SYS2-Dashboard-Nodes.png)
A exibição é compatível com widgets que fornecem a você as informações a seguir.
**Resumo dos nós**
Indica quantas instâncias do EC2 em sua organização ou conta não são nós gerenciados atualmente e quantos nós gerenciados fazem parte da frota da sua organização ou conta.
**O que é uma instância não gerenciada?**
Quando você interrompe uma instância EC2 gerenciada, ela é relatada como "Não gerenciada" no console do Systems Manager. Esse é o comportamento esperado porque o SSM Agent não tem uma conexão ativa com o serviço.
Isso é diferente de como o AWS Config define uma instância como não gerenciada. Se uma instância estiver parada no momento, o AWS Config informa qual foi o status da instância na última vez em que uma conexão "heartbeat" foi feita entre o SSM Agent na instância e o serviço Systems Manager.
Quando a instância é reiniciada, ela se reconecta automaticamente ao serviço Systems Manager e seu status no console unificado é restaurado para "Gerenciada" em cinco minutos. Nenhuma intervenção manual é necessária e todas as configurações do Systems Manager para a instância são preservadas durante o ciclo de Parada/Início.
No entanto, se a instância ainda não for relatada como "Gerenciada" vários minutos após o início, é provável que a instância não esteja configurada adequadamente para o gerenciamento do Systems Manager. Nesse caso, recomendamos executar um diagnóstico para identificar por que a instância permanece em um estado não gerenciado. Para obter mais informações, consulte [Diagnosticar e corrigir instâncias não gerenciadas do Amazon EC2 no Systems Manager](remediating-unmanaged-instances.md).
Se a verificação de diagnóstico não conseguir determinar o problema, consulte os tópicos a seguir para verificar se os requisitos para o SSM Agent, perfis (IAM) AWS Identity and Access Management e os pré-requisitos do Systems Manager foram todos atendidos:
+ [Solução de problemas do SSM Agent](troubleshooting-ssm-agent.md)
+ [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md)
+ [Solução de problemas de disponibilidade do nó gerenciado](fleet-manager-troubleshooting-managed-nodes.md)
**Tipos de nós gerenciados**
Indica quantos nós gerenciados na sua frota são instâncias do EC2 e quantos são outros tipos de servidores, incluindo servidores em suas próprias instalações (servidores on-premises), dispositivos AWS IoT Greengrass básicos, dispositivos de borda AWS IoT e não AWS e máquinas virtuais (VMs), incluindo VMs em outros ambientes de nuvem. Mova o ponteiro do mouse sobre o gráfico **Tipos de nós** para acessar links com mais detalhes na página **Explorar nós**.
Para obter informações sobre suporte da AWS a ambientes híbridos e multinuvem, consulte [Soluções da AWS para nuvem híbrida e multinuvem](https://aws.amazon.com/hybrid-multicloud/).
**Versões do SSM Agent**
Fornece informações sobre as instalações do AWS Systems Manager Agent (SSM Agent) em sua frota. O SSM Agent é um software da Amazon que é executado em seus nós gerenciados. O SSM Agent permite que o Systems Manager atualize, gerencie e configure esses recursos. O agente processa as solicitações do serviço Systems Manager na Nuvem AWS e as executa conforme especificado na solicitação.
Para nós gerenciados em sua frota, esse widget relata as versões do SSM Agent em sua frota, da mais nova para a mais antiga. Mova o ponteiro do mouse sobre o gráfico **Versões do SSM Agent** para acessar links com mais detalhes na página **Explorar nós**.
Para obter mais informações sobre o SSM Agent, consulte [Trabalhar com o SSM Agent](ssm-agent.md).
**Sistemas operacionais de nós gerenciados**
Fornece um detalhamento da porcentagem de cada sistema operacional nos nós gerenciados da sua frota. Mova o ponteiro do mouse sobre o gráfico **Nós gerenciados por sistemas operacionais** para acessar links com mais detalhes na página **Explorar nós**.
É possível personalizar o layout dos widgets na página **Revisar insights do nó** usando um recurso de arrastar e soltar e removendo e adicionando widgets à tela.
Use as informações dos tópicos a seguir para obter ajuda para trabalhar com os widgets de insights do Systems Manager.
**Topics**
+ [Adicionar ou remover widgets da página **Revisar insights do nó**](review-node-insights-add-and-remove-widgets.md)
+ [Reorganizar widgets na página **Revisar insights do nó**](review-node-insights-rearrange-widgets.md)
# Adicionar ou remover widgets da página **Revisar insights do nó**
É possível personalizar o layout da página **Revisar insights do nó** do Systems Manager adicionando e removendo widgets.
**nota**
Por padrão, a página exibe todos os widgets disponíveis.
**Para adicionar ou remover widgets da página **Revisar insights do nó****
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Na navegação à esquerda, selecione **Revisar insights do nó**.
1. Para remover um widget da exibição, faça o seguinte:
1. Escolha o menu Mais opções (![\[The More options menu\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/more-options-menu-widgets.png)) para o widget.
1. Selecione **Remover widget**.
1. Para adicionar um widget à exibição, faça o seguinte:
1. Escolha **Adicionar widgets**.
1. No painel **Adicionar widgets**, clique e segure a alça de arrastar (![\[The drag handle\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) do widget para adicionar à exibição.
1. Arraste o widget e solte-o no painel principal.
# Reorganizar widgets na página **Revisar insights do nó**
É possível personalizar o layout na página **Revisar insights do nó** reorganizando os widgets.
**Para reorganizar os widgets na página **Revisar insights do nó****
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Revisar insights do nó**.
1. Para personalizar o layout de widgets, escolha um widget que gostaria de mover. Clique e mantenha pressionado a alça de arrastar (![\[The drag handle\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) do widget e arraste-o até o novo local.
1. Repita este processo para cada widget que você deseja reposicionar.
Se você decidir que não gosta do novo layout, escolha **Redefinir para layout padrão** para mover todos os widgets de volta para as posições originais.
# Explorando nós
Você pode usar a página **Explorar nós** no Systems Manager para revisar os detalhes dos nós gerenciados em sua organização ou conta de acordo com os critérios especificados nos filtros. Você também pode usar a integração do Systems Manager com o Amazon Q Developer (Amazon Q), uma solução de IA generativa da AWS, para pesquisar usando prompts de texto.
**Antes de começar**
Para usar o recurso **Explorar nós**, primeiro é necessário integrar sua organização ou conta ao console unificado do Systems Manager. Para ter mais informações, consulte [Configurar o console unificado do Systems Manager para uma organização](systems-manager-setting-up-organizations.md).
Após a integração, abra o [Console do Systems Manager](https://console.aws.amazon.com/systems-manager/) e escolha **Explorar nós**.
**nota**
Se você criou um índice agregador para o Explorador de Recursos em uma região diferente da sua região de origem, o Systems Manager rebaixa o índice atual. Em seguida, o Systems Manager promove o índice local em sua região de origem como o novo índice agregador. Durante esse período, somente os nós da sua região de origem são exibidos. A conclusão desse processo poderá demorar até 24 horas.
**Topics**
+ [Explorar nós usando filtros de console](view-aggregated-node-details-console.md)
+ [Explorar nós usando prompts de texto no Amazon Q](view-aggregated-node-details-Q.md)
+ [Visualizar detalhes individuais do nó e realizando ações em um nó](node-detail-actions.md)
+ [Baixar ou exportar um relatório de nó gerenciado](explore-nodes-download-report.md)
+ [Gerenciar o conteúdo e a aparência de relatórios de nós](explore-nodes-manage-report-display.md)
# Explorar nós usando filtros de console
No console do Systems Manager, é possível agrupar seus nós gerenciados de acordo com as seguintes visualizações:
------
#### [ All nodes (No filter) ]
Lista de todos os nós gerenciados em sua organização ou conta.
![\[Uma lista de nós gerenciados na página Explorar nós\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/2-explore-nodes-managed-nodes.png)
------
#### [ Node types ]
Fornece guias para visualização de dados separadamente para instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e outros tipos de máquina, incluindo servidores em suas próprias dependências (servidores on-premises), dispositivos AWS IoT Greengrass básicos, dispositivos de borda AWS IoT e não AWS e máquinas virtuais (VMs), incluindo VMs em outros ambientes de nuvem.
![\[Listas de nós gerenciados em guias de tipo de nó\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/2-explore-nodes-node-types.png)
------
#### [ Operating systems ]
Fornece uma guia para cada tipo de sistema operacional em sua organização ou conta, como **Amazon Linux** e **Microsoft Windows Server 2022 Datacenter**. Em cada guia, é possível filtrar ainda mais a lista selecionando somente versões específicas dos sistemas operacionais, como *Amazon Linux 2* e *Amazon Linux 2023*.
![\[Listas de nós gerenciados nas guias de sistema operacional\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/2-explore-nodes-operating-system.png)
------
#### [ SSM Agent versions ]
Fornece uma guia para cada versão do SSM Agent instalada nos nós gerenciados da sua frota. Em cada guia, é possível filtrar ainda mais a lista selecionando somente sistemas operacionais específicos, como **Amazon Linux** e **Microsoft Windows Server 2022 Datacenter**.
![\[Listas de nós gerenciados nas guias de agente\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/2-explore-nodes-agent-versions.png)
------
Além disso, para cada uma dessas visualizações, você pode refinar ainda mais a lista de nós relatados optando por visualizar somente os nós de uma determinada propriedade, como status do nó, ID do Conta da AWS, ID da unidade organizacional e mais.
É possível personalizar a exibição do relatório escolhendo quais das colunas de dados disponíveis serão exibidas na página **Explorar nós**. Você também pode baixar relatórios nos formatos `CSV` ou `JSON` ou exportar relatórios para o Amazon S3 no formato `CSV`.
**Topics**
+ [Escolher uma visualização de filtro para resumos de nós gerenciados](explore-nodes-filter-view.md)
# Escolher uma visualização de filtro para resumos de nós gerenciados
A página **Explorar nós** no Systems Manager permite visualizar dados agregados sobre sua frota de acordo com várias visualizações de filtro disponíveis.
**Para escolher uma visualização de filtro para resumos de nós gerenciados**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Explorar nós**.
1. Em **Visualização de filtro**, selecione uma das opções de filtro e, opcionalmente, refine ainda mais o relatório:
+ **Nós gerenciados**: na caixa de pesquisa (![\[The search icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/search-icon.png)), é possível selecionar uma propriedade e um delimitador, como `Node type = Managed EC2 instances`.
+ **Sistemas operacionais**: na lista **Filtrar versões do sistema operacional**, é possível selecionar um número de versão do sistema operacional. Na caixa de pesquisa (![\[The search icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/search-icon.png)), é possível selecionar uma propriedade e um delimitador, como `Node type = Managed EC2 instances`.
+ **Versões do SSM Agent**: na lista **Filtrar sistemas operacionais**, é possível selecionar um nome de sistema operacional. Na caixa de pesquisa (![\[The search icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/search-icon.png)), é possível selecionar uma propriedade e um delimitador, como `Node type = Managed EC2 instances`.
+ **Tipos de nós**: na lista **Filtrar sistemas operacionais**, é possível selecionar um nome de sistema operacional. Na caixa de pesquisa (![\[The search icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/search-icon.png)), é possível selecionar uma propriedade e um delimitador, como `Node type = Managed EC2 instances`.
Depois de filtrar a lista em caráter opcional, é possível visualizar detalhes sobre um nó gerenciado específico escolhendo seu ID na coluna **ID do nó**. A partir dessa visão detalhada, você pode realizar várias ações no nó.
# Explorar nós usando prompts de texto no Amazon Q
Usando a integração do Systems Manager com o Amazon Q Developer, você pode usar solicitações de texto para visualizar informações criadas por IA generativa sobre seus nós gerenciados.
O Amazon Q Developer é um assistente conversacional baseado em IA generativa que pode ajudar você a entender, criar, estender e operar aplicações da AWS. Para acelerar o desenvolvimento na AWS, o modelo que impulsiona o Amazon Q foi aprimorado com conteúdo de alta qualidade da AWS para fornecer respostas mais completas, acionáveis e referenciadas. Para ter mais informações, consulte [What is Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/aws-builder-use-ug/what-is.html) no *Guia do usuário do Amazon Q Developer*.
A integração entre o Systems Manager e o Amazon Q permite que você obtenha rapidamente visibilidade e controle sobre ambientes grandes e distribuídos em várias regiões e Contas da AWS. É possível usar consultas em linguagem natural para pesquisar rapidamente dados de nós, identificar problemas e agir com mais rapidez.
Quando você faz uma pergunta em linguagem natural sobre nós gerenciados ou instâncias gerenciadas, o Amazon Q usa a ação `ListNodes` do Systems Manager e cria filtros com base na sua entrada de texto para recuperar os resultados.
Por exemplo, digamos que você forneça o seguinte prompt à Amazon Q:
**List my managed nodes running Red Hat Enterprise Linux 9.2**
O Amazon Q determina quais filtros incluir em uma solicitação e, em seguida, executa uma consulta semelhante à seguinte:
```
aws ssm list-nodes \
--filters Key=PlatformName,Values='Red Hat Enterprise Linux',Type=Equal Key=PlatformVersion,Values=9.2,Type=Equal
```
Em seguida, o Amazon Q gera um relatório sobre instâncias do Red Hat Enterprise Linux em sua conta, listando informações como o número de instâncias, seus IDs e suas regiões.
Você também pode ver um resumo JSON dos detalhes de cada instância, bem como abrir um link para ver as listas completas de instâncias do EC2 ou nós gerenciados na página **Explorar nós** do Systems Manager. **Explorar nós** exibe resultados que correspondem aos critérios de filtro que você incluiu no prompt. A partir daí, você pode alterar ou refinar os filtros da sua solicitação, conforme descrito em [Explorando nós](view-aggregated-node-details.md).
**Topics**
+ [Como criar prompts eficazes para perguntar ao Amazon Q sobre sua frota](view-aggregated-node-details-Q-prompts.md)
+ [Explorar nós gerenciados com o Amazon Q](explore-managed-nodes-using-Q.md)
# Como criar prompts eficazes para perguntar ao Amazon Q sobre sua frota
Quanto melhor a qualidade da pergunta, ou prompt, que você fornecer ao Amazon Q, melhor será o resultado que ela fornecerá.
**Dicas para solicitações de consulta**
Lembre-se das dicas a seguir ao consultar o Amazon Q sobre sua frota:
1. Para ajudar a melhorar a precisão dos resultados, use os termos "nós gerenciados" e "instâncias gerenciadas" em seus prompts, em vez de apenas "nós" e "instâncias".
1. Para consultar resultados em várias contas que fazem parte de uma *organização*, conforme configurado em AWS Organizations, você deverá estar conectado à conta de administrador delegado na região de origem designada.
1. Na conta de administrador delegado, use termos para ajudar a Amazon Q a entender que você está perguntando sobre nós e instâncias em toda a organização usando especificamente termos como "na minha organização" ou "na minha conta 123456789012".
**Topics**
+ [Exemplos de perguntas para o Amazon Q](#sample-questions-Q)
+ [Nomes e versões de sistemas operacionais compatíveis para prompts](#supported-os-names-Q)
## Exemplos de perguntas para o Amazon Q
Na tabela a seguir, fornecemos exemplos de perguntas que demonstram algumas maneiras pelas quais você pode criar consultas do Amazon Q que levam a melhores resultados.
Também fornecemos exemplos dos filtros que o Amazon Q aplicará ao executar o comando [ListNodes](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListNodes.html), os quais são gerados a partir do conteúdo do seu prompt.
| Exemplo de pergunta em linguagem natural | Filtros aplicados do 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
|
## Nomes e versões de sistemas operacionais compatíveis para prompts
Quando você pergunta ao Amazon Q sobre os nós gerenciados em sua conta, é útil fornecer o nome de um sistema operacional conforme rotulado no Systems Manager. Você também pode fornecer números de versão para restringir ainda mais os resultados. Por exemplo, conforme representado nas tabelas a seguir, você pode solicitar resultados específicos sobre **macOS 14.5**, **Microsoft Windows Server 2019 Datacenter** e **AlmaLinux 9.2 through 9.4**, apenas para citar alguns exemplos.
Essas listas podem não ser completas e são oferecidas apenas como exemplos.
**macOS**
| nome-da-plataforma | Números de versão |
| --- | --- |
| macOS | 13.2, 13.4, 13.7, 14.1, 14.5, 14.6.1, 15.0 |
**Windows**
| Versões | Números de versão |
| --- | --- |
| 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 | 10.0.20348 |
**Linux**
| Nomes de plataformas | Números de versão |
| --- | --- |
| AlmaLinux | 8.10, 9.2, 9.3, 9.4 |
| Amazon Linux 2 | 2.0 e posteriores |
| Amazon Linux 2023 | 2023.0.20230315.0 e posteriores |
| 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 |
| Red Hat Enterprise LinuxServidor do | 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 |
# Explorar nós gerenciados com o Amazon Q
A integração do Systems Manager com o Amazon Q Developer permite fazer perguntas sobre nós gerenciados em sua frota de qualquer lugar no Console de gerenciamento da AWS em que a interface do Amazon Q esteja disponível.
Para obter mais informações sobre como interagir com o Amazon Q, consulte [Conversando com o Amazon Q Developer sobre AWS](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html) no *Guia do usuário do Amazon Q Developer*.
**Para explorar nós gerenciados com o Amazon Q**
1. Em qualquer lugar do Console de gerenciamento da AWS, escolha o ícone do Amazon Q (![\[The Amazon Q icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/q-icon-white.png)).
1. No campo de prompt na parte inferior do painel do Amazon Q, faça uma pergunta sobre os nós gerenciados em sua conta ou organização.
**dica**
Para obter dicas de como criar prompts eficazes, revise as informações em [Como criar prompts eficazes para perguntar ao Amazon Q sobre sua frota](view-aggregated-node-details-Q-prompts.md).
1. Examine as informações sobre nós específicos ou escolha **Abrir console do AWS Systems Manager** para continuar explorando.
# Visualizar detalhes individuais do nó e realizando ações em um nó
Em uma lista na página **Explorar nós** no Systems Manager, é possível selecionar um nó individual para visualizar detalhes abrangentes sobre a máquina ou realizar diversas ações no nó. A página **Geral** na página de detalhes apresenta informações abrangentes sobre o nó.
**Para visualizar detalhes individuais do nó e realizar ações em um nó**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Explorar nós**.
1. (Opcional) Siga as etapas em [Escolher uma visualização de filtro para resumos de nós gerenciados](explore-nodes-filter-view.md) para refinar a lista de nós gerenciados exibidos para sua organização ou conta.
1. Na coluna **ID do nó**, escolha o ID vinculado de um nó.
1. Para ver mais detalhes sobre o nó, na navegação à esquerda, na lista **Propriedades**, escolha uma propriedade para visualizar mais informações sobre:
+ **Tags**: visualize uma lista de tags aplicadas ao nó. Também é possível adicionar ou remover tags.
+ **Inventário**: escolha um tipo de inventário, como **AWS:Application ou **AWS:Network****, para visualizar os detalhes do inventário do nó.
+ **Associações**: visualize detalhes sobre todas as associações do State Manager aplicadas ao nó, incluindo detalhes como status e nome do documento do SSM associado.
+ **Patches**: visualize informações resumidas sobre os patches e o status do patch para o nó.
+ **Conformidade da configuração**: visualize detalhes de conformidade do nó, como status de conformidade e gravidade do problema de conformidade.
Para obter mais informações sobre os detalhes nas guias, consulte [O que é o console unificado?](systems-manager-unified-console.md).
1. Para realizar ações no nó, use as seguintes opções no menu **Ações do nó**:
**nota**
Essas ações estão disponíveis somente para nós gerenciados na região e na Conta da AWS em que você está trabalhando no momento. Para nós gerenciados aos quais você pode ter acesso em outras contas ou regiões, é possível acessar uma lista de **Propriedades**.
+ **Conectar, iniciar sessão do terminal**: conecte ao nó usando o [AWS Systems Manager Session Manager](session-manager.md).
+ **Ferramentas**
+ **Visualizar sistema de arquivos**: navegue pelo conteúdo da estrutura de diretórios do nó. Adicione, renomeie e remova diretórios. Recorte ou copie e cole arquivos.
+ **Visualizar contadores de performance**: visualize informações de performance sobre o nó, como utilização da CPU, tráfego de rede e outros tipos de utilização.
+ **Processos gerenciados**: visualize informações sobre o uso de recursos no nó. Inicie ou interrompa processos no nó.
+ **Gerenciar usuários e grupos**: visualize, adicione ou exclua contas de usuário e grupos de usuários no nó.
+ **Executar comando de execução**: use [AWS Systems Manager Run Command](run-command.md) para gerenciar a configuração do nó. Run Command usa [documentos do Systems Manager](documents.md) para realizar alterações sob demanda, como atualizar aplicações ou executar scripts de shell do Linux e comandos do Windows PowerShell.
+ **Aplicar patches em nós**: use o recurso **Aplicar patch agora** no [AWS Systems Manager Patch Manager](patch-manager.md) para executar uma operação de correção sob demanda no nó via console.
**nota**
As tarefas anteriores também podem ser iniciadas no menu **Ferramentas** na navegação à esquerda.
+ **Configurações do nó**
+ **Adicionar tags**: aplique pares de chave-valor de tag ao nó.
+ **Redefinir senha do usuário do nó**: defina uma nova senha para um usuário especificado no nó.
+ **Modificar perfil do IAM**: altere o perfil do IAM associado ao nó. Crie um perfil do IAM para associar ao nó.
# Baixar ou exportar um relatório de nó gerenciado
É possível usar o recurso **Explorar nós** do Systems Manager para visualizar listas filtradas ou não filtradas de nós gerenciados para sua organização ou conta da AWS no console do Systems Manager. Nos casos em que você deseja visualizar os dados offline ou processá-los em outra aplicação, é possível salvar o relatório como um arquivo `CSV` ou `JSON`.
Dependendo do tamanho do relatório, você será solicitado a baixar o relatório para sua máquina local ou exportá-lo para um bucket do Amazon S3. Os relatórios são salvos nos buckets do S3 somente no formato `CSV`.
**Para baixar ou exportar um relatório de nó gerenciado**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Explorar nós**.
1. (Opcional) Siga as etapas em [Escolher uma visualização de filtro para resumos de nós gerenciados](explore-nodes-filter-view.md) para refinar a lista de nós gerenciados exibidos para sua organização ou conta.
1. Escolha **Relatório** (![\[The download report icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/download-arrow-icon.png)).
1. Se a caixa de diálogo **Baixar relatório** for exibida, faça o seguinte:
1. Em **Nome do arquivo**, insira um nome para o arquivo. Recomendamos especificar um nome que represente o escopo do relatório, como `all-organization-nodes` ou `ec2-instances-out-of-date-agent`.
1. Em **Colunas incluídas**, especifique se deseja incluir colunas para todos os detalhes dos nós disponíveis ou somente aqueles que você selecionou para sua exibição atual.
**dica**
Para obter informações sobre o gerenciamento de colunas na exibição do relatório, consulte [Gerenciar o conteúdo e a aparência de relatórios de nós](explore-nodes-manage-report-display.md).
1. Em **Formato do arquivo**, selecione **CSV** ou **JSON**, dependendo de como você usará o arquivo.
1. Em **Título da planilha**, para incluir uma linha de cabeçalhos de coluna em um arquivo `CSV`, selecione **Incluir linha de nomes de colunas**.
1. Escolha **Baixar**.
O relatório é salvo no local de download padrão de acordo com as configurações do seu navegador.
1. Se a caixa de diálogo **Exportar para o Amazon S3** for exibida, faça o seguinte:
1. Em **URI do S3**, insira o URI do bucket para o qual exportar o relatório.
**dica**
Para visualizar uma lista dos buckets do console do Amazon S3, escolha **Visualizar**. Para selecionar em uma lista de buckets em sua conta **Navegar pelo S3**.
1. Para **Método de autorização**, especifique o perfil de serviço a ser usado para fornecer permissões para exportar o relatório para o bucket.
Se você optar por permitir que o Systems Manager crie o perfil para você, ele fornecerá todas as permissões e declarações de confiança necessárias para a operação.
Se você quiser usar ou criar seu próprio perfil, o perfil deverá incluir as permissões e declarações de confiança necessárias. Para obter informações sobre como criar essa função, consulte [Criar um perfil de serviço personalizado para exportar relatórios de diagnóstico para o S3](create-s3-export-role.md).
1. Selecione **Enviar**.
# Criar um perfil de serviço personalizado para exportar relatórios de diagnóstico para o S3
Ao visualizar listas filtradas ou não filtradas de nós gerenciados para sua organização ou conta da AWS na página **Explorar nós** do Systems Manager, é possível exportar a lista como um relatório para um bucket do Amazon S3 na forma de um arquivo `CSV`.
Para fazer isso, é necessário especificar um perfil de serviço com as permissões necessárias e a política de confiança para a operação. É possível fazer com que o Systems Manager crie o perfil para você durante o processo de download do relatório. Opcionalmente, você mesmo pode criar o perfil e a política necessários.
**Para criar um perfil de serviço personalizado para exportar relatórios de diagnóstico para o S3**
1. Siga as etapas em [Criar políticas usando o editor JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) no *Guia do usuário do IAM*.
+ Use o conteúdo a seguir para a política, certificando-se de substituir os *valores do espaço reservado* por suas próprias informações.
------
#### [ 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": "*"
}
]
}
```
------
+ Atribua um nome à política para obter ajuda para reconhecê-la facilmente na próxima etapa.
1. Siga o procedimento [Criar um perfil do IAM usando políticas de confiança personalizadas (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) no *Guia do usuário do IAM*.
+ Na etapa 4, insira a política de confiança a seguir, certificando-se de substituir os *valores do espaço reservado* por suas próprias informações.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMAssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
1. Para a etapa 10, escolha **Etapa 2: adicionar permissões** e selecione o nome da política que você criou na etapa anterior.
Após criar a função, você poderá selecioná-la seguindo as etapas em [Baixar ou exportar um relatório de nó gerenciado](explore-nodes-download-report.md).
# Gerenciar o conteúdo e a aparência de relatórios de nós
É possível usar o recurso **Explorar nós** do Systems Manager para visualizar listas filtradas ou não filtradas de nós gerenciados para sua organização ou conta da AWS no console do Systems Manager. É possível escolher entre mais de uma dúzia de campos para incluir em suas listas de nós, como **ID do nó**, **Nome do sistema operacional**, **Região** e muito mais. Também é possível reordenar as colunas de suas listas e relatórios e alterar a forma como a lista é exibida no console.
**Para gerenciar o conteúdo e a aparência de um relatório de nó**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Explorar nós**.
1. Na área **Nós**, escolha o ícone de engrenagem de preferências (![\[The preferences gear icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/preferences-icon.png)).
1. Na caixa de diálogo **Preferências** faça o seguinte:
1. Em **Tamanho da página**, escolha quantas linhas estão incluídas em cada exibição do console, **10**, **25** ou **50**.
1. Em **Quebrar linhas**, selecione a caixa para exibir todo o conteúdo de uma célula na largura disponível da coluna.
1. Em **Linhas listradas**, selecione a caixa para exibir linhas alternadas de planos de fundo claros e sombreados.
1. Em **Selecionar conteúdo visível**, faça o seguinte:
+ Ative ou desative colunas individuais para a exibição da lista e os relatórios.
+ Para alterar a ordem das colunas, clique e segure a alça de arrastar (![\[The drag handle\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) do nome de uma coluna e arraste-a para cima ou para baixo na lista.
1. Escolha **Confirmar**.
# Acesso a nós just-in-time usando o Systems Manager
O Systems Manager ajuda você a melhorar a segurança de seus nós oferecendo suporte ao acesso *just-in-time*. O acesso a nós just-in-time permite que os usuários solicitem acesso temporário e com limite de tempo aos nós, que você poderá aprovar somente quando o acesso for realmente necessário. Isso elimina a necessidade de fornecer acesso prolongado aos nós gerenciados pelas políticas do IAM. Além disso, o Systems Manager fornece gravação de sessões para sessões RDP em nós do Windows Server para ajudar você a atender aos requisitos de conformidade, realizar análises de causa raiz e muito mais. Para usar o acesso a nós just-in-time, você deve configurar o console unificado do Systems Manager.
Com o acesso a nós just-in-time, você cria políticas granulares do IAM para garantir que somente os usuários permitidos possam enviar solicitações de acesso aos seus nós. Em seguida, você cria *políticas de aprovação* que definem as aprovações necessárias para se conectar aos seus nós. Para o acesso a nós just-in-time, existem políticas de *aprovação automática* e de *aprovação manual*. Uma política de aprovação automática define a quais nós os usuários podem se conectar automaticamente. As políticas de aprovação manual definem o número e os níveis de aprovações manuais que devem ser fornecidas para acessar os nós que você especificar. Além disso, você pode criar uma política de *negação de acesso*. Uma política de negação de acesso impede explicitamente a aprovação automática de solicitações de acesso aos nós que você especificar. Uma política de negação de acesso se aplica a todas as contas em uma organização do AWS Organizations. As políticas de aprovação automática e manual se aplicam somente às Contas da AWS e às Regiões da AWS onde foram criadas.
Quando um usuário tenta se conectar a um nó, ele é solicitado a inserir um motivo para acessá-lo. Depois, suas políticas de aprovação são avaliadas. Dependendo de suas políticas, os usuários se conectam automaticamente ao nó de destino ou o Systems Manager cria automaticamente uma solicitação de aprovação manual em nome do solicitante. Os aprovadores especificados na política de aprovação manual que se aplica ao nó são então notificados da solicitação de acesso e podem aprovar ou negar a solicitação. Os aprovadores e solicitantes podem ser notificados por e-mail ou por meio do Amazon Q Developer na integração de aplicações de chat com o Slack ou o Microsoft Teams. O Systems Manager só concede acesso aos nós solicitados quando os aprovadores especificados fornecem todas as aprovações necessárias. Depois que todas as aprovações necessárias forem recebidas, o usuário poderá iniciar quantas sessões no nó forem necessárias durante a janela de acesso especificada na política de aprovação. O Systems Manager não encerra automaticamente as sessões de acesso a nós just-in-time. Como prática recomendada, especifique valores para as preferências de *duração máxima da sessão* e *tempo limite de sessão ociosa* da sessão. Essas preferências evitam que os usuários permaneçam conectados aos nós além da janela de acesso aprovada.
Recomendamos o uso de uma combinação de políticas de aprovação para ajudar você a proteger os nós com dados mais críticos e permitir que os usuários se conectem a nós menos críticos sem intervenção. Por exemplo, você pode exigir aprovações manuais para solicitações de acesso aos nós do banco de dados e aprovar automaticamente sessões para nós não persistentes da camada de apresentação.
O Systems Manager é compatível com o acesso a nós just-in-time para usuários federados com o Centro de Identidade do IAM ou o IAM. Quando um usuário federado envia uma solicitação de acesso, ele especifica o nó de destino e o motivo da necessidade de se conectar a ele. O Systems Manager compara a identidade do usuário com os parâmetros definidos nas políticas de aprovação da sua organização. Quando as condições da política de aprovação automática são atendidas, ou os aprovadores fornecem aprovações manualmente, o solicitante pode se conectar ao nó de destino. Quando um usuário tenta se conectar a um nó aprovado, o Systems Manager cria e usa um token temporário para estabelecer a sessão.
Como o serviço do Systems Manager gerencia a autenticação para solicitações de acesso e o estabelecimento de sessões, você não precisa usar políticas do IAM para gerenciar o acesso aos seus nós. Ao usar o acesso a nós just-in-time, o Systems Manager ajuda sua organização a ficar mais próxima de privilégios permanentes zero, já que você só precisa permitir que os usuários criem solicitações de acesso em vez de permitir que eles iniciem sessões com permissões prolongadas em seus nós. Para ajudar você a atender aos requisitos de conformidade, o Systems Manager retém todas as solicitações de acesso por um ano. O Systems Manager também emite eventos do EventBridge para acesso a nós just-in-time para solicitações de acesso com falha e atualizações de status para solicitações de acesso para aprovações manuais. Para obter mais informações, consulte, [Monitorar eventos do Systems Manager com o Amazon EventBridge](monitoring-eventbridge-events.md).
**Topics**
+ [Configurar o acesso just-in-time com o Systems Manager](systems-manager-just-in-time-node-access-setting-up.md)
+ [Iniciar uma sessão de acesso a nós just-in-time](systems-manager-just-in-time-node-access-start-session.md)
+ [Gerenciar solicitações de acesso just-in-time](systems-manager-just-in-time-node-access-manage-requests.md)
+ [Migrar para o acesso a nós just-in-time do Session Manager](systems-manager-just-in-time-node-access-moving-from-session-manager.md)
+ [Desabilitar o acesso just-in-time com o Systems Manager](systems-manager-just-in-time-node-access-disable.md)
+ [Perguntas frequentes sobre acesso a nós just-in-time](just-in-time-node-access-faq.md)
# Configurar o acesso just-in-time com o Systems Manager
A configuração do acesso a nós just-in-time com o Systems Manager envolve várias etapas. Primeiro, você escolhe os *destinos* em que deseja configurar o acesso a nós just-in-time. Os destinos consistem em unidades organizacionais (UOs) do AWS Organizations e Regiões da AWS. Por padrão, os mesmos destinos que você escolheu ao configurar o console unificado do Systems Manager são selecionados para acesso a nós just-in-time. Você pode optar por configurar o acesso a nós just-in-time para todos os mesmos destinos ou para um subconjunto dos destinos que você especificou ao configurar o console unificado do Systems Manager. Não há suporte para a adição de novos destinos que não foram selecionados quando você configurou o console unificado do Systems Manager.
Em seguida, você criará *políticas de aprovação* para determinar quando as conexões com os nós exigem aprovação manual e quando são aprovadas automaticamente. As políticas de aprovação são gerenciadas por cada conta em sua organização. Você também pode compartilhar uma política da conta do administrador delegado para negar explicitamente a aprovação automática de conexões com nós específicos.
**nota**
A configuração do acesso a nós just-in-time não afeta as preferências ou políticas existentes do IAM que você configurou para o Session Manager. Você deve remover a permissão para a ação de API do `StartSession` de suas políticas do IAM para garantir que somente o acesso a nós just-in-time seja usado quando os usuários tentarem se conectar aos nós. Depois de configurar o acesso a nós just-in-time, recomendamos testar suas políticas de aprovação com um subconjunto de usuários e nós para verificar se suas políticas estão funcionando conforme desejado, antes de remover as permissões para o Session Manager.
**Compatibilidade com autenticação**
Observe os seguintes detalhes sobre o suporte à autenticação usado para acesso a nós just-in-time:
+ O acesso a nós just-in-time não é compatível com o tipo de autenticação de login único ao se conectar a instâncias Windows Server com o Remote Desktop.
+ Há suporte somente a credenciais de segurança temporárias `AssumeRole` do AWS Security Token Service (AWS STS). Para obter mais informações, consulte os seguintes tópicos no *Guia do usuário do IAM*:
+
+ [Credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [Comparar credenciais do AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html)
+ [Solicitar credenciais de segurança temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)
As políticas do IAM a seguir descrevem as permissões necessárias para administrar e permitir que os usuários criem solicitações de acesso a nós just-in-time com o Systems Manager. Depois de verificar se você tem as permissões necessárias para usar o acesso a nós just-in-time com o Systems Manager, você pode continuar o processo de configuração. Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações.
## Política do IAM para habilitar o acesso a nós 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": "*"
}
]
}
```
------
## Política do IAM para configurar o acesso a nós just-in-time
------
#### [ 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": "*"
}
]
}
```
------
## Política do IAM para aprovadores de solicitações de acesso
------
#### [ 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": "*"
}
]
}
```
------
## Política do IAM para usuários de acesso a nós just-in-time
------
#### [ 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**
Para restringir o acesso às operações de API que criam, atualizam ou excluem políticas de aprovação, use a chave de condição `ssm:DocumentType` para os tipos de documento `AutoApprovalPolicy` e `ManualApprovalPolicy `. As operações de API `StartAccessRequest` e `GetAccessToken` não são compatíveis com as seguintes chaves de contexto globais:
`aws:SourceVpc`
`aws:SourceVpce`
`aws:VpcSourceIp`
`aws:UserAgent`
`aws:MultiFactorAuthPresent`
Para obter mais informações sobre chaves de contexto de condição para o Systems Manager, consulte [Condition keys for AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys) na *Referência de autorização do serviço*.
O procedimento a seguir descreve como concluir a primeira etapa de configuração para o acesso a nós just-in-time.
**Para configurar o acesso a nós just-in-time**
1. Faça login na conta de administrador delegado do Systems Manager da sua organização.
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Acesso ao nó Just-in-time** no painel de navegação.
1. Escolha **Habilitar nova experiência**.
1. Escolha as regiões em que você deseja habilitar o acesso a nós just-in-time. Por padrão, as mesmas regiões que você escolheu ao configurar o console unificado do Systems Manager são selecionadas para acesso a nós just-in-time. Não há suporte para a escolha de novas regiões que não foram selecionadas quando você configurou o console unificado do Systems Manager.
1. Selecione **Habilitar acesso a nós just-in-time**.
Não há cobrança para usar o acesso a nós just-in-time por 30 dias após a habilitação do recurso. Após o período de teste de 30 dias, há uma cobrança pelo uso do acesso a nós just-in-time. Para saber mais, consulte [Preços do AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
# Criar políticas de aprovação para os nós
As políticas de aprovação definem quais aprovações os usuários precisam ter para acessar um nó. Como o acesso a nós just-in-time elimina a necessidade de permissões prolongadas para os nós por meio de políticas do IAM, você deve criar políticas de aprovação para permitir o acesso aos nós. Se não houver políticas de aprovação que se apliquem a um nó, os usuários não poderão solicitar acesso ao nó.
No acesso a nós just-in-time, há três tipos de políticas. Os tipos de política são: *aprovação automática*, *negação de acesso* e *aprovação manual*.
**Tipos de política de acesso a nós just-in-time**
+ Uma política de aprovação automática define a quais nós os usuários podem se conectar automaticamente.
+ As políticas de aprovação manual definem o número e os níveis de aprovações manuais que devem ser fornecidas para acessar os nós que você especificar.
+ Uma política de negação de acesso impede explicitamente a aprovação automática de solicitações de acesso aos nós que você especificar.
Uma política de negação de acesso se aplica a todas as contas em uma organização do AWS Organizations. Por exemplo, você pode negar explicitamente as aprovações automáticas para o grupo `Intern` aos nós marcados com a chave `Production`. As políticas de aprovação automática e manual se aplicam somente às Contas da AWS e às Regiões da AWS onde foram criadas. Cada conta de membro em sua organização gerencia suas próprias políticas de aprovação. As políticas de aprovação são avaliadas na seguinte ordem:
1. Negar acesso
1. Aprovação automática
1. Manual
Embora você só possa ter uma política de negação de acesso por organização e uma política de aprovação automática por conta e região, você provavelmente terá várias políticas de aprovação manual em uma conta. Ao avaliar as políticas de aprovação manual, o acesso a nós just-in-time sempre favorece a política mais específica de um nó. As políticas de aprovação manual são avaliadas na seguinte ordem:
1. Tags específicas para destino
1. Todos os nós para destino
Por exemplo, você tem um nó marcado com a chave `Demo`. Na mesma conta, você tem uma política de aprovação manual que visa todos os nós e exige uma aprovação de um nível. Você também tem uma política de aprovação manual que exige duas aprovações de dois níveis para nós marcados com a chave `Demo`. O Systems Manager aplica a política que direciona a tag `Demo` ao nó, pois ela é mais específica do que a política que visa todos os nós. Isso permite que você crie uma política geral para todos os nós na sua conta, garantindo que os usuários possam enviar solicitações de acesso e, ao mesmo tempo, permitindo que você crie políticas mais granulares conforme necessário.
Dependendo da sua organização, pode haver várias tags aplicadas aos nós. Nesse cenário, se várias políticas de aprovação manual se aplicarem a um nó, as solicitações de acesso falharão. Por exemplo, um nó é marcado com as chaves `Production` e `Database`. Na mesma conta, você tem uma política de aprovação manual que se aplica aos nós marcados com a chave `Production` e outra política de aprovação manual que se aplica aos nós marcados com a chave `Database`. Isso resulta em um conflito para o nó marcado com ambas as chaves, e as solicitações de acesso falham. O Systems Manager redireciona o usuário para a solicitação que falhou. Lá, é possível ver os detalhes sobre as políticas e tags conflitantes para que o usuário possa fazer os ajustes necessários caso tenha as permissões necessárias. Do contrário, o usuário pode notificar um colega em sua organização com as permissões necessárias para modificar as políticas. Conflitos de políticas que resultam em falhas nas solicitações de acesso emitem eventos do EventBridge, permitindo flexibilidade na criação de seus próprios fluxos de trabalho de resposta. Além disso, o Systems Manager envia notificações por e-mail sobre conflitos de políticas que resultam em solicitações de acesso com falha para os destinatários que você especificar. Para obter mais informações sobre como configurar notificações por e-mail de conflitos de políticas, consulte [Configurar notificações para solicitações de acesso just-in-time](systems-manager-just-in-time-node-access-notifications.md).
Em uma política de *negação de acesso*, você usa a linguagem de política Cedar para definir a quais nós os usuários explicitamente não podem se conectar automaticamente em sua organização. Essa política é criada e compartilhada da conta do administrador delegado da sua organização. A política de negação de acesso substitui todas as políticas de aprovação automática. Você só pode ter uma política de negação de acesso por organização.
Em uma política de *aprovação automática*, você usa a linguagem de política Cedar para definir quais usuários podem se conectar automaticamente aos nós especificados sem aprovação manual. A duração do acesso para uma solicitação de acesso aprovada automaticamente é de uma hora. Esse valor não pode ser alterado. Você só pode ter uma política de aprovação automática por conta e região.
Em uma política de aprovação *manual*, você especifica a duração do acesso, quantos níveis de aprovações são necessários, o número de aprovadores necessários por nível e os nós para os quais eles podem aprovar solicitações de acesso just-in-time. A duração do acesso para uma política de aprovação manual deve estar entre 1 e 336 horas. Se você especificar vários níveis de aprovações, as aprovações para a solicitação de acesso processarão um nível por vez. Isso significa que todas as aprovações necessárias para um nível deverão ser fornecidas antes que o processo de aprovação passe para os níveis subsequentes. Se você especificar várias tags em uma política de aprovação manual, elas serão avaliadas como instruções `or`, não instruções `and`. Por exemplo, se você criar uma política de aprovação manual que inclua as tags `Application`, `Web` e `Test`, a política se aplicará a qualquer nó que esteja marcado com uma dessas chaves. A política não se aplica somente aos nós marcados com as três chaves.
Recomendamos usar uma combinação de políticas manuais com sua política de aprovação automática para ajudar você a proteger nós com dados mais críticos e, ao mesmo tempo, permitir que os usuários se conectem a nós menos críticos sem intervenção. Por exemplo, você pode exigir aprovações manuais para solicitações de acesso aos nós do banco de dados e aprovar automaticamente sessões para nós não persistentes da camada de apresentação.
Os procedimentos a seguir descrevem como criar políticas de aprovação para o acesso a nós just-in-time.
**Topics**
+ [Criar políticas de aprovação manual para acesso a nós just-in-time](systems-manager-just-in-time-node-access-create-manual-policies.md)
+ [Estrutura de instruções e operadores integrados para políticas de aprovação automática e negação de acesso](auto-approval-deny-access-policy-statement-structure.md)
+ [Criar uma política de aprovação automática para acesso a nós just-in-time](systems-manager-just-in-time-node-access-create-auto-approval-policies.md)
+ [Criar uma política de negação de acesso para acesso a nós just-in-time](systems-manager-just-in-time-node-access-create-deny-access-policies.md)
+ [Criar políticas de aprovação para acesso a nós just-in-time com o Amazon Q](systems-manager-just-in-time-node-access-create-approval-policies-q-ide-cli.md)
# Criar políticas de aprovação manual para acesso a nós just-in-time
O procedimento a seguir descreve como criar políticas de aprovação manual. O Systems Manager permite que você crie até 50 políticas de aprovação manual por Conta da AWS e Região da AWS.
**Para criar uma política de aprovação manual**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Gerenciar acesso a nós** no painel de navegação.
1. Na seção **Detalhes da política** da etapa **Criar política de aprovação manual**, insira um nome e uma descrição para a política de aprovação.
1. Insira um valor para a **Duração do acesso**. Este é o tempo máximo que um usuário pode iniciar sessões em um nó após a aprovação de uma solicitação de acesso. O valor deve ser entre 1 e 336 horas.
1. Na seção **Destinos do nó**, insira os pares de chave/valor da tag associados aos nós aos quais você deseja que a política se aplique. Se nenhuma das tags especificadas na política estiver associada a um nó, a política não será aplicada ao nó.
1. Na seção **Aprovadores de solicitações de acesso**, insira os usuários ou grupos que você deseja que possam aprovar solicitações de acesso aos destinos de nós na política. Os aprovadores de solicitações de acesso podem ser usuários e grupos do Centro de Identidade do IAM ou perfis do IAM. Você pode especificar até cinco aprovadores por nível e até cinco níveis de aprovadores.
1. Selecione **Criar política de aprovação manual**.
# Estrutura de instruções e operadores integrados para políticas de aprovação automática e negação de acesso
A tabela a seguir mostra a estrutura das políticas de aprovação automática e negação de acesso.
| Componente | Sintaxe |
| --- | --- |
| efeito; | `permit \| forbid` |
| scope | `(principal, action, resource)` |
| Cláusula de condição | when {
principal or resource has attribute name
}; |
## Componentes da política
Uma política de aprovação automática ou negação de acesso contém os seguintes componentes:
+ **Efeito**: permite (`permit`) ou nega (`forbid`) o acesso.
+ **Escopo**: a entidade principal, as ações e os recursos aos quais o efeito se aplica. Você pode deixar o escopo no Cedar indefinido ao não identificar entidades principais, ações ou recursos específicos. Nesse caso, a política se aplica a todos os principais, ações e recursos possíveis. Para acesso a nós just-in-time, o `action` é sempre `AWS::SSM::Action::"getTokenForInstanceAccess"`.
+ **Cláusula de condição**: o contexto no qual o efeito se aplica.
## Comentários
Você pode incluir comentários nas políticas do . Os comentários são definidos como uma linha que começa com `//` e termina com um caractere de nova linha.
O exemplo a seguir mostra comentários em uma política.
```
// 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"
};
```
## Cláusulas múltiplas
Você pode usar mais de uma cláusula de condição em uma declaração de política usando o operador `&&`.
```
// 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"
};
```
## Caracteres reservados
O exemplo a seguir mostra como escrever uma política se uma propriedade de contexto usar `:` (ponto e vírgula), que é um caractere reservado na linguagem da política.
```
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
}
```
Para obter exemplos adicionais, consulte [Exemplo de instruções de políticas](#policy-statement-examples).
## Esquema de acesso a nós just-in-time
Confira abaixo o esquema Cedar para acesso a nós just-in-time.
```
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
}
};
}
```
## Operadores integrados
Ao criar o contexto de uma política de aprovação automática ou negação de acesso usando várias condições, você pode usar o operador `&&` para adicionar outras condições. Há também muitos outros operadores integrados que você pode usar para adicionar mais poder expressivo às condições da sua política. A tabela a seguir contém todos os operadores integrados para referência.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/auto-approval-deny-access-policy-statement-structure.html)
## Exemplo de instruções de políticas
Confira abaixo exemplos de instruções de política.
```
// 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"
};
```
# Criar uma política de aprovação automática para acesso a nós just-in-time
As políticas de aprovação automática usam a linguagem de política Cedar para definir quais usuários podem se conectar automaticamente aos nós especificados sem aprovação manual. Uma política de aprovação automática contém várias declarações `permit` especificando a `principal` e o `resource`. Cada instrução inclui uma cláusula `when` que define as condições para a aprovação automática.
Confira abaixo um exemplo de política de aprovação automática.
```
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"
};
```
O procedimento a seguir descreve como criar uma política de aprovação automática para acesso a nós just-in-time. A duração do acesso para uma solicitação de acesso aprovada automaticamente é de uma hora. Esse valor não pode ser alterado. Você só pode ter uma política de aprovação automática por Conta da AWS e Região da AWS. Para obter informações sobre como criar instruções de política, consulte [Estrutura de instruções e operadores integrados para políticas de aprovação automática e negação de acesso](auto-approval-deny-access-policy-statement-structure.md).
**Para criar uma política de aprovação automática**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Gerenciar acesso a nós** no painel de navegação.
1. Na guia **Políticas de aprovação**, selecione **Criar uma política de aprovação automática**.
1. Insira sua instrução de política para a política de aprovação automática na seção **Instrução de política**. Você pode usar as **Instruções de exemplo** fornecidas para ajudar a criar sua política.
1. Selecione **Criar política de aprovação automática**.
# Criar uma política de negação de acesso para acesso a nós just-in-time
As políticas de negação de acesso usam a linguagem de política Cedar para definir a quais nós os usuários não podem se conectar automaticamente sem aprovação manual. Uma política de negação de acesso contém várias instruções `forbid` especificando a `principal` e o `resource`. Cada instrução inclui uma cláusula `when` que define as condições para negar explicitamente a aprovação automática.
Confira abaixo um exemplo de política de negação de acesso.
```
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"
};
```
O procedimento a seguir descreve como criar uma política de negação de acesso para acesso a nós just-in-time. Para obter informações sobre como criar instruções de política, consulte [Estrutura de instruções e operadores integrados para políticas de aprovação automática e negação de acesso](auto-approval-deny-access-policy-statement-structure.md).
**nota**
Observe as seguintes informações:
Você poderá criar políticas de negação de acesso enquanto estiver conectado à conta de gerenciamento da AWS ou à conta de administrador delegado. Sua organização do AWS Organizations pode ter apenas uma política de negação de acesso.
O acesso ao nó just-in-time faz uso do AWS Resource Access Manager (AWS RAM) para compartilhar sua política de negação de acesso com as contas de membros na sua organização. Se você quiser compartilhar sua política de negação de acesso com as contas de membros da sua organização, o compartilhamento de recursos deve ser habilitado na conta gerencial da sua organização. Para obter mais informações, consulte [Habilitar o compartilhamento de recursos no AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) no *Guia do usuário do AWS RAM*.
**Para criar uma política de negação de acesso**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Gerenciar acesso a nós** no painel de navegação.
1. Na guia **Políticas de aprovação**, selecione **Criar uma política de negação de acesso**.
1. Insira sua instrução de política para a política de negação de acesso na seção **Instrução de política**. Você pode usar as **Instruções de exemplo** fornecidas para ajudar a criar sua política.
1. Selecione **Criar política de negação de acesso**.
# Criar políticas de aprovação para acesso a nós just-in-time com o Amazon Q
O uso do Amazon Q Developer para a linha de comando fornece orientação e suporte em vários aspectos do desenvolvimento de software. Para acesso a nós just-in-time, o Amazon Q ajuda você a criar políticas de aprovação gerando e atualizando o código das políticas, analisando declarações de políticas e muito mais. As informações a seguir descrevem como criar políticas de aprovação usando o Amazon Q para a linha de comando.
## Identifique seu caso de uso
A primeira etapa na criação de políticas de aprovação é definir claramente o caso de uso. Por exemplo, na sua organização, talvez você queira aprovar automaticamente as solicitações de acesso a nós com uma tag `Environment:Testing`. Talvez você também queira negar explicitamente as aprovações automáticas aos nós com uma tag `Environment:Production` se o ID do funcionário começar com `TEMP`. Para nós com uma tag `Tier:Database`, talvez você queira exigir dois níveis de aprovações manuais.
Em qualquer cenário específico, você pode preferir uma política ou condição em vez de outra. Portanto, recomendamos que você defina claramente os comportamentos da política que deseja para determinar quais instruções melhor se adaptam ao seu caso de uso e preferências.
## Configuração do ambiente de desenvolvimento
Instale o Amazon Q para a linha de comando em que você deseja desenvolver suas políticas de aprovação. Para obter informações sobre a instalação do Amazon Q para a linha de comando, consulte [Installing Amazon Q for command line](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html) no *Guia do usuário do Amazon Q Developer*.
Também recomendamos instalar o servidor MCP da documentação da AWS. Esse servidor MCP conecta o Amazon Q da linha de comando aos recursos de documentação mais atuais. Para obter informações sobre o uso do MCP com o Amazon Q para a linha de comando, consulte [Using MCP with Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp.html) no *Guia do usuário do Amazon Q Developer*.
Para obter mais informações sobre o servidor MCP da documentação da AWS, consulte [AWS Documentation MCP Server](https://awslabs.github.io/mcp/servers/aws-documentation-mcp-server/).
Instale e configure a AWS CLI, caso ainda não tenha feito isso. Para obter informações, consulte [Instalar ou atualizar a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
## Desenvolver o conteúdo da política de aprovação
Com o caso de uso identificado e o ambiente configurado, você está pronto para desenvolver o conteúdo das políticas. Seu caso de uso e suas preferências ditarão em grande parte os tipos de políticas e declarações de aprovação que você usa.
Caso não tenha certeza de como usar uma política específica ou precise de mais informações sobre o esquema de uma política, consulte [Criar políticas de aprovação para os nós](systems-manager-just-in-time-node-access-approval-policies.md) e os tópicos subsequentes. Esses tópicos explicam em detalhes como as políticas são avaliadas e fornecem exemplos práticos de instruções.
O procedimento a seguir descreve como criar políticas de aprovação com o Amazon Q da linha de comando.
**nota**
O Amazon Q Developer usa IA generativa. Talvez seja necessário verificar as respostas. Consulte a [Política de uso responsável de IA da AWS](https://aws.amazon.com/ai/responsible-ai/policy/).
**Para criar políticas de aprovação usando o Amazon Q da linha de comando**
1. Abra seu terminal e inicie uma sessão com o Amazon Q.
```
$ q chat
```
1. Insira um prompt e descreva o tipo de instrução de política que você deseja criar. Por exemplo, usando o cenário anterior para uma política de aprovação, você pode inserir o seguinte 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. A inserção desse prompt de exemplo resultou na seguinte saída:
```
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. Cole a instrução de política em um novo arquivo Cedar para validar a sintaxe. Você também pode validar a instrução usando o [playground Cedar](https://www.cedarpolicy.com/en/playground).
1. Depois de validar a instrução, salve o arquivo Cedar.
1. No seu terminal, execute o comando da AWS CLI a seguir para criar um documento do SSM usando o conteúdo da sua política. Antes de usar políticas de aprovação em um ambiente de produção, teste suas políticas de aprovação com um subconjunto de identidades e nós em uma Conta da AWS e Região da AWS.
**nota**
Para uma política de aprovação automática, o nome do documento deve ser `SSM-JustInTimeAccessAutoApprovalPolicy`. Só pode haver uma política de aprovação automática por Conta da AWS e Região da AWS. Para uma política de negação de acesso, o nome do documento deve ser `SSM-JustInTimeAccessDenyAccessOrgPolicy`. Só pode haver uma política de negação de acesso por organização do AWS Organizations, e a política deve ser criada na conta de administrador delegado do Systems Manager. As restrições de nomenclatura das políticas de aprovação manual são as mesmas de outros documentos do SSM. Para obter mais informações, consulte [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"
```
------
# Atualizar as preferências da sessão de acesso a nós just-in-time
Com o acesso a nós just-in-time, você pode especificar as preferências gerais de sessão e registro em log em cada Conta da AWS e Região da AWS em sua organização. Como alternativa, você pode usar o CloudFormation StackSets para criar um documento de preferências de sessão em várias contas e regiões para ajudar você a ter preferências de sessão consistentes. Para obter informações sobre o esquema para documentos de preferências de sessão, consulte [Esquema do documento de sessão](session-manager-schema.md).
Para fins de registro em log, recomendamos usar a opção de streaming com o Amazon CloudWatch Logs. Esse recurso permite que você envie uma transmissão contínua de logs de dados de sessão ao Amazon CloudWatch Logs. Detalhes essenciais, como os comandos que um usuário executou em uma sessão, o ID do usuário que executou os comandos e carimbos de data/hora para quando os dados da sessão são transmitidos para o CloudWatch Logs, são incluídos ao transmitir dados da sessão. Ao transmitir dados de sessão, os logs são formatados em JSON para ajudar você a integrar com suas soluções de log existentes.
O Systems Manager não encerra automaticamente as sessões de acesso a nós just-in-time. Como prática recomendada, especifique os valores para as configurações de *duração máxima da sessão* e *tempo limite de sessão ociosa*. O uso dessas configurações ajuda a evitar que um usuário permaneça conectado a um nó por mais tempo do que a janela de tempo aprovada em uma solicitação de acesso. O procedimento a seguir descreve como atualizar as preferências de sessão para acesso a nós just-in-time.
**Importante**
É necessário marcar com tags as chaves do AWS KMS usadas para criptografia e gravação RDP no acesso a nós just-in-time no Session Manager com a chave de tag `SystemsManagerJustInTimeNodeAccessManaged` e o valor de tag `true`.
Para obter mais informações sobre tags de chaves do KMS, consulte [Tags no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) no *Guia do desenvolvedor do AWS Key Management Service*.
**Para atualizar as preferências da sessão**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Preferências da sessão**, selecione **Editar**.
1. Atualize suas preferências gerais e de registro em log conforme necessário e selecione **Salvar**.
# Configurar notificações para solicitações de acesso just-in-time
Você pode configurar o Systems Manager para enviar notificações quando um usuário criar uma solicitação de acesso a nós just-in-time para os endereços de e-mail ou cliente de chat dos aprovadores e do solicitante. A notificação contém o motivo da solicitação de acesso fornecido pelo solicitante, a Conta da AWS, a Região da AWS, o status da solicitação e o ID do nó de destino. Atualmente, o Systems Manager oferece suporte aos clientes do Slack e do Microsoft Teams por meio da integração com o Amazon Q Developer em aplicações de chat. Ao usar notificações por meio de clientes de chat, os aprovadores de solicitações de acesso podem interagir diretamente com as solicitações de acesso. Isso elimina a necessidade de fazer login no console para executar ações em relação às solicitações de acesso.
**Antes de começar**
Antes de configurar um cliente de chat para notificações de acesso a nós just-in-time, observe o seguinte requisito:
+ Caso esteja usando perfis do IAM para gerenciar identidades de usuários em sua conta, você deverá associar manualmente os endereços de e-mail dos aprovadores ou solicitantes aos quais deseja enviar notificações ao perfil associado. Caso contrário, os destinatários pretendidos não poderão ser notificados por e-mail.
Os procedimentos a seguir descrevem como configurar notificações para solicitações de acesso a nós just-in-time.
**Para configurar um cliente de chat para notificações de acesso a nós just-in-time**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Chat**, selecione **Configurar novo cliente**.
1. No menu suspenso **Selecionar tipo de cliente**, escolha o tipo de cliente de chat que você deseja configurar e selecione **Próximo**.
1. Você será solicitado a permitir que o Amazon Q Developer em aplicações de chat acesse seu cliente de chat. Selecione **Permitir**.
1. Na seção **Configurar canal**, insira as informações do canal do cliente de chat e selecione os tipos de notificações que você deseja receber.
1. Se você estiver configurando as notificações do Slack, convide "@Amazon Q" para cada canal do Slack em que as notificações estão sendo configuradas.
1. Selecione **Configurar canal**.
**nota**
Para permitir a aprovação/rejeição de solicitações de acesso diretamente de um canal do Slack, certifique-se de que o perfil do IAM configurado com o canal do Slack tenha permissões `ssm:SendAutomationSignal` e tenha uma política de confiança que inclua o chatbot:
```
{
"Effect": "Allow",
"Principal": {
"Service": "chatbot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
```
**Para configurar notificações por e-mail para notificações de acesso a nós just-in-time**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **E-mail**, selecione **Editar**.
1. Selecione **Adicionar e-mails**, escolha o **perfil do IAM** ao qual você deseja associar manualmente os endereços de e-mail.
1. No campo **Endereço de e-mail**, insira um endereço de e-mail. Sempre que uma solicitação de acesso é criada e exige aprovação do perfil do IAM que você especificou, os endereços de e-mail que você associou ao perfil são notificados.
1. Selecione **Adicionar endereço de e-mail**.
# Gravar conexões RDP
O acesso a nós just-in-time inclui a capacidade de gravar conexões RDP realizadas com seus nós do Windows Server. A gravação de conexões RDP requer um bucket do S3 e uma chave do AWS Key Management Service (AWS KMS) gerenciada pelo cliente. A AWS KMS key é usada para criptografar temporariamente os dados de gravação enquanto são gerados e armazenados nos recursos do Systems Manager. A chave gerenciada pelo cliente deve ser uma chave simétrica com o uso da chave de criptografia e descriptografia. Você pode usar uma chave multirregional para sua organização, ou você deve criar uma chave gerenciada pelo cliente em cada região onde você habilitou o acesso a nós just-in-time.
Se você habilitou a criptografia do KMS no bucket do S3 no qual armazena gravações, será necessário fornecer acesso à chave gerenciada pelo cliente utilizada para a criptografia de buckets à entidade principal de serviço `ssm-guiconnect`. Essa chave gerenciada pelo cliente pode ser diferente da especificada nas configurações de gravação, que precisa incluir a permissão `kms:CreateGrant` que é necessária para o estabelecimento de conexões.
## Configurar a criptografia de buckets do S3 para gravações de RDP
Suas gravações de conexão são armazenadas no bucket do S3 especificado ao habilitar a gravação de RDP.
Se você utilizar uma chave do KMS como mecanismo de criptografia padrão para o bucket do S3 (SSE-KMS), deverá permitir que a entidade principal de serviço `ssm-guiconnect` acesse a ação `kms:GenerateDataKey` nessa chave. Recomendamos o uso de uma chave gerenciada pelo cliente ao usar a criptografia SSE-KMS com um bucket do S3. Isso porque é possível atualizar a política de chave associada de uma chave gerenciada pelo cliente. Não é possível atualizar as políticas de chave para Chaves gerenciadas pela AWS.
**Importante**
É necessário marcar com tags as chaves do AWS KMS usadas para criptografia e gravação RDP no acesso a nós just-in-time no Session Manager com a chave de tag `SystemsManagerJustInTimeNodeAccessManaged` e o valor de tag `true`.
Para obter mais informações sobre tags de chaves do KMS, consulte [Tags no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) no *Guia do desenvolvedor do AWS Key Management Service*.
Use a política de chave gerenciada pelo cliente a seguir para permitir que o serviço `ssm-guiconnect` acesse a chave do KMS para armazenamento no S3. Para obter informações sobre como modificar uma chave gerenciada pelo cliente, consulte [Alterar uma política de chave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) no *Guia do desenvolvedor do AWS Key Management Service*.
Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações:
+ *account-id* representa o ID da Conta da AWS que inicia a conexão.
+ *region* representa a Região da AWS em que o bucket do S3 está localizado. (Você poderá usar `*` se o bucket for receber gravações de várias regiões. Exemplo: `s3.*.amazonaws.com`).
**nota**
Você poderá usar `aws:SourceOrgID` na política em vez de `aws:SourceAccount` se a conta pertencer a uma organização no 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"
}
}
}
```
## Configurar permissões do IAM para gravar conexões RDP
Além das permissões do IAM necessárias para o acesso a nós just-in-time, o usuário ou perfil que você utilizar deverá ter as permissões a seguir com base na tarefa que você precisará realizar.
**Permissões para configurar a gravação de conexão**
Para configurar o registro de conexões RDP, as seguintes permissões são necessárias:
+ `ssm-guiconnect:UpdateConnectionRecordingPreferences`
+ `ssm-guiconnect:GetConnectionRecordingPreferences`
+ `ssm-guiconnect:DeleteConnectionRecordingPreferences`
+ `kms:CreateGrant`
**Permissões para iniciar conexões**
Para fazer conexões RDP com o acesso a nós just-in-time, as seguintes permissões são necessárias:
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
+ `kms:CreateGrant`
**Antes de começar**
Para armazenar as gravações de conexão, primeiro você deve criar um bucket do S3 e adicionar política de bucket a seguir. Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações.
(Para obter mais informações sobre como adicionar uma política de bucket, consulte [Adicionar uma política de bucket usando o console do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) no *Guia do usuário do 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"
}
}
}
]
}
```
------
## Habilitar e configurar a gravação de conexões RDP
O procedimento a seguir descreve como habilitar e configurar o registro de conexões RDP.
**Para habilitar e configurar a gravação de conexões RDP**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Gravação RDP**, selecione **Habilitar gravação RDP**.
1. Escolha o bucket do S3 no qual você deseja fazer upload das gravações da sessão.
1. Escolha a chave gerenciada pelo cliente que você deseja usar para criptografar temporariamente os dados de gravação enquanto eles são gerados e armazenados nos recursos do Systems Manager. (Pode ser uma chave gerenciada pelo cliente diferente da que você utiliza para criptografar o bucket.)
1. Selecione **Salvar**.
## Valores de status de gravação de conexões RDP
Os valores de status válidos para gravações de conexões RDP incluem o seguinte:
+ `Recording`: a conexão está em processo de ser gravada
+ `Processing`: o vídeo está sendo processado após o encerramento da conexão.
+ `Finished`: estado de terminal com êxito: o vídeo de gravação da conexão foi processado com êxito e carregado no bucket especificado.
+ `Failed`: estado de terminal com falha. A conexão não foi gravada com êxito.
+ `ProcessingError`: uma ou mais falhas/erros intermediários ocorreram durante o processamento do vídeo. Possíveis causas incluem falhas na dependência de serviços ou permissões ausentes em decorrência de uma configuração incorreta no bucket do S3 especificado para o armazenamento de gravações. O serviço continua a fazer tentativasd de processamento quando a gravação se encontra nesse estado.
**nota**
`ProcessingError` pode ocorrer porque a entidade principal de serviço `ssm-guiconnect` não tem permissão para fazer upload de objetos no bucket do S3 depois que a conexão é estabelecida. Outra causa possível é a ausência de permissões do KMS na chave do KMS utilizada para a criptografia do bucket do S3.
# Modificar destinos
Ao configurar o acesso a nós just-in-time, você escolhe os *destinos* em que deseja configurar o acesso a nós just-in-time. Os destinos consistem em unidades organizacionais (UOs) do AWS Organizations e Regiões da AWS. Por padrão, os mesmos destinos que você escolheu ao configurar o console unificado do Systems Manager são selecionados para acesso a nós just-in-time. Você pode optar por configurar o acesso a nós just-in-time para todos os mesmos destinos ou para um subconjunto dos destinos que você especificou ao configurar o console unificado do Systems Manager. Não há suporte para a adição de novos destinos que não foram selecionados quando você configurou o console unificado do Systems Manager. Você pode alterar os destinos selecionados após configurar o acesso a nós just-in-time.
O procedimento a seguir descreve como modificar os destinos para acesso a nós just-in-time.
**Para modificar destinos**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Destinos**, selecione **Editar**.
1. Selecione as **Unidades organizacionais** e as **Regiões** em que você deseja usar o acesso a nós just-in-time.
1. Selecione **Salvar**.
# Alterar provedores de identidade
Por padrão, o acesso a nós just-in-time usa o IAM como provedor de identidade. Depois de habilitar o acesso a nós just-in-time, os clientes que usam o console unificado com uma organização podem modificar essa configuração para usar o Centro de Identidade do IAM. O acesso a nós just-in-time não é compatível com o Centro de Identidade do IAM como provedor de identidade quando configurado para uma única conta e região.
O procedimento a seguir descreve como modificar o provedor de identidade para acesso a nós just-in-time.
**Para modificar provedores de identidade**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Selecione a guia **Acesso a nós just-in-time**.
1. Na seção **Identidade do usuário**, selecione **Editar**.
1. Escolha **Habilitar o Centro de Identidade do AWS IAM**.
1. Selecione **Salvar**.
# Iniciar uma sessão de acesso a nós just-in-time
Depois de habilitar e definir o acesso a nós just-in-time e configurar as preferências de sessão e notificação, os usuários estarão prontos para iniciar as sessões de acesso a nós just-in-time. Você pode iniciar sessões usando o acesso a nós just-in-time no console do Systems Manager ou da AWS Command Line Interface usando o plug-in do Session Manager. As sessões de acesso a nós just-in-time podem ser iniciadas em nós na mesma conta e região. Os procedimentos a seguir descrevem como iniciar sessões com acesso a nós just-in-time.
**nota**
Se os seus usuários usavam anteriormente o Session Manager para se conectar aos nós, você deve remover as permissões do Session Manager, por exemplo `ssm:StartSession`, das políticas do IAM para iniciar sessões usando o acesso a nós just-in-time. Do contrário, ao se conectar aos nós, eles continuarão a usar o Session Manager.
**Para iniciar uma sessão com acesso a nós just-in-time usando o console**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, selecione **Explorar nós**.
1. Selecione o nó ao qual deseja se conectar.
1. No menu suspenso **Ações**, selecione **Conectar**.
Se as políticas de aprovação da sua organização não permitirem que você se conecte automaticamente ao nó, você será solicitado a enviar uma solicitação de acesso. Depois de preencher as informações solicitadas e enviar a solicitação de acesso, você poderá iniciar as sessões no nó assim que todas as aprovações necessárias forem recebidas.
**Para iniciar uma sessão com acesso a nós just-in-time usando a AWS CLI**
1. Execute o comando a seguir para iniciar o fluxo de trabalho da solicitação de acesso, certificando-se de substituir os *valores de espaço reservado* por suas próprias informações.
```
aws ssm start-access-request \
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE
--reason "Troubleshooting networking performance issue"
```
Dependendo das políticas de aprovação da sua organização, você será conectado automaticamente ao nó ou o processo de aprovação manual será iniciado. Para solicitações que exigem aprovações manuais, anote o ID da solicitação de acesso que é retornado na resposta.
1. Aguarde até que todas as aprovações necessárias sejam fornecidas.
1. Depois que todas as aprovações necessárias tiverem sido fornecidas, execute o comando a seguir para obter um token de acesso contendo credenciais temporárias. Substitua os *valores de espaço reservado* por suas próprias informações.
```
aws ssm get-access-token \
--access-request-id oi-12345abcdef
```
Anote o token de acesso retornado na resposta.
1. Execute o comando a seguir para usar a credencial temporária na AWS CLI, certificando-se de substituir os *valores de espaço reservado* por suas próprias informações.
```
export AWS_SESSION_TOKEN=AQoDYXdzEJr...
```
1. Execute o comando a seguir para iniciar uma sessão no nó, certificando-se de substituir os *valores de espaço reservado* por suas próprias informações.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
# Gerenciar solicitações de acesso just-in-time
Para maior visibilidade em toda a organização, o Systems Manager replica as solicitações de acesso para a conta de administrador delegado da sua organização. Para ajudar você a atender aos requisitos de conformidade, o Systems Manager retém todas as solicitações de acesso por um ano. Os tópicos a seguir descrevem como gerenciar solicitações de acesso a nós just-in-time. Essas informações destinam-se aos aprovadores de solicitações de acesso. Antes de começar, recomendamos revisar suas políticas do IAM e garantir que você tenha as permissões necessárias para administrar o acesso a nós just-in-time. Para obter mais informações, consulte, [Configurar o acesso just-in-time com o Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
**Topics**
+ [Aprovar e negar solicitações de acesso a nós just-in-time](systems-manager-just-in-time-node-access-approve-deny-requests.md)
# Aprovar e negar solicitações de acesso a nós just-in-time
Os aprovadores de solicitações de acesso podem aprovar ou negar solicitações de acesso a nós just-in-time no console unificado do Systems Manager, ou podem usar a ferramenta de linha de comando preferencial. Essas informações destinam-se aos aprovadores de solicitações de acesso. Caso não tenha as permissões necessárias para aprovar ou rejeitar solicitações de acesso, entre em contato com o administrador. Os procedimentos a seguir descrevem como aprovar ou negar solicitações de acesso a nós just-in-time.
**Para aprovar ou negar solicitações de acesso a nós just-in-time usando o console**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Gerenciar acesso a nós** no painel de navegação.
1. Selecione a guia **Solicitações de acesso**.
1. Selecione a alternância **Solicitações para mim**.
1. Marque a caixa de seleção ao lado da solicitação de acesso que deseja aprovar ou negar.
1. Selecione **Aprovar** ou **Rejeitar**.
Depois de aprovar uma solicitação de acesso, você pode revogar sua aprovação a qualquer momento selecionando **Revogar**.
**Para aprovar ou negar solicitações de acesso a nós just-in-time usando o console**
1. Anote o ID da solicitação de acesso da notificação. Por exemplo, *oi-12345abcdef*.
1. Execute o comando a seguir para retornar detalhes sobre o fluxo de trabalho de aprovação da solicitação de acesso, certificando-se de substituir os *valores do espaço reservado* por suas próprias informações.
```
aws ssm get-ops-item \
--ops-item-id oi-12345abcdef
```
Observe o valor `automationExecutionId` no campo `/aws/accessrequest` para `OperationalData`. Por exemplo, *9231944f-61c6-40be-8bce-8ee2bEXAMPLE*.
1. Execute o comando a seguir para aprovar ou negar a solicitação de acesso. Use o tipo de sinal `Approve` para aprovar a solicitação e `Deny` para negar a solicitação. Certifique-se de substituir os *valores do espaço reservado* por suas próprias informações.
```
aws ssm send-automation-signal \
--automation-execution-id 9231944f-61c6-40be-8bce-8ee2bEXAMPLE \
--signal-type "Approve"
```
# Migrar para o acesso a nós just-in-time do Session Manager
Quando você habilita o acesso a nós just-in-time, o Systems Manager não faz nenhuma alteração em seus recursos existentes do Session Manager. Isso garante que não haja interrupções em seu ambiente atual e que os usuários possam continuar iniciando sessões enquanto você cria e valida políticas de aprovação. Quando tudo estiver pronto para você testar as políticas de aprovação, você deve modificar as políticas existentes do IAM para concluir a transição para o acesso a nós just-in-time. Isso inclui adicionar as permissões necessárias para o acesso a nós just-in-time às identidades e remover a permissão da operação da API `StartSession` do Session Manager. Recomendamos testar as políticas de aprovação com um subconjunto de identidades e nós em uma Conta da AWS e Região da AWS.
Para obter mais informações sobre as permissões necessárias para o acesso a nós just-in-time, consulte [Configurar o acesso just-in-time com o Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
Para obter mais informações sobre como modificar e as permissões do IAM da identidade, consulte [Adicionar e remover permissões de identidade do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) no *Guia do usuário do IAM*.
A seguir, descrevemos um método detalhado de como você pode migrar para o acesso a nós just-in-time do Session Manager.
Migrar do Session Manager para o acesso a nós just-in-time exige planejamento e testes cuidadosos para garantir uma transição tranquila sem interromper suas operações. As seções a seguir descrevem como você pode concluir esse processo.
## Pré-requisitos
Antes de começar, certifique-se de ter concluído as seguintes tarefas:
+ Configure o console unificado do Systems Manager.
+ Verifique se você tem permissões para modificar as políticas do IAM em sua conta.
+ Identificou todas as políticas e perfis do IAM que atualmente concedem permissões do Session Manager.
+ Documentou sua configuração atual do Session Manager, incluindo preferências de sessão e configurações de registros em log.
## Avaliação
Avalie seu ambiente atual e descreva os comportamentos de aprovação desejados concluindo as seguintes tarefas:
1. **Faça o inventário de seus nós**: identifique todos os nós que os usuários acessam atualmente por meio do Session Manager.
1. **Identifique padrões de acesso do usuário**: documente quais usuários ou perfis precisam acessar quais nós e sob quais circunstâncias.
1. **Mapeie fluxos de trabalho de aprovação**: determine quem deve aprovar solicitações de acesso para diferentes tipos de nós.
1. **Revise a estratégia de marcação**: garanta que seus nós estejam devidamente marcados para apoiar suas políticas de aprovação planejadas.
1. **Audite as políticas existentes do IAM**: identifique todas as políticas que incluem permissões do Session Manager.
## Planejamento
### Estratégia em fases
Ao migrar do Session Manager para o acesso a nós just-in-time, recomendamos usar uma abordagem em fases, como a seguinte:
1. **Fase 1: configuração**: habilite o acesso a nós just-in-time sem modificar as permissões existentes do Session Manager.
1. **Fase 2: desenvolvimento de políticas**: crie e teste políticas de aprovação para seus nós.
1. **Fase 3: migração piloto**: modifique um pequeno grupo de nós não críticos e usuários ou perfis do Session Manager para o acesso a nós just-in-time.
1. **Fase 4: migração completa**: migre gradualmente todos os nós, usuários ou perfis restantes.
### Considerações sobre o cronograma
Considere os seguintes fatores ao criar seu cronograma para migrar do Session Manager para o acesso a nós just-in-time:
+ Reserve um tempo para o treinamento do usuário e a adaptação ao novo fluxo de trabalho de aprovação.
+ Agende as migrações durante períodos de menor atividade operacional.
+ Inclua tempo de buffer para a solução de problemas e ajustes.
+ Planeje um período de operação paralela em que ambos os sistemas estejam disponíveis.
## Etapas de implementação
### Fase 1: configuração
1. Habilite o acesso a nós just-in-time no console do Systems Manager. Para saber detalhes das etapas, consulte [Configurar o acesso just-in-time com o Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
1. Configure as preferências da sessão para acesso a nós just-in-time de acordo com suas configurações atuais do Session Manager. Para obter mais informações, consulte [Atualizar as preferências da sessão de acesso a nós just-in-time](systems-manager-just-in-time-node-access-session-preferences.md).
1. Configure as preferências de notificação das solicitações de acesso. Para obter mais informações, consulte [Configurar notificações para solicitações de acesso just-in-time](systems-manager-just-in-time-node-access-notifications.md).
1. Se você usar conexões RDP para nós do Windows Server, configure a gravação RDP. Para obter mais informações, consulte [Gravar conexões RDP](systems-manager-just-in-time-node-access-rdp-recording.md).
### Fase 2: desenvolvimento de políticas
1. Crie políticas do IAM para administradores e usuários de acesso a nós just-in-time.
1. Desenvolva políticas de aprovação com base nos seus requisitos de segurança e no seu caso de uso.
1. Teste suas políticas em um ambiente de não produção para garantir que funcionem conforme o esperado.
### Fase 3: migração piloto
1. Selecione um pequeno grupo de usuários e nós não críticos para o piloto.
1. Crie novas políticas do IAM para usuários piloto que incluam permissões de acesso a nós just-in-time.
1. Remova as permissões do Session Manager (`ssm:StartSession`) das políticas do IAM dos usuários piloto.
1. Treine os usuários piloto no novo fluxo de trabalho de solicitação de acesso.
1. Monitore o piloto em busca de problemas e colete feedback.
1. Ajuste as políticas e procedimentos com base nos resultados do piloto.
**Exemplo de modificação da política do IAM para usuários piloto**
Política original com permissões do Session Manager:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
Política modificada para acesso a nós just-in-time:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
### Fase 4: migração completa
Desenvolva um cronograma para migrar os usuários e nós restantes em lotes.
## Metodologia de testes
Durante todo o processo de migração, realize os seguintes testes:
+ **Validação da política**: verifique se as políticas de aprovação se aplicam corretamente aos nós e usuários pretendidos.
+ **Fluxo de trabalho da solicitação de acesso**: teste o fluxo de trabalho completo, desde a solicitação de acesso até o estabelecimento da sessão, para cenários de aprovação automática e aprovação manual.
+ **Notificações**: verifique se os aprovadores recebem notificações pelos canais configurados (e-mail, Slack, Microsoft Teams).
+ **Registro em log e monitoramento**: verifique se os logs da sessão e as solicitações de acesso são capturados e armazenados adequadamente.
## Práticas recomendadas para uma migração com êxito
+ **Comunique com antecedência e frequência**: informe os usuários sobre o cronograma de migração e os benefícios do acesso a nós just-in-time.
+ **Comece com sistemas não críticos**: inicie a migração com ambientes de desenvolvimento ou de testes antes de passar para o de produção.
+ **Documente tudo**: mantenha registros detalhados de suas políticas de aprovação, alterações na política do IAM e definições de configuração.
+ **Monitore e ajuste**: monitore continuamente as solicitações de acesso e os fluxos de trabalho de aprovação, ajustando as políticas conforme necessário.
+ **Estabeleça a governança**: crie um processo para revisar e atualizar regularmente as políticas de aprovação à medida que seu ambiente muda.
# Desabilitar o acesso just-in-time com o Systems Manager
O procedimento a seguir descreve como desabilitar o acesso a nós just-in-time. Depois de desabilitar o acesso a nós just-in-time, os usuários da sua organização talvez não consigam se conectar aos seus nós, a menos que você já tenha implementado outros métodos de conexão.
**Para desabilitar o acesso a nós just-in-time**
1. Faça login na conta de administrador delegado do Systems Manager da sua organização.
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Selecione **Configurações** no painel de navegação.
1. Na guia **Acesso a nós just-in-time**, selecione **Desabilitar**.
# Perguntas frequentes sobre acesso a nós just-in-time
## Como faço para migrar do Session Manager para o acesso a nós just-in-time?
Depois de configurar o console unificado e habilitar o acesso a nós just-in-time, você deve modificar as políticas existentes do IAM para concluir a migração para o acesso a nós just-in-time. Isso inclui adicionar as permissões necessárias para o acesso a nós just-in-time e remover a permissão para a operação da API `StartSession` do Session Manager. Para obter mais informações sobre as políticas do IAM para acesso a nós just-in-time, consulte [Configurar o acesso just-in-time com o Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
## Preciso configurar o console unificado para usar o acesso a nós just-in-time?
Sim, configurar o console unificado é um pré-requisito para o acesso a nós just-in-time. No entanto, depois de configurar o console unificado e habilitar o acesso a nós just-in-time, há vários métodos para se conectar aos seus nós. Por exemplo, você pode iniciar sessões de acesso a nós just-in-time no console do Amazon EC2 e na AWS CLI. Para obter mais informações sobre a configuração do console unificado, consulte [Configurar o console unificado do Systems Manager para uma organização](systems-manager-setting-up-organizations.md).
## Há algum custo associado ao acesso a nós just-in-time?
O Systems Manager oferece um teste gratuito de 30 dias para o acesso a nós just-in-time. Após o teste, o acesso a nós just-in-time gera custos. Para saber mais, consulte [Preços do AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Qual é a precedência das políticas de aprovação do acesso a nós just-in-time?
As políticas de aprovação são avaliadas na seguinte ordem:
1. Negar acesso
1. Aprovação automática
1. Manual
## Como as políticas de aprovação manual são avaliadas?
O acesso a nós just-in-time sempre favorece a política mais específica para um nó. As políticas de aprovação manual são avaliadas na seguinte ordem:
1. Tags específicas para destino
1. Todos os nós para destino
## O que acontecerá se não houver uma política de aprovação que se aplique a um nó?
Para se conectar a um nó usando o acesso a nós just-in-time, uma política de aprovação deve ser aplicada ao nó. Se não houver políticas de aprovação que se apliquem a um nó, os usuários não poderão solicitar acesso ao nó.
## Várias políticas de aprovação podem ter como destino uma tag?
Uma tag só pode ser de destino uma vez em suas políticas de aprovação.
## O que acontecerá se várias políticas de aprovação manual se aplicarem a um nó como resultado da sobreposição de tags?
Quando várias políticas de aprovação manual se aplicam a um nó, isso resulta em um conflito, e os usuários não conseguem solicitar acesso ao nó. Lembre-se disso ao criar suas políticas de aprovação manual, pois algumas instâncias podem ter várias tags, dependendo do seu caso.
## Posso usar o acesso a nós just-in-time para solicitar acesso e iniciar sessões em nós em todas as contas e regiões?
O acesso a nós just-in-time oferece suporte à solicitação de acesso e ao início de sessões em nós na mesma conta e região do solicitante.
## Posso usar o acesso a nós just-in-time para solicitar acesso e iniciar sessões em nós registrados com uma ativação híbrida?
Sim, o acesso a nós just-in-time oferece suporte à solicitação de acesso e ao início de sessões em nós registrados com uma ativação híbrida. O nó precisa estar registrado na mesma conta e região que o solicitante.
# Diagnosticar e remediar
Usando o console unificado do Systems Manager, é possível identificar problemas em toda a sua frota em uma única operação de diagnóstico. Para organizações, você pode então tentar remediar todos os alvos ou apenas selecionar alvos usando uma única operação do Automation. Para uma organização, na condição de administrador de conta delegado, você pode selecionar alvos em todas as contas e regiões. Se você estiver trabalhando em uma única conta, poderá selecionar alvos em uma única região por vez.
O Systems Manager pode diagnosticar e ajudar você a corrigir vários tipos de falhas de implantação, bem como configurações desviadas. O Systems Manager também pode identificar instâncias do Amazon Elastic Compute Cloud (Amazon EC2) em sua conta ou organização que o Systems Manager não pode tratar como um *nó gerenciado*. O processo de diagnóstico de instâncias do EC2 pode identificar problemas relacionados a configurações incorretas em uma nuvem privada virtual (VPC), em uma configuração do Domain Name Service (DNS) ou em um grupo de segurança do Amazon Elastic Compute Cloud (Amazon EC2).
**nota**
O Systems Manager oferece suporte a instâncias do EC2 e outros tipos de máquinas em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types) como *nós gerenciados*. Para ser um nó gerenciado, o AWS Systems Manager Agent (SSM Agent) deve estar instalado na máquina e o Systems Manager deve ter permissão para realizar ações na máquina.
Para instâncias do EC2, essa permissão pode ser fornecida no nível da conta usando um perfil do AWS Identity and Access Management (IAM) ou no nível da instância usando um perfil de instância. Para ter mais informações, consulte [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md).
Para máquinas não EC2, essa permissão é fornecida usando um perfil de serviço do IAM. Para ter mais informações, consulte [Criar o perfil de serviço do IAM obrigatório para o Systems Manager em ambientes híbridos e multinuvem](hybrid-multicloud-service-role.md).
**Antes de começar**
Para usar o recurso **Diagnosticar e corrigir** para detectar instâncias do EC2 não gerenciadas, primeiro é necessário integrar sua organização ou conta ao console unificado do Systems Manager. Durante esse processo, você deve escolher a opção de criar os perfis do IAM e as políticas gerenciadas necessárias para essas operações. Para ter mais informações, consulte [Configurar o console unificado do Systems Manager para uma organização](systems-manager-setting-up-organizations.md).
Use os tópicos a seguir para obter ajuda para identificar e corrigir certos tipos comuns de implantações com falha, configurações derivadas e instâncias do EC2 não gerenciadas.
**Topics**
+ [Diagnosticar e corrigir implantações com falha](remediating-deployment-issues.md)
+ [Diagnosticar e revisar configurações com desvios](remediating-configuration-drift.md)
+ [Diagnosticar e corrigir instâncias não gerenciadas do Amazon EC2 no Systems Manager](remediating-unmanaged-instances.md)
+ [Tipos de impacto de remediação de ações do runbook](remediation-impact-type.md)
+ [Verificar o progresso da execução e o histórico de correções no Systems Manager](diagnose-and-remediate-execution-history.md)
# Diagnosticar e corrigir implantações com falha
O Systems Manager pode diagnosticar e ajudar a corrigir os seguintes tipos de implantações com falha:
+ Configuração básica para contas-membro da organização
+ Configuração básica para conta de administrador delegado
+ Configuração básica para sua conta
Use o procedimento a seguir para tentar corrigir esses tipos de problemas.
**Para diagnosticar e corrigir implantações com falha**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Diagnosticar e corrigir**.
1. Escolha a guia **Problemas de implantação**.
1. Na seção **Implantações com falha**, revise a lista de descobertas de implantações que falharam.
1. Na coluna **Etapa de configuração**, escolha o nome de uma descoberta para revisar detalhes adicionais sobre o problema. Por exemplo: **Configuração básica para contas-membro da organização**.
1. Na página de detalhes dessa implantação com falha, é possível visualizar uma lista de contas e quantas regiões em cada uma sofreram falhas de implantação.
1. Selecione um ID de conta para visualizar informações sobre o motivo das falhas nessa conta.
1. Na área **Regiões com falha**, examine as informações fornecidas pelo **Motivo do status**. Essas informações podem indicar o motivo da falha na implantação, o que pode fornecer informações sobre as alterações de configuração que precisam ser feitas.
1. Se desejar repetir a implantação sem fazer alterações na configuração, escolha **Reimplantar**.
# Diagnosticar e revisar configurações com desvios
O Systems Manager pode diagnosticar e, em seguida, ajudar a corrigir os seguintes tipos de configurações com desvios:
+ Configuração básica para contas-membro da organização
+ Configuração básica para conta de administrador delegado
+ Configuração básica para sua conta
Use o procedimento a seguir para tentar corrigir esses tipos de configurações com desvios.
**Para diagnosticar e revisar configurações com desvios**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Diagnosticar e corrigir**.
1. Escolha a guia **Problemas de implantação**.
1. Na seção **Implantações com desvios**, revise a lista de descobertas de implantações que falharam.
- ou -
Para executar um novo diagnóstico, escolha **Detectar desvio**.
1. Na coluna **Etapa de configuração**, escolha o nome de uma descoberta para revisar detalhes adicionais sobre o problema. Por exemplo: **Configuração básica para contas-membro da organização**.
1. Na página de detalhes dessa implantação malsucedida, você pode visualizar uma lista de contas e quantas regiões em cada uma sofreram alterações na configuração.
1. Selecione um ID de conta para visualizar informações sobre o motivo dos desvios de configuração nessa conta.
1. Na área **Recursos com desvio**, a coluna **Recursos** relata os nomes dos recursos que sofreram desvios. A coluna **Tipo de desvio** informa se o recurso foi modificado ou excluído.
1. Para reimplantar a configuração pretendida, escolha **Reimplantar**.
# Diagnosticar e corrigir instâncias não gerenciadas do Amazon EC2 no Systems Manager
Para ajudar a gerenciar suas instâncias do Amazon Elastic Compute Cloud (Amazon EC2) com o Systems Manager, você pode usar o console unificado do Systems Manager para fazer o seguinte:
1. Executar um processo de diagnóstico manual ou programado para identificar as instâncias do EC2 em sua conta ou organização que não são gerenciadas pelo Systems Manager no momento.
1. Identificar a rede ou outros problemas que estão impedindo o Systems Manager de assumir o gerenciamento das instâncias.
1. Executar uma execução do Automation para corrigir automaticamente o problema ou acessar informações que podem ajudar a resolver o problema manualmente.
Use as informações nos tópicos a seguir para ajudar no diagnóstico e na correção de problemas que impedem o Systems Manager de gerenciar as instâncias do EC2.
## Como o Systems Manager conta os nós afetados para a lista "Problemas de instâncias do EC2 não gerenciadas"
O número de nós relatados como não gerenciados na guia **Problemas de instâncias do EC2 não gerenciadas** representa o número total de instâncias com qualquer um dos seguintes valores de status no momento da verificação do diagnóstico:
+ `Running`
+ `Stopped`
+ `Stopping`
Esse número é relatado como **Nós afetados** na área **Resumo do problema**. Na imagem a seguir, esse número de nós afetados não gerenciados no momento pelo Systems Manager é `40`.
![\[A área "Resumo do problema" mostrando 40 nós afetados na página Diagnosticar e corrigir\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/2-unmanaged-EC2-instance-count.png)
Ao contrário do relatório de instâncias do EC2 não gerenciadas na página **Revisar insights do nó**, essa contagem de instâncias do EC2 não é dinâmica. Ele representa as descobertas feitas durante a última verificação de diagnóstico relatada, mostrada como o valor de **Tempo de verificação**. Portanto, recomendamos executar uma verificação de diagnóstico para instâncias do EC2 não gerenciadas em uma programação regular para manter atualizado esse número relatado de nós afetados.
Para obter informações sobre número de instâncias não gerenciadas na página **Revisar insights do nó**, consulte [O que é uma instância não gerenciada?](review-node-insights.md#unmanaged-instance-definition) no tópico [Como revisar insights de nós](review-node-insights.md).
**Topics**
+ [Como o Systems Manager conta os nós afetados para a lista "Problemas de instâncias do EC2 não gerenciadas"](#unmanaged-instance-scan-count)
+ [Categorias de problemas diagnosticáveis de instâncias do EC2 não gerenciadas](diagnosing-ec2-category-types.md)
+ [Executar um diagnóstico e uma correção opcional para instâncias do EC2 não gerenciadas](running-diagnosis-execution-ec2.md)
+ [Programar uma verificação recorrente para instâncias do EC2 não gerenciadas](schedule-recurring-ec2-diagnosis.md)
# Categorias de problemas diagnosticáveis de instâncias do EC2 não gerenciadas
Este tópico lista as principais categorias de problemas de gerenciamento do EC2 e os problemas específicos em cada categoria que o Systems Manager pode ajudar a diagnosticar e corrigir. Observe que, para alguns dos problemas, o Systems Manager pode identificar o problema, mas não fornecer uma correção automática. Nesses casos, o console do Systems Manager direciona você às informações necessárias para ajud a resolver o problema manualmente.
O processo de diagnóstico examina cada grupo de instâncias do EC2 de uma só vez de acordo com a nuvem privada virtual (VPC) à qual elas pertencem.
**Topics**
+ [Categoria do problema: configuração do grupo de segurança e comunicações HTTPS](#unmanaged-ec2-issue-security-groups)
+ [Categoria do problema: configuração do DNS ou do nome de host DNS](#unmanaged-ec2-issue-dns-configuration)
+ [Categoria do problema: configuração do endpoint da VPC](#unmanaged-ec2-issue-vpc-endpoint-configuration)
+ [Categoria do problema: configuração de ACL de rede](#unmanaged-ec2-issue-nacl-configuration)
## Categoria do problema: configuração do grupo de segurança e comunicações HTTPS
Uma operação de diagnóstico pode descobrir que o SSM Agent não consegue se comunicar com o serviço Systems Manager via HTTPS. Nesses casos, você pode optar por executar um runbook do Automation que tente atualizar os grupos de segurança anexados às instâncias.
**nota**
Ocasionalmente, o Systems Manager pode não conseguir corrigir automaticamente esses problemas, mas você pode editar manualmente os grupos de segurança afetados.
**Tipos de problemas com suporte**
+ **Grupo de segurança da instância**: tráfego de saída não é permitido na porta 443
+ **Grupo de segurança do endpoint da VPC do `ssm`**: tráfego de entrada não é permitido na porta 443
+ **Grupo de segurança do endpoint da VPC do `ssmmessages`**: tráfego de entrada não permitido na porta 443
+ **Grupo de segurança do endpoint da VPC do `ec2messages`**: tráfego de entrada não permitido na porta 443
Para saber mais, consulte [Verificar regras de entrada e saída em grupos de segurança de endpoints](troubleshooting-ssm-agent.md#agent-ts-ingress-egress-rules) no tópico [Solução de problemas do SSM Agent](troubleshooting-ssm-agent.md).
## Categoria do problema: configuração do DNS ou do nome de host DNS
Uma operação de diagnóstico pode descobrir que o Domain Name System (DNS) ou os nomes de host DNS não estão configurados corretamente para a VPC. Nesses casos, você pode optar por executar um runbook do Automation que tente ativar os atributos `enableDnsSupport` e `enableDnsHostnames` da VPC afetada.
**Tipos de problemas com suporte**
+ O suporte ao DNS está desabilitado em uma VPC.
+ Um nome de host DNS está desabilitado em uma VPC.
Para saber mais, consulte [Verificar seus atributos relacionados a DNS da VPC](troubleshooting-ssm-agent.md#agent-ts-dns-attributes) no tópico [Solução de problemas do SSM Agent](troubleshooting-ssm-agent.md).
## Categoria do problema: configuração do endpoint da VPC
Uma operação de diagnóstico pode descobrir que os endpoints da VPC não estão configurados adequadamente para a VPC.
Se os endpoints da VPC exigidos pelo SSM Agent não existirem, o Systems Manager tentará executar um runbook do Automation para criar os endpoints da VPC e associá-los a uma sub-rede em cada zona de disponibilidade regional (AZ) relevante. Se os endpoints da VPC necessários existirem, mas não estiverem associados a uma sub-rede na qual o problema foi encontrado, o runbook associará os endpoints da VPC à sub-rede afetada.
**nota**
O Systems Manager não oferece suporte a todos os problemas de VPC com configuração incorreta de endpoints da VPC. Nesses casos, o Systems Manager direcionará você para instruções de correção manual em vez de executar um runbook do Automation .
**Tipos de problemas com suporte**
+ Nenhum endpoint `ssm.region.amazonaws.com` para o PrivateLink foi encontrado.
+ Nenhum endpoint `ssmmessages.region.amazonaws.com` para o PrivateLink foi encontrado.
+ Nenhum endpoint `ec2messages.region.amazonaws.com` para o PrivateLink foi encontrado.
**Tipos de problemas diagnosticáveis**
O Systems Manager pode diagnosticar os tipos de problemas a seguir, mas, no momento, não há um runbook disponível para corrigi-los. É possível editar sua configuração manualmente para esses problemas.
+ A sub-rede de uma instância não está anexada a um endpoint `ssm.region.amazonaws.com`.
+ A sub-rede de uma instância não está anexada a um endpoint `ssmmessages.region.amazonaws.com`.
+ Sub-rede de uma instância não anexada a um endpoint `ec2messages.region.amazonaws.com`.
Para saber mais, consulte [Verificar sua configuração de VPC](troubleshooting-ssm-agent.md#agent-ts-vpc-configuration) no tópico [Solução de problemas do SSM Agent](troubleshooting-ssm-agent.md).
## Categoria do problema: configuração de ACL de rede
Uma operação de diagnóstico pode descobrir que as listas de controle de acesso à rede (NACLs) não estão configuradas corretamente para a VPC, o que bloqueia o tráfego necessário para a comunicação do Systems Manager. As NACLs não têm estado; portanto, tanto as regras de saída quanto as regras de entrada devem permitir tráfego do Systems Manager.
O Systems Manager pode identificar problemas de configuração de NACL e fornecer orientação para remediação manual.
**Tipos de problemas com suporte**
+ **NACL da sub-rede da instância**: não é permitido tráfego de saída na porta 443 para endpoints do Systems Manager
+ **NACL de sub-rede de instância**: não é permitido tráfego de entrada nas portas efêmeras (1024 a 65535) para respostas do Systems Manager
**Tipos de problemas diagnosticáveis**
O Systems Manager pode diagnosticar os seguintes problemas de configuração de NACL, mas é necessária correção manual:
+ A NACL de sub-rede de uma instância bloqueia o tráfego HTTPS de saída (porta 443) para endpoints do Systems Manager
+ A NACL de sub-rede de uma instância bloqueia o tráfego de entrada nas portas efêmeras (1024 a 65535) que é necessário para respostas do Systems Manager
Para obter mais informações, consulte [ Solução de problemas do SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html) e [ACLs de rede personalizadas para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/custom-network-acl.html#nacl-ephemeral-ports).
# Executar um diagnóstico e uma correção opcional para instâncias do EC2 não gerenciadas
Use o procedimento a seguir para diagnosticar os problemas relacionados à rede e à VPC que podem estar impedindo o Systems Manager de gerenciar suas instâncias do EC2.
A operação de diagnóstico pode detectar e agrupar problemas dos seguintes tipos:
+ **Problemas de configuração de rede**: tipos de problemas de rede que podem estar impedindo que as instâncias do EC2 se comuniquem com o serviço Systems Manager na nuvem. Operações de correção podem estar disponíveis para esses problemas. Para obter mais informações sobre os problemas de configuração de rede, consulte [Categorias de problemas diagnosticáveis de instâncias do EC2 não gerenciadas](diagnosing-ec2-category-types.md).
+ **Problemas não identificados**: uma lista de descobertas de casos em que a operação de diagnóstico não conseguiu determinar por que as instâncias do EC2 não conseguem se comunicar com o serviço Systems Manager na nuvem.
**Para executar um diagnóstico e uma correção para instâncias do EC2 não gerenciadas**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Diagnosticar e corrigir**.
1. Escolha a guia **Problema de instâncias do EC2 não gerenciadas**.
1. Na seção **Resumo do problema**, escolha **Executar novo diagnóstico**.
- ou -
Se esta for a primeira vez que você diagnostica problemas do EC2 não gerenciados, na seção **Diagnosticar instâncias do EC2 não gerenciadas**, escolha **Executar**.
**dica**
Enquanto o diagnóstico está em execução, escolha **Visualizar progresso** ou **Visualizar execuções** para monitorar o estado atual da execução. Para obter mais informações, consulte [Verificar o progresso da execução e o histórico de correções no Systems Manager](diagnose-and-remediate-execution-history.md).
1. Após concluir o diagnóstico, faça o seguinte:
+ Para quaisquer problemas relatados na seção **Problemas não identificados**, escolha o link **Saiba mais** para obter informações sobre como resolver o problema.
+ Para problemas relatados na seção **Problemas de configurações de rede**, prossiga para a próxima etapa.
1. Na lista de tipos de descoberta, na coluna **Recomendações**, para um problema específico, escolha o link, como **Duas recomendações**.
1. No painel **Recomendações** que é aberto, escolha entre as mitigações disponíveis:
+ **Saiba mais**: abra um tópico com informações sobre como resolver um problema manualmente.
+ **Visualizar runbook**: abra um painel com informações sobre o runbook do Automation que você pode executar para resolver o problema com suas instâncias do EC2, bem como opções para gerar uma *prévia* das ações que o runbook executaria. Continue na próxima etapa.
1. No painel do runbook, faça o seguinte:
1. Em **Descrição do documento**, revise o conteúdo, que fornece uma visão geral das ações que o runbook pode realizar para remediar seus problemas de instância do EC2 não gerenciada. Escolha **Visualizar etapas** para ver uma prévia das ações individuais que o runbook executaria.
1. Em **Destinos**, faça o seguinte:
+ Se você estiver gerenciando remediações para uma organização, em **Contas**, especifique se esse runbook teria como alvo todas as contas ou apenas um subconjunto de contas escolhido por você.
+ Em **Regiões**, especifique se esse runbook teria como alvo todas as Regiões da AWS em sua conta ou organização ou apenas a subconjunto de regiões escolhido por você.
1. Para ver uma **Prévia do runbook**, revise cuidadosamente as informações. Essas informações explicam qual seria o escopo e o impacto se você optasse por executar o runbook.
**nota**
Executar de fato o runbook incorreria em cobranças. Revise as informações resultantes da prévia com cuidado antes de decidir se deseja continuar.
O conteúdo da **Prévia do runbook** fornece as seguintes informações:
+ Em quantas regiões a operação do runbook ocorreria.
+ (Somente para organizações) Em quantas unidades organizacionais (OUs) a operação seria executada.
+ Os tipos de ações que seriam tomadas e quantas de cada uma.
Os tipos de ações incluem os seguintes:
+ **Mutante**: a etapa de runbook faria alterações nos alvos por meio de ações que criam, modificam ou excluem recursos.
+ **Não mutante**: a etapa do runbook recuperaria dados sobre recursos, mas não faria alterações neles. Essa categoria geralmente inclui `Describe*`, `List*`, `Get*` e ações similares de API somente leitura.
+ **Indeterminada**: uma etapa indeterminada invoca execuçexecutadas por outro serviço de orquestração como AWS Lambda, AWS Step Functions ou AWS Systems Manager Run Command. Uma etapa indeterminada também poderia chamar uma API de terceiros. O Systems Manager Automation não conhece o resultado dos processos de orquestração ou das execuções de API de terceiros. Portanto, os resultados das etapas são indeterminados.
1. Nesse ponto, você pode escolher uma das seguintes ações:
+ Parar e não executar o runbook.
+ Escolher **Executar** para executar o runbook com as opções que você já selecionou.
Se você decidir executar a operação, escolha **Visualizar progresso** ou **Visualizar execuções** para monitorar o estado atual da execução. Para obter mais informações, consulte [Verificar o progresso da execução e o histórico de correções no Systems Manager](diagnose-and-remediate-execution-history.md).
# Programar uma verificação recorrente para instâncias do EC2 não gerenciadas
Você pode executar uma verificação sob demanda para instâncias do Amazon EC2 em sua conta ou organização que o Systems Manager não consegue gerenciar devido a vários problemas de configuração. Também é possível programar essa verificação para que ela ocorra automaticamente de acordo com uma programação regular.
**Para programar uma verificação recorrente para instâncias do EC2 não gerenciadas**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Diagnosticar e corrigir**.
1. Escolha a guia **Problema de instâncias do EC2 não gerenciadas**.
1. Na seção **Diagnosticar instâncias do EC2 não gerenciadas**, ative **Programar diagnóstico recorrente**.
1. Em **Frequência do diagnóstico**, selecione se deseja executar o diagnóstico uma vez por dia ou uma vez por semana.
1. (Opcional) Em **Hora de início**, insira uma hora, no formato de 24 horas, para o início do diagnóstico. Por exemplo, para às 8h15 da noite, insira **20:15**.
A hora inserida deve estar no fuso horário local atual.
Se você não especificar uma hora, a verificação de diagnóstico será executada imediatamente. O Systems Manager também programa a verificação para ser executada no futuro no horário atual. Se você especificar um horário, o Systems Manager aguardará para executar a verificação de diagnóstico no horário especificado.
1. Clique em **Executar**. O diagnóstico é executado imediatamente, mas também de acordo com a programação que você especificou.
# Tipos de impacto de remediação de ações do runbook
O Systems Manager pode executar operações de diagnóstico que descobrem certos tipos de implantações com falha e configurações derivadas, bem como determinados tipos de problemas de configuração que estão impedindo o Systems Manager de gerenciar instâncias do EC2. Os resultados do diagnóstico podem incluir recomendações para runbooks do Automation que você pode executar para tentar solucionar um problema. Para obter mais informações sobre essas operações de diagnóstico, consulte os seguintes tópicos:
+ [Diagnosticar e corrigir implantações com falha](remediating-deployment-issues.md)
+ [Diagnosticar e revisar configurações com desvios](remediating-configuration-drift.md)
+ [Diagnosticar e corrigir instâncias não gerenciadas do Amazon EC2 no Systems Manager](remediating-unmanaged-instances.md)
Quando o Systems Manager identifica um problema que pode ser corrigido por meio da execução de um runbook do Automation nos recursos afetados, ele fornece uma *prévia da execução*. A prévia da execução fornece informações sobre os *tipos* de alterações que a execução do runbook faria em seus alvos. Essas informações incluem quanto de cada um dos três tipos de alterações o diagnóstico identificou.
Esses tipos de alteração são os seguintes:
+ `Mutating`: uma etapa do runbook faria alterações nos alvos por meio de ações que criam, modificam ou excluem recursos.
+ `Non-Mutating`: uma etapa do runbook recuperaria dados sobre recursos, mas não faria alterações neles. Essa categoria geralmente inclui `Describe*`, `List*`, `Get*` e ações similares de API somente leitura.
+ `Undetermined`: uma etapa indeterminada invoca execuções executadas por outro serviço de orquestração como AWS Lambda, AWS Step Functions ou Run Command, uma ferramenta do AWS Systems Manager. Uma etapa indeterminada também pode chamar uma API de terceiros ou executar um script Python ou PowerShell. O Systems Manager Automation não consegue detectar qual seria o resultado dos processos de orquestração ou das execuções de API de terceiros e, portanto, não pode avaliá-los. Os resultados dessas etapas precisariam ser revisados manualmente para determinar seus impactos.
Consulte a tabela a seguir para obter informações sobre o tipo de impacto das ações do Automation válidas.
## Tipos de impacto das ações de correção válidas
A tabela apresenta o tipo de impacto (Mutante, Não mutante e Indeterminada) de várias ações que podem ser incluídas em um runbook de remediação.
| Ação¹ | Tipo de impacto |
| --- | --- |
| aws:approve | Não mutante |
| aws:assertAwsResourceProperty | Não mutante |
| aws:branch | Não mutante |
| aws:changeInstanceState | Mutante |
| aws:copyImage | Mutante |
| aws:createImage | Mutante |
| aws:createStack | Mutante |
| aws:createTags | Mutante |
| aws:deleteImage | Mutante |
| aws:deleteStack | Mutante |
| aws:executeAutomation | Indeterminada |
| aws:executeAwsApi | Indeterminada |
| aws:executeScript | Indeterminada |
| aws:executeStateMachine | Indeterminada |
| aws:invokeLambdaFunction | Indeterminada |
| aws:invokeWebhook | Indeterminada |
| aws:loop | Varia. Depende das ações no loop. |
| aws:pause | Não mutante |
| aws:runCommand | Indeterminada |
| aws:runInstances | Mutante |
| aws:sleep | Não mutante |
| aws:updateVariable | Mutante |
| aws:waitForAwsResourceProperty | Não mutante |
¹ Para obter informações sobre ações do Automation, consulte [Referência de ações do Systems Manager Automation](automation-actions.md).
# Verificar o progresso da execução e o histórico de correções no Systems Manager
É possível visualizar uma lista de todas operações de correção em andamento e concluídas feitas usando o recurso **Diagnosticar e corrigir** no Systems Manager.
Os dados na lista do histórico de execução relatam os seguintes tipos de informações:
+ O tipo de execução, `Diagnosis` ou `Remediation`.
+ O status da execução, como `Success` ou `Failed`.
+ Os horários em que a execução começou e terminou.
**Para verificar o progresso da execução e o histórico de correções**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Diagnosticar e corrigir**.
1. Escolha **Visualizar execuções**.
**dica**
Quando uma execução está em andamento, também é possível escolher **Visualizar progresso** para abrir a página **Histórico de execuções**.
1. (Opcional) Na caixa de pesquisa (![\[The search icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/search-icon.png)), insira uma frase para ajudar a restringir a lista de execução, como **EC2** ou **VPC**.
1. (Opcional) Para visualizar detalhes adicionais sobre uma execução, na coluna **Nome da execução** escolha um nome de operação, como **AWS-DiagnoseUnmanagedEC2NetworkIssues**.
No painel de detalhes, você pode revisar as informações sobre todas as etapas tentadas durante a operação e sobre todas as entradas e saídas da execução.
# Ajustar as configurações do Systems Manager
As opções nas páginas **Configurações** habilitam e configuram recursos no console unificado do Systems Manager. As opções exibidas dependem da conta na qual você está conectado e se você já configurou ou não o Systems Manager.
**nota**
As opções na página **Configurações** não afetam as ferramentas do Systems Manager (anteriormente chamadas de recursos).
## Configurações da conta
Se o Systems Manager estiver habilitado e você estiver conectado a uma conta que não é membro do Organizations ou se o administrador delegado não tiver adicionado sua conta do Organizations ao Systems Manager, a página **Configuração da conta** mostrará a opção **Desabilitar o Systems Manager**. Desabilitar o Systems Manager significa que o Systems Manager não exibirá o console unificado. Todas as ferramentas do Systems Manager ainda funcionam.
## Configurações organizacionais
Na guia **Configuração organizacional**, a seção **Região de origem** exibe a região Região da AWS escolhida como a região de origem durante a configuração. Em ambientes com várias contas e várias regiões que usam o AWS Organizations, o Systems Manager agrega automaticamente os dados dos nós de todas as contas e regiões na região de origem. Agregar dados dessa forma permite que você visualize os dados dos nós em todas as contas e regiões em um único local.
**nota**
Caso deseje alterar a região de origem, será necessário desabilitar o Systems Manager e habilitá-lo novamente. Para desabilitar o Systems Manager, selecione **Desabilitar**.
A seção **Configuração organizacional** exibe as unidades organizacionais da AWS e as Regiões da AWS escolhidas durante a configuração. Para alterar quais unidades organizacionais e regiões exibem dados de nós no Systems Manager, escolha **Editar**. Para obter mais informações sobre a configuração do Systems Manager for Organizations, consulte [Configurar o AWS Systems Manager](systems-manager-setting-up-console.md).
## Configurações de recursos
A seção **Configurações de recursos** permite a você habilitar e configurar os principais recursos do Systems Manager que aprimoram o gerenciamento de nós em sua organização. Esses recursos trabalham juntos para fornecer gerenciamento automatizado, monitoramento de conformidade e manutenção dos seus nós gerenciados.
Você pode configurar esses recursos durante a configuração inicial do Systems Manager ou modificá-los posteriormente por meio da página Configurações. Cada recurso pode ser ativado ou desativado de forma independente com base nos requisitos da sua organização.
### Configuração de gerenciamento de host padrão
A Configuração de gerenciamento de hosts padrão (DHMC) configura automaticamente instâncias do Amazon Elastic Compute Cloud (Amazon EC2) em sua organização para ser gerenciadas pelo Systems Manager. Quando habilitada, a DHMC garante que as instâncias do EC2 novas e existentes tenham as permissões e configurações do AWS Identity and Access Management (IAM) necessárias para se comunicar com os serviços do Systems Manager.
O DHMC fornece os seguintes benefícios:
+ **Atribuição automática de perfis do IAM**: garante que as instâncias do EC2 tenham os perfis e políticas do IAM necessários para funcionar como nós gerenciados
+ **Correção de desvios**: corrige automaticamente os desvios de configuração quando as instâncias perdem o status de nó gerenciado
+ **Integração simplificada**: reduz as etapas de configuração manual para novas instâncias
+ **Configuração consistente**: mantém configurações uniformes em toda a sua frota do EC2
#### Configurar a frequência de correção de desvios
A correção de desvios detecta e corrige automaticamente quando as instâncias do EC2 perdem sua configuração de nó gerenciado. É possível configurar a frequência com que o Systems Manager verifica e corrige os desvios de configuração.
**Para ajustar a Configuração de gerenciamento de hosts padrão**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, selecione **Configurações**.
1. Na seção **Configurações de recursos**, localize **Configuração de gerenciamento de hosts padrão**.
1. Para habilitar a DHMC, ative a chave seletora.
1. Para **Frequência de correção de desvios**, escolha com que frequência você deseja que o Systems Manager verifique e corrija o desvio de configuração:
+ **Diariamente**: verifica e corrige desvios uma vez por dia
+ **Semanalmente**: verifica e corrige desvios uma vez por semana
+ **Mensalmente**: verifica e corrige desvios uma vez por mês
1. Escolha **Salvar**.
**nota**
Quando você habilita a DHMC, o Systems Manager cria os perfis e políticas do IAM necessários em sua conta. Esses perfis permitem que as instâncias do EC2 se comuniquem com os serviços do Systems Manager. Para obter mais informações sobre os perfis do IAM criados pela DHMC, consulte [Gerenciar instâncias do EC2 com o Systems Manager](systems-manager-setting-up-ec2.md).
### Coleta de metadados de inventário
A coleta de metadados de inventário reúne automaticamente informações detalhadas sobre seus nós gerenciados, incluindo aplicações instaladas, configurações de rede, atualizações do sistema e outros metadados do sistema. Essas informações ajudam você a manter a conformidade, realizar análises de segurança e entender a composição da sua infraestrutura.
A coleta de inventário oferece os seguintes benefícios:
+ **Monitoramento da conformidade**: acompanhe o software instalado e as configurações para relatórios de conformidade
+ **Análise de segurança**: identifique software desatualizado e possíveis vulnerabilidades de segurança
+ **Gerenciamento de ativos**: mantenha um inventário atualizado da sua infraestrutura
+ **Recursos de consulta**: use os dados coletados com o Amazon Q Developer para consultas em linguagem natural
#### Tipos de dados de inventário coletados
Quando a coleta de metadados de inventário está habilitada, o Systems Manager coleta os seguintes tipos de informações de seus nós gerenciados:
+ **Aplicações**: pacotes de software e aplicações instalados
+ **Configurações de rede**: interfaces de rede, endereços IP e configurações de rede
+ **Atualizações do sistema**: patches instalados e atualizações disponíveis
+ **Propriedades do sistema**: especificações de hardware, detalhes do sistema operacional e configurações do sistema
+ **Serviços**: serviços em execução e suas configurações
#### Configurar a frequência da coleta de inventário
É possível configurar a frequência na qual o Systems Manager coleta metadados de inventário dos nós gerenciados. A coleta mais frequente fornece informações mais atualizadas, mas pode aumentar o uso do serviço da AWS.
**Para configurar a coleta de metadados do inventário**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, selecione **Configurações**.
1. Na seção **Configurações de recursos**, localize **Coleta de metadados de inventário**.
1. Para habilitar a coleta de inventário, ative a chave seletora.
1. Em **Frequência de coleta**, escolha com que frequência você deseja que o Systems Manager colete dados de inventário:
+ **Diariamente**: coleta dados de inventário uma vez por dia
+ **Semanalmente**: coleta dados de inventário uma vez por semana
+ **Mensalmente**: coleta dados de inventário uma vez por mês
1. Escolha **Salvar**.
**Importante**
A coleta de inventário exige que os nós gerenciados tenham as permissões necessárias para coletar informações do sistema. Certifique-se de que seus nós gerenciados tenham os perfis e políticas apropriados do IAM. Para obter mais informações sobre as permissões necessárias, consulte [AWS Systems Manager Inventory](systems-manager-inventory.md).
### SSM AgentAtualizações do
As atualizações automáticas do SSM Agent garantem que seus nós gerenciados estejam executando a versão mais recente do SSM Agent. Manter o agente atualizado fornece acesso aos recursos, melhorias de segurança e correções de erros mais recentes.
As atualizações automáticas do SSM Agent oferecem os seguintes benefícios:
+ **Recursos mais recentes**: acesso aos novos recursos e melhorias do Systems Manager
+ **Atualizações de segurança**: instalação automática de patches e correções de segurança
+ **Confiabilidade aprimorada**: correções de erros e melhorias na estabilidade
+ **Manutenção reduzida**: elimina a necessidade de atualizações manuais do agente
#### Configurar atualizações automáticas do agente
É possível configurar a frequência com que o Systems Manager verifica e instala atualizações do SSM Agent em seus nós gerenciados. Fazer atualizações regularmente ajuda a garantir níveis ideais de performance e segurança.
**Para configurar atualizações do SSM Agent**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Configurações**.
1. Na seção **Configurações de recursos**, localize **Atualizações do SSM Agent**.
1. Para habilitar as atualizações automáticas, ative a chave seletora.
1. Para **Frequência de atualização**, escolha com que frequência você deseja que o Systems Manager verifique e instale as atualizações do agente:
+ **Diariamente**: verifica se há atualizações uma vez por dia
+ **Semanalmente**: verifica se há atualizações uma vez por semana
+ **Mensalmente**: verifica se há atualizações uma vez por mês
1. Escolha **Salvar**.
## Configurações de Diagnosticar e corrigir
As configurações de **Diagnosticar e corrigir** determinam se o Systems Manager verifica automaticamente seus nós para garantir que eles possam se comunicar com o Systems Manager. Se habilitado, o recurso é executado automaticamente de acordo com um cronograma definido por você. O recurso identifica quais nós não podem se conectar ao Systems Manager e por quê. Esse recurso também fornece runbooks recomendados para corrigir problemas de rede e outros problemas que impedem que os nós sejam configurados como nós gerenciados.
### Programar uma verificação de diagnóstico recorrente
O Systems Manager pode diagnosticar e ajudar você a corrigir vários tipos de falhas de implantação, bem como configurações desviadas. O Systems Manager também pode identificar instâncias do Amazon Elastic Compute Cloud (Amazon EC2) em sua conta ou organização que o Systems Manager não pode tratar como um *nó gerenciado*. O processo de diagnóstico de instâncias do EC2 pode identificar problemas relacionados a configurações incorretas em uma nuvem privada virtual (VPC), em uma configuração do Domain Name Service (DNS) ou em um grupo de segurança do Amazon Elastic Compute Cloud (Amazon EC2).
Para simplificar a tarefa de identificar nós que não conseguem se conectar ao Systems Manager, o recurso **Programar diagnóstico recorrente** permite automatizar uma verificação de diagnóstico recorrente. As verificações ajudam a identificar quais nós não podem se conectar ao Systems Manager e por quê. Use o procedimento a seguir para habilitar e configurar uma verificação de diagnóstico recorrente de seus nós.
**Para programar uma verificação de diagnóstico recorrente**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, selecione **Configurações** e em seguida, a guia **Diagnosticar e corrigir**.
1. Ative a opção **Programar diagnóstico recorrente**.
1. Em **Período de verificação**, escolha a frequência na qual você deseja que a verificação seja executada.
1. (Opcional) Em **Hora de início**, insira uma hora, no formato de 24 horas, para o início do diagnóstico. Por exemplo, para às 8h15 da noite, insira **20:15**.
A hora inserida deve estar no fuso horário local atual.
Se você não especificar uma hora, a verificação de diagnóstico será executada imediatamente. O Systems Manager também programa a verificação para ser executada no futuro no horário atual. Se você especificar um horário, o Systems Manager aguardará para executar a verificação de diagnóstico no horário especificado.
1. Escolha **Salvar**.
1. Depois que a verificação for concluída, visualize os detalhes escolhendo **Diagnosticar e corrigir** no painel de navegação à esquerda.
Para obter mais informações sobre o recurso **Diagnosticar e corrigir**, consulte [Diagnosticar e remediar](diagnose-and-remediate.md).
### Atualizar a criptografia do bucket do S3
Quando você integra o Systems Manager, a Configuração Rápida cria um bucket do Amazon Simple Storage Service (Amazon S3) na conta do administrador delegado para configurações do AWS Organizations. Para configurações de conta única, o bucket é armazenado na conta que está sendo configurada. Esse bucket é usado para armazenar os metadados gerados durante as verificações de diagnóstico.
Para obter mais informações sobre a configuração do console unificado do Systems Manager, consulte [Configurar o AWS Systems Manager](systems-manager-setting-up-console.md).
Por padrão, seus dados no bucket são criptografados usando uma chave AWS Key Management Service (AWS KMS) que pertence a e é gerenciada pela AWS para você.
Você pode optar por usar uma chave do AWS KMS diferente para criptografar o bucket. Outra opção é usar a criptografia no lado do servidor com o AWS KMS keys (SSE-KMS) utilizando uma chave gerenciada pelo cliente (CMK). Para mais informações, consulte [Como trabalhar com buckets do Amazon S3 e com políticas de bucket para o Systems Manager](systems-manager-diagnosis-metadata-bucket.md).
**Para usar uma chave do AWS KMS diferente para criptografar o bucket do S3**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, selecione **Configurações** e em seguida, a guia **Diagnosticar e corrigir**.
1. Na área **Atualizar criptografia do bucket do S3**, escolha **Editar**.
1. Marque a caixa de seleção **Personalizar configurações de criptografia (avançadas)**.
1. Em **Escolher uma chave do AWS KMS**, escolha ou insira o nome do recurso da Amazon (ARN) da chave.
**dica**
Para criar uma nova chave, escolha **Criar uma chave do AWS KMS**.
1. Escolha **Salvar**.
# Como trabalhar com buckets do Amazon S3 e com políticas de bucket para o Systems Manager
Durante o [processo de integração](systems-manager-setting-up-console.md) do AWS Systems Manager, o Quick Setup cria um bucket do Amazon Simple Storage Service (Amazon S3) na conta de administrador delegado para configurações da organização. Para configurações de conta única, o bucket é armazenado na conta que está sendo configurada.
É possível usar o Systems Manager para executar operações de diagnóstico em sua frota para identificar casos de falhas em implantações e configurações com desvios. O Systems Manager também pode detectar casos em que problemas de configuração estão impedindo o Systems Manager de gerenciar instâncias do EC2 em sua conta ou organização. Os resultados dessas operações de diagnóstico são armazenados nesse bucket do Amazon S3, o qual é protegido por um método de criptografia e por uma política de bucket do S3. Para obter informações sobre as operações de diagnóstico que geram dados para esse bucket, consulte [Diagnosticar e remediar](diagnose-and-remediate.md).
**Alterar o método de criptografia do bucket**
Por padrão, o bucket do S3 usa criptografia do lado do servidor com chaves gerenciadas pelo Amazon S3 (SSE-S3).
Em vez disso, você pode usar criptografia do lado do servidor com AWS KMS keys (SSE-KMS) usando uma chave gerenciada pelo cliente (CMK) como alternativa às chaves gerenciadas pelo Amazon S3, conforme explicado em [Mudar para uma chave gerenciada pelo cliente do AWS KMS para fornecer criptografia para recursos do S3](remediate-s3-bucket-encryption.md).
**Conteúdo da política de buckets**
A política de buckets impede que as contas-membro de uma organização descubram umas às outras. As permissões de leitura e gravação no bucket são permitidas somente para os perfis de diagnóstico e remediação criados para o Systems Manager. O conteúdo dessas políticas geradas pelo sistema é apresentado em [Políticas de bucket do S3 para o console unificado do Systems Manager](remediate-s3-bucket-policies.md).
**Atenção**
A modificação da política de bucket padrão pode permitir que as contas-membro de uma organização descubram umas as outras ou leiam os resultados de diagnóstico de instâncias em outra conta. Recomendamos ter muito cuidado ao optar por modificar essa política.
**Topics**
+ [Mudar para uma chave gerenciada pelo cliente do AWS KMS para fornecer criptografia para recursos do S3](remediate-s3-bucket-encryption.md)
+ [Políticas de bucket do S3 para o console unificado do Systems Manager](remediate-s3-bucket-policies.md)
# Mudar para uma chave gerenciada pelo cliente do AWS KMS para fornecer criptografia para recursos do S3
Durante o processo de integração do console unificado do Systems Manager, a Quick Setup cria um bucket do Amazon Simple Storage Service (Amazon S3) na conta do administrador delegado. Esse bucket é usado para armazenar os dados de saída de diagnóstico gerados durante as execuções do runbook de correção. Por padrão, o bucket usa criptografia do lado do servidor com chaves de criptografia gerenciadas pelo Amazon S3 (SSE-S3).
Você pode revisar o conteúdo dessas políticas em [Políticas de bucket do S3 para o console unificado do Systems Manager](remediate-s3-bucket-policies.md).
No entanto, você pode usar a criptografia no lado do servidor com o AWS KMS keys (SSE-KMS) usando uma chave gerenciada pelo cliente (CMK) como alternativa a uma AWS KMS key.
Conclua as tarefas a seguir para configurar o Systems Manager para usar sua CMK.
## Tarefa 1: adicionar uma tag a uma CMK existente
O AWS Systems Manager usará sua CMK somente se ela estiver marcada com o seguinte par de chave-valor:
+ Chave: `SystemsManagerManaged`
+ Valor:: `true`
Use o procedimento a seguir para fornecer acesso para criptografar o bucket do S3 com sua CMK.
**Para adicionar uma tag à sua CMK existente**
1. Abra o console do AWS KMS em [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Na navegação esquerda, escolha **Chaves gerenciadas pelo cliente**.
1. Selecione o AWS KMS key para usar com o AWS Systems Manager.
1. Selecione a guia **Etiquetas** e escolha **Editar**.
1. Escolha **Adicionar Tag**.
1. Faça o seguinte:
1. Em **Tag Key (Chave de tags)**, digite **SystemsManagerManaged**.
1. Em **Valor da tag**, insira **true**.
1. Escolha **Salvar**.
## Tarefa 2: modificar uma política de chave de CMK existente
Use o procedimento a seguir para atualizar a [política de chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) da sua CMK para permitir que os perfis do AWS Systems Manager criptografem o bucket do S3 em seu nome.
**Para modificar uma política de chave de CMK existente**
1. Abra o console do AWS KMS em [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Na navegação esquerda, escolha **Chaves gerenciadas pelo cliente**.
1. Selecione o AWS KMS key para usar com o AWS Systems Manager.
1. Na guia **Política de chave**, escolha **Editar**.
1. Adicione a instrução JSON a seguir ao campo `Statement` e substitua os *valores do espaço reservado* por suas próprias informações.
Certifique-se de adicionar todas as IDs de Conta da AWS integradas em sua organização ao AWS Systems Manager no campo `Principal`.
Para localizar o nome correto do bucket no console do Amazon S3, na conta do administrador delegado, localize o bucket no 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-*"
}
}
}
```
**dica**
Como alternativa, é possível atualizar a política de chave de CMK usando a chave de condição [aws:PrincipalOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) para conceder ao AWS Systems Manager acesso à sua CMK.
## Tarefa 3: especificar a CMK nas configurações do Systems Manager
Após concluir as duas tarefas anteriores, use o procedimento a seguir para alterar a criptografia do bucket do S3. Essa alteração garante que o processo de configuração da Quick Setup associado possa adicionar permissões para que o Systems Manager aceite sua CMK.
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, selecione **Configurações**.
1. **Na guia **Diagnosticar e corrigir**, na seção **Atualizar criptografia do bucket S3**, escolha Editar**.
1. Marque a caixa de seleção **Personalizar configurações de criptografia (avançadas)**.
1. Na caixa de pesquisa (![\[The search icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/search-icon.png)), escolha o ID de uma chave existente ou cole o ARN de uma chave existente.
1. Escolha **Salvar**.
# Políticas de bucket do S3 para o console unificado do Systems Manager
Este tópico inclui as políticas de bucket do Amazon S3 criadas pelo Systems Manager quando você integra uma organização ou conta única ao console unificado do Systems Manager.
**Atenção**
A modificação da política de bucket padrão pode permitir que as contas-membro de uma organização descubram umas as outras ou leiam os resultados de diagnóstico de instâncias em outra conta. Recomendamos ter muito cuidado ao optar por modificar essa política.
## Política de bucket do Amazon S3 para uma organização
O bucket de diagnóstico é criado com a seguinte política de bucket padrão ao integrar uma organização ao 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"
}
}
}
]
}
```
------
## Política de bucket do Amazon S3 para uma única conta
O bucket de diagnóstico é criado com a seguinte política de bucket padrão ao integrar uma conta única ao 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"
}
}
}
]
}
```
------