Fim do ciclo de vida do RHEL 8: datas, riscos e o que fazer a seguir

Principais conclusões

• O RHEL 8 chegará ao fim do ciclo de vida em 31 de maio de 2029. Após essa data, a Red Hat não disponibilizará mais patches de segurança nem correções de bugs sem um pacote adicional de suporte estendido pago.
• Manter esse sistema operacional em uso após 2029 sem um plano específico fará com que você deixe de estar em conformidade com as normas PCI DSS, HIPAA, SOC 2 e a maioria das outras estruturas regulatórias que exigem a aplicação oportuna de patches.
• Suas principais opções são atualizar para o RHEL 9, mudar para uma distribuição compatível, como o AlmaLinux ou o Rocky, ou adquirir suporte de ciclo de vida estendido para ganhar tempo para a migração.
• O suporte estendido de terceiros — como o ELS da TuxCare — permite que você mantenha o RHEL 8 atualizado com patches após o fim da vida útil (EOL) sem precisar realizar uma migração de emergência, além de abranger pacotes essenciais como o kernel do Linux, o OpenJDK, o OpenSSL, o Python e outros.

Se você estiver executando o RHEL 8 em produção, já ultrapassou um marco importante: o Suporte Completo terminou em maio de 2024. Isso significa que agora você está no Suporte de Manutenção, que é mais tranquilo, mas mais limitado — a Red Hat corrige as vulnerabilidades CVE graves, mas não está realizando nenhum trabalho de desenvolvimento novo na plataforma. A próxima data importante é 31 de maio de 2029, quando o RHEL 8 chegará ao fim de vida útil e as correções serão totalmente interrompidas.

Este artigo aborda o que cada fase do ciclo de vida realmente significa para seus sistemas, o que você está abrindo mão a cada transição, os riscos reais de deixar 2029 chegar de surpresa e as opções disponíveis — incluindo aquelas que não exigem uma atualização radical para a qual você não reservou verba no orçamento.

O que significa o fim do ciclo de vida do RHEL 8?

O fim do ciclo de vida no universo Red Hat não é um aviso sutil nem uma sugestão educada para que se considere a atualização. É o momento em que a Red Hat deixa de disponibilizar qualquer novidade para essa versão principal. Não há mais correções de CVE, nem correções de bugs, nem respostas a tickets de suporte. A versão passa para o que a Red Hat chama oficialmente de “Fase de Vida Prolongada”, na qual ainda é possível consultar a documentação e baixar os pacotes existentes, mas nada novo é desenvolvido.

Vale a pena ser preciso quanto ao que cada fase realmente oferece, pois as diferenças são significativas:

• Fase de Suporte Completo: A Red Hat fornece tudo: errata de segurança, correções de bugs urgentes e de alta prioridade, compatibilidade com novos hardwares e melhorias selecionadas de software em versões secundárias. O RHEL 8 permaneceu nessa fase de maio de 2019 até maio de 2024.
• Fase de Suporte à Manutenção: Apenas alertas de segurança críticos e importantes (RHSAs) e correções urgentes de bugs (RHBAs) são disponibilizados. Não há suporte a novos hardwares. Não há desenvolvimento de novos recursos. O RHEL 8 permanecerá disponível até 31 de maio de 2029.
• Fase de Vida Prolongada: Efetivamente descontinuada do ponto de vista de atualizações. Você pode ler a documentação e acessar os pacotes existentes, mas nada novo será disponibilizado, a menos que você tenha adquirido o complemento de Suporte de Ciclo de Vida Estendido.

A implicação prática: quando o RHEL 8 atingir o fim da vida útil (EOL) em 2029, seu kernel já terá uma década de idade do ponto de vista do desenvolvimento e não terá recebido nenhuma nova funcionalidade desde 2024. É um longo período para que o cenário de ameaças evolua enquanto a aplicação de patches é interrompida.

Cronograma do ciclo de vida de suporte do RHEL 8

