TuxCare ELS: Continuar a utilizar versões antigas do Linux de forma controlada

O que complementa o TuxCare ELS

Quando a manutenção regular de uma distribuição Linux chega ao fim, um servidor não continua necessariamente a receber atualizações de segurança através das fontes de pacotes anteriores. Isto é particularmente problemático quando uma aplicação especializada ainda está ligada ao ambiente antigo. O suporte alargado pode proporcionar tempo para uma transição controlada, sem anular o fim da manutenção regular.

TuxCare Suporte ao ciclo de vida ilimitado O for OS disponibiliza atualizações de segurança e correções de erros selecionadas para distribuições mais antigas compatíveis. Segundo o fabricante, a oferta inclui o kernel e uma seleção de pacotes importantes, dependendo da distribuição. Não instala nenhuma nova versão principal do Linux: o servidor mantém a versão da distribuição que já possui e recebe manutenção adicional para os componentes abrangidos.

Para a empresa, isto pode constituir uma solução provisória importante: em vez de ter de mudar imediatamente uma aplicação incompatível, é possível preparar a migração enquanto se instalam as correções de segurança disponíveis para os pacotes abrangidos. No entanto, é necessário que os pacotes efetivamente necessários, a arquitetura e a oferta escolhida sejam compatíveis entre si.

O Capa para pacotes não é sinónimo da segurança de todo o servidor. Uma aplicação instalada pelo próprio utilizador, uma extensão ou um serviço proveniente de outra fonte de pacotes pode estar fora do âmbito do sistema operativo. Além disso, os erros de configuração e os serviços desnecessariamente acessíveis não desaparecem com uma subscrição; continuam a ter de ser verificados e protegidos.

Mesmo no caso dos pacotes abrangidos, o nível de gravidade é relevante: a TuxCare prevê correções de segurança para riscos elevados e críticos a partir de CVSS 7. No caso de riscos médios, entre CVSS 4,0 e 6,9, segundo o fornecedor, as correções são consideradas se não houver medidas de mitigação disponíveis e se houver procura suficiente por parte dos clientes. A TuxCare reserva-se ainda o direito de oferecer uma medida de mitigação em vez de uma correção direta do código. Um pacote abrangido não significa, portanto, que todas as vulnerabilidades conhecidas nele contidas sejam corrigidas.

Por isso, o que é decisivo não é apenas se a distribuição consta de uma lista de suporte. Para Segurança do Linux identifica quais os componentes utilizados nesse servidor específico, se existem correções adequadas disponíveis e se estas estão efetivamente instaladas. O ELS complementa o processo de aplicação de patches, mas não substitui nem o inventário nem um plano de migração.

Verificar a cobertura e o inventário dos servidores

Antes de escolher o TuxCare ELS, é necessário Inventário do servidor. Registe a distribuição e a versão exata, a arquitetura e o kernel em execução. Documente também as fontes de pacotes configuradas e os serviços acessíveis ao público ou a partir de outras redes. Desta forma, é possível comparar a lista do fabricante com o sistema real, em vez de se limitar a assinalar apenas o nome da distribuição.

No caso de um servidor Web mais antigo, por exemplo, o inventário deve incluir o pacote do servidor Web, as bibliotecas de criptografia, o ambiente de execução do PHP e as extensões de PHP necessárias. Regista sempre a origem do pacote e a versão que está instalada. Uma extensão proveniente de um repositório externo pode ter condições de manutenção diferentes das de um pacote da distribuição original.

Compare estes componentes, um a um, com a lista atual de pacotes da distribuição em questão. Verifique também a arquitetura e as condições da oferta prevista. O facto de uma distribuição ser suportada não significa que todos os pacotes nela instalados ou todas as versões de um ambiente de execução sejam automaticamente abrangidos pelo ELS for OS. Mesmo no caso dos pacotes abrangidos, o tratamento de vulnerabilidades específicas depende, entre outros fatores, do seu grau de gravidade.

