Documento de comando do SSM para a aplicação de patches: AWS-RunPatchBaseline - AWS Systems Manager
AWS-RunPatchBaseline parameters

Documento de comando do SSM para a aplicação de patches: AWS-RunPatchBaseline

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

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

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

nota

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

Windows Server

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

Linux

Em nós gerenciados do Linux, o documento AWS-RunPatchBaseline invoca um módulo do Python, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches usa regras e listas de patches aprovados e bloqueados para conduzir o gerenciador de pacotes apropriado para cada tipo de nó:

  • Nós gerenciados do Amazon Linux 1, Amazon Linux 2, CentOS, Oracle Linux e RHEL 7 usam YUM. Para operações YUM, o Patch Manager requer o Python 2.6 ou uma versão posterior compatível (2.6-3.10).

  • Os nós gerenciados do RHEL 8 usam o DNF. Para operações DNF, o Patch Manager requer uma versão compatível do Python 2 ou Python 3 (2.6-3.10). (Nenhuma versão é instalada por padrão no RHEL 8. É necessário instalar um deles manualmente.)

  • As instâncias do Debian Server, do Raspberry Pi OS e do Ubuntu Server usam o APT. Para operações APT, o Patch Manager requer uma versão compatível do Python 3 (3.0-3.10).

  • Os nós gerenciados do SUSE Linux Enterprise Server usam o Zypper. Para operações Zypper, o Patch Manager requer o Python 2.6 ou uma versão posterior compatível (2.6-3.10).

macOS

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

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

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

nota

Se o parâmetro RebootOption estiver definido como NoReboot no documento AWS-RunPatchBaseline, o nó gerenciado não será reinicializado após a execução do Patch Manager. Para ter mais informações, consulte Nome do parâmetro: RebootOption.

Para obter informações sobre como visualizar dados de conformidade de patches, consulte Sobre a conformidade de patches.

AWS-RunPatchBaseline parameters

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

Nome do parâmetro: Operation

Uso: obrigatório.

Opções: Scan | Install.

Verificar

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

Instalar

Quando você escolhe a opção Install, o AWS-RunPatchBaseline tenta instalar as atualizações aprovadas e aplicáveis que estiverem ausentes em seu nó gerenciado. As informações de conformidade dos patches geradas como parte de uma operação Install não listam atualizações ausentes, mas poderão indicar atualizações em estado malsucedido se, por qualquer motivo, a instalação da atualização não tiver tido êxito. Sempre que uma atualização é instalada em um nó gerenciado, o nó é reinicializado para garantir que a atualização esteja instalada e ativa. (Exceção: Se o parâmetro RebootOption estiver definido como NoReboot no documento AWS-RunPatchBaseline, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte Nome do parâmetro: RebootOption).

nota

Se um patch especificado pelas regras da lista de referência for instalado antes que o Patch Manager atualize o nó gerenciado, o sistema poderá não ser reinicializado conforme esperado. Isso pode acontecer quando um patch é instalado manualmente por um usuário ou instalado automaticamente por outro programa, como o pacote unattended-upgrades no Ubuntu Server.

Nome do parâmetro: AssociationId

Uso: opcional.

O AssociationId é o ID de uma associação existente no State Manager, um recurso do AWS Systems Manager. Ela é usada pelo Patch Manager para adicionar dados de conformidade à associação especificada. Essa associação está relacionada a uma operação de aplicação de patches configurada em uma política de patch no Quick Setup.

nota

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

Se ainda não tiver uma associação que você deseja usar, crie uma associação executando o comando create-association.

Nome do parâmetro: Snapshot ID

Uso: opcional.

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

Práticas recomendadas do AWS-RunPatchBaseline
Modo Prática recomendada Detalhes
RunningAWS-RunPatchBaselineDentro de uma janela de manutenção Não forneça um ID de snapshot. O Patch Manager fornecerá para você.