Veja a seguir uma comparação entre o ciclo de vida do RHEL 8 e o de outras versões no histórico de lançamentos da Red Hat. O período de 10 anos é consistente em todas as versões modernas do RHEL; o que muda é a fase em que você se encontra atualmente dentro desse período.

Se você utilizou o RHEL 7 por tempo suficiente para sentir a pressão do prazo final de 2024, o prazo de 2029 do RHEL 8 lhe parecerá familiar — a mesma corrida para a migração, apenas adiada por cinco anos. A diferença desta vez é que o RHEL 9 está disponível ao público desde 2022, portanto, a versão de destino para a atualização é estável e bem testada. A maioria das equipes teve anos de antecedência. O intervalo entre o fim do suporte de manutenção e o fim da cobertura do ELS. É fácil interpretar erroneamente o intervalo entre o fim da manutenção ativa e o fim do suporte estendido — mas, independentemente da perspectiva que você use, 2029 chegará, independentemente de o projeto de migração ter ou não um gerente de projeto.

Por que as versões do RHEL são descontinuadas

Compreender a lógica de negócios por trás das decisões de fim de vida útil (EOL) é útil quando se tenta explicar a urgência às partes interessadas que, ao verem o prazo de 2029, presumem que ainda há tempo.

A largura de banda de engenharia tem limites

A Red Hat mantém cada versão principal ativa com sua própria equipe de mantenedores do kernel, analistas de segurança, fluxos de controle de qualidade e engenheiros de suporte. Cada versão adicional com suporte multiplica essa carga de trabalho. Em determinado momento, manter uma base de código com uma década de idade protegida contra ameaças modernas custa mais do que a receita de assinatura dessa versão justifica. A conta acaba não batendo mais, e a Red Hat decide estabelecer um limite.

Os modelos de segurança evoluem

O panorama de ameaças em 2019 não se parece em nada com o panorama de ameaças que se avizinha em 2029. Medidas de mitigação, como um fortalecimento mais rigoroso do kernel, padrões criptográficos atualizados e geração aprimorada de políticas do SELinux, são incorporadas às versões mais recentes e, muitas vezes, não podem ser portadas de forma limpa para uma base de kernel mais antiga. Eventualmente, aplicar patches em versões antigas para atender aos padrões atuais de conformidade torna-se uma proposta inviável, independentemente do esforço de engenharia.

Você pode saber mais sobre como a evolução da plataforma afeta sua situação em relação às vulnerabilidades em nossa visão geral dos ciclos de vida de segurança da Red Hat.

As cargas de trabalho modernas exigem cadeias de ferramentas modernas

Os ambientes de execução de linguagens mais recentes, as ferramentas de contêineres e as estruturas nativas da nuvem pressupõem, cada vez mais, versões mais recentes da glibc, do kernel e do systemd. O RHEL 8 vem com a glibc 2.28 e o kernel 4.18 — ainda utilizáveis para muitas cargas de trabalho, mas que representam uma limitação real caso você esteja trabalhando com eBPF, ambientes de execução de contêineres modernos ou versões recentes do Kubernetes. As estruturas de conformidade e as ferramentas de auditoria também tendem a pressupor suporte atual à plataforma ao avaliar seu ambiente.

Riscos de continuar usando o RHEL 8 após o fim do ciclo de vida

CVEs sem correção se acumulam rapidamente

Assim que a Red Hat deixar de emitir RHSAs para o RHEL 8, cada CVE no nível do kernel ou de pacotes essenciais que for divulgado se tornará uma vulnerabilidade permanente em seus sistemas. Não haverá correção do desenvolvedor original. O período pós-EOL do RHEL 7 serve como um exemplo razoável: poucos meses após o EOL, os sistemas que não haviam migrado ou adquirido suporte estendido estavam sujeitos a uma lista crescente de vulnerabilidades conhecidas e exploráveis, sem nenhuma solução disponível. Os scanners de vulnerabilidades irão identificá-las imediatamente, e não haverá correção disponível. Os auditores perceberão isso antes mesmo da sua equipe.