Os programas compilados pelo próprio utilizador e os ambientes de execução instalados separadamente são especialmente fáceis de ignorar. Uma imagem de contentor também inclui os seus próprios componentes: a manutenção do sistema operativo anfitrião não garante que os pacotes na imagem estejam atualizados. Para esses componentes, é necessária uma verificação específica e um processo de atualização próprio.

ELS para OS e ELS para aplicações são ofertas distintas. A possibilidade de uma versão antiga do PHP ser mantida através de uma oferta adicional depende, entre outros fatores, da versão, do formato do pacote, da arquitetura e da forma de aquisição. O artigo sobre descreve outro ambiente possível para aplicações PHP mais antigas O CloudLinux Alt-PHP e os seus aspetos de segurança; daí não decorre qualquer cobertura ao abrigo de uma subscrição do sistema operativo TuxCare.

Classificar corretamente os prazos de assistência

O fim do suporte só faz sentido quando considerado em conjunto com a respetiva fase de manutenção. O fim da manutenção regular nem sempre significa que todas as ofertas pagas ou complementares terminem simultaneamente. Por isso, para tomares uma decisão, deves tomar nota tanto do período como dos pacotes abrangidos, das arquiteturas e das condições contratuais.

A documentação da TuxCare atualmente disponível indica, para os sistemas operativos suportados, um tempo de execução ELS garantido de 25 anos a partir da data de fim do suporte inicial indicada em cada caso. A título de exemplo, a empresa refere 30 de junho de 2049 para o CentOS 7 e 31 de maio de 2048 para o Ubuntu 18.04. Trata-se de informações fornecidas pelo fornecedor relativamente ao período de suporte, não constituindo qualquer garantia para todas as aplicações instaladas.

No caso do Ubuntu 18.04, a Canonical distingue várias fases: a manutenção padrão terminou em maio de 2023; o Ubuntu Pro tem suporte até maio de 2028. A visão geral atual indica maio de 2033 como data para a cobertura adicional de versões antigas. Estas ofertas não são comparáveis apenas com base nas suas datas de término, uma vez que o âmbito do pacote, a arquitetura e as condições contratuais específicas do servidor são fatores determinantes.

No caso de um servidor web Ubuntu, por exemplo, verifique se os pacotes necessários estão efetivamente incluídos na versão de manutenção selecionada e como é que as atualizações se integram no processo operacional existente. Um período de tempo mais longo pouco adianta se um prazo crítico ou uma extensão estiver fora do âmbito acordado.

Os prazos mencionados baseiam-se em páginas dinâmicas dos fabricantes, de acordo com as fontes consultadas a 4 de novembro de 2026. Não é possível verificar de forma retroativa se todas as informações atuais já se aplicavam nessa data de referência. Por isso, verifique novamente os prazos e as listas de pacotes antes da publicação ou da celebração do contrato e mantenha o respetivo Saldo de consultas certamente. Mesmo uma promessa de suporte a longo prazo não é garantia de que o servidor seja, no geral, seguro.

Configurar um servidor CentOS 7 de forma prática

Suponhamos que um servidor Web CentOS 7 tenha de continuar a executar, temporariamente, uma aplicação especializada mais antiga. Antes de TuxCare ELS Ao selecionar essa opção, registas o estado real do sistema e as dependências da aplicação. O que é decisivo não é apenas se o CentOS 7 é suportado, mas sim se os componentes necessários para a arquitetura existente estão abrangidos.

Podes executar os comandos seguintes num shell no servidor. Estes comandos leem o identificador da distribuição, a arquitetura da máquina e a versão do kernel em execução; não alteram nem os pacotes nem as fontes dos pacotes. Anota os resultados no inventário do servidor e compara-os com as instruções atuais do CentOS 7.

cat /etc/os-release
uname -m
uname -r

Completa isto Inventário do servidor fontes de pacotes configuradas, versões de pacotes instaladas e serviços acessíveis ao público. No caso de um servidor Web, isto inclui, em particular, o pacote do servidor Web, bibliotecas de criptografia, o ambiente de execução do PHP e as extensões. Regista também quais os componentes que provêm de fontes externas ou que foram compilados pelo próprio; estes não podem ser considerados, sem verificação, como parte da cobertura do sistema operativo.

