Verificar o ciclo de vida de suporte de um sistema operacional antes de automatizar sobre ele

Objetivo

Antes de um agente automatizar patching, upgrades ou uma verificação de conformidade em um host, confirmar que a versão do sistema operacional do host ainda está dentro do período de suporte do fornecedor e, se não estiver, sinalizar isso de forma clara.

Pré-requisitos

Capacidade de identificar o sistema operacional e a versão (veja o artigo complementar sobre como detectar o SO a partir de um script) e acesso de rede à página de ciclo de vida publicada pelo fornecedor, ou uma cópia local em cache das datas relevantes.

Passos

1. Identifique primeiro a família do SO e a versão/release exata (nome da distribuição, versão principal e, no caso de sistemas com point releases, também a versão secundária).
2. Consulte como fonte primária a declaração de ciclo de vida do próprio fornecedor, não a de terceiros:
   • RHEL: a página da Red Hat sobre a política de suporte a atualizações de pacotes e errata descreve as fases de cada release principal e suas durações.
   • Ubuntu: a página do ciclo de releases do Ubuntu distingue as releases padrão (9 meses) das releases LTS (5 anos de suporte padrão, estendível).
   • Debian: a página das releases stable indica qual release é a atual e acompanha o momento em que uma release deixa de receber atualizações; o projeto separado Debian LTS estende ainda mais o suporte de segurança para algumas arquiteturas.
   • Windows / Windows Server: o site da Microsoft Lifecycle Policy fornece as datas de ciclo de vida fixo e moderno por produto e canal de manutenção (servicing channel).
   • AIX: as páginas de suporte da IBM publicam as datas do ciclo de vida de suporte dos Technology Levels (TL) do AIX.
   • FreeBSD: a página Security Information lista quais branches recebem patches de segurança atualmente.
   • macOS: a Apple não publica um calendário fixo de fim de vida; na prática, a Apple costuma lançar atualizações de segurança para a release atual e as duas anteriores (as duas mais antigas muitas vezes recebem apenas parte das correções), acompanhadas por agregadores de terceiros como endoflife.date, e não por um calendário oficial.
3. Compare a versão do host com as datas encontradas; trate "não foi possível determinar, nenhuma data publicada encontrada" como equivalente a "sinalizar para revisão", e não como "presumir que há suporte".
4. Registre a data da verificação, a fonte consultada e o status resultante (com suporte / próximo do fim de vida / após o fim de vida) junto ao registro do host no inventário.
5. Para um host após o fim de vida, impeça que os fluxos automatizados de patch/conformidade o reportem como em situação regular; em vez disso, apresente-o como um achado que exige uma decisão (fazer upgrade, substituir ou aceitar o risco de forma documentada).

Resultado esperado

Todo host no escopo tem um status de ciclo de vida registrado, datado e com fonte nomeada; os hosts após o fim de vida aparecem claramente sinalizados, em vez de serem incluídos silenciosamente em resumos do tipo "tudo atualizado".

Limites e base de verificação

As páginas de ciclo de vida dos fornecedores mudam; uma data em cache deve ser reverificada periodicamente, não tratada como permanente. A ausência de uma política de EOL publicada pela Apple significa que o status do macOS é, por natureza, uma inferência e não um fato documentado, e deve ser identificado como tal em qualquer relatório. Esta metodologia não determina se um host em EOL está sendo explorado no momento; determina apenas que ele deixará de receber correções, uma questão distinta e anterior que a automação não deve ignorar.