• 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). # Linhas de base de patch Os tópicos nesta seção fornecem informações sobre como as listas de referência de patches funcionam no Patch Manager, uma ferramenta do AWS Systems Manager, quando você executa uma operação `Scan` ou `Install` em seus nós gerenciados. **Topics** + [ # Listas de referência de patches predefinidas e personalizadas ](patch-manager-predefined-and-custom-patch-baselines.md) + [ # Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados ](patch-manager-approved-rejected-package-name-formats.md) + [ # Grupos de patches ](patch-manager-patch-groups.md) + [ # Aplicações de patches lançadAs pela Microsoft no Windows Server ](patch-manager-patching-windows-applications.md) # Listas de referência de patches predefinidas e personalizadas O Patch Manager, uma ferramenta do AWS Systems Manager, fornece uma lista de referência de patches predefinida para cada sistema operacional compatível com o Patch Manager. É possível usar essas listas de referência como estão configuradas no momento (não é possível personalizá-las) ou criar suas próprias listas de referência de patches personalizadas. As listas de referência de patches personalizadas permitem um controle maior sobre quais patches são aprovados ou rejeitados para o ambiente. Além disso, as listas de referência predefinidas atribuem um nível de conformidade de `Unspecified` a todos os patches instalados usando essas listas de referência. Para que os valores de conformidade sejam atribuídos, é possível criar uma cópia de uma lista de referência predefinida e especificar os valores de conformidade que deseja atribuir aos patches. Para obter mais informações, consulte [Linhas de base personalizadas](#patch-manager-baselines-custom) e [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md). **nota** As informações neste tópico se aplicam independentemente do método ou tipo de configuração que você esteja usando para suas operações de aplicação de patch: Uma política de patch configurada no Quick Setup Uma opção do Host Management configurada no Quick Setup Uma janela de manutenção para executar um patch `Scan` ou tarefa `Install` Uma operação **Patch now** (Aplicar patch agora) sob demanda **Topics** + [ ## Linhas de base predefinidas ](#patch-manager-baselines-pre-defined) + [ ## Linhas de base personalizadas ](#patch-manager-baselines-custom) ## Linhas de base predefinidas A tabela a seguir descreve as linhas de base de patch predefinidas fornecidas com o Patch Manager. Para obter informações sobre quais versões de cada sistema operacional são compatíveis com o Patch Manager, consulte [Pré-requisitos do Patch Manager](patch-manager-prerequisites.md). **** | Nome | Sistema operacional com suporte | Detalhes | | --- | --- | --- | | `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Também aprova todos os patches classificados como “Bugfix” (Correção de erros). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹ | | AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Também aprova todos os patches com uma classificação de “Bugfix” (Correção de erros). Os patches são aprovados automaticamente sete dias após o lançamento.¹ | | AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Os patches são aprovados automaticamente sete dias após a liberação. Também aprova todos os patches com uma classificação de "Bugfix" (Correção de erros) sete dias após o lançamento. | | AWS-CentOSDefaultPatchBaseline | CentOS Stream | Aprova todas as atualizações sete dias após elas serem disponibilizadas, incluindo atualizações que não sejam de segurança. | | AWS-DebianDefaultPatchBaseline | Debian Server | Aprova imediatamente todos os patches relacionados à segurança do sistema operacional com prioridade "Required", (Obrigatório), "Standard" (Padrão) ou "Extra". Não há espera antes da aprovação, pois as datas de lançamento confiáveis não estão disponíveis nos repositórios. | | AWS-MacOSDefaultPatchBaseline | macOS | Aprova todos os patches do sistema operacional classificados como “Security” (Segurança). Também aprova todos os pacotes com uma atualização atual. | | AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Important" (Importante) ou "Moderate" (Moderado). Também aprova todos os patches classificados como “Bugfix” (Correção de erros) sete dias após o lançamento. Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹ | | `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Também aprova todos os patches classificados como “Bugfix” (Correção de erros). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹ | | `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com nível de gravidade "Critical" (Crítico) ou "Important" (Importante). Também aprova todos os patches classificados como “Bugfix” (Correção de erros). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹ | | AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Aprova todos os patches do sistema operacional classificados como "Security" (Segurança) e com gravidade "Critical" (Crítico) ou "Important" (Importante). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.¹ | | `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | Aprova imediatamente todos os patches relacionados à segurança do sistema operacional com prioridade "Required", (Obrigatório), "Standard" (Padrão) ou "Extra". Não há espera antes da aprovação, pois as datas de lançamento confiáveis não estão disponíveis nos repositórios. | | AWS-DefaultPatchBaseline | Windows Server | Aprova todos os patches do sistema operacional Windows Server classificados como "CriticalUpdates" (Atualizações críticas) ou "SecurityUpdates" (Atualizações de segurança) e com um nível de gravidade MSRC "Critical" (Crítico) ou "Important" (Importante). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.² | | AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | Aprova todos os patches do sistema operacional Windows Server classificados como "CriticalUpdates" (Atualizações críticas) ou "SecurityUpdates" (Atualizações de segurança) e com um nível de gravidade MSRC "Critical" (Crítico) ou "Important" (Importante). Os patches são aprovados automaticamente sete dias após serem lançados ou atualizados.² | | AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Para o sistema operacional Windows Server, aprova todos os patches classificados como "CriticalUpdates" (Atualizações críticas) ou "SecurityUpdates" (Atualizações de segurança) e com um nível de gravidade MSRC "Critical" (Crítico) ou "Important" (Importante). Para aplicações lançadas pela Microsoft, aprova todos os patches. Os patches para sistemas operacionais e aplicações são aprovados automaticamente sete dias após serem lançados ou atualizados.² | ¹ Para Amazon Linux 2, a espera de 7 dias antes da aprovação automática dos patches é calculada a partir de um valor `Updated Date` em `updateinfo.xml` e não um valor `Release Date`. Vários fatores podem afetar o valor `Updated Date`. Outros sistemas operacionais processam datas de lançamento e atualização de modo diferente. Para obter informações que podem ajudar você a evitar resultados inesperados com atrasos na aprovação automática, consulte [Como as datas de lançamento e atualização de pacotes são calculadas](patch-manager-release-dates.md). ² Para o Windows Server, as listas de referência padrão incluem um atraso de sete dias para a aprovação automática. Para instalar um patch em até sete dias após o lançamento, você deve criar uma lista de referência personalizada. ## Linhas de base personalizadas Use as informações a seguir para ajudar você a criar listas de referência de patches personalizadas para atender às suas metas de patches. **Topics** + [ ### Usar aprovações automáticas em listas de referência personalizadas ](#baselines-auto-approvals) + [ ### Informações adicionais para criar listas de referência de patches ](#baseline-additional-info) ### Usar aprovações automáticas em listas de referência personalizadas Se você criar sua própria linha de base para patch, poderá escolher quais patches serão automaticamente aprovados, usando as seguintes categorias. + **Sistema operacional**: versões compatíveis de Windows Server, Amazon Linux, Ubuntu Server e assim por diante. + **Nome do produto **(para sistemas operacionais): por exemplo, RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2 e assim por diante. + **Nome do produto **(somente para aplicações lançadas pela Microsoft no Windows Server): por exemplo, Word 2016, BizTalk Server e assim por diante. + **Classificação**: por exemplo, atualizações críticas, atualizações de segurança e assim por diante. + **Gravidade**: por exemplo, crítica, importante e assim por diante. Para cada regra de aprovação criada, é possível optar por especificar um atraso de aprovação automática ou especificar uma data-limite de aprovação de patch. **nota** Como não é possível determinar de forma confiável as datas de lançamento dos pacotes de atualização do Ubuntu Server, as opções de aprovação automática não são compatíveis com esse sistema operacional. Um atraso na aprovação automática é o número de dias para aguardar após o lançamento ou a última atualização do patch, antes que a aplicação do patch seja aprovada automaticamente. Por exemplo, se você criar uma regra usando a classificação `CriticalUpdates` e configurá-la para atraso de aprovação automática de 7 dias, um novo patch crítico lançado em 7 de julho será automaticamente aprovado em 14 de julho. Se um repositório do Linux não fornecer informações de data de lançamento para pacotes, o Patch Manager usará o horário de compilação do pacote como a data para especificações de data de aprovação automática para Amazon Linux 2, Amazon Linux 2023 e Red Hat Enterprise Linux (RHEL). Se o horário de compilação do pacote não puder ser determinado, o Patch Manager usa uma data padrão de 1º de janeiro de 1970. Isso resulta no Patch Manager ignorar quaisquer especificações de data de aprovação automática nas lista de referência de patches que estão configuradas para aprovar patches para qualquer data após 1º de janeiro de 1970. Quando você especifica uma data-limite de aprovação automática, o Patch Manager aplica automaticamente todos os patches lançados ou com a última atualização nessa data ou antes dela. Por exemplo, se você especificar 7 de julho de 2023 como a data-limite, nenhum patch lançado ou com a última atualização em ou após 8 de julho de 2023 será instalado automaticamente. Ao criar uma linha de lista de referência personalizada, é possível especificar um nível de gravidade de conformidade para patches aprovados por essa lista de referência de patches, como `Critical` ou `High`. Se o estado do patch de qualquer patch aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado. ### Informações adicionais para criar listas de referência de patches Lembre-se do seguinte ao criar uma linha de base de patch: + Patch ManagerO fornece uma linha de base de patch predefinida para cada sistema operacional compatível. Essas linhas de base de patch predefinidas são usadas como as linhas de base de patch padrão para cada tipo de sistema operacional, a menos que você crie sua própria linha de base de patch e a designe como a padrão para o tipo de sistema operacional correspondente. **nota** Para o Windows Server, três linhas de base de patch predefinidas são fornecidas. As listas de referência de patches `AWS-DefaultPatchBaseline` e `AWS-WindowsPredefinedPatchBaseline-OS` oferecem suporte apenas às atualizações do sistema operacional Windows em si. O `AWS-DefaultPatchBaseline` é usado como lista de referência de patches para nós gerenciados do Windows Server, a menos que você especifique outra lista de referência de patches. As definições de configuração nestas duas linhas de base de patch são as mesmas. O mais novo dos dois,`AWS-WindowsPredefinedPatchBaseline-OS`, foi criado para distingui-lo da terceira linha de base de patch predefinida paraWindows Server. Essa lista de referência do patch, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, pode ser usada para aplicar patches tanto ao sistema operacional Windows Server quanto a aplicações compatíveis lançadas pela Microsoft. + Por padrão, o Windows Server 2019 e o Windows Server 2022 removem atualizações que são substituídas por atualizações posteriores. Como resultado, se você usar o parâmetro `ApproveUntilDate` em uma lista de referência de patches do Windows Server, mas a data selecionada no parâmetro `ApproveUntilDate` for anterior à data do patch mais recente, o novo patch não será instalado quando a operação de patch for executada. Para obter mais informações sobre como criar regras de aplicação de patches no Windows Server, consulte a guia Windows Server em [Como os patches de segurança são selecionados](patch-manager-selecting-patches.md). Isso significa que o nó gerenciado é compatível em termos de operações do Systems Manager, mesmo que um patch crítico do mês anterior possa não ter sido instalado. Esse mesmo cenário pode ocorrer ao usar o parâmetro `ApproveAfterDays`. Devido ao comportamento do patch substituído pela Microsoft, é possível definir um número (geralmente maior que 30 dias) para que os patches do Windows Server nunca sejam instalados se o patch mais recente disponível da Microsoft for lançado antes de o número de dias em `ApproveAfterDays` tiver passado. + Apenas para Windows Server, um patch de atualização de segurança disponível que não seja aprovado pela lista de referência de patches pode ter um valor de conformidade de `Compliant` ou `Non-Compliant`, conforme definido em uma lista de referência de patches personalizada. Ao criar ou atualizar uma lista de referência de patches, você escolhe o status que deseja atribuir aos patches de segurança que estão disponíveis, mas não aprovados, porque não atendem aos critérios de instalação especificados na lista de referência de patches. Por exemplo, os patches de segurança que você talvez queira instalar poderão ser ignorados se você tiver especificado um longo período de espera após o lançamento de um patch antes da instalação. Se uma atualização do patch for lançada durante o período de espera especificado, o período de espera para instalação do patch recomeçará. Se o período de espera for muito longo, várias versões do patch poderão ser lançadas, mas nunca instaladas. Usando o console para criar ou atualizar uma lista de referência de patches, você especifica essa opção no campo **Status de conformidade das atualizações de segurança disponíveis**. Usando a AWS CLI para executar o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) ou [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html), você especifica essa opção no parâmetro `available-security-updates-compliance-status`. + Para servidores on-premises e máquinas virtuais (VMs), o Patch Manager tenta usar a lista de referência de patches padrão personalizada. Se não existir uma linha de base de patch padrão personalizada, o sistema usará a linha de base de patch predefinida para o sistema operacional correspondente. + Se um patch estiver listado como aprovado e rejeitado na mesma linha de base de patch, o patch será rejeitado. + Um nó gerenciado pode ter apenas uma lista de referência de patches definida para ele. + Os formatos de nomes de pacotes que você pode adicionar a listas de patches aprovados e rejeitados para uma linha de base de patch dependem do tipo de sistema operacional no qual você está aplicando patches. Para obter mais informações sobre os formatos aceitos de listas de patches aprovados e rejeitados, consulte [Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados](patch-manager-approved-rejected-package-name-formats.md). + Se você estiver usando uma [configuração de política de patch](patch-manager-policies.md) em Quick Setup, as atualizações feitas nas listas de referência de patches personalizadas serão sincronizadas com Quick Setup uma vez por hora. Se uma lista de referência de patches personalizada que foi referenciada em uma política de patch for excluída, um banner será exibido na página **Configuration details** (Detalhes da configuração) do Quick Setup da sua política de patch. O banner informa que a política de patch faz referência a uma lista de referência de patches que não existe mais e que as operações de aplicação de patches subsequentes falharão. Nesse caso, retorne à página **Configurations** (Configurações) do Quick Setup, selecione a configuração Patch Manager e escolha **Actions** (Ações), **Edit configuration** (Editar configuração). O nome da lista de referência de patches excluída será destacado, e você deverá selecionar uma nova lista de referência de patches para o sistema operacional afetado. + Quando você cria uma regra de aprovação com vários valores `Classification` e `Severity`, os patches são aprovados com base nos atributos disponíveis. Pacotes com atributos `Classification` e `Severity` corresponderão aos valores de linha de base selecionados para ambos os campos. Pacotes com somente atributos `Classification` são comparados somente com os valores de linha de base `Classification` selecionados. Os requisitos de severidade na mesma regra são ignorados para pacotes que não têm atributos `Severity`. Para obter mais informações sobre a linha de base de patch, consulte [Trabalhando com linhas de base de patch personalizadas](patch-manager-manage-patch-baselines.md) e [Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). # Sobre formatos de nomes de pacotes para listas de patches aprovados e rejeitados Os formatos de nomes de pacotes que você pode adicionar a listas de patches aprovados e rejeitados dependem do tipo de sistema operacional no qual você está aplicando patches. ## Formatos de nomes de pacotes para sistemas operacionais Linux Os formatos que você pode especificar para patches aprovados e rejeitados em sua linha de base de patches variam de acordo com o tipo do Linux. Mais especificamente, os formatos compatíveis dependem do gerenciador de pacotes usado pelo tipo de sistema operacional Linux. **Topics** + [ ### Amazon Linux 2, Amazon Linux 2023, Oracle Linux e Red Hat Enterprise Linux (RHEL) ](#patch-manager-approved-rejected-package-name-formats-standard) + [ ### Debian Server e da Ubuntu Server ](#patch-manager-approved-rejected-package-name-formats-ubuntu) + [ ### SUSE Linux Enterprise Server (SLES) ](#patch-manager-approved-rejected-package-name-formats-sles) ### Amazon Linux 2, Amazon Linux 2023, Oracle Linux e Red Hat Enterprise Linux (RHEL) **Gerenciador de pacotes**: YUM, exceto no Amazon Linux 2023 e RHEL 8, que usam o DNF como gerenciador de pacotes. **Patches aprovados**: para patches aprovados, você pode especificar qualquer um dos seguintes: + IDs Bugzilla, no formato `1234567` (o sistema processa somente números de sequências como IDs Bugzilla). + IDs CVE, no formato `CVE-2018-1234567` + IDs de consultoria em formatos como `RHSA-2017:0864` e `ALAS-2018-123` + Nomes de pacotes criados usando um ou mais dos componentes disponíveis para nomeação de pacotes. Para ilustrar, para o pacote chamado `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, os componentes são os seguintes: + `name`: `dbus` + `architecture`: `x86_64` + `epoch`: `1` + `version`: `1.12.28` + `release`: `1.amzn2023.0.1` Nomes de pacotes com as seguintes construções são aceitos: + `name` + `name.arch` + `name-version` + `name-version-release` + `name-version-release.arch` + `version` + `version-release` + `epoch:version-release` + `name-epoch:version-release` + `name-epoch:version-release.arch` + `epoch:name-version-release.arch` + `name.arch:epoch:version-release` Alguns exemplos: + `dbus.x86_64` + `dbus-1.12.28` + `dbus-1.12.28-1.amzn2023.0.1` + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` + Também oferecemos suporte a componentes de nome de pacote com um único curinga nos formatos acima, como os seguintes: + `dbus*` + `dbus-1.12.2*` + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64` **Patches rejeitados**: para patches rejeitados, você pode especificar qualquer um dos seguintes: + Nomes de pacotes criados usando um ou mais dos componentes disponíveis para nomeação de pacotes. Para ilustrar, para o pacote chamado `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, os componentes são os seguintes: + `name`: `dbus` + `architecture`; `x86_64` + `epoch`: `1` + `version`: `1.12.28` + `release`: `1.amzn2023.0.1` Nomes de pacotes com as seguintes construções são aceitos: + `name` + `name.arch` + `name-version` + `name-version-release` + `name-version-release.arch` + `version` + `version-release` + `epoch:version-release` + `name-epoch:version-release` + `name-epoch:version-release.arch` + `epoch:name-version-release.arch` + `name.arch:epoch:version-release` Alguns exemplos: + `dbus.x86_64` + `dbus-1.12.28` + `dbus-1.12.28-1.amzn2023.0.1` + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` + Também oferecemos suporte a componentes de nome de pacote com um único curinga nos formatos acima, como os seguintes: + `dbus*` + `dbus-1.12.2*` + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64` ### Debian Server e da Ubuntu Server **Gerenciador de pacotes**: APT **Patches aprovados** e **patches rejeitados**: para patches aprovados e rejeitados, especifique o seguinte: + Nomes de pacotes no formato `ExamplePkg33` **nota** Para listas do Debian Server e Ubuntu Server, não inclua elementos como arquitetura ou versões. Por exemplo, você especifica o nome do pacote `ExamplePkg33` para incluir todos os seguintes em uma lista de patches: `ExamplePkg33.x86.1` `ExamplePkg33.x86.2` `ExamplePkg33.x64.1` `ExamplePkg33.3.2.5-364.noarch` ### SUSE Linux Enterprise Server (SLES) **Gerenciador de pacotes**: Zypper **Patches aprovados** e **patches rejeitados**: para listas de patches aprovados e rejeitados, você pode especificar o seguinte: + Nomes de pacotes completos em formatos como: + `SUSE-SLE-Example-Package-15-2023-123` + `example-pkg-2023.15.4-46.17.1.x86_64.rpm` + Nomes de pacotes com um único caractere curinga, como: + `SUSE-SLE-Example-Package-15-2023-*` + `example-pkg-2023.15.4-46.17.1.*.rpm` ## Formatos de nomes de pacotes macOS **Gerenciadores de pacote compatíveis**: atualização de software, instalador, Brew, Brew Cask **Patches aprovados** e **patches rejeitados**: para listas de patches aprovados e rejeitados, especifique os nomes completos do pacote, em formatos como: + `XProtectPlistConfigData` + `MRTConfigData` Curingas não são compatíveis com listas de patches aprovados e rejeitados para macOS. ## Formatos de nomes de pacotes para sistemas operacionais Windows Para sistemas operacionais Windows, especifique os patches usando IDs da Base de Dados de Conhecimento Microsoft e IDs do boletim de segurança da Microsoft; por exemplo: ``` KB2032276,KB2124261,MS10-048 ``` # Grupos de patches **nota** Os grupos de patches não são usados em operações de aplicação de patches em *políticas de patch*. Para obter informações sobre como trabalhar com políticas de patch, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md). Não há suporte no console à funcionalidade de grupos de patches para pares de conta-região que ainda não usavam grupos de patches antes do lançamento do suporte à política de patches em 22 de dezembro de 2022. A funcionalidade de grupo de patches ainda está disponível em pares de conta-região que começaram a usar grupos de patches antes dessa data. Você pode usar um *grupo de patches* para associar os nós gerenciados a uma lista de referência de patches específica no Patch Manager, uma ferramenta do AWS Systems Manager. Grupos de patches ajudam a garantir que você esteja implantando os patches apropriados, com base nas regras de lista de referência de patches associadas, para corrigir o conjunto de nós. Grupos de patches também podem ajudar você a evitar a implantação de patches antes que eles tenham sido adequadamente testados. Por exemplo, você pode criar grupos de patches para diferentes ambientes (como Desenvolvimento, Teste e Produção) e registrar cada grupo de patches em uma linha de base de patch apropriada. Ao executar o `AWS-RunPatchBaseline` ou outros documentos do comando do SSM para aplicar patches, você pode direcionar os nós gerenciados usando o ID ou as tags do nó. Em seguida, o SSM Agent e o Patch Manager avaliam qual lista de referência de patches deve ser usada, com base no valor do grupo de patches que você adicionou ao nó gerenciado. ## Usando tags para definir grupos de patches É possível criar um grupo de patches ao usar tags aplicadas as instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e nós que não são do EC2 em seu ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). Observe os seguintes detalhes sobre o uso de tags para grupos de patches: + Um grupo de patches deve ser definido usando a chave de tag `Patch Group` ou `PatchGroup` aplicada aos seus nós gerenciados. Ao registrar um grupo de patches para uma lista de referência de patches, quaisquer *valores* idênticos especificados para essas duas chaves são interpretados como parte do mesmo grupo. Por exemplo, digamos que você tenha marcado cinco nós com o primeiro dos seguintes pares de valores-chave e cinco com o segundo: + `key=PatchGroup,value=DEV` + `key=Patch Group,value=DEV` O comando do Patch Manager para criar uma linha de base combina esses 10 nós gerenciados em um único grupo com base no valor `DEV`. A AWS CLI equivalente para o comando criar uma lista de referência de patches para grupos de patches é o seguinte: ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id pb-0c10e65780EXAMPLE \ --patch-group DEV ``` A combinação de valores de chaves diferentes em um único destino é exclusiva desse comando do Patch Manager para criar um novo grupo de patches e não é suportada por outras ações da API. Por exemplo, se você executar ações [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) usando chaves do `Patch Group` e do `PatchGroup` com os mesmos valores, terá como alvo dois conjuntos de nós completamente diferentes: ``` aws ssm send-command \ --document-name AWS-RunPatchBaseline \ --targets "Key=tag:PatchGroup,Values=DEV" ``` ``` aws ssm send-command \ --document-name AWS-RunPatchBaseline \ --targets "Key=tag:Patch Group,Values=DEV" ``` + Há limites na segmentação baseada em tags. Cada matriz de alvos para `SendCommand` pode conter no máximo cinco pares de chave-valor. + Recomendamos que você escolha apenas uma dessas convenções de chave de tag, seja `PatchGroup` (sem espaço) ou `Patch Group` (com espaço). No entanto, se você tiver [tags permitidas nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), em uma instância, você deve usar o `PatchGroup`. + Observe que a chave faz distinção entre maiúsculas e minúsculas. Você pode especificar qualquer *valor* para ajudar você a identificar e direcionar os recursos desse grupo, por exemplo, “servidores web” ou “US-EAST-PROD”, mas a chave deve ser `Patch Group` ou `PatchGroup`. Depois de criar um grupo de patches e marcar os nós gerenciados, você poderá registrar o grupo de patches com uma lista de referência de patches. Registrar o grupo de patches em uma lista de referência de patches garante que os nós nesse grupo usem as regras definidas na lista de referência de patches associada. Para obter mais informações sobre como criar um grupo de patches e associá-lo a uma lista de referência dos patches, consulte [Como criar e gerenciar grupos de patches](patch-manager-tag-a-patch-group.md) e [Adicionar um grupo de patches a uma lista de referência de patches](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline). Para visualizar um exemplo de como criar uma lista de referência de patches e grupos de patches usando a AWS Command Line Interface (AWS CLI), consulte [Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). Para obter mais informações, consulte [Marcar recursos do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) no *Guia do usuário do Amazon EC2 para instâncias do Linux*. ## Como funciona Quando o sistema executar a tarefa para aplicar uma lista de referência de patches a um nó gerenciado, o SSM Agent verificará se um grupo de patches está definido para esse nó. Se o nó estiver atribuído a um grupo de patches, o Patch Manager verificará se a lista de referência de patches está registrada nesse grupo. Se uma lista de referência de patches for encontrada para esse grupo, o Patch Manager notificará o SSM Agent para usar a lista de referência de patches associada. Se um nó não estiver configurado para um grupo de patches, o Patch Manager notificará automaticamente o SSM Agent para usar a lista de referência de patches padrão atualmente configurada. **Importante** Um nó gerenciado só pode estar em um grupo de patches. Um grupo de patches pode ser registrado em somente uma linha de base de patch para cada tipo de sistema operacional. Não é possível aplicar a tag `Patch Group` (com um espaço) a uma instância do Amazon EC2 se a opção **Allow tags in instance metadata** (Permitir tags em metadados de instância) estiver habilitada na instância. Permitir tags em metadados de instância impede que nomes de chaves de tag contenham espaços. Se você tiver [permissão para tags nos metadados da instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), é necessário usar a chave de tag `PatchGroup` (sem um espaço). **Diagrama 1: exemplo geral do fluxo de processos de operações da aplicação de patches** A ilustração a seguir mostra um exemplo geral dos processos que o Systems Manager realiza ao enviar uma tarefa do Run Command à sua frota de servidores para aplicar patches usando o Patch Manager. Esses processos determinam quais listas de referência de patches usar nas operações de aplicação de patches. (Um processo semelhante é usado quando uma janela de manutenção estiver configurada para enviar um comando para aplicar patches usando o Patch Manager.) O processo completo é explicado abaixo da ilustração. ![\[Fluxo de trabalho do Patch Manager para determinar quais listas de referência de patches usar ao realizar operações de patch.\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/patch-groups-how-it-works.png) Neste exemplo, temos três grupos de instâncias do EC2 para Windows Server, com as seguintes tags aplicadas: **** | Grupo de instâncias do EC2 | Tags | | --- | --- | | Grupo 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` | | Grupo 2 | `key=OS,value=Windows` | | Grupo 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` | Para este exemplo, também temos essas duas listas de referência de patches do Windows Server: **** | ID da linha de base do patch | Padrão | Grupo de patches associado | | --- | --- | --- | | `pb-0123456789abcdef0` | Sim | `Default` | | `pb-9876543210abcdef0` | Não | `DEV` | O processo geral para verificar ou instalar patches usando o Run Command, uma ferramenta do AWS Systems Manager, e o Patch Manager é o seguinte: 1. **Enviar um comando para patch**: use o console do Systems Manager, o SDK, a AWS Command Line Interface (AWS CLI) ou o AWS Tools for Windows PowerShell para enviar uma tarefa de Run Command usando o documento `AWS-RunPatchBaseline`. O diagrama mostra uma tarefa de Run Command para aplicar patch a instâncias gerenciadas especificando a etiqueta `key=OS,value=Windows`. 1. **Determinação da lista de referência de patches**: o SSM Agent verifica as etiquetas de grupo de patches aplicadas à instância do EC2 e consulta o Patch Manager em busca da lista de referência de patches correspondente. + **Valor de grupo de patches correspondente associado à linha de base de patch:** 1. O SSM Agent, que está instalado em instâncias do EC2 no grupo 1, recebe o comando emitido na Etapa 1 para iniciar uma operação de aplicação de patch. O SSM Agent valida se as instâncias do EC2 têm o valor de tag `DEV` aplicado ao grupo de patches e consulta o Patch Manager em busca de uma linha de base de patch associada. 1. O Patch Manager verifica se a linha de base do patch `pb-9876543210abcdef0` tem o grupo de patches `DEV` associado e notifica o SSM Agent. 1. O SSM Agent recupera um snapshot de linha de base de patch do Patch Manager com base nas regras de aprovação e nas exceções configuradas em `pb-9876543210abcdef0` e prossegue para a próxima etapa. + **Nenhuma tag de grupo de patches adicionada à instância:** 1. O SSM Agent, que está instalado em instâncias do EC2 no grupo 2, recebe o comando emitido na Etapa 1 para iniciar uma operação de aplicação de patch. O SSM Agent valida se as instâncias do EC2 não têm uma tag `Patch Group` ou `PatchGroup` aplicada e, como resultado, o SSM Agent consulta o Patch Manager em busca da lista de referência de patches do Windows. 1. O Patch Manager verifica se a lista de referência de patches padrão do Windows Server é `pb-0123456789abcdef0` e notifica o SSM Agent. 1. O SSM Agent recupera um snapshot de linha de base de patch do Patch Manager com base nas regras de aprovação e nas exceções configuradas na linha de base de patch padrão `pb-0123456789abcdef0` e prossegue para a próxima etapa. + **Nenhum valor de grupo de patches correspondente associado a uma linha de base de patch:** 1. O SSM Agent, que está instalado nas instâncias do EC2 no grupo 3, recebe o comando emitido na Etapa 1 para iniciar uma operação de aplicação de patch. O SSM Agent valida se as instâncias do EC2 têm o valor de tag `QA` aplicado ao grupo de patches e consulta o Patch Manager em busca de uma linha de base de patch associada. 1. O Patch Manager não encontra uma linha de base do patch que tenha o grupo de patches `QA` associado. 1. O Patch Manager notifica o SSM Agent para usar a linha de base de patch padrão do Windows, `pb-0123456789abcdef0`. 1. O SSM Agent recupera um snapshot de linha de base de patch do Patch Manager com base nas regras de aprovação e nas exceções configuradas na linha de base de patch padrão `pb-0123456789abcdef0` e prossegue para a próxima etapa. 1. **Verificação ou instalação de patches**: depois de determinar a linha de base de patch apropriada para uso, o SSM Agent começa a sondar ou instalar patches com base no valor de operação especificado na Etapa 1. Os patches sondados ou instalados são determinados pelas regras de aprovação e pelas exceções de patches definidas no snapshot de lista de referência de patches fornecido pelo Patch Manager. **Mais informações** + [Valores de estados de conformidade de patches](patch-manager-compliance-states.md) # Aplicações de patches lançadAs pela Microsoft no Windows Server Use as informações neste tópico para ajudar você a preparar a aplicação de patches no Windows Server usando o Patch Manager, uma ferramenta do AWS Systems Manager. **Aplicação de patches** O suporte à aplicação de patches em instâncias gerenciadas do Windows Server é limitado a aplicações lançadas pela Microsoft. **nota** Em alguns casos, a Microsoft lança patches para aplicações que não especificam data e hora atualizadas. Nesses casos, uma data e hora atualizadas de `01/01/1970` são fornecidas por padrão. **Lista de referência de patches para aplicações de patches lançados pela Microsoft.** Para o Windows Server, três linhas de base de patch predefinidas são fornecidas. As listas de referência de patches `AWS-DefaultPatchBaseline` e `AWS-WindowsPredefinedPatchBaseline-OS` oferecem suporte apenas às atualizações do sistema operacional Windows em si. O `AWS-DefaultPatchBaseline` é usado como lista de referência de patches para nós gerenciados do Windows Server, a menos que você especifique outra lista de referência de patches. As definições de configuração nestas duas linhas de base de patch são as mesmas. O mais novo dos dois,`AWS-WindowsPredefinedPatchBaseline-OS`, foi criado para distingui-lo da terceira linha de base de patch predefinida paraWindows Server. Essa lista de referência do patch, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, pode ser usada para aplicar patches tanto ao sistema operacional Windows Server quanto a aplicações compatíveis lançadas pela Microsoft. Você também pode criar uma lista de referência de patch personalizada para atualizar aplicações da Microsoft em máquinas do Windows Server. **Compatibilidade com a aplicação de patches em aplicativos lançados pela Microsoft em servidores on-premises, dispositivos de borda, VMs e outros nós que não pertençam ao EC2** Para aplicar patches em aplicações lançadas pela Microsoft em máquinas virtuais (VMs) e outros gerenciados que não são do EC2, é necessário ativar o nível de instâncias avançadas. Há uma cobrança para o uso do nível de instâncias avançadas. **No entanto, não há custo adicional para aplicar patches em aplicativos lançados pela Microsoft em instâncias do Amazon Elastic Compute Cloud (Amazon EC2).** Para obter mais informações, consulte [Configurar níveis de instâncias](fleet-manager-configure-instance-tiers.md). **Opção de atualização do Windows para “outros produtos da Microsoft”** Para que o Patch Manager possa aplicar patches em aplicações lançadas pela Microsoft nos nós gerenciados pelo Windows Server, a opção **Give me updates for other Microsoft products when I update Windows** (Fornecer atualizações para outros produtos Microsoft quando atualizo o Windows), para a atualização do Windows, deverá estar ativada em seu nó gerenciado. Para obter informações sobre como permitir essa opção em um único nó gerenciado, consulte [Update Office with Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) (Atualizar o Office com o Microsoft Update) no site de Suporte da Microsoft. Para uma frota de nós gerenciados que executam o Windows Server 2016 e posterior, você pode usar um objeto de política de grupo (GPO) para ativar a configuração. No editor de gerenciamento de políticas de grupo, acesse **Configuração do computador**, **Templates Administrativos**, **Componentes do Windows**, **Atualizações do Windows** e escolha **Instalar atualizações para outros produtos da Microsoft**. Recomendamos também configurar o GPO com parâmetros adicionais que impedem atualizações automáticas não planejadas e reinicializações fora doPatch Manager. Para obter mais informações, consulte [Configurar atualizações automáticas em um ambiente não Active Directory](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499), no site de documentação técnica da Microsoft. Para uma frota de nós gerenciados que executam o Windows Server 2012 ou 2012 R2, você pode ativar a opção usando um script, conforme descrito em [Enabling and Disabling Microsoft Update in Windows 7 via Script](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) (Ativar e desativar o Microsoft Update no Windows 7 via Script) no site do Blog do Microsoft Docs. Por exemplo, você pode fazer o seguinte: 1. Salve o script da postagem do blog em um arquivo. 1. Faça upload do arquivo para um bucket do Amazon Simple Storage Service (Amazon S3) ou outro local acessível. 1. Usar o Run Command, uma ferramenta do AWS Systems Manager, para executar o script em seus nós gerenciados usando o documento do Systems Manager (documento do SSM) `AWS-RunPowerShellScript` com um comando semelhante ao mostrado a seguir. ``` Invoke-WebRequest ` -Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" ` -Outfile "C:\script.vbs" cscript c:\script.vbs ``` **Requisitos mínimos de parâmetros** Para incluir aplicações da Microsoft em sua lista de referência do patch personalizada, especifique pelo menos o produto ao qual deseja aplicar os patches. O comando da AWS Command Line Interface (AWS CLI) a seguir demonstra os requisitos mínimos para aplicar patch a um produto, como o Office 2016. ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "My-Windows-App-Baseline" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ #### [ Windows Server ] ``` aws ssm create-patch-baseline ^ --name "My-Windows-App-Baseline" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ Se você especificar a família de produtos de aplicativos Microsoft, cada produto especificado deverá ser compatível com o membro da família de produtos selecionada. Por exemplo, para aplicar patch ao produto "Active Directory Rights Management Services Client 2.0", você deve especificar sua família de produtos como "Active Directory" e não, por exemplo, "Office" ou "SQL Server". O seguinte comando da AWS CLI demonstra um emparelhamento de correspondência entre família e produto: ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "My-Windows-App-Baseline" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ #### [ Windows Server ] ``` aws ssm create-patch-baseline ^ --name "My-Windows-App-Baseline" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ **nota** Se você receber uma mensagem de erro sobre um emparelhamento de produto e família incompatíveis, consulte[Problema: família de produtos/pares de produtos incompatíveis](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch)para obter ajuda para resolver o problema.