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

# 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.