Comparando o KernelCare
com o kpatch da Red Hat

Atualmente, a maioria dos fornecedores de Linux corporativo oferece uma ferramenta de correção em tempo real, e a da Red Hat é o kpatch, integrado ao RHEL desde 2014. Seu projeto de código aberto de origem, no entanto, está obsoleto. O kpatch aplica correções no kernel a um servidor em execução, de modo que as atualizações de segurança não precisam mais aguardar uma janela de manutenção.

O problema é o quão limitada é a cobertura. O kpatch corrige apenas cerca de 10% das vulnerabilidades (CVEs) que afetam um sistema, ignorando completamente o espaço do usuário, e sua cobertura expira após cerca de um ano por kernel, forçando justamente as reinicializações que a aplicação de patches em tempo real deveria eliminar. Além disso, essa proteção tão limitada ainda depende de assinaturas caras do RHEL.

O KernelCare da TuxCare foi desenvolvido para evitar essas lacunas. Ele corrige todas as vulnerabilidades CVE do kernel, independentemente do nível de gravidade, estende-se ao OpenSSL e à glibc por meio do LibCare e oferece cobertura contínua sem reinicializações forçadas, tudo isso por apenas US$ 50 por sistema por ano. A comparação abaixo detalha os pontos em que os dois produtos divergem.

	Red Hat kpatch	KernelCare
Distribuições compatíveis	Apenas Red Hat Enterprise Linux	Red Hat Enterprise Linux 6, 7, 8, 9, além do Ubuntu, Oracle, AlmaLinux e muitos outros
Vulnerabilidades corrigidas	❌ Apenas cerca de 10% das CVEs (CVE-s do kernel classificadas como “Importantes” e “Críticas”)	✅ Cobertura de até 100%
Cobertura para o kernel do Linux e para componentes críticos do espaço do usuário (OpenSSL, glibc)	❌ Apenas no kernel	✅ Sim
Suporte à arquitetura ARM64	❌ Apenas x86-64	✅ Sim
Aplicação de patches em tempo real para qualquer kernel em execução	❌ Selecione apenas os grãos qualificados	✅ Sim
Vida útil praticamente ilimitada para a aplicação de patches no kernel	❌ Cerca de um ano por semente	✅ Sim
integrado e automatizado para aplicação de patches	❌ Sem agente dedicado; patches fornecidos como RPMs, aplicados via yum/dnf ou Satellite	✅ O agente verifica e aplica novos patches automaticamente
Aplicação de patches em tempo real para o sistema operacional em fim de vida útil	❌ Não incluído no complemento pago “Suporte de Ciclo de Vida Estendido”	✅ Red Hat Enterprise Linux 6, 7, além do Ubuntu, Oracle, AlmaLinux e muitos outros
Funcionalidade de reversão sem reinicialização	❌ Após reiniciar	✅ Sem necessidade de reinicialização
Entrega personalizada de emblemas	❌ Faça você mesmo com o kpatch-build; não é fornecido nem oferecido como serviço	✅ Totalmente gerenciado
Gerenciamento centralizado e isolado da rede	❌ Requer o Red Hat Satellite (licença separada)	✅ Incluído (ePortal)
API disponível	❌ A API centralizada requer o Red Hat Satellite (licença separada)	✅ Incluído (ePortal)
Distribuição de um único pacote de correções para todas as correções	✅ Sim	✅ Sim
Desenvolvido ativamente na fase inicial	❌ Obsoleto, em modo de manutenção	✅ Sim
Suporte 24 horas por dia, 7 dias por semana	❌ Apenas gravidade 1 e 2, assinantes premium	✅ Online, 24 horas por dia, 7 dias por semana, 365 dias por ano
Complementos	–	LibCare, emblemas personalizados
Tipo de remendo	Persistente	Persistente
Custo	Requer uma assinatura ativa do RHEL: US$ 878,90 (Padrão) ou US$ 1.428,90 (Premium) por sistema/ano; complemento EUS: +US$ 273,90	A partir de US$ 50 por sistema por ano; preços por volume disponíveis

O gráfico mostra em que pontos os dois se diferenciam. O restante desta comparação explica o que cada diferença significa para os sistemas que você realmente utiliza.

