• 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). 

# AWS Systems Manager Patch Manager
<a name="patch-manager"></a>

O Patch Manager, uma ferramenta do AWS Systems Manager, automatiza o processo de aplicação de patches aos nós gerenciados com atualizações de relativas a segurança e outros tipos de atualizações.

**nota**  
O Systems Manager fornece suporte a *políticas de patches* no Quick Setup, uma ferramenta do AWS Systems Manager. O uso de políticas de patches é o método recomendado para configurar suas operações de patches. Usando uma única configuração de política de patch, é possível definir a aplicação de patches para todas as contas em todas as regiões da sua organização, somente para as contas e regiões que você escolher, ou para um único par de conta-região. Para obter mais informações, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).

Você pode usar o Patch Manager para aplicar patches em sistemas operacionais e aplicações. (No Windows Server, o suporte a aplicações é limitado a atualizações de aplicações da Microsoft.) É possível usar o Patch Manager para instalar os Service Packs em nós do Windows e executar atualizações de versões secundárias em nós do Linux. Você pode aplicar patches a frotas de instâncias do Amazon Elastic Compute Cloud (Amazon EC2), a dispositivos de borda, a servidores on-premises e a máquinas virtuais (VMs) por tipo de sistema operacional. Isso inclui versões com suporte de vários sistemas operacionais, conforme listado em [Pré-requisitos do Patch Manager](patch-manager-prerequisites.md). Você pode verificar instâncias para visualizar somente um relatório de patches ausentes ou verificar e instalar automaticamente todos os patches ausentes. Para começar a usar o Patch Manager, abra o [Systems Manager console](https://console.aws.amazon.com//systems-manager/patch-manager) (Console do gerenciador de sistemas). No painel de navegação, escolha **Patch Manager**.

AWS A não faz testes de patches antes de disponibilizá-los no Patch Manager. Além disso, o Patch Manager não oferece suporte à atualização das principais versões de sistemas operacionais, como Windows Server 2016 a Windows Server 2019 ou Red Hat Enterprise Linux (RHEL) 7.0 para RHEL 8.0.

Para tipos de sistema operacional baseados em Linux que relatem um nível de gravidade para patches, o Patch Manager usa o nível de gravidade relatado pelo editor do software para o aviso de atualização ou patch individual. O Patch Manager não deriva níveis de gravidade de fontes de terceiros, como o [Sistema comum de pontuação de vulnerabilidades](https://www.first.org/cvss/) (CVSS), ou a partir de métricas lançadas pelo [Banco de dados nacional de vulnerabilidades](https://nvd.nist.gov/vuln) (NVD).

## Como o Patch Manager beneficia minha organização?
<a name="how-can-patch-manager-benefit-my-organization"></a>

O Patch Manager automatiza o processo de aplicação de patches aos nós gerenciados com atualizações de relativas a segurança e outros tipos de atualizações. Ele oferece vários benefícios principais:
+ **Controle centralizado de patches**: com políticas de patch, você pode configurar operações recorrentes de aplicação de patches para todas as contas em todas as Regiões da sua organização, em contas e Regiões específicas ou em um único par de conta e Região.
+ **Operações flexíveis de aplicação de patches:** é possível optar por verificar as instâncias para visualizar apenas um relatório dos patches ausentes ou verificar e instalar automaticamente todos os patches ausentes.
+ **Relatórios de conformidade abrangentes:** depois de realizar as operações de verificação, é possível visualizar informações detalhadas sobre quais nós gerenciados não estão em conformidade com patches e quais patches estão ausentes.
+ **Suporte entre iplataformas**: o Patch Manager é compatível com vários sistemas operacionais, incluindo diversas distribuições do Linux, macOS e Windows Server.
+ **Listas de referência de patches personalizadas**: é possível definir o que constitui conformidade de patches para a sua organização por meio de listas de referência de patches personalizadas que especificam quais patches estão aprovados para instalação.
+ **Integração com outros serviços da AWS**: o Patch Manager pode ser integrado com o AWS Organizations, o AWS Security Hub CSPM, o AWS CloudTrail e o AWS Config para melhorar o gerenciamento e reforçar a segurança.
+ **Upgrades determinísticos**: suporte para upgrades determinísticos por meio de repositórios com versionamento para sistemas operacionais, como o Amazon Linux 2023.

## Quem deve usar o Patch Manager?
<a name="who-should-use-patch-manager"></a>

O Patch Manager foi concebido para os seguintes casos de uso:
+ Administradores de TI que têm a necessidade de manter a conformidade dos patches em toda a frota de nós gerenciados.
+ Gerentes de operações que exigem visibilidade sobre o status de conformidade dos patches em toda a sua infraestrutura
+ Arquitetos de nuvem que pretendem implementar soluções automatizadas para aplicação de patches em grande escala
+ Engenheiros de DevOps que precisam integrar a aplicação de patches aos seus fluxos de trabalho de operações
+ Organizações que possuem implantações em várias contas/regiões e que necessitam de gerenciamento centralizado de patches
+ Qualquer pessoa responsável pela mantenção da postura de segurança e da integridade operacional de nós gerenciados da AWS, dispositivos de borda, servidores on-premises e máquinas virtuais

## Quais são os principais recursos do Patch Manager?
<a name="what-are-the-main-features-of-patch-manager"></a>

O Patch Manager fornece vários recursos principais:
+ **Políticas de patches**: configure operações de aplicação de patches em várias Regiões e Contas da AWS utilizando uma única política por meio da integração com o AWS Organizations.
+ **Listas de referência de patches personalizadas**: defina regras de aprovação automática de patches alguns dias após o lançamento dos mesmos, bem como listas de patches aprovados e rejeitados.
+ **Diversos métodos de aplicação de patches**: escolha entre políticas de patches, janelas de manutenção ou operações sob demanda para aplicação de patches a fim de atender às suas necessidades específicas.
+ **Relatórios de conformidade**: gere relatórios detalhados sobre o status de conformidade dos patches, que podem ser enviados a um bucket do Amazon S3 no formato CSV.
+ **Suporte entre plataformas**: aplique patches em sistemas operacionais e aplicações no Windows Server, várias distribuições do Linux e no macOS.
+ **Flexibilidade de programação**: defina programações diferentes para verificar e instalar patches usando expressões CRON ou Rate personalizadas.
+ **Ganchos do ciclo de vida**: execute scripts personalizados antes e depois de operações de aplicação de patches usando documentos do Systems Manager.
+ **Foco na segurança**: por padrão, o foco do Patch Manager está em atualizações de segurança em vez de na instalação de todos os patches disponíveis.
+ **Controle de taxa**: configure limites de simultaneidade e erro para operações de aplicação de patches a fim de minimizar o impacto sobre as operações.

## O que é conformidade no Patch Manager?
<a name="patch-manager-definition-of-compliance"></a>

A referência para o que constitui a *conformidade de patches* para os nós gerenciados em suas frotas do Systems Manager não é definida pela AWS, pelos fornecedores de sistemas operacionais (SO) ou por terceiros, como empresas de consultoria em segurança.

Em vez disso, você define o que significa conformidade de patches para nós gerenciados em sua organização ou conta em uma *lista de referência de patches*. Uma lista de referência de patches é uma configuração que especifica regras para a instalação de patches em um nó gerenciado. Um nó gerenciado é compatível com patches quando está atualizado com todos os patches que atendem aos critérios de aprovação que você especifica na lista de referência de patches. 

Observe que estar *em conformidade* com uma lista de referência de patches não significa que um nó gerenciado seja necessariamente *seguro*. Em conformidade significa que os patches definidos pela lista de referência de patches que estão *disponíveis* e *aprovados* foram instalados no nó. A segurança geral de um nó gerenciado é determinada por muitos fatores fora do escopo do Patch Manager. Para obter mais informações, consulte [Segurança no AWS Systems Manager](security.md).

Cada lista de referência de patches é uma configuração para um tipo específico de sistema operacional (SO) compatível, como Red Hat Enterprise Linux (RHEL), macOS ou Windows Server. Uma lista de referência de patches pode definir regras de patches para todas as versões compatíveis de um sistema operacional ou ser limitada somente às que você especificar, como RHEL 7.8. e RHEL 9.3.

Em uma lista de referência de patches, você pode especificar que todos os patches de determinadas classificações e níveis de severidade sejam aprovados para instalação. Por exemplo, você pode incluir todos os patches classificados como `Security`, mas excluir outras classificações, como `Bugfix` ou `Enhancement`. E você pode incluir todos os patches com uma severidade de `Critical` e excluir outros, como `Important` e `Moderate`.

Você também pode definir patches explicitamente em uma lista de referência de patches adicionando suas IDs às listas de patches específicos a serem aprovados ou rejeitados, como `KB2736693` para Windows Server ou `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` para Amazon Linux 2023 (AL2023). Opcionalmente, você pode especificar um determinado número de dias de espera para a aplicação de patches após a disponibilização de um patch. Para Linux e macOS, você tem a opção de especificar uma lista externa de patches para fins de conformidade (uma lista de substituição de instalação) em vez daquelas definidas pelas regras da lista de referência de patches.

Quando uma operação de aplicação de patches é executada, o Patch Manager compara os patches atualmente aplicados a um nó gerenciado com aqueles que devem ser aplicados de acordo com as regras definidas na lista de referência de patches ou na lista de substituição de instalação. É possível optar para que o Patch Manager mostre somente um relatório de patches que estejam faltando (uma operação `Scan`) ou que o Patch Manager instale automaticamente todos os patches que descobrir estarem faltando em um nó gerenciado (uma operação `Scan and install`).

**nota**  
Os dados de conformidade de patches representam um instantâneo pontual da última operação bem-sucedida de aplicação de patches. Cada relatório de conformidade contém um tempo de captura que identifica quando o status de conformidade foi calculado. Ao analisar os dados de conformidade, considere o tempo de captura para determinar se a operação foi executada conforme o esperado.

O Patch Manager fornece listas de referência de patches predefinidas que você pode usar para suas operações de aplicação de patches; no entanto, essas configurações predefinidas são fornecidas como exemplos e não como práticas recomendadas. Recomendamos que você crie suas próprias listas de referência de patches personalizadas para exercer maior controle sobre o que constitui a conformidade de patches para sua frota.

Para obter mais informações sobre a listas de referência de patches personalizadas, consulte os seguintes tópicos:
+ [Listas de referência de patches predefinidas e personalizadas](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md)
+ [Visualizar as listas de referência de patches predefinidas da AWS](patch-manager-view-predefined-patch-baselines.md)
+ [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md)
+ [Trabalhando com relatórios de conformidade de patch](patch-manager-compliance-reports.md)

## Componentes primários
<a name="primary-components"></a>

Antes de começar a trabalhar com a ferramenta Patch Manager, você deve se familiarizar com alguns dos principais componentes e atributos das operações de aplicação de patches da ferramenta.

**Linhas de base de patch**  
O Patch Manager usa *listas de referência de patches*, que incluem regras para a aprovação automática de patches poucos dias após seus lançamentos, bem como listas opcionais de patches aprovados e rejeitados. Quando uma operação de aplicação de patches é executada, o Patch Manager compara os patches atualmente aplicados a um nó gerenciado com aqueles que devem ser aplicados de acordo com as regras definidas na lista de referência de patches. É possível optar para que o Patch Manager mostre somente um relatório de patches que estejam faltando (uma operação `Scan`) ou que o Patch Manager instale automaticamente todos os patches que descobrir estarem faltando em um nó gerenciado (uma operação `Scan and install`).

**Métodos de operação de aplicação de patches**  
O Patch Manager atualmente oferece quatro métodos para a execução das operações `Scan` e `Scan and install`:
+ **(Recomendado) Uma política de patch configurada em Quick Setup**: com base na integração com o AWS Organizations, uma única política de patch pode definir programações de aplicação de patches e listas de referência de patches para uma organização inteira, incluindo várias Contas da AWS e todas as Regiões da AWS em que essas contas operem. Uma política de patch também pode ter como destino somente algumas unidades organizacionais (UOs) em uma organização. É possível usar uma única política de patch para verificar e instalar em horários diferentes. Para obter mais informações, consulte [Configurar a aplicação de patches para instâncias em uma organização usando uma política de patch do Quick Setup](quick-setup-patch-manager.md) e [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).
+ **Uma opção do Host Management configurada em Quick Setup**: também há suporte para as configurações do Host Management na integração com o AWS Organizations, possibilitando a execução de uma operação de aplicação de patches até para uma organização inteira. No entanto, essa opção se limita à verificação de patches ausentes usando a lista de referência de patches atual padrão e ao fornecimento de resultados em relatórios de conformidade. Esse método de operação não pode instalar patches. Para obter mais informações, consulte [Configurar o gerenciamento de host do Amazon EC2 usando a Quick Setup](quick-setup-host-management.md).
+ **Uma janela de manutenção para executar uma tarefa de `Scan` ou `Install` patches**: uma janela de manutenção, que você configura na ferramenta do Systems Manager chamada Maintenance Windows, pode ser configurada para executar diferentes tipos de tarefas em um agendamento definido por você. Uma tarefa do tipo Run Command pode ser usada para executar tarefas `Scan` ou `Scan and install` em um conjunto de nós gerenciados que você escolher. Cada tarefa da janela de manutenção pode ter como destino os nós gerenciados em apenas um único par Conta da AWS-Região da AWS. Para obter mais informações, consulte [Tutorial: Create a maintenance window for patching using the console](maintenance-window-tutorial-patching.md).
+ **Uma operação **Aplicar patch agora** sob demanda em Patch Manager**: a opção **Aplicar patch** agora permite que você ignore as configurações de programação quando você precisar corrigir os nós gerenciados o mais rápido possível. Usando **Patch now** (Aplicar patch agora), você especifica se deseja executar a operação `Scan` ou `Scan and install` e em quais nós gerenciados executar a operação. Você também pode optar por executar documentos do Systems Manager (documentos SSM) como ganchos do ciclo de vida durante a operação de aplicação de patches. Cada operação **Patch Now** (Aplicar patch agora) pode atingir nós gerenciados em apenas um único par Conta da AWS-Região da AWS. Para obter mais informações, consulte [Aplicação de patches em nós gerenciados sob demanda](patch-manager-patch-now-on-demand.md).

**Relatórios de conformidade**  
Depois de uma operação `Scan`, é possível usar o console do Systems Manager para visualizar informações sobre quais dos seus nós gerenciados estão fora de conformidade com o patch e quais patches estão faltando em cada um desses nós. Você também pode gerar relatórios de conformidade de patches no formato .csv que serão enviados a um bucket do Amazon Simple Storage Service (Amazon S3) de sua escolha. Você pode gerar relatórios únicos ou gerar relatórios em uma programação regular. Para um único nó gerenciado, os relatórios incluem detalhes de todos os patches para o nó. Para obter um relatório sobre todas os nós gerenciados, apenas um resumo de quantos patches estão ausentes é fornecido. Depois que um relatório é gerado, você pode usar uma ferramenta, como o Amazon Quick, para importar e analisar os dados. Para obter mais informações, consulte [Trabalhando com relatórios de conformidade de patch](patch-manager-compliance-reports.md).

**nota**  
Um item de conformidade gerado por meio do uso de uma política de patch tem um tipo de execução de `PatchPolicy`. Um item de conformidade não gerado em uma operação de política de patch tem um tipo de execução de `Command`.

**Integrações**  
O Patch Manager se integra com os outros seguintes Serviços da AWS: 
+ **AWS Identity and Access Management (IAM)**: use o IAM para controlar quais usuários, grupos e funções têm acesso às operações do Patch Manager. Para obter mais informações, consulte [Como o AWS Systems Manager funciona com o IAM](security_iam_service-with-iam.md) e [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md). 
+ **AWS CloudTrail** – use o CloudTrail para registrar um histórico auditável de eventos de operação de aplicação de patches iniciados por usuários, perfis ou grupos. Para obter mais informações, consulte [Registrar em log chamadas de API do AWS Systems Manager com o AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **AWS Security Hub CSPM**: dados de conformidade de patches do Patch Manager pode ser enviado para o AWS Security Hub CSPM. O Security Hub CSPM oferece uma visão abrangente dos alertas de segurança de alta prioridade e do status de conformidade. Também monitora o estado de aplicação de patches da sua frota. Para obter mais informações, consulte [Integração do Patch Manager com o AWS Security Hub CSPM](patch-manager-security-hub-integration.md). 
+ **AWS Config**: configure a gravação no AWS Config para visualizar os dados de gerenciamento de instâncias do Amazon EC2 no painel do Patch Manager. Para obter mais informações, consulte [Visualizar resumos do painel de patches](patch-manager-view-dashboard-summaries.md).

**Topics**
+ [Como o Patch Manager beneficia minha organização?](#how-can-patch-manager-benefit-my-organization)
+ [Quem deve usar o Patch Manager?](#who-should-use-patch-manager)
+ [Quais são os principais recursos do Patch Manager?](#what-are-the-main-features-of-patch-manager)
+ [O que é conformidade no Patch Manager?](#patch-manager-definition-of-compliance)
+ [Componentes primários](#primary-components)
+ [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md)
+ [Pré-requisitos do Patch Manager](patch-manager-prerequisites.md)
+ [Como operações do Patch Manager funcionam](patch-manager-patching-operations.md)
+ [Documentos do comando do SSM para aplicação de patches em nós gerenciados](patch-manager-ssm-documents.md)
+ [Linhas de base de patch](patch-manager-patch-baselines.md)
+ [Usar o Kernel Live Patching em nós gerenciados do Amazon Linux 2](patch-manager-kernel-live-patching.md)
+ [Trabalhar com recursos e conformidade do Patch Manager usando o console](patch-manager-console.md)
+ [Trabalhar com recursos do Patch Manager usando a AWS CLI](patch-manager-cli-commands.md)
+ [Tutoriais do AWS Systems Manager Patch Manager](patch-manager-tutorials.md)
+ [Solução de problemas do Patch Manager](patch-manager-troubleshooting.md)

# Configurações de políticas de patches em Quick Setup
<a name="patch-manager-policies"></a>

A AWS recomenda o uso de *políticas de patch* para configurar a aplicação de patches para sua organização e Contas da AWS. As políticas de patch foram introduzidas no Patch Manager em dezembro de 2022. 

Uma política de patch é uma configuração que você define usando o Quick Setup, uma ferramenta do AWS Systems Manager. As políticas de patch fornecem um controle mais amplo e centralizado sobre suas operações de aplicação de patch do que o disponível com os métodos anteriores de configuração de patches. As políticas de patch podem ser usadas com [todos os sistemas operacionais com suporte pelo Patch Manager](patch-manager-prerequisites.md#pm-prereqs), incluindo versões do Linux, macOS, e Windows Server com suporte. Para obter instruções sobre como criar uma política de patches, consulte [Configurar a aplicação de patches para instâncias em uma organização usando uma política de patch do Quick Setup](quick-setup-patch-manager.md).

## Principais características das políticas de patch
<a name="patch-policies-about-major-features"></a>

Em vez de usar outros métodos para corrigir seus nós, use uma política de patch para aproveitar esses recursos principais:
+ **Configuração única**: a configuração de operações de aplicação de patches usando uma janela de manutenção ou uma associação do State Manager pode exigir várias tarefas em diferentes partes do console do Systems Manager. Usando uma política de patch, todas as suas operações de aplicação de patch podem ser configuradas em um único assistente.
+ **Suporte para várias contas/várias regiões**: usando uma janela de manutenção, uma associação do State Manager ou o recurso **Patch Now** do Patch Manager, você está limitado a visar nós gerenciados em um único par Conta da AWS-Região da AWS. Se você usa várias contas e várias regiões, suas tarefas de configuração e manutenção podem exigir muito tempo, pois você precisa executar tarefas de configuração em cada par conta-região. No entanto, se você usar o AWS Organizations, poderá configurar uma política de patch que se aplique a todos os seus nós gerenciados em todas as Regiões da AWS, em todas as suas Contas da AWS. Ou, se você preferir, uma política de patch pode ser aplicada somente a algumas unidades organizacionais (UOs) nas contas e regiões que você escolher. Uma política de patch também pode ser aplicada a uma única conta local, se você preferir.
+ **Suporte de instalação no nível organizacional**: a opção de configuração existente do Host Management em Quick Setup fornece suporte a uma verificação diária de seus nós gerenciados para verificar a conformidade dos patches. No entanto, essa verificação é feita em um horário predeterminado e resulta somente em informações de conformidade dos patches. Nenhuma instalação de patch é executada. Com uma política de patch, é possível especificar diferentes programações de verificação e instalação. Você também pode escolher a frequência e a hora dessas operações usando expressões personalizadas do CRON ou Rate. Por exemplo, é possível verificar todos os dias se há patches faltando, para fornecer informações de conformidade atualizadas regularmente. Porém, sua programação de instalação pode ser de apenas uma vez por semana, para evitar períodos de inatividade indesejados.
+ **Seleção simplificada da lista de referência de patches**: as políticas de patch ainda incorporam listas de referência de patches, e não há alterações na forma como as lista de referência de patches são configuradas. No entanto, ao criar ou atualizar uma política de patch, é possível selecionar a lista de referência gerenciada da AWS ou a personalizada que desejar usar para cada tipo de sistema operacional (SO) em uma única lista. Não é necessário especificar a lista de referência padrão para cada tipo de sistema operacional em tarefas separadas.

**nota**  
Quando as operações de aplicação de patch baseadas em uma política de patch são executadas, elas usam o documento SSM da `AWS-RunPatchBaseline`. Para obter mais informações, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

**Informações relacionadas**  
[Implante centralmente as operações de aplicação de patches em toda a sua organização da AWS usando o Quick Setup do Systems Manager](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/) (blog de operações e migrações para a nuvem da AWS)

## Outras diferenças com as políticas de patches
<a name="patch-policies-about-other-features"></a>

Aqui estão algumas outras diferenças a serem observadas ao usar as políticas de patch em vez de os métodos anteriores de configuração de patches:
+ **Não são necessários grupos de patches**: em operações de aplicação de patches anteriores, você podia marcar vários nós para pertencerem a um grupo de patches e, em seguida, especificar a lista de referência de patches a ser usada para esse grupo de patches. Se nenhum grupo de patches tivesse sido definido, o Patch Manager aplicaria patch nas instâncias com a lista de referência de patches padrão atual do tipo de sistema operacional. Usando políticas de patch, não é mais necessário configurar e manter grupos de patches. 
**nota**  
Não há suporte no console à funcionalidade de grupos de patches para pares de conta-região que ainda não usavam grupos de patches antes do lançamento do suporte à política de patches em 22 de dezembro de 2022. A funcionalidade de grupo de patches ainda está disponível em pares de conta-região que começaram a usar grupos de patches antes dessa data.
+ **Página “Configure patching” (Configurar a aplicação de patches) removida**: antes do lançamento das políticas de patch, você podia especificar padrões para quais nós aplicar patches, uma programação de patches e uma operação de aplicação de patches em uma página **Configure patching** (Configurar a aplicação de patches). Esta página foi removida do Patch Manager. Essas opções agora estão especificadas nas políticas de patch. 
+ **Sem suporte para “Patch Now”**: a capacidade de aplicar patches em nós sob demanda ainda está limitada a um único par Conta da AWS-Região da AWS por vez. Para mais informações, consulte [Aplicação de patches em nós gerenciados sob demanda](patch-manager-patch-now-on-demand.md).
+ **Políticas de patch e informações de conformidade**: quando seus nós gerenciados são varridos quanto à conformidade de acordo com uma configuração de política de aplicação de patches, os dados de conformidade são disponibilizados para você. É possível visualizar e trabalhar com os dados da mesma forma que com outros métodos de verificação de conformidade. Embora você possa configurar uma política de patch para uma organização inteira ou várias unidades organizacionais, as informações de conformidade são relatadas individualmente para cada par Conta da AWS-Região da AWS. Para obter mais informações, consulte [Trabalhando com relatórios de conformidade de patch](patch-manager-compliance-reports.md).
+ **Status de conformidade da associação e políticas de patch**: o status de patch de um nó gerenciado que está sob uma política de patch de Quick Setup corresponde ao status de execução da associação do State Manager para esse nó. Se o status de execução da associação for `Compliant`, o status de patch do nó gerenciado também será marcado como `Compliant`. Se o status de execução da associação for `Non-Compliant`, o status de patch do nó gerenciado também será marcado como `Non-Compliant`. 

## Regiões da AWS com suporte para políticas de patch
<a name="patch-policies-supported-regions"></a>

No momento, as configurações de política de patch do Quick Setup são compatíveis nas seguintes regiões:
+ Leste dos EUA (Ohio) (us-east-2)
+ Leste dos EUA (Norte da Virgínia) (us-east-1)
+ Oeste dos EUA (Norte da Califórnia) (us-west-1)
+ Oeste dos EUA (Oregon) (us-west-2)
+ Ásia-Pacífico (Mumbai) (ap-south-1)
+ Ásia-Pacífico (Seul) (ap-northeast-2)
+ Ásia-Pacífico (Singapura) (ap-southeast-1)
+ Ásia-Pacífico (Sydney) (ap-southeast-2)
+ Ásia Pacific (Tóquio) (ap-northeast-1)
+ Canadá (Central) (ca-central-1)
+ Europa (Frankfurt) (eu-central-1)
+ Europa (Irlanda) (eu-west-1)
+ Europa (Londres) (eu-west-2)
+ Europa (Paris) (eu-west-3)
+ UE (Estocolmo) (eu-north-1)
+ América do Sul (São Paulo) (sa-east-1)

# Pré-requisitos do Patch Manager
<a name="patch-manager-prerequisites"></a>

Certifique-se de ter atendido aos pré-requisitos necessários antes de usar o Patch Manager, uma ferramenta do AWS Systems Manager. 

**Topics**
+ [Versão do SSM Agent](#agent-versions)
+ [Versão do Python](#python-version)
+ [Requisitos de pacotes adicionais](#additional-package-requirements)
+ [Conectividade com a origem do patch](#source-connectivity)
+ [Acesso do endpoint do S3](#s3-endpoint-access)
+ [Permissões para instalar patches localmente](#local-installation-permissions)
+ [Sistemas operacionais compatíveis com o Patch Manager](#supported-os)

## Versão do SSM Agent
<a name="agent-versions"></a>

A versão 2.0.834.0 ou posterior do SSM Agent deve estar em execução nos nós gerenciados que você quiser gerenciar com o Patch Manager.

**nota**  
Uma versão atualizada do SSM Agent é lançada sempre que novas ferramentas são adicionadas ao Systems Manager ou sempre que atualizações são feitas nas ferramentas existentes. Deixar de usar a versão mais recente do atendente pode impedir que seu nó gerenciado use várias ferramentas do Systems Manager. Por isso, recomendamos automatizar o processo de manter o SSM Agent atualizado em suas máquinas. Para mais informações, consulte [Automatizar atualizações do SSM Agent](ssm-agent-automatic-updates.md). Inscreva-se na página [Notas de versão do SSM Agent](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) no GitHub para receber notificações sobre atualizações do SSM Agent.

## Versão do Python
<a name="python-version"></a>

Para o macOS e a maioria dos sistemas operacionais (SOs) Linux, o Patch Manager é atualmente compatível com o Python versões 2.6 - 3.12. Os sistemas operacionais AlmaLinux, Debian Server e Ubuntu Server exigem uma versão compatível do Python 3 (3.0 a 3.12).

## Requisitos de pacotes adicionais
<a name="additional-package-requirements"></a>

Para sistemas operacionais baseados em DNF, os utilitários `zstd`, `xz` e `unzip` podem ser necessários para descompactar as informações do repositório e os arquivos de patch. Os sistemas operacionais baseados em DNF incluem Amazon Linux 2023, Red Hat Enterprise Linux 8 e versões posteriores, Oracle Linux 8 e versões posteriores, Rocky Linux, AlmaLinux e CentOS 8 e versões posteriores. Se você vir erro semelhante a `No such file or directory: b'zstd'`, `No such file or directory: b'unxz'` ou falhas de correção devido à ausência de `unzip`, será necessário instalar esses utilitários. `zstd`, `xz` e `unzip` podem ser instalados executando o seguinte:

```
dnf install zstd xz unzip
```

## Conectividade com a origem do patch
<a name="source-connectivity"></a>

Se os nós gerenciados não tiverem uma conexão direta com a Internet e você estiver usando uma Amazon Virtual Private Cloud (Amazon VPC) com um endpoint da VPC, verifique se os nós têm acesso aos repositórios de patch de origem (repositórios). Em nós do Linux, as atualizações de patches normalmente são baixadas dos repositórios remotos configurados em seu nó. Portanto, o nó deve conseguir se conectar aos repositórios para que a aplicação do patch seja realizada. Para obter mais informações, consulte [Como os patches de segurança são selecionados](patch-manager-selecting-patches.md).

Ao corrigir um nó que está sendo executado em um ambiente somente IPv6, certifique-se de que o nó tenha conectividade com a origem do patch. Você pode verificar a saída Run Command da execução do patch para verificar se há avisos sobre repositórios inacessíveis. Para sistemas operacionais baseados em DNF, é possível configurar para que repositórios indisponíveis sejam ignorados durante a aplicação de patches se a opção `skip_if_unavailable` estiver definida como `True` em `/etc/dnf/dnf.conf`. Os sistemas operacionais baseados em DNF incluem Amazon Linux 2023, Red Hat Enterprise Linux 8 e versões posteriores, Oracle Linux 8 e versões posteriores, Rocky Linux, AlmaLinux e CentOS 8 e versões posteriores. No Amazon Linux 2023, a opção `skip_if_unavailable` é definida como `True` por padrão.

**CentOS Stream: ativar a bandeira `EnableNonSecurity`**  
Os nós do CentOS Stream usam o DNF como gerenciador de pacotes com o conceito de um aviso de atualização. Uma notificação de atualização é um conjunto de pacotes que corrige problemas específicos. 

No entanto, os repositórios padrão do CentOS Stream não são configurados com um aviso de atualização. Isso significa que o Patch Manager não detecta pacotes em repositórios padrão do CentOS Stream. Para permitir que o Patch Manager processe pacotes que não estão contidos em um aviso de atualização, você deve ativar o sinalizador `EnableNonSecurity` nas regras da lista de referência de patches.

**Windows Server: garanta a conectividade ao Windows Update Catalog ou ao Windows Server Update Services (WSUS)**  
Os nós gerenciados do Windows Server devem se conectar ao Windows Update Catalog ou ao Windows Server Update Services (WSUS). Confirme se os nós têm conectividade com o [Catálogo de atualizações da Microsoft](https://www.catalog.update.microsoft.com/home.aspx) por meio de um gateway da Internet, um gateway de NAT ou uma instância NAT. Se você estiver usando o WSUS, confirme se o nó tem conectividade com o servidor WSUS em seu ambiente. Para obter mais informações, consulte [Problema: o nó gerenciado não tem acesso ao Catálogo do Windows Update ou ao WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access).

## Acesso do endpoint do S3
<a name="s3-endpoint-access"></a>

Se os nós gerenciados operam em uma rede privada ou pública, sem acesso aos buckets do Amazon Simple Storage Service (Amazon S3) gerenciados pela AWS, as operações de aplicação de patches falham. Para obter informações sobre os buckets do S3 que os nós gerenciados devem poder acessar, consulte [SSM Agent Comunicações do AWS com os buckets do S3 gerenciados pela](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) e [Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager](setup-create-vpc.md).

## Permissões para instalar patches localmente
<a name="local-installation-permissions"></a>

Nos sistemas operacionais Windows Server e Linux, o Patch Manager assume as contas de administrador e usuário-raiz, respectivamente, para instalar os patches.

No entanto, para Brew e Brew Cask no macOS, o Homebrew não oferece suporte à execução de seus comandos sob o usuário-raiz. Como resultado, o Patch Manager consulta e executa comandos Homebrew como o proprietário do diretório Homebrew ou como um usuário válido pertencente ao grupo de proprietários do diretório Homebrew. Portanto, para instalar os patches, o proprietário do diretório `homebrew` também precisa de permissões recursivas para o diretório `/usr/local`.

**dica**  
O comando a seguir fornece essa permissão para o usuário especificado:  

```
sudo chown -R $USER:admin /usr/local
```

## Sistemas operacionais compatíveis com o Patch Manager
<a name="supported-os"></a>

A ferramenta Patch Manager pode não ser compatível com todas as versões de sistemas operacionais que são compatíveis com outras ferramentas do Systems Manager. (Para obter a lista completa de sistemas operacionais compatíveis com o Systems Manager, consulte [Sistemas operacionais compatíveis com o Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems).) Portanto, verifique se os nós gerenciados utilizados com o Patch Manager estão executando um dos sistemas operacionais listados na tabela a seguir.

**nota**  
O Patch Manager depende dos repositórios de patches configurados em um nó gerenciado, como o Catálogo do Windows Update e o Windows Server Update Services para Windows, para recuperar os patches disponíveis para instalação. Portanto, para versões de sistema operacional de fim de vida útil (EOL), se nenhuma nova atualização estiver disponível, o Patch Manager talvez não consiga relatar as novas atualizações. Isso pode ocorrer porque nenhuma nova atualização foi lançada pelo mantenedor da distribuição Linux, pela Microsoft ou pela Apple, ou porque o nó gerenciado não tem a licença adequada para acessar as novas atualizações.  
É altamente recomendável que você evite usar versões do sistema operacional que tenham atingido o fim da vida útil (EOL). Os fornecedores de sistemas operacionais, inclusive a AWS, normalmente não fornecem patches de segurança ou outras atualizações para versões que atingiram o EOL. Continuar usando um sistema EOL aumenta muito o risco de não conseguir aplicar atualizações, incluindo correções de segurança e outros problemas operacionais. A AWS não testa a funcionalidade do Systems Manager em versões do sistema operacional que atingiram o EOL.  
O Patch Manager relata o status de conformidade em relação aos patches disponíveis no nó gerenciado. Portanto, se uma instância estiver executando um sistema operacional em EOL e nenhuma atualização estiver disponível, o Patch Manager poderá relatar o nó como Em conformidade, dependendo das linhas de referência do patch configuradas para a operação de patch.


| Sistema operacional | Detalhes | 
| --- | --- | 
|  Linux  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-prerequisites.html)  | 
| macOS |  *macOS O é compatível somente com instâncias do Amazon EC2.* 13.0 – 13.7 (Ventura) 14*.x* (Sonoma) 15*.x* (Sequoia)  macOS atualizações do sistema operacional Patch Manager não oferece suporte a atualizações ou upgrades do sistema operacional (SO) macOS, como de 13.1 para 13.2. Para realizar atualizações de versão do sistema operacional macOS, recomendamos usar os mecanismos integrados de atualização do sistema operacional da Apple. Para obter mais informações, consulte [Gerenciamento de dispositivos](https://developer.apple.com/documentation/devicemanagement) no site da Apple Developer Documentation.   Suporte do Homebrew O Patch Manager requer que o Homebrew, o sistema de gerenciamento de pacotes de software de código aberto, seja instalado em um dos seguintes locais de instalação padrão:  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-prerequisites.html) As operações de aplicação de patches usando o Patch Manager não funcionam corretamente quando o Homebrew não está instalado.  Suporte de região Não há suporte para macOS em todas as Regiões da AWS. Para obter mais informações sobre o suporte a instâncias do EC2 para macOS, consulte [Instâncias Mac do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) no *Guia do usuário do Amazon EC2*.   macOS dispositivos de borda O SSM Agent para dispositivos principais do AWS IoT Greengrass não é compatível com o macOS. Você não pode usar o Patch Manager para aplicar patches aos dispositivos de borda do macOS.   | 
|  Windows  |  Windows Server 2012 a Windows Server 2025, incluindo versões R2.  O SSM Agent para dispositivos principais do AWS IoT Greengrass não é compatível com o Windows 10. Você não pode usar o Patch Manager para aplicar patches aos dispositivos de borda do Windows 10.   Suporte ao Windows Server 2012 e 2012 R2 O Windows Server 2012 e 2012 R2 atingiram o fim do suporte em 10 de outubro de 2023. Para usar o Patch Manager com essas versões, recomendamos também usar as Extended Security Updates (ESUs) da Microsoft. Para obter mais informações, consulte [Fim do suporte ao Windows Server 2012 e 2012 R2](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support) no site da Microsoft.   | 

# Como operações do Patch Manager funcionam
<a name="patch-manager-patching-operations"></a>

Esta seção fornece detalhes técnicos que explicam como o Patch Manager, uma ferramenta do AWS Systems Manager, define quais patches devem ser instalados e como ele os instala em cada sistema operacional compatível. Para sistemas operacionais Linux, ele também fornece informações sobre como especificar um repositório de origem, em uma lista personalizada de referência de patches, para patches diferentes do padrão configurado em um nó gerenciado. Esta seção também fornece detalhes sobre como as regras de linha de base de patch funcionam em diferentes distribuições do sistema operacional Linux.

**nota**  
As informações nos tópicos a seguir se aplicam independentemente do método ou tipo de configuração que você estiver usando para suas operações de aplicação de patch:  
Uma política de patch configurada no Quick Setup
Uma opção do Host Management configurada no Quick Setup
Uma janela de manutenção para executar um patch `Scan` ou tarefa `Install`
Uma operação **Patch now** (Aplicar patch agora) sob demanda

**Topics**
+ [Como as datas de lançamento e atualização de pacotes são calculadas](patch-manager-release-dates.md)
+ [Como os patches de segurança são selecionados](patch-manager-selecting-patches.md)
+ [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md)
+ [Como os patches são instalados](patch-manager-installing-patches.md)
+ [Como funcionam as regras de linha de base de patch em sistemas baseados no Linux](patch-manager-linux-rules.md)
+ [Principais diferenças entre a aplicação de patches em nós do Linux e em nós do Windows Server](patch-manager-windows-and-linux-differences.md)

# Como as datas de lançamento e atualização de pacotes são calculadas
<a name="patch-manager-release-dates"></a>

**Importante**  
As informações desta página se aplicam aos sistemas operacionais (SOs) Amazon Linux 2 e Amazon Linux 2023 para instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Os pacotes para esses tipos de SOs são criados e mantidos pela Amazon Web Services. A forma como os fabricantes de outros SOs gerenciam seus pacotes e repositórios afeta a forma como as datas de lançamento e de atualização deles são calculadas. Para sistemas operacionais além do Amazon Linux 2 e Amazon Linux 2023, como Red Hat Enterprise Linux, consulte a documentação do fabricante para obter informações sobre como os pacotes deles são atualizados e mantidos.

Nas configurações da [lista de referência de patches personalizada](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) que você cria, para a maioria dos tipos de SO, é possível especificar que os patches sejam aprovados automaticamente para instalação após um determinado número de dias. O AWS fornece várias listas de referência de patches predefinidas que incluem datas de aprovação automática de sete dias.

Um *atraso de aprovação automática* é o número de dias para aguardar após o lançamento do patch, antes que a aplicação do patch seja aprovada automaticamente. Por exemplo, você cria uma regra usando a classificação `CriticalUpdates` e a configura para um atraso de aprovação automática de 7 dias. Como resultado, um novo patch crítico com data de lançamento ou data da última atualização em 7 de julho será aprovado automaticamente em 14 de julho.

Para evitar resultados inesperados com atrasos na aprovação automática no Amazon Linux 2 e Amazon Linux 2023, é importante entender como as datas de lançamento e de atualização desses serviços são calculadas.

**nota**  
Se um repositório do Amazon Linux 2 ou Amazon Linux 2023 não fornecer informações de data de lançamento para pacotes, o Patch Manager usará o horário de compilação do pacote como a data para especificações de data de aprovação automática. Se o horário de compilação do pacote não puder ser determinado, o Patch Manager usa uma data padrão de 1º de janeiro de 1970. Isso resulta no Patch Manager ignorar quaisquer especificações de data de aprovação automática nas lista de referência de patches que estão configuradas para aprovar patches para qualquer data após 1º de janeiro de 1970.

Na maioria dos casos, o tempo de espera de aprovação automática antes da instalação dos patches é calculado com base em um valor `Updated Date` em `updateinfo.xml`, e não um valor `Release Date`. Veja a seguir detalhes importantes sobre esses cálculos de data: 
+ `Release Date` é a data de lançamento de uma *notificação*. Isso não significa que o pacote já esteja necessariamente disponível nos repositórios associados. 
+ `Update Date` é a última data em que a notificação foi atualizada. Uma atualização de uma notificação pode representar algo tão pequeno quanto uma atualização de texto ou descrição. Isso não significa que o pacote tenha sido liberado nessa data ou já esteja necessariamente disponível nos repositórios associados. 

  Isso significa que um pacote pode ter um valor `Update Date` de 7 de julho, mas não estará disponível para instalação até (p. ex.) 13 de julho. Nesse caso, suponha que uma lista de referência de patches que especifique um atraso de aprovação automática de 7 dias seja executada em uma operação `Install` em 14 de julho. Como o valor `Update Date` é de 7 dias antes da data de execução, os patches e atualizações no pacote serão instalados em 14 de julho. A instalação acontece mesmo que apenas 1 dia tenha passado desde que o pacote foi disponibilizado para instalação efetiva.
+ Um pacote contendo patches de sistema operacional ou aplicativo pode ser atualizado mais de uma vez após o lançamento inicial.
+ Um pacote pode ser lançado nos repositórios gerenciados da AWS e ser revertido se houver a descoberta de problemas posteriormente.

Em algumas operações de aplicação de patches, talvez esses fatores não sejam importantes. Por exemplo, se uma lista de referência de patches estiver configurada para instalar um patch com valores de severidade de `Low` e `Medium`, e uma classificação de `Recommended`, qualquer atraso na aprovação automática pode ter pouco impacto em suas operações.

No entanto, em casos nos quais o tempo de patches críticos ou de alta severidade é mais importante, pode ser necessário que você exerça mais controle sobre quando os patches são instalados. O método recomendado para fazer isso é usar repositórios alternativos de origem de patch em vez dos repositórios padrão para operações de patch em um nó gerenciado. 

Você pode especificar os repositórios de origem de patches alternativos ao criar uma linha de base de patch personalizada. Em cada linha de base de patch personalizada, você pode especificar as configurações de origem de patches para até 20 versões de um sistema operacional Linux compatível. Para obter mais informações, consulte [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md).

# Como os patches de segurança são selecionados
<a name="patch-manager-selecting-patches"></a>

O foco principal do Patch Manager, uma ferramenta do AWS Systems Manager, é instalar as atualizações relacionadas à segurança de sistemas operacionais nos nós gerenciados. Por padrão, o Patch Manager não instala todos os patches disponíveis, mas sim um conjunto menor de patches relacionados à segurança.

Por padrão, o Patch Manager não substitui um pacote que foi marcado como obsoleto em um repositório de pacotes por pacotes de substituição de nome diferente, a menos que essa substituição seja necessário pela instalação de outra atualização de pacote. Em vez disso, para comandos que atualizam um pacote, o Patch Manager somente informa e instala atualizações ausentes do pacote instalado, mas obsoleto. Isso porque a substituição de um pacote obsoleto normalmente exige a desinstalação de um pacote existente e a instalação do substituto. A substituição do pacote obsoleto pode introduzir alterações de impacto ou funcionalidades adicionais não pretendidas.

Esse comportamento é consistente com o comando `update-minimal` do YUM e DNF, cujo foco está em atualizações de segurança em vez de em atualizações de recursos. Para obter mais informações, consulte [Como os patches são instalados](patch-manager-installing-patches.md).

**nota**  
Quando você usa o parâmetro `ApproveUntilDate` ou `ApproveAfterDays` em uma regra de lista de referência de patches, o Patch Manager avalia as datas de lançamento do patch usando o Tempo Universal Coordenado (UTC).   
Por exemplo, para `ApproveUntilDate`, se você especificar uma data como `2025-11-16`, os patches lançados entre `2025-11-16T00:00:00Z` e `2025-11-16T23:59:59Z` serão aprovados.   
Lembre-se de que as datas de lançamento de patches exibidas pelos gerenciadores de pacotes nativos em seus nós gerenciados podem mostrar horários diferentes com base no fuso horário local do seu sistema, mas o Patch Manager sempre usa a data e hora UTC para cálculos de aprovação. Isso garante a consistência com as datas de lançamento dos patches publicadas nos sites oficiais de consultorias de segurança.

Para tipos de sistema operacional baseados em Linux que relatem um nível de gravidade para patches, o Patch Manager usa o nível de gravidade relatado pelo editor do software para o aviso de atualização ou patch individual. O Patch Manager não deriva níveis de gravidade de fontes de terceiros, como o [Sistema comum de pontuação de vulnerabilidades](https://www.first.org/cvss/) (CVSS), ou a partir de métricas lançadas pelo [Banco de dados nacional de vulnerabilidades](https://nvd.nist.gov/vuln) (NVD).

**nota**  
Em todos os sistemas baseados em Linux com os quais o Patch Manager é compatível, você pode escolher um outro repositório de origem configurado para o nó gerenciado, normalmente para instalar atualizações não relacionadas a segurança. Para mais informações, consulte [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md).

Escolha uma das guias a seguir para saber como o Patch Manager seleciona patches de segurança para o sistema operacional.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

O Amazon Linux 2 lida com repositórios pré-configurados de modo diferente do Amazon Linux 2023.

No Amazon Linux 2, o serviço de lista de referência de patches do Systems Manager usa repositórios pré-configurados em seu nó gerenciado. Há dois repositórios pré-configurados (repos) em um nó:

**No Amazon Linux 2**
+ **ID do repositório**: `amzn2-core/2/architecture`

  **Nome do repositório**: `Amazon Linux 2 core repository`
+ **ID do repositório**: `amzn2extra-docker/2/architecture`

  **Nome do repositório**: `Amazon Extras repo for docker`

**nota**  
*arquitetura* pode ser x86\$164 ou (para processadores Graviton) aarch64.

Quando você cria uma instância do Amazon Linux 2023 (AL2023), ela contém as atualizações que estavam disponíveis na versão do AL2023 e na AMI específica que você selecionou. A instância do AL2023 não recebe automaticamente outras atualizações de segurança críticas e importantes durante a inicialização. Em vez disso, com o recurso de *atualizações determinísticas por meio de repositórios versionados* compatível com o AL2023, o qual está ativado por padrão, é possível aplicar atualizações com base em uma programação que atenda às suas necessidades específicas. Para obter mais informações, consulte [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) no *Amazon Linux 2023 User Guide*. 

No AL2023, o repositório pré-configurado é o seguinte:
+ **ID do repositório**: `amazonlinux`

  **Nome do repositório**: repositório do Amazon Linux 2023

No Amazon Linux 2023 (versão de pré-visualização), os repositórios pré-configurados estão vinculados a *versões vinculadas* de atualizações de pacotes. Quando novas Amazon Machine Images (AMIs) para o AL2023 são lançadas, elas são vinculadas a uma versão específica. Para atualizações de patches, o Patch Manager recupera a versão vinculada mais recente do repositório de atualizações de patches e, em seguida, atualiza os pacotes no nó gerenciado com base no conteúdo dessa versão vinculada.

**Gerenciadores de pacotes**  
Os nós gerenciados do Amazon Linux 2 usam o Yum como gerenciador de pacotes. O Amazon Linux 2023 usa o DNF como gerenciador de pacotes. 

Os gerenciadores de pacotes usam o conceito de um *aviso de atualização* como um arquivo denominado `updateinfo.xml`. Uma notificação de atualização é um conjunto de pacotes que corrige problemas específicos. Todos os pacotes que estão em um aviso de atualização são considerados de segurança pelo Patch Manager. Pacotes individuais não recebem classificações ou níveis de gravidade. Por esse motivo, o Patch Manager designa os atributos de um aviso de atualização aos pacotes relacionados.

**nota**  
Se você marcar a caixa de seleção **Incluir atualizações não relacionadas a segurança** na página **Criar lista de referência de patch**, os pacotes não classificados em um arquivo `updateinfo.xml` (ou um pacote que contenha um arquivo sem valores de classificação, gravidade e data devidamente formatados) poderão ser incluídos na lista de patches pré-filtrada. No entanto, para que um patch seja aplicado, ele ainda deve atender às regras de linha de base de patch especificadas pelo usuário.  
Para obter mais informações sobre a opção **Incluir atualizações não relacionadas à segurança**, consulte [Como os patches são instalados](patch-manager-installing-patches.md) e [Como funcionam as regras de linha de base de patch em sistemas baseados no Linux](patch-manager-linux-rules.md).

------
#### [  CentOS Stream ]

No CentOS Stream, o serviço de lista de referência de patches do Systems Manager usa repositórios (repos) pré-configurados em seu nó gerenciado. A lista a seguir fornece exemplos para uma Amazon Machine Image (AMI) do CentOS 9.2 fictícia:
+ **ID do repositório**: `example-centos-9.2-base`

  **Nome do repositório**: `Example CentOS-9.2 - Base`
+ **ID do repositório**: `example-centos-9.2-extras` 

  **Nome do repositório**: `Example CentOS-9.2 - Extras`
+ **ID do repositório**: `example-centos-9.2-updates`

  **Nome do repositório**: `Example CentOS-9.2 - Updates`
+ **ID do repositório**: `example-centos-9.x-examplerepo`

  **Nome do repositório**: `Example CentOS-9.x – Example Repo Packages`

**nota**  
Todas as atualizações são obtidas por download dos repositórios remotos configurados em seu nó gerenciado. Portanto, o nó deve ter acesso de saída à Internet para se conectar aos repositórios para que a aplicação do patch seja realizada.

Os nós do CentOS Stream usam o DNF como gerenciador de pacotes. O gerenciador de pacotes usa o conceito de um aviso de atualização. Uma notificação de atualização é um conjunto de pacotes que corrige problemas específicos. 

No entanto, os repositórios padrão do CentOS Stream não são configurados com um aviso de atualização. Isso significa que o Patch Manager não detecta pacotes em repositórios padrão do CentOS Stream. Para permitir que o Patch Manager processe pacotes que não estão contidos em um aviso de atualização, você deve ativar o sinalizador `EnableNonSecurity` nas regras da lista de referência de patches.

**nota**  
As notificações de atualização do CentOS Stream são suportadas. Os repositórios com notificações de atualização podem ser obtidos por download após a inicialização.

------
#### [ Debian Server ]

No Debian Server, o serviço de lista de referência de patches do Systems Manager usa repositórios (repos) pré-configurados na instância. Esses repos pré-configurados são usados para obter uma lista das atualizações de pacote disponíveis. Para isso, o Systems Manager executa um comando equivalente a `sudo apt-get update`. 

Os pacotes são então filtrados dos repositórios `debian-security codename`. Isso significa que, em cada versão do Debian Server, o Patch Manager identifica apenas as atualizações que fazem parte do repositório associado a essa versão, da seguinte forma:
+  Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`

------
#### [ Oracle Linux ]

No Oracle Linux, o serviço de lista de referência de patches do Systems Manager usa repositórios (repos) pré-configurados em seu nó gerenciado. Há normalmente dois repositórios pré-configurados (repositórios) em um nó.

**Oracle Linux 7**:
+ **ID do repositório**: `ol7_UEKR5/x86_64`

  **Nome do repositório**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **ID do repositório**: `ol7_latest/x86_64`

  **Nome do repositório**: `Oracle Linux 7Server Latest (x86_64)` 

**Oracle Linux 8**:
+ **ID do repositório**: `ol8_baseos_latest` 

  **Nome do repositório**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **ID do repositório**: `ol8_appstream`

  **Nome do repositório**: `Oracle Linux 8 Application Stream (x86_64)` 
+ **ID do repositório**: `ol8_UEKR6`

  **Nome do repositório**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`

**Oracle Linux 9**:
+ **ID do repositório**: `ol9_baseos_latest` 

  **Nome do repositório**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **ID do repositório**: `ol9_appstream`

  **Nome do repositório**: `Oracle Linux 9 Application Stream Packages(x86_64)` 
+ **ID do repositório**: `ol9_UEKR7`

  **Nome do repositório**: `Oracle Linux UEK Release 7 (x86_64)`

**nota**  
Todas as atualizações são obtidas por download dos repositórios remotos configurados em seu nó gerenciado. Portanto, o nó deve ter acesso de saída à Internet para se conectar aos repositórios para que a aplicação do patch seja realizada.

Oracle Linux Os nós gerenciados do usam o Yum como gerenciador de pacotes, e o Yum usa o conceito de uma notificação de atualização como um arquivo chamado `updateinfo.xml`. Uma notificação de atualização é um conjunto de pacotes que corrige problemas específicos. Pacotes individuais não recebem classificações ou níveis de gravidade. Por essa razão, o Patch Manager designa os atributos de um aviso de atualização aos pacotes relacionados e instala pacotes com base nos filtros de classificação especificados na lista de referência do patch.

**nota**  
Se você marcar a caixa de seleção **Incluir atualizações não relacionadas a segurança** na página **Criar lista de referência de patch**, os pacotes não classificados em um arquivo `updateinfo.xml` (ou um pacote que contenha um arquivo sem valores de classificação, gravidade e data devidamente formatados) poderão ser incluídos na lista de patches pré-filtrada. No entanto, para que um patch seja aplicado, ele ainda deve atender às regras de linha de base de patch especificadas pelo usuário.

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

No AlmaLinux, no Red Hat Enterprise Linux e no Rocky Linux, o serviço de lista de referência de patches do Systems Manager usa repositórios (repos) pré-configurados em seu nó gerenciado. Há normalmente três repositórios pré-configurados (repos) em um nó.

Todas as atualizações são obtidas por download dos repositórios remotos configurados em seu nó gerenciado. Portanto, o nó deve ter acesso de saída à Internet para se conectar aos repositórios para que a aplicação do patch seja realizada.

**nota**  
Se você marcar a caixa de seleção **Incluir atualizações não relacionadas a segurança** na página **Criar lista de referência de patch**, os pacotes não classificados em um arquivo `updateinfo.xml` (ou um pacote que contenha um arquivo sem valores de classificação, gravidade e data devidamente formatados) poderão ser incluídos na lista de patches pré-filtrada. No entanto, para que um patch seja aplicado, ele ainda deve atender às regras de linha de base de patch especificadas pelo usuário.

Os nós gerenciados do Red Hat Enterprise Linux 7 usam o Yum como gerenciador de pacotes. O AlmaLinux, o Red Hat Enterprise Linux 8 e os nós gerenciados do Rocky Linux usam o DNF como o gerenciador de pacotes. Os gerenciadores de pacotes usam o conceito de um aviso de atualização como um arquivo denominado `updateinfo.xml`. Uma notificação de atualização é um conjunto de pacotes que corrige problemas específicos. Pacotes individuais não recebem classificações ou níveis de gravidade. Por essa razão, o Patch Manager designa os atributos de um aviso de atualização aos pacotes relacionados e instala pacotes com base nos filtros de classificação especificados na lista de referência do patch.

RHEL 7  
Os IDs de repo a seguir estão associados ao RHUI 2. O RHUI 3 foi lançado em dezembro de 2019 e apresentou um esquema de nomenclatura diferente para IDs do repositório Yum. Dependendo da AMI do RHEL-7 na qual você cria os nós gerenciados, talvez seja necessário atualizar os comandos. Para obter mais informações, consulte [Repository IDs for RHEL 7 in AWS Have Changed](https://access.redhat.com/articles/4599971) no *Red Hat Customer Portal*.
+ **ID do repositório**: `rhui-REGION-client-config-server-7/x86_64`

  **Nome do repositório**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **ID do repositório**: `rhui-REGION-rhel-server-releases/7Server/x86_64`

  **Nome do repositório**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **ID do repositório**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`

  **Nome do repositório**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`

AlmaLinux, 8 RHEL 8 e Rocky Linux 8  
+ **ID do repositório**: `rhel-8-appstream-rhui-rpms`

  **Nome do repositório**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **ID do repositório**: `rhel-8-baseos-rhui-rpms`

  **Nome do repositório**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **ID do repositório**: `rhui-client-config-server-8`

  **Nome do repositório**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`

AlmaLinux 9, RHEL 9 e Rocky Linux 9  
+ **ID do repositório**: `rhel-9-appstream-rhui-rpms`

  **Nome do repositório**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **ID do repositório**: `rhel-9-baseos-rhui-rpms`

  **Nome do repositório**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **ID do repositório**: `rhui-client-config-server-9`

  **Nome do repositório**: `Red Hat Enterprise Linux 9 Client Configuration`

------
#### [ SLES ]

Nas instâncias do SUSE Linux Enterprise Server (SLES), a biblioteca do ZYPP obtém a lista de patches disponíveis (um conjunto de pacotes) dos seguintes locais:
+ Lista de repositórios: `etc/zypp/repos.d/*`
+ Informações do pacote: `/var/cache/zypp/raw/*`

SLESOs nós gerenciados do usam o Zypper como gerenciador de pacotes, e o Zypper usa o conceito de um patch. Um patch é um conjunto de pacotes que corrige um problema específico. O Patch Manager lida com todos os pacotes referenciados em um patch como relacionados à segurança. Como pacotes individuais não recebem classificações ou níveis de gravidade, o Patch Manager atribui aos pacotes os atributos do patch ao qual eles pertencem.

------
#### [ Ubuntu Server ]

No Ubuntu Server, o serviço de lista de referência de patches do Systems Manager usa repositórios (repos) pré-configurados em seu nó gerenciado. Esses repos pré-configurados são usados para obter uma lista das atualizações de pacote disponíveis. Para isso, o Systems Manager executa um comando equivalente a `sudo apt-get update`. 

Os pacotes são então filtrados dos repositórios `codename-security`, onde codename é exclusivo da versão do lançamento, como `trusty` para Ubuntu Server 14. O Patch Manager identifica apenas upgrades que são parte desses repositórios: 
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)

------
#### [ Windows Server ]

Em sistemas operacionais Microsoft Windows, o Patch Manager recupera uma lista de atualizações disponíveis que a Microsoft publica no Microsoft Update e são disponibilizadas automaticamente para o Windows Server Update Services (WSUS).

**nota**  
O Patch Manager apenas disponibiliza patches para versões de sistemas operacionais Windows Server compatíveis com o Patch Manager. Por exemplo, o Patch Manager não pode ser usado para aplicar patches ao Windows RT.

Patch Manager O monitora continuamente as novas atualizações em cada Região da AWS. A lista de atualizações do disponíveis em cada região é atualizada pelo menos uma vez por dia. Quando as informações de patch da Microsoft são processadas, o Patch Manager remove da sua lista de patches as atualizações que foram substituídas por atualizações posteriores. Portanto, apenas a atualização mais recente é exibida e disponibilizada para instalação. Por exemplo, se `KB4012214` substituir `KB3135456`, somente o `KB4012214` será disponibilizado como atualização no Patch Manager.

Da mesma forma, o Patch Manager pode instalar somente os patches que estão disponíveis no nó gerenciado durante o período da operação de patch. Por padrão, o Windows Server 2019 e o Windows Server 2022 removem atualizações que são substituídas por atualizações posteriores. Como resultado, se você usar o parâmetro `ApproveUntilDate` em uma lista de referência de patches Windows Server, mas a data selecionada no parâmetro `ApproveUntilDate` for *anterior* à data do patch mais recente, ocorrerá o seguinte cenário:
+ O patch substituído é removido do nó e, portanto, não pode ser instalado usando o Patch Manager.
+ O patch de substituição mais recente está presente no nó, mas ainda não foi aprovado para instalação na data especificada pelo parâmetro `ApproveUntilDate`. 

Isso significa que o nó gerenciado é compatível em termos de operações do Systems Manager, mesmo que um patch crítico do mês anterior possa não ter sido instalado. Esse mesmo cenário pode ocorrer ao usar o parâmetro `ApproveAfterDays`. Devido ao comportamento do patch substituído pela Microsoft, é possível definir um número (geralmente maior que 30 dias) para que os patches do Windows Server nunca sejam instalados se o patch mais recente disponível da Microsoft for lançado antes de o número de dias em `ApproveAfterDays` tiver passado. Observe que esse comportamento do sistema não se aplica se você tiver modificado as configurações do Objeto de Política de Grupo (GPO) do Windows para disponibilizar o patch substituído nos nós gerenciados.

**nota**  
Em alguns casos, a Microsoft lança patches para aplicações que não especificam data e hora atualizadas. Nesses casos, uma data e hora atualizadas de `01/01/1970` são fornecidas por padrão.

------

# Como especificar um repositório de origem de patches alternativo (Linux)
<a name="patch-manager-alternative-source-repository"></a>

Ao usar os repositórios padrão configurados em um nó gerenciado para operações de aplicação de patch, o Patch Manager, uma ferramenta do AWS Systems Manager, verifica ou instala patches relacionados à segurança. Esse é o comportamento padrão do Patch Manager. Para obter informações completas sobre como o Patch Manager seleciona e instala patches de segurança, consulte [Como os patches de segurança são selecionados](patch-manager-selecting-patches.md).

Em sistemas Linux, no entanto, você também pode usar o Patch Manager para instalar patches que não são relacionados à segurança ou que estão em um repositório de origem diferente do padrão configurado em seu nó gerenciado. Você pode especificar os repositórios de origem de patches alternativos ao criar uma linha de base de patch personalizada. Em cada linha de base de patch personalizada, você pode especificar as configurações de origem de patches para até 20 versões de um sistema operacional Linux compatível. 

Por exemplo, suponha que a sua frota Ubuntu Server inclua nós gerenciados do Ubuntu Server 25.04. Nesse caso, você pode especificar os repositórios alternativo para cada versão na mesma linha de base de patch personalizada. Para cada versão, insira um nome, especifique o tipo de versão do sistema operacional (produto) e forneça uma configuração do repositório. Você também pode especificar um único repositório de origem alternativo que se aplica a todas as versões de um sistema operacional compatível.

**nota**  
Executar uma linha personalizada de referência de patches, que especifica repositórios de patches alternativos para um nó gerenciado, não torna esses repositórios o novo padrão no sistema operacional. Após a conclusão da operação de patch, os repositórios previamente configurados como padrão para o sistema operacional do nó permanecerão como padrão.

Para obter uma lista de exemplos de situações para usar essa opção, consulte [Exemplos de uso de repositórios de origem de patches alternativos](#patch-manager-alternative-source-repository-examples) mais adiante neste tópico.

Para obter informações sobre linhas de base de patch padrão e personalizadas, consulte [Listas de referência de patches predefinidas e personalizadas](patch-manager-predefined-and-custom-patch-baselines.md).

**Exemplo: usar o console**  
Para especificar repositórios de origem de patches alternativos quando você está trabalhando no console do Systems Manager, use a seção **Patch sources** (Origens de patches) na página **Create patch baseline** (Criar linha de base de patch). Para obter informações sobre como usar as opções de **Fontes de patch**, consulte [Criar uma lista de referência de patches personalizada para o Linux](patch-manager-create-a-patch-baseline-for-linux.md).

**Exemplos: usar a AWS CLI**  
Para obter um exemplo do uso da opção `--sources` com a AWS Command Line Interface (AWS CLI), consulte [Criar uma linha de base de patch com repositórios personalizados para diferentes versões do SO](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).

**Topics**
+ [Considerações importantes para repositórios alternativos](#alt-source-repository-important)
+ [Exemplos de uso de repositórios de origem de patches alternativos](#patch-manager-alternative-source-repository-examples)

## Considerações importantes para repositórios alternativos
<a name="alt-source-repository-important"></a>

Tenha em mente os seguintes pontos ao planejar a estratégia de patches usando alternativas de repositórios de patch.

**Aplique verificações de atualização do repositório (YUM e DNF)**  
Uma configuração padrão para um gerenciador de pacotes em uma distribuição Linux pode ser definida para ignorar um repositório de pacotes inacessível se a conexão com o repositório não puder ser estabelecida. Para impor a verificação da atualização do repositório, adicione `skip_if_unavailable=False` à configuração do repositório.

Para obter mais informações sobre a opção `skip_if_available`, consulte [Conectividade com a origem do patch](patch-manager-prerequisites.md#source-connectivity).

**Somente repositórios especificados são usados para a aplicação de patches**  
Especificar repositórios alternativos não significa especificar repositórios *adicionais*. Você pode optar por especificar repositórios que não sejam os configurados como padrão em um nó gerenciado. No entanto, você também deve especificar os repositórios padrão como parte da configuração de origem de patch alternativo se você deseja que as atualizações sejam aplicadas.

Por exemplo, em nós gerenciados do Amazon Linux 2, os repositórios padrão são `amzn2-core` e `amzn2extra-docker`. Se você deseja incluir o repositório Extra Packages for Enterprise Linux (EPEL) em suas operações de patch, deve especificar os três repositórios como repositórios alternativos.

**nota**  
Executar uma linha personalizada de referência de patches, que especifica repositórios de patches alternativos para um nó gerenciado, não torna esses repositórios o novo padrão no sistema operacional. Após a conclusão da operação de patch, os repositórios previamente configurados como padrão para o sistema operacional do nó permanecerão como padrão.

**O comportamento de patches para distribuições com base em YUM depende do manifesto updateinfo.xml**  
Quando você especifica repositórios alternativos de patch para distribuições com base em YUM, como Amazon Linux 2 ou Red Hat Enterprise Linux, o comportamento de patches depende de o repositório incluir ou não uma atualização manifesto na forma de um arquivo `updateinfo.xml` completo e formatado corretamente. Esse arquivo especifica a data de lançamento, classificações e gravidades dos vários pacotes. Qualquer um dos seguintes afetará o comportamento de patch:
+ Se você filtrar **Classificação** e **Gravidade**, mas eles não estiverem especificados em `updateinfo.xml`, o pacote não será incluído pelo filtro. Isso também significa que os pacotes sem um arquivo `updateinfo.xml` não serão incluídos no patch.
+ Se você filtrar **ApprovalAfterDays**, mas a data de liberação do pacote não estiver no formato Unix Epoch (ou não tiver data de liberação especificada), o pacote não será incluído pelo filtro.
+ Há uma exceção se você selecionar a caixa de seleção **Incluir atualizações não relacionadas a segurança** na página **Criar linha de base de patch**. Nesse caso, os pacotes sem um arquivo `updateinfo.xml` (ou que contenham esse arquivo sem valores propriamente formatados de **Classificação**, **Gravidade** e **Data**) *serão* incluídos na lista de patches pré-filtrados. (Eles ainda deverão corresponder aos outros requisitos de regras de linha de base de patch para serem instalados.)

## Exemplos de uso de repositórios de origem de patches alternativos
<a name="patch-manager-alternative-source-repository-examples"></a>

**Exemplo 1 - Atualizações não de segurança para o Ubuntu Server**  
Você já está usando o Patch Manager para instalar patches de segurança em uma frota de nós gerenciados do Ubuntu Server usando a lista de referência de patches `AWS-UbuntuDefaultPatchBaseline` predefinida fornecida pela AWS. Você pode criar uma nova linha de base de patch baseada nesse padrão, mas especifique nas regras de aprovação que você deseja que as atualizações não relacionadas à segurança que fazem parte da distribuição padrão sejam instaladas também. Quando essa lista de referência de patches é executada em nós, os patches para problemas relacionados ou não a segurança são aplicados. Você também pode optar por aprovar patches não relacionados a segurança nas exceções de patches que você especifica para uma linha de base.

**Exemplo 2 – Personal Package Archives (PPA) para o Ubuntu Server**  
As instâncias do Ubuntu Server estão executando o software que é distribuído por meio de um [Personal Package Archives (PPA) para Ubuntu](https://launchpad.net/ubuntu/+ppas). Nesse caso, crie uma lista de referência de patches que especifique um repositório PPA que você configurou em seu nó gerenciado como repositório de origem para a operação de aplicação de patch. Em seguida, use o Run Command para executar o documento da lista de referência de patches em seus nós.

**Exemplo 3: aplicações corporativas internas nas versões compatíveis do Amazon Linux**  
Você deve executar algumas aplicações necessárias para a conformidade regulatória do setor nos nós gerenciados do Amazon Linux. Você pode configurar um repositório para essas aplicações em nós, usar o YUM inicialmente para instalar as aplicações e, em seguida, atualizar ou criar uma nova lista de referência de patches para incluir esse novo repositório corporativo. Depois disso, você pode usar o Run Command para executar o documento `AWS-RunPatchBaseline` com a opção `Scan` para conferir se o pacote corporativo está listado entre os pacotes instalados e está atualizado dentro do nó gerenciado. Se ele não estiver atualizado, você pode executar o documento novamente usando a opção `Install` para atualizar os aplicativos. 

# Como os patches são instalados
<a name="patch-manager-installing-patches"></a>

O Patch Manager, uma ferramenta do AWS Systems Manager, usa o gerenciador de pacotes integrado do sistema operacional para instalar atualizações nos nós gerenciados. Por exemplo, ele usa a API do Windows Update no Windows Server e no `DNF` no Amazon Linux 2023. O Patch Manager respeita as configurações existentes do gerenciador de pacotes e do repositório nos nós, incluindo configurações como status do repositório, URLs espelhados, verificação de GPG e opções como `skip_if_unavailable`.

O Patch Manager não instala um novo pacote que substitui um pacote obsoleto atualmente instalado. (Exceções: o novo pacote depende da instalação de outro pacote que está sendo atualizado, ou o novo pacote possui o mesmo nome do pacote obsoleto.) Em vez disso, o Patch Manager informa e instala as atualizações disponíveis para os pacotes que estão instalados. Essa abordagem ajuda a impedir alterações inesperadas na funcionalidade do sistema que podem ocorrer ao substituir um pacote por outro.

Se for necessário desinstalar um pacote que se tornou obsoleto e instalar um substituto, pode ser necessário que você utilize um script personalizado ou comandos do gerenciador de pacotes fora das operações padrão do Patch Manager.

Escolha uma das guias a seguir para saber como o Patch Manager instala patches em um sistema operacional.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

Em nós gerenciados do Amazon Linux 2 e Amazon Linux 2023, o fluxo de trabalho de instalação de patches ocorre da seguinte maneira:

1. Se uma lista de patches for especificada usando um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3), que usa o parâmetro do `InstallOverrideList` para os documentos `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`, os patches listados serão instalados e as de etapas de 2 a 7 serão ignoradas.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) conforme especificado na lista de referência de patches, mantendo apenas os pacotes qualificados para processamento adicional. 

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conforme especificado na lista de referência de patches. Cada regra de aprovação pode definir um pacote como aprovado.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. 

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) conforme especificado na lista de referência de patches. Os patches aprovados têm aprovação para atualizar, mesmo que sejam descartados por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou mesmo que nenhuma regra de aprovação especificada em [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conceda a aprovação.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) conforme especificado na lista de referência de patches. Os patches rejeitados são removidos da lista de patches aprovados e não serão aplicados.

1. Se várias versões de um patch forem aprovadas, a versão mais recente será aplicada.

1. A API de atualização do YUM (Amazon Linux 2) ou a API de atualização do DNF (Amazon Linux 2023) é aplicada aos patches aprovados da seguinte maneira:
   + Para linhas de base de patch padrão predefinidas fornecidas pela AWS, somente os patches especificados em `updateinfo.xml` são aplicados (apenas atualizações de segurança). Isso acontece porque a caixa de seleção **Incluir atualizações não relacionadas a segurança** não está marcada. As linhas de base predefinidas são equivalentes a uma linha de base personalizada com o seguinte:
     + A caixa de seleção **Incluir atualizações não relacionadas a segurança** não está marcada
     + Uma lista de GRAVIDADE de `[Critical, Important]`
     + Uma lista de CLASSIFICAÇÃO de `[Security, Bugfix]`

     No Amazon Linux 2, o comando yum equivalente para esse fluxo de trabalho é:

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     No Amazon Linux 2023, o comando dnf equivalente para esse fluxo de trabalho é:

     ```
     sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```

     Se a caixa de seleção **Incluir atualizações não relacionadas a segurança** estiver marcada, os patches em `updateinfo.xml` e fora de `updateinfo.xml` serão todos aplicados (atualizações de segurança e não relacionadas a segurança).

     Para o Amazon Linux 2, se uma linha de base com **Incluir atualizações não relacionadas a segurança** for selecionada, tiver uma lista de GRAVIDADE de `[Critical, Important]` e uma lista de CLASSIFICAÇÃO de `[Security, Bugfix]`, o comando yum equivalente será:

     ```
     sudo yum update --security --sec-severity=Critical,Important --bugfix -y
     ```

     No Amazon Linux 2023, o comando dnf equivalente é:

     ```
     sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```
**nota**  
Novos pacotes que substituem pacotes que se tornaram obsoletos com nomes diferentes serão instalados se os seguintes comandos `yum` ou `dnf` forem executados fora do Patch Manager. Porém, eles *não* são instalados por meio de operações do Patch Manager equivalentes.

**Detalhes adicionais de patches para Amazon Linux 2023**  
Suporte ao nível de gravidade "Nenhuma"  
O Amazon Linux 2023 também é compatível com o nível de gravidade de patch `None`, que é reconhecido pelo gerenciador de pacotes DNF.   
Suporte ao nível de gravidade "Média"  
No Amazon Linux 2023,, um nível de gravidade de patch `Medium` é equivalente a uma gravidade `Moderate` que pode ser definida em alguns repositórios externos. Se você incluir patches de gravidade `Medium` na linha lista de referência de patches, os patches de gravidade `Moderate` dos patches externos também serão instalados nas instâncias.  
Quando você consulta dados de conformidade usando a ação de API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html), a filtragem para o nível de gravidade `Medium` informa patches com ambos os níveis de gravidade `Medium` e `Moderate`.  
Tratamento de dependências transitivas para Amazon Linux 2023  
No Amazon Linux 2023, o Patch Manager pode instalar versões de dependências transitivas das instaladas pelos comandos `dnf` equivalentes. Dependências transitivas são pacotes que são instalados automaticamente para satisfazer os requisitos de outros pacotes (dependências de dependências).   
Por exemplo, o `dnf upgrade-minimal --security` instala as versões *mínimas* das dependências transitivas necessárias para resolver problemas de segurança conhecidos, enquanto o Patch Manager instala as versões **mais recentes disponíveis das mesmas dependências transitivas.

1. O nó gerenciado será reinicializado se todas as atualizações forem instaladas. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**nota**  
Uma configuração padrão para um gerenciador de pacotes em uma distribuição Linux pode ser definida para ignorar um repositório de pacotes inacessível sem erro. Nesses casos, a operação de correção relacionada prossegue sem instalar atualizações do repositório e é concluída com sucesso. Para impor as atualizações do repositório, adicione `skip_if_unavailable=False` à configuração do repositório.  
Para obter mais informações sobre a opção `skip_if_available`, consulte [Conectividade com a origem do patch](patch-manager-prerequisites.md#source-connectivity).

------
#### [ CentOS Stream ]

Em nós gerenciados do CentOS Stream, o fluxo de trabalho da instalação de patches é o seguinte:

1. Se uma lista de patches for especificada usando um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3), que usa o parâmetro do `InstallOverrideList` para os documentos `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`, os patches listados serão instalados e as de etapas de 2 a 7 serão ignoradas.

   Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) conforme especificado na lista de referência de patches, mantendo apenas os pacotes qualificados para processamento adicional. 

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conforme especificado na lista de referência de patches. Cada regra de aprovação pode definir um pacote como aprovado.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. 

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) conforme especificado na lista de referência de patches. Os patches aprovados têm aprovação para atualizar, mesmo que sejam descartados por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou mesmo que nenhuma regra de aprovação especificada em [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conceda a aprovação.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) conforme especificado na lista de referência de patches. Os patches rejeitados são removidos da lista de patches aprovados e não serão aplicados.

1. Se várias versões de um patch forem aprovadas, a versão mais recente será aplicada.

1. A atualização de DNF no CentOS Stream é aplicada aos patches aprovados. 
**nota**  
Para o CentOS Stream, o Patch Manager pode instalar versões de dependências transitivas diferentes das instaladas pelos comandos `dnf` equivalentes. Dependências transitivas são pacotes que são instalados automaticamente para satisfazer os requisitos de outros pacotes (dependências de dependências).   
Por exemplo, o `dnf upgrade-minimal ‐‐security` instala as versões *mínimas* das dependências transitivas necessárias para resolver problemas de segurança conhecidos, enquanto o Patch Manager instala as *versões mais recentes disponíveis* das mesmas dependências transitivas.

1. O nó gerenciado será reinicializado se todas as atualizações forem instaladas. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Debian Server ]

Em instâncias do Debian Server, o fluxo de trabalho de instalação de patches é como o seguinte:

1. Se uma lista de patches for especificada usando um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3), que usa o parâmetro do `InstallOverrideList` para os documentos `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`, os patches listados serão instalados e as de etapas de 2 a 7 serão ignoradas.

1. Se uma atualização estiver disponível para o `python3-apt` (uma interface de biblioteca Python para `libapt`), ela será atualizada para a versão mais recente. (Este pacote não relacionado à segurança é atualizado mesmo se você não selecionou a opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança)).

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) conforme especificado na lista de referência de patches, mantendo apenas os pacotes qualificados para processamento adicional. 

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conforme especificado na lista de referência de patches. Cada regra de aprovação pode definir um pacote como aprovado. 
**nota**  
Como não é possível determinar de forma confiável as datas de lançamento dos pacotes de atualização do Debian Server, as opções de aprovação automática não são compatíveis com esse sistema operacional.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. 

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.
**nota**  
Para Debian Server, as versões candidatas de patch são limitadas a patches incluídos no `debian-security`.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) conforme especificado na lista de referência de patches. Os patches aprovados têm aprovação para atualizar, mesmo que sejam descartados por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou mesmo que nenhuma regra de aprovação especificada em [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conceda a aprovação.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) conforme especificado na lista de referência de patches. Os patches rejeitados são removidos da lista de patches aprovados e não serão aplicados.

1. A biblioteca de APT é usada para atualizar pacotes.
**nota**  
O Patch Manager não oferece suporte ao uso da opção `Pin-Priority` de APT para atribuir prioridades aos pacotes. O Patch Manager agrega as atualizações disponíveis de todos os repositórios habilitados e seleciona a atualização mais recente que corresponde à lista de referência de cada pacote instalado.

1. O nó gerenciado será reinicializado se todas as atualizações forem instaladas. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ macOS ]

Em nós gerenciados do macOS, o fluxo de trabalho da instalação de patches é o seguinte:

1. O`/Library/Receipts/InstallHistory.plist`é um registro de software que foi instalado e atualizado usando o`softwareupdate`e`installer`Gerenciadores de pacotes. Usar o`pkgutil`ferramenta de linha de comando (para`installer`) e o`softwareupdate`, os comandos da CLI são executados para analisar esta lista. 

   Para o `installer`, a resposta aos comandos da CLI inclui `package name`, `version`, `volume`, `location` e `install-time`, mas apenas o `package name` e a `version` serão usados pelo Patch Manager.

   Para o `softwareupdate`, a resposta aos comandos da CLI inclui o nome do pacote (`display name`), `version` e `date`, mas apenas o nome e a versão do pacote são usados pelo Patch Manager.

   Para Brew e Brew Cask, o Homebrew não suporta seus comandos rodando sob o usuário raiz. Como resultado, o Patch Manager consulta e executa comandos Homebrew como o proprietário do diretório Homebrew ou como um usuário válido pertencente ao grupo de proprietários do diretório Homebrew. Os comandos são semelhantes a`softwareupdate`e`installer`e são executados por meio de um subprocesso Python para coletar dados de pacotes, e a saída é analisada para identificar nomes e versões de pacotes.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) conforme especificado na lista de referência de patches, mantendo apenas os pacotes qualificados para processamento adicional. 

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conforme especificado na lista de referência de patches. Cada regra de aprovação pode definir um pacote como aprovado.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) conforme especificado na lista de referência de patches. Os patches aprovados têm aprovação para atualizar, mesmo que sejam descartados por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou mesmo que nenhuma regra de aprovação especificada em [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conceda a aprovação.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) conforme especificado na lista de referência de patches. Os patches rejeitados são removidos da lista de patches aprovados e não serão aplicados.

1. Se várias versões de um patch forem aprovadas, a versão mais recente será aplicada.

1. Invoca a CLI de pacote apropriada em seu nó gerenciado para processar patches aprovados da seguinte maneira:
**nota**  
`installer`O não tem a funcionalidade para verificar e instalar atualizações. Portanto, para o `installer`, o Patch Manager somente informa quais pacotes estão instalados. Como resultado, os pacotes do `installer` nunca são relatados como `Missing`.
   + Para listas de referência de patches padrão predefinidas fornecidas pela AWS e para linhas de base de patch personalizadas em que a caixa de seleção **Incluir atualizações não relacionadas a segurança** *não* está marcada, somente atualizações de segurança são aplicadas.
   + Para listas de referência de patches personalizadas em que a caixa de seleção **Incluir atualizações não relacionadas a segurança** *estiver* selecionada, tanto as atualizações de segurança quanto as não relacionadas a segurança se aplicarão.

1. O nó gerenciado será reinicializado se todas as atualizações forem instaladas. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Oracle Linux ]

Em nós gerenciados do Oracle Linux, o fluxo de trabalho da instalação de patches é o seguinte:

1. Se uma lista de patches for especificada usando um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3), que usa o parâmetro do `InstallOverrideList` para os documentos `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`, os patches listados serão instalados e as de etapas de 2 a 7 serão ignoradas.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) conforme especificado na lista de referência de patches, mantendo apenas os pacotes qualificados para processamento adicional. 

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conforme especificado na lista de referência de patches. Cada regra de aprovação pode definir um pacote como aprovado.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. 

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) conforme especificado na lista de referência de patches. Os patches aprovados têm aprovação para atualizar, mesmo que sejam descartados por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou mesmo que nenhuma regra de aprovação especificada em [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conceda a aprovação.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) conforme especificado na lista de referência de patches. Os patches rejeitados são removidos da lista de patches aprovados e não serão aplicados.

1. Se várias versões de um patch forem aprovadas, a versão mais recente será aplicada.

1. Em nós gerenciados da versão 7, a API da atualização do YUM é aplicada a patches aprovados, da seguinte maneira:
   + Para linhas de base de patch padrão predefinidas fornecidas pela AWS e para linhas de base de patch personalizadas em que a caixa de seleção **Incluir atualizações não relacionadas a segurança** *não* está marcada, somente os patches especificados em `updateinfo.xml` são aplicados (somente atualizações de segurança).

     O comando equivalente do yum para esse fluxo de trabalho é:

     ```
     sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
     ```
   + Para linhas de base de patch personalizadas em que a opção **Incluir atualizações não relacionadas a segurança** *está* selecionada, ambos os patches no `updateinfo.xml` e os que não estão no `updateinfo.xml` são aplicados (atualizações de segurança e não relacionadas a segurança).

     O comando equivalente do yum para esse fluxo de trabalho é:

     ```
     sudo yum update --security --bugfix -y
     ```

     Em nós gerenciados da versão 8 e 9, a API da atualização do DNF é aplicada a patches aprovados, da seguinte maneira:
     + Para linhas de base de patch padrão predefinidas fornecidas pela AWS e para linhas de base de patch personalizadas em que a caixa de seleção **Incluir atualizações não relacionadas a segurança** *não* está marcada, somente os patches especificados em `updateinfo.xml` são aplicados (somente atualizações de segurança).

       O comando equivalente do yum para esse fluxo de trabalho é:

       ```
       sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
       ```
**nota**  
No Oracle Linux, o Patch Manager pode instalar versões de dependências transitivas das instaladas pelos comandos `dnf` equivalentes. Dependências transitivas são pacotes que são instalados automaticamente para satisfazer os requisitos de outros pacotes (dependências de dependências).   
Por exemplo, o `dnf upgrade-minimal --security` instala as versões *mínimas* das dependências transitivas necessárias para resolver problemas de segurança conhecidos, enquanto o Patch Manager instala as *versões mais recentes disponíveis* das mesmas dependências transitivas.
     + Para linhas de base de patch personalizadas em que a opção **Incluir atualizações não relacionadas a segurança** *está* selecionada, ambos os patches no `updateinfo.xml` e os que não estão no `updateinfo.xml` são aplicados (atualizações de segurança e não relacionadas a segurança).

       O comando equivalente do yum para esse fluxo de trabalho é:

       ```
       sudo dnf upgrade --security --bugfix
       ```
**nota**  
Novos pacotes que substituem pacotes que se tornaram obsoletos com nomes diferentes serão instalados se os seguintes comandos `yum` ou `dnf` forem executados fora do Patch Manager. Porém, eles *não* são instalados por meio de operações do Patch Manager equivalentes.

1. O nó gerenciado será reinicializado se todas as atualizações forem instaladas. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**nota**  
Uma configuração padrão para um gerenciador de pacotes em uma distribuição Linux pode ser definida para ignorar um repositório de pacotes inacessível sem erro. Nesses casos, a operação de correção relacionada prossegue sem instalar atualizações do repositório e é concluída com sucesso. Para impor as atualizações do repositório, adicione `skip_if_unavailable=False` à configuração do repositório.  
Para obter mais informações sobre a opção `skip_if_available`, consulte [Conectividade com a origem do patch](patch-manager-prerequisites.md#source-connectivity).

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

Em nós gerenciados do AlmaLinux, do Red Hat Enterprise Linux e do Rocky Linux, o fluxo de trabalho da instalação de patches é este:

1. Se uma lista de patches for especificada usando um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3), que usa o parâmetro do `InstallOverrideList` para os documentos `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`, os patches listados serão instalados e as de etapas de 2 a 7 serão ignoradas.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) conforme especificado na lista de referência de patches, mantendo apenas os pacotes qualificados para processamento adicional. 

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conforme especificado na lista de referência de patches. Cada regra de aprovação pode definir um pacote como aprovado.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. 

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) conforme especificado na lista de referência de patches. Os patches aprovados têm aprovação para atualizar, mesmo que sejam descartados por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou mesmo que nenhuma regra de aprovação especificada em [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conceda a aprovação.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) conforme especificado na lista de referência de patches. Os patches rejeitados são removidos da lista de patches aprovados e não serão aplicados.

1. Se várias versões de um patch forem aprovadas, a versão mais recente será aplicada.

1. A API de atualização do YUM (no RHEL 7) ou a API de atualização do DNF (no AlmaLinux 8 e 9, no RHEL 8, 9 e 10 e no Rocky Linux 8 e 9) é aplicada a patches aprovados da seguinte forma:

    

**Cenário 1: atualizações não relacionadas à segurança excluídas**
   + **Aplica-se a**: listas de referência de patches padrão predefinidas fornecidas pela AWS e listas de referência de patches personalizadas.
   + Caixa de seleção **Incluir atualizações não relacionadas à segurança**: *não* está marcada.
   + **Patches aplicados**: os patches especificados em `updateinfo.xml` (somente atualizações de segurança) serão aplicados *apenas* se ambos corresponderem à configuração da lista de referência de patches e forem encontrados nos repositórios configurados.

     Em alguns casos, um patch especificado em `updateinfo.xml` pode não estar mais disponível em um repositório configurado. Os repositórios configurados geralmente têm apenas a versão mais recente de um patch, que é um acúmulo de todas as atualizações anteriores, mas a versão mais recente pode não corresponder às regras da lista de referência de patches e ser omitida da operação de aplicação de patches.
   + **Comandos**: no RHEL 7, o comando yum equivalente para esse fluxo de trabalho é: 

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     Para o AlmaLinux, o RHEL 8 e o Rocky Linux, os comandos dnf equivalentes para o fluxo de trabalho são:

     ```
     sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
     sudo dnf update-minimal --sec-severity=Important --bugfix -y
     ```
**nota**  
No Alma Linux, RHEL e Rocky LinuxRocky Linux, o Patch Manager pode instalar versões de dependências transitivas das instaladas pelos comandos `dnf` equivalentes. Dependências transitivas são pacotes que são instalados automaticamente para satisfazer os requisitos de outros pacotes (dependências de dependências).   
Por exemplo, o `dnf upgrade-minimal --security` instala as versões *mínimas* das dependências transitivas necessárias para resolver problemas de segurança conhecidos, enquanto o Patch Manager instala as *versões mais recentes disponíveis* das mesmas dependências transitivas.

**Cenário 2: atualizações não relacionadas à segurança incluídas**
   + **Aplica-se a**: listas de referência de patches personalizadas.
   + Caixa de seleção **Incluir atualizações não relacionadas à segurança**: marcada.
   + **Patches aplicados**: os patches em `updateinfo.xml` *e* os que não estão em `updateinfo.xml` são aplicados (atualizações de segurança e não relacionadas à segurança).
   + **Comandos**: no RHEL 7, o comando yum equivalente para esse fluxo de trabalho é:

     ```
     sudo yum update --security --bugfix -y
     ```

     No AlmaLinux 8 e 9, no RHEL 8 e 9 e no Rocky Linux 8 e 9, o comando dnf equivalente para esse fluxo de trabalho é:

     ```
     sudo dnf update --security --bugfix -y
     ```
**nota**  
Novos pacotes que substituem pacotes que se tornaram obsoletos com nomes diferentes serão instalados se os seguintes comandos `yum` ou `dnf` forem executados fora do Patch Manager. Porém, eles *não* são instalados por meio de operações do Patch Manager equivalentes.

1. O nó gerenciado será reinicializado se todas as atualizações forem instaladas. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**nota**  
Uma configuração padrão para um gerenciador de pacotes em uma distribuição Linux pode ser definida para ignorar um repositório de pacotes inacessível sem erro. Nesses casos, a operação de correção relacionada prossegue sem instalar atualizações do repositório e é concluída com sucesso. Para impor as atualizações do repositório, adicione `skip_if_unavailable=False` à configuração do repositório.  
Para obter mais informações sobre a opção `skip_if_available`, consulte [Conectividade com a origem do patch](patch-manager-prerequisites.md#source-connectivity).

------
#### [ SLES ]

Em nós gerenciados do SUSE Linux Enterprise Server (SLES), o fluxo de trabalho da instalação de patches é o seguinte:

1. Se uma lista de patches for especificada usando um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3), que usa o parâmetro do `InstallOverrideList` para os documentos `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`, os patches listados serão instalados e as de etapas de 2 a 7 serão ignoradas.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) conforme especificado na lista de referência de patches, mantendo apenas os pacotes qualificados para processamento adicional. 

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conforme especificado na lista de referência de patches. Cada regra de aprovação pode definir um pacote como aprovado.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. 

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) conforme especificado na lista de referência de patches. Os patches aprovados têm aprovação para atualizar, mesmo que sejam descartados por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou mesmo que nenhuma regra de aprovação especificada em [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conceda a aprovação.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) conforme especificado na lista de referência de patches. Os patches rejeitados são removidos da lista de patches aprovados e não serão aplicados.

1. Se várias versões de um patch forem aprovadas, a versão mais recente será aplicada.

1. A API de atualização do Zypper é aplicada a patches aprovados.

1. O nó gerenciado será reinicializado se todas as atualizações forem instaladas. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Ubuntu Server ]

Em nós gerenciados do Ubuntu Server, o fluxo de trabalho da instalação de patches é o seguinte:

1. Se uma lista de patches for especificada usando um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3), que usa o parâmetro do `InstallOverrideList` para os documentos `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`, os patches listados serão instalados e as de etapas de 2 a 7 serão ignoradas.

1. Se uma atualização estiver disponível para o `python3-apt` (uma interface de biblioteca Python para `libapt`), ela será atualizada para a versão mais recente. (Este pacote não relacionado à segurança é atualizado mesmo se você não selecionou a opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança)).

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) conforme especificado na lista de referência de patches, mantendo apenas os pacotes qualificados para processamento adicional. 

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conforme especificado na lista de referência de patches. Cada regra de aprovação pode definir um pacote como aprovado. 
**nota**  
Como não é possível determinar de forma confiável as datas de lançamento dos pacotes de atualização do Ubuntu Server, as opções de aprovação automática não são compatíveis com esse sistema operacional.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. 

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.
**nota**  
Para cada versão do Ubuntu Server, as versões candidatas a patches são limitadas aos patches que fazem parte do repositório associado a essa versão, da seguinte forma:  
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS): `focal-security`
Ubuntu Server 22.04 LTS: `jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) conforme especificado na lista de referência de patches. Os patches aprovados têm aprovação para atualizar, mesmo que sejam descartados por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou mesmo que nenhuma regra de aprovação especificada em [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) conceda a aprovação.

1. Aplique o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) conforme especificado na lista de referência de patches. Os patches rejeitados são removidos da lista de patches aprovados e não serão aplicados.

1. A biblioteca de APT é usada para atualizar pacotes.
**nota**  
O Patch Manager não oferece suporte ao uso da opção `Pin-Priority` de APT para atribuir prioridades aos pacotes. O Patch Manager agrega as atualizações disponíveis de todos os repositórios habilitados e seleciona a atualização mais recente que corresponde à lista de referência de cada pacote instalado.

1. O nó gerenciado será reinicializado se todas as atualizações forem instaladas. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Windows Server ]

Quando uma operação de aplicação de patch é executada em um nó gerenciado do Windows Server, o nó solicita um snapshot da lista de referência de patches apropriada no Systems Manager. Esse snapshot contém a lista de todas as atualizações disponíveis na linha de base de patch que foram aprovadas para implantação. Essa lista de atualizações é enviada à API do Windows Update, que determina quais das atualizações são aplicáveis ao nó gerenciado e os instala conforme necessário. O Windows permite que somente a versão mais recente disponível de um KB seja instalada. O Patch Manager instala a versão mais recente de um KB quando ele, ou qualquer versão anterior do KB, corresponde à lista de referência de patches aplicada. Se todas as atualizações forem instaladas, o nó gerenciado será reinicializado posteriormente quantas vezes for preciso para concluir todas as correções necessárias. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)). O resumo da operação de patch pode ser encontrado na saída da solicitação do Run Command. Os logs adicionais podem ser encontrados em seu nó gerenciado da pasta `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`.

Como a API do Windows Update é usada para fazer download e instalar KBs, todas as configurações de política de grupo para Windows Update são respeitadas. Nenhuma configuração de política de grupo é necessária para usar o Patch Manager, mas todas as configurações definidas serão aplicadas, como para direcionar nós gerenciados para um servidor WSUS (Windows Server Update Services).

**nota**  
Por padrão, o Windows baixa todas as KBs do site do Microsoft Windows Update porque o Patch Manager usa a API do Windows Update para conduzir o download e a instalação de KBs. Por isso, o nó gerenciado precisa acessar o site de atualização do Microsoft Windows Update, caso contrário, a aplicação de patches falhará. Uma alternativa é configurar um servidor WSUS para servir como repositório de KBs e configurar os nós gerenciados para direcionar esse WSUS, em vez de usar políticas de grupo.  
O Patch Manager pode fazer referência a IDs de KB ao criar listas de referência de patches personalizadas para Windows Server, por exemplo, quando uma lista de **Patches aprovados** ou uma lista de **Patches rejeitados** é incluída na configuração da lista de referência. Somente as atualizações que recebem um ID de KB no Microsoft Windows Update ou em um servidor WSUS são instaladas pelo Patch Manager. Atualizações sem ID de KB não são incluídas nas operações de aplicação de patches.   
Para obter mais informações sobre a criação de listas de referência de patches personalizadas, consulte os seguintes tópicos:  
 [Criar uma lista de referência de patches personalizada para o Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
 [Criar uma lista de referência de patches (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Formatos de nomes de pacotes para sistemas operacionais Windows](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)

------

# Como funcionam as regras de linha de base de patch em sistemas baseados no Linux
<a name="patch-manager-linux-rules"></a>

As regras na linha de base de patch para distribuições do Linux funcionam de forma diferente dependendo do tipo de distribuição. Ao contrário das atualizações de patch em nós gerenciados do Windows Server, as regras são avaliadas em cada nó para levar em conta os repositórios configurados na instância. O Patch Manager, uma ferramenta do AWS Systems Manager, usa o gerenciador de pacotes nativo para conduzir a instalação de patches aprovados pela lista de referência de patches.

Para tipos de sistema operacional baseados em Linux que relatem um nível de gravidade para patches, o Patch Manager usa o nível de gravidade relatado pelo editor do software para o aviso de atualização ou patch individual. O Patch Manager não deriva níveis de gravidade de fontes de terceiros, como o [Sistema comum de pontuação de vulnerabilidades](https://www.first.org/cvss/) (CVSS), ou a partir de métricas lançadas pelo [Banco de dados nacional de vulnerabilidades](https://nvd.nist.gov/vuln) (NVD).

**Topics**
+ [Como funcionam as regras de lista de referência de patches no Amazon Linux 2 e no Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Como as regras de lista de referência de patches funcionam no CentOS Stream](#linux-rules-centos)
+ [Como as regras de lista de referência de patches funcionam no Debian Server](#linux-rules-debian)
+ [Como as regras de lista de referência de patches funcionam no macOS](#linux-rules-macos)
+ [Como as regras de lista de referência de patches funcionam no Oracle Linux](#linux-rules-oracle)
+ [Como as regras de lista de referência de patches funcionam no AlmaLinux, no RHEL e no Rocky Linux](#linux-rules-rhel)
+ [Como as regras de lista de referência de patches funcionam no SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Como as regras de lista de referência de patches funcionam no Ubuntu Server](#linux-rules-ubuntu)

## Como funcionam as regras de lista de referência de patches no Amazon Linux 2 e no Amazon Linux 2023
<a name="linux-rules-amazon-linux"></a>

**nota**  
O Amazon Linux 2023 (AL2023) usa repositórios versionados que podem ser bloqueados em uma versão específica por meio de uma ou mais configurações do sistema. Para todas as operações de aplicação de patches nas instâncias do EC2 AL2023, o Patch Manager usa as versões mais recentes do repositório, independentemente da configuração do sistema. Para obter mais informações, consulte [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) no *Amazon Linux 2023 User Guide*.

Em instâncias do Amazon Linux 2 e do Amazon Linux 2023, o processo de seleção de patches é o seguinte:

1. No nó gerenciado, a biblioteca do YUM (Amazon Linux 2) ou a biblioteca do DNF (Amazon Linux 2023) acessa o arquivo `updateinfo.xml` para cada repositório configurado. 

   Se nenhum arquivo `updateinfo.xml` for encontrado, a instalação dos patches depende das configurações de **Incluir atualizações não relacionadas a segurança** e **Autoaprovação**. Por exemplo, se forem permitidas atualizações não relacionadas à segurança, elas serão instaladas quando o tempo de autoaprovação chegar.

1. Toda notificação de atualização em `updateinfo.xml` inclui vários atributos que denotam as propriedades dos pacotes na notificação, tal como descrito na tabela a seguir.  
**Atributos de notificação de atualização**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).

1. O produto do nó gerenciado é determinado pelo SSM Agent. Esse atributo corresponde ao valor do atributo de chave do [ProdutoPatchFilter no tipo de dados ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) da linha de base de patch.

1. Os pacotes são selecionados para a atualização de acordo com as seguintes diretrizes:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obter informações sobre valores de status de conformidade de patches, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md).

## Como as regras de lista de referência de patches funcionam no CentOS Stream
<a name="linux-rules-centos"></a>

Os repositórios padrão do CentOS Stream não incluem um arquivo `updateinfo.xml`. No entanto, os repositórios personalizados criados ou usados por você podem incluir esse arquivo. Neste tópico, referências a `updateinfo.xml` se aplicam somente a esses repositórios personalizados.

No CentOS Stream, o processo de seleção de patches é como o seguinte:

1. Em um nó gerenciado, a biblioteca do DNF acessa o arquivo `updateinfo.xml`, se ele existir em um repositório personalizado, para cada repositório configurado.

   Se nenhum `updateinfo.xml` for encontrado, o que sempre inclui o repositório padrão, a instalação dos patches depende das configurações de **Incluir atualizações não relacionadas a segurança** e **Autoaprovação**. Por exemplo, se forem permitidas atualizações não relacionadas à segurança, elas serão instaladas quando o tempo de autoaprovação chegar.

1. Se `updateinfo.xml` estiver presente, toda notificação de atualização no arquivo incluirá vários atributos que denotam as propriedades dos pacotes na notificação, tal como descrito na tabela a seguir.  
**Atributos de notificação de atualização**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).

1. Em todos os casos, o produto do nó gerenciado é determinado pelo SSM Agent. Esse atributo corresponde ao valor do atributo de chave do [ProdutoPatchFilter no tipo de dados ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) da linha de base de patch.

1. Os pacotes são selecionados para a atualização de acordo com as seguintes diretrizes:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obter informações sobre valores de status de conformidade de patches, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md).

## Como as regras de lista de referência de patches funcionam no Debian Server
<a name="linux-rules-debian"></a>

No Debian Server, o serviço de lista de referência de patches oferece filtragem nos campos *Prioridade* e *Seção*. Esses campos geralmente estão presentes em todos os pacotes do Debian Server. Para determinar se um patch é selecionado pela lista de referência de patches, o Patch Manager faz o seguinte:

1. Em sistemas Debian Server, o equivalente a `sudo apt-get update` é executado para atualizar a lista de pacotes disponíveis. Os repos não são configurados e os dados são extraídas dos repos configurados em uma lista `sources`.

1. Se uma atualização estiver disponível para o `python3-apt` (uma interface de biblioteca Python para `libapt`), ela será atualizada para a versão mais recente. (Este pacote não relacionado à segurança é atualizado mesmo se você não selecionou a opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança)).

1. Em seguida, as listas [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) e [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) são aplicadas.
**nota**  
Como não é possível determinar de forma confiável as datas de lançamento dos pacotes de atualização do Debian Server, as opções de aprovação automática não são compatíveis com esse sistema operacional.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. Neste caso, para o Debian Server, versões candidatas de patch são limitadas a patches incluídos nos seguintes repositórios:

   Esses repositórios são nomeados da seguinte forma:
   + Debian Server 11: `debian-security bullseye`
   + Debian Server 12: `debian-security bookworm`

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.

   Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).

Para visualizar o conteúdo dos campos *Priority* e *Section *, execute o comando `aptitude` a seguir: 

**nota**  
Pode ser necessário primeiro instalar o Aptitude nos sistemas Debian Server.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

Em resposta a esse comando, todos os pacotes atualizáveis são relatados no seguinte formato: 

```
name, priority, section, archive, candidate version
```

Para obter informações sobre valores de status de conformidade de patches, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md).

## Como as regras de lista de referência de patches funcionam no macOS
<a name="linux-rules-macos"></a>

No macOS, o processo de seleção de patches é como o seguinte:

1. Em um nó gerenciado, o Patch Manager acessa o conteúdo analisado do `InstallHistory.plist` e identifica nomes e versões de pacotes. 

   Para obter detalhes sobre o processo de análise, consulte a guia **macOS**em [Como os patches são instalados](patch-manager-installing-patches.md).

1. O produto do nó gerenciado é determinado pelo SSM Agent. Esse atributo corresponde ao valor do atributo de chave do [ProdutoPatchFilter no tipo de dados ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) da linha de base de patch.

1. Os pacotes são selecionados para a atualização de acordo com as seguintes diretrizes:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obter informações sobre valores de status de conformidade de patches, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md).

## Como as regras de lista de referência de patches funcionam no Oracle Linux
<a name="linux-rules-oracle"></a>

No Oracle Linux, o processo de seleção de patches é como o seguinte:

1. Em um nó gerenciado, a biblioteca do YUM acessa o arquivo `updateinfo.xml` para cada repositório configurado.
**nota**  
O arquivo `updateinfo.xml` talvez não esteja disponível se o repo não for gerenciado pela Oracle. Se nenhum `updateinfo.xml` for encontrado, a instalação dos patches depende das configurações de **Incluir atualizações não relacionadas a segurança** e **Autoaprovação**. Por exemplo, se forem permitidas atualizações não relacionadas à segurança, elas serão instaladas quando o tempo de autoaprovação chegar.

1. Toda notificação de atualização em `updateinfo.xml` inclui vários atributos que denotam as propriedades dos pacotes na notificação, tal como descrito na tabela a seguir.  
**Atributos de notificação de atualização**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).

1. O produto do nó gerenciado é determinado pelo SSM Agent. Esse atributo corresponde ao valor do atributo de chave do [ProdutoPatchFilter no tipo de dados ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) da linha de base de patch.

1. Os pacotes são selecionados para a atualização de acordo com as seguintes diretrizes:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obter informações sobre valores de status de conformidade de patches, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md).

## Como as regras de lista de referência de patches funcionam no AlmaLinux, no RHEL e no Rocky Linux
<a name="linux-rules-rhel"></a>

No AlmaLinux, no Red Hat Enterprise Linux (RHEL) e no Rocky Linux, o processo de seleção de patches é o seguinte:

1. Em um nó gerenciado, a biblioteca do YUM (RHEL 7) ou a biblioteca do DNF (AlmaLinux 8 e 9, RHEL 8, 9 e 10 e Rocky Linux 8 e 9) acessa o arquivo `updateinfo.xml` para cada repositório configurado.
**nota**  
O arquivo `updateinfo.xml` talvez não esteja disponível se o repo não for gerenciado pela Red Hat. Se não for encontrado nenhum `updateinfo.xml`, nenhum patch será aplicado.

1. Toda notificação de atualização em `updateinfo.xml` inclui vários atributos que denotam as propriedades dos pacotes na notificação, tal como descrito na tabela a seguir.  
**Atributos de notificação de atualização**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).

1. O produto do nó gerenciado é determinado pelo SSM Agent. Esse atributo corresponde ao valor do atributo de chave do [ProdutoPatchFilter no tipo de dados ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) da linha de base de patch.

1. Os pacotes são selecionados para a atualização de acordo com as seguintes diretrizes:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obter informações sobre valores de status de conformidade de patches, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md).

## Como as regras de lista de referência de patches funcionam no SUSE Linux Enterprise Server
<a name="linux-rules-sles"></a>

No SLES, cada patch inclui os atributos a seguir, que identificam as propriedades dos pacotes no patch:
+ **Categoria**: corresponde ao valor do atributo de chave de **Classificação** no tipo de dados [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) da lista de referência de patches. Denota o tipo de patch incluso na notificação de atualização.

  Você pode exibir a lista de valores compatíveis usando o comando da AWS CLI, **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)**, ou a operação **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** da API. Você também pode visualizar a lista na área **Approval rules** (Regras de aprovação) da página **Create patch baseline** (Criar lista de referência do patch) ou da página **Edit patch baseline** (Editar lista de referência do patch) no console do Systems Manager.
+ **Gravidade**: corresponde ao valor do atributo de chave de **gravidade** no tipo de dados [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) da lista de referência de patches. Indica o nível de severidade dos patches.

  Você pode exibir a lista de valores compatíveis usando o comando da AWS CLI, **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)**, ou a operação **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** da API. Você também pode visualizar a lista na área **Approval rules** (Regras de aprovação) da página **Create patch baseline** (Criar lista de referência do patch) ou da página **Edit patch baseline** (Editar lista de referência do patch) no console do Systems Manager.

O produto do nó gerenciado é determinado pelo SSM Agent. Esse atributo corresponde ao valor do atributo de chave do **Produto** no tipo de dados [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) da lista de referência de patches. 

Para cada patch, a linha de base de patch é usada como filtro, permitindo que somente os pacotes qualificados sejam incluídos na atualização. Se vários pacotes forem aplicáveis depois de aplicar a definição da linha de base de patch, será usada a versão mais recente. 

Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).

## Como as regras de lista de referência de patches funcionam no Ubuntu Server
<a name="linux-rules-ubuntu"></a>

No Ubuntu Server, o serviço de lista de referência de patches oferece filtragem nos campos *Prioridade* e *Seção*. Esses campos geralmente estão presentes em todos os pacotes do Ubuntu Server. Para determinar se um patch é selecionado pela lista de referência de patches, o Patch Manager faz o seguinte:

1. Em sistemas Ubuntu Server, o equivalente a `sudo apt-get update` é executado para atualizar a lista de pacotes disponíveis. Os repos não são configurados e os dados são extraídas dos repos configurados em uma lista `sources`.

1. Se uma atualização estiver disponível para o `python3-apt` (uma interface de biblioteca Python para `libapt`), ela será atualizada para a versão mais recente. (Este pacote não relacionado à segurança é atualizado mesmo se você não selecionou a opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança)).

1. Em seguida, as listas [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) e [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) são aplicadas.
**nota**  
Como não é possível determinar de forma confiável as datas de lançamento dos pacotes de atualização do Ubuntu Server, as opções de aprovação automática não são compatíveis com esse sistema operacional.

   As regras de aprovação, no entanto, também dependem da seleção da opção **Include nonsecurity updates** (Incluir atualizações não relacionadas à segurança) ao criar ou atualizar pela última vez a lista de referência de patches.

   Se nenhuma atualização que não seja de segurança for excluída, uma regra implícita será aplicada para selecionar apenas os pacotes com atualizações nos repositórios de segurança. Para cada pacote, a versão candidata do pacote (que geralmente é a versão mais recente) deve fazer parte de um repo de segurança. Neste caso, para o Ubuntu Server, versões candidatas de patch são limitadas a patches incluídos nos seguintes repositórios:
   + Ubuntu Server 16.04 LTS: `xenial-security`
   + Ubuntu Server 18.04 LTS: `bionic-security`
   + Ubuntu Server 20.04 LTS: `focal-security`
   + Ubuntu Server 22.04 LTS (`jammy-security`)
   + Ubuntu Server 24.04 LTS (`noble-security`)
   + Ubuntu Server 25.04 (`plucky-security`)

   Se atualizações não relacionadas à segurança forem incluídas, os patches de outros repositórios também serão considerados.

   Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).

Para visualizar o conteúdo dos campos *Priority* e *Section *, execute o comando `aptitude` a seguir: 

**nota**  
Pode ser necessário primeiro instalar o Aptitude em sistemas Ubuntu Server 16.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

Em resposta a esse comando, todos os pacotes atualizáveis são relatados no seguinte formato: 

```
name, priority, section, archive, candidate version
```

Para obter informações sobre valores de status de conformidade de patches, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md).

# Principais diferenças entre a aplicação de patches em nós do Linux e em nós do Windows Server
<a name="patch-manager-windows-and-linux-differences"></a>

Este tópico descreve diferenças importantes entre a aplicação de patches do Windows Server e do Linux no Patch Manager, uma ferramenta do AWS Systems Manager.

**nota**  
Para aplicar patches a nós gerenciados do Linux, os nós devem estar em execução no SSM Agent versão 2.0.834.0 ou posterior.  
Uma versão atualizada do SSM Agent é lançada sempre que novas ferramentas são adicionadas ao Systems Manager ou sempre que atualizações são feitas nas ferramentas existentes. Deixar de usar a versão mais recente do atendente pode impedir que seu nó gerenciado use várias ferramentas do Systems Manager. Por isso, recomendamos automatizar o processo de manter o SSM Agent atualizado em suas máquinas. Para mais informações, consulte [Automatizar atualizações do SSM Agent](ssm-agent-automatic-updates.md). Inscreva-se na página [Notas de versão do SSM Agent](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) no GitHub para receber notificações sobre atualizações do SSM Agent.

## Diferença 1: avaliação de patches
<a name="patch-evaluation_diff"></a>

Patch ManagerO usa processos diferentes em nós gerenciados do Windows e do Linux para avaliar quais patches devem estar presentes. 

**Linux**  
Para patches do Linux, o Systems Manager avalia as regras da lista de referência de patches e a lista de patches aprovados e rejeitados em *cada* nó gerenciado. O Systems Manager deve avaliar o patch em cada nó porque o serviço recupera a lista de patches conhecidos e atualizações dos repositórios configurados em seu nó gerenciado.

**Windows**  
Para aplicação de patch do Windows, o Systems Manager avalia as regras da lista de referência do patch e a lista de patches aprovados e rejeitados *diretamente no serviço*. Isso pode ser feito porque os patches do Windows são extraídos de um único repositório (Windows Update).

## Diferença 2: patches `Not Applicable`
<a name="not-applicable-diff"></a>

Devido à grande quantidade de pacotes disponíveis para sistemas operacionais Linux, o Systems Manager não relata detalhes sobre patches no estado *Not Applicable* (Não aplicável). Um patch `Not Applicable` é, por exemplo, um patch para o software Apache quando a instância não tiver o Apache instalado. O Systems Manager relata o número de patches `Not Applicable` no resumo, mas, se você chamar a API [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) para um nó gerenciado, os dados retornados não incluirão patches com um estado `Not Applicable`. Esse comportamento é diferente do Windows.

## Diferença 3: suporte a documentos do SSM
<a name="document-support-diff"></a>

O documento do Systems Manager (documento SSM) `AWS-ApplyPatchBaseline` não oferece suporte a nós gerenciados do Linux. Para aplicar listas de referência de patches a nós gerenciados do Linux, do macOS e do Windows Server, o documento SSM recomendado é o `AWS-RunPatchBaseline`. Para obter mais informações, consulte [Documentos do comando do SSM para aplicação de patches em nós gerenciados](patch-manager-ssm-documents.md) e [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

## Diferença 4: patches de aplicativos
<a name="application-patches-diff"></a>

O foco principal do Patch Manager é aplicar patches a sistemas operacionais. No entanto, você também pode usar o Patch Manager para aplicar patches em algumas aplicações dos nós gerenciados.

**Linux**  
Em sistemas operacionais Linux, o Patch Manager usa os repositórios configurados para atualizações e não diferencia entre patches de sistemas operacionais e de aplicações. Você pode usar o Patch Manager para definir de quais repositórios deseja buscar atualizações. Para obter mais informações, consulte [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md).

**Windows**  
Em nós gerenciados do Windows Server, você pode aplicar regras de aprovação, bem como exceções de patches *Aprovados* e *Rejeitados*, para aplicações lançadas pela Microsoft, como o Microsoft Word 2016 e o Microsoft Exchange Server 2016. Para obter mais informações, consulte [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md).

## Diferença 5: opções de lista de patches rejeitados em listas de referência de patches personalizados
<a name="rejected-patches-diff"></a>

Ao criar uma lista de referência de patches personalizados, é possível especificar um ou mais patches para uma lista de **Patches rejeitados**. Para nós gerenciados do Linux, você também pode optar por permitir que eles sejam instalados se forem dependências de outro patch permitido pela lista de referência.

O Windows Server, no entanto, não é compatível com o conceito de dependências de patches. Você pode adicionar um patch à lista de **Patches rejeitados** em uma lista de referência personalizada para o Windows Server, mas o resultado depende de (1) se o patch rejeitado já está ou não instalado em um nó gerenciado e (2) de qual opção você escolhe para a **ação de Patches rejeitados**.

Consulte a tabela a seguir para obter detalhes sobre as opções de patch rejeitadas no Windows Server.


| Status da instalação | Opção: "Permitir como dependência" | Opção: "Bloquear" | 
| --- | --- | --- | 
| O patch já está instalado | Status relatado: INSTALLED\$1OTHER | Status relatado: INSTALLED\$1REJECTED | 
| O patch ainda não está instalado | Patch ignorado | Patch ignorado | 

Cada patch para Windows Server que a Microsoft lança normalmente contém todas as informações necessárias para que a instalação seja bem-sucedida. Ocasionalmente, no entanto, pode ser necessário um pacote de pré-requisitos, que você deve instalar manualmente. O Patch Manager não relata informações sobre esses pré-requisitos. Para obter informações relacionadas, consulte a [solução de problemas do Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting) no site da Microsoft.

# Documentos do comando do SSM para aplicação de patches em nós gerenciados
<a name="patch-manager-ssm-documents"></a>

Este tópico descreve os sete documentos do Systems Manager (documentos SSM) atualmente disponíveis para ajudar você a manter seus nós gerenciados protegidos com as mais recentes atualizações relacionadas à segurança. 

Recomendamos usar apenas cinco desses documentos em suas operações de aplicação de patches. Juntos, esses cinco documentos do SSM fornecem uma variedade completa de opções de aplicação de patches usando o AWS Systems Manager. Quatro desses documentos foram lançados após os quatro documentos do SSM legados para substituí-los e representam expansões ou consolidações de funcionalidade.

**Documentos do SSM recomendados para aplicação de patches**  
Recomendamos usar os cinco documentos do SSM a seguir em suas operações de aplicação de patches.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`

**Documentos do SSM legados para aplicação de patches**  
Os quatro documentos SSM herdados a seguir permanecem disponíveis em alguns Regiões da AWS, mas não são mais atualizados ou suportados. Não é garantido que esses documentos funcionem em ambientes IPv6 e suportem apenas IPv4. Não é garantido que funcionem em todos os cenários e podem perder suporte no futuro. Recomendamos que você não use esses documentos para operações de correção.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`

Para obter as etapas para configurar as operações de correção em um ambiente que suporta somente IPv6, consulte [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md).

Consulte as seções a seguir para obter mais informações sobre como usar esses documentos do SSM em suas operações de aplicação de patches.

**Topics**
+ [Documentos do SSM recomendados para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-recommended)
+ [Documentos do SSM para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-legacy)
+ [Limitações dos documentos do SSM para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-known-limitations)
+ [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Cenário de exemplo do uso do parâmetro InstallOverrideList em `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Usar o parâmetro BaselineOverride](patch-manager-baselineoverride-parameter.md)

## Documentos do SSM recomendados para aplicação de patches em nós gerenciados
<a name="patch-manager-ssm-documents-recommended"></a>

Os cinco documentos do SSM a seguir são recomendados para uso nas operações de aplicação de patches em nós gerenciados.

**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)

### `AWS-ConfigureWindowsUpdate`
<a name="patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate"></a>

Oferece suporte à configuração e uso de funções básicas do Windows Update para instalar atualizações automaticamente (ou desativar atualizações automáticas). Disponível em todas as Regiões da AWS.

Esse documento do SSM configura o Windows Update para baixar e instalar as atualizações especificadas e reiniciar os nós gerenciados conforme necessário. Use esse documento com o State Manager, uma ferramenta do AWS Systems Manager, para garantir que o Windows Update mantenha sua configuração. Você também pode executá-lo manualmente usando o Run Command, uma ferramenta do AWS Systems Manager, para alterar a configuração do Windows Update. 

Os parâmetros disponíveis neste documento oferecem suporte à especificação de uma categoria de atualizações a serem instaladas (ou se as atualizações automáticas devem ser desativadas), bem como especificar o dia da semana e a hora do dia para executar operações de aplicação de patches. Esse documento do SSM é mais útil se você não precisa de controles rigorosos sobre as atualizações do Windows e não precisa coletar informações de conformidade. 

**Substitui estes documentos do SSM legados: **
+ *Nenhum*

### `AWS-InstallWindowsUpdates`
<a name="patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates"></a>

Instala atualizações em um nó gerenciado do Windows Server. Disponível em todas as Regiões da AWS.

Esse documento do SSM fornece a funcionalidade básica de aplicação de patches nos casos em que você deseja instalar uma atualização específica (usando o parâmetro `Include Kbs`) ou deseja instalar patches com classificações ou categorias específicas, mas não precisa de informações de conformidade do patch. 

**Substitui estes documentos do SSM legados:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`

Os três documentos legados executam funções diferentes, mas você pode alcançar os mesmos resultados usando diferentes configurações de parâmetro com o documento do SSM mais recente `AWS-InstallWindowsUpdates`. Essas configurações de parâmetro são descritas em [Documentos do SSM para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-legacy).

### `AWS-RunPatchBaseline`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline"></a>

Instala patches em nós gerenciados ou verifica os nós para determinar se qualquer patch qualificado está ausente. Disponível em todas as Regiões da AWS.

`AWS-RunPatchBaseline`O permite controlar aprovações de patches usando a linha de base do patch especificada como “padrão” para um tipo de sistema operacional. Ele relata informações de conformidade de patch que você pode exibir usando as ferramentas de conformidade do Systems Manager. Essas ferramentas fornecem informações sobre o estado de conformidade de patch dos nós gerenciados, como quais nós têm patches ausentes e quais são esses patches. Quando você usa`AWS-RunPatchBaseline`, as informações de conformidade de patch são registradas usando o`PutInventory`Comando da API. Para sistemas operacionais Linux, as informações de conformidade são fornecidas para patches do repositório de origem padrão configurado em um nó gerenciado e de qualquer repositório de origem alternativo especificado em uma lista personalizada de referência de patches. Para obter mais informações sobre repositórios de origem alternativos, consulte [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md). Para obter mais informações sobre as ferramentas de conformidade do Systems Manager, consulte [AWS Systems Manager Compliance](systems-manager-compliance.md).

 **Substitui estes documentos legados:**
+ `AWS-ApplyPatchBaseline`

O documento legado `AWS-ApplyPatchBaseline` se aplica apenas a nós gerenciados do Windows Server e não é compatível com a aplicação de patches em aplicações. O `AWS-RunPatchBaseline` mais recente fornece o mesmo suporte para sistemas Windows e Linux. A versão 2.0.834.0 ou posterior do SSM Agent é necessária para usar o documento `AWS-RunPatchBaseline`. 

Para obter mais informações sobre o documento do SSM, `AWS-RunPatchBaseline`, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

### `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation"></a>

Instala patches nas suas instâncias ou verifica as instâncias para determinar se qualquer patch qualificado está ausente. Disponível em todas as comerciais Regiões da AWS. 

O `AWS-RunPatchBaselineAssociation` difere do `AWS-RunPatchBaseline` de algumas maneiras importantes:
+ O `AWS-RunPatchBaselineAssociation` deve ser usado principalmente com associações do State Manager criadas usando o Quick Setup, uma ferramenta do AWS Systems Manager. Especificamente, quando você usar o tipo de configuração do Host Management do Quick Setup, se você escolher a opção **Scan instances for missing patches daily** (Verificar patches ausentes nas instâncias diariamente), o sistema usará `AWS-RunPatchBaselineAssociation` para a operação.

  Na maioria dos casos, no entanto, ao configurar suas próprias operações de patch, você deve escolher [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) ou [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md), ao invés do `AWS-RunPatchBaselineAssociation`. 

  Para saber mais, consulte os seguintes tópicos:
  + [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
  + [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation`O suporta o uso de tags para identificar qual linha de base de patch usar com um conjunto de destinos, quando ele for executado. 
+ Para operações de patch que usam o `AWS-RunPatchBaselineAssociation`, os dados de conformidade de patches são compilados em termos de uma associação do State Manager. Os dados de conformidade de patches coletados quando `AWS-RunPatchBaselineAssociation` é executado são gravados usando a API `PutComplianceItems` em vez do comando `PutInventory`. Isso impede que os dados de conformidade que não estão associados a essa associação específica sejam substituídos.

  Para sistemas operacionais Linux, as informações de conformidade são fornecidas para patches do repositório de origem padrão configurado em uma instância e de qualquer repositório de origem alternativo especificado em uma linha de base de patch personalizada. Para obter mais informações sobre repositórios de origem alternativos, consulte [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md). Para obter mais informações sobre as ferramentas de conformidade do Systems Manager, consulte [AWS Systems Manager Compliance](systems-manager-compliance.md).

 **Substitui estes documentos legados:**
+ **Nenhum**

Para obter mais informações sobre o documento do SSM, `AWS-RunPatchBaselineAssociation`, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).

### `AWS-RunPatchBaselineWithHooks`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks"></a>

Instala patches em seus nós gerenciados ou verifica os nós para determinar se qualquer patch qualificado está ausente, com hooks opcionais que você pode usar para executar documentos do SSM em três pontos durante o ciclo de aplicação de patches. Disponível em todas as comerciais Regiões da AWS. Não compatível com o macOS.

O `AWS-RunPatchBaselineWithHooks` difere do `AWS-RunPatchBaseline` na operação `Install`.

O `AWS-RunPatchBaselineWithHooks` oferece suporte a hooks de ciclo de vida executados em pontos designados durante a aplicação de patches em nós gerenciados. Como as instalações de patches às vezes exigem nós gerenciados para reinicializar, a operação de aplicação patches é dividida em dois eventos, para um total de três ganchos que suportam funcionalidade personalizada. O primeiro hook é antes da operação O segundo hook é depois da operação `Install with NoReboot`. O terceiro hook está disponível após a reinicialização do nó.

 **Substitui estes documentos legados:**
+ **Nenhum**

Para obter mais informações sobre o documento do SSM, `AWS-RunPatchBaselineWithHooks`, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).

## Documentos do SSM para aplicação de patches em nós gerenciados
<a name="patch-manager-ssm-documents-legacy"></a>

Os quatro documentos do SSM a seguir ainda estão disponíveis em algumas Regiões da AWS. No entanto, eles não estão sendo mais atualizados e podem não ter mais suporte no futuro. Por isso, não recomendamos seu uso. Em vez disso, use os documentos descritos em [Documentos do SSM recomendados para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-recommended).

**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)

### `AWS-ApplyPatchBaseline`
<a name="patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline"></a>

Oferece suporte apenas aos nós gerenciados do Windows Server, mas não inclui suporte para a aplicação de patches em aplicações, como ocorre em seu substituto, o `AWS-RunPatchBaseline`. Não disponível em Regiões da AWS lançadas após agosto de 2017.

**nota**  
O substituto deste documento do SSM, `AWS-RunPatchBaseline`, requer a versão 2.0.834.0 ou posterior do SSM Agent. Você pode usar o documento `AWS-UpdateSSMAgent` para atualizar os nós gerenciados para a versão mais recente do atendente. 

### `AWS-FindWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates"></a>

Substituído por `AWS-InstallWindowsUpdates`, que pode realizar as mesmas ações. Não disponível em Regiões da AWS lançadas após abril de 2017.

Para obter o mesmo resultado que teria com esse documento do SSM legado, use a seguinte configuração de parâmetro com o documento substituto recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`

### `AWS-InstallMissingWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates"></a>

Substituído por `AWS-InstallWindowsUpdates`, que pode realizar as mesmas ações. Não disponível em nenhuma Regiões da AWS lançada após abril de 2017.

Para obter o mesmo resultado que teria com esse documento do SSM legado, use a seguinte configuração de parâmetro com o documento substituto recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`

### `AWS-InstallSpecificWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates"></a>

Substituído por `AWS-InstallWindowsUpdates`, que pode realizar as mesmas ações. Não disponível em nenhuma Regiões da AWS lançada após abril de 2017.

Para obter o mesmo resultado que teria com esse documento do SSM legado, use a seguinte configuração de parâmetro com o documento substituto recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *lista de artigos da base de dados de conhecimento separados por vírgula*

## Limitações dos documentos do SSM para aplicação de patches em nós gerenciados
<a name="patch-manager-ssm-documents-known-limitations"></a>

### Interrupções na reinicialização externa
<a name="patch-manager-ssm-documents-known-limitations-external-reboot"></a>

Se uma reinicialização for iniciada pelo sistema no nó durante a instalação do patch (por exemplo, para aplicar atualizações no firmware ou em atributos como o SecureBoot), a execução do documento de patch poderá ser interrompida e marcada como falha, mesmo que os patches tenham sido instalados com sucesso. Isso ocorre porque o SSM Agent não pode persistir e retomar o estado de execução do documento em reinicializações externas.

Para verificar o status da instalação do patch após uma falha na execução, execute uma operação de patch `Scan` e, em seguida, verifique os dados de conformidade do patch no Patch Manager para avaliar o estado atual de conformidade.

# Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`
<a name="patch-manager-aws-runpatchbaseline"></a>

O AWS Systems Manager é compatível com o `AWS-RunPatchBaseline`, um documento do Systems Manager (documento SSM) para o Patch Manager, uma ferramenta do AWS Systems Manager. Este documento do SSM executa operações de aplicação de patches em nós gerenciados para atualizações de segurança e outros tipos de atualizações. Quando o documento é executado, ele usa a linha de base do patch especificada como “padrão” para um tipo de sistema operacional se nenhum grupo de patches for especificado. Caso contrário, ele usa a linha de base do patch associada ao grupo de patches. Para obter mais informações sobre grupos de patches, consulte [Grupos de patches](patch-manager-patch-groups.md). 

Você pode usar o documento `AWS-RunPatchBaseline` para aplicar patches aos sistemas operacionais e aplicações. (No Windows Server, o suporte a aplicações é limitado a atualizações de aplicações da Microsoft.)

Este documento oferece suporte a nós gerenciados do Linux, macOS e Windows Server. O documento executará as ações adequadas a cada plataforma. 

**nota**  
Patch Manager O também oferece suporte ao documento SSM legado `AWS-ApplyPatchBaseline`. No entanto, esse documento comporta a aplicação de patches somente em nós gerenciados do Windows. Em vez disso, é recomendável usar o `AWS-RunPatchBaseline` por ser compatível com a aplicação de patches em nós gerenciados do Linux, do macOS e do Windows Server. A versão 2.0.834.0 ou posterior do SSM Agent é necessária para usar o documento `AWS-RunPatchBaseline`.

------
#### [ Windows Server ]

Em nós gerenciados do Windows Server, o documento `AWS-RunPatchBaseline` baixa e invoca um módulo do PowerShell, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches contém uma lista de patches aprovados que é compilada consultando a lista de referência de patches em um servidor Windows Server Update Service (WSUS). Esse snapshot da lista de referência de patches é passado para a API do Windows Update, que controla o download e a instalação de patches aprovados, conforme apropriado. 

------
#### [ Linux ]

Em nós gerenciados do Linux, o documento `AWS-RunPatchBaseline` invoca um módulo do Python, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches usa regras e listas de patches aprovados e bloqueados para conduzir o gerenciador de pacotes apropriado para cada tipo de nó: 
+ Nós gerenciados do Amazon Linux 2, Oracle Linux e RHEL 7 usam YUM. Para operações YUM, o Patch Manager requer o `Python 2.6` ou uma versão posterior compatível (2.6 - 3.12). O Amazon Linux 2023 usa DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12).
+ RHELOs nós gerenciados do 8 usam o DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12). (Nenhuma versão é instalada por padrão no RHEL 8. É necessário instalar um deles manualmente.)
+ As instâncias do Debian Server e Ubuntu Server usam o APT. Para operações APT, o Patch Manager requer uma versão compatível do `Python 3` (3.0 - 3.12).

------
#### [ macOS ]

Em nós gerenciados do macOS, o documento `AWS-RunPatchBaseline` invoca um módulo do Python, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Em seguida, um subprocesso do Python invoca o AWS Command Line Interface (AWS CLI) em seu nó para recuperar as informações de instalação e atualização para os gerenciadores de pacotes especificados e para direcionar o gerenciador de pacotes apropriado para cada pacote de atualização.

------

Cada snapshot é específico para uma Conta da AWS, um grupo de patches, um sistema operacional e um ID de snapshot. O snapshot é entregue por meio de um URL pré-assinado do Amazon Simple Storage Service (Amazon S3), que expira 24 horas após a criação do snapshot. No entanto, se você quiser aplicar o mesmo conteúdo de snapshot a outros nós gerenciados depois que o URL expirar, você poderá gerar um novo URL pré-assinado do Amazon S3 até três dias após a criação do snapshot. Para fazer isso, use o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html). 

Depois que todas as atualizações aprovadas e aplicáveis forem instaladas, e as reinicializações realizadas conforme a necessidade, as informações de conformidade do patch serão geradas em um nó gerenciado e relatadas ao Patch Manager. 

**nota**  
Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado após a execução do Patch Manager. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).

Para obter informações sobre como visualizar dados de conformidade de patches, consulte [Sobre a conformidade de patches](compliance-about.md#compliance-monitor-patch). 

## `AWS-RunPatchBaseline`Parâmetros do
<a name="patch-manager-aws-runpatchbaseline-parameters"></a>

`AWS-RunPatchBaseline`O oferece suporte a seis parâmetros. O parâmetro `Operation` é obrigatório. Os parâmetros `InstallOverrideList`, `BaselineOverride` e `RebootOption` são opcionais. O `Snapshot-ID` é tecnicamente opcional, mas recomendamos que você forneça um valor personalizado para ele quando executar o `AWS-RunPatchBaseline` fora de uma janela de manutenção. O Patch Manager pode fornecer o valor personalizado automaticamente quando o documento for executado como parte de uma operação da janela de manutenção.

**Topics**
+ [Nome do parâmetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nome do parâmetro: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Nome do parâmetro: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Nome do parâmetro: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Nome do parâmetro: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Nome do parâmetro: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)

### Nome do parâmetro: `Operation`
<a name="patch-manager-aws-runpatchbaseline-parameters-operation"></a>

**Uso**: obrigatório.

**Opções**: `Scan` \$1 `Install`. 

Verificar  
Quando você escolhe a opção `Scan`, o `AWS-RunPatchBaseline` determina o estado de conformidade dos patches do nó gerenciado e retorna essas informações para o Patch Manager. A opção `Scan` não solicita que atualizações sejam instaladas ou que nós gerenciados sejam reinicializados. Em vez disso, a operação identifica onde existem atualizações ausentes que estão aprovadas e são aplicáveis ao nó. 

Instalar  
Quando você escolhe a opção `Install`, o `AWS-RunPatchBaseline` tenta instalar as atualizações aprovadas e aplicáveis que estiverem ausentes em seu nó gerenciado. As informações de conformidade dos patches geradas como parte de uma operação `Install` não listam atualizações ausentes, mas poderão indicar atualizações em estado malsucedido se, por qualquer motivo, a instalação da atualização não tiver tido êxito. Sempre que uma atualização é instalada em um nó gerenciado, o nó é reinicializado para garantir que a atualização esteja instalada e ativa. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).  
Se um patch especificado pelas regras da lista de referência for instalado *antes* que o Patch Manager atualize o nó gerenciado, o sistema poderá não ser reinicializado conforme esperado. Isso pode acontecer quando um patch é instalado manualmente por um usuário ou instalado automaticamente por outro programa, como o pacote `unattended-upgrades` no Ubuntu Server.

### Nome do parâmetro: `AssociationId`
<a name="patch-manager-aws-runpatchbaseline-parameters-association-id"></a>

**Uso**: opcional.

O `AssociationId` é o ID de uma associação existente no State Manager, uma ferramenta do AWS Systems Manager. Ela é usada pelo Patch Manager para adicionar dados de conformidade à associação especificada. Essa associação está relacionada a uma operação de aplicação de patches [configurada em uma política de patch no Quick Setup](quick-setup-patch-manager.md). 

**nota**  
Com o `AWS-RunPatchBaseline`, se um valor de `AssociationId` for fornecido junto com uma substituição da lista de referência da política de patch, a aplicação de patches será feita como uma operação `PatchPolicy` e o valor `ExecutionType` informado em `AWS:ComplianceItem` também será `PatchPolicy`. Se nenhum valor de `AssociationId` for fornecido, a aplicação de patches será feita como uma operação `Command` e a informação do valor `ExecutionType` no `AWS:ComplianceItem` enviado também será `Command`. 

Se ainda não tiver uma associação que você deseja usar, crie uma associação executando o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html). 

### Nome do parâmetro: `Snapshot ID`
<a name="patch-manager-aws-runpatchbaseline-parameters-snapshot-id"></a>

**Uso**: opcional.

O `Snapshot ID` é um ID exclusivo (GUID) usado pelo Patch Manager para garantir que um conjunto de nós gerenciados, corrigidos em uma única operação, tenham o mesmo conjunto de patches aprovados. Embora o parâmetro seja definido como opcional, nossa recomendação baseada em práticas recomendadas depende de estar executando ou não o `AWS-RunPatchBaseline` em uma janela de manutenção, conforme descrito na tabela a seguir.


**`AWS-RunPatchBaseline`Práticas recomendadas da**  

| Modo | Melhor prática | Detalhes | 
| --- | --- | --- | 
| RunningAWS-RunPatchBaselineDentro de uma janela de manutenção | Não forneça um ID de snapshot. O Patch Manager fornecerá para você. |  Se você usar uma janela de manutenção para executar o `AWS-RunPatchBaseline`, não forneça seu próprio ID de snapshot gerado. Nesse cenário, o Systems Manager fornece um valor GUID com base no ID de execução da janela de manutenção. Isso garante que seja usado um ID correto para todas as invocações do `AWS-RunPatchBaseline` nessa janela de manutenção.  Se você especificar um valor nesse cenário, observe que talvez o snapshot da lista de referência de patches não permaneça vigente por mais de três dias. Depois disso, um novo snapshot será gerado, mesmo que você especificar o mesmo ID depois que o snapshot expirar.   | 
| RunningAWS-RunPatchBaselineFora de uma janela de manutenção | Gere e especifique um valor de GUID personalizado para o ID do snapshot..¹ |  Quando você não estiver usando uma janela de manutenção para executar o `AWS-RunPatchBaseline`, recomendamos gerar e especificar um ID de snapshot exclusivo para cada lista de referência de patches, principalmente se estiver executando o documento `AWS-RunPatchBaseline` em vários nós gerenciados na mesma operação. Se você não especificar um ID nesse cenário, o Systems Manager gerará um ID de snapshot diferente para cada nó gerenciado para o qual o comando for enviado. Em consequência disso, vários conjuntos de patches podem ser especificados entre os nós gerenciados. Por exemplo, digamos que você esteja executando o documento `AWS-RunPatchBaseline` diretamente do Run Command, uma ferramenta do AWS Systems Manager, e visando um grupo de 50 nós gerenciados. Ao especificar os resultados de um ID de snapshot personalizado, na geração de um único snapshot da lista de referência, que é usado para avaliar e corrigir todos os nós, garantindo que eles adquiram um estado consistente.   | 
|  ¹ Você pode usar qualquer ferramenta capaz de gerar um GUID para gerar um valor para o parâmetro ID do snapshot. Por exemplo, no PowerShell, você pode usar o cmdlet `New-Guid` para gerar um GUID no formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`.  | 

### Nome do parâmetro: `InstallOverrideList`
<a name="patch-manager-aws-runpatchbaseline-parameters-installoverridelist"></a>

**Uso**: opcional.

Usando o `InstallOverrideList`, especifique um URL de estilo caminho do Amazon S3 para uma lista de patches a serem instalados. Esta lista de instalação de patches mantida no formato YAML substitui os patches especificados pela linha de base de patch padrão atual. Isso fornece a você mais controle granular sobre quais patches estão instalados em seus nós gerenciados. 

**Importante**  
O nome do arquivo `InstallOverrideList` não pode conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).

O comportamento da operação de aplicação de patches ao usar o parâmetro `InstallOverrideList` difere entre os nós gerenciados pelo Linux e pelo macOS e os nós gerenciados pelo Windows Server. No Linux e no macOS, o Patch Manager tenta aplicar os patches incluídos na lista de patches `InstallOverrideList` que estão presentes em qualquer repositório habilitado no nó, independentemente de os patches corresponderem ou não às regras da lista de referência de patches. Em nós Windows Server, no entanto, os patches na lista de patches `InstallOverrideList` são aplicados *somente* se eles também correspondem às regras da lista de referência de patches.

Lembre-se de que os relatórios de conformidade de patch refletem estados de acordo com o que está especificado na linha de base de patch, e não o que você especifica em uma lista de patches `InstallOverrideList`. Em outras palavras, operações de verificação ignoram o parâmetro `InstallOverrideList`. Isso é para garantir que os relatórios de conformidade reflitam consistentemente os estados de patch de acordo com a política, em vez de algo aprovado para uma determinada operação de patch. 

**nota**  
Ao corrigir um nó que usa somente IPv6, assegure que a URL fornecida possa ser acessada a partir do nó. Se a opção de configuração `UseDualStackEndpoint` do SSM Agent estiver definida como `true`, um cliente S3 de dualstack será usado quando uma URL S3 for fornecida. Consulte [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obter mais informações sobre como configurar o atendente para usar dualstack.

Para obter uma descrição de como você pode usar o parâmetro `InstallOverrideList` para aplicar diferentes tipos de patches a um grupo de destino, em diferentes programações de janelas de manutenção, enquanto ainda usa uma única lista de referência de patches, consulte [Cenário de exemplo do uso do parâmetro InstallOverrideList em `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).

**Formatos URL válidos**

**nota**  
Se o arquivo estiver armazenado em um bucket disponível publicamente, você poderá especificar um formato de URL https ou um URL de estilo de caminho do Amazon S3. Se o arquivo estiver armazenado em um bucket privado, você deverá especificar um URL do estilo de caminho do Amazon S3.
+ **Formato URL em https**:

  ```
  https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```
+ **URL estilo de caminho do Amazon S3**:

  ```
  s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```

**Formatos de conteúdo YAML válidos**

Os formatos que você usa para especificar patches em sua lista depende do sistema operacional do nó gerenciado. O formato geral, no entanto, é o seguinte:

```
patches:
    - 
        id: '{patch-d}'
        title: '{patch-title}'
        {additional-fields}:{values}
```

Embora você possa fornecer campos adicionais em seu arquivo YAML, eles serão ignorados durante operações de patch.

Além disso, é recomendável verificar se o formato do arquivo YAML é válido antes de adicionar ou atualizar a lista no seu bucket do S3. Para obter mais informações sobre o formato YAML, consulte [yaml.org](http://www.yaml.org). Para as opções de ferramenta de validação, pesquise na Internet por "validadores de formato yaml".

------
#### [ Linux ]

**id**  
O campo **id** é obrigatório. Use-o para especificar patches usando o nome do pacote e a arquitetura. Por exemplo: `'dhclient.x86_64'`. Você pode usar caracteres curinga no id para indicar vários pacotes. Por exemplo: `'dhcp*'` e `'dhcp*1.*'`.

**Cargo**  
O campo **título** é opcional, mas em sistemas Linux ele fornece recursos de filtragem adicionais. Se você usar o **título**, ele deve conter informações sobre a versão do pacote em um dos seguintes formatos:

YUM/SUSE Linux Enterprise Server (SLES):

```
{name}.{architecture}:{epoch}:{version}-{release}
```

APT

```
{name}.{architecture}:{version}
```

Para títulos de patches do Linux, você pode usar um ou mais caracteres curinga em qualquer posição para expandir o número de correspondências de pacotes. Por exemplo: `'*32:9.8.2-0.*.rc1.57.amzn1'`. 

Por exemplo: 
+ A versão do pacote apt 1.2.25 está atualmente instalada em seu nó gerenciado, mas a versão 1.2.27 agora está disponível. 
+ Você adiciona a versão apt.amd64 1.2.27 à lista de patches. Depende da versão do apt utils.amd64 1.2.27, mas a versão apt utils.amd64 1.2.25 é especificada na lista. 

Neste caso, a versão apt 1.2.27 não poderá ser instalada e será relatada como "Failed-NonCompliant."

------
#### [ Windows Server ]

**id**  
O campo **id** é obrigatório. Use-o para especificar os patches usando IDs da Base de Dados de Conhecimento Microsoft (por exemplo, KB2736693 e IDs do boletim de segurança da Microsoft (por exemplo, MS17-023). 

Todos os outros campos que você deseja fornecer em uma lista de patches para Windows são opcionais e são apenas para seu próprio uso informativo. Você pode usar campos adicionais, como **título**, **classificação**, **severidade**, ou qualquer outra coisa para fornecer informações mais detalhadas sobre os patches especificados.

------
#### [ macOS ]

**id**  
O campo **id** é obrigatório. O valor do**id**pode ser fornecido usando um campo`{package-name}.{package-version}`ou um formato \$1package\$1name\$1.

------

**Exemplo de listas de patch**
+ **Amazon Linux 2**

  ```
  patches:
      -
          id: 'kernel.x86_64'
      -
          id: 'bind*.x86_64'
          title: '39.11.4-26.P2.amzn2.5.2'
  
          id: 'glibc*'
      -
          id: 'dhclient*'
          title: '*4.2.5-58.amzn2'
      -
          id: 'dhcp*'
          title: '*4.2.5-77.amzn2'
  ```
+ **Debian Server**

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **macOS**

  ```
  patches:
      -
          id: 'XProtectPlistConfigData'
      -
          id: 'MRTConfigData.1.61'
      -
          id: 'Command Line Tools for Xcode.11.5'
      -
          id: 'Gatekeeper Configuration Data'
  ```
+ **Oracle Linux**

  ```
  patches:
      -
          id: 'audit-libs.x86_64'
          title: '*2.8.5-4.el7'
      -
          id: 'curl.x86_64'
          title: '*.el7'
      -
          id: 'grub2.x86_64'
          title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
      -
          id: 'grub2.x86_64'
          title: 'grub2.x86_64:1:*-0.81.0.1.el7'
  ```
+ **Red Hat Enterprise Linux (RHEL)**

  ```
  patches:
      -
          id: 'NetworkManager.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'NetworkManager-*.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'audit.x86_64'
          title: '*0:2.8.1-3.el7'
      -
          id: 'dhclient.x86_64'
          title: '*.el7_5.1'
      -
          id: 'dhcp*.x86_64'
          title: '*12:5.2.5-68.el7'
  ```
+ **SUSE Linux Enterprise Server (SLES)**

  ```
  patches:
      -
          id: 'amazon-ssm-agent.x86_64'
      -
          id: 'binutils'
          title: '*0:2.26.1-9.12.1'
      -
          id: 'glibc*.x86_64'
          title: '*2.19*'
      -
          id: 'dhcp*'
          title: '0:4.3.3-9.1'
      -
          id: 'lib*'
  ```
+ **Ubuntu Server **

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```

### Nome do parâmetro: `RebootOption`
<a name="patch-manager-aws-runpatchbaseline-parameters-norebootoption"></a>

**Uso**: opcional.

**Opções**: `RebootIfNeeded` \$1 `NoReboot` 

**Padrão**: `RebootIfNeeded`

**Atenção**  
A opção padrão é `RebootIfNeeded`. Selecione a opção correta para o seu caso de uso. Por exemplo, se os nós gerenciados precisarem reinicializar imediatamente para concluir um processo de configuração, escolha `RebootIfNeeded`. Ou, se você precisar manter a disponibilidade do nó gerenciado até um horário de reinicialização agendado, escolha `NoReboot`.

**Importante**  
Não é recomendável usar o Patch Manager para aplicar patches em instâncias de cluster no Amazon EMR (antes chamado de Amazon Elastic MapReduce). Em particular, não selecione a opção `RebootIfNeeded` para o parâmetro `RebootOption`. (Essa opção está disponível nos documentos do SSM Command para aplicação de patches em `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`.)  
Os comandos subjacentes para aplicação de patches usando o Patch Manager utilizam os comandos `yum` e `dnf`. Portanto, as operações resultam em incompatibilidades por causa da forma como os pacotes são instalados. Para obter informações sobre os métodos preferenciais para atualizar o software nos clusters do Amazon EMR, consulte [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) no *Guia de gerenciamento do Amazon EMR*.

RebootIfNeeded  
Quando você escolhe a opção `RebootIfNeeded`, o nó gerenciado é reinicializado em um dos seguintes casos:   
+ Patch ManagerO instalou um ou mais patches. 

  O Patch Manager não avalia se uma reinicialização é *exigida* pelo patch. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.
+ O Patch Manager detecta um ou mais patches com um status de `INSTALLED_PENDING_REBOOT` durante a operação `Install`. 

  O status `INSTALLED_PENDING_REBOOT` pode significar que a opção `NoReboot` foi selecionada na última vez em que a operação `Install` foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado.
A reinicialização de nós gerenciados nesses dois casos garante que os pacotes atualizados sejam liberados da memória e mantenham o comportamento da aplicação de patches e da reinicialização consistente em todos os sistemas operacionais.

NoReboot  
Quando você escolhe a opção `NoReboot`, o Patch Manager não reinicializa um nó gerenciado, mesmo que tenha instalado patches durante a operação `Install`. Essa opção é útil se você souber que os nós gerenciados não exigem reinicialização após a aplicação de patches, ou se houver aplicações ou processos em execução em um nó que não devam ser interrompidos por uma reinicialização da operação de aplicação de patch. Também é útil quando você deseja mais controle sobre o tempo de reinicializações de nós gerenciados, como, por exemplo, usando uma janela de manutenção.  
Se você escolher a opção `NoReboot` e um patch for instalado, o patch receberá um status de `InstalledPendingReboot`. O nó gerenciado em si, no entanto, é marcado como `Non-Compliant`. Depois que ocorre uma reinicialização e uma operação `Scan` é executada, o status do nó gerenciado é atualizado para `Compliant`.  
A opção `NoReboot` só impede reinicializações no nível do sistema operacional. Reinicializações no nível de serviço ainda podem ocorrer como parte do processo de aplicação de patches. Por exemplo, quando o Docker é atualizado, serviços dependentes, como o Amazon Elastic Container Service, podem ser reiniciados automaticamente mesmo com `NoReboot` habilitado. Se você tiver serviços críticos que não devem ser interrompidos, considere medidas adicionais, como remover temporariamente as instâncias do serviço ou programar a aplicação de patches durante as janelas de manutenção.

**Arquivo de rastreamento de instalação de patches**: para rastrear a instalação de patches, sobretudo os patches que foram instalados desde a última reinicialização do sistema, o Systems Manager mantém um arquivo em seu nó gerenciado.

**Importante**  
Não exclua nem modifique o arquivo de monitoramento. Se esse arquivo for excluído ou corrompido, o relatório de conformidade de patch do nó gerenciado será impreciso. Se isso acontecer, reinicialize o nó e execute uma operação de verificação de patch para restaurar o arquivo.

Esse arquivo de rastreamento é armazenado nos seguintes locais em seus nós gerenciados:
+ Sistemas operacionais Linux: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operacional : 
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

### Nome do parâmetro: `BaselineOverride`
<a name="patch-manager-aws-runpatchbaseline-parameters-baselineoverride"></a>

**Uso**: opcional.

Você pode definir preferências de patches no runtime usando o parâmetro `BaselineOverride`. Essa substituição de linha de base é mantida como um objeto JSON em um bucket do S3. Ele garante que as operações de patch usem as linhas de base fornecidas que correspondem ao sistema operacional host em vez de aplicar as regras da linha de base do patch padrão

**Importante**  
O nome do arquivo `BaselineOverride` não pode conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).

Para obter mais informações sobre como usar o parâmetro `BaselineOverride`, consulte [Usar o parâmetro BaselineOverride](patch-manager-baselineoverride-parameter.md).

### Nome do parâmetro: `StepTimeoutSeconds`
<a name="patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds"></a>

**Uso**: obrigatório.

O tempo em segundos, entre 1 e 36.000 segundos (10 horas), para que um comando seja concluído antes de que seja considerado que ele falhou.

# Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-aws-runpatchbaselineassociation"></a>

Como o`AWS-RunPatchBaseline`Documento,`AWS-RunPatchBaselineAssociation`O executa operações de aplicação de patches em instâncias para atualizações relacionadas à segurança e outros tipos de atualizações. Você pode usar o documento `AWS-RunPatchBaselineAssociation` para aplicar patches aos sistemas operacionais e aplicações.. (No Windows Server, o suporte a aplicações é limitado a atualizações de aplicações da Microsoft.)

Este documento oferece suporte a instâncias do Amazon Elastic Compute Cloud (Amazon EC2) para Linux, macOS, eWindows Server. Não há suporte para nós que não sejam do EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). O documento executará as ações adequadas a cada plataforma, invocando um módulo Python no Linux e no macOS e um módulo do PowerShell em instâncias do Windows.

O `AWS-RunPatchBaselineAssociation`, porém, difere do `AWS-RunPatchBaseline` das seguintes maneiras: 
+ O `AWS-RunPatchBaselineAssociation` deve ser usado principalmente com associações do State Manager criadas usando o [Quick Setup](systems-manager-quick-setup.md), uma ferramenta do AWS Systems Manager. Especificamente, quando você usar o tipo de configuração do Host Management do Quick Setup, se você escolher a opção **Scan instances for missing patches daily** (Verificar patches ausentes nas instâncias diariamente), o sistema usará `AWS-RunPatchBaselineAssociation` para a operação.

  Na maioria dos casos, no entanto, ao configurar suas próprias operações de patch, você deve escolher [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) ou [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md), ao invés do `AWS-RunPatchBaselineAssociation`.
+ Quando você usa o`AWS-RunPatchBaselineAssociation`, você pode especificar um key pair de tag no`BaselineTags`campo de parâmetro. Se uma lista de referência de patches personalizada na Conta da AWS compartilha essas tags, o Patch Manager, uma ferramenta do AWS Systems Manager, usa essa lista marcada quando ela é executada nas instâncias de destino em vez da lista de referência de patches "padrão" especificada no momento para o tipo de sistema operacional.
**nota**  
Se você optar por usar `AWS-RunPatchBaselineAssociation` em operações de patch diferentes daquelas configuradas usando o Quick Setup e quiser usar o parâmetro `BaselineTags`, forneça algumas permissões adicionais para o [perfil](setup-instance-permissions.md) de instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Para obter mais informações, consulte [Nome do parâmetro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).

  Ambos os formatos a seguir são válidos para o parâmetro `BaselineTags`:

  `Key=tag-key,Values=tag-value`

  `Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Importante**  
As chaves e os valores das chaves não podem conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).
+ Quando `AWS-RunPatchBaselineAssociation` é executado, os dados de conformidade de patches coletados são registrados usando o comando da API `PutComplianceItems` em vez do comando `PutInventory`, que é usado pelo `AWS-RunPatchBaseline`. Essa diferença significa que as informações de conformidade de patch que são armazenadas e relatadas por uma *Associação*. Os dados de conformidade de patch gerados fora dessa associação não são substituídos.
+ As informações de conformidade de patch relatadas após a execução de `AWS-RunPatchBaselineAssociation` indica se uma instância está ou não em conformidade. Ele não inclui detalhes em nível de patch, como demonstrado pela saída do comando da AWS Command Line Interface (AWS CLI) a seguir. Os filtros de comando em `Association` como o tipo de conformidade:

  ```
  aws ssm list-compliance-items \
      --resource-ids "i-02573cafcfEXAMPLE" \
      --resource-types "ManagedInstance" \
      --filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
      --region us-east-2
  ```

  O sistema retorna informações como estas.

  ```
  {
      "ComplianceItems": [
          {
              "Status": "NON_COMPLIANT", 
              "Severity": "UNSPECIFIED", 
              "Title": "MyPatchAssociation", 
              "ResourceType": "ManagedInstance", 
              "ResourceId": "i-02573cafcfEXAMPLE", 
              "ComplianceType": "Association", 
              "Details": {
                  "DocumentName": "AWS-RunPatchBaselineAssociation", 
                  "PatchBaselineId": "pb-0c10e65780EXAMPLE", 
                  "DocumentVersion": "1"
              }, 
              "ExecutionSummary": {
                  "ExecutionTime": 1590698771.0
              }, 
              "Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
          }
      ]
  }
  ```

Se um valor de par de chaves de etiqueta tiver sido especificado como um parâmetro para o documento `AWS-RunPatchBaselineAssociation`, o Patch Manager pesquisa uma lista de referência de patches personalizada que corresponda ao tipo de sistema operacional e que tenha sido marcada com esse mesmo par de chaves de marca. Essa pesquisa não se limita à linha de base do patch padrão especificada atual ou à linha de base atribuída a um grupo de patches. Se nenhuma lista de referência for encontrada com as etiquetas especificadas, o Patch Manager procura por um grupo de patches, se um tiver sido especificado no comando que executa `AWS-RunPatchBaselineAssociation`. Se não houver correspondência com nenhum grupo de patches, o Patch Manager retorna à lista de referência de patches padrão atual da conta do sistema operacional. 

Se mais de uma lista de referência de patches for encontrada com as tags especificadas no documento `AWS-RunPatchBaselineAssociation`, o Patch Manager retorna uma mensagem de erro indicando que apenas uma lista de referência de patches pode ser marcada com esse par de chave-valor para que a operação prossiga.

**nota**  
Em nós do Linux, o gerenciador de pacotes apropriado para cada tipo de nó é usado para instalar pacotes:   
Instâncias do Amazon Linux 2, Oracle Linux e RHEL usam YUM. Para operações YUM, o Patch Manager requer o `Python 2.6` ou uma versão posterior compatível (2.6 - 3.12). O Amazon Linux 2023 usa DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12)
As instâncias do Debian Server e Ubuntu Server usam o APT. Para operações APT, o Patch Manager requer uma versão compatível do `Python 3` (3.0 - 3.12).

Depois que todas as atualizações aprovadas e aplicáveis forem instaladas, e as reinicializações realizadas conforme a necessidade, as informações de conformidade do patch serão geradas em uma instância e relatadas ao Patch Compliance Service. 

**nota**  
Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaselineAssociation`, a instância não será reinicializada após a execução do Patch Manager. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).

Para obter informações sobre como visualizar dados de conformidade de patches, consulte [Sobre a conformidade de patches](compliance-about.md#compliance-monitor-patch). 

## `AWS-RunPatchBaselineAssociation`Parâmetros do
<a name="patch-manager-aws-runpatchbaselineassociation-parameters"></a>

`AWS-RunPatchBaselineAssociation`O oferece suporte a cinco parâmetros. Os parâmetros `Operation` e `AssociationId` são obrigatórios. Os parâmetros `InstallOverrideList`, `RebootOption` e `BaselineTags` são opcionais. 

**Topics**
+ [Nome do parâmetro: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Nome do parâmetro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Nome do parâmetro: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Nome do parâmetro: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)

### Nome do parâmetro: `Operation`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-operation"></a>

**Uso**: obrigatório.

**Opções**: `Scan` \$1 `Install`. 

Verificar  
Quando você escolhe a opção `Scan`, o `AWS-RunPatchBaselineAssociation` determina o estado de conformidade dos patches da instância e retorna essas informações para o Patch Manager. A opção `Scan` não solicita que atualizações sejam instaladas ou que instâncias sejam reinicializadas. Em vez disso, a operação identifica onde existem atualizações ausentes que estão aprovadas e são aplicáveis à instância. 

Instalar  
Quando você escolhe a opção `Install`, o `AWS-RunPatchBaselineAssociation` tenta instalar as atualizações aprovadas e aplicáveis que estiverem ausentes na instância. As informações de conformidade dos patches geradas como parte de uma operação `Install` não listam atualizações ausentes, mas poderão indicar atualizações em estado malsucedido se, por qualquer motivo, a instalação da atualização não tiver tido êxito. Sempre que uma atualização é instalada em uma instância, a instância é reinicializada para garantir que a atualização está instalada e ativa. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no `AWS-RunPatchBaselineAssociation`, a instância não será reinicializada depis que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)).  
Se um patch especificado pelas regras da lista de referência for instalado *antes* que o Patch Manager atualize a instância, o sistema poderá não ser reinicializado conforme esperado. Isso pode acontecer quando um patch é instalado manualmente por um usuário ou instalado automaticamente por outro programa, como o pacote `unattended-upgrades` no Ubuntu Server.

### Nome do parâmetro: `BaselineTags`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags"></a>

**Uso**: opcional. 

`BaselineTags`O é um par de chaves/valores de tags exclusivo que você escolhe e atribui a uma linha de base de patch personalizada individual. Você pode especificar um ou mais valores para esse parâmetro. Ambos os formatos a seguir são válidos:

`Key=tag-key,Values=tag-value`

`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`

**Importante**  
As chaves e os valores das chaves não podem conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).

O valor de `BaselineTags` é usado pelo Patch Manager para garantir que todas as instâncias de um conjunto que são corrigidas em uma única operação tenham o mesmo conjunto de patches aprovados. Quando a operação de patch é executada, o Patch Manager verifica se uma linha de base de patch para o tipo de sistema operacional está marcada com o mesmo par chave-valor especificado para `BaselineTags`. Se houver uma correspondência, essa lista de referência do patch personalizada será usada. Se não houver uma correspondência, uma linha de base de patch será identificada de acordo com qualquer grupo de patches especificado para a operação de patch. Se não houver nenhum, a linha de base de patch predefinida gerenciada da AWS para esse sistema operacional é usada. 

**Requisitos de permissão adicionais**  
Se você usar o `AWS-RunPatchBaselineAssociation` em operações de patch diferentes daquelas configuradas usando o Quick Setup, e quiser usar o parâmetro `BaselineTags`, adicione as permissões a seguir ao [perfil](setup-instance-permissions.md) para instâncias do Amazon Elastic Compute Cloud (Amazon EC2).

**nota**  
O Quick Setup e `AWS-RunPatchBaselineAssociation` não oferecem suporte a servidores on-premises e máquinas virtuais (VMs).

```
{
    "Effect": "Allow",
    "Action": [
        "ssm:DescribePatchBaselines",
        "tag:GetResources"
    ],
    "Resource": "*"
},
{
    "Effect": "Allow",
    "Action": [
        "ssm:GetPatchBaseline",
        "ssm:DescribeEffectivePatchesForPatchBaseline"
    ],
    "Resource": "patch-baseline-arn"
}
```

Substitua *patch-baseline-arn* pelo nome do recurso da Amazon (ARN) da linha de referência de patches à qual você deseja fornecer acesso no formato`arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`.

### Nome do parâmetro: `AssociationId`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-association-id"></a>

**Uso**: obrigatório.

O `AssociationId` é o ID de uma associação existente no State Manager, uma ferramenta do AWS Systems Manager. Isso é usado pelo Patch Manager para adicionar dados de conformidade a uma associação especificada. Essa associação está relacionada a uma operação de `Scan` de patch habilitada em uma [configuração do Host Management criada no Quick Setup](quick-setup-host-management.md). Ao enviar resultados da aplicação de patch como dados de conformidade de associação em vez de dados de conformidade do inventário, as informações de conformidade do inventário existentes para as instâncias não são substituídas após uma operação de aplicação de patch, nem em outras IDs de associação. Se ainda não tiver uma associação que você deseja usar, crie uma associação executando o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html). Por exemplo:

------
#### [ Linux & macOS ]

```
aws ssm create-association \
    --name "AWS-RunPatchBaselineAssociation" \
    --association-name "MyPatchHostConfigAssociation" \
    --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
    --parameters "Operation=Scan" \
    --schedule-expression "cron(0 */30 * * * ? *)" \
    --sync-compliance "MANUAL" \
    --region us-east-2
```

------
#### [ Windows Server ]

```
aws ssm create-association ^
    --name "AWS-RunPatchBaselineAssociation" ^
    --association-name "MyPatchHostConfigAssociation" ^
    --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
    --parameters "Operation=Scan" ^
    --schedule-expression "cron(0 */30 * * * ? *)" ^
    --sync-compliance "MANUAL" ^
    --region us-east-2
```

------

### Nome do parâmetro: `InstallOverrideList`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist"></a>

**Uso**: opcional.

O uso do`InstallOverrideList`, você especifica um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3) para uma lista de patches a serem instalados. Esta lista de instalação de patches mantida no formato YAML substitui os patches especificados pela linha de base de patch padrão atual. Isso fornece a você mais controle granular sobre quais patches estão instalados em suas instâncias.

**Importante**  
O nome do arquivo `InstallOverrideList` não pode conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).

O comportamento da operação de aplicação de patches ao usar o parâmetro `InstallOverrideList` difere entre os nós gerenciados pelo Linux e pelo macOS e os nós gerenciados pelo Windows Server. No Linux e no macOS, o Patch Manager tenta aplicar os patches incluídos na lista de patches `InstallOverrideList` que estão presentes em qualquer repositório habilitado no nó, independentemente de os patches corresponderem ou não às regras da lista de referência de patches. Em nós Windows Server, no entanto, os patches na lista de patches `InstallOverrideList` são aplicados *somente* se eles também correspondem às regras da lista de referência de patches.

Lembre-se de que os relatórios de conformidade de patch refletem estados de acordo com o que está especificado na linha de base de patch, e não o que você especifica em uma lista de patches `InstallOverrideList`. Em outras palavras, operações de verificação ignoram o parâmetro `InstallOverrideList`. Isso é para garantir que os relatórios de conformidade reflitam consistentemente os estados de patch de acordo com a política, em vez de algo aprovado para uma determinada operação de patch. 

**Formatos URL válidos**

**nota**  
Se o arquivo estiver armazenado em um bucket disponível publicamente, você poderá especificar um formato de URL https ou um URL de estilo de caminho do Amazon S3. Se o arquivo estiver armazenado em um bucket privado, você deverá especificar um URL do estilo de caminho do Amazon S3.
+ **Exemplo de formato de URL https**:

  ```
  https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```
+ **Exemplo de URL estilo de caminho do Amazon S3**:

  ```
  s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```

**Formatos de conteúdo YAML válidos**

Os formatos que você usa para especificar patches em sua lista depende do sistema operacional da instância. O formato geral, no entanto, é o seguinte:

```
patches:
    - 
        id: '{patch-d}'
        title: '{patch-title}'
        {additional-fields}:{values}
```

Embora você possa fornecer campos adicionais em seu arquivo YAML, eles serão ignorados durante operações de patch.

Além disso, é recomendável verificar se o formato do arquivo YAML é válido antes de adicionar ou atualizar a lista no seu bucket do S3. Para obter mais informações sobre o formato YAML, consulte [yaml.org](http://www.yaml.org). Para as opções de ferramenta de validação, pesquise na Internet por "validadores de formato yaml".
+ Microsoft Windows

**id**  
O campo **id** é obrigatório. Use-o para especificar os patches usando IDs da Base de Dados de Conhecimento Microsoft (por exemplo, KB2736693 e IDs do boletim de segurança da Microsoft (por exemplo, MS17-023). 

  Todos os outros campos que você deseja fornecer em uma lista de patches para Windows são opcionais e são apenas para seu próprio uso informativo. Você pode usar campos adicionais, como **título**, **classificação**, **severidade**, ou qualquer outra coisa para fornecer informações mais detalhadas sobre os patches especificados.
+ Linux

**id**  
O campo **id** é obrigatório. Use-o para especificar patches usando o nome do pacote e a arquitetura. Por exemplo: `'dhclient.x86_64'`. Você pode usar caracteres curinga no id para indicar vários pacotes. Por exemplo: `'dhcp*'` e `'dhcp*1.*'`.

**título**  
O campo **título** é opcional, mas em sistemas Linux ele fornece recursos de filtragem adicionais. Se você usar o **título**, ele deve conter informações sobre a versão do pacote em um dos seguintes formatos:

  YUM/Red Hat Enterprise Linux (RHEL):

  ```
  {name}.{architecture}:{epoch}:{version}-{release}
  ```

  APT

  ```
  {name}.{architecture}:{version}
  ```

  Para títulos de patches do Linux, você pode usar um ou mais caracteres curinga em qualquer posição para expandir o número de correspondências de pacotes. Por exemplo: `'*32:9.8.2-0.*.rc1.57.amzn1'`. 

  Por exemplo: 
  + A versão do pacote apt 1.2.25 está atualmente instalada em sua instância, mas a versão 1.2.27 agora está disponível. 
  + Você adiciona a versão apt.amd64 1.2.27 à lista de patches. Depende da versão do apt utils.amd64 1.2.27, mas a versão apt utils.amd64 1.2.25 é especificada na lista. 

  Neste caso, a versão apt 1.2.27 não poderá ser instalada e será relatada como "Failed-NonCompliant."

**Outros campos**  
Todos os outros campos que você deseja fornecer em uma lista de patches para Linux são opcionais e são apenas para seu próprio uso informativo. Você pode usar campos adicionais, como **classificação**, **severidade**, ou qualquer outra coisa para fornecer informações mais detalhadas sobre os patches especificados.

**Exemplo de listas de patch**
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```
+ **APT**

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Amazon Linux 2**

  ```
  patches:
      -
          id: 'kernel.x86_64'
      -
          id: 'bind*.x86_64'
          title: '39.11.4-26.P2.amzn2.5.2'
  
          id: 'glibc*'
      -
          id: 'dhclient*'
          title: '*4.2.5-58.amzn2'
      -
          id: 'dhcp*'
          title: '*4.2.5-77.amzn2'
  ```
+ **Red Hat Enterprise Linux (RHEL)**

  ```
  patches:
      -
          id: 'NetworkManager.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'NetworkManager-*.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'audit.x86_64'
          title: '*0:2.8.1-3.el7'
      -
          id: 'dhclient.x86_64'
          title: '*.el7_5.1'
      -
          id: 'dhcp*.x86_64'
          title: '*12:5.2.5-68.el7'
  ```
+ **SUSE Linux Enterprise Server (SLES)**

  ```
  patches:
      -
          id: 'amazon-ssm-agent.x86_64'
      -
          id: 'binutils'
          title: '*0:2.26.1-9.12.1'
      -
          id: 'glibc*.x86_64'
          title: '*2.19*'
      -
          id: 'dhcp*'
          title: '0:4.3.3-9.1'
      -
          id: 'lib*'
  ```
+ **Ubuntu Server **

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```

### Nome do parâmetro: `RebootOption`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption"></a>

**Uso**: opcional.

**Opções**: `RebootIfNeeded` \$1 `NoReboot` 

**Padrão**: `RebootIfNeeded`

**Atenção**  
A opção padrão é `RebootIfNeeded`. Selecione a opção correta para o seu caso de uso. Por exemplo, se as instâncias precisarem reinicializar imediatamente para concluir um processo de configuração, escolha `RebootIfNeeded`. Ou, se você precisar manter a disponibilidade das instâncias até um horário de reinicialização agendado, escolha `NoReboot`.

**Importante**  
A opção `NoReboot` só impede reinicializações no nível do sistema operacional. Reinicializações no nível de serviço ainda podem ocorrer como parte do processo de aplicação de patches. Por exemplo, quando o Docker é atualizado, serviços dependentes, como o Amazon Elastic Container Service, podem ser reiniciados automaticamente mesmo com `NoReboot` habilitado. Se você tiver serviços críticos que não devem ser interrompidos, considere medidas adicionais, como remover temporariamente as instâncias do serviço ou programar a aplicação de patches durante as janelas de manutenção.

**Importante**  
Não é recomendável usar o Patch Manager para aplicar patches em instâncias de cluster no Amazon EMR (antes chamado de Amazon Elastic MapReduce). Em particular, não selecione a opção `RebootIfNeeded` para o parâmetro `RebootOption`. (Essa opção está disponível nos documentos do SSM Command para aplicação de patches em `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`.)  
Os comandos subjacentes para aplicação de patches usando o Patch Manager utilizam os comandos `yum` e `dnf`. Portanto, as operações resultam em incompatibilidades por causa da forma como os pacotes são instalados. Para obter informações sobre os métodos preferenciais para atualizar o software nos clusters do Amazon EMR, consulte [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) no *Guia de gerenciamento do Amazon EMR*.

RebootIfNeeded  
Quando você escolhe a opção `RebootIfNeeded`, a instância é reinicializada em um dos seguintes casos:   
+ Patch ManagerO instalou um ou mais patches. 

  O Patch Manager não avalia se uma reinicialização é *exigida* pelo patch. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.
+ O Patch Manager detecta um ou mais patches com um status de `INSTALLED_PENDING_REBOOT` durante a operação `Install`. 

  O status `INSTALLED_PENDING_REBOOT` pode significar que a opção `NoReboot` foi selecionada na última vez em que a operação `Install` foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado.
A reinicialização de instâncias nesses dois casos garante que os pacotes atualizados sejam liberados da memória e mantém o comportamento de patch e reinicialização consistente em todos os sistemas operacionais.

NoReboot  
Quando você escolhe a opção `NoReboot`, o Patch Manager não reinicializa uma instância, mesmo que tenha instalado patches durante a operação `Install`. Essa opção é útil se você souber que as instâncias não exigem reinicialização após a aplicação de patches, ou se houver aplicações ou processos em execução em uma instância que não devam ser interrompidos por uma reinicialização de operação de patch. Também é útil quando você deseja mais controle sobre o tempo de reinicializações de instâncias, como, por exemplo, usando uma janela de manutenção.

**Arquivo de rastreamento de instalação de patches**: para rastrear a instalação de patches, sobretudo os patches que foram instalados desde a última reinicialização do sistema, o Systems Manager mantém um arquivo na instância gerenciada.

**Importante**  
Não exclua nem modifique o arquivo de monitoramento. Se esse arquivo for excluído ou corrompido, o relatório de conformidade de patch da instância será impreciso. Se isso acontecer, reinicialize a instância e execute uma operação de verificação de patch para restaurar o arquivo.

Esse arquivo de rastreamento é armazenado nos seguintes locais em suas instâncias gerenciadas:
+ Sistemas operacionais Linux: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operacional : 
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

# Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineWithHooks`
<a name="patch-manager-aws-runpatchbaselinewithhooks"></a>

O AWS Systems Manager é compatível com o `AWS-RunPatchBaselineWithHooks`, um documento do Systems Manager (documento SSM) para o Patch Manager, uma ferramenta do AWS Systems Manager. Este documento do SSM executa operações de aplicação de patches em nós gerenciados para atualizações de segurança e outros tipos de atualizações. 

O `AWS-RunPatchBaselineWithHooks` difere do `AWS-RunPatchBaseline` das seguintes maneiras:
+ **Um documento do wrapper**, `AWS-RunPatchBaselineWithHooks`, é um wrapper para `AWS-RunPatchBaseline` e depende do `AWS-RunPatchBaseline` para algumas de suas operações.
+ **A operação `Install`**: o `AWS-RunPatchBaselineWithHooks` oferece suporte a hooks de ciclo de vida executados em pontos designados durante a aplicação de patches do nó gerenciado. Como as instalações de patches às vezes exigem nós gerenciados para reinicializar, a operação de aplicação patches é dividida em dois eventos, para um total de três hooks que oferecem suporte à funcionalidade personalizada. O primeiro hook é antes da operação `Install with NoReboot`. O segundo hook é depois da operação `Install with NoReboot`. O terceiro hook está disponível após a reinicialização do nó gerenciado.
+ **Sem suporte à lista de patches personalizada**–`AWS-RunPatchBaselineWithHooks`não é compatível com o`InstallOverrideList`parâmetro .
+ **Suporte ao SSM Agent**: o `AWS-RunPatchBaselineWithHooks` exige que o SSM Agent 3.0.502 ou posterior seja instalado em um nó gerenciado para a aplicação de patches.

Quando o documento é executado, ele usa a linha de base do patch atualmente especificada como “padrão” para um tipo de sistema operacional se nenhum grupo de patches for especificado. Caso contrário, ele usa as linhas de base do patch associadas ao grupo de patches. Para obter mais informações sobre grupos de patches, consulte [Grupos de patches](patch-manager-patch-groups.md). 

Você pode usar o documento `AWS-RunPatchBaselineWithHooks` para aplicar patches aos sistemas operacionais e aplicações. (No Windows Server, o suporte a aplicações é limitado a atualizações de aplicações da Microsoft.)

Este documento oferece suporte a nós gerenciados do Linux e Windows Server. O documento executará as ações adequadas a cada plataforma.

**nota**  
`AWS-RunPatchBaselineWithHooks` não é compatível com macOS.

------
#### [ Linux ]

Em nós gerenciados do Linux, o documento `AWS-RunPatchBaselineWithHooks` invoca um módulo do Python, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches usa regras e listas de patches aprovados e bloqueados para conduzir o gerenciador de pacotes apropriado para cada tipo de nó: 
+ Nós gerenciados do Amazon Linux 2, Oracle Linux e RHEL 7 usam YUM. Para operações YUM, o Patch Manager requer o `Python 2.6` ou uma versão posterior compatível (2.6 - 3.12). O Amazon Linux 2023 usa DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12).
+ RHELOs nós gerenciados do 8 usam o DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12). (Nenhuma versão é instalada por padrão no RHEL 8. É necessário instalar um deles manualmente.)
+ As instâncias do Debian Server e Ubuntu Server usam o APT. Para operações APT, o Patch Manager requer uma versão compatível do `Python 3` (3.0 - 3.12).

------
#### [ Windows Server ]

Em nós gerenciados do Windows Server, o documento `AWS-RunPatchBaselineWithHooks` baixa e invoca um módulo do PowerShell, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches contém uma lista de patches aprovados que é compilada consultando a lista de referência de patches em um servidor Windows Server Update Service (WSUS). Esse snapshot da lista de referência de patches é passado para a API do Windows Update, que controla o download e a instalação de patches aprovados, conforme apropriado. 

------

Cada snapshot é específico para uma Conta da AWS, um grupo de patches, um sistema operacional e um ID de snapshot. O snapshot é entregue por meio de um URL pré-assinado do Amazon Simple Storage Service (Amazon S3), que expira 24 horas após a criação do snapshot. No entanto, depois que o URL expirar, se você quiser aplicar o mesmo conteúdo de snapshot a outros nós gerenciados, você poderá gerar um novo URL pré-assinado do Amazon S3 até três dias após a criação do snapshot. Para fazer isso, use o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html). 

Depois que todas as atualizações aprovadas e aplicáveis forem instaladas, e as reinicializações realizadas conforme a necessidade, as informações de conformidade do patch serão geradas em um nó gerenciado e relatadas ao Patch Manager. 

Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaselineWithHooks`, o nó gerenciado não será reinicializado após a execução do Patch Manager. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).

**Importante**  
Embora a opção `NoReboot` impeça a reinicialização do sistema operacional, ela não impede as reinicializações no nível de serviço que podem ocorrer quando determinados pacotes são atualizados. Por exemplo, atualizar pacotes como o Docker pode acionar reinicializações automáticas de serviços dependentes (como serviços de orquestração de contêineres), mesmo quando `NoReboot` é especificado.

Para obter informações sobre como visualizar dados de conformidade de patches, consulte [Sobre a conformidade de patches](compliance-about.md#compliance-monitor-patch).

## `AWS-RunPatchBaselineWithHooks`Etapas operacionais do
<a name="patch-manager-aws-runpatchbaselinewithhooks-steps"></a>

Quando o`AWS-RunPatchBaselineWithHooks`é executado, as seguintes etapas são executadas:

1. **Scan** - Uma operação `Scan` que usa o `AWS-RunPatchBaseline` é executada em um nó gerenciado, e um relatório de conformidade é gerado e carregado. 

1. **Verificar estados de patch locais**- Um script é executado para determinar quais etapas serão executadas com base na operação selecionada e`Scan`Resultado da Etapa 1. 

   1. Se a operação selecionada for `Scan`, ela será marcada como concluída. A operação termina. 

   1. Se a operação selecionada for `Install`, o Patch Manager avalia o resultado `Scan` da Etapa 1 para determinar o que executar a seguir: 

      1. Se nenhum patch ausente for detectado e nenhuma reinicialização pendente for necessária, a operação prosseguirá diretamente para a etapa final (Etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas. 

      1. Se nenhum patch ausente for detectado, mas houver reinicializações pendentes necessárias e a opção de reinicialização selecionada for`NoReboot`, a operação prossegue diretamente para a etapa final (Etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas. 

      1. Caso contrário, a operação prossegue para a próxima etapa.

1. **Operação do hook pré-patch**: o documento do SSM que você forneceu para o primeiro hook do ciclo de vida, `PreInstallHookDocName`, é executado no seu nó gerenciado. 

1. **Instalar com NoReboot** - Uma operação `Install` com a opção de reinicialização do `NoReboot` usando `AWS-RunPatchBaseline` é executada em seu nó gerenciado, e um relatório de conformidade é gerado e carregado. 

1. **Operação do hook pós-instalação**: o documento do SSM que você forneceu para o segundo hook do ciclo de vida, `PostInstallHookDocName`, é executado em seu nó gerenciado.

1. **Verificar reinicializações** - Um script é executado para determinar se uma reinicialização é necessária para o nó gerenciado e quais etapas executar:

   1. Se a opção de reinicialização selecionada for `NoReboot`, a operação prosseguirá diretamente para a etapa final (Etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas. 

   1. Se a opção de reinicialização selecionada for `RebootIfNeeded`, o Patch Manager verifica se há reinicializações pendentes necessárias do inventário coletado na Etapa 4. Isso significa que a operação continua na etapa 7 e o nó gerenciado é reinicializado em um dos seguintes casos:

      1. O Patch Manager instalou um ou mais patches. (O Patch Manager não avalia se o patch exige uma reinicialização. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.)

      1. O Patch Manager detecta um ou mais patches com um status de `INSTALLED_PENDING_REBOOT` durante a operação de instalação. O status `INSTALLED_PENDING_REBOOT` pode significar que a opção `NoReboot` foi selecionada na última vez em que a operação Instalar foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado. 

      Se nenhum patch que atenda a esses critérios for encontrado, a operação de aplicação de patch no nó gerenciado será concluída e a operação prosseguirá diretamente para a etapa final (etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas.

1. **Reinicializações e relatórios** - Uma operação de instalação com a opção de reinicialização do `RebootIfNeeded` é executado em seu nó gerenciado usando o `AWS-RunPatchBaseline` e um relatório de conformidade é gerado e carregado. 

1. **Operação de hook pós-reinicialização**: o documento do SSM que você forneceu para o terceiro hook do ciclo de vida, `OnExitHookDocName`, é executado em seu nó gerenciado. 

Para uma operação de `Scan`, se a Etapa 1 falhar, o processo de execução do documento pára e a etapa é relatada como falha, embora as etapas subsequentes sejam relatadas como bem-sucedidas. 

 Para uma operação `Install`, se qualquer uma das etapas do `aws:runDocument` falharem durante a operação, essas etapas serão relatadas como falhas e a operação prosseguirá diretamente para a etapa final (Etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas. Esta etapa é relatada como falhou, a última etapa relata o status de seu resultado de operação e todas as etapas entre são relatadas como bem-sucedidas.

## `AWS-RunPatchBaselineWithHooks`Parâmetros do
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters"></a>

`AWS-RunPatchBaselineWithHooks`O oferece suporte a seis parâmetros. 

O parâmetro `Operation` é obrigatório. 

Os parâmetros `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` e `OnExitHookDocName` são opcionais. 

O `Snapshot-ID` é tecnicamente opcional, mas recomendamos que você forneça um valor personalizado para ele quando executar o `AWS-RunPatchBaselineWithHooks` fora de uma janela de manutenção. Deixe o Patch Manager fornecer o valor automaticamente quando o documento é executado como parte de uma operação de janela de manutenção.

**Topics**
+ [Nome do parâmetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nome do parâmetro: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nome do parâmetro: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nome do parâmetro: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nome do parâmetro: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)

### Nome do parâmetro: `Operation`
<a name="patch-manager-aws-runpatchbaseline-parameters-operation"></a>

**Uso**: obrigatório.

**Opções**: `Scan` \$1 `Install`. 

Verificar  
Quando você escolhe a opção `Scan`, o sistema usa o documento `AWS-RunPatchBaseline` para determinar o estado de conformidade dos patches do nó gerenciado e retorna essas informações para o Patch Manager. A opção `Scan` não solicita que atualizações sejam instaladas ou que nós gerenciados sejam reinicializados. Em vez disso, a operação identifica onde existem atualizações ausentes que estão aprovadas e são aplicáveis ao nó. 

Instalar  
Quando você escolhe a opção `Install`, o `AWS-RunPatchBaselineWithHooks` tenta instalar as atualizações aprovadas e aplicáveis que estiverem ausentes em seu nó gerenciado. As informações de conformidade dos patches geradas como parte de uma operação `Install` não listam atualizações ausentes, mas poderão indicar atualizações em estado malsucedido se, por qualquer motivo, a instalação da atualização não tiver tido êxito. Sempre que uma atualização é instalada em um nó gerenciado, o nó é reinicializado para garantir que a atualização esteja instalada e ativa. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaselineWithHooks`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)).  
Se um patch especificado pelas regras da lista de referência for instalado *antes* que o Patch Manager atualize o nó gerenciado, o sistema poderá não ser reinicializado conforme esperado. Isso pode acontecer quando um patch é instalado manualmente por um usuário ou instalado automaticamente por outro programa, como o pacote `unattended-upgrades` no Ubuntu Server.

### Nome do parâmetro: `Snapshot ID`
<a name="patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id"></a>

**Uso**: opcional.

O `Snapshot ID` é um ID exclusivo (GUID) usado pelo Patch Manager para garantir que um conjunto de nós gerenciados, corrigidos em uma única operação, tenham o mesmo conjunto de patches aprovados. Embora o parâmetro seja definido como opcional, nossa recomendação baseada em práticas recomendadas depende de estar executando ou não o `AWS-RunPatchBaselineWithHooks` em uma janela de manutenção, conforme descrito na tabela a seguir.


**`AWS-RunPatchBaselineWithHooks`Práticas recomendadas da**  

| Modo | Melhor prática | Detalhes | 
| --- | --- | --- | 
| RunningAWS-RunPatchBaselineWithHooksDentro de uma janela de manutenção | Não forneça um ID de snapshot. O Patch Manager fornecerá para você. |  Se você usar uma janela de manutenção para executar o `AWS-RunPatchBaselineWithHooks`, não forneça seu próprio ID de snapshot gerado. Nesse cenário, o Systems Manager fornece um valor GUID com base no ID de execução da janela de manutenção. Isso garante que seja usado um ID correto para todas as invocações do `AWS-RunPatchBaselineWithHooks` nessa janela de manutenção.  Se você especificar um valor nesse cenário, observe que talvez o snapshot da lista de referência de patches não permaneça vigente por mais de três dias. Depois disso, um novo snapshot será gerado, mesmo que você especificar o mesmo ID depois que o snapshot expirar.   | 
| RunningAWS-RunPatchBaselineWithHooksFora de uma janela de manutenção | Gere e especifique um valor de GUID personalizado para o ID do snapshot..¹ |  Quando você não estiver usando uma janela de manutenção para executar o `AWS-RunPatchBaselineWithHooks`, recomendamos gerar e especificar um ID de snapshot exclusivo para cada lista de referência de patches, principalmente se estiver executando o documento `AWS-RunPatchBaselineWithHooks` em vários nós gerenciados na mesma operação. Se você não especificar um ID nesse cenário, o Systems Manager gerará um ID de snapshot diferente para cada nó gerenciado para o qual o comando for enviado. Em consequência disso, vários conjuntos de patches podem ser especificados entre os nós. Por exemplo, digamos que você esteja executando o documento `AWS-RunPatchBaselineWithHooks` diretamente do Run Command, uma ferramenta do AWS Systems Manager, e visando um grupo de 50 nós gerenciados. Ao especificar um ID de snapshot personalizado, é gerado um único snapshot da lista de referência, que é usado para avaliar e corrigir todos os nós gerenciados, garantindo que eles adquiram um estado consistente.   | 
|  ¹ Você pode usar qualquer ferramenta capaz de gerar um GUID para gerar um valor para o parâmetro ID do snapshot. Por exemplo, no PowerShell, você pode usar o cmdlet `New-Guid` para gerar um GUID no formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`.  | 

### Nome do parâmetro: `RebootOption`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption"></a>

**Uso**: opcional.

**Opções**: `RebootIfNeeded` \$1 `NoReboot` 

**Padrão**: `RebootIfNeeded`

**Atenção**  
A opção padrão é `RebootIfNeeded`. Selecione a opção correta para o seu caso de uso. Por exemplo, se os nós gerenciados precisarem reinicializar imediatamente para concluir um processo de configuração, escolha `RebootIfNeeded`. Ou, se você precisar manter a disponibilidade do nó gerenciado até um horário de reinicialização agendado, escolha `NoReboot`.

**Importante**  
Não é recomendável usar o Patch Manager para aplicar patches em instâncias de cluster no Amazon EMR (antes chamado de Amazon Elastic MapReduce). Em particular, não selecione a opção `RebootIfNeeded` para o parâmetro `RebootOption`. (Essa opção está disponível nos documentos do SSM Command para aplicação de patches em `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`.)  
Os comandos subjacentes para aplicação de patches usando o Patch Manager utilizam os comandos `yum` e `dnf`. Portanto, as operações resultam em incompatibilidades por causa da forma como os pacotes são instalados. Para obter informações sobre os métodos preferenciais para atualizar o software nos clusters do Amazon EMR, consulte [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) no *Guia de gerenciamento do Amazon EMR*.

RebootIfNeeded  
Quando você escolhe a opção `RebootIfNeeded`, o nó gerenciado é reinicializado em um dos seguintes casos:   
+ Patch ManagerO instalou um ou mais patches. 

  O Patch Manager não avalia se uma reinicialização é *exigida* pelo patch. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.
+ O Patch Manager detecta um ou mais patches com um status de `INSTALLED_PENDING_REBOOT` durante a operação `Install`. 

  O status `INSTALLED_PENDING_REBOOT` pode significar que a opção `NoReboot` foi selecionada na última vez em que a operação `Install` foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado.
A reinicialização de nós gerenciados nesses dois casos garante que os pacotes atualizados sejam liberados da memória e mantenham o comportamento da aplicação de patches e da reinicialização consistente em todos os sistemas operacionais.

NoReboot  
Quando você escolhe a opção `NoReboot`, o Patch Manager não reinicializa um nó gerenciado, mesmo que tenha instalado patches durante a operação `Install`. Essa opção é útil se você souber que os nós gerenciados não exigem reinicialização após a aplicação de patches, ou se houver aplicações ou processos em execução em um nó que não devam ser interrompidos por uma reinicialização da operação de aplicação de patch. Também é útil quando você deseja mais controle sobre o tempo de reinicializações de nós gerenciados, como, por exemplo, usando uma janela de manutenção.  
Se você escolher a opção `NoReboot` e um patch for instalado, o patch receberá um status de `InstalledPendingReboot`. O nó gerenciado em si, no entanto, é marcado como `Non-Compliant`. Depois que ocorre uma reinicialização e uma operação `Scan` é executada, o status do nó é atualizado para `Compliant`.

**Arquivo de rastreamento de instalação de patches**: para rastrear a instalação de patches, sobretudo os patches que foram instalados desde a última reinicialização do sistema, o Systems Manager mantém um arquivo em seu nó gerenciado.

**Importante**  
Não exclua nem modifique o arquivo de monitoramento. Se esse arquivo for excluído ou corrompido, o relatório de conformidade de patch do nó gerenciado será impreciso. Se isso acontecer, reinicialize o nó e execute uma operação de verificação de patch para restaurar o arquivo.

Esse arquivo de rastreamento é armazenado nos seguintes locais em seus nós gerenciados:
+ Sistemas operacionais Linux: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operacional : 
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

### Nome do parâmetro: `PreInstallHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname"></a>

**Uso**: opcional.

**Padrão**: `AWS-Noop`. 

O valor a ser fornecido para o parâmetro `PreInstallHookDocName` é o nome ou o nome do recurso da Amazon (ARN) de um documento do SSM de sua escolha. Você pode fornecer o nome de um documento gerenciado pela AWS ou o nome ou ARN de um documento SSM personalizado que você criou ou que foi compartilhado com você. (Para um documento do SSM que foi compartilhado com você de uma Conta da AWS diferente, você deve especificar o ARN completo do recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).

O documento SSM especificado é executado antes da operação `Install` e executa todas as ações suportadas pelo SSM Agent, como um script shell para executar a verificação de integridade da aplicação, antes que o patch seja executado em seu nó gerenciado. Para obter uma lista de ações consulte [Referência de plug-ins de documentos de comando](documents-command-ssm-plugin-reference.md)). O nome do documento SSM padrão é `AWS-Noop`, que não executa nenhuma operação em um nó gerenciado. 

Para obter informações sobre como criar um documento SSM personalizado, consulte [Criar conteúdo de documento do SSM](documents-creating-content.md). 

### Nome do parâmetro: `PostInstallHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname"></a>

**Uso**: opcional.

**Padrão**: `AWS-Noop`. 

O valor a ser fornecido para o parâmetro `PostInstallHookDocName` é o nome ou o nome do recurso da Amazon (ARN) de um documento do SSM de sua escolha. Você pode fornecer o nome de um documento gerenciado pela AWS ou o nome ou ARN de um documento SSM personalizado que você criou ou que foi compartilhado com você. (Para um documento do SSM que foi compartilhado com você de uma Conta da AWS diferente, você deve especificar o ARN completo do recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).

O documento SSM especificado é executado após o`Install with NoReboot`e executa todas as ações suportadas peloSSM Agent, como um script shell para instalar atualizações de terceiros antes da reinicialização. Para obter uma lista de ações consulte [Referência de plug-ins de documentos de comando](documents-command-ssm-plugin-reference.md)). O nome do documento SSM padrão é `AWS-Noop`, que não executa nenhuma operação em um nó gerenciado. 

Para obter informações sobre como criar um documento SSM personalizado, consulte [Criar conteúdo de documento do SSM](documents-creating-content.md). 

### Nome do parâmetro: `OnExitHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname"></a>

**Uso**: opcional.

**Padrão**: `AWS-Noop`. 

O valor a ser fornecido para o parâmetro `OnExitHookDocName` é o nome ou o nome do recurso da Amazon (ARN) de um documento do SSM de sua escolha. Você pode fornecer o nome de um documento gerenciado pela AWS ou o nome ou ARN de um documento SSM personalizado que você criou ou que foi compartilhado com você. (Para um documento do SSM que foi compartilhado com você de uma Conta da AWS diferente, você deve especificar o ARN completo do recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).

O documento SSM especificado é executado após a operação de reinicialização do nó gerenciado e executa todas as ações suportadas pelo SSM Agent, como um script shell para verificar a integridade do nó após a conclusão da operação de aplicação do patch. Para obter uma lista de ações consulte [Referência de plug-ins de documentos de comando](documents-command-ssm-plugin-reference.md)). O nome do documento SSM padrão é `AWS-Noop`, que não executa nenhuma operação em um nó gerenciado. 

Para obter informações sobre como criar um documento SSM personalizado, consulte [Criar conteúdo de documento do SSM](documents-creating-content.md). 

# Cenário de exemplo do uso do parâmetro InstallOverrideList em `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-override-lists"></a>

Você poderá usar o parâmetro `InstallOverrideList` quando quiser substituir os patches especificados pela lista de referência de patches padrão atual no Patch Manager, uma ferramenta do AWS Systems Manager. Este tópico fornece exemplos que mostram como usar esse parâmetro para obter o seguinte:
+ Aplique diferentes conjuntos de patches a um grupo de nós gerenciados de destino.
+ Aplique esses conjuntos de patches em diferentes frequências.
+ Use a mesma lista de referência de patches para as operações.

Digamos que você quer instalar duas categorias diferentes de patches em nós gerenciados do Amazon Linux 2. Você deseja instalar esses patches em programações diferentes usando janelas de manutenção. Deseja que uma janela de manutenção seja executada todas as semanas e instale todos os patches `Security`. Deseja que outra janela de manutenção seja executada uma vez por mês e instale todos os patches disponíveis ou categorias de patches que não sejam `Security`. 

No entanto, só é possível definir uma lista de referência de patches por vez como o padrão para um sistema operacional. Esse requisito ajuda a evitar situações em que uma lista de referência de patches aprova um patch enquanto outro o bloqueia, o que pode levar a problemas entre versões conflitantes.

A estratégia a seguir permite que você use o parâmetro `InstallOverrideList` para aplicar tipos de patches diferentes a um grupo de destino, em diferentes programações, enquanto ainda usa a mesma lista de referência de patches.

1. Na lista de referência de patches padrão, confirme se apenas as atualizações `Security` estão especificadas.

1. Crie uma janela de manutenção que execute o `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation` toda semana. Não especifique uma lista de substituição.

1. Crie uma lista de substituição dos patches de todos os tipos que você deseja aplicar mensalmente e armazene-a em um bucket do Amazon Simple Storage Service (Amazon S3). 

1. Crie uma segunda janela de manutenção que é executada uma vez por mês. No entanto, para a tarefa do Run Command registrada para essa janela de manutenção, especifique o local da lista de substituição.

O resultado: somente patches `Security`, conforme definido na lista de referência de patches padrão, são instalados toda semana. Todos os patches disponíveis, ou qualquer subconjunto de patches que você definir, são instalados todos os meses.

**nota**  
Ao corrigir um nó que usa somente IPv6, assegure que a URL fornecida possa ser acessada a partir do nó. Se a opção de configuração `UseDualStackEndpoint` do SSM Agent estiver definida como `true`, um cliente S3 de dualstack será usado quando uma URL S3 for fornecida. Consulte [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obter mais informações sobre como configurar o atendente para usar dualstack.

Para obter mais informações e listas de exemplo, consulte [Nome do parâmetro: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).

# Usar o parâmetro BaselineOverride
<a name="patch-manager-baselineoverride-parameter"></a>

Defina as preferências da aplicação de patches no runtime usando o recurso de substituição da lista de referência no Patch Manager, uma ferramenta do AWS Systems Manager. Faça isso especificando um bucket do Amazon Simple Storage Service (Amazon S3) que contenha um objeto JSON com uma lista de referência de patches. A operação de patch usa as linhas de base fornecidas no objeto JSON que correspondem ao sistema operacional host em vez de aplicar as regras da linha de base do patch padrão.

**Importante**  
O nome do arquivo `BaselineOverride` não pode conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).

Exceto quando uma operação de patch usa uma política de patch, usar o parâmetro `BaselineOverride` não substitui a conformidade do patch da linha de base fornecida no parâmetro. Os resultados de saída são registrados nos logs de Stdout do Run Command, uma ferramenta do AWS Systems Manager. Os resultados apenas imprimem pacotes marcados como `NON_COMPLIANT`. Isso significa que o pacote está marcado como`Missing`,`Failed`,`InstalledRejected`, ou`InstalledPendingReboot`.

No entanto, quando uma operação de patch usa uma política de patch, o sistema passa o parâmetro de substituição do bucket do S3 associado e o valor de conformidade é atualizado para o nó gerenciado. Para obter mais informações sobre comportamentos de políticas de patch, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).

**nota**  
Ao corrigir um nó que usa somente IPv6, assegure que a URL fornecida possa ser acessada a partir do nó. Se a opção de configuração `UseDualStackEndpoint` do SSM Agent estiver definida como `true`, um cliente S3 de dualstack será usado quando uma URL S3 for fornecida. Consulte [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obter mais informações sobre como configurar o atendente para usar dualstack.

## Usando a substituição da linha de base do patch com parâmetros Id de Snapshot ou Lista de Sobreposição de Instalação
<a name="patch-manager-baselineoverride-parameter-other-parameters"></a>

Há dois casos em que a substituição da linha de base do patch tem um comportamento digno de nota.

**Usando substituição de linha de base e ID de Snapshot ao mesmo tempo**  
Os IDs do snapshot garantem que todos os nós gerenciados em um determinado comando de patch apliquem a mesma coisa. Por exemplo, se você corrigir 1.000 nós gerenciados ao mesmo tempo, os patches serão os mesmos.

Ao usar um ID de Snapshot e uma substituição de linha de base de patch, o ID de Snapshot tem precedência sobre a substituição de linha de base do patch. As regras de substituição de linha de base ainda serão usadas, mas elas serão avaliadas apenas uma vez. No exemplo anterior, os patches em seus 1.000 nós gerenciados continuarão sempre os mesmos. Se, no meio da operação de patch, você alterou o arquivo JSON no bucket S3 referenciado para ser algo diferente, os patches aplicados continuarão sendo os mesmos. Isso ocorre porque o ID do Snapshot foi fornecido.

**Usando substituição de linha de base e Lista de Substituição de Instalação ao mesmo tempo**  
Você não pode usar esses dois parâmetros ao mesmo tempo. O documento de patch falhará se ambos os parâmetros forem fornecidos e não executará nenhuma verificação ou instalação em seu nó gerenciado.

## Exemplos de código
<a name="patch-manager-baselineoverride-parameter-code"></a>

O exemplo de código a seguir para Python mostra como gerar a substituição de linha de base do patch.

```
import boto3
import json

ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']

baseline_overrides = []
for baseline_id in baseline_ids_to_export:
    baseline_overrides.append(ssm.get_patch_baseline(
        BaselineId=baseline_id
    ))

json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```

Isso produz uma substituição de linha de base de patch, como a seguir.

```
[
    {
        "ApprovalRules": {
            "PatchRules": [
                {
                    "ApproveAfterDays": 0, 
                    "ComplianceLevel": "UNSPECIFIED", 
                    "EnableNonSecurity": false, 
                    "PatchFilterGroup": {
                        "PatchFilters": [
                            {
                                "Key": "PRODUCT", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "CLASSIFICATION", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "SEVERITY", 
                                "Values": [
                                    "*"
                                ]
                            }
                        ]
                    }
                }
            ]
        }, 
        "ApprovedPatches": [], 
        "ApprovedPatchesComplianceLevel": "UNSPECIFIED", 
        "ApprovedPatchesEnableNonSecurity": false, 
        "GlobalFilters": {
            "PatchFilters": []
        }, 
        "OperatingSystem": "AMAZON_LINUX_2", 
        "RejectedPatches": [], 
        "RejectedPatchesAction": "ALLOW_AS_DEPENDENCY", 
        "Sources": []
    }, 
    {
        "ApprovalRules": {
            "PatchRules": [
                {
                    "ApproveUntilDate": "2021-01-06", 
                    "ComplianceLevel": "UNSPECIFIED", 
                    "EnableNonSecurity": true, 
                    "PatchFilterGroup": {
                        "PatchFilters": [
                            {
                                "Key": "PRODUCT", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "CLASSIFICATION", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "SEVERITY", 
                                "Values": [
                                    "*"
                                ]
                            }
                        ]
                    }
                }
            ]
        }, 
        "ApprovedPatches": [
            "open-ssl*"
        ], 
        "ApprovedPatchesComplianceLevel": "UNSPECIFIED", 
        "ApprovedPatchesEnableNonSecurity": false, 
        "GlobalFilters": {
            "PatchFilters": []
        }, 
        "OperatingSystem": "SUSE", 
        "RejectedPatches": [
            "python*"
        ], 
        "RejectedPatchesAction": "ALLOW_AS_DEPENDENCY", 
        "Sources": []
    }
]
```

# Linhas de base de patch
<a name="patch-manager-patch-baselines"></a>

Os tópicos nesta seção fornecem informações sobre como as listas de referência de patches funcionam no Patch Manager, uma ferramenta do AWS Systems Manager, quando você executa uma operação `Scan` ou `Install` em seus nós gerenciados.

**Topics**
+ [Listas de referência de patches predefinidas e personalizadas](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md)
+ [Grupos de patches](patch-manager-patch-groups.md)
+ [Aplicações de patches lançadAs pela Microsoft no Windows Server](patch-manager-patching-windows-applications.md)

# Listas de referência de patches predefinidas e personalizadas
<a name="patch-manager-predefined-and-custom-patch-baselines"></a>

O Patch Manager, uma ferramenta do AWS Systems Manager, fornece uma lista de referência de patches predefinida para cada sistema operacional compatível com o Patch Manager. É possível usar essas listas de referência como estão configuradas no momento (não é possível personalizá-las) ou criar suas próprias listas de referência de patches personalizadas. As listas de referência de patches personalizadas permitem um controle maior sobre quais patches são aprovados ou rejeitados para o ambiente. Além disso, as listas de referência predefinidas atribuem um nível de conformidade de `Unspecified` a todos os patches instalados usando essas listas de referência. Para que os valores de conformidade sejam atribuídos, é possível criar uma cópia de uma lista de referência predefinida e especificar os valores de conformidade que deseja atribuir aos patches. Para obter mais informações, consulte [Linhas de base personalizadas](#patch-manager-baselines-custom) e [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md).

**nota**  
As informações neste tópico se aplicam independentemente do método ou tipo de configuração que você esteja usando para suas operações de aplicação de patch:  
Uma política de patch configurada no Quick Setup
Uma opção do Host Management configurada no Quick Setup
Uma janela de manutenção para executar um patch `Scan` ou tarefa `Install`
Uma operação **Patch now** (Aplicar patch agora) sob demanda

**Topics**
+ [Linhas de base predefinidas](#patch-manager-baselines-pre-defined)
+ [Linhas de base personalizadas](#patch-manager-baselines-custom)

## Linhas de base predefinidas
<a name="patch-manager-baselines-pre-defined"></a>

A tabela a seguir descreve as linhas de base de patch predefinidas fornecidas com o Patch Manager.

Para obter informações sobre quais versões de cada sistema operacional são compatíveis com o Patch Manager, consulte [Pré-requisitos do Patch Manager](patch-manager-prerequisites.md).


****  

| Nome | Sistema operacional com suporte | Detalhes | 
| --- | --- | --- | 
|  `AWS-AlmaLinuxDefaultPatchBaseline`  |  AlmaLinux  |  Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Também aprova todos os patches classificados como “Bugfix” (Correção de erros). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹  | 
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Também aprova todos os patches com uma classificação de “Bugfix” (Correção de erros). Os patches são aprovados automaticamente sete dias após o lançamento.¹ | 
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 |  Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Os patches são aprovados automaticamente sete dias após a liberação. Também aprova todos os patches com uma classificação de "Bugfix" (Correção de erros) sete dias após o lançamento.  | 
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | Aprova todas as atualizações sete dias após elas serem disponibilizadas, incluindo atualizações que não sejam de segurança. | 
| AWS-DebianDefaultPatchBaseline | Debian Server | Aprova imediatamente todos os patches relacionados à segurança do sistema operacional com prioridade "Required", (Obrigatório), "Standard" (Padrão) ou "Extra". Não há espera antes da aprovação, pois as datas de lançamento confiáveis não estão disponíveis nos repositórios. | 
| AWS-MacOSDefaultPatchBaseline | macOS | Aprova todos os patches do sistema operacional classificados como “Security” (Segurança). Também aprova todos os pacotes com uma atualização atual. | 
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Important" (Importante) ou "Moderate" (Moderado). Também aprova todos os patches classificados como “Bugfix” (Correção de erros) sete dias após o lançamento. Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹ | 
|  `AWS-RedHatDefaultPatchBaseline`  |  Red Hat Enterprise Linux (RHEL)   |  Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Também aprova todos os patches classificados como “Bugfix” (Correção de erros). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹  | 
|  `AWS-RockyLinuxDefaultPatchBaseline`  |  Rocky Linux  |  Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Também aprova todos os patches classificados como “Bugfix” (Correção de erros). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹  | 
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com gravidade "Critical" (Crítico) ou "Important" (Importante). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹ | 
|  `AWS-UbuntuDefaultPatchBaseline`  |  Ubuntu Server  |  Aprova imediatamente todos os patches relacionados à segurança do sistema operacional com prioridade "Required", (Obrigatório), "Standard" (Padrão) ou "Extra". Não há espera antes da aprovação, pois as datas de lançamento confiáveis não estão disponíveis nos repositórios.  | 
| AWS-DefaultPatchBaseline |  Windows Server  |  Aprova todos os patches do sistema operacional Windows Server classificados como "CriticalUpdates" (Atualizações críticas) ou "SecurityUpdates" (Atualizações de segurança) e com um nível de gravidade MSRC "Critical" (Crítico) ou "Important" (Importante). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.²  | 
| AWS-WindowsPredefinedPatchBaseline-OS |  Windows Server  |  Aprova todos os patches do sistema operacional Windows Server classificados como "CriticalUpdates" (Atualizações críticas) ou "SecurityUpdates" (Atualizações de segurança) e com um nível de gravidade MSRC "Critical" (Crítico) ou "Important" (Importante). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.²  | 
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Para o sistema operacional Windows Server, aprova todos os patches classificados como "CriticalUpdates" (Atualizações críticas) ou "SecurityUpdates" (Atualizações de segurança) e com um nível de gravidade MSRC "Critical" (Crítico) ou "Important" (Importante). Para aplicações lançadas pela Microsoft, aprova todos os patches. Os patches para sistemas operacionais e aplicações são aprovados automaticamente sete dias após serem lançados ou atualizados.² | 

¹ Para Amazon Linux 2, a espera de 7 dias antes da aprovação automática dos patches é calculada a partir de um valor `Updated Date` em `updateinfo.xml` e não um valor `Release Date`. Vários fatores podem afetar o valor `Updated Date`. Outros sistemas operacionais processam datas de lançamento e atualização de modo diferente. Para obter informações que podem ajudar você a evitar resultados inesperados com atrasos na aprovação automática, consulte [Como as datas de lançamento e atualização de pacotes são calculadas](patch-manager-release-dates.md).

² Para o Windows Server, as listas de referência padrão incluem um atraso de sete dias para a aprovação automática. Para instalar um patch em até sete dias após o lançamento, você deve criar uma lista de referência personalizada.

## Linhas de base personalizadas
<a name="patch-manager-baselines-custom"></a>

Use as informações a seguir para ajudar você a criar listas de referência de patches personalizadas para atender às suas metas de patches.

**Topics**
+ [Usar aprovações automáticas em listas de referência personalizadas](#baselines-auto-approvals)
+ [Informações adicionais para criar listas de referência de patches](#baseline-additional-info)

### Usar aprovações automáticas em listas de referência personalizadas
<a name="baselines-auto-approvals"></a>

Se você criar sua própria linha de base para patch, poderá escolher quais patches serão automaticamente aprovados, usando as seguintes categorias.
+ **Sistema operacional**: versões compatíveis de Windows Server, Amazon Linux, Ubuntu Server e assim por diante.
+ **Nome do produto **(para sistemas operacionais): por exemplo, RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2 e assim por diante.
+ **Nome do produto **(somente para aplicações lançadas pela Microsoft no Windows Server): por exemplo, Word 2016, BizTalk Server e assim por diante.
+ **Classificação**: por exemplo, atualizações críticas, atualizações de segurança e assim por diante.
+ **Gravidade**: por exemplo, crítica, importante e assim por diante.

Para cada regra de aprovação criada, é possível optar por especificar um atraso de aprovação automática ou especificar uma data-limite de aprovação de patch. 

**nota**  
Como não é possível determinar de forma confiável as datas de lançamento dos pacotes de atualização do Ubuntu Server, as opções de aprovação automática não são compatíveis com esse sistema operacional.

Um atraso na aprovação automática é o número de dias para aguardar após o lançamento ou a última atualização do patch, antes que a aplicação do patch seja aprovada automaticamente. Por exemplo, se você criar uma regra usando a classificação `CriticalUpdates` e configurá-la para atraso de aprovação automática de 7 dias, um novo patch crítico lançado em 7 de julho será automaticamente aprovado em 14 de julho.

Se um repositório do Linux não fornecer informações de data de lançamento para pacotes, o Patch Manager usará o horário de compilação do pacote como a data para especificações de data de aprovação automática para Amazon Linux 2, Amazon Linux 2023 e Red Hat Enterprise Linux (RHEL). Se o horário de compilação do pacote não puder ser determinado, o Patch Manager usa uma data padrão de 1º de janeiro de 1970. Isso resulta no Patch Manager ignorar quaisquer especificações de data de aprovação automática nas lista de referência de patches que estão configuradas para aprovar patches para qualquer data após 1º de janeiro de 1970.

Quando você especifica uma data-limite de aprovação automática, o Patch Manager aplica automaticamente todos os patches lançados ou com a última atualização nessa data ou antes dela. Por exemplo, se você especificar 7 de julho de 2023 como a data-limite, nenhum patch lançado ou com a última atualização em ou após 8 de julho de 2023 será instalado automaticamente.

Ao criar uma linha de lista de referência personalizada, é possível especificar um nível de gravidade de conformidade para patches aprovados por essa lista de referência de patches, como `Critical` ou `High`. Se o estado do patch de qualquer patch aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.

### Informações adicionais para criar listas de referência de patches
<a name="baseline-additional-info"></a>

Lembre-se do seguinte ao criar uma linha de base de patch:
+ Patch ManagerO fornece uma linha de base de patch predefinida para cada sistema operacional compatível. Essas linhas de base de patch predefinidas são usadas como as linhas de base de patch padrão para cada tipo de sistema operacional, a menos que você crie sua própria linha de base de patch e a designe como a padrão para o tipo de sistema operacional correspondente. 
**nota**  
Para o Windows Server, três linhas de base de patch predefinidas são fornecidas. As listas de referência de patches `AWS-DefaultPatchBaseline` e `AWS-WindowsPredefinedPatchBaseline-OS` oferecem suporte apenas às atualizações do sistema operacional Windows em si. O `AWS-DefaultPatchBaseline` é usado como lista de referência de patches para nós gerenciados do Windows Server, a menos que você especifique outra lista de referência de patches. As definições de configuração nestas duas linhas de base de patch são as mesmas. O mais novo dos dois,`AWS-WindowsPredefinedPatchBaseline-OS`, foi criado para distingui-lo da terceira linha de base de patch predefinida paraWindows Server. Essa lista de referência do patch, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, pode ser usada para aplicar patches tanto ao sistema operacional Windows Server quanto a aplicações compatíveis lançadas pela Microsoft.
+ Por padrão, o Windows Server 2019 e o Windows Server 2022 removem atualizações que são substituídas por atualizações posteriores. Como resultado, se você usar o parâmetro `ApproveUntilDate` em uma lista de referência de patches do Windows Server, mas a data selecionada no parâmetro `ApproveUntilDate` for anterior à data do patch mais recente, o novo patch não será instalado quando a operação de patch for executada. Para obter mais informações sobre como criar regras de aplicação de patches no Windows Server, consulte a guia Windows Server em [Como os patches de segurança são selecionados](patch-manager-selecting-patches.md).

  Isso significa que o nó gerenciado é compatível em termos de operações do Systems Manager, mesmo que um patch crítico do mês anterior possa não ter sido instalado. Esse mesmo cenário pode ocorrer ao usar o parâmetro `ApproveAfterDays`. Devido ao comportamento do patch substituído pela Microsoft, é possível definir um número (geralmente maior que 30 dias) para que os patches do Windows Server nunca sejam instalados se o patch mais recente disponível da Microsoft for lançado antes de o número de dias em `ApproveAfterDays` tiver passado. 
+ Apenas para Windows Server, um patch de atualização de segurança disponível que não seja aprovado pela lista de referência de patches pode ter um valor de conformidade de `Compliant` ou `Non-Compliant`, conforme definido em uma lista de referência de patches personalizada. 

  Ao criar ou atualizar uma lista de referência de patches, você escolhe o status que deseja atribuir aos patches de segurança que estão disponíveis, mas não aprovados, porque não atendem aos critérios de instalação especificados na lista de referência de patches. Por exemplo, os patches de segurança que você talvez queira instalar poderão ser ignorados se você tiver especificado um longo período de espera após o lançamento de um patch antes da instalação. Se uma atualização do patch for lançada durante o período de espera especificado, o período de espera para instalação do patch recomeçará. Se o período de espera for muito longo, várias versões do patch poderão ser lançadas, mas nunca instaladas.

  Usando o console para criar ou atualizar uma lista de referência de patches, você especifica essa opção no campo **Status de conformidade das atualizações de segurança disponíveis**. Usando a AWS CLI para executar o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) ou [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html), você especifica essa opção no parâmetro `available-security-updates-compliance-status`. 
+ Para servidores on-premises e máquinas virtuais (VMs), o Patch Manager tenta usar a lista de referência de patches padrão personalizada. Se não existir uma linha de base de patch padrão personalizada, o sistema usará a linha de base de patch predefinida para o sistema operacional correspondente.
+ Se um patch estiver listado como aprovado e rejeitado na mesma linha de base de patch, o patch será rejeitado.
+ Um nó gerenciado pode ter apenas uma lista de referência de patches definida para ele.
+ Os formatos de nomes de pacotes que você pode adicionar a listas de patches aprovados e rejeitados para uma linha de base de patch dependem do tipo de sistema operacional no qual você está aplicando patches.

  Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).
+ Se você estiver usando uma [configuração de política de patch](patch-manager-policies.md) em Quick Setup, as atualizações feitas nas listas de referência de patches personalizadas serão sincronizadas com Quick Setup uma vez por hora. 

  Se uma lista de referência de patches personalizada que foi referenciada em uma política de patch for excluída, um banner será exibido na página **Configuration details** (Detalhes da configuração) do Quick Setup da sua política de patch. O banner informa que a política de patch faz referência a uma lista de referência de patches que não existe mais e que as operações de aplicação de patches subsequentes falharão. Nesse caso, retorne à página **Configurations** (Configurações) do Quick Setup, selecione a configuração Patch Manager e escolha **Actions** (Ações), **Edit configuration** (Editar configuração). O nome da lista de referência de patches excluída será destacado, e você deverá selecionar uma nova lista de referência de patches para o sistema operacional afetado.
+ Quando você cria uma regra de aprovação com vários valores `Classification` e `Severity`, os patches são aprovados com base nos atributos disponíveis. Pacotes com atributos `Classification` e `Severity` corresponderão aos valores de linha de base selecionados para ambos os campos. Pacotes com somente atributos `Classification` são comparados somente com os valores de linha de base `Classification` selecionados. Os requisitos de severidade na mesma regra são ignorados para pacotes que não têm atributos `Severity`. 

Para obter mais informações sobre a linha de base de patch, consulte [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md) e [Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).

# Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados
<a name="patch-manager-approved-rejected-package-name-formats"></a>

Os formatos de nomes de pacotes que você pode adicionar a listas de patches aprovados e rejeitados dependem do tipo de sistema operacional no qual você está aplicando patches.

## Formatos de nomes de pacotes para sistemas operacionais Linux
<a name="patch-manager-approved-rejected-package-name-formats-linux"></a>

Os formatos que você pode especificar para patches aprovados e rejeitados em sua linha de base de patches variam de acordo com o tipo do Linux. Mais especificamente, os formatos compatíveis dependem do gerenciador de pacotes usado pelo tipo de sistema operacional Linux.

**Topics**
+ [Amazon Linux 2, Amazon Linux 2023, Oracle Linux e Red Hat Enterprise Linux (RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server e da Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)

### Amazon Linux 2, Amazon Linux 2023, Oracle Linux e Red Hat Enterprise Linux (RHEL)
<a name="patch-manager-approved-rejected-package-name-formats-standard"></a>

**Gerenciador de pacotes**: YUM, exceto no Amazon Linux 2023 e RHEL 8, que usam o DNF como gerenciador de pacotes.

**Patches aprovados**: para patches aprovados, você pode especificar qualquer um dos seguintes:
+ IDs Bugzilla, no formato `1234567` (o sistema processa somente números de sequências como IDs Bugzilla).
+ IDs CVE, no formato `CVE-2018-1234567`
+ IDs de consultoria em formatos como `RHSA-2017:0864` e `ALAS-2018-123`
+ Nomes de pacotes criados usando um ou mais dos componentes disponíveis para nomeação de pacotes. Para ilustrar, para o pacote chamado `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, os componentes são os seguintes: 
  + `name`: `dbus`
  + `architecture`: `x86_64`
  + `epoch`: `1`
  + `version`: `1.12.28`
  + `release`: `1.amzn2023.0.1`

  Nomes de pacotes com as seguintes construções são aceitos:
  + `name`
  + `name.arch`
  + `name-version`
  + `name-version-release`
  + `name-version-release.arch`
  + `version`
  + `version-release`
  + `epoch:version-release`
  + `name-epoch:version-release`
  + `name-epoch:version-release.arch`
  + `epoch:name-version-release.arch`
  + `name.arch:epoch:version-release`

  Alguns exemplos:
  + `dbus.x86_64`
  + `dbus-1.12.28`
  + `dbus-1.12.28-1.amzn2023.0.1`
  + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ Também oferecemos suporte a componentes de nome de pacote com um único curinga nos formatos acima, como os seguintes:
  + `dbus*` 
  + `dbus-1.12.2*`
  + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`

**Patches rejeitados**: para patches rejeitados, você pode especificar qualquer um dos seguintes:
+ Nomes de pacotes criados usando um ou mais dos componentes disponíveis para nomeação de pacotes. Para ilustrar, para o pacote chamado `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, os componentes são os seguintes: 
  + `name`: `dbus`
  + `architecture`; `x86_64`
  + `epoch`: `1`
  + `version`: `1.12.28`
  + `release`: `1.amzn2023.0.1`

  Nomes de pacotes com as seguintes construções são aceitos:
  + `name`
  + `name.arch`
  + `name-version`
  + `name-version-release`
  + `name-version-release.arch`
  + `version`
  + `version-release`
  + `epoch:version-release`
  + `name-epoch:version-release`
  + `name-epoch:version-release.arch`
  + `epoch:name-version-release.arch`
  + `name.arch:epoch:version-release`

  Alguns exemplos:
  + `dbus.x86_64`
  + `dbus-1.12.28`
  + `dbus-1.12.28-1.amzn2023.0.1`
  + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` 
+ Também oferecemos suporte a componentes de nome de pacote com um único curinga nos formatos acima, como os seguintes:
  + `dbus*` 
  + `dbus-1.12.2*`
  + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`

### Debian Server e da Ubuntu Server
<a name="patch-manager-approved-rejected-package-name-formats-ubuntu"></a>

**Gerenciador de pacotes**: APT

**Patches aprovados** e **patches rejeitados**: para patches aprovados e rejeitados, especifique o seguinte:
+ Nomes de pacotes no formato `ExamplePkg33`
**nota**  
Para listas do Debian Server e Ubuntu Server, não inclua elementos como arquitetura ou versões. Por exemplo, você especifica o nome do pacote `ExamplePkg33` para incluir todos os seguintes em uma lista de patches:  
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`

### SUSE Linux Enterprise Server (SLES)
<a name="patch-manager-approved-rejected-package-name-formats-sles"></a>

**Gerenciador de pacotes**: Zypper

**Patches aprovados** e **patches rejeitados**: para listas de patches aprovados e rejeitados, você pode especificar o seguinte:
+ Nomes de pacotes completos em formatos como:
  + `SUSE-SLE-Example-Package-15-2023-123`
  + `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ Nomes de pacotes com um único caractere curinga, como:
  + `SUSE-SLE-Example-Package-15-2023-*`
  + `example-pkg-2023.15.4-46.17.1.*.rpm`

## Formatos de nomes de pacotes macOS
<a name="patch-manager-approved-rejected-package-name-formats-macos"></a>

**Gerenciadores de pacote compatíveis**: atualização de software, instalador, Brew, Brew Cask

**Patches aprovados** e **patches rejeitados**: para listas de patches aprovados e rejeitados, especifique os nomes completos do pacote, em formatos como:
+ `XProtectPlistConfigData`
+ `MRTConfigData`

Curingas não são compatíveis com listas de patches aprovados e rejeitados para macOS.

## Formatos de nomes de pacotes para sistemas operacionais Windows
<a name="patch-manager-approved-rejected-package-name-formats-windows"></a>

Para sistemas operacionais Windows, especifique os patches usando IDs da Base de Dados de Conhecimento Microsoft e IDs do boletim de segurança da Microsoft; por exemplo:

```
KB2032276,KB2124261,MS10-048
```

# Grupos de patches
<a name="patch-manager-patch-groups"></a>

**nota**  
Os grupos de patches não são usados em operações de aplicação de patches em *políticas de patch*. Para obter informações sobre como trabalhar com políticas de patch, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).  
Não há suporte no console à funcionalidade de grupos de patches para pares de conta-região que ainda não usavam grupos de patches antes do lançamento do suporte à política de patches em 22 de dezembro de 2022. A funcionalidade de grupo de patches ainda está disponível em pares de conta-região que começaram a usar grupos de patches antes dessa data.

Você pode usar um *grupo de patches* para associar os nós gerenciados a uma lista de referência de patches específica no Patch Manager, uma ferramenta do AWS Systems Manager. Grupos de patches ajudam a garantir que você esteja implantando os patches apropriados, com base nas regras de lista de referência de patches associadas, para corrigir o conjunto de nós. Grupos de patches também podem ajudar você a evitar a implantação de patches antes que eles tenham sido adequadamente testados. Por exemplo, você pode criar grupos de patches para diferentes ambientes (como Desenvolvimento, Teste e Produção) e registrar cada grupo de patches em uma linha de base de patch apropriada. 

Ao executar o `AWS-RunPatchBaseline` ou outros documentos do comando do SSM para aplicar patches, você pode direcionar os nós gerenciados usando o ID ou as tags do nó. Em seguida, o SSM Agent e o Patch Manager avaliam qual lista de referência de patches deve ser usada, com base no valor do grupo de patches que você adicionou ao nó gerenciado.

## Usando tags para definir grupos de patches
<a name="patch-group-tags"></a>

É possível criar um grupo de patches ao usar tags aplicadas as instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e nós que não são do EC2 em seu ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). Observe os seguintes detalhes sobre o uso de tags para grupos de patches:
+ 

  Um grupo de patches deve ser definido usando a chave de tag `Patch Group` ou `PatchGroup` aplicada aos seus nós gerenciados. Ao registrar um grupo de patches para uma lista de referência de patches, quaisquer *valores* idênticos especificados para essas duas chaves são interpretados como parte do mesmo grupo. Por exemplo, digamos que você tenha marcado cinco nós com o primeiro dos seguintes pares de valores-chave e cinco com o segundo:
  + `key=PatchGroup,value=DEV` 
  + `key=Patch Group,value=DEV`

  O comando do Patch Manager para criar uma linha de base combina esses 10 nós gerenciados em um único grupo com base no valor `DEV`. A AWS CLI equivalente para o comando criar uma lista de referência de patches para grupos de patches é o seguinte:

  ```
  aws ssm register-patch-baseline-for-patch-group \
      --baseline-id pb-0c10e65780EXAMPLE \
      --patch-group DEV
  ```

  A combinação de valores de chaves diferentes em um único destino é exclusiva desse comando do Patch Manager para criar um novo grupo de patches e não é suportada por outras ações da API. Por exemplo, se você executar ações [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) usando chaves do `Patch Group` e do `PatchGroup` com os mesmos valores, terá como alvo dois conjuntos de nós completamente diferentes:

  ```
  aws ssm send-command \
      --document-name AWS-RunPatchBaseline \
      --targets "Key=tag:PatchGroup,Values=DEV"
  ```

  ```
  aws ssm send-command \
      --document-name AWS-RunPatchBaseline \
      --targets "Key=tag:Patch Group,Values=DEV"
  ```
+ Há limites na segmentação baseada em tags. Cada matriz de alvos para `SendCommand` pode conter no máximo cinco pares de chave-valor.
+ Recomendamos que você escolha apenas uma dessas convenções de chave de tag, seja `PatchGroup` (sem espaço) ou `Patch Group` (com espaço). No entanto, se você tiver [tags permitidas nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), em uma instância, você deve usar o `PatchGroup`.
+ Observe que a chave faz distinção entre maiúsculas e minúsculas. Você pode especificar qualquer *valor* para ajudar você a identificar e direcionar os recursos desse grupo, por exemplo, “servidores web” ou “US-EAST-PROD”, mas a chave deve ser `Patch Group` ou `PatchGroup`.

Depois de criar um grupo de patches e marcar os nós gerenciados, você poderá registrar o grupo de patches com uma lista de referência de patches. Registrar o grupo de patches em uma lista de referência de patches garante que os nós nesse grupo usem as regras definidas na lista de referência de patches associada. 

Para obter mais informações sobre como criar um grupo de patches e associá-lo a uma lista de referência dos patches, consulte [Como criar e gerenciar grupos de patches](patch-manager-tag-a-patch-group.md) e [Adicionar um grupo de patches a uma lista de referência de patches](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline).

Para visualizar um exemplo de como criar uma lista de referência de patches e grupos de patches usando a AWS Command Line Interface (AWS CLI), consulte [Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). Para obter mais informações, consulte [Marcar recursos do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) no *Guia do usuário do Amazon EC2 para instâncias do Linux*.

## Como funciona
<a name="how-it-works-patch-groups"></a>

Quando o sistema executar a tarefa para aplicar uma lista de referência de patches a um nó gerenciado, o SSM Agent verificará se um grupo de patches está definido para esse nó. Se o nó estiver atribuído a um grupo de patches, o Patch Manager verificará se a lista de referência de patches está registrada nesse grupo. Se uma lista de referência de patches for encontrada para esse grupo, o Patch Manager notificará o SSM Agent para usar a lista de referência de patches associada. Se um nó não estiver configurado para um grupo de patches, o Patch Manager notificará automaticamente o SSM Agent para usar a lista de referência de patches padrão atualmente configurada.

**Importante**  
Um nó gerenciado só pode estar em um grupo de patches.  
Um grupo de patches pode ser registrado em somente uma linha de base de patch para cada tipo de sistema operacional.  
Não é possível aplicar a tag `Patch Group` (com um espaço) a uma instância do Amazon EC2 se a opção **Allow tags in instance metadata** (Permitir tags em metadados de instância) estiver habilitada na instância. Permitir tags em metadados de instância impede que nomes de chaves de tag contenham espaços. Se você tiver [permissão para tags nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), é necessário usar a chave de tag `PatchGroup` (sem um espaço).

**Diagrama 1: exemplo geral do fluxo de processos de operações da aplicação de patches**

A ilustração a seguir mostra um exemplo geral dos processos que o Systems Manager realiza ao enviar uma tarefa do Run Command à sua frota de servidores para aplicar patches usando o Patch Manager. Esses processos determinam quais listas de referência de patches usar nas operações de aplicação de patches. (Um processo semelhante é usado quando uma janela de manutenção estiver configurada para enviar um comando para aplicar patches usando o Patch Manager.)

O processo completo é explicado abaixo da ilustração.

![\[Fluxo de trabalho do Patch Manager para determinar quais listas de referência de patches usar ao realizar operações de patch.\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)


Neste exemplo, temos três grupos de instâncias do EC2 para Windows Server, com as seguintes tags aplicadas:


****  

| Grupo de instâncias do EC2 | Tags | 
| --- | --- | 
|  Grupo 1  |  `key=OS,value=Windows` `key=PatchGroup,value=DEV`  | 
|  Grupo 2  |  `key=OS,value=Windows`  | 
|  Grupo 3  |  `key=OS,value=Windows` `key=PatchGroup,value=QA`  | 

Para este exemplo, também temos essas duas listas de referência de patches do Windows Server:


****  

| ID da linha de base do patch | Padrão | Grupo de patches associado | 
| --- | --- | --- | 
|  `pb-0123456789abcdef0`  |  Sim  |  `Default`  | 
|  `pb-9876543210abcdef0`  |  Não  |  `DEV`  | 

O processo geral para verificar ou instalar patches usando o Run Command, uma ferramenta do AWS Systems Manager, e o Patch Manager é o seguinte:

1. **Enviar um comando para patch**: use o console do Systems Manager, o SDK, a AWS Command Line Interface (AWS CLI) ou o AWS Tools for Windows PowerShell para enviar uma tarefa de Run Command usando o documento `AWS-RunPatchBaseline`. O diagrama mostra uma tarefa de Run Command para aplicar patch a instâncias gerenciadas especificando a etiqueta `key=OS,value=Windows`.

1. **Determinação da lista de referência de patches**: o SSM Agent verifica as etiquetas de grupo de patches aplicadas à instância do EC2 e consulta o Patch Manager em busca da lista de referência de patches correspondente.
   + **Valor de grupo de patches correspondente associado à linha de base de patch:**

     1. O SSM Agent, que está instalado em instâncias do EC2 no grupo 1, recebe o comando emitido na Etapa 1 para iniciar uma operação de aplicação de patch. O SSM Agent valida se as instâncias do EC2 têm o valor de tag `DEV` aplicado ao grupo de patches e consulta o Patch Manager em busca de uma linha de base de patch associada.

     1. O Patch Manager verifica se a linha de base do patch `pb-9876543210abcdef0` tem o grupo de patches `DEV` associado e notifica o SSM Agent.

     1. O SSM Agent recupera um snapshot de linha de base de patch do Patch Manager com base nas regras de aprovação e nas exceções configuradas em `pb-9876543210abcdef0` e prossegue para a próxima etapa.
   + **Nenhuma tag de grupo de patches adicionada à instância:**

     1. O SSM Agent, que está instalado em instâncias do EC2 no grupo 2, recebe o comando emitido na Etapa 1 para iniciar uma operação de aplicação de patch. O SSM Agent valida se as instâncias do EC2 não têm uma tag `Patch Group` ou `PatchGroup` aplicada e, como resultado, o SSM Agent consulta o Patch Manager em busca da lista de referência de patches do Windows.

     1. O Patch Manager verifica se a lista de referência de patches padrão do Windows Server é `pb-0123456789abcdef0` e notifica o SSM Agent.

     1. O SSM Agent recupera um snapshot de linha de base de patch do Patch Manager com base nas regras de aprovação e nas exceções configuradas na linha de base de patch padrão `pb-0123456789abcdef0` e prossegue para a próxima etapa.
   + **Nenhum valor de grupo de patches correspondente associado a uma linha de base de patch:**

     1. O SSM Agent, que está instalado nas instâncias do EC2 no grupo 3, recebe o comando emitido na Etapa 1 para iniciar uma operação de aplicação de patch. O SSM Agent valida se as instâncias do EC2 têm o valor de tag `QA` aplicado ao grupo de patches e consulta o Patch Manager em busca de uma linha de base de patch associada.

     1. O Patch Manager não encontra uma linha de base do patch que tenha o grupo de patches `QA` associado.

     1. O Patch Manager notifica o SSM Agent para usar a linha de base de patch padrão do Windows, `pb-0123456789abcdef0`.

     1. O SSM Agent recupera um snapshot de linha de base de patch do Patch Manager com base nas regras de aprovação e nas exceções configuradas na linha de base de patch padrão `pb-0123456789abcdef0` e prossegue para a próxima etapa.

1. **Verificação ou instalação de patches**: depois de determinar a linha de base de patch apropriada para uso, o SSM Agent começa a sondar ou instalar patches com base no valor de operação especificado na Etapa 1. Os patches sondados ou instalados são determinados pelas regras de aprovação e pelas exceções de patches definidas no snapshot de lista de referência de patches fornecido pelo Patch Manager.

**Mais informações**  
+ [Valores de estados de conformidade de patches](patch-manager-compliance-states.md)

# Aplicações de patches lançadAs pela Microsoft no Windows Server
<a name="patch-manager-patching-windows-applications"></a>

Use as informações neste tópico para ajudar você a preparar a aplicação de patches no Windows Server usando o Patch Manager, uma ferramenta do AWS Systems Manager.

**Aplicação de patches**  
O suporte à aplicação de patches em instâncias gerenciadas do Windows Server é limitado a aplicações lançadas pela Microsoft.

**nota**  
Em alguns casos, a Microsoft lança patches para aplicações que não especificam data e hora atualizadas. Nesses casos, uma data e hora atualizadas de `01/01/1970` são fornecidas por padrão.

**Lista de referência de patches para aplicações de patches lançados pela Microsoft.**  
Para o Windows Server, três linhas de base de patch predefinidas são fornecidas. As listas de referência de patches `AWS-DefaultPatchBaseline` e `AWS-WindowsPredefinedPatchBaseline-OS` oferecem suporte apenas às atualizações do sistema operacional Windows em si. O `AWS-DefaultPatchBaseline` é usado como lista de referência de patches para nós gerenciados do Windows Server, a menos que você especifique outra lista de referência de patches. As definições de configuração nestas duas linhas de base de patch são as mesmas. O mais novo dos dois,`AWS-WindowsPredefinedPatchBaseline-OS`, foi criado para distingui-lo da terceira linha de base de patch predefinida paraWindows Server. Essa lista de referência do patch, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, pode ser usada para aplicar patches tanto ao sistema operacional Windows Server quanto a aplicações compatíveis lançadas pela Microsoft.

Você também pode criar uma lista de referência de patch personalizada para atualizar aplicações da Microsoft em máquinas do Windows Server.

**Compatibilidade com a aplicação de patches em aplicativos lançados pela Microsoft em servidores on-premises, dispositivos de borda, VMs e outros nós que não pertençam ao EC2**  
Para aplicar patches em aplicações lançadas pela Microsoft em máquinas virtuais (VMs) e outros gerenciados que não são do EC2, é necessário ativar o nível de instâncias avançadas. Há uma cobrança para o uso do nível de instâncias avançadas. **No entanto, não há custo adicional para aplicar patches em aplicativos lançados pela Microsoft em instâncias do Amazon Elastic Compute Cloud (Amazon EC2).** Para obter mais informações, consulte [Configurar níveis de instâncias](fleet-manager-configure-instance-tiers.md).

**Opção de atualização do Windows para “outros produtos da Microsoft”**  
Para que o Patch Manager possa aplicar patches em aplicações lançadas pela Microsoft nos nós gerenciados pelo Windows Server, a opção **Give me updates for other Microsoft products when I update Windows** (Fornecer atualizações para outros produtos Microsoft quando atualizo o Windows), para a atualização do Windows, deverá estar ativada em seu nó gerenciado. 

Para obter informações sobre como permitir essa opção em um único nó gerenciado, consulte [Update Office with Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) (Atualizar o Office com o Microsoft Update) no site de Suporte da Microsoft.

Para uma frota de nós gerenciados que executam o Windows Server 2016 e posterior, você pode usar um objeto de política de grupo (GPO) para ativar a configuração. No editor de gerenciamento de políticas de grupo, acesse **Configuração do computador**, **Templates Administrativos**, **Componentes do Windows**, **Atualizações do Windows** e escolha **Instalar atualizações para outros produtos da Microsoft**. Recomendamos também configurar o GPO com parâmetros adicionais que impedem atualizações automáticas não planejadas e reinicializações fora doPatch Manager. Para obter mais informações, consulte [Configurar atualizações automáticas em um ambiente não Active Directory](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499), no site de documentação técnica da Microsoft.

Para uma frota de nós gerenciados que executam o Windows Server 2012 ou 2012 R2, você pode ativar a opção usando um script, conforme descrito em [Enabling and Disabling Microsoft Update in Windows 7 via Script](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) (Ativar e desativar o Microsoft Update no Windows 7 via Script) no site do Blog do Microsoft Docs. Por exemplo, você pode fazer o seguinte:

1. Salve o script da postagem do blog em um arquivo.

1. Faça upload do arquivo para um bucket do Amazon Simple Storage Service (Amazon S3) ou outro local acessível.

1. Usar o Run Command, uma ferramenta do AWS Systems Manager, para executar o script em seus nós gerenciados usando o documento do Systems Manager (documento do SSM) `AWS-RunPowerShellScript` com um comando semelhante ao mostrado a seguir.

   ```
   Invoke-WebRequest `
       -Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
       -Outfile "C:\script.vbs" cscript c:\script.vbs
   ```

**Requisitos mínimos de parâmetros**  
Para incluir aplicações da Microsoft em sua lista de referência do patch personalizada, especifique pelo menos o produto ao qual deseja aplicar os patches. O comando da AWS Command Line Interface (AWS CLI) a seguir demonstra os requisitos mínimos para aplicar patch a um produto, como o Office 2016.

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "My-Windows-App-Baseline" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "My-Windows-App-Baseline" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------

Se você especificar a família de produtos de aplicativos Microsoft, cada produto especificado deverá ser compatível com o membro da família de produtos selecionada. Por exemplo, para aplicar patch ao produto "Active Directory Rights Management Services Client 2.0", você deve especificar sua família de produtos como "Active Directory" e não, por exemplo, "Office" ou "SQL Server". O seguinte comando da AWS CLI demonstra um emparelhamento de correspondência entre família e produto:

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "My-Windows-App-Baseline" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "My-Windows-App-Baseline" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------

**nota**  
Se você receber uma mensagem de erro sobre um emparelhamento de produto e família incompatíveis, consulte[Problema: família de produtos/pares de produtos incompatíveis](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch)para obter ajuda para resolver o problema.

# Usar o Kernel Live Patching em nós gerenciados do Amazon Linux 2
<a name="patch-manager-kernel-live-patching"></a>

Kernel Live PatchingO para Amazon Linux 2 permite que você aplique patches para vulnerabilidades de segurança e erros críticos a um kernel do Linux em execução, sem reinicializações ou interrupções às aplicações em execução. Isso permite que você aproveite a maior disponibilidade de serviços e aplicações, mantendo sua infraestrutura segura e atualizada. O Kernel Live Patching é compatível com instâncias do Amazon EC2, com dispositivos principais do AWS IoT Greengrass e com [máquinas virtuais on-premises](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html) que executam o Amazon Linux 2.

Para obter informações gerais sobre o Kernel Live Patching, consulte [Kernel Live Patching no AL2](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html) no *Guia do usuário do Amazon Linux 2*.

Depois de ativar Kernel Live Patching em um nó gerenciado do Amazon Linux 2, você poderá usar o Patch Manager, uma ferramenta do AWS Systems Manager, para aplicar patches dinâmicos do kernel ao nó gerenciado. Usar o Patch Manager é uma alternativa ao uso de fluxos de trabalho do yum existentes em seu nó para aplicar as atualizações.

**Antes de começar**  
Para usar o Patch Manager para aplicar patches dinâmicos do kernel aos nós gerenciados do Amazon Linux 2, verifique se os nós são baseados na arquitetura e na versão do kernel corretas. Para obter mais informações, consulte [Configurações e pré-requisitos compatíveis](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) no *Guia do usuário do Amazon EC2*.

**Topics**
+ [Kernel Live Patching  usando o  Patch Manager](#about-klp)
+ [Como funciona o Patch Manager usando o Kernel Live Patching](#how-klp-works)
+ [Ativar o Kernel Live Patching usando Run Command](enable-klp.md)
+ [Aplicar patches dinâmicos do kernel usando o Run Command](install-klp.md)
+ [Desativar o Kernel Live Patching usando Run Command](disable-klp.md)

## Kernel Live Patching  usando o  Patch Manager
<a name="about-klp"></a>

Atualizar a versão do kernel  
Não é necessário reinicializar um nó gerenciado depois de aplicar uma atualização de patch dinâmico do kernel. No entanto, a AWS fornece patches dinâmicos do kernel para uma versão do kernel do Amazon Linux 2 por até três meses após seu lançamento. Após o período de três meses, é necessário fazer a atualização para uma versão posterior do kernel para continuar a receber patches dinâmicos do kernel. Recomendamos usar uma janela de manutenção para agendar uma reinicialização do nó pelo menos uma vez a cada três meses para solicitar a atualização da versão do kernel.

Desinstalar patches dinâmicos do kernel  
Os patches dinâmicos do kernel não podem ser desinstalados usando o Patch Manager. Em vez disso, é possível desabilitar o Kernel Live Patching, o que remove os pacotes RPM para os patches dinâmicos do kernel aplicados. Para obter mais informações, consulte [Desativar o Kernel Live Patching usando Run Command](disable-klp.md).

Conformidade com o kernel  
Em alguns casos, instalar todas as correções CVE dos patches dinâmicos para a versão atual do kernel pode trazer esse kernel para o mesmo estado de conformidade de uma versão mais recente do kernel. Quando isso acontece, a versão mais recente é relatada como `Installed` e o nó gerenciado é relatado como `Compliant`. No entanto, nenhum tempo de instalação é relatado para a versão mais recente do kernel.

Um patch dinâmico do kernel, vários CVEs  
Se um patch dinâmico do kernel aborda vários CVEs e estes tiverem vários valores de classificação e gravidade, somente a classificação e a gravidade mais altas entre os CVEs serão relatadas ao patch. 

O restante desta seção descreve como usar o Patch Manager para aplicar patches dinâmicos do kernel aos nós gerenciados que atendem a esses requisitos.

## Como funciona o Patch Manager usando o Kernel Live Patching
<a name="how-klp-works"></a>

A AWS lança dois tipos de patches dinâmicos do kernel para o Amazon Linux 2: atualizações de segurança e correções de bugs. Para aplicar esses tipos de patches, use um documento de linha de base de patch que visa somente as classificações e severidades listadas na tabela a seguir.


| Classificação | Gravidade | 
| --- | --- | 
| Security | Critical, Important | 
| Bugfix | All | 

É possível criar uma lista de referência de patches personalizada destinada apenas a esses patches ou usar a lista de referência de patches `AWS-AmazonLinux2DefaultPatchBaseline` predefinida. Em outras palavras, é possível usar o `AWS-AmazonLinux2DefaultPatchBaseline` com nós gerenciados do Amazon Linux 2 nos quais o Kernel Live Patching estiver ativado, e as atualizações ao vivo do kernel serão aplicadas.

**nota**  
A configuração `AWS-AmazonLinux2DefaultPatchBaseline` especifica um período de espera de sete dias após o lançamento ou última atualização de um patch antes que ele seja instalado automaticamente. Se você não quiser aguardar sete dias para que os patches dinâmicos do kernel sejam aprovados automaticamente, é possível criar e usar uma lista de referência de patches personalizada. Na linha de base do patch, você pode especificar nenhum período de espera de aprovação automática ou especificar um período mais curto ou mais longo. Para obter mais informações, consulte [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md).

Recomendamos a seguinte estratégia para aplicar patches aos nós gerenciados com atualizações ao vivo do kernel:

1. Ativar o Kernel Live Patching em nós gerenciados do Amazon Linux 2.

1. Use o Run Command, uma ferramenta do AWS Systems Manager, para executar uma operação do `Scan` em seus nós gerenciados, usando a lista de referência de patches `AWS-AmazonLinux2DefaultPatchBaseline` predefinida ou a personalizada que também é destinada somente às atualizações `Security` classificadas como `Critical` e `Important` e a gravidade `Bugfix` de `All`. 

1. Use o Compliance, uma ferramenta do AWS Systems Manager para verificar se uma não conformidade para aplicação de patches é relatada para qualquer um dos nós gerenciados que foram verificados. Em caso afirmativo, visualize os detalhes de conformidade do nó para determinar se algum patch dinâmico do kernel está ausente em seu nó gerenciado.

1. Para instalar patches dinâmicos do kernel ausentes, use o Run Command com a mesma lista de referência de patches especificada anteriormente, mas desta vez execute uma operação `Install` em vez de uma operação `Scan`.

   Como os patches dinâmicos do kernel são instalados sem a necessidade de reinicialização, é possível escolher a opção de reinicialização `NoReboot` para esta operação. 
**nota**  
Você pode ainda reinicializar o nó gerenciado se necessário para outros tipos de patches instalados nele ou se quiser atualizar para um kernel mais recente. Nesses casos, escolha a opção de reinicialização `RebootIfNeeded`.

1. Retorne à conformidade do para verificar se os patches dinâmicos do kernel foram instalados.

# Ativar o Kernel Live Patching usando Run Command
<a name="enable-klp"></a>

Para ativar o Kernel Live Patching, você pode executar o `yum` em seus nós gerenciados ou usar o Run Command e um documento personalizado do Systems Manager (documento SSM) que você criar.

Para obter informações sobre como ativar o Kernel Live Patching executando comandos `yum` diretamente em seu nó gerenciado, consulte [Habilitar o Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) no *Guia do usuário do Amazon EC2*.

**nota**  
Quando você ativa o Kernel Live Patching, se o kernel já executado em seu nó gerenciado for *anterior* ao `kernel-4.14.165-131.185.amzn2.x86_64` (a versão mínima suportada), o processo instala a versão mais recente do kernel disponível e reinicializa o nó gerenciado. Se o nó já estiver executando o `kernel-4.14.165-131.185.amzn2.x86_64` ou posterior, o processo não instalará uma versão mais recente e não reinicializará o nó.

**Para ativar oKernel Live PatchingusandoRun Command(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, escolha **Run Command**.

1. Selecione **Run command**.

1. No **Documento de comando**, escolha o documento SSM personalizado`AWS-ConfigureKernelLivePatching`.

1. Na seção **Command parameters** (Parâmetros de comando), especifique se deseja que os nós gerenciados sejam reinicializados como parte desta operação.

1. Para obter informações sobre como trabalhar com os controles restantes nesta página, consulte [Executar comandos no console](running-commands-console.md).

1. Escolha **Executar**.

**Para ativar Kernel Live Patching (AWS CLI)**
+ Execute o seguinte comando na máquina local.

------
#### [ Linux & macOS ]

  ```
  aws ssm send-command \
      --document-name "AWS-ConfigureKernelLivePatching" \
      --parameters "EnableOrDisable=Enable" \
      --targets "Key=instanceids,Values=instance-id"
  ```

------
#### [ Windows Server ]

  ```
  aws ssm send-command ^
      --document-name "AWS-ConfigureKernelLivePatching" ^
      --parameters "EnableOrDisable=Enable" ^
      --targets "Key=instanceids,Values=instance-id"
  ```

------

  Substitua *instance-id* pelo ID do nó gerenciado do Amazon Linux 2 na qual você deseja ativar o recurso, como i-02573cafcfEXAMPLE. Para ativar o recurso em vários nós gerenciados, é possível usar um dos formatos a seguir.
  + `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
  + `--targets "Key=tag:tag-key,Values=tag-value"`

  Para obter informações sobre outras opções que você pode usar no comando, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) na *AWS CLI Command Reference*.

# Aplicar patches dinâmicos do kernel usando o Run Command
<a name="install-klp"></a>

Para aplicar patches dinâmicos do kernel, é possível executar os comandos do `yum` em seus nós gerenciados ou usar o Run Command e o documento `AWS-RunPatchBaseline` do SSM. 

Para obter informações sobre como aplicar patches dinâmicos do kernel executando os comandos do `yum` diretamente em seu nó gerenciado, consulte [Aplicar patches dinâmicos do kernel](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply) no *Guia do usuário do Amazon EC2*.

**Como aplicar patches dinâmicos do kernel usando o Run Command (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, escolha **Run Command**.

1. Selecione **Run command**.

1. Na lista **Documento do comando**, escolha o documento `AWS-RunPatchBaseline` do SSM.

1. Na seção **Parâmetros de comando**, siga um destes procedimentos:
   + Se você estiver verificando se novos patches dinâmicos do kernel estão disponíveis, em **Operação**, escolha `Scan`. Em **Reboot Option** (Opção de reinicialização), se você não quiser que os nós gerenciados sejam reinicializados após essa operação, escolha `NoReboot`. Após a conclusão da operação, será possível verificar se há novos patches e status de conformidade em Compliance (Conformidade).
   + Se você já verificou a conformidade de patches e está pronto para aplicar patches dinâmicos do kernel disponíveis, em **Operação**, escolha `Install`. Em **Reboot Option** (Opção de reinicialização), se não quiser que os nós gerenciados sejam reinicializados após essa operação, escolha `NoReboot`.

1. Para obter informações sobre como trabalhar com os controles restantes nesta página, consulte [Executar comandos no console](running-commands-console.md).

1. Escolha **Executar**.

**Como aplicar patches dinâmicos do kernel usando o Run Command (AWS CLI)**

1. Para executar uma operação `Scan` antes de verificar os resultados no Compliance, execute o comando a seguir na máquina local.

------
#### [ Linux & macOS ]

   ```
   aws ssm send-command \
       --document-name "AWS-RunPatchBaseline" \
       --targets "Key=InstanceIds,Values=instance-id" \
       --parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
   ```

------
#### [ Windows Server ]

   ```
   aws ssm send-command ^
       --document-name "AWS-RunPatchBaseline" ^
       --targets "Key=InstanceIds,Values=instance-id" ^
       --parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
   ```

------

   Para obter informações sobre outras opções que você pode usar no comando, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) na *AWS CLI Command Reference*.

1. Para executar uma operação `Install` após verificar os resultados no Compliance, execute o comando a seguir na máquina local.

------
#### [ Linux & macOS ]

   ```
   aws ssm send-command \
       --document-name "AWS-RunPatchBaseline" \
       --targets "Key=InstanceIds,Values=instance-id" \
       --parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
   ```

------
#### [ Windows Server ]

   ```
   aws ssm send-command ^
       --document-name "AWS-RunPatchBaseline" ^
       --targets "Key=InstanceIds,Values=instance-id" ^
       --parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
   ```

------

Nos comandos anteriores, substitua *instance-id* pelo ID do nó gerenciado do Amazon Linux 2 no qual você deseja aplicar patches dinâmicos do kernel, como i-02573cafcfEXAMPLE. Para ativar o recurso em vários nós gerenciados, é possível usar um dos formatos a seguir.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`

Para obter informações sobre outras opções que você pode usar nesses comandos, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) na *AWS CLI Command Reference*.

# Desativar o Kernel Live Patching usando Run Command
<a name="disable-klp"></a>

Para habilitar o Kernel Live Patching, é possível executar os comandos do `yum` em seus nós gerenciados ou usar o Run Command e um documento personalizado do `AWS-ConfigureKernelLivePatching` criado por você.

**nota**  
Se não precisar mais usar o Kernel Live Patching, você pode desabilitá-lo a qualquer momento. Na maioria dos casos, não é necessário desativar o recurso.

Para obter informações sobre como desativar o Kernel Live Patching executando comandos `yum` diretamente em seu nó gerenciado, consulte [Habilitar o Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable) no *Guia do usuário do Amazon EC2*.

**nota**  
Quando você desativa o Kernel Live Patching, o processo desinstala o plugin Kernel Live Patching e, em seguida, reinicializa o nó gerenciado.

**Para desativar oKernel Live PatchingusandoRun Command(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, escolha **Run Command**.

1. Selecione **Run command**.

1. Na lista **Documento do comando**, escolha o documento `AWS-ConfigureKernelLivePatching` do SSM.

1. Na seção **Command parameters**, especifique valores para os parâmetros necessários.

1. Para obter informações sobre como trabalhar com os controles restantes nesta página, consulte [Executar comandos no console](running-commands-console.md).

1. Escolha **Executar**.

**Para desativar oKernel Live Patching(AWS CLI)**
+ Execute um comando semelhante ao seguinte.

------
#### [ Linux & macOS ]

  ```
  aws ssm send-command \
      --document-name "AWS-ConfigureKernelLivePatching" \
      --targets "Key=instanceIds,Values=instance-id" \
      --parameters "EnableOrDisable=Disable"
  ```

------
#### [ Windows Server ]

  ```
  aws ssm send-command ^
      --document-name "AWS-ConfigureKernelLivePatching" ^
      --targets "Key=instanceIds,Values=instance-id" ^
      --parameters "EnableOrDisable=Disable"
  ```

------

  Substitua *instance-id* pelo ID do nó gerenciado do Amazon Linux 2 na qual você quer desativar o recurso, como i-02573cafcfEXAMPLE. Para desativar o recurso em vários nós gerenciados, é possível usar um dos formatos a seguir.
  + `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
  + `--targets "Key=tag:tag-key,Values=tag-value"`

  Para obter informações sobre outras opções que você pode usar no comando, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) na *AWS CLI Command Reference*.

# Trabalhar com recursos e conformidade do Patch Manager usando o console
<a name="patch-manager-console"></a>

Para usar o Patch Manager, uma ferramenta do AWS Systems Manager, conclua as tarefas a seguir. Essas tarefas estão descritas com mais detalhes nesta seção.

1. Verifique se a linha de base de patch predefinida da AWS para cada tipo de sistema operacional que você usa atende às suas necessidades. Se não atender, crie uma lista de referência de patches que defina um conjunto padrão de patches para esse tipo de nó gerenciado e a defina como o padrão.

1. Organize os nós gerenciados em grupos de patches usando etiquetas do Amazon Elastic Compute Cloud (Amazon EC2) (opcional, mas recomendado).

1. Execute um destes procedimentos:
   + (Recomendado) Configure uma política de patch no Quick Setup, uma ferramenta do Systems Manager que permite instalar patches que estão faltando de acordo com uma agenda para uma organização inteira, um subconjunto de unidades organizacionais ou uma única Conta da AWS. Para obter mais informações, consulte [Configurar a aplicação de patches para instâncias em uma organização usando uma política de patch do Quick Setup](quick-setup-patch-manager.md).
   + Crie uma janela de manutenção que use o documento Systems Manager (SSM document) `AWS-RunPatchBaseline` em um tipo de tarefa Run Command. Para obter mais informações, consulte [Tutorial: Create a maintenance window for patching using the console](maintenance-window-tutorial-patching.md).
   + Executar manualmente`AWS-RunPatchBaseline`em umRun Commandoperação. Para obter mais informações, consulte [Executar comandos no console](running-commands-console.md).
   + Aplique manualmente os patches nos nós sob demanda usando o recurso **Patch now**. Para obter mais informações, consulte [Aplicação de patches em nós gerenciados sob demanda](patch-manager-patch-now-on-demand.md).

1. Monitore a aplicação de patches para verificar a conformidade e investigar falhas.

**Topics**
+ [Criação de uma política de patch](patch-manager-create-a-patch-policy.md)
+ [Visualizar resumos do painel de patches](patch-manager-view-dashboard-summaries.md)
+ [Trabalhando com relatórios de conformidade de patch](patch-manager-compliance-reports.md)
+ [Aplicação de patches em nós gerenciados sob demanda](patch-manager-patch-now-on-demand.md)
+ [Trabalhar com linhas de base de patches](patch-manager-create-a-patch-baseline.md)
+ [Visualizar patches disponíveis](patch-manager-view-available-patches.md)
+ [Como criar e gerenciar grupos de patches](patch-manager-tag-a-patch-group.md)
+ [Integração do Patch Manager com o AWS Security Hub CSPM](patch-manager-security-hub-integration.md)

# Criação de uma política de patch
<a name="patch-manager-create-a-patch-policy"></a>

Uma política de patch é uma configuração que você define usando o Quick Setup, uma ferramenta do AWS Systems Manager. As políticas de patch fornecem um controle mais amplo e centralizado sobre suas operações de aplicação de patches do que o disponível com os outros métodos de configuração de patches. Uma política de patch define a programação e a lista de referência de patches a serem usados na aplicação automática de patches nos seus nós gerenciados.

Para obter mais informações, consulte os tópicos a seguir.
+ [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md)
+ [Configurar a aplicação de patches para instâncias em uma organização usando uma política de patch do Quick Setup](quick-setup-patch-manager.md)

# Visualizar resumos do painel de patches
<a name="patch-manager-view-dashboard-summaries"></a>

A guia **Painel** no Patch Manager oferece uma visualização de resumo no console que você pode usar para monitorar suas operações de aplicação de patches em uma visualização consolidada. O Patch Manager é uma ferramenta do AWS Systems Manager. Na guia **Dashboard** (Painel), você pode visualizar o seguinte:
+ Um snapshot de quantos nós gerenciados são ou não são compatíveis com as regras de aplicação de patches.
+ Um snapshot de quando os resultados de conformidade dos patches para os nós gerenciados foram gerados.
+ Uma contagem vinculada de quantos nós gerenciados não compatíveis existem para cada um dos motivos mais comuns para a não conformidade.
+ Uma lista vinculada das operações de patch mais recentes.
+ Uma lista vinculada das tarefas de patch recorrentes que foram configuradas.

**Para visualizar resumos do painel de patches**

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 **Patch Manager**.

1. Selecione a guia **Dashboard** (Painel).

1. Role até a seção que contém dados de resumo que você deseja visualizar:
   + **Gerenciamento de instâncias do Amazon EC**
   + **Resumo de conformidade**
   + **Contagens de não conformidade**
   + **Relatórios de conformidade**
   + **Operações baseadas em políticas que não sejam de patches**
   + **Tarefas recorrentes baseadas em políticas que não sejam de patches**

# Trabalhando com relatórios de conformidade de patch
<a name="patch-manager-compliance-reports"></a>

Use as informações nos tópicos a seguir para ajudar você a gerar e trabalhar com relatórios de conformidade de patches no Patch Manager, uma ferramenta do AWS Systems Manager.

As informações nos tópicos a seguir se aplicam independentemente do método ou tipo de configuração que você estiver usando para suas operações de aplicação de patch: 
+ Uma política de patch configurada no Quick Setup
+ Uma opção do Host Management configurada no Quick Setup
+ Uma janela de manutenção para executar um patch `Scan` ou tarefa `Install`
+ Uma operação **Patch now** (Aplicar patch agora) sob demanda

**Importante**  
Os relatórios de conformidade de patches são instantâneos pontuais gerados somente por operações bem-sucedidas de aplicação de patches. Cada relatório contém um tempo de captura que identifica quando o status de conformidade foi calculado.  
Se você tiver vários tipos de operações em andamento para verificar a conformidade dos patches em suas instâncias, observe que cada verificação substitui os dados de conformidade de patches de verificações anteriores. Como resultado, você pode obter resultados inesperados em seus dados de conformidade de patch. Para obter mais informações, consulte [Identificar a execução que criou os dados de conformidade do patch](patch-manager-compliance-data-overwrites.md).  
Para verificar qual lista de referência de patches foi usada para gerar as informações de conformidade mais recentes, navegue até a guia **Relatórios de conformidade** no Patch Manager, localize a linha do nó gerenciado sobre o qual deseja obter informações e escolha o ID da lista de referência na coluna **ID da lista de referência usada**.

**Topics**
+ [Visualizar resultados de conformidade de patches](patch-manager-view-compliance-results.md)
+ [Gere relatórios .csv de conformidade de patches](patch-manager-store-compliance-results-in-s3.md)
+ [Corrigir nós gerenciados fora de conformidade com o Patch Manager](patch-manager-noncompliant-nodes.md)
+ [Identificar a execução que criou os dados de conformidade do patch](patch-manager-compliance-data-overwrites.md)

# Visualizar resultados de conformidade de patches
<a name="patch-manager-view-compliance-results"></a>

Use esses procedimentos para exibir as informações de conformidade de patches sobre seus nós gerenciados.

Este procedimento se aplica a operações de patch que usam o`AWS-RunPatchBaseline`document. Para obter mais informações sobre como visualizar informações de conformidade de patches para operações de patch que usam o documento `AWS-RunPatchBaselineAssociation`, consulte [Identificar nós gerenciados fora de conformidade](patch-manager-find-noncompliant-nodes.md).

**nota**  
As operações de digitalização de patches para Quick Setup e Explorer usam o documento `AWS-RunPatchBaselineAssociation`. Quick Setup e Explorer são ambos ferramentas do AWS Systems Manager.

**Identificar a solução de patch para um problema específico de CVE (Linux)**  
Para muitos sistemas operacionais baseados em Linux, os resultados de conformidade de patch indicam quais problemas do boletim Common Vulnerabilities and Exposure (CVE) serão resolvidos por quais patches. Essas informações podem ajudar você a determinar com que urgência você precisa instalar um patch ausente ou com falha.

Os detalhes do CVE estão incluídos nas versões com suporte dos seguintes tipos de sistema operacional:
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux

**nota**  
Por padrão, o CentOS Stream não fornece informações do CVE sobre atualizações. No entanto, você pode permitir esse suporte usando repositórios de terceiros como o repositório Extra Packages for Enterprise Linux (EPEL) publicado pelo Fedora. Para obter mais informações, consulte [EPEL](https://fedoraproject.org/wiki/EPEL) no Fedora Wiki.  
No momento, os valores de ID de CVE são reportados somente para patches com um status de `Missing` ou `Failed`.

Você também pode adicionar IDs de CVE às listas de patches aprovados ou rejeitados em suas linhas de base de patch, conforme a situação e suas metas de patch o justificarem.

Para obter mais informações sobre como trabalhar com listas de patches aprovados e rejeitados, consulte os seguintes tópicos:
+ [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md)
+ [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md)
+ [Como funcionam as regras de linha de base de patch em sistemas baseados no Linux](patch-manager-linux-rules.md)
+ [Como os patches são instalados](patch-manager-installing-patches.md)

**nota**  
Em alguns casos, a Microsoft lança patches para aplicações que não especificam data e hora atualizadas. Nesses casos, uma data e hora atualizadas de `01/01/1970` são fornecidas por padrão.

## Visualizar resultados de conformidade de patches
<a name="viewing-patch-compliance-results-console"></a>

Use o procedimento a seguir para visualizar dados de conformidade do patch no console do AWS Systems Manager. 

**nota**  
Para obter informações sobre como gerar relatórios de conformidade de patches que foram baixados em um bucket do Amazon Simple Storage Service (Amazon S3), consulte [Gere relatórios .csv de conformidade de patches](patch-manager-store-compliance-results-in-s3.md).

**Para visualizar resultados de conformidade de patch do**

1. Execute um destes procedimentos:

   **Opção 1** (recomendada): navegar desde o Patch Manager, uma ferramenta do AWS Systems Manager:
   + No painel de navegação, escolha **Patch Manager**.
   + Selecione a guia **Compliance reporting** (Relatório de conformidade).
   + Na área **Detalhes de patch do nó**, escolha o ID de nó do nó gerenciado para o qual deseja analisar os resultados da conformidade de patches. Nós que são `stopped` ou `terminated` não serão exibidos aqui.
   + Na área **Detalhes**, na lista **Propriedades**, escolha **Patches**.

   **Opção 2**: navegar desde o Compliance, uma ferramenta do AWS Systems Manager:
   + No painel de navegação, selecione **Compliance** (Conformidade).
   + Para **Compliance resources summary** (Resumo dos recursos de conformidade), escolha um número na coluna para os tipos de recursos de patch que você deseja revisar, como **Non-Compliant resources** (Recursos sem conformidade).
   + Na lista **Recurso** abaixo, escolha o ID do nó gerenciado do qual você deseja rever os resultados de conformidade do patch.
   + Na área **Detalhes**, na lista **Propriedades**, escolha **Patches**.

   **Opção 3**: navegar desde o Fleet Manager, uma ferramenta do AWS Systems Manager.
   + No painel de navegação, escolha **Fleet Manager**.
   + Na área **Instâncias gerenciadas**, escolha o ID do nó gerenciado do qual você deseja rever os resultados da conformidade do patch.
   + Na área **Detalhes**, na lista **Propriedades**, escolha **Patches**.

1. (Opcional) Na caixa de pesquisa (![\[The Search icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/search-icon.png)), escolha um ou mais dos filtros disponíveis.

   Por exemplo, para o Red Hat Enterprise Linux (RHEL), escolha uma das seguintes opções:
   + Nome
   + Classificação
   + Estado
   + Gravidade

    Para o Windows Server, escolha uma das seguintes opções:
   + KB
   + Classificação
   + Estado
   + Gravidade

1. Escolha um dos valores disponíveis para o tipo de filtro escolhido. Por exemplo, se você escolheu **State** (Estado), agora escolha um estado de conformidade como **InstalledPendingReboot**, **Failed** (Com falha) ou **Missing** (Ausente).
**nota**  
No momento, os valores de ID de CVE são reportados somente para patches com um status de `Missing` ou `Failed`.

1. Dependendo do estado de conformidade do nó gerenciado, você poderá escolher qual ação tomar para corrigir qualquer nó não compatível.

   Por exemplo, você pode optar por corrigir os nós gerenciados não compatíveis imediatamente. Para obter informações sobre a aplicação de patches em nós gerenciados sob demanda, consulte [Aplicação de patches em nós gerenciados sob demanda](patch-manager-patch-now-on-demand.md).

   Para obter informações sobre dados de conformidade dos patches, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md).

# Gere relatórios .csv de conformidade de patches
<a name="patch-manager-store-compliance-results-in-s3"></a>

Você pode usar o console do AWS Systems Manager para gerar relatórios de conformidade de patch que são salvos como um arquivo.csv em um bucket do Amazon Simple Storage Service (Amazon S3) de sua escolha. Você pode gerar um único relatório sob demanda ou especificar uma programação para gerar os relatórios automaticamente. 

Os relatórios podem ser gerados para um único nó gerenciado ou para todos os nós gerenciados na sua Conta da AWS e Região da AWS selecionadas. Para um único nó, um relatório contém detalhes abrangentes, incluindo os IDs de patches relacionados a um nó que não esteja compatível. Para obter um relatório sobre todos os nós gerenciados, apenas informações resumidas e contagens de patches de nós não compatíveis são fornecidas.

Depois que um relatório é gerado, você pode usar uma ferramenta, como o Amazon Quick, para importar e analisar os dados. O Quick é um serviço de business intelligence (BI) que você pode usar para explorar e interpretar informações em um ambiente visual interativo. Para obter mais informações, consulte o [ Manual do usuário do Amazon Quick](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html).

**nota**  
Ao criar uma linha de lista de referência personalizada, é possível especificar um nível de gravidade de conformidade para patches aprovados por essa lista de referência de patches, como `Critical` ou `High`. Se o estado do patch de qualquer patch aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.

Você também pode especificar um tópico do Amazon Simple Notification Service (Amazon SNS) a ser usado para enviar notificações quando um relatório for gerado.

**Funções de serviço para gerar relatórios de conformidade de patch**  
Na primeira vez que você gera um relatório, o Systems Manager cria um perfil de admissão do Automation chamado `AWS-SystemsManager-PatchSummaryExportRole` para usar com o processo de exportação para o S3.

**nota**  
Se você estiver exportando dados de conformidade para um bucket criptografado do S3, será necessário atualizar a política de chave do AWS KMS associada para fornecer as permissões necessárias para `AWS-SystemsManager-PatchSummaryExportRole`. Por exemplo, adicione uma permissão semelhante a essa à política do AWS KMS de seu bucket do S3:  

```
{
    "Effect": "Allow",
    "Action": [
        "kms:GenerateDataKey"
    ],
    "Resource": "role-arn"
}
```
Substitua *role-arn* pelo nome do recurso da Amazon (ARN) criado em sua conta no formato `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`.  
Para saber mais, consulte [Políticas de chaves no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) no *Guia do desenvolvedor do AWS Key Management Service*.

Na primeira vez que você gerar um relatório em um agendamento, o Systems Manager cria outra função de serviço chamada`AWS-EventBridge-Start-SSMAutomationRole`, juntamente com a função de serviço`AWS-SystemsManager-PatchSummaryExportRole`(se ainda não tiver sido criado) para usar para o processo de exportação.`AWS-EventBridge-Start-SSMAutomationRole`permite que o Amazon EventBridge inicie uma automação usando o runbook[AWS-ExportPatchReporttos3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).

Recomendamos que não tente modificar essas políticas e funções. Isso pode causar falha na geração do relatório de conformidade do patch. Para obter mais informações, consulte [Solução de problemas da geração de relatórios de conformidade de patches](#patch-compliance-reports-troubleshooting).

**Topics**
+ [O que está em um relatório de conformidade de patch gerado?](#patch-compliance-reports-to-s3-examples)
+ [Gerar relatórios de conformidade de patch para um único nó gerenciado.](#patch-compliance-reports-to-s3-one-instance)
+ [Gerar relatórios de conformidade de patch para todos os nós gerenciados.](#patch-compliance-reports-to-s3-all-instances)
+ [Visualizar histórico de relatórios de conformidade de patches](#patch-compliance-reporting-history)
+ [Visualizar as programações de relatórios de conformidade de patches](#patch-compliance-reporting-schedules)
+ [Solução de problemas da geração de relatórios de conformidade de patches](#patch-compliance-reports-troubleshooting)

## O que está em um relatório de conformidade de patch gerado?
<a name="patch-compliance-reports-to-s3-examples"></a>

Este tópico fornece informações sobre os tipos de conteúdo incluídos nos relatórios de conformidade de patch que são gerados e baixados para um bucket do S3 especificado.

### Formato de relatório para um único nó gerenciado
<a name="patch-compliance-reports-to-s3-examples-single-instance"></a>

Um relatório gerado para um único nó gerenciado fornece informações resumidas e detalhadas.

[Baixar um relatório de exemplo (nó único)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)

Informações resumidas para um único nó gerenciado incluem o seguinte:
+ Índice
+ ID da instância
+ Nome da instância
+ Instance IP
+  nome-da-plataforma
+ Versão da plataforma
+ Versão do SSM Agent
+ Linha de base de patch
+ Grupo de patches
+ Compliance status (Status de conformidade)
+ Gravidade da conformidade
+ Contagem de patches de severidade crítica não compatível
+ Contagem de patches de alta gravidade não compatível
+ Contagem de patches de gravidade média não compatível
+ Contagem de patches de baixa gravidade não compatível
+ Contagem de patches de severidade informativa não compatível
+ Contagem de patches de gravidade não especificada não compatível

Informações detalhadas para um único nó gerenciado incluem o seguinte:
+ Índice
+ ID da instância
+ Nome da instância
+ Nome do patch
+ ID do BC/ID do patch
+ Estado do patch
+ Hora do último relatório
+ Nível de conformidade
+ Gravidade do patch
+ Classificação de patch
+ CVE ID
+ Linha de base de patch
+ URL de logs
+ Instance IP
+  nome-da-plataforma
+ Versão da plataforma
+ Versão do SSM Agent

**nota**  
Ao criar uma linha de lista de referência personalizada, é possível especificar um nível de gravidade de conformidade para patches aprovados por essa lista de referência de patches, como `Critical` ou `High`. Se o estado do patch de qualquer patch aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.

### Formato de relatório para todos os nós gerenciados
<a name="patch-compliance-reports-to-s3-examples-all-instances"></a>

Um relatório gerado para todos os nós gerenciados fornece apenas informações resumidas.

[Baixar um relatório de amostra (todos os nós gerenciados)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)

Informações resumidas para todos os nós gerenciados incluem o seguinte:
+ Índice
+ ID da instância
+ Nome da instância
+ Instance IP
+  nome-da-plataforma
+ Versão da plataforma
+ Versão do SSM Agent
+ Linha de base de patch
+ Grupo de patches
+ Compliance status (Status de conformidade)
+ Gravidade da conformidade
+ Contagem de patches de severidade crítica não compatível
+ Contagem de patches de alta gravidade não compatível
+ Contagem de patches de gravidade média não compatível
+ Contagem de patches de baixa gravidade não compatível
+ Contagem de patches de severidade informativa não compatível
+ Contagem de patches de gravidade não especificada não compatível

## Gerar relatórios de conformidade de patch para um único nó gerenciado.
<a name="patch-compliance-reports-to-s3-one-instance"></a>

Use o procedimento a seguir para gerar um relatório de resumo de patches para um único nó gerenciado na sua Conta da AWS. O relatório de um único nó gerenciado fornece detalhes sobre cada patch que estiver fora de conformidade, incluindo nomes de patches e IDs. 

**Para gerar relatórios de conformidade de patch para um único 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 **Patch Manager**.

1. Selecione a guia **Compliance reporting** (Relatório de conformidade).

1. Selecione o botão na linha do nó gerenciado para o qual você deseja gerar um relatório e escolha **View detail** (Visualizar detalhes).

1. Na seção **Patch summary** (Resumo do patch), escolha **Export to S3** (Exportar para o S3).

1. Para **Report name** (Nome do relatório), insira um nome para ajudar você a identificar o relatório mais tarde.

1. Para **Reporting frequency** (Frequência dos relatórios), escolha uma das seguintes opções:
   + **Sob demanda**— Cria um relatório único. Vá para a etapa 9.
   + **Em um horário**— Especifique uma programação recorrente para gerar relatórios automaticamente. Continue na etapa 8.

1. Para **Schedule type** (Tipo de programação), especifique uma expressão de taxa, como a cada 3 dias, ou forneça uma expressão cron para definir a frequência do relatório.

   Para obter informações sobre expressões cron, consulte [Referência: Expressões cron e rate para o Systems Manager](reference-cron-and-rate-expressions.md).

1. Para o **Bucket name** (Nome do bucket), selecione o nome de um bucket do S3 onde você deseja armazenar os arquivos .csv de relatório
**Importante**  
Se você estiver trabalhando em uma Região da AWS que foi lançada após 20 de março de 2019, selecione um bucket do S3 na mesma região. As regiões iniciadas após essa data foram desativadas por padrão. Para obter mais informações e uma lista dessas regiões, consulte [Enabling a Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) no *Referência geral da Amazon Web Services*.

1. (Opcional) Para enviar notificações quando o relatório for gerado, expanda a seção **Tópico do SNS** e escolha um tópico existente do Amazon SNS em **SNS topic Amazon Resource Name (ARN)** (Nome do recurso da Amazon (ARN) do tópico do SNS).

1. Selecione **Enviar**.

Para obter informações sobre como exibir um histórico de relatórios gerados, consulte [Visualizar histórico de relatórios de conformidade de patches](#patch-compliance-reporting-history).

Para obter informações sobre como visualizar detalhes das agendas de relatórios que você criou, consulte [Visualizar as programações de relatórios de conformidade de patches](#patch-compliance-reporting-schedules).

## Gerar relatórios de conformidade de patch para todos os nós gerenciados.
<a name="patch-compliance-reports-to-s3-all-instances"></a>

Use o procedimento a seguir para gerar um relatório de resumo de patches para todos os nós gerenciados na sua Conta da AWS. O relatório de todos os nós gerenciados indica quais nós estão fora de conformidade e os números de patches fora de conformidade. Ele não fornece os nomes ou outros identificadores dos patches. Para esses detalhes adicionais, você pode gerar um relatório de conformidade de patches para um único nó gerenciado. Para obter mais informações, consulte [Gerar relatórios de conformidade de patch para um único nó gerenciado.](#patch-compliance-reports-to-s3-one-instance) já abordado neste tópico. 

**Para gerar relatórios de conformidade de patch para todos os 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 **Patch Manager**.

1. Selecione a guia **Compliance reporting** (Relatório de conformidade).

1. Selecione **Export to S3** (Exportar para o S3). (Não selecione um ID de nó primeiro.)

1. Para **Report name** (Nome do relatório), insira um nome para ajudar você a identificar o relatório mais tarde.

1. Para **Reporting frequency** (Frequência dos relatórios), escolha uma das seguintes opções:
   + **Sob demanda**— Cria um relatório único. Vá para a etapa 8.
   + **Em um horário**— Especifique uma programação recorrente para gerar relatórios automaticamente. Continue na etapa 7.

1. Para **Schedule type** (Tipo de programação), especifique uma expressão de taxa, como a cada 3 dias, ou forneça uma expressão cron para definir a frequência do relatório.

   Para obter informações sobre expressões cron, consulte [Referência: Expressões cron e rate para o Systems Manager](reference-cron-and-rate-expressions.md).

1. Para o **Bucket name** (Nome do bucket), selecione o nome de um bucket do S3 onde você deseja armazenar os arquivos .csv de relatório
**Importante**  
Se você estiver trabalhando em uma Região da AWS que foi lançada após 20 de março de 2019, selecione um bucket do S3 na mesma região. As regiões iniciadas após essa data foram desativadas por padrão. Para obter mais informações e uma lista dessas regiões, consulte [Enabling a Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) no *Referência geral da Amazon Web Services*.

1. (Opcional) Para enviar notificações quando o relatório for gerado, expanda a seção **Tópico do SNS** e escolha um tópico existente do Amazon SNS em **SNS topic Amazon Resource Name (ARN)** (Nome do recurso da Amazon (ARN) do tópico do SNS).

1. Selecione **Enviar**.

Para obter informações sobre como exibir um histórico de relatórios gerados, consulte [Visualizar histórico de relatórios de conformidade de patches](#patch-compliance-reporting-history).

Para obter informações sobre como visualizar detalhes das agendas de relatórios que você criou, consulte [Visualizar as programações de relatórios de conformidade de patches](#patch-compliance-reporting-schedules).

## Visualizar histórico de relatórios de conformidade de patches
<a name="patch-compliance-reporting-history"></a>

Use as informações deste tópico para ajudar você a exibir detalhes sobre os relatórios de conformidade de patches gerados em seu Conta da AWS.

**Para visualizar o histórico dos relatórios de conformidade dos patches**

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 **Patch Manager**.

1. Selecione a guia **Compliance reporting** (Relatório de conformidade).

1. Selecione **View all S3 exports** (Exibir todas as exportações do S3) e, em seguida, selecione a guia **Export history** (Histórico de exportação).

## Visualizar as programações de relatórios de conformidade de patches
<a name="patch-compliance-reporting-schedules"></a>

Use as informações deste tópico para ajudar você a exibir detalhes sobre as agendas de relatórios de conformidade de patch criadas em seu Conta da AWS.

**Para visualizar o histórico dos relatórios de conformidade dos patches**

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 **Patch Manager**.

1. Selecione a guia **Compliance reporting** (Relatório de conformidade).

1. Selecione **View all S3 exports** (Exibir todas as exportações do S3) e, em seguida, selecione a guia **Report schedule rules** (Regras para o agendamento de relatórios).

## Solução de problemas da geração de relatórios de conformidade de patches
<a name="patch-compliance-reports-troubleshooting"></a>

Use as seguintes informações para ajudar você a solucionar problemas com a geração de relatórios de conformidade de patches no Patch Manager, uma ferramenta do AWS Systems Manager.

**Topics**
+ [Uma mensagem informa que a política `AWS-SystemsManager-PatchManagerExportRolePolicy` está corrompida](#patch-compliance-reports-troubleshooting-1)
+ [Depois de excluir políticas ou funções de conformidade de patch, os relatórios agendados não são gerados com êxito](#patch-compliance-reports-troubleshooting-2)

### Uma mensagem informa que a política `AWS-SystemsManager-PatchManagerExportRolePolicy` está corrompida
<a name="patch-compliance-reports-troubleshooting-1"></a>

**Problema**: Você recebe uma mensagem de erro semelhante à seguinte, indicando a`AWS-SystemsManager-PatchManagerExportRolePolicy`está corrompido:

```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any 
role that uses it, then try again. Systems Manager recreates the roles and policies 
you have deleted.
```
+ **Solução**: use o console do Patch Manager ou a AWS CLI para excluir as políticas e os perfis afetados antes de gerar um novo relatório de conformidade de patches.

**Para excluir a política corrompida usando o console**

  1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

  1. Execute um destes procedimentos:

     **Relatórios sob demanda**: se o problema ocorreu durante a geração de um relatório por solicitação único, na navegação à esquerda, escolha **Políticas**, pesquise por `AWS-SystemsManager-PatchManagerExportRolePolicy` e exclua a política. Depois, escolha **Perfis**, pesquise por `AWS-SystemsManager-PatchSummaryExportRole` e, em seguida, exclua o perfil.

     **Relatórios programados**: se o problema ocorreu durante a geração de um relatório em um agendamento, na navegação à esquerda, escolha **Políticas**, pesquise um de cada vez por`AWS-EventBridge-Start-SSMAutomationRolePolicy` e `AWS-SystemsManager-PatchManagerExportRolePolicy` e exclua cada política. Depois, escolha**Perfil**, pesquise um de cada vez por `AWS-EventBridge-Start-SSMAutomationRole` e `AWS-SystemsManager-PatchSummaryExportRole`, e exclua cada perfil.

**Para excluir a política corrompida usando a AWS CLI**

  Substitua os *valores dos espaços reservados* pelo ID de sua conta.
  + Se o problema ocorreu ao gerar um relatório único sob demanda, execute estes comandos:

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
    ```

    ```
    aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
    ```

    Se o problema ocorreu ao gerar um relatório sobre um agendamento, execute estes comandos:

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
    ```

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
    ```

    ```
    aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
    ```

    ```
    aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
    ```

  Após concluir todos os procedimento, siga as etapas para gerar ou agendar um novo relatório de conformidade de patch.

### Depois de excluir políticas ou funções de conformidade de patch, os relatórios agendados não são gerados com êxito
<a name="patch-compliance-reports-troubleshooting-2"></a>

**Problema**: A primeira vez que você gerar um relatório, o Systems Manager cria uma função de serviço e uma política a ser usada para o processo de exportação (`AWS-SystemsManager-PatchSummaryExportRole`e`AWS-SystemsManager-PatchManagerExportRolePolicy`). Na primeira vez que você gerar um relatório em uma agenda, o Systems Manager cria outra função de serviço e uma política (`AWS-EventBridge-Start-SSMAutomationRole`e`AWS-EventBridge-Start-SSMAutomationRolePolicy`). Eles permitem que o Amazon EventBridge inicie uma automação usando o runbook[AWS-ExportPatchReporttos3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).

Se você excluir qualquer uma dessas políticas ou funções, as conexões entre o agendamento e o bucket do S3 especificado e o tópico do Amazon SNS poderão ser perdidas. 
+ **Solução**: para contornar esse problema, recomendamos excluir o agendamento anterior e criar um novo agendamento para substituir o que estava enfrentando problemas.

# Corrigir nós gerenciados fora de conformidade com o Patch Manager
<a name="patch-manager-noncompliant-nodes"></a>

Os tópicos desta seção fornecem visões gerais de como identificar nós gerenciados que estão fora da conformidade de patch e como colocar esses nós em conformidade.

**Topics**
+ [Identificar nós gerenciados fora de conformidade](patch-manager-find-noncompliant-nodes.md)
+ [Valores de estados de conformidade de patches](patch-manager-compliance-states.md)
+ [Aplicação de patches em nós gerenciados fora de conformidade](patch-manager-compliance-remediation.md)

# Identificar nós gerenciados fora de conformidade
<a name="patch-manager-find-noncompliant-nodes"></a>

Os nós gerenciados fora de conformidade são identificados quando um dos dois documentos do AWS Systems Manager (documentos SSM) são executados. Esses documentos do SSM fazem referência à lista de referência de patches apropriada para cada nó gerenciado do Patch Manager, uma ferramenta do AWS Systems Manager. Em seguida, eles avaliam o estado do patch do nó gerenciado e, em seguida, disponibilizam os resultados de conformidade para você.

Há dois documentos do SSM que são usados para identificar ou atualizar nós gerenciados fora de conformidade: `AWS-RunPatchBaseline` e `AWS-RunPatchBaselineAssociation`. Cada um é usado por diferentes processos, e seus resultados de conformidade estão disponíveis em diferentes canais. A tabela a seguir descreve as diferenças entre esses documentos.

**nota**  
Dados de conformidade de patches do Patch Manager podem ser enviados para o AWS Security Hub CSPM. O Security Hub CSPM oferece uma visão abrangente dos alertas de segurança de alta prioridade e do status de conformidade. Também monitora o estado de aplicação de patches da sua frota. Para obter mais informações, consulte [Integração do Patch Manager com o AWS Security Hub CSPM](patch-manager-security-hub-integration.md). 


|  | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` | 
| --- | --- | --- | 
| Processos que usam o documento |  **Patch sob demanda** - Você pode verificar ou corrigir os nós gerenciados sob demanda usando a opção **Patch now** (Aplicar patch agora). Para mais informações, consulte [Aplicação de patches em nós gerenciados sob demanda](patch-manager-patch-now-on-demand.md). **Políticas de patch do Quick Setup do Systems Manager**: é possível criar uma configuração de patches no Quick Setup, uma ferramenta do AWS Systems Manager que pode verificar ou instalar patches que estão faltando em programações separadas para uma organização inteira, um subconjunto de unidades organizacionais ou uma única Conta da AWS. Para mais informações, consulte [Configurar a aplicação de patches para instâncias em uma organização usando uma política de patch do Quick Setup](quick-setup-patch-manager.md). **Execute um comando**: é possível executar `AWS-RunPatchBaseline` manualmente em uma operação no Run Command, uma ferramenta do AWS Systems Manager. Para mais informações, consulte [Executar comandos no console](running-commands-console.md). **Maintenance window (Janela de manutenção)**— Você pode criar uma janela de manutenção que use o documento do SSM`AWS-RunPatchBaseline`em umRun CommandTipo de tarefa. Para mais informações, consulte [Tutorial: Create a maintenance window for patching using the console](maintenance-window-tutorial-patching.md).  |  **Host Management do Quick Setup do Systems Manager**: é possível ativar uma opção de configuração do Host Management no Quick Setup para verificar as instâncias gerenciadas quanto à conformidade de patches todos os dias. Para mais informações, consulte [Configurar o gerenciamento de host do Amazon EC2 usando a Quick Setup](quick-setup-host-management.md). **Systems Manager [Explorer](Explorer.md)**: quando você habilita o Explorer, uma ferramenta do AWS Systems Manager, ele verifica suas instâncias gerenciadas regularmente no que diz respeito à conformidade de patches e relata os resultados no painel do Explorer.  | 
| Formato dos dados do resultado da verificação do patch |  Depois que o `AWS-RunPatchBaseline` é executado, o Patch Manager envia um objeto do `AWS:PatchSummary` ao Inventory, uma ferramenta do AWS Systems Manager. Esse relatório é gerado somente por operações de aplicação de patches bem-sucedidas e inclui um tempo de captura que identifica quando o status de conformidade foi calculado.  |  Depois que o `AWS-RunPatchBaselineAssociation` é executado, o Patch Manager envia um objeto do `AWS:ComplianceItem` ao Systems Manager Inventory.  | 
| Visualizar relatórios da conformidade de patches no console |  Você pode visualizar as informações de conformidade do patch para processos que usam o `AWS-RunPatchBaseline` em [Conformidade da configuração do Systems Manager](systems-manager-compliance.md) e em [Trabalhar com nós gerenciados](fleet-manager-managed-nodes.md). Para obter mais informações, consulte [Visualizar resultados de conformidade de patches](patch-manager-view-compliance-results.md).  |  Se você usa o Quick Setup para verificar as instâncias gerenciadas quanto à conformidade de patches, você pode ver o relatório de conformidade no [Fleet Manager do Systems Manager](fleet-manager.md). No console do Fleet Manager, escolha o ID do seu nó gerenciado. No menu **Geral**, escolha **Conformidade de configuração**. Se você usa o Explorer para verificar as instâncias gerenciadas quanto à conformidade de patches, você pode ver o relatório de conformidade no Explorer e no [OpsCenter do Systems Manager](OpsCenter.md).  | 
| AWS CLIComandos da para visualizar os resultados de conformidade de patches |  Para processos que usam o `AWS-RunPatchBaseline`, você pode usar o seguinte comando da AWS CLI para visualizar informações resumidas sobre patches em um nó gerenciado. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html)  |  Para processos que usam o `AWS-RunPatchBaselineAssociation`, você pode usar o seguinte comando da AWS CLI para visualizar informações resumidas sobre patches em uma instância. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html)  | 
| Sobre operações de aplicação de patches |  Para processos que usam o `AWS-RunPatchBaseline`, você especifica se deseja que a operação execute uma `Scan` somente operação ou uma operação `Scan and install`. Se o objetivo for identificar nós gerenciados fora de conformidade e não os corrigir, execute apenas uma operação `Scan`.  | Os processos do Quick Setup e Explorer, que usam o AWS-RunPatchBaselineAssociation, executam apenas uma operação de Scan. | 
| Mais informações |  [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)  |  [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)  | 

Para obter informações sobre os vários estados de conformidade dos patches que você poderá ver relatados, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md)

Para obter informações sobre como corrigir nós gerenciados que não estiverem em conformidade com os patches, consulte [Aplicação de patches em nós gerenciados fora de conformidade](patch-manager-compliance-remediation.md).

# Valores de estados de conformidade de patches
<a name="patch-manager-compliance-states"></a>

As informações sobre patches de um nó gerenciado incluem um relatório do estado, ou status, de cada patch individual.

**dica**  
Para atribuir um estado de conformidade de patch específico a um nó gerenciado, você pode usar o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) da AWS Command Line Interface (AWS CLI) ou a operação de API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html). A atribuição do estado da conformidade não tem suporte no console.

Use as informações nas tabelas a seguir para ajudar você a identificar por que um nó gerenciado pode estar fora de conformidade com patches.

## Valores de conformidade de patch para Debian Server e Ubuntu Server
<a name="patch-compliance-values-ubuntu"></a>

Para Debian Server e Ubuntu Server, as regras de classificação de pacotes em diferentes estados de conformidade estão descritas na tabela abaixo.

**nota**  
Tenha em mente o seguinte ao avaliar os valores de status `INSTALLED`, `INSTALLED_OTHER`, e `MISSING`: se você não marcar a caixa de seleção **Incluir atualizações não relacionadas à segurança** ao criar ou atualizar uma linha de base de patch, as versões candidatas a patches serão limitadas a patches nos repositórios a seguir.   
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS: `focal-security`
Ubuntu Server 22.04 LTS (`jammy-security`)
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
`debian-security` (Debian Server)
Se você selecionar a caixa de seleção **Incluir atualizações não relacionadas à segurança**, os patches de outros repositórios também são considerados.


| Estado do patch | Descrição | Compliance status (Status de conformidade) | 
| --- | --- | --- | 
|  **`INSTALLED`**  |  O patch está listado na lista de referência de patches e está instalado em seu nó gerenciado. Ele poderia ter sido instalado manualmente por um indivíduo, ou automaticamente pelo Patch Manager, quando o documento `AWS-RunPatchBaseline` foi executado em seu nó gerenciado.  | Compatível | 
|  **`INSTALLED_OTHER`**  |  O patch não está incluído na lista de referência ou não é aprovado por ela, mas está instalado em seu nó gerenciado. O patch pode ter sido instalado manualmente, o pacote pode ser uma dependência necessária de outro patch aprovado ou o patch pode ter sido incluído em uma operação InstallOverrideList. Se você não especificar `Block` como a ação **Rejected patches** (Patches rejeitados), os patches `INSTALLED_OTHER` também incluirão os patches instalados, porém rejeitados.   | Compatível | 
|  **`INSTALLED_PENDING_REBOOT`**  |  `INSTALLED_PENDING_REBOOT` pode significar uma de duas possibilidades: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-compliance-states.html) Em nenhum dos casos isso significa que um patch com esse status *exige* uma reinicialização, mas apenas que o nó não foi reinicializado desde que o patch foi instalado.  | incompatível: | 
|  **`INSTALLED_REJECTED`**  |  O patch está instalado em seu nó gerenciado, mas está especificado em uma lista de **patches rejeitados**. Isso geralmente significa que o patch foi instalado antes de ser adicionado a uma lista de patches rejeitados.  | incompatível: | 
|  **`MISSING`**  |  O patch foi aprovado na lista de referência, mas não está instalado em seu nó gerenciado. Se você configurar a tarefa do documento `AWS-RunPatchBaseline` para verificar (em vez de instalar), o sistema relatará esse status para os patches que foram localizados durante a verificação, mas que não foram instalados.  | incompatível: | 
|  **`FAILED`**  |  FAILED: o patch foi aprovado na linha de base, mas não pôde ser instalado. Para solucionar essa situação, reveja o resultado do comando para obter informações que possam ajudar você a entender o problema.  | incompatível: | 

## Valores de conformidade de patches para outros sistemas operacionais
<a name="patch-compliance-values"></a>

Para todos os sistemas operacionais além do Debian Server e Ubuntu Server, as regras de classificação de pacotes em diferentes estados de conformidade estão descritas na tabela abaixo. 


|  Estado do patch | Descrição | Valor da conformidade | 
| --- | --- | --- | 
|  **`INSTALLED`**  |  O patch está listado na lista de referência de patches e está instalado em seu nó gerenciado. Ele poderia ter sido instalado manualmente por um indivíduo, ou automaticamente pelo Patch Manager, quando o documento `AWS-RunPatchBaseline` foi executado em seu nó.  | Compatível | 
|  **`INSTALLED_OTHER`**1  |  O patch não está na lista de referência, mas está instalado em seu nó gerenciado. Há dois motivos possíveis para isso: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-compliance-states.html)  | Compatível | 
|  **`INSTALLED_REJECTED`**  |  O patch está instalado em seu nó gerenciado, mas está especificado em uma lista de patches rejeitados. Isso geralmente significa que o patch foi instalado antes de ser adicionado a uma lista de patches rejeitados.  | incompatível: | 
|  **`INSTALLED_PENDING_REBOOT`**  |  `INSTALLED_PENDING_REBOOT` pode significar uma de duas possibilidades: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/patch-manager-compliance-states.html) Em nenhum dos casos isso significa que um patch com esse status *exige* uma reinicialização, mas apenas que o nó não foi reinicializado desde que o patch foi instalado.  | incompatível: | 
|  **`MISSING`**  |  O patch foi aprovado na lista de referência, mas não está instalado em seu nó gerenciado. Se você configurar a tarefa do documento `AWS-RunPatchBaseline` para verificar (em vez de instalar), o sistema relatará esse status para os patches que foram localizados durante a verificação, mas que não foram instalados.  | incompatível: | 
|  **`FAILED`**  |  FAILED: o patch foi aprovado na linha de base, mas não pôde ser instalado. Para solucionar essa situação, reveja o resultado do comando para obter informações que possam ajudar você a entender o problema.  | incompatível: | 
|  **`NOT_APPLICABLE`**1  |  *Este estado de conformidade é apenas indicado em sistemas operacionais do Windows Server*. O patch está aprovado na lista de referência, mas o serviço ou recurso que o utiliza não está instalado em seu nó gerenciado. Por exemplo, um patch para o serviço do servidor Web, como os Serviços de Informações da Internet (IIS), mostraria `NOT_APPLICABLE` se fosse aprovado na linha de base, mas o serviço da Web não está instalado em seu nó gerenciado. Um patch também pode ser marcado como `NOT_APPLICABLE` se tiver sido substituído por uma atualização subsequente. Isso significa que a atualização posterior está instalada e a atualização `NOT_APPLICABLE` não é mais necessária.  | Não aplicável | 
| AVAILABLE\$1SECURITY\$1UPDATES |  *Este estado de conformidade é apenas indicado em sistemas operacionais do Windows Server*. Um patch de atualização de segurança disponível que não é aprovado pela lista de referência de patches pode ter um valor de conformidade `Compliant` ou `Non-Compliant`, conforme definido em uma lista de referência de patches personalizada. Ao criar ou atualizar uma lista de referência de patches, você escolhe o status que deseja atribuir aos patches de segurança que estão disponíveis, mas não aprovados, porque não atendem aos critérios de instalação especificados na lista de referência de patches. Por exemplo, os patches de segurança que você talvez queira instalar poderão ser ignorados se você tiver especificado um longo período de espera após o lançamento de um patch antes da instalação. Se uma atualização do patch for lançada durante o período de espera especificado, o período de espera para instalação do patch recomeçará. Se o período de espera for muito longo, várias versões do patch poderão ser lançadas, mas nunca instaladas. Para contagens resumidas de patches, quando um patch é informado como `AvailableSecurityUpdate`, ele sempre será incluído em `AvailableSecurityUpdateCount`. Se a lista de referência estiver configurada para informar esses patches como `NonCompliant`, eles também serão incluídos em `SecurityNonCompliantCount`. Se a lista de referência estiver configurada para informar esses patches como `Compliant`, eles não serão incluídos em `SecurityNonCompliantCount`. Esses patches são sempre informados com uma severidade não especificada e nunca são incluídos em `CriticalNonCompliantCount`.  |  Compatível ou Não compatível, dependendo da opção selecionada para as atualizações de segurança disponíveis.  Usando o console para criar ou atualizar uma lista de referência de patches, você especifica essa opção no campo **Status de conformidade das atualizações de segurança disponíveis**. Usando a AWS CLI para executar o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) ou [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html), você especifica essa opção no parâmetro `available-security-updates-compliance-status`.   | 

¹ Para patches com o estado `INSTALLED_OTHER` e `NOT_APPLICABLE`, o Patch Manager omite alguns dados dos resultados de consultas com base no comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html), como os valores para `Classification` e `Severity`. Isso é feito para ajudar a evitar ultrapassar o limite de dados para nós individuais no Inventory, uma ferramenta do AWS Systems Manager. Para visualizar todos os detalhes do patch, você pode usar o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html). 

# Aplicação de patches em nós gerenciados fora de conformidade
<a name="patch-manager-compliance-remediation"></a>

Muitas das mesmas ferramentas e processos do AWS Systems Manager que você pode usar para conferir a conformidade do patch em nós gerenciados podem ser usadas para colocar os nós em conformidade com as regras de patch que se aplicam atualmente a eles. Para promover a conformidade com patches em nós gerenciados, o Patch Manager, uma ferramenta do AWS Systems Manager, deve executar uma operação `Scan and install`. (Se o objetivo for apenas identificar nós gerenciados fora de conformidade e não os corrigir, execute uma operação `Scan`. Para obter mais informações, consulte [Identificar nós gerenciados fora de conformidade](patch-manager-find-noncompliant-nodes.md).)

**Instalar patches usando o Systems Manager**  
Você pode escolher entre várias ferramentas para executar um`Scan and install`operação:
+ (Recomendado) Configure uma política de patch no Quick Setup, uma ferramenta do Systems Manager que permite instalar patches que estão faltando de acordo com uma agenda para uma organização inteira, um subconjunto de unidades organizacionais ou uma única Conta da AWS. Para obter mais informações, consulte [Configurar a aplicação de patches para instâncias em uma organização usando uma política de patch do Quick Setup](quick-setup-patch-manager.md).
+ Crie uma janela de manutenção que use o documento Systems Manager (SSM document) `AWS-RunPatchBaseline` em um tipo de tarefa Run Command. Para mais informações, consulte [Tutorial: Create a maintenance window for patching using the console](maintenance-window-tutorial-patching.md).
+ Executar manualmente`AWS-RunPatchBaseline`em umRun Commandoperação. Para mais informações, consulte [Executar comandos no console](running-commands-console.md).
+ Instale patches sob demanda usando o**Patch agora**opção. Para mais informações, consulte [Aplicação de patches em nós gerenciados sob demanda](patch-manager-patch-now-on-demand.md).

# Identificar a execução que criou os dados de conformidade do patch
<a name="patch-manager-compliance-data-overwrites"></a>

Os dados de conformidade de patches representam um instantâneo pontual da última operação bem-sucedida de aplicação de patches. Cada relatório de conformidade inclui uma ID de execução e um tempo de captura que ajudam a identificar qual operação criou os dados de conformidade e quando eles foram gerados.

Se você tiver vários tipos de operações em andamento para verificar a conformidade dos patches em suas instâncias, cada verificação substitui os dados de conformidade de patches de verificações anteriores. Como resultado, você pode obter resultados inesperados em seus dados de conformidade de patch.

Por exemplo, suponha que você crie uma política de patch que verifique a conformidade dos patches todos os dias às 2h, horário local. Essa política de patch usa uma lista de referência de patches que visa patches com gravidade marcada como `Critical`, `Important` e `Moderate`. Essa lista de referência de patches também define alguns patches especificamente rejeitados. 

Suponha também que você já tenha uma janela de manutenção configurada para realizar a verificação do mesmo conjunto de nós gerenciados todos os dias às 4h da manhã, no horário local, que você não exclui nem desativa. A tarefa dessa janela de manutenção usa uma lista de referência de patches diferente, que visa apenas patches com gravidade `Critical` e não exclui nenhum patch específico. 

Quando essa segunda verificação é executada pela janela de manutenção, os dados de conformidade do patch da primeira verificação são excluídos e substituídos pela conformidade do patch da segunda verificação. 

Portanto, é altamente recomendável usar apenas um método automatizado para verificar e instalar em suas operações de aplicação de patch. Se você estiver configurando políticas de patch, exclua ou desative outros métodos de verificação de conformidade de patches. Para saber mais, consulte os seguintes tópicos: 
+ Para remover uma tarefa de operação de aplicação de patch de uma janela de manutenção: [Atualização ou cancelamento de registros de tarefas da janela de manutenção usando o console](sysman-maintenance-update.md#sysman-maintenance-update-tasks) 
+ Para excluir uma associação de State Manager: [Excluir associações](systems-manager-state-manager-delete-association.md).

Para desativar as verificações diárias de conformidade de patches em uma configuração de gerenciamento de host, faça o seguinte em Quick Setup:

1. No painel de navegação, escolha **Quick Setup**.

1. Selecione a configuração do Host Management a ser atualizada.

1. Escolha **Actions, Edit configuration** (Ações, Editar configuração).

1. Desmarque a caixa de seleção **Scan instances for missing patches daily** (Verificar instâncias em busca de patches ausentes diariamente).

1. Selecione **Atualizar**.

**nota**  
O uso da opção **Patch now** (Aplicar patch agora) para verificar a conformidade de um nó gerenciado também resulta na substituição dos dados de conformidade do patch. 

# Aplicação de patches em nós gerenciados sob demanda
<a name="patch-manager-patch-now-on-demand"></a>

Usar a opção **Patch agora** no Patch Manager, uma ferramenta do AWS Systems Manager, é possível executar operações de patch sob demanda no console do Systems Manager. Isso significa que você não precisa criar um agendamento para atualizar o status de conformidade dos os nós gerenciados ou instalar patches em nós não compatíveis. Você também não precisa alternar o console do Systems Manager entre o Patch Manager e a Maintenance Windows, uma ferramenta do AWS Systems Manager para configurar ou modificar uma janela de patch programada.

A opção **Patch now** (Aplicar patch agora) é especialmente útil quando você tiver que aplicar atualizações de dia zero ou instalar outros patches críticos aos nós gerenciados o mais rápido possível.

**nota**  
Há suporte para a aplicação de patches sob demanda para um único par Conta da AWS-Região da AWS por vez. Ela não pode ser usada com operações de aplicação de patches baseadas em *políticas de patch*. Recomendamos o uso de políticas de patch para manter todos os seus nós gerenciados em conformidade. Para mais informações sobre como trabalhar com políticas de patch, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).

**Topics**
+ [Como funciona o comando 'Patch now' (Aplicar patches agora)](#patch-on-demand-how-it-works)
+ [Executar 'Patch agora'](#run-patch-now)

## Como funciona o comando 'Patch now' (Aplicar patches agora)
<a name="patch-on-demand-how-it-works"></a>

Para executar o **Patch agora**, você especifica apenas duas configurações necessárias:
+ Verificar somente se há patches ausentes ou verificar *e* instalar patches em nós gerenciados
+ Em quais nós gerenciados executar a operação

Quando a operação **Patch now** (Aplicar patch agora) é executada, ela determina qual lista de referência de patches usar, da mesma forma que uma é selecionada para outras operações de aplicação de patches. Se um nó gerenciado estiver associado a um grupo de patches, a lista de referência de patches especificada para esse grupo será usada. Se o nó gerenciado não estiver associado a um grupo de patches, a operação usará a lista de referência de patches atualmente definida como padrão para o tipo de sistema operacional do nó gerenciado. Esta pode ser uma linha de base predefinida ou a linha de base personalizada que você definiu como padrão. Para obter mais informações sobre a seleção da lista de referência de patches, consulte [Grupos de patches](patch-manager-patch-groups.md). 

As opções que você pode especificar para **Patch now** (Aplicar patches agora) incluem escolher quando, ou se, reinicializar nós gerenciados após a aplicação do patch, especificar um bucket do Amazon Simple Storage Service (Amazon S3) para armazenar dados de log para a operação de patch e executar documentos do Systems Manager (documentos do SSM) como hooks de ciclo de vida durante a aplicação de patches.

### Limites de erro e simultaneidade para 'Patch now’ (Aplicar patch agora)
<a name="patch-on-demand-concurrency"></a>

Para as operações **Patch now** (Aplicar patch agora), a simultaneidade e as opções de limite de erro são resolvidas pelo Patch Manager. Você não precisa especificar quantos nós gerenciados devem ser corrigidos de uma só vez, nem quantos erros são permitidos antes que a operação falhe. O Patch Manager aplica as configurações de limite de simultaneidade e erro descritas nas tabelas a seguir quando você aplica patches sob demanda.

**Importante**  
Os seguintes limites se aplicam somente a operações `Scan and install`. Para operações `Scan`, o Patch Manager tenta verificar até 1.000 nós simultaneamente e continuar a varredura até que ele tenha encontrado até 1.000 erros.


**Simultaneidade: operações de instalação**  

| Número total de nós gerenciados na operação **Patch now** (Aplicar patch agora) | Número de nós gerenciados verificados ou corrigidos de cada vez | 
| --- | --- | 
| Menos de 25 | 1 | 
| 25-100 | 5% | 
| 101 a 1.000 | 8% | 
| Mais de 1.000 | 10% | 


**Limite de erro: operações de instalação**  

| Número total de nós gerenciados na operação **Patch now** (Aplicar patch agora) | Número de erros permitidos antes da falha da operação | 
| --- | --- | 
| Menos de 25 | 1 | 
| 25-100 | 5 | 
| 101 a 1.000 | 10 | 
| Mais de 1.000 | 10 | 

### Usando hooks de ciclo de vida "Patch agora"
<a name="patch-on-demand-hooks"></a>

**Patch agora** oferece a capacidade de executar documentos de Comando do SSM como hook s de ciclo de vida durante uma operação de aplicação de patches de `Install`. É possível usar esses hooks para tarefas como desligar aplicações antes de aplicar patches ou executar verificações de integridade em aplicações após a aplicação de patches ou após uma reinicialização. 

Para obter mais informações sobre hooks de ciclo de vida, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).

A tabela a seguir lista os hooks de ciclo de vida disponíveis para cada uma das três opções de reinicialização **Patch agora**, além de exemplos de usos para cada hook.


**Hooks de ciclo de vida e usos de amostra**  

| Opção de reinicializações | Hook: antes da instalação | Hook: após a instalação | Hook: na saída | Hook: após a reinicialização agendada | 
| --- | --- | --- | --- | --- | 
| Reinicializar, se necessário |  Execute um documento do SSM antes do início do patch. Exemplo de uso: encerre aplicações com segurança antes do início do processo de aplicação de patches.   |  Execute um documento SSM no final da operação de patch e antes da reinicialização do nó gerenciado. Exemplo de uso: execute operações como a instalação de aplicações de terceiros antes de uma possível reinicialização.  |  Execute um documento do SSM após concluir a operação de aplicação de patches e reinicializar as instâncias. Exemplo de uso: verifique se as aplicações estão sendo executadas conforme esperado após a aplicação de patches.  | Não disponível | 
| Não reinicialize minhas instâncias | O mesmo que acima. |  Execute um documento do SSM no final da operação de patch. Exemplo de uso: verifique se as aplicações estão sendo executadas conforme esperado após a aplicação de patches.  |  *Não disponível*   |  *Não disponível*   | 
| Agendar um tempo de reinicialização | O mesmo que acima. | Igual a de Não reinicialize minhas instâncias. | Não disponível |  Execute um documento do SSM imediatamente após uma reinicialização programada estar concluída. Exemplo de uso: verifique se as aplicações estão sendo executadas conforme esperado após a reinicialização.  | 

## Executar 'Patch agora'
<a name="run-patch-now"></a>

Use o procedimento a seguir para corrigir os nós gerenciados sob demanda.

**Para executar 'Patch agora'**

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 **Patch Manager**.

1. Selecione **Patch now** (Patch agora).

1. Para a **Patching operation** (Operação de aplicação de patches), escolha uma das seguintes opções:
   + **Scan** (Verificar): o Patch Manager localiza quais patches estão faltando em seus nós gerenciados, mas não os instala. Você pode visualizar os resultados no painel **Compliance** (Conformidade) ou em outras ferramentas que você usar para exibir a conformidade dos patches.
   + **Scan e install** (Verificar e instalar): o Patch Manager localiza quais patches estão faltando em seus nós gerenciados e os instala.

1. Use esta etapa se escolher **Scan e instalação** na etapa anterior. Em **Reboot Option** (Opção de reinicialização), escolha uma das seguintes opções:
   + **Reboot if needed** (Reinicializar se necessário): após a instalação, o Patch Manager reinicializa os nós gerenciados somente se necessário para concluir uma instalação de patch.
   + **Não reinicialize minhas instâncias**: após a instalação, Patch Manager não reinicializará os nós. Você pode reinicializar nós manualmente ao escolher ou gerenciar reinicializações fora do Patch Manager.
   + **Schedule a reboot time** (Agendar um tempo de reinicialização): especifique a data, a hora e o fuso horário UTC para o Patch Manager para reiniciar os nós gerenciados. Depois de executar a operação **Patch now** (Aplicar o patch agora), a reinicialização agendada será listada como uma associação no State Manager com o nome `AWS-PatchRebootAssociation`.
**Importante**  
Se você cancelar a operação principal de aplicação de patch após o início, a associação `AWS-PatchRebootAssociation` em State Manager NÃO será cancelada automaticamente. Para evitar reinicializações inesperadas, será necessário excluir manualmente `AWS-PatchRebootAssociation` de State Manager se você não desejar mais que a reinicialização programada ocorra. Se isso não for feito, pode haver reinicializações não planejadas do sistema que podem afetar as workloads de produção. Você pode encontrar essa associação no console do Systems Manager em **State Manager** > **Associações**.

1. Em **Instances to patch** (Instâncias que receberão os patches) escolha uma das seguintes opções:
   + **Patch all instances** (Aplicar patch a todas as instâncias): o Patch Manager executa a operação especificada em todos os nós gerenciados na sua Conta da AWS, na Região da AWS atual.
   + **Patch only the target instances I specify** (Aplicar patch somente aos nós gerenciados de destino que eu especificar): você especifica com quais nós gerenciados você deve trabalhar, na próxima etapa.

1. Use esta etapa se escolher **Patch apenas as instâncias de destino que eu especificar** na etapa anterior. Na seção **Target selection** (Seleção de destino), identifique os nós onde você deseja executar essa operação especificando etiquetas, selecionando nós manualmente ou especificando um grupo de recursos.
**nota**  
Se um nó gerenciado que você espera ver não estiver listado, consulte [Solução de problemas de disponibilidade do nó gerenciado](fleet-manager-troubleshooting-managed-nodes.md) para obter dicas de solução de problemas.  
Se você optar por segmentar um grupo de recursos, observe que os grupos de recursos que são baseados em um AWS CloudFormation ainda devem ser marcados com a tag `aws:cloudformation:stack-id` padrão. Se ele tiver sido removido, o Patch Manager poderá não conseguir determinar quais nós gerenciados pertencem ao grupo de recursos.

1. (Opcional) Em **Patching log storage** (Aplicação de patches ao armazenamento de logs), se você quiser criar e salvar logs dessa operação de patch, selecione o bucket S3 para armazenar os logs.
**nota**  
As permissões do S3 que concedem a possibilidade de gravar os dados em um bucket do S3 são as do perfil de instância (para instâncias do EC2) ou perfil de serviço do IAM (máquinas ativadas para ambientes híbridos) atribuído à instância, e não as do usuário do IAM que realiza essa tarefa. Para obter mais informações, consulte [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md) ou [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). Além disso, se o bucket do S3 especificado estiver em uma conta da Conta da AWS diferente, verifique se o perfil da instância ou a função de serviço do IAM associado ao nó gerenciado tenha as permissões necessárias para gravar nesse bucket.

1. (Opcional) Se você deseja executar documentos do SSM como hooks de ciclo de vida durante pontos específicos da operação de patch, faça o seguinte:
   + Selecione **Usar hooks de ciclo de vida**.
   + Para cada hook disponível, selecione o documento do SSM a ser executado no ponto especificado da operação:
     + Antes da instalação
     + Após a instalação
     + Na saída
     + Após a reinicialização agendada
**nota**  
O documento padrão,`AWS-Noop`, não executa operações.

1. Selecione **Patch now** (Patch agora).

   A página **Association execution targets (Destinos de execução da associação)** é aberta. (O Patch agora usa associações no State Manager, uma ferramenta do AWS Systems Manager, para suas operações). Na área **Operation summary** (Resumo da operação), você pode monitorar o status da verificação ou a aplicação de patches em seus nós gerenciados.

# Trabalhar com linhas de base de patches
<a name="patch-manager-create-a-patch-baseline"></a>

Uma lista de referência de patches no Patch Manager, uma ferramenta do AWS Systems Manager, define quais patches são aprovados para instalação em nós gerenciados. Você pode especificar individualmente os patches aprovados ou rejeitados. Pode também criar regras de aprovação automática para especificar que determinados tipos de atualização (por exemplo, atualizações essenciais) devem ser aprovados automaticamente. A lista se rejeitados substitui as regras e a lista de aprovados. Para usar uma lista de patches aprovados para instalar pacotes específicos, primeiro remova todas as regras de aprovação automática. Se você identificar explicitamente um patch como rejeitado, ele não será aprovado ou instalado, mesmo que ele corresponda a todos os critérios em uma regra de aprovação automática. Além disso, um patch é instalado em um nó gerenciado somente se ele se aplicar ao software do nó gerenciado, mesmo que tenha sido aprovado para o mesmo.

**Topics**
+ [Visualizar as listas de referência de patches predefinidas da AWS](patch-manager-view-predefined-patch-baselines.md)
+ [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md)
+ [Definir uma linha de base de patches existente como padrão](patch-manager-default-patch-baseline.md)

**Mais informações**  
+ [Linhas de base de patch](patch-manager-patch-baselines.md)

# Visualizar as listas de referência de patches predefinidas da AWS
<a name="patch-manager-view-predefined-patch-baselines"></a>

O Patch Manager, uma ferramenta do AWS Systems Manager, inclui uma lista de referência de patches predefinida para cada sistema operacional compatível com o Patch Manager. Você pode usar essas linhas de base de patch (não pode personalizá-las) ou pode criar suas próprias. O procedimento a seguir descreve como visualizar uma linha de base de patch predefinida para ver se ela atende às suas necessidades. Para saber mais sobre linhas de base de patch, consulte [Listas de referência de patches predefinidas e personalizadas](patch-manager-predefined-and-custom-patch-baselines.md).

**Para visualizar linhas de base de patch predefinida da AWS**

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 **Patch Manager**.

1. Na lista de linhas de base de patch, escolha o ID da linha de base de uma das linhas de base de patch predefinidas.

   - ou -

   Se estiver acessando o Patch Manager pela primeira vez na Região da AWS atual, escolha **Iniciar com uma visão geral**, escolha a guia **Listas de referência de patches** e escolha o ID da lista de referência de uma das listas de referência de patches predefinidas.
**nota**  
Para o Windows Server, três linhas de base de patch predefinidas são fornecidas. As listas de referência de patches `AWS-DefaultPatchBaseline` e `AWS-WindowsPredefinedPatchBaseline-OS` oferecem suporte apenas às atualizações do sistema operacional Windows em si. O `AWS-DefaultPatchBaseline` é usado como lista de referência de patches para nós gerenciados do Windows Server, a menos que você especifique outra lista de referência de patches. As definições de configuração nestas duas linhas de base de patch são as mesmas. O mais novo dos dois,`AWS-WindowsPredefinedPatchBaseline-OS`, foi criado para distingui-lo da terceira linha de base de patch predefinida paraWindows Server. Essa lista de referência do patch, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, pode ser usada para aplicar patches tanto ao sistema operacional Windows Server quanto a aplicações compatíveis lançadas pela Microsoft.  
Para obter mais informações, consulte [Definir uma linha de base de patches existente como padrão](patch-manager-default-patch-baseline.md).

1. Escolha a guia **Regras de aprovação** e analise a configuração da lista de referência de patches.

1. Se a configuração for aceitável para os nós gerenciados, você poderá passar para o procedimento [Como criar e gerenciar grupos de patches](patch-manager-tag-a-patch-group.md). 

   - ou -

   Para criar sua própria linha de base de patch padrão, prossiga para o tópico [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md).

# Trabalhando com linhas de base de patch personalizadas
<a name="patch-manager-manage-patch-baselines"></a>

O Patch Manager, uma ferramenta do AWS Systems Manager, inclui uma lista de referência de patches predefinida para cada sistema operacional compatível com o Patch Manager. Você pode usar essas linhas de base de patch (não pode personalizá-las) ou pode criar suas próprias. 

Os procedimentos a seguir descrevem como criar sua própria lista de referência de patches personalizada. Para saber mais sobre linhas de base de patch, consulte [Listas de referência de patches predefinidas e personalizadas](patch-manager-predefined-and-custom-patch-baselines.md).

**Topics**
+ [Criar uma lista de referência de patches personalizada para o Linux](patch-manager-create-a-patch-baseline-for-linux.md)
+ [Criar uma lista de referência de patches personalizada para o macOS](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Criar uma lista de referência de patches personalizada para o Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
+ [Atualizar ou excluir uma linha de base de patches personalizada](patch-manager-update-or-delete-a-patch-baseline.md)

# Criar uma lista de referência de patches personalizada para o Linux
<a name="patch-manager-create-a-patch-baseline-for-linux"></a>

Use o procedimento a seguir para criar uma lista de referência de patches personalizada para os nós gerenciados do Linux no Patch Manager, uma ferramenta do AWS Systems Manager. 

Para obter informações sobre como criar uma lista de referência de patches para nós gerenciados do macOS, consulte [Criar uma lista de referência de patches personalizada para o macOS](patch-manager-create-a-patch-baseline-for-macos.md). Para obter informações sobre como criar uma lista de referência de patches para nós gerenciados do Windows, consulte [Criar uma lista de referência de patches personalizada para o Windows Server](patch-manager-create-a-patch-baseline-for-windows.md).

**Para criar uma lista de referência de patches personalizada para os nós gerenciados do Linux**

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 **Patch Manager**.

1. Escolha a guia **Listas de referência do patches** e, em seguida, escolha **Criar lista de referência de patches**.

   - ou -

   Se estiver acessando o Patch Manager pela primeira vez na Região da AWS atual, escolha **Iniciar com uma visão geral**, escolha a guia **Listas de referência de patches** e depois escolha **Criar lista de referência de patches**.

1. Em **Nome**, insira um nome para a nova lista de referência de patches, como `MyRHELPatchBaseline`.

1. (Opcional) Em **Description (Descrição)**, insira uma descrição para essa linha de base de patch.

1. Em **Operating System (Sistema operacional)**, escolha um sistema operacional, como `Red Hat Enterprise Linux`.

1. Se você quiser começar a usar essa lista de referência de patch como o padrão para o sistema operacional assim que a criar, selecione a opção **Set this patch baseline as the default patch baseline for *operating system name* instances** (Definir esta lista de referência de patch como a padrão para instâncias do [nome do sistema operacional]).
**nota**  
Essa opção está disponível somente se você acessou pela primeira vez Patch Manager antes do lançamento [das políticas de patch](patch-manager-policies.md) em 22 de dezembro de 2022.  
Para obter informações sobre como definir uma linha de base de patch existente como padrão, consulte [Definir uma linha de base de patches existente como padrão](patch-manager-default-patch-baseline.md).

1. Na seção **Approval rules for operating-systems (Regras de aprovação para sistemas operacionais)**, use os campos para criar uma ou mais regras de aprovação automática.
   + **Produtos**: a versão dos sistemas operacionais à qual a regra de aprovação se aplica, como `RedhatEnterpriseLinux7.4`. A seleção padrão é `All`.
   + **Classificação**: o tipo de patch ao qual a regra de aprovação se aplica, como `Security` ou `Enhancement`. A seleção padrão é `All`. 
**dica**  
É possível configurar uma lista de referência de patches para controlar se atualizações secundárias de versão do Linux são instaladas, como o RHEL 7.8. As atualizações de versões secundárias podem ser instaladas automaticamente pelo Patch Manager, desde que a atualização esteja disponível no repositório apropriado.  
Para sistemas operacionais Linux, atualizações de versões secundárias não são classificadas de forma consistente. Elas podem ser classificadas como correções de bugs ou atualizações de segurança, ou não classificadas, mesmo dentro da mesma versão do kernel. Veja a seguir algumas opções para controlar se uma lista de referência de patches fará a instalação.   
**Opção 1**: a regra de aprovação mais ampla para garantir que atualizações de versões secundárias sejam instaladas quando disponíveis é especificar **Classificação** como `All` (\$1) e escolher a opção **Incluir atualizações não relacionadas a segurança**.
**Opção 2**: para garantir que os patches para uma versão do sistema operacional estejam instalados, é possível usar um curinga (\$1) para especificar o formato de kernel na seção **Exceções de patch** da lista de referência. Por exemplo, o formato do kernel para o RHEL 7.\$1 é `kernel-3.10.0-*.el7.x86_64`.  
Insira `kernel-3.10.0-*.el7.x86_64` na lista **Patches aprovados** na lista de referência de patches para garantir que todos os patches, inclusive atualizações de versões secundárias, sejam aplicados aos nós gerenciados do RHEL 7.\$1. (Se você souber o nome exato do pacote de um patch de versão secundária, poderá inseri-lo.)
**Opção 3**: é possível obter o máximo de controle sobre quais patches são aplicados aos nós gerenciados, inclusive atualizações de versões secundárias, usando o parâmetro [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) no documento `AWS-RunPatchBaseline`. Para obter mais informações, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
   + **Severity (Gravidade)**: o valor da gravidade dos patches aos quais a regra se aplica, como `Critical`. A seleção padrão é `All`. 
   + **Auto-approval (Aprovação automática)**: o método para selecionar patches para aprovação automática.
**nota**  
Como não é possível determinar de forma confiável as datas de lançamento dos pacotes de atualização do Ubuntu Server, as opções de aprovação automática não são compatíveis com esse sistema operacional.
     + **Approve patches after a specified number of days** (Aprovar patches após um número específico de dias): o número de dias que o Patch Manager deve aguardar para aprovar automaticamente um patch após o lançamento ou última atualização de um patch. Insira qualquer número inteiro de zero (0) a 360. Para a maioria dos casos, recomendamos que não aguarde mais de 100 dias.
     + **Approve patches released up to a specific date** (Aprovar patches lançados até uma data específica): a data de lançamento do patch para a qual o Patch Manager aplica automaticamente todos os patches lançados ou com a última atualização nessa data ou antes dela. Por exemplo, se você especificar 7 de julho de 2023, nenhum patch lançado ou com última atualização em ou após 8 de julho de 2023 será instalado automaticamente.
   + (Opcional) **Relatórios de conformidade**: o nível de gravidade que você deseja atribuir aos patches aprovados pela lista de referência, como `Critical` ou `High`.
**nota**  
Se você especificar um nível de relatório de conformidade e o estado do patch de qualquer patch aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.
   + **Include non-security updates (Incluir atualizações não relacionadas a segurança)**: marque a caixa de seleção para instalar patches do sistema operacional Linux não relacionados a segurança que estão disponíveis no repositório de origem, além de patches de segurança. 

   Para obter mais informações sobre como trabalhar com regras de aprovação em uma linha de base de patch personalizada, consulte [Linhas de base personalizadas](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).

1. Se quiser explicitamente aprovar qualquer patch, além das suas regras de aprovação, faça o seguinte na seção **Patch exceptions (Exceções de patch)**:
   + Em **Approved patches (Patches aprovados)**, insira uma lista separada por vírgulas dos patches que você deseja aprovar.

     Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).
   + (Opcional) Em **Approved patches compliance level (Nível de conformidade dos patches aprovados)**, atribua um nível de conformidade aos patches na lista.
   + Se algum dos patches aprovados que você especificar não for relacionado a segurança, marque a caixa **Incluir atualizações não relacionadas a segurança** para que esse patch também seja instalado no sistema operacional Linux.

1. Se quiser explicitamente rejeitar qualquer patch que de outra forma atendem às suas regras de aprovação, faça o seguinte na seção **Patch exceptions (Exceções de patch)**:
   + Em **Rejected patches (Patches rejeitados)**, insira uma lista separada por vírgulas dos patches que você deseja rejeitar.

     Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).
   + Em **Rejected patches action** (Ação para patches rejeitados), selecione a ação que o Patch Manager deve realizar para patches incluídos na lista **Rejected patches** (Patches rejeitados).
     + **Permitir como dependência**: um pacote na lista **Rejected patches** (Patches rejeitados) é instalado apenas se for uma dependência de outro. Ele é considerado compatível com a linha de base de patch e seu status é relatado como *InstalledOther*. Essa é a ação padrão se nenhuma opção for especificada.
     + **Bloco**: os pacotes na lista **Patches rejeitados** e pacotes que os incluem como dependências não são instalados pelo Patch Manager em nenhuma circunstância. Se um pacote tiver sido instalado antes de ser adicionado à lista **Patches rejeitados** ou instalado fora do Patch Manager, ele será considerado como fora conformidade com a lista de referência de patches e seu status será indicado como *InstalledRejected*.
**nota**  
O Patch Manager pesquisa dependências de patches recursivamente.

1. (Opcional) Se quiser especificar repositórios de patches alternativos para versões diferentes de um sistema operacional, como *AmazonLinux2016.03* e *AmazonLinux2017.09*, faça o seguinte para cada produto na seção **Patch sources (Origens de patches)**:
   + Em **Name (Nome)**, insira um nome para ajudar você a identificar a configuração de origem.
   + Em **Product (Produto)**, selecione a versão dos sistemas operacionais para a qual o repositório de origem de patches é destinado, como `RedhatEnterpriseLinux7.4`.
   + Em **Configuração**, insira o valor da configuração do repositório a ser usado formato apropriado:

------
#### [  Example for yum repositories  ]

     ```
     [main]
     name=MyCustomRepository
     baseurl=https://my-custom-repository
     enabled=1
     ```

**dica**  
Para obter informações sobre outras opções disponíveis para a configuração do repositório yum, consulte [dnf.conf (5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html).

------
#### [  Examples for Ubuntu Server and Debian Server ]

      `deb http://security.ubuntu.com/ubuntu jammy main` 

      `deb https://site.example.com/debian distribution component1 component2 component3` 

     As informações de repositório para repositórios do Ubuntu Server devem ser especificadas em uma única linha. Para obter mais exemplos e informações, consulte [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) no site *Ubuntu Server Manuals* e [sources.list format](https://wiki.debian.org/SourcesList#sources.list_format) no *Debian Wiki*.

------

     Selecione **Add another source** (Adicionar outra origem) para especificar um repositório de origem para cada versão do sistema operacional adicional, até um máximo de 20.

     Para obter mais informações sobre repositórios de origem de patches alternativos, consulte [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md).

1. (Opcional) Em **Manage tags (Gerenciar tags)**, aplique um ou mais pares de nome/valor de chave de tag à linha de base de patch.

   Tags são metadados opcionais que você atribui a um recurso. As tags permitem categorizar um recurso de diferentes formas, como por finalidade, proprietário ou ambiente. Por exemplo, você pode querer marcar uma linha de base de patch para identificar o nível de gravidade dos patches especificados, a família de sistemas operacionais aos quais ela se aplica e o tipo de ambiente. Nesse caso, você pode especificar tags semelhantes aos seguintes pares de nome/valor:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=OS,Value=RHEL`
   + `Key=Environment,Value=Production`

1. Escolha **Create patch baseline**.

# Criar uma lista de referência de patches personalizada para o macOS
<a name="patch-manager-create-a-patch-baseline-for-macos"></a>

Use o procedimento a seguir para criar uma lista de referência de patches personalizada para os nós gerenciados do macOS no Patch Manager, uma ferramenta do AWS Systems Manager. 

Para obter informações sobre como criar uma lista de referência de patches para nós gerenciados do Windows Server, consulte [Criar uma lista de referência de patches personalizada para o Windows Server](patch-manager-create-a-patch-baseline-for-windows.md). Para obter informações sobre como criar uma lista de referência de patches para nós gerenciados do Linux, consulte [Criar uma lista de referência de patches personalizada para o Linux](patch-manager-create-a-patch-baseline-for-linux.md). 

**nota**  
Não há suporte para macOS em todas as Regiões da AWS. Para obter mais informações sobre o suporte a instâncias do EC2 para macOS, consulte [Instâncias Mac do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) no *Guia do usuário do Amazon EC2*.

**Para criar uma lista personalizada de referência de patches para os nós gerenciados do macOS**

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 **Patch Manager**.

1. Escolha a guia **Listas de referência do patches** e, em seguida, escolha **Criar lista de referência de patches**.

   - ou -

   Se estiver acessando o Patch Manager pela primeira vez na Região da AWS atual, escolha **Iniciar com uma visão geral**, escolha a guia **Listas de referência de patches** e depois escolha **Criar lista de referência de patches**.

1. Em **Nome**, insira um nome para a nova lista de referência de patches, como `MymacOSPatchBaseline`.

1. (Opcional) Em **Description (Descrição)**, insira uma descrição para essa linha de base de patch.

1. Em **Operating system (Sistema operacional)**, escolha macOS.

1. Se você quiser começar a usar essa lista de referência de patch como o padrão para o macOS assim que a criar, selecione a opção **Set this patch baseline as the default patch baseline for macOS instances** (Definir esta lista de referência de patch como a padrão para instâncias do Windows Server).
**nota**  
Essa opção está disponível somente se você acessou pela primeira vez Patch Manager antes do lançamento [das políticas de patch](patch-manager-policies.md) em 22 de dezembro de 2022.  
Para obter informações sobre como definir uma linha de base de patch existente como padrão, consulte [Definir uma linha de base de patches existente como padrão](patch-manager-default-patch-baseline.md).

1. Na seção **Approval rules for operating-systems (Regras de aprovação para sistemas operacionais)**, use os campos para criar uma ou mais regras de aprovação automática.
   + **Produto**: a versão dos sistemas operacionais à qual a regra de aprovação se aplica, como `BigSur11.3.1` ou `Ventura13.7`. A seleção padrão é `All`.
   + **Classificação**: o gerenciador ou gerenciadores de pacotes aos quais você deseja aplicar pacotes durante o processo de aplicação de patches. Você pode escolher entre as seguintes opções:
     + atualização de software
     + installer
     + brew
     + brew cask

     A seleção padrão é `All`. 
   + (Opcional) **Relatórios de conformidade**: o nível de gravidade que você deseja atribuir aos patches aprovados pela lista de referência, como `Critical` ou `High`.
**nota**  
Se você especificar um nível de relatório de conformidade e o estado do patch de qualquer patch aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.

   Para obter mais informações sobre como trabalhar com regras de aprovação em uma linha de base de patch personalizada, consulte [Linhas de base personalizadas](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).

1. Se quiser explicitamente aprovar qualquer patch, além das suas regras de aprovação, faça o seguinte na seção **Patch exceptions (Exceções de patch)**:
   + Em **Approved patches (Patches aprovados)**, insira uma lista separada por vírgulas dos patches que você deseja aprovar.

     Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).
   + (Opcional) Em **Approved patches compliance level (Nível de conformidade dos patches aprovados)**, atribua um nível de conformidade aos patches na lista.

1. Se quiser explicitamente rejeitar qualquer patch que de outra forma atendem às suas regras de aprovação, faça o seguinte na seção **Patch exceptions (Exceções de patch)**:
   + Em **Rejected patches (Patches rejeitados)**, insira uma lista separada por vírgulas dos patches que você deseja rejeitar.

     Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).
   + Em **Rejected patches action** (Ação para patches rejeitados), selecione a ação que o Patch Manager deve realizar para patches incluídos na lista **Rejected patches** (Patches rejeitados).
     + **Permitir como dependência**: um pacote na lista **Rejected patches** (Patches rejeitados) é instalado apenas se for uma dependência de outro. Ele é considerado compatível com a linha de base de patch e seu status é relatado como *InstalledOther*. Essa é a ação padrão se nenhuma opção for especificada.
     + **Bloco**: os pacotes na lista **Patches rejeitados** e pacotes que os incluem como dependências não são instalados pelo Patch Manager em nenhuma circunstância. Se um pacote tiver sido instalado antes de ser adicionado à lista **Patches rejeitados** ou instalado fora do Patch Manager, ele será considerado como fora conformidade com a lista de referência de patches e seu status será indicado como *InstalledRejected*.

1. (Opcional) Em **Manage tags (Gerenciar tags)**, aplique um ou mais pares de nome/valor de chave de tag à linha de base de patch.

   Tags são metadados opcionais que você atribui a um recurso. As tags permitem categorizar um recurso de diferentes formas, como por finalidade, proprietário ou ambiente. Por exemplo, você pode querer marcar uma linha de base de patch para identificar o nível de gravidade dos patches especificados, a família de sistemas operacionais aos quais ela se aplica e o tipo de ambiente. Nesse caso, você pode especificar tags semelhantes aos seguintes pares de nome/valor:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=PackageManager,Value=softwareupdate`
   + `Key=Environment,Value=Production`

1. Escolha **Create patch baseline**.

# Criar uma lista de referência de patches personalizada para o Windows Server
<a name="patch-manager-create-a-patch-baseline-for-windows"></a>

Use o procedimento a seguir para criar uma lista de referência de patches personalizada para os nós gerenciados do Windows no Patch Manager, uma ferramenta do AWS Systems Manager. 

Para obter informações sobre como criar uma lista de referência de patches para nós gerenciados do Linux, consulte [Criar uma lista de referência de patches personalizada para o Linux](patch-manager-create-a-patch-baseline-for-linux.md). Para obter informações sobre como criar uma lista de referência de patches para nós gerenciados do macOS, consulte [Criar uma lista de referência de patches personalizada para o macOS](patch-manager-create-a-patch-baseline-for-macos.md).

Para obter um exemplo de criação de uma lista de referência de patches limitada à instalação apenas do Windows Service Packs, consulte [Tutorial: Criar uma lista de referência de patches para instalar o Windows Service Packs usando o console](patch-manager-windows-service-pack-patch-baseline-tutorial.md).

**Para criar uma linha de base de patch personalizada (Windows)**

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 **Patch Manager**.

1. Escolha a guia **Listas de referência do patches** e, em seguida, escolha **Criar lista de referência de patches**. 

   - ou -

   Se estiver acessando o Patch Manager pela primeira vez na Região da AWS atual, escolha **Iniciar com uma visão geral**, escolha a guia **Listas de referência de patches** e depois escolha **Criar lista de referência de patches**.

1. Em **Nome**, insira um nome para a nova lista de referência de patches, como `MyWindowsPatchBaseline`.

1. (Opcional) Em **Description (Descrição)**, insira uma descrição para essa linha de base de patch.

1. Em **Operating system (Sistema operacional)**, escolha `Windows`.

1. Em **Status de conformidade de atualizações de segurança disponíveis**, escolha o status que você deseja atribuir aos patches de segurança que estão disponíveis, mas não aprovados, porque não atendem aos critérios de instalação especificados na lista de referência de patches, **Não compatível** ou **Compatível**.

   Cenário de exemplo: os patches de segurança que você talvez queira instalar poderão ser ignorados se você tiver especificado um longo período de espera após o lançamento de um patch antes da instalação. Se uma atualização do patch for lançada durante o período de espera especificado, o período de espera para instalação do patch recomeçará. Se o período de espera for muito longo, várias versões do patch poderão ser lançadas, mas nunca instaladas.

1. Se você deseja começar a usar essa linha de base de patch como o padrão para o Windows assim que a criar, selecione **Set this patch baseline as the default patch baseline for Windows Server instances (Definir essa linha de base de patch como a linha de base de patch padrão para instâncias do Windows Server)**.
**nota**  
Essa opção está disponível somente se você acessou pela primeira vez Patch Manager antes do lançamento [das políticas de patch](patch-manager-policies.md) em 22 de dezembro de 2022.  
Para obter informações sobre como definir uma linha de base de patch existente como padrão, consulte [Definir uma linha de base de patches existente como padrão](patch-manager-default-patch-baseline.md).

1. Na seção **Approval rules for operating systems (Regras de aprovação para sistemas operacionais)**, use os campos para criar uma ou mais regras de aprovação automática.
   + **Produto**: a versão dos sistemas operacionais à qual a regra de aprovação se aplica, como `WindowsServer2012`. A seleção padrão é `All`.
   + **Classificação**: o tipo de patch ao qual a regra de aprovação se aplica, como `CriticalUpdates`, `Drivers` e `Tools`. A seleção padrão é `All`. 
**dica**  
É possível incluir instalações do Windows Service Pack nas regras de aprovação, incluindo `ServicePacks` ou escolhendo `All` na lista **Classificação**. Para ver um exemplo, consulte [Tutorial: Criar uma lista de referência de patches para instalar o Windows Service Packs usando o console](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
   + **Severity (Gravidade)**: o valor da gravidade dos patches aos quais a regra se aplica, como `Critical`. A seleção padrão é `All`. 
   + **Auto-approval (Aprovação automática)**: o método para selecionar patches para aprovação automática.
     + **Approve patches after a specified number of days** (Aprovar patches após um número específico de dias): o número de dias que o Patch Manager deve aguardar para aprovar automaticamente um patch após o lançamento ou atualização de um patch. Insira qualquer número inteiro de zero (0) a 360. Para a maioria dos casos, recomendamos que não aguarde mais de 100 dias.
     + **Approve patches released up to a specific date** (Aprovar patches lançados até uma data específica): a data de lançamento do patch para a qual o Patch Manager aplica automaticamente todos os patches lançados ou com a última atualização nessa data ou antes dela. Por exemplo, se você especificar 7 de julho de 2023, nenhum patch lançado ou com última atualização em ou após 8 de julho de 2023 será instalado automaticamente.
   + (Opcional) **Compliance reporting (Relatórios de conformidade)**: o nível de gravidade que você deseja atribuir aos patches aprovados pela linha de base, como `High`.
**nota**  
Se você especificar um nível de relatório de conformidade e o estado do patch de qualquer patch aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.

1. Na seção **Approval rules for applications** (Regras de aprovação para aplicações), use os campos para criar uma ou mais regras de aprovação automática.
**nota**  
Em vez de especificar regras de aprovação, você pode especificar listas de patches aprovados e rejeitados como exceções de patch. Consulte as etapas 10 e 11. 
   + **Product family (Família de produtos)**: a família de produtos Microsoft geral para a qual você deseja especificar uma regra, como `Office` ou `Exchange Server`.
   + **Produto**: a versão do aplicativo à qual a regra de aprovação se aplica, como `Office 2016` ou `Active Directory Rights Management Services Client 2.0 2016`. A seleção padrão é `All`.
   + **Classification (Classificação)**: o tipo de patch ao qual a regra de aprovação se aplica, como `CriticalUpdates`. A seleção padrão é `All`. 
   + **Severity (Gravidade)**: o valor da gravidade dos patches aos quais a regra se aplica, como `Critical`. A seleção padrão é `All`. 
   + **Auto-approval (Aprovação automática)**: o método para selecionar patches para aprovação automática.
     + **Approve patches after a specified number of days** (Aprovar patches após um número específico de dias): o número de dias que o Patch Manager deve aguardar para aprovar automaticamente um patch após o lançamento ou atualização de um patch. Insira qualquer número inteiro de zero (0) a 360. Para a maioria dos casos, recomendamos que não aguarde mais de 100 dias.
     + **Approve patches released up to a specific date** (Aprovar patches lançados até uma data específica): a data de lançamento do patch para a qual o Patch Manager aplica automaticamente todos os patches lançados ou com a última atualização nessa data ou antes dela. Por exemplo, se você especificar 7 de julho de 2023, nenhum patch lançado ou com última atualização em ou após 8 de julho de 2023 será instalado automaticamente.
   + (Opcional) **Relatórios de conformidade**: o nível de gravidade que você deseja atribuir aos patches aprovados pela lista de referência, como `Critical` ou `High`.
**nota**  
Se você especificar um nível de relatório de conformidade e o estado do patch de qualquer patch aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.

1. (Opcional) Se você quiser explicitamente aprovar qualquer patch em vez de permitir que os patches sejam selecionados de acordo com regras de aprovação, faça o seguinte na seção **Patch exceptions** (Exceções de patch):
   + Em **Approved patches (Patches aprovados)**, insira uma lista separada por vírgulas dos patches que você deseja aprovar.

     Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).
   + (Opcional) Em **Approved patches compliance level (Nível de conformidade dos patches aprovados)**, atribua um nível de conformidade aos patches na lista.

1. Se quiser explicitamente rejeitar qualquer patch que de outra forma atendem às suas regras de aprovação, faça o seguinte na seção **Patch exceptions (Exceções de patch)**:
   + Em **Rejected patches (Patches rejeitados)**, insira uma lista separada por vírgulas dos patches que você deseja rejeitar.

     Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).
   + Em **Rejected patches action** (Ação para patches rejeitados), selecione a ação que o Patch Manager deve realizar para patches incluídos na lista **Rejected patches** (Patches rejeitados).
     + **Permitir como dependência**: o Windows Server não é compatível com o conceito de dependências de pacotes. Se um pacote estiver na lista de **Patches rejeitados** e já estiver instalado no nó, seu status será relatado como `INSTALLED_OTHER`. Qualquer pacote que ainda não esteja instalado no nó é ignorado. 
     + **Bloquear**: os pacotes na lista de **patches rejeitados** não são instalados pelo Patch Manager em nenhuma circunstância. Se um pacote tiver sido instalado antes de ser adicionado à lista **Patches rejeitados** ou instalado fora do Patch Manager, ele será considerado como fora conformidade com a lista de referência de patches e seu status será indicado como `INSTALLED_REJECTED`.

     Para obter mais informações sobre ações de pacotes rejeitados, consulte [Opções de lista de patches rejeitados em listas de referência de patches personalizados](patch-manager-windows-and-linux-differences.md#rejected-patches-diff). 

1. (Opcional) Em **Manage tags (Gerenciar tags)**, aplique um ou mais pares de nome/valor de chave de tag à linha de base de patch.

   Tags são metadados opcionais que você atribui a um recurso. As tags permitem categorizar um recurso de diferentes formas, como por finalidade, proprietário ou ambiente. Por exemplo, você pode querer marcar uma linha de base de patch para identificar o nível de gravidade dos patches especificados, a família de sistemas operacionais aos quais ela se aplica e o tipo de ambiente. Nesse caso, você pode especificar tags semelhantes aos seguintes pares de nome/valor:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=OS,Value=RHEL`
   + `Key=Environment,Value=Production`

1. Escolha **Create patch baseline**.

# Atualizar ou excluir uma linha de base de patches personalizada
<a name="patch-manager-update-or-delete-a-patch-baseline"></a>

Você pode atualizar ou excluir uma lista de referência de patches' personalizada que criou no Patch Manager, uma ferramenta do AWS Systems Manager. Ao atualizar uma linha de base do patch, você pode alterar seu nome ou descrição, suas regras de aprovação e suas exceções para os patches aprovados e rejeitados. Você também pode atualizar as tags que são aplicadas à linha de base de patch. Você não pode alterar o tipo de sistema operacional para o qual uma linha de base de patch foi criada e não pode fazer alterações em uma linha de base de patch predefinida fornecida pela AWS.

## Atualizar ou excluir uma linha de base de patches
<a name="sysman-maintenance-update-mw"></a>

Siga estas etapas para atualizar ou excluir uma linha de base de patch.

**Importante**  
 Tenha cuidado ao excluir uma lista de referência de patches personalizada que possa ser usada por uma configuração de política de patch no Quick Setup.  
Se você estiver usando uma [configuração de política de patch](patch-manager-policies.md) em Quick Setup, as atualizações feitas nas listas de referência de patches personalizadas serão sincronizadas com Quick Setup uma vez por hora.   
Se uma lista de referência de patches personalizada que foi referenciada em uma política de patch for excluída, um banner será exibido na página **Configuration details** (Detalhes da configuração) do Quick Setup da sua política de patch. O banner informa que a política de patch faz referência a uma lista de referência de patches que não existe mais e que as operações de aplicação de patches subsequentes falharão. Nesse caso, retorne à página **Configurations** (Configurações) do Quick Setup, selecione a configuração Patch Manager e escolha **Actions** (Ações), **Edit configuration** (Editar configuração). O nome da lista de referência de patches excluída será destacado, e você deverá selecionar uma nova lista de referência de patches para o sistema operacional afetado.

**Para atualizar ou excluir uma linha de base de patches**

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 **Patch Manager**.

1. Escolha a linha de base de patch que você deseja atualizar ou excluir e execute uma das seguintes ações:
   + Para remover a lista de referência de patches da sua Conta da AWS, escolha **Delete** (Excluir). O sistema solicitará que você confirme suas ações. 
   + Para fazer alterações no nome ou na descrição da linha de base de patch, nas regras de aprovação ou nas exceções de patch, escolha **Edit (Editar)**. Na página **Edit patch baseline (Editar linha de base de patch)**, altere as opções e os valores desejados e escolha **Save changes (Salvar alterações)**. 
   + Para adicionar, alterar ou excluir tags aplicadas à linha de base de patch, escolha a guia **Tags** e depois escolha **Edit tags (Editar tags)**. Na página **Edit patch baseline tags (Editar tags de linha de base de patch)**, faça atualizações nas tags da linha de base de patch e escolha **Save changes (Salvar alterações)**. 

   Para obter informações sobre as opções de configuração que podem ser feitas, consulte [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md).

# Definir uma linha de base de patches existente como padrão
<a name="patch-manager-default-patch-baseline"></a>

**Importante**  
Qualquer seleção padrão da lista de referência de patches que você fizer aqui não se aplicará às operações de aplicação de patches baseadas em uma política de patch. As políticas de patch usam suas próprias especificações de lista de referência de patches. Para obter mais informações sobre políticas de patch, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).

Ao criar uma lista de referência de patches personalizada em Patch Manager, uma ferramenta do AWS Systems Manager, você pode defini-la como padrão para o tipo de sistema operacional associado assim que a criar. Para mais informações, consulte [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md).

Você também pode definir uma linha de base de patch existente como padrão para um tipo de sistema operacional.

**nota**  
As etapas a serem seguidas variam se você acessou o Patch Manager pela primeira vez antes ou depois do lançamento das políticas de patch de 22 de dezembro de 2022. Se você usou o Patch Manager antes dessa data, use o procedimento do console. Caso contrário, use o procedimento da AWS CLI. O menu **Ações** referenciado no procedimento do console não é exibido em regiões em que o Patch Manager não era usado antes do lançamento das políticas de patch.

**Para definir uma linha de base de patch como 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, escolha **Patch Manager**.

1. Selecione a guia **Patch baselines** (Listas de referência do patch).

1. Na lista de referências do patch, escolha o botão de uma lista de referência do patch que não esteja definida como padrão para um tipo de sistema operacional.

   A coluna **Default baseline (Linha de base padrão)** indica quais linhas de base estão atualmente definidas como padrões.

1. No menu **Actions (Ações)**, escolha **Set default patch baseline (Definir linha de base de patch padrão)**.
**Importante**  
O menu **Ações** não está disponível se você não trabalhou com o Patch Manager na Conta da AWS e na região atuais antes de 22 de dezembro de 2022. Consulte a **observação** anterior neste tópico para obter mais informações.

1. Na caixa de diálogo de confirmação, escolha **Set default (Definir padrão)**.

**Para definir uma lista de referência de patches como padrão (AWS CLI)**

1. Execute o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html) para ver uma lista das listas de referência de patches disponíveis e seus IDs e nomes do recurso da Amazon (ARNs).

   ```
   aws ssm describe-patch-baselines
   ```

1. Execute o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) para definir uma lista de referência como padrão para o sistema operacional ao qual ela está associada. Substitua *baseline-id-or-ARN* pelo ID da lista de referência de patches personalizada ou da lista de referência predefinida a ser usada. 

------
#### [ Linux & macOS ]

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id baseline-id-or-ARN
   ```

   Veja a seguir um exemplo de como definir uma lista de referência personalizada como padrão.

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id pb-abc123cf9bEXAMPLE
   ```

   Veja a seguir um exemplo de como definir uma lista de referência predefinida gerenciada pela AWS como padrão.

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id baseline-id-or-ARN
   ```

   Veja a seguir um exemplo de como definir uma lista de referência personalizada como padrão.

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id pb-abc123cf9bEXAMPLE
   ```

   Veja a seguir um exemplo de como definir uma lista de referência predefinida gerenciada pela AWS como padrão.

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
   ```

------

# Visualizar patches disponíveis
<a name="patch-manager-view-available-patches"></a>

O Patch Manager, uma ferramenta do AWS Systems Manager, permite visualizar todos os patches disponíveis para um sistema operacional especificado e, opcionalmente, uma versão específica do sistema operacional.

**dica**  
Para gerar uma lista de patches disponíveis e salvá-los em um arquivo, você pode usar o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) e especificar a [saída](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html) de sua preferência.

**Para visualizar patches disponíveis**

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 **Patch Manager**.

1. Selecione a guia **Patches**.

   - ou -

   Se estiver acessando Patch Manager pela primeira vez no atual Região da AWS, escolha **Start with an overview** (Iniciar com uma visão geral) e depois escolha a guia **Patches**.
**nota**  
No Windows Server, a guia **Patches** exibe as atualizações que estão disponíveis no Windows Server Update Services (WSUS).

1. Para **Operating system** (Sistema operacional), escolha o sistema operacional para o qual você deseja visualizar os patches disponíveis, como`Windows` ou `Amazon Linux`.

1. (Opcional) Para **Product** (Produto), escolha uma versão do sistema operacional, como `WindowsServer2019` ou `AmazonLinux2018.03`.

1. (Opcional) Para adicionar ou remover colunas de informações para seus resultados, escolha o botão Configure (Configurar) (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/configure-button.png)) no canto superior direito da lista de **Patches**. (Por padrão, a guia **Patches** exibe colunas para apenas alguns dos metadados de patch disponíveis).

   Para obter informações sobre os tipos de metadados que você pode adicionar à visualização, consulte [Patch](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html) na *Referência de API do AWS Systems Manager*.

# Como criar e gerenciar grupos de patches
<a name="patch-manager-tag-a-patch-group"></a>

Se *não* estiver usando políticas de patch em suas operações, você pode organizar suas iniciativas de aplicação de patches, adicionando nós gerenciados aos grupos de patches com o uso de etiquetas.

**nota**  
Os grupos de patches não são usados em operações de aplicação de patches em *políticas de patch*. Para obter informações sobre como trabalhar com políticas de patch, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).  
Não há suporte no console à funcionalidade de grupos de patches para pares de conta-região que ainda não usavam grupos de patches antes do lançamento do suporte à política de patches em 22 de dezembro de 2022. A funcionalidade de grupo de patches ainda está disponível em pares de conta-região que começaram a usar grupos de patches antes dessa data.

Para usar etiquetas em operações de aplicação de patches, é necessário aplicar a chave de etiqueta `Patch Group` ou `PatchGroup` aos nós gerenciados. Também é necessário especificar o nome que você deseja dar ao grupo de patches como o valor da etiqueta. Você pode especificar qualquer valor de tag, mas a chave da tag precisa ser `Patch Group` ou `PatchGroup`.

`PatchGroup` (sem espaço) é obrigatório, se você tiver [permissão para etiquetas nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS). 

Depois de agrupar os nós gerenciados usando etiquetas, adicione o valor do grupo de patches a uma lista de referência de patches. Ao registrar o grupo de patches em uma linha de base de patch, você garante que os patches corretos sejam instalados durante a aplicação de patches. Para obter mais informações sobre grupos de patches, consulte [Grupos de patches](patch-manager-patch-groups.md).

Conclua as tarefas deste tópico para preparar seus nós gerenciados para aplicação de patches usando etiquetas com seus nós e a lista de referência de patches. A tarefa 1 é necessária somente para aplicar patches em instâncias do Amazon EC2. A tarefa 2 é necessária somente para aplicar patches em instâncias que não sejam do EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). A tarefa 3 é necessária para todos os nós gerenciados.

**dica**  
Também é possível adicionar tags aos nós gerenciados usando o comando da AWS CLI `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` ou a operação de API do Systems Manager ssm-agent-minimum-s3-permissions-required`[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)`.

**Topics**
+ [Tarefa 1: adicionar instâncias do EC2 a um grupo de patches usando tags](#sysman-patch-group-tagging-ec2)
+ [Tarefa 2: Adicionar nós gerenciados a um grupo de patches usando etiquetas](#sysman-patch-group-tagging-managed)
+ [Tarefa 3: Adicionar um grupo de patches a uma linha de base de patches](#sysman-patch-group-patchbaseline)

## Tarefa 1: adicionar instâncias do EC2 a um grupo de patches usando tags
<a name="sysman-patch-group-tagging-ec2"></a>

É possível adicionar etiquetas a instâncias do EC2 usando o console do Systems Manager ou o console do Amazon EC2. Essa tarefa é necessária somente para corrigir instâncias do Amazon EC2.

**Importante**  
Não é possível aplicar a tag `Patch Group` (com um espaço) a uma instância do Amazon EC2 se a opção **Allow tags in instance metadata** (Permitir tags em metadados de instância) estiver habilitada na instância. Permitir tags em metadados de instância impede que nomes de chaves de tag contenham espaços. Se você tiver [permissão para tags nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), é necessário usar a chave de tag `PatchGroup` (sem um espaço).

**Opção 1: para adicionar instâncias do EC2 a um grupo de patches (console do Systems Manager)**

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 **Fleet Manager**.

1. Na lista **Instâncias gerenciadas**, selecione o ID de uma instância gerenciada do EC2 que você deseja configurar para aplicação de patches. Os IDs de nós para instâncias do EC2 começam com `i-`.
**nota**  
Ao usar o console e a AWS CLI do Amazon EC2, é possível aplicar tags `Key = Patch Group` ou `Key = PatchGroup` a instâncias que ainda não estejam configuradas para uso com o Systems Manager.  
Se um nó gerenciado que você espera ver não estiver listado, consulte [Solução de problemas de disponibilidade do nó gerenciado](fleet-manager-troubleshooting-managed-nodes.md) para obter dicas de solução de problemas.

1. Selecione a guia **Etiquetas** e escolha **Editar**.

1. Na coluna esquerda, insira **Patch Group** ou **PatchGroup**. Se você tiver [permissão para tags nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), é necessário usar `PatchGroup` (sem um espaço).

1. Na coluna direita, insira um valor de etiqueta para servir como nome do grupo de patches.

1. Escolha **Salvar**.

1. Repita esse procedimento para adicionar outras instâncias do EC2 ao mesmo grupo de patches.

**Opção 2: para adicionar instâncias do EC2 a um grupo de patches (console do Amazon EC2)**

1. Abra o [console do Amazon EC2](https://console.aws.amazon.com/ec2/) e depois escolha **Instances** (Instâncias) no painel de navegação. 

1. Na lista de instâncias, escolha uma instância que você deseja configurar para aplicação de patch.

1. No menu **Ações**, escolha **Configurações da instância** e, depois, **Gerenciar etiquetas**.

1. Selecione **Adicionar nova tag**.

1. Em **Key** (Chave), insira **Patch Group** ou **PatchGroup**. Se você tiver [permissão para tags nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), é necessário usar `PatchGroup` (sem um espaço).

1. Em **Valor**, insira um valor para servir como nome do grupo de patches.

1. Escolha **Salvar**.

1. Repita esse procedimento para adicionar outras instâncias ao mesmo grupo de patches.

## Tarefa 2: Adicionar nós gerenciados a um grupo de patches usando etiquetas
<a name="sysman-patch-group-tagging-managed"></a>

Siga as etapas deste tópico para adicionar etiquetas aos dispositivos principais do AWS IoT Greengrass e aos nós gerenciados ativados para ambiente híbrido que não são do EC2 (mi-\$1). Essa tarefa é necessária somente para corrigir instâncias que não sejam do EC2 em um ambiente híbrido e multinuvem.

**nota**  
Não é possível adicionar etiquetas para nós gerenciados que não são do EC2 usando o console do Amazon EC2.

**Para adicionar nós gerenciados que não são do EC2 a um grupo de patches (console do Systems Manager)**

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 **Fleet Manager**.

1. Na lista **Nós gerenciados**, escolha o nome do nó gerenciado que você deseja configurar para a aplicação de patch.
**nota**  
Se um nó gerenciado que você espera ver não estiver listado, consulte [Solução de problemas de disponibilidade do nó gerenciado](fleet-manager-troubleshooting-managed-nodes.md) para obter dicas de solução de problemas.

1. Selecione a guia **Etiquetas** e escolha **Editar**.

1. Na coluna esquerda, insira **Patch Group** ou **PatchGroup**. Se você tiver [permissão para tags nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), é necessário usar `PatchGroup` (sem um espaço).

1. Na coluna direita, insira um valor de etiqueta para servir como nome do grupo de patches.

1. Escolha **Salvar**.

1. Repita esse procedimento para adicionar outros nós gerenciados ao mesmo grupo de patches.

## Tarefa 3: Adicionar um grupo de patches a uma linha de base de patches
<a name="sysman-patch-group-patchbaseline"></a>

Para associar uma lista de referência de patches específica aos nós gerenciados, você deve adicionar o valor do grupo de patches a essa lista. Ao registrar o grupo de patches em uma linha de base de patch, você pode garantir que os patches corretos sejam instalados durante uma aplicação de patches. Essa tarefa é necessária para aplicar patches em instâncias do EC2, nós gerenciados que não são do EC2 ou ambos.

Para obter mais informações sobre grupos de patches, consulte [Grupos de patches](patch-manager-patch-groups.md).

**nota**  
As etapas a serem seguidas variam se você acessou o Patch Manager pela primeira vez antes ou depois do lançamento das [políticas de patch](patch-manager-policies.md) de 22 de dezembro de 2022.

**Para adicionar um grupo de patches a uma lista de referência de patches (console do Systems Manager)**

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 **Patch Manager**.

1. Se você estiver acessando o Patch Manager pela primeira vez na Região da AWS atual, e a página inicial do Patch Manager for aberta, escolha **Iniciar com uma visão geral**.

1. Escolha a guia **Listas de referência de patches** e, em **Listas de referência de patches**, escolha o nome da lista de referência de patches que você deseja configurar para o grupo de patches.

   Se você só acessou o Patch Manager depois do lançamento das políticas de patch, é necessário escolher uma lista de referência personalizada que você criou.

1. Se a página de detalhes **ID da lista de referência** incluir um menu **Ações**, faça o seguinte: 
   + Escolha **Actions (Ações)** e depois **Modify patch groups (Modificar grupos de patches)**.
   + Insira o *valor* da etiqueta que você adicionou aos nós gerenciados e [Tarefa 2: Adicionar nós gerenciados a um grupo de patches usando etiquetas](#sysman-patch-group-tagging-managed) escolha **Adicionar**.

   Se a página de detalhes **ID da lista de referência** *não* incluir um menu **Ações**, não será possível configurar os grupos de patches no console. Em vez disso, você pode fazer qualquer um dos seguintes:
   + (Recomendado) Configure uma política de patch na Quick Setup, uma ferramenta do AWS Systems Manager, para mapear uma lista de referência de patches em uma ou mais instâncias do EC2.

     Para obter mais informações, consulte [Using Quick Setup patch policies](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) e [Automate organization-wide patching using a Quick Setup patch policy](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
   + Use o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html) na AWS Command Line Interface (AWS CLI) para configurar um grupo de patches.

# Integração do Patch Manager com o AWS Security Hub CSPM
<a name="patch-manager-security-hub-integration"></a>

[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) O fornece uma visão abrangente do seu estado de segurança na AWS. O Security Hub CSPM coleta dados de segurança de Contas da AWS, Serviços da AWS e produtos compatíveis de parceiros. Com o Security Hub CSPM, você pode verificar o ambiente de acordo com os padrões e as melhores práticas do setor de segurança. O Security Hub CSPM ajuda você a analisar suas tendências de segurança e identificar os problemas de segurança de prioridade mais alta.

Usando a integração entre o Patch Manager, uma ferramenta do AWS Systems Manager, e o Security Hub CSPM, é possível enviar descobertas sobre nós que estão fora de conformidade do Patch Manager para o Security Hub CSPM. Uma descoberta é o registro observável de uma verificação de segurança ou detecção relacionada à segurança. O Security Hub CSPM pode então incluir essas descobertas relacionadas a patches na análise feita sobre sua postura de segurança.

As informações nos tópicos a seguir se aplicam independentemente do método ou tipo de configuração que você estiver usando para suas operações de aplicação de patch:
+ Uma política de patch configurada no Quick Setup
+ Uma opção do Host Management configurada no Quick Setup
+ Uma janela de manutenção para executar um patch `Scan` ou tarefa `Install`
+ Uma operação **Patch now** (Aplicar patch agora) sob demanda

**Contents**
+ [Como o Patch Manager envia as descobertas para o CSPM do Security Hub](#securityhub-integration-sending-findings)
  + [Tipos de descobertas que o Patch Manager envia](#securityhub-integration-finding-types)
  + [Latência para enviar descobertas](#securityhub-integration-finding-latency)
  + [Tentar novamente quando o CSPM do Security Hub não está disponível](#securityhub-integration-retry-send)
  + [Visualização de descobertas do no CSPM do Security Hub](#securityhub-integration-view-findings)
+ [Descoberta típica do Patch Manager](#securityhub-integration-finding-example)
+ [Ativar e configurar a integração](#securityhub-integration-enable)
+ [Como parar de enviar descobertas](#securityhub-integration-disable)

## Como o Patch Manager envia as descobertas para o CSPM do Security Hub
<a name="securityhub-integration-sending-findings"></a>

No CSPM do Security Hub, os problemas de segurança são rastreados como descobertas. Algumas descobertas provêm de problemas que são detectados por outros Serviços da AWS ou por parceiros terceirizados. O CSPM do Security Hub também tem um conjunto de regras que ele usa para detectar problemas de segurança e gerar descobertas.

 O Patch Manager é uma das ferramentas do Systems Manager que envia descobertas ao Security Hub CSPM. Depois de executar uma operação de aplicação de patches executando um documento SSM (`AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, ou`AWS-RunPatchBaselineWithHooks`), as informações sobre a aplicação de patches serão enviadas às ferramentas Inventory ou Compliance do AWS Systems Manager ou a ambas. Depois que o Inventário, a Conformidade ou ambos receberem os dados, o Patch Manager receberá uma notificação. Em seguida, o Patch Manager avalia os dados quanto a precisão, formatação e conformidade. Se todas as condições forem cumpridas, o Patch Manager encaminhará os dados ao Security Hub CSPM.

O CSPM do Security Hub fornece ferramentas para gerenciar descobertas em todas essas origens. É possível exibir e filtrar listas de descobertas e exibir detalhes de uma descoberta. Para obter mais informações, consulte [Visualizar descobertas](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html) no *Guia do usuário do AWS Security Hub*. Também é possível rastrear o status de uma investigação em uma descoberta. Para obter mais informações, consulte [Tomar medidas sobre descobertas](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html) no *Manual do usuário do AWS Security Hub*.

Todas as descobertas no CSPM do Security Hub usam um formato JSON padrão chamado Formato de Descobertas de Segurança da AWS (ASFF). O ASFF inclui detalhes sobre a origem do problema, os recursos afetados e o status atual da descoberta. Para obter mais informações, consulte [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm) no *Manual do usuário do AWS Security Hub*.

### Tipos de descobertas que o Patch Manager envia
<a name="securityhub-integration-finding-types"></a>

O Patch Manager envia descobertas ao Security Hub CSPM usando o [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html). No ASFF, o campo `Types` fornece o tipo de descoberta. As descobertas do Patch Manager podem ter os seguintes valores para `Types`:
+ Verificações de software e configuração/Gerenciamento de patches

 Patch ManagerO envia uma descoberta por nó gerenciado não compatível. A descoberta é relatada com o tipo de recurso [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance) para que as descobertas possam ser correlacionadas com outras integrações do Security Hub CSPM que relatam tipos de recursos do `AwsEc2Instance`. O Patch Manager somente encaminhará uma descoberta ao Security Hub CSPM se a operação descobrir que a instância não é compatível. A descoberta inclui os resultados do Resumo do Patch. 

**nota**  
Depois de reportar um nó fora de conformidade ao Security Hub CSPM. O Patch Manager não envia uma atualização para o Security Hub CSPM depois que o nó é colocado em conformidade. É possível resolver manualmente as descobertas no Security Hub CSPM após a aplicação dos patches necessários ao nó gerenciado.

Para obter mais informações sobre definições de conformidade, consulte [Valores de estados de conformidade de patches](patch-manager-compliance-states.md). Para obter mais informações sobre o `PatchSummary`, consulte [Resumo de Patches](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)na *Referência de API do AWS Security Hub*.

### Latência para enviar descobertas
<a name="securityhub-integration-finding-latency"></a>

Quando o Patch Manager cria uma nova descoberta, ela normalmente é enviada para o Security Hub CSPM dentro de alguns segundos a duas horas. A velocidade depende do tráfego na Região da AWS sendo processado naquele momento.

### Tentar novamente quando o CSPM do Security Hub não está disponível
<a name="securityhub-integration-retry-send"></a>

Se houver uma interrupção do serviço, uma função AWS Lambda será executada para colocar as mensagens de volta na fila principal depois que o serviço estiver sendo executado novamente. Depois que as mensagens estiverem na fila principal, a tentativa será automática.

Se o Security Hub CSPM não estiver disponível, o Patch Manager tentará enviar as descobertas novamente até que sejam recebidas.

### Visualização de descobertas do no CSPM do Security Hub
<a name="securityhub-integration-view-findings"></a>

Este procedimento descreve como visualizar as descobertas no Security Hub CSPM sobre nós gerenciados da frota que estão fora de conformidade com os patches.

**Para analisar as descobertas do Security Hub CSPM quanto à conformidade de patches**

1. Faça login no Console de gerenciamento da AWS e abra o console do AWS Security Hub CSPM em [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/).

1. No painel de navegação, selecione **Descobertas**.

1. Escolha a caixa **Adicionar filtros** (![\[The Search icon\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/search-icon.png)).

1. No menu, em **Filtros**, escolha **Nome do produto**.

1. Na caixa de diálogo que é aberta, escolha **é** no primeiro campo e insira **Systems Manager Patch Manager** no segundo campo.

1. Escolha **Aplicar**.

1. Adicione quaisquer filtros que você quiser para ajudar a restringir os resultados.

1. Na lista de resultados, escolha o título da descoberta sobre a qual você deseja ver mais informações.

   Um painel é exibido no lado direito da tela com mais detalhes sobre o recurso, o problema descoberto e uma correção recomendada.
**Importante**  
No momento, o Security Hub CSPM relata como `EC2 Instance` o tipo de recurso de todos os nós gerenciados. Isso inclui servidores on-premises e máquinas virtuais (VMs) registrados para uso com o Systems Manager.

**Classificações de gravidade**  
A lista de descobertas do **Systems Manager Patch Manager** inclui um relatório da gravidade da descoberta. Os níveis de **gravidade** incluem este, do mais baixo ao mais alto:
+ **INFORMATIVO**: nenhum problema foi encontrado.
+ **BAIXO**: o problema não requer correção.
+ **MÉDIA**: o problema deve ser solucionado, mas não é urgente.
+ **ALTA**: o problema deve ser tratado como prioridade.
+ **CRÍTICA**: o problema deve ser corrigido imediatamente para evitar que seja escalonado.

A gravidade é determinada pelo pacote fora de conformidade mais grave da instância. Como é possível ter várias listas de referência de patches com vários níveis de gravidade, a gravidade mais alta é relatada de todos os pacotes fora de conformidade. Por exemplo, suponha que você tenha dois pacotes fora de conformidade em que a gravidade do pacote A seja “Crítica” e a gravidade do pacote B seja “Baixa”. “Crítica” será relatada como a gravidade.

O campo da gravidade está diretamente correlacionado com o campo `Compliance` do Patch Manager. É um campo que você define para atribuir a patches individuais que correspondem à regra. Como esse campo `Compliance` é atribuído a patches individuais, ele não é refletido no nível de resumo do patch.

**Conteúdo relacionado**
+ [Findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html) no *Guia do usuário do AWS Security Hub*
+ [Conformidade de patches de várias contas com o Patch Manager e o Security Hub](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/) no *Blog de gerenciamento e governança da AWS*

## Descoberta típica do Patch Manager
<a name="securityhub-integration-finding-example"></a>

O Patch Manager envia descobertas para o Security Hub CSPM por meio do [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html).

Aqui está um exemplo de uma descoberta típica do Patch Manager.

```
{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
  "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
  "GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
  "AwsAccountId": "111122223333",
  "Types": [
    "Software & Configuration Checks/Patch Management/Compliance"
  ],
  "CreatedAt": "2021-11-11T22:05:25Z",
  "UpdatedAt": "2021-11-11T22:05:25Z",
  "Severity": {
    "Label": "INFORMATIONAL",
    "Normalized": 0
  },
  "Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
  "Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
  "Remediation": {
    "Recommendation": {
      "Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
      "Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
    }
  },
  "SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
  "ProductFields": {
    "aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
    "aws/securityhub/ProductName": "Systems Manager Patch Manager",
    "aws/securityhub/CompanyName": "AWS"
  },
  "Resources": [
    {
      "Type": "AwsEc2Instance",
      "Id": "i-02573cafcfEXAMPLE",
      "Partition": "aws",
      "Region": "us-east-2"
    }
  ],
  "WorkflowState": "NEW",
  "Workflow": {
    "Status": "NEW"
  },
  "RecordState": "ACTIVE",
  "PatchSummary": {
    "Id": "pb-0c10e65780EXAMPLE",
    "InstalledCount": 45,
    "MissingCount": 2,
    "FailedCount": 0,
    "InstalledOtherCount": 396,
    "InstalledRejectedCount": 0,
    "InstalledPendingReboot": 0,
    "OperationStartTime": "2021-11-11T22:05:06Z",
    "OperationEndTime": "2021-11-11T22:05:25Z",
    "RebootOption": "NoReboot",
    "Operation": "SCAN"
  }
}
```

## Ativar e configurar a integração
<a name="securityhub-integration-enable"></a>

Para usar o Patch Manager com o Security Hub CSPM, é necessário ativar o Security Hub CSPM. Para obter informações sobre como habilitar o Security Hub CSPM, consulte [Configurar o Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html) no *Guia do usuário do AWS Security Hub*.

O procedimento a seguir descreve como integrar o Patch Manager e o Security Hub CSPM quando o Security Hub CSPM já está ativo, mas a integração com o Patch Manager está desativada. Você só precisa concluir este procedimento se a integração foi desativada manualmente.

**Para adicionar o Patch Manager à integração com o Security Hub CSPM**

1. No painel de navegação, escolha **Patch Manager**.

1. Escolha a guia **Configurações**.

   - ou -

   Se estiver acessando o Patch Manager pela primeira vez na Região da AWS atual, escolha **Start with an overview** (Começar com uma visão geral) e, em seguida, escolha a guia **Settings** (Configurações).

1. Na seção **Exportar para Security Hub CSPM**, à direita de **As descobertas de conformidade de patches não estão sendo exportadas para o Security Hub**, escolha **Habilitar**.

## Como parar de enviar descobertas
<a name="securityhub-integration-disable"></a>

Para interromper o envio de descobertas ao CSPM do Security Hub, você poderá usar o console ou a API do CSPM do Security Hub.

Para saber mais, consulte os seguintes tópicos no *Manual do usuário do AWS Security Hub*:
+ [Desabilitar e habilitar o fluxo de descobertas em uma integração (console)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [Desabilitar e habilitar o fluxo de descobertas em uma integração (API do Security Hub CSPM, AWS CLI)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)

# Trabalhar com recursos do Patch Manager usando a AWS CLI
<a name="patch-manager-cli-commands"></a>

Esta seção inclui exemplos de comandos da AWS Command Line Interface (AWS CLI) que você pode usar para realizar tarefas de configuração do Patch Manager, uma ferramenta do AWS Systems Manager.

Para obter uma ilustração do uso da AWS CLI para aplicar um patch a um ambiente de servidor usando a linha de base de patch personalizada, consulte [Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).

Para obter mais informações sobre como usar a AWS CLI para tarefas do AWS Systems Manager, consulte a [Seção do AWS Systems Manager da Referência de comando da AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html).

**Topics**
+ [AWS CLIComandos da para linhas de base de patches](#patch-baseline-cli-commands)
+ [AWS CLIComandos da para grupos de patches](#patch-group-cli-commands)
+ [AWS CLIComandos da para visualizar resumos e detalhes de patches](#patch-details-cli-commands)
+ [AWS CLIComandos da para verificação e correção de nós gerenciados](#patch-operations-cli-commands)

## AWS CLIComandos da para linhas de base de patches
<a name="patch-baseline-cli-commands"></a>

**Topics**
+ [Criar uma linha de base de patch](#patch-manager-cli-commands-create-patch-baseline)
+ [Criar uma linha de base de patch com repositórios personalizados para diferentes versões do SO](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [Atualizar uma linha de base de patch](#patch-manager-cli-commands-update-patch-baseline)
+ [Renomear uma linha de base de patch](#patch-manager-cli-commands-rename-patch-baseline)
+ [Excluir uma linha de base de patch](#patch-manager-cli-commands-delete-patch-baseline)
+ [Listar todas as linhas de base de patch](#patch-manager-cli-commands-describe-patch-baselines)
+ [Listar todas as listas de referência de patches fornecidas pela AWS](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [Listar minhas linhas de base de patches](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [Exibir uma linha de base de patch](#patch-manager-cli-commands-get-patch-baseline)
+ [Obter a linha de base padrão de patch](#patch-manager-cli-commands-get-default-patch-baseline)
+ [Definir uma linha de base de patch personalizada como padrão](#patch-manager-cli-commands-register-default-patch-baseline)
+ [Redefinir uma lista de referência de patches da AWS como padrão](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [Marcar uma linha de base de patch](#patch-manager-cli-commands-add-tags-to-resource)
+ [Listar as tags para uma linha de base de patch](#patch-manager-cli-commands-list-tags-for-resource)
+ [Remover uma tag de uma linha de base de patch](#patch-manager-cli-commands-remove-tags-from-resource)

### Criar uma linha de base de patch
<a name="patch-manager-cli-commands-create-patch-baseline"></a>

O comando a seguir cria uma lista de referência de patches que aprova todas as atualizações de segurança críticas e importantes para o Windows Server 2012 R2 cinco dias após o lançamento. Os patches também foram especificados para as listas de patches Approved (Aprovado) e Rejected (Rejeitado). Além disso, a linha de base de patch foi marcada para indicar que é para um ambiente de produção.

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "Windows-Server-2012R2" \
    --tags "Key=Environment,Value=Production" \
    --description "Windows Server 2012 R2, Important and Critical security updates" \
    --approved-patches "KB2032276,MS10-048" \
    --rejected-patches "KB2124261" \
    --rejected-patches-action "ALLOW_AS_DEPENDENCY" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "Windows-Server-2012R2" ^
    --tags "Key=Environment,Value=Production" ^
    --description "Windows Server 2012 R2, Important and Critical security updates" ^
    --approved-patches "KB2032276,MS10-048" ^
    --rejected-patches "KB2124261" ^
    --rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```

------

O sistema retorna informações como estas.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Criar uma linha de base de patch com repositórios personalizados para diferentes versões do SO
<a name="patch-manager-cli-commands-create-patch-baseline-mult-sources"></a>

Aplica-se somente aos nós gerenciados do Linux. O comando a seguir mostra como especificar o repositório de patches a ser usado para uma determinada versão do sistema operacional Amazon Linux. Este exemplo usa um repositório de origem ativado por padrão no Amazon Linux 2017.09, mas pode ser adaptado para outro repositório de origem que você tenha configurado para um nó gerenciado.

**nota**  
Para demonstrar melhor este comando mais complexo, estamos usando a opção `--cli-input-json` com opções adicionais armazenadas em um arquivo JSON externo.

1. Crie um arquivo JSON com um nome como `my-patch-repository.json` e adicione o seguinte conteúdo a ele:

   ```
   {
       "Description": "My patch repository for Amazon Linux 2",
       "Name": "Amazon-Linux-2",
       "OperatingSystem": "AMAZON_LINUX_2",
       "ApprovalRules": {
           "PatchRules": [
               {
                   "ApproveAfterDays": 7,
                   "EnableNonSecurity": true,
                   "PatchFilterGroup": {
                       "PatchFilters": [
                           {
                               "Key": "SEVERITY",
                               "Values": [
                                   "Important",
                                   "Critical"
                               ]
                           },
                           {
                               "Key": "CLASSIFICATION",
                               "Values": [
                                   "Security",
                                   "Bugfix"
                               ]
                           },
                           {
                               "Key": "PRODUCT",
                               "Values": [
                                   "AmazonLinux2"
                               ]
                           }
                       ]
                   }
               }
           ]
       },
       "Sources": [
           {
               "Name": "My-AL2",
               "Products": [
                   "AmazonLinux2"
               ],
               "Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
           }
       ]
   }
   ```

1. No diretório em que você salvou o arquivo, execute o seguinte comando:

   ```
   aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
   ```

   O sistema retorna informações como estas.

   ```
   {
       "BaselineId": "pb-0c10e65780EXAMPLE"
   }
   ```

### Atualizar uma linha de base de patch
<a name="patch-manager-cli-commands-update-patch-baseline"></a>

O comando a seguir adiciona dois patches como rejeitados e um patch como aprovado para uma linha de base de patch existente.

Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md).

------
#### [ Linux & macOS ]

```
aws ssm update-patch-baseline \
    --baseline-id pb-0c10e65780EXAMPLE \
    --rejected-patches "KB2032276" "MS10-048" \
    --approved-patches "KB2124261"
```

------
#### [ Windows Server ]

```
aws ssm update-patch-baseline ^
    --baseline-id pb-0c10e65780EXAMPLE ^
    --rejected-patches "KB2032276" "MS10-048" ^
    --approved-patches "KB2124261"
```

------

O sistema retorna informações como estas.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012R2",
   "RejectedPatches":[
      "KB2032276",
      "MS10-048"
   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1481001494.035,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[
      "KB2124261"
   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Renomear uma linha de base de patch
<a name="patch-manager-cli-commands-rename-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm update-patch-baseline \
    --baseline-id pb-0c10e65780EXAMPLE \
    --name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```

------
#### [ Windows Server ]

```
aws ssm update-patch-baseline ^
    --baseline-id pb-0c10e65780EXAMPLE ^
    --name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```

------

O sistema retorna informações como estas.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
   "RejectedPatches":[
      "KB2032276",
      "MS10-048"
   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1481001795.287,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[
      "KB2124261"
   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Excluir uma linha de base de patch
<a name="patch-manager-cli-commands-delete-patch-baseline"></a>

```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```

O sistema retorna informações como estas.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Listar todas as linhas de base de patch
<a name="patch-manager-cli-commands-describe-patch-baselines"></a>

```
aws ssm describe-patch-baselines
```

O sistema retorna informações como estas.

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      },
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

Este é um exemplo de outro comando que lista todas as listas de referência de patch em uma Região da AWS.

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[All]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[All]"
```

------

O sistema retorna informações como estas.

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      },
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Listar todas as listas de referência de patches fornecidas pela AWS
<a name="patch-manager-cli-commands-describe-patch-baselines-aws"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[AWS]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[AWS]"
```

------

O sistema retorna informações como estas.

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Listar minhas linhas de base de patches
<a name="patch-manager-cli-commands-describe-patch-baselines-custom"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[Self]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[Self]"
```

------

O sistema retorna informações como estas.

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Exibir uma linha de base de patch
<a name="patch-manager-cli-commands-get-patch-baseline"></a>

```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```

**nota**  
Para listas de referência de patches personalizadas, você pode especificar o ID da lista de referência de patches ou o Amazon Resource Name (ARN) completo. Para a lista de referência de patches fornecida pela AWS, você deve especificar o ARN completo. Por exemplo, `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`.

O sistema retorna informações como estas.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012R2",
   "PatchGroups":[
      "Web Servers"
   ],
   "RejectedPatches":[

   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1480997823.81,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[

   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Obter a linha de base padrão de patch
<a name="patch-manager-cli-commands-get-default-patch-baseline"></a>

```
aws ssm get-default-patch-baseline --region us-east-2
```

O sistema retorna informações como estas.

```
{
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

### Definir uma linha de base de patch personalizada como padrão
<a name="patch-manager-cli-commands-register-default-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-default-patch-baseline \
    --region us-east-2 \
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm register-default-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------

O sistema retorna informações como estas.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Redefinir uma lista de referência de patches da AWS como padrão
<a name="patch-manager-cli-commands-register-aws-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-default-patch-baseline \
    --region us-east-2 \
    --baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm register-default-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```

------

O sistema retorna informações como estas.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Marcar uma linha de base de patch
<a name="patch-manager-cli-commands-add-tags-to-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm add-tags-to-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE" \
    --tags "Key=Project,Value=Testing"
```

------
#### [ Windows Server ]

```
aws ssm add-tags-to-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE" ^
    --tags "Key=Project,Value=Testing"
```

------

### Listar as tags para uma linha de base de patch
<a name="patch-manager-cli-commands-list-tags-for-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm list-tags-for-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm list-tags-for-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE"
```

------

### Remover uma tag de uma linha de base de patch
<a name="patch-manager-cli-commands-remove-tags-from-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm remove-tags-from-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE" \
    --tag-keys "Project"
```

------
#### [ Windows Server ]

```
aws ssm remove-tags-from-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE" ^
    --tag-keys "Project"
```

------

## AWS CLIComandos da para grupos de patches
<a name="patch-group-cli-commands"></a>

**Topics**
+ [Criar um grupo de patches](#patch-manager-cli-commands-create-patch-group)
+ [Registrar um grupo de patches "web servers" em uma linha de base de patches](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [Registrar um grupo de patches "Backend" na lista de referência de patches fornecida pela AWS](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [Exibir registros de grupos de patches](#patch-manager-cli-commands-describe-patch-groups)
+ [Cancelar o registro de um grupo de patches de uma linha de base de patch](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)

### Criar um grupo de patches
<a name="patch-manager-cli-commands-create-patch-group"></a>

**nota**  
Os grupos de patches não são usados em operações de aplicação de patches em *políticas de patch*. Para obter informações sobre como trabalhar com políticas de patch, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).

Para ajudar você a organizar suas iniciativas de aplicação de patches, recomendamos que você adicione nós gerenciados aos grupos de patches usando etiquetas. Os grupos de patches exigem o uso da chave de tag `Patch Group` ou `PatchGroup`. Se você tiver [permissão para tags nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), é necessário usar `PatchGroup` (sem um espaço). Você pode especificar qualquer valor de tag, mas a chave da tag precisa ser `Patch Group` ou `PatchGroup`. Para obter mais informações sobre grupos de patches, consulte [Grupos de patches](patch-manager-patch-groups.md).

Depois de agrupar os nós gerenciados usando etiquetas, adicione o valor do grupo de patches a uma lista de referência de patches. Ao registrar o grupo de patches em uma linha de base de patch, você garante que os patches corretos sejam instalados durante a aplicação de patches.

#### Tarefa 1: adicionar instâncias do EC2 a um grupo de patches usando tags
<a name="create-patch-group-cli-1"></a>

**nota**  
Ao usar o console e a AWS CLI do Amazon Elastic Compute Cloud (Amazon EC2), é possível aplicar as tags `Key = Patch Group` ou `Key = PatchGroup` a instâncias que ainda não estejam configuradas para uso com o Systems Manager. Se uma instância do EC2 que você espere ver no Patch Manager não estiver listada após a aplicação da tag `Patch Group` ou `Key = PatchGroup`, consulte [Solução de problemas de disponibilidade do nó gerenciado](fleet-manager-troubleshooting-managed-nodes.md) para obter dicas de solução de problemas.

Execute o comando a seguir para adicionar a tag `PatchGroup` a uma instância do EC2.

```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```

#### Tarefa 2: Adicionar nós gerenciados a um grupo de patches usando etiquetas
<a name="create-patch-group-cli-2"></a>

Execute o comando a seguir para adicionar a etiqueta `PatchGroup` a um nó gerenciado.

------
#### [ Linux & macOS ]

```
aws ssm add-tags-to-resource \
    --resource-type "ManagedInstance" \
    --resource-id "mi-0123456789abcdefg" \
    --tags "Key=PatchGroup,Value=GroupValue"
```

------
#### [ Windows Server ]

```
aws ssm add-tags-to-resource ^
    --resource-type "ManagedInstance" ^
    --resource-id "mi-0123456789abcdefg" ^
    --tags "Key=PatchGroup,Value=GroupValue"
```

------

#### Tarefa 3: Adicionar um grupo de patches a uma linha de base de patches
<a name="create-patch-group-cli-3"></a>

Execute o comando a seguir para associar um valor de tag `PatchGroup` à linha de base de patch especificada.

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --baseline-id "pb-0c10e65780EXAMPLE" \
    --patch-group "Development"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --baseline-id "pb-0c10e65780EXAMPLE" ^
    --patch-group "Development"
```

------

O sistema retorna informações como estas.

```
{
  "PatchGroup": "Development",
  "BaselineId": "pb-0c10e65780EXAMPLE"
}
```

### Registrar um grupo de patches "web servers" em uma linha de base de patches
<a name="patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --baseline-id "pb-0c10e65780EXAMPLE" \
    --patch-group "Web Servers"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --baseline-id "pb-0c10e65780EXAMPLE" ^
    --patch-group "Web Servers"
```

------

O sistema retorna informações como estas.

```
{
   "PatchGroup":"Web Servers",
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Registrar um grupo de patches "Backend" na lista de referência de patches fornecida pela AWS
<a name="patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --region us-east-2 \
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
    --patch-group "Backend"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --region us-east-2 ^
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
    --patch-group "Backend"
```

------

O sistema retorna informações como estas.

```
{
   "PatchGroup":"Backend",
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

### Exibir registros de grupos de patches
<a name="patch-manager-cli-commands-describe-patch-groups"></a>

```
aws ssm describe-patch-groups --region us-east-2
```

O sistema retorna informações como estas.

```
{
   "PatchGroupPatchBaselineMappings":[
      {
         "PatchGroup":"Backend",
         "BaselineIdentity":{
            "BaselineName":"AWS-DefaultPatchBaseline",
            "DefaultBaseline":false,
            "BaselineDescription":"Default Patch Baseline Provided by AWS.",
            "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
         }
      },
      {
         "PatchGroup":"Web Servers",
         "BaselineIdentity":{
            "BaselineName":"Windows-Server-2012R2",
            "DefaultBaseline":true,
            "BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
            "BaselineId":"pb-0c10e65780EXAMPLE"
         }
      }
   ]
}
```

### Cancelar o registro de um grupo de patches de uma linha de base de patch
<a name="patch-manager-cli-commands-deregister-patch-baseline-for-patch-group"></a>

------
#### [ Linux & macOS ]

```
aws ssm deregister-patch-baseline-for-patch-group \
    --region us-east-2 \
    --patch-group "Production" \
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm deregister-patch-baseline-for-patch-group ^
    --region us-east-2 ^
    --patch-group "Production" ^
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```

------

O sistema retorna informações como estas.

```
{
   "PatchGroup":"Production",
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

## AWS CLIComandos da para visualizar resumos e detalhes de patches
<a name="patch-details-cli-commands"></a>

**Topics**
+ [Obter todos os patches definidos por uma linha de base de patch](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [Obtenha todos os patches para o AmazonLinux2018.03 que tenha uma classificação de `SECURITY` e uma gravidade `Critical`](#patch-manager-cli-commands-describe-available-patches-linux)
+ [Obtenha todos os patches para o Windows Server 2012 que tenham a gravidade MSRC como `Critical`.](#patch-manager-cli-commands-describe-available-patches)
+ [Obter todos os patches disponíveis](#patch-manager-cli-commands-describe-available-patches)
+ [Obter estados de resumo de patches por nó gerenciado](#patch-manager-cli-commands-describe-instance-patch-states)
+ [Obter detalhes da conformidade de patches para um nó gerenciado](#patch-manager-cli-commands-describe-instance-patches)
+ [Visualizar os resultados de conformidade dos patches (AWS CLI)](#viewing-patch-compliance-results-cli)

### Obter todos os patches definidos por uma linha de base de patch
<a name="patch-manager-cli-commands-describe-effective-patches-for-patch-baseline"></a>

**nota**  
Esse comando é compatível com listas de referência de patches do Windows Server.

------
#### [ Linux & macOS ]

```
aws ssm describe-effective-patches-for-patch-baseline \
    --region us-east-2 \
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm describe-effective-patches-for-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------

O sistema retorna informações como estas.

```
{
   "NextToken":"--token string truncated--",
   "EffectivePatches":[
      {
         "PatchStatus":{
            "ApprovalDate":1384711200.0,
            "DeploymentStatus":"APPROVED"
         },
         "Patch":{
            "ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
            "ProductFamily":"Windows",
            "Product":"WindowsServer2012R2",
            "Vendor":"Microsoft",
            "Description":"A security issue has been identified in a Microsoft software 
               product that could affect your system. You can help protect your system 
               by installing this update from Microsoft. For a complete listing of the 
               issues that are included in this update, see the associated Microsoft 
               Knowledge Base article. After you install this update, you may have to 
               restart your system.",
            "Classification":"SecurityUpdates",
            "Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
            "ReleaseDate":1384279200.0,
            "MsrcClassification":"Critical",
            "Language":"All",
            "KbNumber":"KB2876331",
            "MsrcNumber":"MS13-089",
            "Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
         }
      },
      {
         "PatchStatus":{
            "ApprovalDate":1428858000.0,
            "DeploymentStatus":"APPROVED"
         },
         "Patch":{
            "ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
            "ProductFamily":"Windows",
            "Product":"WindowsServer2012R2",
            "Vendor":"Microsoft",
            "Description":"Windows Server 2012 R2 Update is a cumulative 
               set of security updates, critical updates and updates. You 
               must install Windows Server 2012 R2 Update to ensure that 
               your computer can continue to receive future Windows Updates, 
               including security updates. For a complete listing of the 
               issues that are included in this update, see the associated 
               Microsoft Knowledge Base article for more information. After 
               you install this item, you may have to restart your computer.",
            "Classification":"SecurityUpdates",
            "Title":"Windows Server 2012 R2 Update (KB2919355)",
            "ReleaseDate":1428426000.0,
            "MsrcClassification":"Critical",
            "Language":"All",
            "KbNumber":"KB2919355",
            "MsrcNumber":"MS14-018",
            "Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
         }
      }
     ---output truncated---
```

### Obtenha todos os patches para o AmazonLinux2018.03 que tenha uma classificação de `SECURITY` e uma gravidade `Critical`
<a name="patch-manager-cli-commands-describe-available-patches-linux"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-available-patches \
    --region us-east-2 \
    --filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```

------
#### [ Windows Server ]

```
aws ssm describe-available-patches ^
    --region us-east-2 ^
    --filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```

------

O sistema retorna informações como estas.

```
{
    "Patches": [
        {
            "AdvisoryIds": ["ALAS-2011-1"],
            "BugzillaIds": [ "1234567" ],
            "Classification": "SECURITY",
            "CVEIds": [ "CVE-2011-3192"],
            "Name": "zziplib",
            "Epoch": "0",
            "Version": "2.71",
            "Release": "1.3.amzn1",
            "Arch": "i686",
            "Product": "AmazonLinux2018.03",
            "ReleaseDate": 1590519815,
            "Severity": "CRITICAL"
        }
    ]
}     
---output truncated---
```

### Obtenha todos os patches para o Windows Server 2012 que tenham a gravidade MSRC como `Critical`.
<a name="patch-manager-cli-commands-describe-available-patches"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-available-patches \
    --region us-east-2 \
    --filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```

------
#### [ Windows Server ]

```
aws ssm describe-available-patches ^
    --region us-east-2 ^
    --filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```

------

O sistema retorna informações como estas.

```
{
   "Patches":[
      {
         "ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
         "ProductFamily":"Windows",
         "Product":"WindowsServer2012",
         "Vendor":"Microsoft",
         "Description":"A security issue has been identified that could 
           allow an unauthenticated remote attacker to compromise your 
           system and gain control over it. You can help protect your 
           system by installing this update from Microsoft. After you 
           install this update, you may have to restart your system.",
         "Classification":"SecurityUpdates",
         "Title":"Security Update for Windows Server 2012 (KB2727528)",
         "ReleaseDate":1352829600.0,
         "MsrcClassification":"Critical",
         "Language":"All",
         "KbNumber":"KB2727528",
         "MsrcNumber":"MS12-072",
         "Id":"1eb507be-2040-4eeb-803d-abc55700b715"
      },
      {
         "ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
         "ProductFamily":"Windows",
         "Product":"WindowsServer2012",
         "Vendor":"Microsoft",
         "Description":"A security issue has been identified that could 
           allow an unauthenticated remote attacker to compromise your 
           system and gain control over it. You can help protect your 
           system by installing this update from Microsoft. After you 
           install this update, you may have to restart your system.",
         "Classification":"SecurityUpdates",
         "Title":"Security Update for Microsoft .NET Framework 3.5 on 
           Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
         "ReleaseDate":1352829600.0,
         "MsrcClassification":"Critical",
         "Language":"All",
         "KbNumber":"KB2729462",
         "MsrcNumber":"MS12-074",
         "Id":"af873760-c97c-4088-ab7e-5219e120eab4"
      }
     
---output truncated---
```

### Obter todos os patches disponíveis
<a name="patch-manager-cli-commands-describe-available-patches"></a>

```
aws ssm describe-available-patches --region us-east-2
```

O sistema retorna informações como estas.

```
{
   "NextToken":"--token string truncated--",
   "Patches":[
      {
            "Classification": "SecurityUpdates",
            "ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
            "Description": "A security issue has been identified in a Microsoft software 
            product that could affect your system. You can help protect your system by 
            installing this update from Microsoft. For a complete listing of the issues 
            that are included in this update, see the associated Microsoft Knowledge Base 
            article. After you install this update, you may have to restart your system.",
            "Id": "11adea10-0701-430e-954f-9471595ae246",
            "KbNumber": "KB4074588",
            "Language": "All",
            "MsrcNumber": "",
            "MsrcSeverity": "Critical",
            "Product": "WindowsServer2016",
            "ProductFamily": "Windows",
            "ReleaseDate": 1518548400,
            "Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based 
            Systems (KB4074588)",
            "Vendor": "Microsoft"
        },
        {
            "Classification": "SecurityUpdates",
            "ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
            "Description": "A security issue has been identified in a Microsoft software 
            product that could affect your system. You can help protect your system by 
            installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
            "KbNumber": "KB4074590",
            "Language": "All",
            "MsrcNumber": "",
            "MsrcSeverity": "Critical",
            "Product": "WindowsServer2016",
            "ProductFamily": "Windows",
            "ReleaseDate": 1518544805,
            "Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based 
            Systems (KB4074590)",
            "Vendor": "Microsoft"
        }
      ---output truncated---
```

### Obter estados de resumo de patches por nó gerenciado
<a name="patch-manager-cli-commands-describe-instance-patch-states"></a>

O resumo por nó gerenciado fornece uma série de patches nos seguintes estados por nó: "NotApplicable", "Missing", "Failed", "InstalledOther" e "Installed". 

------
#### [ Linux & macOS ]

```
aws ssm describe-instance-patch-states \
    --instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```

------
#### [ Windows Server ]

```
aws ssm describe-instance-patch-states ^
    --instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```

------

O sistema retorna informações como estas.

```
{
   "InstancePatchStates":[
      {
            "InstanceId": "i-08ee91c0b17045407",
            "PatchGroup": "",
            "BaselineId": "pb-0c10e65780EXAMPLE",
            "SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
            "InstalledCount": 50,
            "InstalledOtherCount": 353,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 0,
            "FailedCount": 0,
            "UnreportedNotApplicableCount": -1,
            "NotApplicableCount": 671,
            "OperationStartTime": "2020-01-24T12:37:56-08:00",
            "OperationEndTime": "2020-01-24T12:37:59-08:00",
            "Operation": "Scan",
            "RebootOption": "NoReboot"
        },
        {
            "InstanceId": "i-09a618aec652973a9",
            "PatchGroup": "",
            "BaselineId": "pb-0c10e65780EXAMPLE",
            "SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
            "InstalledCount": 36,
            "InstalledOtherCount": 396,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 3,
            "FailedCount": 0,
            "UnreportedNotApplicableCount": -1,
            "NotApplicableCount": 420,
            "OperationStartTime": "2020-01-24T12:37:34-08:00",
            "OperationEndTime": "2020-01-24T12:37:37-08:00",
            "Operation": "Scan",
            "RebootOption": "NoReboot"
        }
     ---output truncated---
```

### Obter detalhes da conformidade de patches para um nó gerenciado
<a name="patch-manager-cli-commands-describe-instance-patches"></a>

```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```

O sistema retorna informações como estas.

```
{
   "NextToken":"--token string truncated--",
   "Patches":[
      {
            "Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
            "KBId": "bind-libs.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:24-07:00"
        },
        {
            "Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
            "KBId": "bind-utils.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:32-07:00"
        },
        {
            "Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
            "KBId": "dhclient.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:31-07:00"
        },
    ---output truncated---
```

### Visualizar os resultados de conformidade dos patches (AWS CLI)
<a name="viewing-patch-compliance-results-cli"></a>

**Para visualizar os resultados de conformidade de patches para um único nó gerenciado**

Execute o seguinte comando na AWS Command Line Interface (AWS CLI) para exibir os resultados de conformidade do patch para um único nó gerenciado.

```
aws ssm describe-instance-patch-states --instance-id instance-id
```

Substitua *instance-id* pelo ID do nó gerenciado para o qual você deseja visualizar os resultados, no formato `i-02573cafcfEXAMPLE` ou `mi-0282f7c436EXAMPLE`.

O sistema retorna informações como as seguintes.

```
{
    "InstancePatchStates": [
        {
            "InstanceId": "i-02573cafcfEXAMPLE",
            "PatchGroup": "mypatchgroup",
            "BaselineId": "pb-0c10e65780EXAMPLE",            
            "SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
            "CriticalNonCompliantCount": 2,
            "SecurityNonCompliantCount": 2,
            "OtherNonCompliantCount": 1,
            "InstalledCount": 123,
            "InstalledOtherCount": 334,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 1,
            "FailedCount": 2,
            "UnreportedNotApplicableCount": 11,
            "NotApplicableCount": 2063,
            "OperationStartTime": "2021-05-03T11:00:56-07:00",
            "OperationEndTime": "2021-05-03T11:01:09-07:00",
            "Operation": "Scan",
            "LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
            "RebootOption": "RebootIfNeeded"
        }
    ]
}
```

**Para visualizar um resumo da contagem de patches para todas as instâncias do EC2 em uma região**

O`describe-instance-patch-states`O oferece suporte à recuperação de resultados para apenas uma instância gerenciada por vez. No entanto, usando um script personalizado com o`describe-instance-patch-states`, você pode gerar um relatório mais granular.

Por exemplo, se a [ferramenta de filtro jq](https://stedolan.github.io/jq/download/) estiver instalada na máquina local, você poderá executar o seguinte comando para identificar qual de suas instâncias do EC2 em uma determinada Região da AWS tem um status `InstalledPendingReboot`:

```
aws ssm describe-instance-patch-states \
    --instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
    --output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```

A *região* representa o identificador da região para uma região da Região da AWS compatível com o AWS Systems Manager, como `us-east-2` para a região Leste dos EUA (Ohio). Para ver uma lista dos valores de *região* com suporte, consulte a coluna **Region** em [Systems Manager service endpoints](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) no *Referência geral da Amazon Web Services*.

Por exemplo:

```
aws ssm describe-instance-patch-states \
    --instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
    --output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```

O sistema retorna informações como estas.

```
1       i-02573cafcfEXAMPLE
0       i-0471e04240EXAMPLE
3       i-07782c72faEXAMPLE
6       i-083b678d37EXAMPLE
0       i-03a530a2d4EXAMPLE
1       i-01f68df0d0EXAMPLE
0       i-0a39c0f214EXAMPLE
7       i-0903a5101eEXAMPLE
7       i-03823c2fedEXAMPLE
```

Além de`InstalledPendingRebootCount`, a lista de tipos de contagem que você pode pesquisar inclui o seguinte:
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`

## AWS CLIComandos da para verificação e correção de nós gerenciados
<a name="patch-operations-cli-commands"></a>

Depois de executar os seguintes comandos para verificar a conformidade do patch ou instalar patches, você pode usar comandos no [AWS CLIComandos da para visualizar resumos e detalhes de patches](#patch-details-cli-commands) para exibir informações sobre o status e a conformidade do patch.

**Topics**
+ [Verificar a conformidade dos patches () em nós gerenciados (AWS CLI)](#patch-operations-scan)
+ [Instalar patches em nós gerenciados (AWS CLI)](#patch-operations-install-cli)

### Verificar a conformidade dos patches () em nós gerenciados (AWS CLI)
<a name="patch-operations-scan"></a>

**Para verificar a conformidade dos patches em nós gerenciados**

Execute o comando a seguir.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
    --parameters 'Operation=Scan' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
    --parameters "Operation=Scan" ^
    --timeout-seconds 600
```

------

O sistema retorna informações como estas.

```
{
    "Command": {
        "CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621974475.267,
        "Parameters": {
            "Operation": [
                "Scan"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "InstanceIds",
                "Values": [
                    "i-02573cafcfEXAMPLE,
                     i-0471e04240EXAMPLE"
                ]
            }
        ],
        "RequestedDateTime": 1621952275.267,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

**Para verificar os nós gerenciados quanto à conformidade do patch por etiqueta do grupo de patches**

Execute o comando a seguir.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key='tag:PatchGroup',Values='Web servers' \
    --parameters 'Operation=Scan' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key="tag:PatchGroup",Values="Web servers" ^
    --parameters "Operation=Scan" ^
    --timeout-seconds 600
```

------

O sistema retorna informações como estas.

```
{
    "Command": {
        "CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621974983.128,
        "Parameters": {
            "Operation": [
                "Scan"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "tag:PatchGroup",
                "Values": [
                    "Web servers"
                ]
            }
        ],
        "RequestedDateTime": 1621952783.128,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

### Instalar patches em nós gerenciados (AWS CLI)
<a name="patch-operations-install-cli"></a>

**Para instalar patches em nós gerenciados específicos**

Execute o comando a seguir. 

**nota**  
Os nós gerenciados de destino são reinicializados conforme necessário para concluir a instalação do patch. Para obter mais informações, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
    --parameters 'Operation=Install' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
    --parameters "Operation=Install" ^
    --timeout-seconds 600
```

------

O sistema retorna informações como estas.

```
{
    "Command": {
        "CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621975301.791,
        "Parameters": {
            "Operation": [
                "Install"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "InstanceIds",
                "Values": [
                    "i-02573cafcfEXAMPLE,
                     i-0471e04240EXAMPLE"
                ]
            }
        ],
        "RequestedDateTime": 1621953101.791,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

**Para instalar patches em nós gerenciados em um grupo de patches específico**

Execute o comando a seguir.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key='tag:PatchGroup',Values='Web servers' \
    -parameters 'Operation=Install' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key="tag:PatchGroup",Values="Web servers" ^
    --parameters "Operation=Install" ^
    --timeout-seconds 600
```

------

O sistema retorna informações como estas.

```
{
    "Command": {
        "CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621975407.865,
        "Parameters": {
            "Operation": [
                "Install"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "tag:PatchGroup",
                "Values": [
                    "Web servers"
                ]
            }
        ],
        "RequestedDateTime": 1621953207.865,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

# Tutoriais do AWS Systems Manager Patch Manager
<a name="patch-manager-tutorials"></a>

Os tutoriais desta seção demonstram como usar o Patch Manager, uma ferramenta do AWS Systems Manager, para vários cenários de aplicação de patches.

**Topics**
+ [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md)
+ [Tutorial: Criar uma lista de referência de patches para instalar o Windows Service Packs usando o console](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutorial: Atualizar dependências de aplicações, corrigir um nó gerenciado e executar uma verificação de integridade específica da aplicação usando o console](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)

# Tutorial: corrigindo um servidor em um ambiente somente IPv6
<a name="patch-manager-server-patching-iPv6-tutorial"></a>

O Patch Manager suporta a correção de nós em ambientes somente IPv6. Ao atualizar a configuração do SSM Agent, as operações de correção podem ser configuradas para fazer chamadas somente para endpoints de serviço IPv6.

**Corrigir um servidor em um ambiente somente IPv6**

1. Certifique-se de que o SSM Agent versão 3.3270.0 ou posterior esteja instalado em seu nó gerenciado.

1. No nó gerenciado, navegue até o arquivo de configuração do SSM Agent. É possível encontrar o arquivo `amazon-ssm-agent.json` nos seguintes diretórios:
   + Linux: `/etc/amazon/ssm/`
   + macOS: `/opt/aws/ssm/`
   + Windows Server: `C:\Program Files\Amazon\SSM`

   Se `amazon-ssm-agent.json` ainda não existir, copie o conteúdo de `amazon-ssm-agent.json.template` no mesmo diretório para `amazon-ssm-agent.json`.

1. Atualize a entrada a seguir para definir a região correta e definir `UseDualStackEndpoint` como`true`:

   ```
   {
    --------
       "Agent": {
           "Region": "region",
           "UseDualStackEndpoint": true
       },
   --------
   }
   ```

1. Reinicie o serviço do SSM Agent usando o comando apropriado para seu sistema operacional:
   + Linux: `sudo systemctl restart amazon-ssm-agent`
   + Ubuntu Server usando Snap: `sudo snap restart amazon-ssm-agent`
   + macOS: `sudo launchctl stop com.amazon.aws.ssm` seguido por `sudo launchctl start com.amazon.aws.ssm`
   + Windows Server: `Stop-Service AmazonSSMAgent` seguido por `Start-Service AmazonSSMAgent`

   Para obter a lista completa de comandos de cada sistema operacional, consulte [Verificar o status do SSM Agent e iniciar o agente](ssm-agent-status-and-restart.md).

1. Execute qualquer operação de correção para verificar se as operações de correção são bem-sucedidas em seu ambiente somente IPv6. Certifique-se de que os nós que estão sendo corrigidos tenham conectividade com a fonte do patch. Você pode verificar a saída Run Command da execução do patch para verificar se há avisos sobre repositórios inacessíveis. Ao corrigir um nó que está sendo executado em um ambiente somente IPv6, certifique-se de que o nó tenha conectividade com a origem do patch. Você pode verificar a saída Run Command da execução do patch para verificar se há avisos sobre repositórios inacessíveis. Para sistemas operacionais baseados em DNF, é possível configurar para que repositórios indisponíveis sejam ignorados durante a aplicação de patches se a opção `skip_if_unavailable` estiver definida como `True` em `/etc/dnf/dnf.conf`. Os sistemas operacionais baseados em DNF incluem Amazon Linux 2023, Red Hat Enterprise Linux 8 e versões posteriores, Oracle Linux 8 e versões posteriores, Rocky Linux, AlmaLinux e CentOS 8 e versões posteriores. No Amazon Linux 2023, a opção `skip_if_unavailable` é definida como `True` por padrão.
**nota**  
 Ao usar os atributos Install Override List ou Baseline Override, certifique-se de que o URL fornecido esteja acessível a partir do nó. Se a opção de configuração `UseDualStackEndpoint` do SSM Agent estiver definida como `true`, um cliente S3 de dualstack será usado quando uma URL S3 for fornecida.

# Tutorial: Criar uma lista de referência de patches para instalar o Windows Service Packs usando o console
<a name="patch-manager-windows-service-pack-patch-baseline-tutorial"></a>

Ao criar uma lista de referência de patches personalizada, é possível especificar que todos, alguns ou apenas um tipo de patch compatível está instalado.

Nas listas de referência de patches do Windows, é possível selecionar `ServicePacks` como a única opção **Classificação** para limitar atualizações de patch somente para Service Packs. Os Service Packs podem ser instalados automaticamente pelo Patch Manager, uma ferramenta do AWS Systems Manager, desde que a atualização esteja disponível no Windows Update ou no Windows Server Update Services (WSUS).

É possível configurar uma lista de referência de patches para controlar se os Service Packs de todas as versões do Windows estão instalados ou apenas aqueles de versões específicas, como o Windows 7 ou Windows Server 2016. 

Use o procedimento a seguir para criar uma lista de referência de patches personalizada a ser usada exclusivamente para instalar todos os Service Packs em seus nós gerenciados do Windows. 

**Para criar uma lista de referência de patches para instalar o Windows Service Packs (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, escolha **Patch Manager**.

1. Escolha a guia **Listas de referência de patches** e, em seguida, escolha **Criar lista de referência de patches**. 

1. Em **Nome**, insira um nome para a nova lista de referência de patches, como `MyWindowsServicePackPatchBaseline`.

1. (Opcional) Em **Description (Descrição)**, insira uma descrição para essa linha de base de patch.

1. Em **Operating system (Sistema operacional)**, escolha `Windows`.

1. Se você deseja começar a usar essa linha de base de patch como o padrão para o Windows assim que a criar, selecione **Set this patch baseline as the default patch baseline for Windows Server instances (Definir essa linha de base de patch como a linha de base de patch padrão para instâncias do Windows Server)**.
**nota**  
Essa opção está disponível somente se você acessou pela primeira vez Patch Manager antes do lançamento [das políticas de patch](patch-manager-policies.md) em 22 de dezembro de 2022.  
Para obter informações sobre como definir uma linha de base de patch existente como padrão, consulte [Definir uma linha de base de patches existente como padrão](patch-manager-default-patch-baseline.md).

1. Na seção **Approval rules for operating systems (Regras de aprovação para sistemas operacionais)**, use os campos para criar uma ou mais regras de aprovação automática.
   + **Produtos**: as versões do sistema operacional às quais a regra de aprovação se aplica, como `WindowsServer2012`. É possível escolher uma, mais de uma ou todas as versões compatíveis do Windows. A seleção padrão é `All`.
   + **Classificação**: escolha `ServicePacks`. 
   + **Gravidade**: o valor da gravidade dos patches aos quais a regra se aplica. Para garantir que todos os Service Packs estejam incluídos pela regra, escolha `All`. 
   + **Auto-approval (Aprovação automática)**: o método para selecionar patches para aprovação automática.
     + **Approve patches after a specified number of days** (Aprovar patches após um número específico de dias): o número de dias que o Patch Manager deve aguardar para aprovar automaticamente um patch após o lançamento ou atualização de um patch. Insira qualquer número inteiro de zero (0) a 360. Para a maioria dos casos, recomendamos que não aguarde mais de 100 dias.
     + **Approve patches released up to a specific date** (Aprovar patches lançados até uma data específica): a data de lançamento do patch para a qual o Patch Manager aplica automaticamente todos os patches lançados ou com a última atualização nessa data ou antes dela. Por exemplo, se você especificar 7 de julho de 2023, nenhum patch lançado ou com última atualização em ou após 8 de julho de 2023 será instalado automaticamente.
   + (Opcional) **Relatórios de conformidade**: o nível de gravidade que você deseja atribuir aos Service Packs aprovados pela lista de referência, como `High`.
**nota**  
Se você especificar um nível de relatório de conformidade e o estado do patch de qualquer pacote de serviço aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.

1. (Opcional) Em **Manage tags (Gerenciar tags)**, aplique um ou mais pares de nome/valor de chave de tag à linha de base de patch.

   Tags são metadados opcionais que você atribui a um recurso. As tags permitem categorizar um recurso de diferentes formas, como por finalidade, proprietário ou ambiente. Para esta lista de referência de patches dedicada à atualização de Service Packs, é possível especificar pares de chave/valor como o seguinte:
   + `Key=OS,Value=Windows`
   + `Key=Classification,Value=ServicePacks`

1. Escolha **Create patch baseline**.

# Tutorial: Atualizar dependências de aplicações, corrigir um nó gerenciado e executar uma verificação de integridade específica da aplicação usando o console
<a name="aws-runpatchbaselinewithhooks-tutorial"></a>

Em muitos casos, um nó gerenciado deve ser reinicializado depois de ter sido corrigido com a atualização de software mais recente. No entanto, a reinicialização de um nó gerenciado em produção sem proteções implementadas pode causar vários problemas, como invocação de alarmes, registro incorreto de dados de métrica e interrupção de sincronizações de dados.

Esse tutorial demonstra como evitar problemas como esses usando o documento do AWS Systems Manager (documento do SSM) `AWS-RunPatchBaselineWithHooks` para obter uma operação de aplicação de patches complexa e de várias etapas que realize o seguinte:

1. Impedir novas conexões com a aplicação

1. Instale as atualizações para o sistema operacional.

1. Atualizar as dependências do pacote da aplicação

1. Reinicie o daemon ().

1. Executar uma verificação de integridade específica da aplicação

Para este exemplo, configuramos nossa infraestrutura desta forma:
+ As máquinas virtuais de destino são registradas como nós gerenciados com o Systems Manager.
+ `Iptables` é usado como um firewall local.
+ A aplicação hospedada em seus nós gerenciados está sendo executada na porta 443.
+ A aplicação hospedada em seus nós gerenciados é uma aplicação `nodeJS`.
+ A aplicação hospedada em seus nós gerenciados pelo gerenciador de processos pm2.
+ A aplicação já possui um endpoint de verificação de integridade especificado.
+ O endpoint da verificação de integridade da aplicação não requer autenticação do usuário final. O endpoint permite uma verificação de integridade que atenda aos requisitos da organização para estabelecer a disponibilidade. (Em seus ambientes, pode ser suficiente simplesmente verificar se a aplicação `nodeJS` está em execução e é capaz de receber solicitações. Em outros casos, também é possível verificar se uma conexão com a camada de armazenamento em cache ou com a camada de banco de dados já foi estabelecida.)

Os exemplos deste tutorial são apenas para fins de demonstração e não devem ser implementados inalterados em ambientes de produção. Além disso, tenha em mente que o recurso de ganchos de ciclo de vida do Patch Manager, uma ferramenta do Systems Manager, com o documento `AWS-RunPatchBaselineWithHooks` pode oferecer suporte a vários outros cenários. Aqui estão alguns exemplos:
+ Interrompa um agente de relatório de métricas antes de aplicar patches e reiniciá-lo após a reinicialização do nó gerenciado.
+ Desconecte o nó gerenciado de um cluster CRM ou PCS antes de aplicar patches e reconecte após a reinicialização do nó.
+ Atualize software de terceiros (por exemplo, aplicações Java, Tomcat, Adobe e outras) em máquinas do Windows Server depois que as atualizações do sistema operacional (SO) forem aplicadas, mas antes da reinicialização do nó gerenciado.

**Para atualizar dependências de aplicações, corrigir um nó gerenciado e executar uma verificação de integridade específica da aplicação**

1. Crie um documento do SSM para o script de pré-instalação com o conteúdo a seguir e nomeie-o como `NodeJSAppPrePatch`. Substituir *your\$1application* pelo nome da sua aplicação.

   Este script bloqueia imediatamente novas solicitações de entrada e fornece cinco segundos para que as já ativas sejam concluídas antes de iniciar a operação de patch. Para a opção `sleep`, especifique um número de segundos maior do que normalmente leva para que as solicitações recebidas sejam concluídas.

   ```
   # exit on error
   set -e
   # set up rule to block incoming traffic
   iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
   # wait for current connections to end. Set timeout appropriate to your application's latency
   sleep 5 
   # Stop your application
   pm2 stop your_application
   ```

   Para obter informações sobre como criar um documento do SSM, consulte [Criar conteúdo de documento do SSM](documents-creating-content.md).

1. Crie outro documento SSM com o conteúdo a seguir para o script após a instalação, para atualizar as dependências da aplicação e dê a ele o nome `NodeJSAppPostPatch`. Substituir */your/application/path* pelo caminho para a sua aplicação.

   ```
   cd /your/application/path
   npm update 
   # you can use npm-check-updates if you want to upgrade major versions
   ```

1. Crie outro documento SSM com o seguinte conteúdo para o scipt do `onExit` para fazer backup da aplicação e executar uma verificação de integridade. Nomeie este documento do SSM `NodeJSAppOnExitPatch`. Substituir *your\$1application* pelo nome da sua aplicação.

   ```
   # exit on error
   set -e
   # restart nodeJs application
   pm2 start your_application
   # sleep while your application starts and to allow for a crash
   sleep 10
   # check with pm2 to see if your application is running
   pm2 pid your_application
   # re-enable incoming connections
   iptables -D INPUT -j DROP -p tcp --syn --destination-port 
   # perform health check
   /usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
   ```

1. Criar uma associação no State Manager, uma ferramenta do AWS Systems Manager para emitir a operação executando as seguintes etapas:

   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 **State Manager** e selecione **Create association**.

   1. Para **Name** (Nome), forneça um nome para ajudar a identificar a finalidade da associação.

   1. Na lista **Document (Documento)**, escolha `AWS-RunPatchBaselineWithHooks`.

   1. Em **Action** (Ação), selecione **Install** (Instalar).

   1. (Opcional) Em **Snapshot Id** (ID do snapshot), forneça um GUID que você gera para ajudar a acelerar a operação e garantir a consistência. O valor GUID pode ser tão simples quanto `00000000-0000-0000-0000-111122223333`.

   1. Para **Pre Install Hook Doc Name** (Nome do Doc do Hook antes da instalação), insira `NodeJSAppPrePatch`. 

   1. Para **Post Install Hook Doc Name** (Nome do Doc do Hook após instalação), insira `NodeJSAppPostPatch`. 

   1. Para **On ExitHook Doc Name** (No nome do documento ExitHook), insira `NodeJSAppOnExitPatch`. 

1. Para **Targets** (Destinos), identifique os nós gerenciados especificando etiquetas, escolhendo os nós manualmente, escolhendo um grupo de recursos ou escolhendo todos os nós gerenciados.

1. Para **Specify schedule** (Especificar programação), especifique a frequência com que a associação deve ser executada. Por exemplo, a aplicação de patches em nós gerenciados uma vez por semana é uma cadência comum.

1. Na seção **Rate control** (Controle de taxa), escolha opções para controlar como a associação é executada em vários nós gerenciados. Verifique se apenas uma parte dos nós gerenciados é atualizada de cada vez. Caso contrário, toda ou a maior parte da sua frota poderá ficar offline de uma só vez. Para obter mais informações sobre como usar controles de taxa, consulte [Sobre destinos e controles de taxa em associações do State Manager](systems-manager-state-manager-targets-and-rate-controls.md).

1. (Opcional) Em **Opções de saída**, para salvar a saída de comando em um arquivo, selecione a caixa **Habilitar a gravação da saída no S3**. Digite os nomes de bucket e prefixo (pastas) nas caixas de texto.
**nota**  
As permissões do S3 que concedem a possibilidade de gravar os dados em um bucket do S3 são as do perfil da instância atribuído ao nó gerenciado, e não as do usuário do IAM que realiza essa tarefa. Para obter mais informações, consulte [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md) ou [Criar um perfil de serviço do IAM para um ambiente híbrido](hybrid-multicloud-service-role.md). Além disso, se o bucket do S3 especificado estiver em uma conta da Conta da AWS diferente, verifique se o perfil da instância ou a função de serviço IAM associada ao nó gerenciado tenha as permissões necessárias para gravar nesse bucket.

1. Escolha **Create Association (Criar associação)**.

# Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI
<a name="patch-manager-patch-servers-using-the-aws-cli"></a>

O procedimento a seguir descreve como aplicar patch a um ambiente de servidor usando uma linha de base de patch personalizada, grupos de patches e uma janela de manutenção.

**Antes de começar**
+ Instale ou atualize o SSM Agent em seus nós gerenciados. Para aplicar patches a nós gerenciados do Linux, os nós devem estar em execução no SSM Agent versão 2.0.834.0 ou posterior. Para obter mais informações, consulte [Atualização do SSM Agent por meio de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Configure as funções e permissões para a Maintenance Windows, uma ferramenta do AWS Systems Manager. Para obter mais informações, consulte [Configurar o Maintenance Windows](setting-up-maintenance-windows.md).
+ Instale e configure a AWS Command Line Interface (AWS CLI), caso ainda não o tenha feito.

  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).

**Para configurar o Patch Manager e aplicar patches aos nós gerenciados (linha de comando)**

1. Execute o comando a seguir para criar uma lista de referência de patches para o Windows chamada `Production-Baseline`. Essa lista de referência de patches aprova patches para um ambiente de produção sete dias após o lançamento ou última atualização. Ou seja, marcamos a lista de referência de patches para indicar que é para um ambiente de produção.
**nota**  
O parâmetro `OperatingSystem` e `PatchFilters` varia dependendo do sistema operacional dos nós gerenciados aos quais a lista de referência de patches se aplica. Para obter mais informações, consulte [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) e [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html).

------
#### [ Linux & macOS ]

   ```
   aws ssm create-patch-baseline \
       --name "Production-Baseline" \
       --operating-system "WINDOWS" \
       --tags "Key=Environment,Value=Production" \
       --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
       --description "Baseline containing all updates approved for production systems"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-patch-baseline ^
       --name "Production-Baseline" ^
       --operating-system "WINDOWS" ^
       --tags "Key=Environment,Value=Production" ^
       --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
       --description "Baseline containing all updates approved for production systems"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

1. Execute os comandos a seguir para registrar a linha de base de patch "Production-Baseline" para dois grupos de patches. Os grupos são chamados de "Database Servers" (Servidores de banco de dados) e "Front-End Servers" (Servidores front-end).

------
#### [ Linux & macOS ]

   ```
   aws ssm register-patch-baseline-for-patch-group \
       --baseline-id pb-0c10e65780EXAMPLE \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-patch-baseline-for-patch-group ^
       --baseline-id pb-0c10e65780EXAMPLE ^
       --patch-group "Database Servers"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "PatchGroup":"Database Servers",
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-patch-baseline-for-patch-group \
       --baseline-id pb-0c10e65780EXAMPLE \
       --patch-group "Front-End Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-patch-baseline-for-patch-group ^
       --baseline-id pb-0c10e65780EXAMPLE ^
       --patch-group "Front-End Servers"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "PatchGroup":"Front-End Servers",
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

1. Execute os comandos a seguir para criar duas janelas de manutenção para os servidores de produção. A primeira janela é executada todas as terças-feiras às 22 horas. A segunda janela é executada todos os sábados às 22 horas. Além disso, a janela de manutenção é marcada para indicar que é para um ambiente de produção.

------
#### [ Linux & macOS ]

   ```
   aws ssm create-maintenance-window \
       --name "Production-Tuesdays" \
       --tags "Key=Environment,Value=Production" \
       --schedule "cron(0 0 22 ? * TUE *)" \
       --duration 1 \
       --cutoff 0 \
       --no-allow-unassociated-targets
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-maintenance-window ^
       --name "Production-Tuesdays" ^
       --tags "Key=Environment,Value=Production" ^
       --schedule "cron(0 0 22 ? * TUE *)" ^
       --duration 1 ^
       --cutoff 0 ^
       --no-allow-unassociated-targets
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "WindowId":"mw-0c50858d01EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm create-maintenance-window \
       --name "Production-Saturdays" \
       --tags "Key=Environment,Value=Production" \
       --schedule "cron(0 0 22 ? * SAT *)" \
       --duration 2 \
       --cutoff 0 \
       --no-allow-unassociated-targets
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-maintenance-window ^
       --name "Production-Saturdays" ^
       --tags "Key=Environment,Value=Production" ^
       --schedule "cron(0 0 22 ? * SAT *)" ^
       --duration 2 ^
       --cutoff 0 ^
       --no-allow-unassociated-targets
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "WindowId":"mw-9a8b7c6d5eEXAMPLE"
   }
   ```

1. Execute os comandos a seguir para registrar os grupos de patches de servidores `Database` e `Front-End` com suas respectivas janelas de manutenção.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-target-with-maintenance-window \
       --window-id mw-0c50858d01EXAMPLE \
       --targets "Key=tag:PatchGroup,Values=Database Servers" \
       --owner-information "Database Servers" \
       --resource-type "INSTANCE"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-target-with-maintenance-window ^
       --window-id mw-0c50858d01EXAMPLE ^
       --targets "Key=tag:PatchGroup,Values=Database Servers" ^
       --owner-information "Database Servers" ^
       --resource-type "INSTANCE"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-target-with-maintenance-window \
   --window-id mw-9a8b7c6d5eEXAMPLE \
   --targets "Key=tag:PatchGroup,Values=Front-End Servers" \
   --owner-information "Front-End Servers" \
   --resource-type "INSTANCE"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-target-with-maintenance-window ^
       --window-id mw-9a8b7c6d5eEXAMPLE ^
       --targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
       --owner-information "Front-End Servers" ^
       --resource-type "INSTANCE"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
   }
   ```

1. Execute os comandos a seguir para registrar uma tarefa de patch que instala atualizações ausentes nos servidores `Database` e `Front-End` durante suas respectivas janelas de manutenção.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-task-with-maintenance-window \
       --window-id mw-0c50858d01EXAMPLE \
       --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
       --task-arn "AWS-RunPatchBaseline" \
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
       --task-type "RUN_COMMAND" \
       --max-concurrency 2 \
       --max-errors 1 \
       --priority 1 \
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-task-with-maintenance-window ^
       --window-id mw-0c50858d01EXAMPLE ^
       --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
       --task-arn "AWS-RunPatchBaseline" ^
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
       --task-type "RUN_COMMAND" ^
       --max-concurrency 2 ^
       --max-errors 1 ^
       --priority 1 ^
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-task-with-maintenance-window \
       --window-id mw-9a8b7c6d5eEXAMPLE \
       --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
       --task-arn "AWS-RunPatchBaseline" \
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
       --task-type "RUN_COMMAND" \
       --max-concurrency 2 \
       --max-errors 1 \
       --priority 1 \
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-task-with-maintenance-window ^
       --window-id mw-9a8b7c6d5eEXAMPLE ^
       --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
       --task-arn "AWS-RunPatchBaseline" ^
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
       --task-type "RUN_COMMAND" ^
       --max-concurrency 2 ^
       --max-errors 1 ^
       --priority 1 ^
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
   }
   ```

1. Execute o seguinte comando para obter o resumo de conformidade de patch de alto nível para um grupo de patches. O resumo de conformidade de patches de alto nível inclui o número de nós gerenciados com patches nos respectivos estados do patch.
**nota**  
Durante a primeira janela de manutenção é normal que zeros apareçam como o número de nós gerenciados no resumo, até que a tarefa de aplicação do patch seja executada.

------
#### [ Linux & macOS ]

   ```
   aws ssm describe-patch-group-state \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm describe-patch-group-state ^
       --patch-group "Database Servers"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "Instances": number,
      "InstancesWithFailedPatches": number,
      "InstancesWithInstalledOtherPatches": number,
      "InstancesWithInstalledPatches": number,
      "InstancesWithInstalledPendingRebootPatches": number,
      "InstancesWithInstalledRejectedPatches": number,
      "InstancesWithMissingPatches": number,
      "InstancesWithNotApplicablePatches": number,
      "InstancesWithUnreportedNotApplicablePatches": number
   }
   ```

1. Execute o seguinte comando para obter os estados de resumo de patches por nó gerenciado para um grupo de patches. O resumo por nó gerenciado inclui vários patches nos respectivos estados de patch por instância para um grupo de patches.

------
#### [ Linux & macOS ]

   ```
   aws ssm describe-instance-patch-states-for-patch-group \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm describe-instance-patch-states-for-patch-group ^
       --patch-group "Database Servers"
   ```

------

   O sistema retorna informações como estas.

   ```
   {
      "InstancePatchStates": [ 
         { 
            "BaselineId": "string",
            "FailedCount": number,
            "InstalledCount": number,
            "InstalledOtherCount": number,
            "InstalledPendingRebootCount": number,
            "InstalledRejectedCount": number,
            "InstallOverrideList": "string",
            "InstanceId": "string",
            "LastNoRebootInstallOperationTime": number,
            "MissingCount": number,
            "NotApplicableCount": number,
            "Operation": "string",
            "OperationEndTime": number,
            "OperationStartTime": number,
            "OwnerInformation": "string",
            "PatchGroup": "string",
            "RebootOption": "string",
            "SnapshotId": "string",
            "UnreportedNotApplicableCount": number
         }
      ]
   }
   ```

Para obter exemplos de outros comandos da AWS CLI que você pode usar nas tarefas de configuração do Patch Manager, consulte [Trabalhar com recursos do Patch Manager usando a AWS CLI](patch-manager-cli-commands.md).

# Solução de problemas do Patch Manager
<a name="patch-manager-troubleshooting"></a>

Use as informações a seguir para obter ajuda para solucionar problemas com o Patch Manager, uma ferramenta do AWS Systems Manager.

**Topics**
+ [Problema: erro “Invoke-PatchBaselineOperation: Access Denied” ou erro “Unable to download file from S3” para `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Problema: a aplicação de patches falha sem uma causa aparente ou mensagem de erro](#race-condition-conflict)
+ [Problema: resultados inesperados de conformidade de patches](#patch-manager-troubleshooting-compliance)
+ [Erros ao executar `AWS-RunPatchBaseline` no Linux](#patch-manager-troubleshooting-linux)
+ [Erros ao executar `AWS-RunPatchBaseline` no Windows Server](#patch-manager-troubleshooting-windows)
+ [Erros ao executar `AWS-RunPatchBaseline` no macOS](#patch-manager-troubleshooting-macos)
+ [Como usar runbooks do AWS Support Automation](#patch-manager-troubleshooting-using-support-runbooks)
+ [Entrar em contato com o AWS Support](#patch-manager-troubleshooting-contact-support)

## Problema: erro “Invoke-PatchBaselineOperation: Access Denied” ou erro “Unable to download file from S3” para `baseline_overrides.json`
<a name="patch-manager-troubleshooting-patch-policy-baseline-overrides"></a>

**Problema**: quando as operações de aplicação de patches especificadas pela política de patch são executadas, você recebe um erro semelhante ao exemplo a seguir. 

------
#### [ Example error on Windows Server ]

```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```

------
#### [ Example error on Linux ]

```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```

------

**Causa**: você criou uma política de patch na Quick Setup, e alguns de seus nós gerenciados já tinham um perfil de instância anexado (para instâncias do EC2) ou um perfil de serviço anexado (para máquinas que não são do EC2). 

No entanto, conforme mostrado na imagem a seguir, você não marcou a caixa de seleção **Adicionar políticas do IAM necessárias aos perfis de instância existentes anexados às suas instâncias**.

![\[\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/QS-instance-profile-option.png)


Quando você cria uma política de patch, também é criado um bucket do Amazon S3 para armazenar o arquivo de configuração `baseline_overrides.json` da política. Se você não marcar a caixa de seleção **Adicionar políticas do IAM necessárias aos perfis de instância existentes anexados às suas instâncias** ao criar a política, as políticas do IAM e as etiquetas de recursos necessárias para acessar `baseline_overrides.json` no bucket do S3 não serão adicionadas automaticamente aos perfis de instâncias e perfis de serviço já existentes no IAM.

**Solução 1**: exclua a configuração da política de patch atual e crie uma substituta, certificando-se de marcar a caixa de seleção **Adicionar políticas do IAM necessárias aos perfis de instância existentes anexados às suas instâncias**. Essa seleção aplica as políticas do IAM criadas por essa configuração da Quick Setup aos nós que já têm um perfil de instância ou um perfil de serviço anexado. (Por padrão, a Quick Setup adiciona as políticas necessárias às instâncias e aos nós que ainda *não* tenham perfis de instância ou perfis de serviço.) Para obter mais informações, consulte [Automate organization-wide patching using a Quick Setup patch policy](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html). 

**Solução 2**: adicione manualmente as permissões e etiquetas necessárias a cada perfil de instância do IAM e perfil de serviço do IAM que você usa com a Quick Setup. Para instruções, consulte [Permissões para o bucket do S3 da política de patch](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).

## Problema: a aplicação de patches falha sem uma causa aparente ou mensagem de erro
<a name="race-condition-conflict"></a>

**Problema**: uma operação de aplicação de patches falha sem retornar uma mensagem de erro.

**Possível causa**: ao aplicar patches em nós gerenciados, a execução do documento pode ser interrompida e marcada como falha, mesmo que os patches tenham sido instalados com sucesso. Isso pode ocorrer se o sistema iniciar uma reinicialização inesperada durante a operação de patch (por exemplo, para aplicar atualizações no firmware ou em atributos como o SecureBoot). O agente SSM não pode persistir e retomar o estado de execução do documento em reinicializações externas, resultando na execução relatada como falha. 

**Solução**: para verificar o status da instalação do patch após uma falha na execução, execute uma das operações de aplicação de patches `Scan` e verifique os dados de conformidade do patch no Patch Manager para avaliar o estado atual de conformidade.

Se você determinar que reinicializações externas conflitantes não foram a causa da falha nesse cenário, recomendamos que entre em contato com o [AWS Support](#patch-manager-troubleshooting-contact-support).

## Problema: resultados inesperados de conformidade de patches
<a name="patch-manager-troubleshooting-compliance"></a>

**Problema**: ao analisar os detalhes de conformidade dos patches gerados após uma operação `Scan`, os resultados incluem informações que não refletem as regras definidas na lista de referência de patches. Por exemplo, uma exceção adicionada à lista **Rejected patches** (Patches rejeitados) em uma lista de referência de patches é listada como `Missing`. Ou os patches classificados como `Important` estão listados como ausentes, mesmo que sua lista de referência de patches especifique somente patches `Critical`.

**Causa**: Patch Manager atualmente oferece suporte a vários métodos de execução de operações `Scan`:
+ Uma política de patch configurada no Quick Setup
+ Uma opção do Host Management configurada no Quick Setup
+ Uma janela de manutenção para executar um patch `Scan` ou tarefa `Install`
+ Uma operação **Patch now** (Aplicar patch agora) sob demanda

Quando uma operação `Scan` é executada, ela substitui os detalhes de conformidade da verificação mais recente. Se você tiver mais de um método configurado para executar uma operação `Scan`, e eles usarem listas de referência de patches diferentes com regras diferentes, eles resultarão em resultados de conformidade de patches diferentes. 

**Solução**: para evitar resultados inesperados de conformidade de patches, recomendamos usar somente um método por vez para executar a operação `Scan` do Patch Manager. Para obter mais informações, consulte [Identificar a execução que criou os dados de conformidade do patch](patch-manager-compliance-data-overwrites.md).

## Erros ao executar `AWS-RunPatchBaseline` no Linux
<a name="patch-manager-troubleshooting-linux"></a>

**Topics**
+ [Problema: erro 'Nenhum arquivo ou diretório'](#patch-manager-troubleshooting-linux-1)
+ [Problema: erro 'outro processo adquiriu bloqueio yum'](#patch-manager-troubleshooting-linux-2)
+ [Problema: erro 'Permissão negada/falhou ao executar comandos'](#patch-manager-troubleshooting-linux-3)
+ [Problema: Erro 'Não é possível baixar a carga de pagamento'](#patch-manager-troubleshooting-linux-4)
+ [Problema: erro 'gerenciador de pacotes não suportado e combinação de versão python'](#patch-manager-troubleshooting-linux-5)
+ [Problema: o Patch Manager não está aplicando regras especificadas para excluir determinados pacotes](#patch-manager-troubleshooting-linux-6)
+ [Problema: falha na aplicação de patches e o Patch Manager relata que a extensão Indicação de Nome do Servidor para TLS não está disponível](#patch-manager-troubleshooting-linux-7)
+ [Problema: o Patch Manager relata "Não há mais espelhos para tentar"](#patch-manager-troubleshooting-linux-8)
+ [Problema: a aplicação de patches falhou com “Error code returned from curl is 23”](#patch-manager-troubleshooting-linux-9)
+ [Problema: falha na aplicação de patches com a mensagem “Error unpacking rpm package...”](#error-unpacking-rpm)
+ [Problema: a aplicação de patches falha com a mensagem “Encounter service side error when uploading the inventory”](#inventory-upload-error)
+ [Problema: falha na aplicação de patches com a mensagem “Errors were encountered while downloading packages”](#errors-while-downloading)
+ [Problema: falha na aplicação de patches com erro de memória](#patch-manager-troubleshooting-linux-oom)
+ [Problema: falha na aplicação de patches com a mensagem “Não foi possível verificar as seguintes assinaturas, pois a chave pública não está disponível”](#public-key-unavailable)
+ [Problema: falha na aplicação de patches com a mensagem “NoMoreMirrorsRepoError”](#no-more-mirrors-repo-error)
+ [Problema: falha na aplicação de patches com a mensagem “Unable to download payload”](#payload-download-error)
+ [Problema: falha na aplicação de patches com a mensagem “install errors: dpkg: error: dpkg frontend is locked by another process”](#dpkg-frontend-locked)
+ [Problema: a aplicação de patches no Ubuntu Server falha com um erro “dpkg was interrupted”](#dpkg-interrupted)
+ [Problema: o utilitário gerenciador de pacotes não consegue resolver uma dependência de pacote](#unresolved-dependency)
+ [Problema: falhas na dependência do bloqueio de pacotes zypper em nós gerenciados pelo SLES](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Problema: não é possível adquirir bloqueio. Outra operação de aplicação de patch está em andamento.](#patch-manager-troubleshooting-linux-concurrent-lock)

### Problema: erro 'Nenhum arquivo ou diretório'
<a name="patch-manager-troubleshooting-linux-1"></a>

**Problema**: Quando você executa`AWS-RunPatchBaseline`, o patch falha com um dos seguintes erros.

```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```

```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```

```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```

**Causa 1**: dois comandos para executar `AWS-RunPatchBaseline` estavam em execução ao mesmo tempo no mesmo nó. Isso cria uma condição de corrida que resulta no`file patch-baseline-operations*`não sendo criado ou acessado corretamente.

**Causa 2**: espaço de armazenamento insuficiente permanece no diretório `/var`. 

**Solução 1**: certifique-se de que nenhuma janela de manutenção tenha duas ou mais tarefas do Run Command que executam o `AWS-RunPatchBaseline` com o mesmo nível de prioridade e que executem nos mesmos IDs de destino. Se for esse o caso, reordene a prioridade. O Run Command é uma ferramenta do AWS Systems Manager.

**Solução 2**: certifique-se de que apenas uma janela de manutenção de cada vez esteja executando tarefas do Run Command que usam `AWS-RunPatchBaseline` nos mesmos alvos e na mesma programação. Nesse caso, altere o horário.

**Solução 3**: certifique-se de que apenas uma associação do State Manager esteja em execução no `AWS-RunPatchBaseline` na mesma agenda e voltada para os mesmos nós gerenciados. O State Manager é uma ferramenta do AWS Systems Manager.

**Solução 4**: libere espaço de armazenamento suficiente sob o diretório `/var` para os pacotes de atualização.

### Problema: erro 'outro processo adquiriu bloqueio yum'
<a name="patch-manager-troubleshooting-linux-2"></a>

**Problema**: Quando você executa`AWS-RunPatchBaseline`A aplicação de patch falha com o erro a seguir.

```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```

**Causa**: o documento `AWS-RunPatchBaseline` começou a ser executado em um nó gerenciado onde já está sendo executado em outra operação e adquiriu o processo `yum` do gerenciador de pacotes.

**Solução**: certifique-se de que nenhuma associação, tarefa da janela de manutenção ou outras configuração do State Manager executada no `AWS-RunPatchBaseline` em uma programação esteja voltada para o mesmo nó gerenciado de destino aproximadamente ao mesmo tempo.

### Problema: erro 'Permissão negada/falhou ao executar comandos'
<a name="patch-manager-troubleshooting-linux-3"></a>

**Problema**: Quando você executa`AWS-RunPatchBaseline`A aplicação de patch falha com o erro a seguir.

```
sh: 
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```

**Causa**: o `/var/lib/amazon/` pode ser montado com permissões do `noexec`. Este é um problema porque o SSM Agent faz o download de scripts de carga para `/var/lib/amazon/ssm` e os executa a partir desse local.

**Solução**: confirme se você configurou partições exclusivas para `/var/log/amazon` e `/var/lib/amazon`, e se elas estão montadas com permissões `exec`.

### Problema: Erro 'Não é possível baixar a carga de pagamento'
<a name="patch-manager-troubleshooting-linux-4"></a>

**Problema**: Quando você executa`AWS-RunPatchBaseline`A aplicação de patch falha com o erro a seguir.

```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```

**Causa**: o nó gerenciado não tem as permissões necessárias para acessar o bucket especificado do Amazon Simple Storage Service (Amazon S3).

**Solução**: atualize sua configuração de rede para que os endpoints do S3 estejam acessíveis. Para obter mais detalhes, consulte informações sobre o acesso necessário aos buckets do S3 para o Patch Manager em [SSM Agent Comunicações do AWS com os buckets do S3 gerenciados pela](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).

### Problema: erro 'gerenciador de pacotes não suportado e combinação de versão python'
<a name="patch-manager-troubleshooting-linux-5"></a>

**Problema**: Quando você executa`AWS-RunPatchBaseline`A aplicação de patch falha com o erro a seguir.

```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```

**Causa**: uma versão com suporte do python3 não está instalada na instância do Debian Server ou Ubuntu Server.

**Solução**: instale uma versão com suporte do Python 3 (3.0 a 3.12) no servidor, que é necessária para nós gerenciados do Debian Server e Ubuntu Server.

### Problema: o Patch Manager não está aplicando regras especificadas para excluir determinados pacotes
<a name="patch-manager-troubleshooting-linux-6"></a>

**Problema**: Você tentou excluir determinados pacotes especificando-os na seção`/etc/yum.conf`, no formato`exclude=package-name`, mas eles não são excluídos durante oPatch Manager `Install`operação.

**Causa**: o Patch Manager não incorpora exclusões especificadas no arquivo `/etc/yum.conf`.

**Solução**: Para excluir pacotes específicos, crie uma linha de base de patch personalizada e crie uma regra para excluir os pacotes que você não deseja instalar.

### Problema: falha na aplicação de patches e o Patch Manager relata que a extensão Indicação de Nome do Servidor para TLS não está disponível
<a name="patch-manager-troubleshooting-linux-7"></a>

**Problema**: A operação de patch emite a seguinte mensagem.

```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369: 
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS 
certificate, which can cause validation failures. You can upgrade to a newer version of Python 
to solve this. 
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```

**Causa**: esta mensagem não indica um erro. Em vez disso, é um aviso de que a versão mais antiga do Python distribuída com o sistema operacional não suporta a Indicação de Nome do Servidor TLS. O script de carga de patch do Systems Manager emite este aviso ao se conectar a APIs da AWS que oferecem suporte a SNI.

**Solução**: para solucionar problemas de falhas de patch quando essa mensagem é relatada, revise o conteúdo do`stdout`e`stderr`arquivos. Se você não configurou a lista de referência de patches para armazenar esses arquivos em um bucket do S3 ou no Amazon CloudWatch Logs, é possível localizar os arquivos no local a seguir em seu nó gerenciado do Linux. 

`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`

### Problema: o Patch Manager relata "Não há mais espelhos para tentar"
<a name="patch-manager-troubleshooting-linux-8"></a>

**Problema**: A operação de patch emite a seguinte mensagem.

```
[Errno 256] No more mirrors to try.
```

**Causa**: os repositórios configurados em seu nó gerenciado não estão funcionando corretamente. As possíveis causas incluem:
+ O`yum`A cache está corrompida.
+ Um URL de repositório não pode ser alcançado devido a problemas relacionados à rede.

**Solução**: o Patch Manager usa o gerenciador de pacotes padrão do nó gerenciado para executar a operação de aplicação de patch. Verifique se os repositórios estão configurados e funcionando corretamente.

### Problema: a aplicação de patches falhou com “Error code returned from curl is 23”
<a name="patch-manager-troubleshooting-linux-9"></a>

**Problema**: uma operação de aplicação de patches que usa `AWS-RunPatchBaseline` falha com um erro semelhante a este:

```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```

**Causa**: a ferramenta curl usada em seus sistemas não tem as permissões necessárias para gravar no sistema de arquivos. Isso pode ocorrer quando a ferramenta curl padrão do gerenciador de pacotes foi substituída por outra versão, como uma instalada com snap.

**Solução**: se a versão curl fornecida pelo gerenciador de pacotes foi desinstalada quando outra versão foi instalada, reinstale-a.

Se você precisar manter várias versões do curl instaladas, certifique-se de que a versão associada ao gerenciador de pacotes esteja no primeiro diretório listado na variável `PATH`. Você pode verificar isso executando o comando `echo $PATH` para ver a ordem atual dos diretórios de seu sistema que estão sendo verificados quanto a arquivos executáveis.

### Problema: falha na aplicação de patches com a mensagem “Error unpacking rpm package...”
<a name="error-unpacking-rpm"></a>

**Problema**: uma operação de aplicação de patches falha com um erro semelhante a este:

```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```

**Causa 1**: quando um pacote específico está presente em vários instaladores de pacotes, como `pip` e `yum` ou `dnf`, podem ocorrer conflitos ao usar o gerenciador de pacotes padrão.

Um exemplo comum ocorre com o pacote `urllib3`, encontrado em `pip`, `yum` e `dnf`.

**Causa 2**: o pacote `python-urllib3` está corrompido. Isso poderá acontecer se os arquivos do pacote tiverem sido instalados ou atualizados pelo `pip` após o pacote `rpm` ter sido instalado anteriormente por `yum` ou `dnf`.

**Solução**: remova o pacote `python-urllib3` do pip executando o comando `sudo pip uninstall urllib3`, mantendo o pacote somente no gerenciador de pacotes padrão (`yum` ou `dnf`). 

### Problema: a aplicação de patches falha com a mensagem “Encounter service side error when uploading the inventory”
<a name="inventory-upload-error"></a>

**Problema**: ao executar o documento `AWS-RunPatchBaseline`, você recebe a seguinte mensagem de erro:

```
Encounter service side error when uploading the inventory
```

**Causa**: dois comandos para executar `AWS-RunPatchBaseline` estavam em execução ao mesmo tempo no mesmo nó gerenciado. Isso cria uma condição de corrida ao inicializar o cliente boto3 durante as operações de aplicação de patches.

**Solução**: certifique-se de que nenhuma associação, tarefa da janela de manutenção ou outras configuração do State Manager executada no `AWS-RunPatchBaseline` em uma programação esteja voltada para o mesmo nó gerenciado de destino aproximadamente ao mesmo tempo.

### Problema: falha na aplicação de patches com a mensagem “Errors were encountered while downloading packages”
<a name="errors-while-downloading"></a>

**Problema**: durante a aplicação de patches, você recebe um erro semelhante a este:

```
YumDownloadError: [u'Errors were encountered while downloading 
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12] 
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5] 
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64: 
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64: 
[Errno 5] [Errno 12] Cannot allocate memory',
```

**Causa**: esse erro pode ocorrer quando a memória disponível em um nó gerenciado é insuficiente.

**Solução**: configure a memória swap ou atualize a instância para um tipo diferente para aumentar o suporte à memória. Em seguida, inicie uma nova operação de aplicação de patches.

### Problema: falha na aplicação de patches com erro de memória
<a name="patch-manager-troubleshooting-linux-oom"></a>

**Problema**: quando você executa `AWS-RunPatchBaseline`, a operação de patch falha devido à memória insuficiente no nó gerenciado. Você pode ver erros como `Cannot allocate memory`, `Killed` (do Linux OOM killer) ou a operação falhar inesperadamente. É mais provável que esse erro ocorra em instâncias com menos de 1 GB de RAM, mas também pode afetar instâncias com mais memória quando existem muitas atualizações disponíveis.

**Causa**: o Patch Manager executa operações de patch usando o gerenciador de pacotes nativo no nó gerenciado. A memória necessária durante uma operação de patch depende de vários fatores, entre eles:
+ O número de pacotes instalados e as atualizações disponíveis no nó gerenciado.
+ O gerenciador de pacotes em uso e suas características de memória.
+ Da mesma maneira, o Patch Manager pode instalar somente patches que estão disponíveis no nó gerenciado durante o período de operação de patches com erro de memória

Os nós gerenciados com muitos pacotes instalados ou diversas atualizações disponíveis exigem mais memória durante operações de patch. Quando a memória disponível é insuficiente, o processo de correção falha e é encerrado com um erro. O sistema operacional também pode encerrar o processo de correção.

**Solução**: experimente uma ou mais das seguintes opções:
+ Programe as operações de aplicação de patches para períodos de baixa workload no nó gerenciado, por exemplo, utilizando janelas de manutenção.
+ Faça upgrade da instância para um tipo com mais memória.
+ Configure a memória de permuta no nó gerenciado. Observe que, em instâncias com throughput limitado do EBS, o uso intenso da área de troca pode causar uma queda na performance.
+ Analise e reduza o número de processos em execução no nó gerenciado durante as operações de aplicação de patches.

### Problema: falha na aplicação de patches com a mensagem “Não foi possível verificar as seguintes assinaturas, pois a chave pública não está disponível”
<a name="public-key-unavailable"></a>

**Problema**: aplicação de patches falha no Ubuntu Server com um erro semelhante a este:

```
02/17/2022 21:08:43 root [ERROR]: W:GPG error: 
http://repo.mysql.com/apt/ubuntu  bionic InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```

**Causa**: a chave GNU Privacy Guard (GPG) expirou ou está ausente.

**Solução**: atualize a chave GPG ou adicione a chave novamente.

Por exemplo, usando o erro mostrado anteriormente, vemos que a chave `467B942D3A79BD29` está ausente e deve ser adicionada. Para fazer isso, execute um dos comandos a seguir:

```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```

```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```

Ou, para atualizar todas as chaves, execute este comando:

```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```

Se o erro persistir depois disso, é recomendável relatar o problema à organização que retém o repositório. Até que uma correção esteja disponível, você pode editar o arquivo `/etc/apt/sources.list` de modo a omitir o repositório durante o processo de aplicação de patches.

Para fazer isso, abra o arquivo `sources.list` para edição, localize a linha do repositório e insira um caractere `#` no início da linha para comentá-la. Depois, salve e feche o arquivo.

### Problema: falha na aplicação de patches com a mensagem “NoMoreMirrorsRepoError”
<a name="no-more-mirrors-repo-error"></a>

**Problema**: você recebe um erro semelhante a este:

```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```

**Causa**: há um erro no repositório de origem.

**Solução**: é recomendável relatar o problema à organização que retém o repositório. Até que o erro seja corrigido, é possível desabilitar o repositório no nível do sistema operacional. Para isso, execute o seguinte comando, substituindo o valor de *repo-name* pelo nome do repositório:

```
yum-config-manager --disable repo-name
```

Veja um exemplo a seguir.

```
yum-config-manager --disable pgdg94
```

Depois de executar esse comando, execute outra operação de aplicação de patches.

### Problema: falha na aplicação de patches com a mensagem “Unable to download payload”
<a name="payload-download-error"></a>

**Problema**: você recebe um erro semelhante a este:

```
Unable to download payload: 
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed  to run commands: exit status 156
```

**Causa**: a configuração do nó gerenciado contém erros ou está incompleta.

**Solução**: verifique se o nó gerenciado está configurado desta forma:
+ Regra de saída TCP 443 no grupo de segurança.
+ Regra de saída TCP 443 em NACL.
+ Regra de entrada TCP 1024-65535 em NACL.
+ NAT/IGW na tabela de rotas para fornecer conectividade a um endpoint do S3. Se a instância não tiver acesso à Internet, forneça conectividade com o endpoint do S3. Para isso, adicione um endpoint de gateway do S3 à VPC e integre-o à tabela de rotas do nó gerenciado.

### Problema: falha na aplicação de patches com a mensagem “install errors: dpkg: error: dpkg frontend is locked by another process”
<a name="dpkg-frontend-locked"></a>

**Problema**: aplicação de patches falha com um erro semelhante a este:

```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```

**Causa**: o gerenciador de pacotes já está executando outro processo em um nó gerenciado no nível do sistema operacional. Se esse outro processo levar muito tempo para ser concluído, a operação de aplicação de patches do Patch Manager poderá atingir o tempo limite e falhar.

**Solução**: após a conclusão do outro processo que está usando o gerenciador de pacotes, execute uma nova operação de aplicação de patches.

### Problema: a aplicação de patches no Ubuntu Server falha com um erro “dpkg was interrupted”
<a name="dpkg-interrupted"></a>

**Problema**: no Ubuntu Server, a aplicação de patches falha com um erro semelhante a este:

```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```

**Causa**: um ou mais pacotes foram configurados incorretamente.

**Solução**Siga estas etapas:

1. Execute os seguintes comandos, um por vez, para verificar quais pacotes são afetados e quais são os problemas com cada pacote:

   ```
   sudo apt-get check
   ```

   ```
   sudo dpkg -C
   ```

   ```
   dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
   ```

1. Execute este comando para corrigir os pacotes com problemas:

   ```
   sudo dpkg --configure -a
   ```

1. Se o comando anterior não resolver totalmente o problema, execute este comando:

   ```
   sudo apt --fix-broken install
   ```

### Problema: o utilitário gerenciador de pacotes não consegue resolver uma dependência de pacote
<a name="unresolved-dependency"></a>

**Problema**: o gerenciador de pacotes nativo no nó gerenciado não consegue resolver uma dependência de pacote, e a aplicação de patches falha. O exemplo de mensagem de erro a seguir indica esse tipo de falha em um sistema operacional que usa o `yum` como gerenciador de pacotes.

```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1, 
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3', 
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```

**Causa**: em sistemas operacionais Linux, o Patch Manager usa o gerenciador de pacotes nativo da máquina para executar operações de aplicação de patches, como `yum`, `dnf`, `apt` e `zypper`. As aplicações detectam, instalam, atualizam ou removem automaticamente pacotes dependentes, conforme necessário. Porém, algumas condições podem fazer com que o gerenciador de pacotes não consiga concluir uma operação de dependência, como:
+ Múltiplos repositórios conflitantes estão configurados no sistema operacional.
+ O URL do repositório remoto está inacessível por causa de problemas relacionados à rede.
+ Foi encontrado um pacote para a arquitetura errada no repositório.

**Solução**: a aplicação de patches pode falhar por causa de um problema de dependência de diversos motivos. Portanto, é recomendável entrar em contato com o AWS Support para ajudar na solução de problemas.

### Problema: falhas na dependência do bloqueio de pacotes zypper em nós gerenciados pelo SLES
<a name="patch-manager-troubleshooting-linux-zypper-locks"></a>

**Problema**: quando você executa `AWS-RunPatchBaseline` com a operação `Install` em instâncias do SUSE Linux Enterprise Server, a aplicação de patches falha com erros de verificação de dependência relacionados a bloqueios de pacotes. Você poderá receber mensagens de erro semelhantes à seguinte mensagem:

```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
  uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
 Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
 Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
 Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c] (c): c
```

Neste exemplo, o pacote `mock-pkg-standalone` está bloqueado, o que você pode verificar executando `sudo zypper locks` e procurando esse nome de pacote na saída.

Ou você pode ver as entradas de logs indicando falhas na verificação de dependência:

```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```

**nota**  
Esse problema ocorre somente durante as operações `Install`. As operações `Scan` não aplicam bloqueios de pacotes e não são afetadas pelos bloqueios existentes.

**Causa**: este erro ocorre quando os bloqueios de pacotes zypper impedem a instalação ou atualização de pacotes por causa de conflitos de dependência. Os bloqueios de pacotes podem estar presentes por diversos motivos:
+ **Bloqueios aplicados pelo cliente**: você ou o administrador do sistema bloqueou pacotes manualmente usando comandos do zypper, como `zypper addlock`.
+ **Patches rejeitados pelo Gerenciador de Patches**: o Patch Manager aplica automaticamente bloqueios de pacotes quando você especifica pacotes na lista **Patches rejeitados** da sua lista de referência de patches para impedir a instalação.
+ **Bloqueios residuais de operações interrompidas**: em casos raros, se uma operação de patch foi interrompida (como por uma reinicialização do sistema) antes de o Patch Manager poder limpar os bloqueios temporários, os bloqueios residuais de pacotes poderão permanecer em seu nó gerenciado.

**Solução**: para resolver problemas de bloqueio de pacotes zypper, siga estas etapas com base na causa:

**Etapa 1: identificar pacotes bloqueados**

Conecte-se ao seu nó gerenciado pelo SLES e execute o seguinte comando para listar todos os pacotes atualmente bloqueados:

```
sudo zypper locks
```

**Etapa 2: determinar a origem dos bloqueios**
+ Se os pacotes bloqueados forem os que você bloqueou intencionalmente para a estabilidade do sistema, analise se eles precisam permanecer bloqueados ou se podem ser desbloqueados temporariamente para a aplicação de patches.
+ Se os pacotes bloqueados corresponderem às entradas da lista **Patches rejeitados** da sua lista de referência de patches, provavelmente são bloqueios residuais de uma operação de patch interrompida. Durante as operações normais, o Patch Manager aplica esses bloqueios temporariamente e os remove automaticamente quando a operação é concluída. Você pode remover os pacotes da lista de rejeitados ou modificar suas regras da lista de referência de patches.
+ Se você não reconhece os pacotes bloqueados e eles não foram bloqueados intencionalmente, eles podem ser bloqueios residuais de uma operação anterior de patch interrompida.

**Etapa 3: remover os bloqueios conforme apropriado**

Para remover bloqueios de pacotes específicos, use o seguinte comando:

```
sudo zypper removelock package-name
```

Para remover todos os bloqueios de pacotes (use com cautela), execute:

```
sudo zypper cleanlocks
```

**Etapa 4: atualizar a lista de referência de patches (se aplicável)**

Se os bloqueios foram causados por patches rejeitados na lista de referência de patches:

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 **Patch Manager**.

1. Escolha a guia **Listas de referência de patches**, e depois escolha sua lista de referência de patches personalizada.

1. Escolha **Ações**, **Modificar lista de referência de patches**.

1. Na seção **Patches rejeitados**, revise os pacotes listados e remova os que devem ter permissão para instalação.

1. Escolha **Salvar alterações**.

**Etapa 5: tentar novamente a operação de patch**

Depois de remover os bloqueios problemáticos e atualizar a lista de referência de patches, se necessário, execute o documento `AWS-RunPatchBaseline` novamente.

**nota**  
Quando o Patch Manager aplica bloqueios para patches rejeitados durante as operações `Install`, ele foi projetado para limpar esses bloqueios automaticamente após a conclusão da operação de patch. Se você vir esses bloqueios durante a execução de `sudo zypper locks`, isso indica que uma operação de patch anterior foi interrompida antes que a limpeza pudesse ocorrer. No entanto, se uma operação de patch for interrompida, a limpeza manual poderá ser necessária, conforme descrito neste procedimento.

**Prevenção**: para evitar futuros conflitos de bloqueios do zypper:
+ Analise cuidadosamente a lista de patches rejeitados da sua lista de referência de patches para garantir que ela inclua somente pacotes que você realmente deseja excluir.
+ Evite bloquear manualmente pacotes que possam ser necessários como dependências para as atualizações de segurança.
+ Se você precisar bloquear pacotes manualmente, documente os motivos e revise os bloqueios periodicamente.
+ Certifique-se de que as operações de patch sejam concluídas com êxito e não sejam interrompidas por reinicializações do sistema ou outros fatores.
+ Monitore as operações de patch até a conclusão e evite interrompê-las com reinicializações do sistema ou outras ações que possam impedir a limpeza adequada dos bloqueios temporários.

### Problema: não é possível adquirir bloqueio. Outra operação de aplicação de patch está em andamento.
<a name="patch-manager-troubleshooting-linux-concurrent-lock"></a>

**Problema**: quando você executa `AWS-RunPatchBaseline`, ocorre falha na aplicação de patch com a mensagem de erro 4 a seguir.

```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Causa**: esse erro ocorre quando é feita uma tentativa de executar várias operações de aplicação de patch no mesmo nó gerenciado ao mesmo tempo. O arquivo de bloqueio impede operações simultâneas de aplicação de patch para evitar conflitos e garantir a estabilidade do sistema.

**Solução**: garanta que as operações de aplicação de patch não sejam agendadas para execução no mesmo nó gerenciado ao mesmo tempo. Analise as seguintes configurações para identificar e resolver conflitos de agendamento:
+ **Políticas de patches**: verifique as configurações da política de patches da Configuração Rápida para garantir que elas não coincidam com o agendamento de outras aplicações de patch.
+ **Janelas de manutenção**: revise as associações das janelas de manutenção para garantir que várias janelas não se destinem à aplicação de patches nos mesmos nós gerenciados em horários coincidentes.
+ **Operações manuais Aplicar patch agora**: evite iniciar operações manuais **Aplicar patch agora** enquanto uma aplicação de patch agendada estiver em andamento.

## Erros ao executar `AWS-RunPatchBaseline` no Windows Server
<a name="patch-manager-troubleshooting-windows"></a>

**Topics**
+ [Problema: família de produtos/pares de produtos incompatíveis](#patch-manager-troubleshooting-product-family-mismatch)
+ [Problema:`AWS-RunPatchBaseline`retorna um`HRESULT`(Windows Server)](#patch-manager-troubleshooting-hresult)
+ [Problema: o nó gerenciado não tem acesso ao Catálogo do Windows Update ou ao WSUS](#patch-manager-troubleshooting-instance-access)
+ [Problema: o módulo PatchBaselineOperations PowerShell não pode ser baixado](#patch-manager-troubleshooting-module-not-downloadable)
+ [Problema: patches ausentes](#patch-manager-troubleshooting-missing-patches)
+ [Problema: não é possível adquirir bloqueio. Outra operação de aplicação de patch está em andamento.](#patch-manager-troubleshooting-windows-concurrent-lock)

### Problema: família de produtos/pares de produtos incompatíveis
<a name="patch-manager-troubleshooting-product-family-mismatch"></a>

**Problema**: ao criar uma lista de referência de patches no console do Systems Manager, você especifica uma família de produtos e um produto. Por exemplo, você pode escolher:
+ **Product family (Família de produtos**: `Office`

  **Produto**: `Office 2016`

**Cause**: se você tentar criar uma linha de base de patch com um par ou uma família de produtos sem correspondência, uma mensagem de erro será exibida. Isso pode acontecer pelos seguintes motivos:
+ Você selecionou um par e uma família de produtos, mas depois removeu a seleção da família de produtos.
+ Você escolheu um produto na sublista **Obsolete or mismatched options (Opções obsoletas ou incompatíveis)** em vez de sublista **Available and matching options (Opções disponíveis e correspondentes)**. 

  Os itens na sublista **Obsolete or mismatched options** (Opções obsoletas ou incompatíveis) do produto podem ter sido inseridos incorretamente por um SDK ou comando `create-patch-baseline` da AWS Command Line Interface (AWS CLI). Isso pode significar um erro ortográfico foi introduzido ou um produto foi atribuído à família de produtos errada. Um produto também será incluído na sublista **Obsolete or mismatched options** (Opções obsoletas ou incompatíveis) se tiver sido especificado para uma linha de base de patch anterior, mas não tiver patches disponibilizados pela Microsoft. 

**Solução**: para evitar esse problema no console, sempre escolha opções das sublistas **Currently available options** (Opções atualmente disponíveis).

Você também pode visualizar os produtos com patches atualmente disponíveis usando o comando `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` na AWS CLI ou o comando da API `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)`.

### Problema:`AWS-RunPatchBaseline`retorna um`HRESULT`(Windows Server)
<a name="patch-manager-troubleshooting-hresult"></a>

**Problema:** você recebeu um erro semelhante ao seguinte:

```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when 
attempting to search Windows Update.
Exception Level 1:
 Error Message: Exception from HRESULT: 0x80240437
 Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```

**Causa**: esta saída indica que as APIs nativas do Windows Update não conseguiram executar as operações de aplicação de patches.

**Solução**: verifique o código `HResult` nos tópicos a seguir em microsoft.com para identificar as etapas de solução de problemas e resolver o erro:
+ [Códigos de erro do Windows Update por componente](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference) 
+ [Erros comuns e mitigações do Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors) 

### Problema: o nó gerenciado não tem acesso ao Catálogo do Windows Update ou ao WSUS
<a name="patch-manager-troubleshooting-instance-access"></a>

**Problema:** você recebeu um erro semelhante ao seguinte:

```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.

Extracting PatchBaselineOperations zip file contents to temporary folder.

Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.

Successfully downloaded and installed the PatchBaselineOperations PowerShell module.

Patch Summary for

PatchGroup :

BaselineId :

Baseline : null

SnapshotId :

RebootOption : RebootIfNeeded

OwnerInformation :

OperationType : Scan

OperationStartTime : 1970-01-01T00:00:00.0000000Z

OperationEndTime : 1970-01-01T00:00:00.0000000Z

InstalledCount : -1

InstalledRejectedCount : -1

InstalledPendingRebootCount : -1

InstalledOtherCount : -1

FailedCount : -1

MissingCount : -1

NotApplicableCount : -1

UnreportedNotApplicableCount : -1

EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169

----------ERROR-------

Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.

Exception Level 1:

Error Message: Exception from HRESULT: 0x80072EE2

Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)

at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String

searchCriteria)

At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58

e3\PatchWindows\_script.ps1:230 char:13

+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv

oke-PatchBaselineOperation], Exception

+ FullyQualifiedErrorId : Exception Level 1:

Error Message: Exception Details: An error occurred when attempting to search Windows Update.

Exception Level 1:

Error Message: Exception from HRESULT: 0x80072EE2

Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)

at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc

---Error truncated----
```

**Causa**: este erro pode estar relacionado aos componentes do Windows Update ou a falta de conectividade com o Catálogo do Windows Update ou Windows Server Update Services (WSUS).

**Solução**: confirme se o nó gerenciado tem conectividade com o [Catálogo do Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx) por meio de um gateway da Internet, um gateway de NAT ou uma instância NAT. Se você estiver usando o WSUS, confirme se o nó gerenciado tem conectividade com o servidor WSUS em seu ambiente. Se a conectividade estiver disponível para o destino pretendido, verifique a documentação da Microsoft para outras causas potenciais do `HResult 0x80072EE2`. Isso pode indicar um problema no nível do sistema operacional. 

### Problema: o módulo PatchBaselineOperations PowerShell não pode ser baixado
<a name="patch-manager-troubleshooting-module-not-downloadable"></a>

**Problema:** você recebeu um erro semelhante ao seguinte:

```
Preparing to download PatchBaselineOperations PowerShell module from S3.
                    
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------

C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\

PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server

+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException

+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1

failed to run commands: exit status 4294967295
```

**Solução**: confira a conectividade e as permissões do nó gerenciado para o Amazon Simple Storage Service (Amazon S3). A função AWS Identity and Access Management (IAM) do nó gerenciado deve usar as permissões mínimas citadas em [SSM Agent Comunicações do AWS com os buckets do S3 gerenciados pela](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions). O nó deve se comunicar com o endpoint do Amazon S3 por meio do endpoint do gateway do Amazon S3, do gateway NAT ou do gateway da Internet. Para obter mais informações sobre os requisitos do endpoint da VPC para oAWS Systems Manager SSM Agent (SSM Agent), consulte [Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager](setup-create-vpc.md). 

### Problema: patches ausentes
<a name="patch-manager-troubleshooting-missing-patches"></a>

**Problema**:`AWS-RunPatchbaseline`concluída com êxito, mas há alguns patches ausentes.

Veja a seguir algumas causas comuns e suas soluções.

**Causa 1**: lista de referência não é eficaz.

**Solução 1**: Para verificar se essa é a causa, use o procedimento a seguir.

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 **Run Command**.

1. Selecione o **Histórico de comandos** e selecione o comando cuja linha de base você deseja verificar.

1. Selecione o nó gerenciado que tiver patches ausentes.

1. Selecione **Etapa 1: saída** e encontre o valor de `BaselineId`.

1. Verifique a [configuração da lista de referência de patches](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) atribuída, ou seja, o sistema operacional, o nome do produto, a classificação e a gravidade da lista de referência do patch.

1. Acesse o [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx).

1. Pesquise os IDs de artigo da Base de Dados de Conhecimento Microsoft (KB) (por exemplo, KB3216916).

1. Verifique se o valor em **Product** (Produto) corresponde ao do nó gerenciado e selecione o **Title** (Título) correspondente. Uma nova janela **Update Details** (Atualizar detalhes) será aberta.

1. Na guia **Visão geral**, a **classificação** e a **gravidade do MSRC** devem corresponder à configuração da lista de referência de patches encontrada anteriormente.

**Causa 2**: o patch foi substituído.

**Solução 2**: Para conferir se isso de fato ocorreu, use o procedimento a seguir.

1. Acesse o [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx).

1. Pesquise os IDs de artigo da Base de Dados de Conhecimento Microsoft (KB) (por exemplo, KB3216916).

1. Verifique se o valor em **Product** (Produto) corresponde ao do nó gerenciado e selecione o **Title** (Título) correspondente. Uma nova janela **Update Details** (Atualizar detalhes) será aberta.

1. Acesse a guia **Package Details** (Detalhes do Pacote). Procure por uma entrada no cabeçalho **Esta atualização foi substituída pelas seguintes atualizações:**

**Causa 3**: o mesmo patch pode ter números de KB diferentes porque as atualizações online do WSUS e do Windows são tratadas como canais de lançamento independentes pela Microsoft.

**Solução 3**: Verifique a elegibilidade do patch. Se o pacote não estiver disponível no WSUS, instale a [Compilação do SO 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Se o pacote estiver disponível para todas as compilações do sistema operacional, instale as [Compilações do SO 18362.1256 e 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).

### Problema: não é possível adquirir bloqueio. Outra operação de aplicação de patch está em andamento.
<a name="patch-manager-troubleshooting-windows-concurrent-lock"></a>

**Problema**: quando você executa `AWS-RunPatchBaseline`, ocorre falha na aplicação de patch com a mensagem de erro 4 a seguir.

```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Causa**: esse erro ocorre quando é feita uma tentativa de executar várias operações de aplicação de patch no mesmo nó gerenciado ao mesmo tempo. O arquivo de bloqueio impede operações simultâneas de aplicação de patch para evitar conflitos e garantir a estabilidade do sistema.

**Solução**: garanta que as operações de aplicação de patch não sejam agendadas para execução no mesmo nó gerenciado ao mesmo tempo. Analise as seguintes configurações para identificar e resolver conflitos de agendamento:
+ **Políticas de patches**: verifique as configurações da política de patches da Configuração Rápida para garantir que elas não coincidam com o agendamento de outras aplicações de patch.
+ **Janelas de manutenção**: revise as associações das janelas de manutenção para garantir que várias janelas não se destinem à aplicação de patches nos mesmos nós gerenciados em horários coincidentes.
+ **Operações manuais Aplicar patch agora**: evite iniciar operações manuais **Aplicar patch agora** enquanto uma aplicação de patch agendada estiver em andamento.

## Erros ao executar `AWS-RunPatchBaseline` no macOS
<a name="patch-manager-troubleshooting-macos"></a>

**Topics**
+ [Problema: não é possível adquirir bloqueio. Outra operação de aplicação de patch está em andamento.](#patch-manager-troubleshooting-macos-concurrent-lock)

### Problema: não é possível adquirir bloqueio. Outra operação de aplicação de patch está em andamento.
<a name="patch-manager-troubleshooting-macos-concurrent-lock"></a>

**Problema**: quando você executa `AWS-RunPatchBaseline`, ocorre falha na aplicação de patch com a mensagem de erro 4 a seguir.

```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Causa**: esse erro ocorre quando é feita uma tentativa de executar várias operações de aplicação de patch no mesmo nó gerenciado ao mesmo tempo. O arquivo de bloqueio impede operações simultâneas de aplicação de patch para evitar conflitos e garantir a estabilidade do sistema.

**Solução**: garanta que as operações de aplicação de patch não sejam agendadas para execução no mesmo nó gerenciado ao mesmo tempo. Analise as seguintes configurações para identificar e resolver conflitos de agendamento:
+ **Políticas de patches**: verifique as configurações da política de patches da Configuração Rápida para garantir que elas não coincidam com o agendamento de outras aplicações de patch.
+ **Janelas de manutenção**: revise as associações das janelas de manutenção para garantir que várias janelas não se destinem à aplicação de patches nos mesmos nós gerenciados em horários coincidentes.
+ **Operações manuais Aplicar patch agora**: evite iniciar operações manuais **Aplicar patch agora** enquanto uma aplicação de patch agendada estiver em andamento.

## Como usar runbooks do AWS Support Automation
<a name="patch-manager-troubleshooting-using-support-runbooks"></a>

O AWS Support fornece dois runbooks do Automation que você pode usar para solucionar determinados problemas relacionados à aplicação de patches.
+ `AWSSupport-TroubleshootWindowsUpdate`: o runbook [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) é usado para identificar problemas que podem causar falhas nas atualizações do Windows Server para instâncias Windows Server do Amazon Elastic Compute Cloud (Amazon EC2).
+ `AWSSupport-TroubleshootPatchManagerLinux`: o runbook [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) soluciona problemas comuns que podem causar uma falha de aplicação de patch em nós gerenciados baseados em Linux ao usar o Patch Manager. O objetivo principal desse runbook é identificar a causa raiz da falha do comando de patch e sugerir um plano de correção.

**nota**  
A execução de runbooks do Automation é cobrada. Para obter informações, consulte [Preços do AWS Systems Manager para o Automation](https://aws.amazon.com/systems-manager/pricing/#Automation).

## Entrar em contato com o AWS Support
<a name="patch-manager-troubleshooting-contact-support"></a>

Se não conseguir encontrar soluções para a solução de problemas nesta seção  ou nos problemas do Systems Manager em [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager), e você tiver um [plano do Suporte Developer, Business, or Enterprise](https://aws.amazon.com/premiumsupport/plans), você poderá criar um caso de suporte técnico em [AWS Support](https://aws.amazon.com/premiumsupport/).

Antes de entrar em contato com o Suporte, colete os seguintes itens:
+ [Registros de atendentes do SSM](ssm-agent-logs.md)
+ ID de comando, ID de janela de manutenção ou ID de execução de automação do Run Command
+ Para os nós gerenciados do Windows Server, colete também o seguinte:
  + `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`, conforme descrito na guia **Windows** do [Como os patches são instalados](patch-manager-installing-patches.md)
  + Registros de atualização do Windows: ParaWindows Server2012 R2 e anteriores, use`%windir%/WindowsUpdate.log`. Para o Windows Server 2016 e mais recente, primeiro execute o comando do PowerShell[https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps), antes de usar o `%windir%/WindowsUpdate.log`
+ Para os nós gerenciados do Linux, colete também o seguinte:
  + O conteúdo do diretório `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`