Criar uma lista de referência de patches personalizada (Linux) - AWS Systems Manager

Criar uma lista de referência de patches personalizada (Linux)

Use o procedimento a seguir para criar uma lista personalizada de referência de patches para os nós gerenciados do Linux no Patch Manager, um recurso do AWS Systems Manager.

Para obter informações sobre como criar uma lista de referência de patches para nós gerenciados do macOS, consulte Criar uma lista de referência de patches personalizada (macOS). Para obter informações sobre como criar uma lista de referência de patches para nós gerenciados do Windows, consulte Criar uma lista de referência de patches personalizada (Windows).

Para criar uma lista de referência de patches personalizada para os nós gerenciados do Linux

  1. Abra o console AWS Systems Manager em https://console.aws.amazon.com/systems-manager/.

  2. No painel de navegação, escolha Patch Manager.

  3. Escolha a guia Listas de referência do patches e, em seguida, escolha Criar lista de referência de patches.

    - ou -

    Se estiver acessando o Patch Manager pela primeira vez na Região da AWS atual, escolha Iniciar com uma visão geral, escolha a guia Listas de referência de patches e depois escolha Criar lista de referência de patches.

  4. Em Nome, insira um nome para a nova lista de referência de patches, como MyRHELPatchBaseline.

  5. (Opcional) Em Description (Descrição), insira uma descrição para essa linha de base de patch.

  6. Em Operating System (Sistema operacional), escolha um sistema operacional, como Red Hat Enterprise Linux.

  7. Se você quiser começar a usar essa lista de referência de patch como o padrão para o sistema operacional assim que a criar, selecione a opção Set this patch baseline as the default patch baseline for operating system name instances (Definir esta lista de referência de patch como a padrão para instâncias do [nome do sistema operacional]).

    nota

    Essa opção está disponível somente se você acessou pela primeira vez Patch Manager antes do lançamento das políticas de patch em 22 de dezembro de 2022.

    Para obter informações sobre como definir uma linha de base de patch existente como padrão, consulte Definir uma linha de base de patches existente como padrão.

  8. Na seção Approval rules for operating-systems (Regras de aprovação para sistemas operacionais), use os campos para criar uma ou mais regras de aprovação automática.

    • Produtos: a versão dos sistemas operacionais à qual a regra de aprovação se aplica, como RedhatEnterpriseLinux7.4. A seleção padrão é All.

    • Classificação: o tipo de patch ao qual a regra de aprovação se aplica, como Security ou Enhancement. A seleção padrão é All.

      dica

      É possível configurar uma lista de referência de patches para controlar se atualizações secundárias de versão do Linux são instaladas, como o RHEL 7.8. As atualizações de versões secundárias podem ser instaladas automaticamente pelo Patch Manager, desde que a atualização esteja disponível no repositório apropriado.

      Para sistemas operacionais Linux, atualizações de versões secundárias não são classificadas de forma consistente. Elas podem ser classificadas como correções de bugs ou atualizações de segurança, ou não classificadas, mesmo dentro da mesma versão do kernel. Veja a seguir algumas opções para controlar se uma lista de referência de patches fará a instalação.

      • Opção 1: a regra de aprovação mais ampla para garantir que atualizações de versões secundárias sejam instaladas quando disponíveis é especificar Classificação como All (*) e escolher a opção Incluir atualizações não relacionadas a segurança.

      • Opção 2: para garantir que os patches para uma versão do sistema operacional estejam instalados, é possível usar um curinga (*) para especificar o formato de kernel na seção Exceções de patch da lista de referência. Por exemplo, o formato do kernel para o RHEL 7.* é kernel-3.10.0-*.el7.x86_64.

        Insira kernel-3.10.0-*.el7.x86_64 na lista Patches aprovados na lista de referência de patches para garantir que todos os patches, inclusive atualizações de versões secundárias, sejam aplicados aos nós gerenciados do RHEL 7.*. (Se você souber o nome exato do pacote de um patch de versão secundária, poderá inseri-lo.)

      • Opção 3: é possível obter o máximo de controle sobre quais patches são aplicados aos nós gerenciados, inclusive atualizações de versões secundárias, usando o parâmetro InstallOverrideList no documento AWS-RunPatchBaseline. Para ter mais informações, consulte Sobre o documento do SSM do AWS-RunPatchBaseline.

    • Severity (Gravidade): o valor da gravidade dos patches aos quais a regra se aplica, como Critical. A seleção padrão é All.

    • Auto-approval (Aprovação automática): o método para selecionar patches para aprovação automática.

      nota

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

      • Approve patches after a specified number of days (Aprovar patches após um número específico de dias): o número de dias que o Patch Manager deve aguardar para aprovar automaticamente um patch após o lançamento ou última atualização de um patch. Insira qualquer número inteiro de zero (0) a 360. Para a maioria dos casos, recomendamos que não aguarde mais de 100 dias.

      • Approve patches released up to a specific date (Aprovar patches lançados até uma data específica): a data de lançamento do patch para a qual o Patch Manager aplica automaticamente todos os patches lançados ou com a última atualização nessa data ou antes dela. Por exemplo, se você especificar 7 de julho de 2023, nenhum patch lançado ou com última atualização em ou após 8 de julho de 2023 será instalado automaticamente.

    • (Opcional) Relatórios de conformidade: o nível de gravidade que você deseja atribuir aos patches aprovados pela lista de referência, como Critical ou High.

      nota

      Se você especificar um nível de relatório de conformidade e o estado do patch de qualquer patch aprovado for relatado como Missing, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado.

    • Include non-security updates (Incluir atualizações não relacionadas a segurança): marque a caixa de seleção para instalar patches do sistema operacional Linux não relacionados a segurança que estão disponíveis no repositório de origem, além de patches de segurança.

      nota

      No SUSE Linux Enterprise Server, (SLES) não é necessário marcar a caixa de seleção, pois os patches relacionados ou não a segurança são instalados por padrão em nós gerenciados do SLES. Para obter mais informações, consulte o conteúdo sobre o SLES em Como os patches de segurança são selecionados.

    Para obter mais informações sobre como trabalhar com regras de aprovação em uma linha de base de patch personalizada, consulte Sobre linhas de base personalizadas.

  9. Se quiser explicitamente aprovar qualquer patch, além das suas regras de aprovação, faça o seguinte na seção Patch exceptions (Exceções de patch):

    • Em Approved patches (Patches aprovados), insira uma lista separada por vírgulas dos patches que você deseja aprovar.

      nota

      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.

    • (Opcional) Em Approved patches compliance level (Nível de conformidade dos patches aprovados), atribua um nível de conformidade aos patches na lista.

    • Se algum dos patches aprovados que você especificar não for relacionado a segurança, marque a caixa Incluir atualizações não relacionadas a segurança para que esse patch também seja instalado no sistema operacional Linux.

  10. Se quiser explicitamente rejeitar qualquer patch que de outra forma atendem às suas regras de aprovação, faça o seguinte na seção Patch exceptions (Exceções de patch):

    • Em Rejected patches (Patches rejeitados), insira uma lista separada por vírgulas dos patches que você deseja rejeitar.

      nota

      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.

    • Em Rejected patches action (Ação para patches rejeitados), selecione a ação que o Patch Manager deve realizar para patches incluídos na lista Rejected patches (Patches rejeitados).

      • Permitir como dependência: um pacote na lista Rejected patches (Patches rejeitados) é instalado apenas se for uma dependência de outro. Ele é considerado compatível com a linha de base de patch e seu status é relatado como InstalledOther. Essa é a ação padrão se nenhuma opção for especificada.

      • Bloco: os pacotes na lista Patches rejeitados e pacotes que os incluem como dependências não são instalados pelo Patch Manager em nenhuma circunstância. Se um pacote tiver sido instalado antes de ser adicionado à lista Patches rejeitados ou instalado fora do Patch Manager, ele será considerado como fora conformidade com a lista de referência de patches e seu status será indicado como InstalledRejected.

  11. (Opcional) Se quiser especificar repositórios de patches alternativos para versões diferentes de um sistema operacional, como AmazonLinux2016.03 e AmazonLinux2017.09, faça o seguinte para cada produto na seção Patch sources (Origens de patches):

    • Em Name (Nome), insira um nome para ajudar você a identificar a configuração de origem.

    • Em Product (Produto), selecione a versão dos sistemas operacionais para a qual o repositório de origem de patches é destinado, como RedhatEnterpriseLinux7.4.

    • Em Configuration (Configuração), insira o valor da configuração do repositório yum a ser usado, no seguinte formato:

      [main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
      dica

      Para obter informações sobre outras opções disponíveis para a configuração do repositório yum, consulte dnf.conf (5).

      Selecione Add another source (Adicionar outra origem) para especificar um repositório de origem para cada versão do sistema operacional adicional, até um máximo de 20.

      Para obter mais informações sobre repositórios de origem de patches alternativos, consulte Como especificar um repositório de origem de patches alternativo (Linux).

  12. (Opcional) Em Manage tags (Gerenciar tags), aplique um ou mais pares de nome/valor de chave de tag à linha de base de patch.

    Tags são metadados opcionais que você atribui a um recurso. As tags permitem categorizar um recurso de diferentes formas, como por finalidade, proprietário ou ambiente. Por exemplo, você pode querer marcar uma linha de base de patch para identificar o nível de gravidade dos patches especificados, a família de sistemas operacionais aos quais ela se aplica e o tipo de ambiente. Nesse caso, você pode especificar tags semelhantes aos seguintes pares de nome/valor:

    • Key=PatchSeverity,Value=Critical

    • Key=OS,Value=RHEL

    • Key=Environment,Value=Production

  13. Escolha Create patch baseline.