A aplicação de patches em tempo real deve abranger os sistemas que você realmente utiliza, independentemente da combinação de distribuições que venha a ser. O kpatch é desenvolvido e mantido pelos desenvolvedores da Red Hat; portanto, na prática, trata-se de uma ferramenta do RHEL, e mesmo dentro do RHEL, o RHEL 6 e algumas versões do RHEL 7 estão fora do escopo de suporte. Algumas distribuições que não são do RHEL, como versões específicas do Ubuntu, Debian e Gentoo, têm suporte técnico, mas somente se você mesmo criar os patches dinâmicos, o que exige profundo conhecimento do kernel e acarreta risco real caso haja algum erro.

O KernelCare adota uma postura oposta. Ele aplica patches em tempo real no RHEL, Ubuntu, Debian, Oracle Linux, AlmaLinux, Rocky Linux, Amazon Linux e outras distribuições, logo de cara. Para uma empresa que utiliza apenas uma distribuição, isso pode não parecer decisivo hoje, mas significa uma única ferramenta e um único fluxo de trabalho caso seu ambiente venha a se expandir para além do RHEL.

O objetivo principal da aplicação de correções em tempo real é corrigir rapidamente as vulnerabilidades; portanto, a primeira questão é saber quais delas uma ferramenta realmente corrige. Nossa própria pesquisa constatou que o kpatch aplica correções em tempo real em apenas cerca de 10% dos CVEs que afetam um sistema, e parte dessa lacuna se deve ao próprio design da ferramenta.

O kpatch aplica correções em tempo real apenas às CVEs do kernel que a própria Red Hat classifica como “Importantes” ou “Críticas”, e esse critério é mais restrito do que parece. A Red Hat atribui suas próprias classificações de gravidade, que podem diferir da pontuação que uma CVE recebe no Banco de Dados Nacional de Vulnerabilidades (NVD); portanto, uma falha classificada como “Crítica” em outros lugares pode ter sua classificação rebaixada e ser ignorada. Essas classificações também pressupõem uma configuração típica; portanto, um CVE que a Red Hat classifique com pontuação mais baixa ainda pode representar um risco grave em sua configuração específica, mas não receberá um patch em tempo real e terá que aguardar a próxima versão do kernel e uma reinicialização. E mesmo entre os CVEs que a Red Hat mantém como “Importantes” ou “Críticos”, sua própria documentação afirma que nem todos têm garantia de receber um patch em tempo real.

O KernelCare elimina as incertezas ao aplicar correções dinâmicas a todas as vulnerabilidades (CVEs) do kernel, independentemente da classificação de gravidade; assim, a cobertura não depende da pontuação atribuída a uma determinada CVE.

A aplicação de patches em tempo real deveria manter todo o sistema seguro sem a necessidade de reinicializações, mas o kpatch atua apenas no kernel. Todas as vulnerabilidades nas bibliotecas do espaço do usuário, incluindo as falhas no OpenSSL e na glibc por trás de incidentes como Heartbleed, GHOST e Looney Tunables, ainda dependem de uma atualização do pacote e da reinicialização de um serviço ou aplicativo. Essas bibliotecas estão na base de quase tudo o que você executa; portanto, uma única correção na glibc ou no OpenSSL pode significar a reinicialização de grande parte da pilha.

O KernelCare preenche essa lacuna com o LibCare, aplicando patches em bibliotecas compartilhadas como o OpenSSL e a glibc na memória, sem precisar reiniciar os aplicativos que dependem delas. A aplicação de patches em partes críticas do espaço do usuário sem tempo de inatividade é o que permite que as equipes cumpram os prazos de correção exigidos pelas normas PCI DSS, SOC 2 e FedRAMP em sistemas que não podem ser colocados fora do ar.

A aplicação de patches em tempo real deve proteger todos os servidores do seu ambiente, não apenas aqueles que utilizam um processador específico. O kpatch aplica patches em tempo real em x86-64 e ppc64le, o que deixa os sistemas Arm64 totalmente sem essa funcionalidade. À medida que a Arm ganha cada vez mais espaço nos data centers e na nuvem, esse se torna um ponto cego cada vez mais significativo.

O KernelCare oferece suporte tanto ao x86-64 quanto ao Arm64; portanto, a mesma proteção sem necessidade de reinicialização se aplica independentemente de a carga de trabalho ser executada em hardware x86 tradicional ou em Arm.