Para o CentOS 7, a TuxCare indica como pré-requisitos uma chave de licença válida, acesso de root e ligações HTTPS. O guia também faz uma distinção consoante a arquitetura: para aarch64 e i686, descreve a cobertura do espaço de utilizador, enquanto a aplicação de patches em tempo real no kernel é descrita apenas para x86_64. Esta restrição diz respeito ao guia do CentOS 7 e não pode ser generalizada para outras distribuições.

Em seguida, para a aplicação específica, verifique cada pacote necessário em relação à lista atual e esclareça as lacunas remanescentes com o respetivo fornecedor. Mesmo um kernel em execução que seja suportado não garante, por si só, nem a compatibilidade com a aplicação nem que todas as atualizações disponíveis estejam instaladas e ativas.

Configurar o repositório e implementar atualizações

Planeia a instalação como controlada Cadeia de controlo: Em primeiro lugar, a licença, a arquitetura e os pacotes necessários têm de ser compatíveis. Em seguida, verifica se o servidor tem permissão para aceder, através de HTTPS, aos destinos necessários para a sua distribuição. Para o registo e a configuração do repositório, utiliza as instruções originais e atualizadas específicas da distribuição, uma vez que os pré-requisitos e os endereços de destino podem sofrer alterações.

No CentOS 7, a TuxCare descreve o registo do sistema, a adição da fonte de pacotes e de uma chave PGP. A fonte permite, posteriormente, obter os pacotes adequados; no entanto, não instala automaticamente todas as atualizações disponíveis. Após a configuração, verifique se o repositório foi integrado conforme o esperado e se o gestor de pacotes disponibiliza as atualizações adequadas.

É necessário ter em conta na planificação a utilização de um proxy ou de regras restritivas de firewall de saída. No caso de vários sistemas, poderá ser considerada a criação de um espelho local, após consulta à TuxCare. Não copie cegamente os endereços de destino de um FAQ geral: verifique-os antes da aprovação, consultando as instruções atualizadas para a distribuição escolhida e o modo de funcionamento previsto.

Teste primeiro as atualizações disponíveis num ambiente de teste o mais semelhante possível à aplicação especializada. Ao fazê-lo, verifique o seu arranque, os processos empresariais importantes e as interfaces. Em seguida, procede-se à aprovação operacional e à instalação no sistema produtivo; documente as versões dos pacotes, a data e o resultado, em vez de considerar apenas a ativação bem-sucedida no repositório como conclusão.

Se uma atualização esperada ainda não estiver disponível, verifica também o Estado da implementação. Para várias plataformas, a TuxCare distribui as atualizações de forma escalonada; após a publicação no repositório estável, este processo pode demorar até 14 dias adicionais. Se necessário, o fornecedor descreve uma solução alternativa: utilize-a apenas de acordo com as instruções atuais para a respetiva distribuição e versão específica, bem como após aprovação operacional. A duração da implementação não implica um prazo total garantido para um patch.

Além disso, prepara um plano de contingência e um intervalo de tempo adequado para a manutenção. As chaves de licença não devem constar em comandos de exemplo publicados, tickets ou registos não protegidos. Para o registo propriamente dito, deves seguir as instruções atuais do fabricante e fornecer os dados de acesso apenas através dos procedimentos previstos para o efeito.

Comparação entre alternativas de manutenção

A escolha entre o TuxCare ELS e uma manutenção alargada do fabricante depende do conjunto de pacotes efetivamente existente e das condições do contrato. A tabela apresenta exemplos para a pré-seleção, não constituindo um compromisso geral para todas as arquiteturas ou pacotes. A data de referência da pesquisa é 4 de novembro de 2026; as informações dinâmicas do fabricante e as listas de pacotes devem ser verificadas novamente antes da publicação.