Se você usar uma janela de manutenção para executar o AWS-RunPatchBaseline, não forneça seu próprio ID de snapshot gerado. Nesse cenário, o Systems Manager fornece um valor GUID com base no ID de execução da janela de manutenção. Isso garante que seja usado um ID correto para todas as invocações do AWS-RunPatchBaseline nessa janela de manutenção.

Se você especificar um valor nesse cenário, observe que talvez o snapshot da lista de referência de patches não permaneça vigente por mais de três dias. Depois disso, um novo snapshot será gerado, mesmo que você especificar o mesmo ID depois que o snapshot expirar.

RunningAWS-RunPatchBaselineFora de uma janela de manutenção Gere e especifique um valor de GUID personalizado para o ID do snapshot..¹

Quando você não estiver usando uma janela de manutenção para executar o AWS-RunPatchBaseline, recomendamos gerar e especificar um ID de snapshot exclusivo para cada lista de referência de patches, principalmente se estiver executando o documento AWS-RunPatchBaseline em vários nós gerenciados na mesma operação. Se você não especificar um ID nesse cenário, o Systems Manager gerará um ID de snapshot diferente para cada nó gerenciado para o qual o comando for enviado. Em consequência disso, vários conjuntos de patches podem ser especificados entre os nós gerenciados.

Por exemplo, digamos que esteja executando o documento AWS-RunPatchBaseline diretamente do Run Command, um recurso do AWS Systems Manager, e visando um grupo de 50 nós gerenciados. Ao especificar os resultados de um ID de snapshot personalizado, na geração de um único snapshot da lista de referência, que é usado para avaliar e corrigir todos os nós, garantindo que eles adquiram um estado consistente.

¹ Você pode usar qualquer ferramenta capaz de gerar um GUID para gerar um valor para o parâmetro ID do snapshot. Por exemplo, no PowerShell, você pode usar o cmdlet New-Guid para gerar um GUID no formato 12345699-9405-4f69-bc5e-9315aEXAMPLE.

Nome do parâmetro: InstallOverrideList

Uso: opcional.

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

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

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

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

Formatos URL válidos

nota

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

  • Formato URL em https:

    https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml

  • URL estilo de caminho do Amazon S3:

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

Formatos de conteúdo YAML válidos

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

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

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

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

Linux
id

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

Cargo

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

YUM/SUSE Linux Enterprise Server (SLES):

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

APT

{name}.{architecture}:{version}

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

Por exemplo:

  • A versão do pacote apt 1.2.25 está atualmente instalada em seu nó gerenciado, mas a versão 1.2.27 agora está disponível.

  • Você adiciona a versão apt.amd64 1.2.27 à lista de patches. Depende da versão do apt utils.amd64 1.2.27, mas a versão apt utils.amd64 1.2.25 é especificada na lista.

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

Windows Server
id

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

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

macOS
id

O campo id é obrigatório. O valor doidpode ser fornecido usando um campo{package-name}.{package-version}ou um formato {package_name}.