De acordo com o Relatório sobre o Panorama do Linux Empresarial e do Código Aberto de 2025, da TuxCare, 40% das organizações pesquisadas sofreram um incidente de segurança cibernética nos últimos 12 meses, e 60% desses incidentes estavam relacionados a patches de segurança não aplicados.

As certificações de conformidade começam a ser reprovadas

PCI DSS, HIPAA, SOC 2 Tipo II, ISO 27001, FedRAMP – todas essas normas exigem a execução de softwares que recebam patches de segurança em tempo hábil. No momento em que o RHEL 8 atingir o fim da vida útil (EOL) sem um acordo de suporte estendido em vigor, você estará tecnicamente em situação de não conformidade. Isso não é um problema teórico: uma empresa de SaaS com 40 funcionários que esteja tentando renovar um relatório SOC 2 com versões de sistema operacional sem suporte no escopo gastará muito tempo elaborando controles compensatórios que os auditores geralmente não aceitam como substitutos adequados para a aplicação efetiva de patches.

O suporte do fornecedor para toda a sua pilha vai diminuindo

Os ISVs — fornecedores de bancos de dados, fornecedores de middleware e provedores de ferramentas de segurança — vinculam suas matrizes de suporte ao ciclo de vida do sistema operacional subjacente. Quando o RHEL 8 sair da lista de sistemas operacionais suportados pela Red Hat, muitos desses fornecedores seguirão o mesmo caminho. Um incidente em produção em um banco de dados Oracle ou em uma instância SAP rodando em um sistema operacional sem suporte é o pior momento possível para descobrir que seu contrato de suporte não é mais válido.

O seguro cibernético se torna complicado

As seguradoras têm se tornado mais exigentes nesse aspecto. Os formulários de solicitação de cobertura de seguro cibernético agora perguntam rotineiramente sobre softwares em fim de vida útil (EOL) em seu ambiente, e as apólices incluem cada vez mais cláusulas que anulam pedidos de indenização por violações atribuíveis a vulnerabilidades conhecidas e não corrigidas. Utilizar software desatualizado sabendo que ele está em fim de vida útil (EOL) é um risco comprovado de responsabilidade civil que as seguradoras começaram a refletir nos preços ou a recusar os pedidos de cobertura de acordo com isso.

Quanto mais você esperar, mais difícil fica a atualização

Esse aspecto não recebe a devida atenção. A cada mês que você permanece no RHEL 8 após o fim da vida útil (EOL), a migração futura fica mais cara. Os novos funcionários têm menos familiaridade com ferramentas ultrapassadas. O gerenciamento de configurações se afasta do que está documentado ou pode ser testado. As atualizações de hardware esbarram em problemas de compatibilidade de drivers quando o firmware mais recente de placas de rede ou controladores de armazenamento não oferece suporte certificado para o RHEL 8. O sistema se torna mais difícil de equipar com pessoal, mais difícil de operar e mais difícil de migrar — tudo ao mesmo tempo.

Opções após o fim do ciclo de vida do RHEL 8

O caminho certo depende da quantidade de trabalho na camada de aplicação que uma atualização implica, do tempo de inatividade que você pode tolerar e se sua equipe conta com pessoal suficiente para assumir um projeto de migração neste momento. Não há uma resposta universal, mas há um conjunto realista de opções.

Opção 1: Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare

Vale a pena conhecer o Endless Lifecycle Support (ELS) da TuxCare caso não haja certeza de que a migração será concluída até maio de 2029. A TuxCare já oferece o ELS para o RHEL 7, fornecendo correções contínuas para vulnerabilidades após o término do suporte de manutenção da Red Hat, e espera-se que essa mesma cobertura se estenda ao RHEL 8 quando ele atingir o fim da vida útil (EOL). O serviço é independente do modelo de assinatura da Red Hat, o que significa que você pode manter as cargas de trabalho críticas do RHEL 8 atualizadas e prontas para auditoria enquanto seu projeto de migração avança em um ritmo razoável, em vez de uma corrida forçada.