No caso do Ubuntu 18.04, a manutenção padrão terminou em maio de 2023. A Canonical indica que o suporte para o Ubuntu Pro se estende até maio de 2028 e, na sua visão geral atual sobre cobertura adicional para versões antigas, até maio de 2033. A TuxCare indica atualmente 31 de maio de 2048 como data de término do ELS para o Ubuntu 18.04. Estas datas referem-se a ofertas diferentes; uma data de término mais tardia não implica automaticamente a cobertura adequada do pacote.

Por isso, compara o Âmbito da manutenção para cada pacote necessário e para a arquitetura efetivamente utilizada. No caso do Ubuntu, são particularmente relevantes os componentes Main e Universe, bem como as condições para o Pro e um eventual complemento Legacy. Regista também como é possível comprovar as correções CVE disponíveis e se os processos de aprovação e atualização existentes se adequam à oferta.

Em ambos os exemplos, o destino da migração continua a ser uma decisão de planeamento, não uma característica do contrato de manutenção. Se a aplicação especializada ainda não for executável numa plataforma suportada, uma alternativa de manutenção adequada pode proporcionar tempo para a realização de testes. Se nenhuma das propostas cobrir uma dependência crítica, essa lacuna deve ser tratada separadamente antes de se poder garantir a continuidade da operação de forma responsável.

Verificar alertas CVE e backports

Se, após uma atualização, um scanner continuar a indicar uma vulnerabilidade, verifique primeiro a distribuição e a versão exatas, bem como o nome, a arquitetura e a versão instalada do pacote em questão. Verifique também de que fonte de pacotes provém. Um resultado relativo a um pacote da distribuição não pode ser automaticamente aplicado a uma aplicação compilada pelo próprio utilizador ou a um pacote proveniente de um repositório externo.

A razão para as aparentes contradições pode ser um Backport ser: Neste caso, uma correção de segurança é incorporada numa versão de desenvolvimento mais antiga, sem que o número de versão «upstream» visível corresponda à versão mais recente. Por conseguinte, um número de versão mais antigo, por si só, não prova nem que o pacote seja vulnerável, nem que a notificação do scanner seja necessariamente errada.

Compare o CVE específico e a versão do pacote instalado com as informações relativas à tua distribuição no TuxCare CVE Tracker. „In Testing“ significa que uma correção ainda está a ser testada; em „In Rollout“, está a ser distribuída através dos repositórios de rollout. Por outro lado, „Released“ indica o lançamento completo para todos os utilizadores. Mesmo nesse caso, deve verificar se a versão adequada foi efetivamente instalada; „Not Vulnerable“ significa que a versão da TuxCare não está afetada.

Se faltar uma atualização esperada no gestor de pacotes, verifica, além da fonte do pacote e da versão, o Estado da implementação. No caso de várias plataformas, a distribuição faseada após a publicação no repositório estável pode demorar até 14 dias adicionais. Uma eventual derrogação só pode ser incluída no processo de acordo com as instruções originais atuais relativas à distribuição e à versão, bem como mediante aprovação operacional; tal não implica qualquer garantia quanto ao prazo total de aplicação do patch.

Em seguida, analisa a base de dados e os resultados do scanner. A TuxCare disponibiliza dados OVAL para uma série de produtos ELS; cabe-te a ti verificar se a tua ferramenta utiliza os dados adequados para o sistema em questão e se os interpreta corretamente. Documenta a versão do pacote, o estado do CVE e a data e hora da verificação. Se a correspondência continuar a não ser clara, continue a tratar o resultado como pendente e esclareça-o junto dos serviços especializados competentes ou do fornecedor.

Planear a aplicação de patches e os reinícios

A criação de um repositório é o início do processo de aplicação de patches, não o seu fim. Defina quem deve verificar regularmente se existem atualizações disponíveis, quem dá a autorização e como são detetadas as atualizações que falharam. Ao fazê-lo, compare as versões dos pacotes efetivamente instaladas com as atualizações disponíveis e registe as discrepâncias para cada sistema.