A aplicação de patches em tempo real deve abranger o kernel que você está executando no momento, mas o kpatch aplica patches apenas a um subconjunto deles. Ele aplica patches em tempo real aos kernels de errata de base elegíveis para o kpatch, designados pela Red Hat uma vez a cada trimestre; portanto, a menos que seu sistema esteja executando um desses kernels designados, você não receberá patches em tempo real até que mude para um deles.

O KernelCare não impõe absolutamente nenhuma restrição de elegibilidade. Seja qual for o kernel carregado, ele aplica o patch nele; assim, a cobertura se adapta aos seus sistemas, em vez de exigir que eles sigam uma lista.

Mesmo quando você está usando um kernel elegível, a cobertura é limitada no tempo. Cada kernel elegível recebe patches em tempo real por cerca de um ano; após esse período, é necessário atualizar o kernel e reiniciar o sistema para continuar recebendo correções. Essa é a limitação que, discretamente, anula o objetivo. Em vez de eliminar as reinicializações, o kpatch apenas as adia, e você acaba tendo que planejar janelas de manutenção de acordo com o calendário do fornecedor de qualquer maneira.

O KernelCare não estabelece esse prazo, aplicando patches em cada kernel por um período praticamente ilimitado, para que você permaneça protegido no seu kernel atual, sem a necessidade de uma reinicialização anual obrigatória.

A aplicação de patches em tempo real deve ocorrer discretamente em segundo plano, sem se tornar mais uma tarefa a ser gerenciada. O kpatch não possui um agente dedicado para a automação de patches. Os patches são fornecidos como RPMs que você aplica por meio do yum ou do dnf, ou distribui com o Satellite, o que significa que manter o sistema atualizado é uma tarefa administrativa manual ou algo que você precisa organizar usando ferramentas de atualização de uso geral.

O KernelCare instala um agente leve que verifica e aplica novos patches automaticamente, além de se integrar à automação de TI que você já utiliza. Depois de implantado, manter os sistemas atualizados deixa de ser uma tarefa recorrente.

A Red Hat não fornece patches dinâmicos (kpatch) durante a Fase de Vida Útil Estendida, nem mesmo com o complemento pago de Suporte ao Ciclo de Vida Estendido. Quando uma versão chega ao fim da vida útil, o recurso de patches dinâmicos é desativado, mesmo que você continue pagando pelas errata de segurança.

O KernelCare faz o contrário. Ele continua fornecendo patches em tempo real para versões de distribuições que chegaram ao fim do ciclo de vida, como CentOS 7, Ubuntu 18.04, Debian 10, RHEL 7 e muitas outras, de modo que os sistemas que você não pode desativar dentro do prazo continuem protegidos enquanto você planeja a migração de acordo com seu próprio cronograma.

As correções em tempo real devem ser reversíveis, pois, ocasionalmente, uma correção precisa ser revertida, por exemplo, quando uma medida de mitigação acarreta um custo de desempenho (como aconteceu com algumas correções para as vulnerabilidades Spectre e Meltdown) e há uma medida alternativa disponível.

O kpatch não consegue fazer isso. Reverter um patch aplicado em produção exige uma reinicialização, o que transforma um patch problemático em uma interrupção planejada e elimina justamente a vantagem que tornava a aplicação de patches em produção tão atraente. O KernelCare, por outro lado, permite reverter qualquer patch aplicado com um único comando e sem necessidade de reinicialização; assim, reverter um patch tem um impacto tão baixo quanto aplicá-lo.

Alguns ambientes precisam de uma correção que o fornecedor ainda não disponibilizou ou de um patch adaptado ao seu próprio código. Com o kpatch, isso é um trabalho “faça você mesmo”: você mesmo compila o patch com o kpatch-build, sem entrega gerenciada e sem suporte técnico. Para a maioria das equipes, o conhecimento necessário sobre o kernel já é, por si só, uma barreira.

A KernelCare oferece patches personalizados totalmente gerenciados, que a TuxCare desenvolve, testa e mantém para você. Você obtém a correção necessária sem ter que arcar com o trabalho e o risco de criar patches em produção internamente.

Em qualquer escala real, a aplicação de patches em tempo real precisa ser gerenciada de forma centralizada e, cada vez mais, em ambientes sem acesso à internet. Com o kpatch, a implantação centralizada implica a instalação de um Red Hat Satellite com licença separada, o que representa um custo adicional e mais um sistema para ser executado.

O KernelCare inclui o ePortal, um servidor de patches privado local para implementações em etapas, implantações controladas e redes totalmente isoladas, sem custo adicional de licença. O recurso que tem custo adicional na Red Hat já faz parte do pacote da TuxCare.