Vale a pena saber o que o RHEL ELS da TuxCare realmente abrange no nível dos pacotes. O ELS no nível do sistema operacional não se limita apenas ao kernel — ele inclui pacotes comumente utilizados, como OpenJDK, Python, httpd, OpenSSL e OpenSSH; assim, os componentes essenciais da sua pilha de tecnologia estão cobertos pela mesma assinatura.

Opção 2: Atualização no local para o RHEL 9 usando o Leapp

O utilitário Leapp da Red Hat lida com atualizações diretas do RHEL 8 para o RHEL 9 e, em um sistema limpo e bem mantido, funciona bem. Em um sistema que está em operação desde 2019, com personalizações acumuladas, repositórios de terceiros e módulos do kernel que ninguém documentou completamente — nem tanto.

A abordagem correta é executar leapp preupgrade Primeiro – ele identifica os obstáculos antes de você se comprometer com qualquer coisa. Reserve tempo de verdade para resolver os obstáculos que ele encontrar, pois certamente haverá alguns.

Dica profissional: Antes de executar o comando `leapp upgrade`, verifique o /var/log/leapp/leapp-report.txt depois de leapp preupgrade – Não se limite a procurar por “inibidores”. Os itens com gravidade “alta” que não são inibidores ainda podem causar problemas após a atualização, especialmente no que diz respeito a módulos de kernel de terceiros e configurações personalizadas do PAM. Corrija-os antes de fazer o commit.

Opção 3: Reinstalação completa no RHEL 9 ou RHEL 10

Para cargas de trabalho compatíveis com contêineres ou gerenciadas por meio de infraestrutura como código, uma reconstrução paralela costuma ser mais limpa do que uma atualização no local. Você obtém uma linha de base renovada, sem artefatos de atualização, e uma oportunidade natural de eliminar a dívida técnica que vem se acumulando desde 2019. Mais lenta por host, mas mais confiável em escala.

Opção 4: Mudar para uma distribuição compatível com o RHEL

O AlmaLinux, o Rocky Linux e o Oracle Linux são alternativas binariamente compatíveis que executam os mesmos pacotes e são certificadas para a maioria das mesmas cargas de trabalho. O AlmaLinux e o Rocky são gratuitos; a Oracle oferece um nível de suporte pago. Essa opção funciona bem se suas ferramentas tratarem o sistema operacional como um produto de uso comum e você não tiver requisitos de contrato de suporte específicos da Red Hat. Verifique as certificações dos fornecedores independentes de software (ISVs) antes de tomar uma decisão — nem todos os fornecedores oferecem suporte formal às alternativas, e alguns exigem especificamente o RHEL.

Opção 5: O complemento ELS da própria Red Hat

A Red Hat oferece um complemento de Suporte de Ciclo de Vida Estendido que amplia a cobertura de segurança limitada, ultrapassando o prazo final de maio de 2029 até maio de 2032. É a escolha óbvia caso você precise permanecer no ecossistema da Red Hat e tenha orçamento para isso. A cobertura é significativamente mais restrita do que a do Suporte de Manutenção — menos pacotes, apenas os CVEs de maior gravidade —, portanto, trata-se de uma solução provisória, e não de um substituto de longo prazo para a atualização.

Como escolher:

• Se seus aplicativos já estiverem certificados no RHEL 9 e você tiver recursos de engenharia disponíveis, basta usar o Leapp e dar andamento ao processo. Essa é a solução ideal para a maioria dos ambientes mais simples.
• Se você estiver utilizando qualquer solução vinculada a um fornecedor específico – como o banco de dados Oracle, o SAP ou middleware mais antigo que ainda não tenha sido certificado para o RHEL 9 –, vale a pena ser realista quanto aos prazos desde o início. Os ciclos de certificação de software corporativo não são rápidos, e uma migração que parece simples no papel tende a se prolongar quando se leva em conta a aprovação do fornecedor, os testes e os processos de aprovação de mudanças. O suporte de ciclo de vida estendido existe justamente para esse cenário: ele oferece o tempo necessário para que você faça tudo da maneira correta, em vez de agir sob pressão.
• Se você está preocupado com os custos e não precisa de um contrato de suporte da Red Hat, o AlmaLinux ou o Rocky são opções realmente boas. Não se trata de um compromisso — são distribuições sólidas, com apoio concreto tanto da comunidade quanto do setor comercial.