Sempre que possível, teste as atualizações primeiro num sistema de teste semelhante, com a mesma aplicação e as fontes de pacotes relevantes. Verifique, em particular, o arranque, o início de sessão e as interfaces importantes da aplicação especializada. Só após a aprovação operacional é que deve implementar os pacotes de forma controlada; o resultado e eventuais erros devem constar do relatório de instalação.

Preveja também a possibilidade de alterações Janela de manutenção. Mesmo após uma atualização bem-sucedida do pacote, os processos em execução podem continuar a utilizar bibliotecas antigas até serem reiniciados. Se necessário, as aplicações também terão de ser reiniciadas; no caso de alterações no kernel, poderá ser necessário reiniciar o sistema. Após o reinício, verifica tanto o funcionamento dos serviços como o estado esperado dos pacotes e do sistema.

O KernelCare Live Patching é um produto complementar e deve ser distinguido das atualizações regulares de pacotes do ELS. Pode aplicar correções suportadas ao kernel em tempo real, mas não substitui todas as atualizações nem todas as reinicializações de serviços ou do sistema. Verifique o produto, a distribuição e a arquitetura: para o CentOS 7, a TuxCare documenta o Kernel Live Patching apenas para x86_64. Outros conceitos básicos são explicados no artigo sobre o KernelCare Patch Feed.

A edição de uname -r mostra o kernel atualmente em execução, mas não o estado completo das atualizações do servidor. Um pacote de kernel instalado, por exemplo, só pode entrar em funcionamento após um reinício; por outro lado, a saída não indica se as bibliotecas e as aplicações foram atualizadas e reiniciadas.

Escolher uma solução provisória ou a migração

A adequação do TuxCare ELS a um servidor específico depende dos seus componentes e riscos reais. Compare os pacotes necessários com a cobertura disponível e identifique lacunas em aplicações, ambientes de execução e software de terceiros. O ELS for OS abrange uma seleção dependente da distribuição; o suporte ao sistema operativo não implica a manutenção de todas as aplicações nele executadas.

Verifica também as vulnerabilidades CVE remanescentes nos pacotes abrangidos. De acordo com a TuxCare, os riscos médios só são considerados para a aplicação de um patch se forem cumpridas condições adicionais; além disso, o fornecedor pode prever uma medida de mitigação em vez de uma correção direta do código. Por isso, avalia, para a vulnerabilidade em questão, se está disponível uma correção ou uma medida de mitigação e se os riscos remanescentes são aceitáveis para a tua operação.

Uma solução provisória pode fazer sentido se uma aplicação especializada estiver, por enquanto, ligada à plataforma antiga e os riscos remanescentes forem controláveis. No entanto, compare também os serviços de manutenção disponíveis oferecidos pelo fabricante: no caso do Ubuntu 18.04, dependendo do âmbito necessário, o Ubuntu Pro e, se for o caso, o complemento Legacy podem ser considerados como alternativas. Verifique os pacotes, a arquitetura e as condições contratuais, em vez de se limitar apenas à respetiva data de validade.

No caso de um serviço acessível ao público com uma aplicação desatualizada ou cujo período de vigência não esteja coberto, o ELS, por si só, pode ser insuficiente. Por isso, limite os acessos às redes e serviços efetivamente necessários, elimine autorizações desnecessárias e controle os acessos administrativos. Estes Limitação da rede reduz a superfície de ataque, mas não substitui as atualizações de segurança em falta.

Limita a duração da continuação da operação e define um objetivo de migração, com responsáveis e um prazo verificável. Planeie testes de aplicações na plataforma de destino, a transferência de dados e a verificação de todas as interfaces relevantes. Um plano de contingência deve definir em que condições interromperá a transição e como regressará ao funcionamento anterior.

Verifique regularmente o plano, tendo em conta novas vulnerabilidades nos pacotes, alterações nas dependências dos fabricantes e os custos operacionais. Se os componentes necessários já não puderem ser mantidos ou se não for possível limitar suficientemente os acessos necessários, a simples prorrogação da manutenção do sistema operativo poderá não ser suficiente. Nesse caso, é necessário reavaliar a migração, a substituição da aplicação ou o encerramento controlado.