A aplicação de patches moderna deve poder ser automatizada por meio de scripts e integrada ao restante da sua automação. O kpatch não oferece uma API nativa; portanto, qualquer processo orientado por API passa, mais uma vez, pelo Red Hat Satellite.

O KernelCare inclui a API do ePortal para registro, gerenciamento e automação via Ansible, de modo que a aplicação de patches em tempo real se integra aos pipelines existentes sem a necessidade de um produto de gerenciamento separado.

A escolha de uma ferramenta de aplicação de patches é uma decisão de longo prazo; por isso, a saúde do projeto é importante. O projeto kpatch, de código aberto, está agora em modo de manutenção, com a compilação de patches migrando para o klp-build no kernel principal. O KernelCare, por outro lado, é desenvolvido ativamente e conta com suporte comercial em diversas distribuições e arquiteturas — exatamente o tipo de trajetória que você deseja para a infraestrutura que pretende manter em operação por muitos anos.

Quando uma questão relacionada a patches se torna urgente, o tempo de resposta é fundamental. O suporte 24 horas por dia do kpatch é restrito a casos de gravidade 1 e 2 e está disponível apenas para assinantes premium; portanto, problemas de menor gravidade ficam pendentes até o horário comercial. O KernelCare inclui suporte online 24 horas por dia, 7 dias por semana, 365 dias por ano, para todos os níveis de assinatura.

O KernelCare Enterprise custa a partir de US$ 50 por sistema por ano para a aplicação de patches em tempo real no kernel e funciona em seus sistemas RHEL existentes, sem a necessidade de uma assinatura da Red Hat. A aplicação de patches em tempo real no espaço do usuário para OpenSSL e glibc está disponível por meio do complemento LibCare. O kpatch, por outro lado, não tem custo adicional, mas depende de uma assinatura ativa do RHEL, com preço de US$ 878,90 para a versão Standard ou US$ 1.428,90 para a versão Premium por sistema por ano, com o complemento EUS custando mais US$ 273,90 para manter as janelas de aplicação de patches em tempo real abertas.

A diferença é mais acentuada quando se considera uma frota. O patch em tempo real do kernel para 100 sistemas custa US$ 5.000 por ano com o KernelCare. Para obter o mesmo serviço pela Red Hat — uma assinatura do RHEL Standard mais o EUS —, o custo é de quase US$ 115.280 por ano, cerca de 23 vezes mais. E mesmo que você considere o kpatch como já pago dentro de um ambiente RHEL existente, os direitos do EUS que mantêm essa possibilidade ainda acrescentam cerca de US$ 27.390 por ano.

Se você utiliza apenas o RHEL, o kpatch pode parecer uma escolha natural, já que vem incluído no seu contrato com a Red Hat. O ponto central dessa comparação é que, mesmo em um ambiente composto exclusivamente por RHEL, a configuração padrão deixa mais vulnerabilidades sem correção do que parece. Muitas vulnerabilidades (CVEs) do kernel e todas as do espaço do usuário ficam sem correção; a cobertura oferecida se limita aos kernels básicos selecionados pela Red Hat; cada janela de atualização expira após cerca de um ano; e até mesmo reverter uma correção exige uma reinicialização.

O KernelCare foi desenvolvido para eliminar essas limitações. Ele aplica patches continuamente no kernel e no espaço do usuário, independentemente do nível de gravidade, em qualquer kernel que você esteja executando, mesmo muito além do fim de vida útil do mesmo. As reversões são feitas sem reinicialização, os patches personalizados são totalmente gerenciados e tudo isso funciona em seus sistemas existentes por uma fração do que a Red Hat cobra. Portanto, quer você utilize uma combinação de distribuições ou deseje que todas as vulnerabilidades sejam corrigidas sem interromper o funcionamento dos sistemas, o KernelCare é a melhor opção.

A migração do kpatch para o KernelCare é simples. Um único script de início rápido instala o KernelCare, seus sistemas passam a receber correções contínuas em tempo real em toda a infraestrutura, e as cargas de trabalho existentes continuam em execução pelo tempo que você precisar.

Para as equipes que desejam experimentá-lo primeiro, o KernelCare oferece um período de teste gratuito de 30 dias com todas as funcionalidades, para que você possa conferir a cobertura ininterrupta antes de se comprometer.