Exemplo de listas de patch

  • Amazon Linux

    patches:
    -
        id: 'kernel.x86_64'
    -
        id: 'bind*.x86_64'
        title: '32:9.8.2-0.62.rc1.57.amzn1'
    -
        id: 'glibc*'
    -
        id: 'dhclient*'
        title: '*12:4.1.1-53.P1.28.amzn1'
    -
        id: 'dhcp*'
        title: '*10:3.1.1-50.P1.26.amzn1'

  • CentOS

    patches:
    -
        id: 'kernel.x86_64'
    -
        id: 'bind*.x86_64'
        title: '32:9.8.2-0.62.rc1.57.amzn1'
    -
        id: 'glibc*'
    -
        id: 'dhclient*'
        title: '*12:4.1.1-53.P1.28.amzn1'
    -
        id: 'dhcp*'
        title: '*10:3.1.1-50.P1.26.amzn1'

  • Debian Server

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

  • macOS

    patches:
    -
        id: 'XProtectPlistConfigData'
    -
        id: 'MRTConfigData.1.61'
    -
        id: 'Command Line Tools for Xcode.11.5'
    -
        id: 'Gatekeeper Configuration Data'

  • Oracle Linux

    patches:
    -
        id: 'audit-libs.x86_64'
        title: '*2.8.5-4.el7'
    -
        id: 'curl.x86_64'
        title: '*.el7'
    -
        id: 'grub2.x86_64'
        title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
    -
        id: 'grub2.x86_64'
        title: 'grub2.x86_64:1:*-0.81.0.1.el7'

  • Red Hat Enterprise Linux (RHEL)

    patches:
    -
        id: 'NetworkManager.x86_64'
        title: '*1:1.10.2-14.el7_5'
    -
        id: 'NetworkManager-*.x86_64'
        title: '*1:1.10.2-14.el7_5'
    -
        id: 'audit.x86_64'
        title: '*0:2.8.1-3.el7'
    -
        id: 'dhclient.x86_64'
        title: '*.el7_5.1'
    -
        id: 'dhcp*.x86_64'
        title: '*12:5.2.5-68.el7'

  • SUSE Linux Enterprise Server (SLES)

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

  • Ubuntu Server 

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

  • Windows

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

Nome do parâmetro: RebootOption

Uso: opcional.

Opções: RebootIfNeeded | NoReboot

Padrão: RebootIfNeeded

Atenção

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

Importante

Não é recomendável usar o Patch Manager para aplicar patches em instâncias de cluster no Amazon EMR (antes chamado de Amazon Elastic MapReduce). Em particular, não selecione a opção RebootIfNeeded para o parâmetro RebootOption. (Essa opção está disponível nos documentos do SSM Command para aplicação de patches em AWS-RunPatchBaseline, AWS-RunPatchBaselineAssociation e AWS-RunPatchBaselineWithHooks.)

Os comandos subjacentes para aplicação de patches usando o Patch Manager utilizam os comandos yum e dnf. Portanto, as operações resultam em incompatibilidades por causa da forma como os pacotes são instalados. Para obter informações sobre os métodos preferenciais para atualizar o software nos clusters do Amazon EMR, consulte Using the default AMI for Amazon EMR no Guia de gerenciamento do Amazon EMR.

RebootIfNeeded

Quando você escolhe a opção RebootIfNeeded, o nó gerenciado é reinicializado em um dos seguintes casos:

  • O Patch Manager instalou um ou mais patches.

    O Patch Manager não avalia se uma reinicialização é exigida pelo patch. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.

  • O Patch Manager detecta um ou mais patches com um status de INSTALLED_PENDING_REBOOT durante a operação Install.

    O status INSTALLED_PENDING_REBOOT pode significar que a opção NoReboot foi selecionada na última vez em que a operação Install foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado.

A reinicialização de nós gerenciados nesses dois casos garante que os pacotes atualizados sejam liberados da memória e mantenham o comportamento da aplicação de patches e da reinicialização consistente em todos os sistemas operacionais.

NoReboot

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

nota

Se você escolher a opção NoReboot e um patch for instalado, o patch receberá um status de InstalledPendingReboot. O nó gerenciado em si, no entanto, é marcado como Non-Compliant. Depois que ocorre uma reinicialização e uma operação Scan é executada, o status do nó gerenciado é atualizado para Compliant.

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

Importante

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

Esse arquivo de rastreamento é armazenado nos seguintes locais em seus nós gerenciados:

  • Sistemas operacionais Linux:

    • /var/log/amazon/ssm/patch-configuration/patch-states-configuration.json

    • /var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json

  • Sistema operacional Windows Server:

    • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json

    • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json

Nome do parâmetro: BaselineOverride

Uso: opcional.

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

Para obter mais informações sobre como usar o parâmetro BaselineOverride, consulte Usar o parâmetro BaselineOverride.