Planejamento antecipado: um cronograma realista

Os prazos de fim de vida útil (EOL) parecem bem distantes até que, de repente, não estão mais. As equipes que iniciaram as migrações do RHEL 7 no início de 2024, em sua maioria, não conseguiram cumprir o prazo de junho de 2024 — os projetos de migração quase sempre levam mais tempo do que a estimativa inicial, especialmente quando há certificações de aplicativos de terceiros envolvidas.

As equipes que cumprem os prazos tratam a migração como um projeto de verdade – com um gerente de projeto, um backlog e alguém cuja função é acompanhar o status da certificação do ISV a cada duas semanas. As equipes que não cumprem os prazos são aquelas que atribuíram a tarefa a um engenheiro sênior “quando ele tiver tempo”. Esse engenheiro não tem tempo. Ele nunca tem tempo. E, de repente, já é março de 2029 e alguém está lendo o aviso de fim de vida útil (EOL) da Red Hat pela primeira vez, como se fosse uma notícia de última hora.

Uma abordagem viável para o RHEL 8 seria algo como isto:

• Mais de 24 meses: Faça um inventário de todos os hosts RHEL 8, aplicativos e dependências de ISVs. Identifique quais aplicativos já estão certificados para o RHEL 9 e quais representam obstáculos.
• Faltam 18 meses: Faça um teste piloto do RHEL 9 (ou da alternativa de sua escolha) em cargas de trabalho que não sejam de produção. Execute leapp preupgrade em sistemas representativos e documentar os fatores inibidores.
• 12 meses antes: Inicie as migrações de produção em etapas, começando pelas cargas de trabalho de menor risco. Decida quais sistemas permanecerão no RHEL 8 com suporte estendido e elabore o orçamento de acordo com isso.
• A 6 meses do prazo: Finalize os contratos de suporte estendido para os casos que ainda estejam pendentes. Confirme a documentação de conformidade com seus auditores para que não haja surpresas.
• Pré-EOL: Todos os sistemas são migrados ou contam com suporte estendido. Nenhum sistema fica em operação sem as atualizações de segurança instaladas.

Se o seu ambiente for composto por mais do que alguns poucos hosts, é quase certo que você se deparará com o tipo de complexidade operacional que transforma atualizações simples em esforços que se estendem por vários trimestres. Quanto mais cedo você assumir a responsabilidade pelo projeto, menos impactante essa complexidade se tornará.

Mantenha-se protegido com o ELS da TuxCare

Para a maioria dos ambientes de produção do RHEL 8, o cenário mais realista é o seguinte: você inicia a migração dentro do prazo, se depara com um aplicativo dependente de um fornecedor específico que ainda não foi certificado para o RHEL 9 e precisa de mais tempo do que o previsto no plano original. É aí que o suporte de segurança estendido deixa de ser opcional.

A TuxCare mantém seus sistemas atualizados contra vulnerabilidades após a data de fim de vida útil do RHEL 8, em maio de 2029, com experiência no suporte ao CentOS, ao RHEL 7 e a uma variedade de outras distribuições Linux que chegaram ao fim de vida útil. Você ganha tempo para realizar a migração de forma adequada, sem ficar com sistemas sem patches em produção – e sem precisar comprar às pressas uma assinatura estendida da Red Hat no último minuto.

Para ambientes em que a reinicialização é um problema, vale a pena dar uma olhada no KernelCare separadamente – ele aplica patches no kernel em execução sem exigir tempo de inatividade. É um produto diferente do ELS, adquirido separadamente, mas os dois podem ser usados em conjunto.

Resumo

Nome do artigo

Fim do ciclo de vida do RHEL 8: datas, riscos e o que fazer a seguir

Descrição

Saiba quando termina o suporte ao RHEL 8, quais são os riscos de utilizar sistemas sem suporte e quais são as melhores opções para manter a segurança e a conformidade após o fim do ciclo de vida (EOL).

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora