Práticas recomendadas para gerenciamento de patches

Como arquiteto de soluções, as pessoas sempre me perguntam quais são as práticas recomendadas da Red Hat em relação ao gerenciamento de patches. Este artigo vai direto ao ponto e inclui links para leituras e materiais relevantes quando apropriado. Assim, você confere algumas orientações específicas sobre o que exatamente é uma prática recomendada e quais ferramentas usar como parte do gerenciamento de patches.

Após ler este artigo, você terá uma ideia mais clara sobre as ferramentas e as abordagens que podem ser utilizadas na aplicação de patches da sua organização e as práticas recomendadas que definem esse processo.

Chamar algo de “prática recomendada” talvez seja um pouco presunçoso. O que é recomendado para uma organização pode não ser para outra. Por isso, em vez de definir uma abordagem como “a recomendada”, talvez seja melhor falar sobre o processo em termos do que é mais apropriado para um determinado nível de risco. Quando se trata do gerenciamento de patches, estamos falando do gerenciamento dos riscos ou das alterações.

Toda organização precisa de uma abordagem para lidar com os riscos. No entanto, é necessário que cada uma delas também tenha uma abordagem exclusiva para determinar como esse processo é definido, qual é o foco e como avaliar os vários resultados, impactos e limitações dos negócios.

Para mim, “boas práticas” é um termo mais apropriado. Por exemplo, a Automation Community of Practice publicou o documento Boas práticas da automação (em inglês) com base nos insights que ela adquiriu ao auxiliar os clientes.

O que podemos usar na abordagem e no kit de ferramentas de gerenciamento de patches?

Há ferramentas e metodologias para definir a maneira de gerenciar os patches na infraestrutura.

1. Definições de errata

A Red Hat divide as alterações no código ou conteúdo (erratas) em três categorias diferentes. Cada uma delas tem sua própria finalidade e uma taxa de alterações diferente. Dependendo das metas e da tolerância a alterações da sua organização, talvez uma opção tenha mais a ver com um objetivo e taxa de alterações do que outra.

• Red Hat Security Advisory (RHSA): quando alterações urgentes são feitas para proteger os sistemas
• Red Hat Bug Advisory (RHBA): correções de bugs que podem ou não ter afetado sua organização
• Red Hat Enhancement Advisory (RHEA): quando novas funcionalidades são adicionadas

Para ver mais detalhes, conheça a prática de backporting de segurança da Red Hat e descubra o que é backporting e como isso se aplica ao RHEL e a outras soluções Red Hat.

Com base nesse princípio, é possível isolar as erratas por tipo e risco, além de escolher depois quais patches você considera como necessários e opcionais. 

Por exemplo, imagine que você tem uma infraestrutura voltada para a Internet ou uma zona desmilitarizada (DMZ) com um perfil de alta segurança. Você poderá aplicar apenas a errata do Red Hat Security Advisory sempre que uma for lançada nesse ambiente. Assim, você atende às necessidades de uma infraestrutura de alto risco e divide a alteração em lotes pequenos e fáceis de consumir. 

Nestes links, você confere exemplos de como aplicar apenas a errata de segurança em um processo de patch:

• É possível limitar o yum para que ele liste ou instale apenas atualizações de segurança?
• Como aplicar a errata de segurança do Red Hat Satellite?

Outra abordagem é aplicar patches a subconjuntos de pacotes para reduzir ainda mais o risco das alterações. Isso também oferece a você a flexibilidade para fazer uma reversão caso descubra que o patch interage de maneiras inesperadas com o sistema. Como em qualquer abordagem, você precisa estar ciente dos prós e dos contras, além de lidar com eles. Esse processo pode ser muito granular para algumas organizações, mas talvez se encaixe melhor na tolerância a alterações de outras.

2. Dez etapas para criar um ambiente operacional padrão (SOE)

Este artigo oferece orientações completas sobre como usar o Red Hat Satellite para habilitar e gerenciar um ambiente operacional padrão. Ele aborda todos os assuntos em detalhes e serve de referência para você tirar as dúvidas mais comuns sobre as práticas recomendadas. Embora o conteúdo tenha sido escrito alguns anos atrás quando o Red Hat Satellite 6 foi lançado, seus conceitos básicos ainda se aplicam hoje em dia.

O gerenciamento e o preparo de conteúdo são muito importantes no processo de aplicação de patches. Eles definem como o conteúdo do patch é apresentado à infraestrutura e desempenham um papel fundamental no processo de aplicação de patches para gerenciar e reduzir riscos.

Vale a pena se concentrar principalmente nas visualizações de conteúdo e ambientes de ciclo de vida do Satellite. Esses são conceitos essenciais para o preparo do conteúdo e para a promoção dele (ou reversão) na infraestrutura.

Outros tópicos importantes são as organizações, locais e grupos de hosts para classificar a infraestrutura e o inventário. Muitas vezes, as pessoas adotam abordagens muito granulares em relação aos ambientes de ciclo de vida e visualizações de conteúdo. Isso acontece porque elas tentam usar essas estruturas para classificar locais, ambientes de nuvem, infraestruturas semelhantes e diferentes equipes na organização.

3. Aplicação de patches ao kernel em tempo real

Há muitos anos, a aplicação de patches ao kernel em tempo real faz parte de várias versões principais do RHEL. Você pode aplicar em tempo real um patch ao kernel sem reinicialização para solucionar uma vulnerabilidade com muita rapidez. Isso oferece aos administradores a capacidade de eliminar os riscos imediatamente e a oportunidade de agendar uma janela de manutenção mais apropriada quando uma reinicialização é viável. 

Também é possível orquestrar esse processo com o Red Hat Satellite.

4. Identificação de pacotes que exigem reinicialização do sistema após uma atualização

Dependendo da atualização e do conteúdo da errata, talvez não haja motivo para fazer uma reinicialização após um patch. Às vezes, basta reiniciar um serviço após a atualização para usar um binário atualizado. 

A partir do RHEL 7, o yum-utils inclui um plugin chamado needs-restarting. Esse utilitário informa se uma reinicialização é necessária após a aplicação de patches. Assim, você entende se uma alteração é exigida em um sistema, além de reduzir a necessidade de fazer reinicializações ao aplicar patches.

O Satellite também tem um recurso chamado de Tracer. Ele oferece a mesma funcionalidade da perspectiva do Satellite, ajudando os administradores a identificarem as aplicações que precisam ser reiniciadas após a aplicação de patch em um sistema.

5. Abra um caso proativo do Red Hat Support

Ter conhecimento avançado sobre uma determinada atividade de manutenção e aproveitar a oportunidade de coletar informações e dados com antecedência ajuda você a reduzir o downtime e alguns riscos associados à aplicação de patches.

Quando você abre um caso de suporte proativo, é possível reduzir significativamente o tempo de solução de problemas necessário para recuperar um serviço. Além disso, você tem a oportunidade de revisar todos os procedimentos e abordagens com antecedência. Isso tem um impacto considerável na redução de interrupções e nas métricas de tempo médio de recuperação (MTTR).

6. Automação

Todo mundo sabe que substituir as etapas manuais por uma abordagem automatizada diminui os erros humanos, aumenta a confiabilidade e acelera o processo de aplicação de patches. A automação é um diferencial importante na hora de adotar as melhores práticas recomendadas para sua organização.

O Red Hat Satellite oferece suporte à execução remota com o Ansible. Com ele, você executa Ansible Playbooks e Roles no inventário do RHEL, além de automatizar e agendar atividades de aplicação de patches com facilidade.

Na verdade, usando o Ansible Collection oficial redhat.satellite incluída no Red Hat Ansible Automation Platform, é possível automatizar e orquestrar todo o gerenciamento de conteúdo do Satellite e aplicar o conteúdo do patch depois do preparo dele.

Indo mais além, há módulos do Ansible que servem para você fazer testes funcionais de serviços web ou a verificação do serviço após a aplicação de um patch.

Resumo

A Red Hat publicou o artigo Uma abordagem aberta para o gerenciamento de vulnerabilidades, que apresenta uma metodologia concisa e abrangente sobre como nós organizações abordamos o gerenciamento de vulnerabilidades. O gerenciamento de riscos é uma decisão que você deve tomar depois de considerar e avaliar os resultados, impactos e limitações dos negócios.

A grande questão é a seguinte: todas as vulnerabilidades realmente importam? Este artigo destaca alguns fatos e prós e contras relacionados à avaliação de resultados, impactos e restrições. Ele oferece um bom exemplo de como ponderar o desejo de alcançar resultados em relação ao custo e benefícios desse processo. Embora você precise considerar todos os riscos, nem tudo deve ser avaliado da mesma forma, e ninguém tem recursos ilimitados para lidar com eles. O segredo é priorizar o que é mais importante e estabelecer uma estratégia para classificar os riscos que valem a pena ou não mitigar.

Em resumo, o que você precisa é iteração e compromisso. Nenhum dos exemplos mostrados neste artigo vieram da primeira tentativa de uma estratégia. Cada um deles foi reformulado e aprimorado várias vezes até encontrarmos o equilíbrio ideal para a Red Hat no gerenciamento de riscos. E esses métodos continuam sendo aprimorados à medida que aprendemos mais e o setor muda. Continuar avaliando a postura e a tolerância a riscos é tão importante quanto ter uma abordagem definida. A adaptação e o aprimoramento contínuos são o que realmente tornam uma prática “recomendada”.