• 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 os patches de segurança são selecionados 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\_64 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. ------