Comparando o KernelCare com o
Oracle Ksplice

A Oracle foi uma das pioneiras na aplicação de patches no Linux sem reinicialização. O Ksplice vem aplicando correções no kernel em servidores em funcionamento muito antes de a maioria dos fornecedores lançar qualquer solução comparável. A tecnologia funciona. A verdadeira questão é quanto custa para você usá-la.

O Ksplice não é um produto independente. Trata-se de um recurso do Oracle Linux Premier Support; portanto, a aplicação de patches sem reinicialização vem incluída em uma assinatura de suporte da Oracle de alto custo e, cada vez mais, junto com o kernel da Oracle. Ele aplica patches em tempo real apenas a uma seleção de vulnerabilidades — mesmo entre as classificadas como Críticas e Importantes —, corrige bibliotecas críticas do espaço do usuário somente após uma reinicialização única que deixa grande parte da pilha fora de operação e obriga os sistemas a usar o kernel da Oracleantes de aplicar os patches. O resultado é uma aplicação de patches em tempo real que deixa lacunas, impõe tempo de inatividade e, gradualmente, leva seu ambiente para a Oracle.

O KernelCare, da TuxCare, foi desenvolvido para evitar isso. Ele corrige todas as vulnerabilidades do kernel e do espaço do usuário críticas diretamente no sistema, independentemente da distribuição em que o sistema já esteja rodando, por US$ 50 por sistema por ano. A comparação abaixo detalha os pontos em que os dois se diferenciam.

	Oracle Ksplice	KernelCare
Distribuições compatíveis	Oracle Linux (UEK / kernels compatíveis com Red Hat) e Ubuntu; os kernels do RHEL não são suportados	Oracle Linux 6 – 10, Ubuntu, Debian, RHEL, AlmaLinux, Rocky e muitos outros
Vulnerabilidades corrigidas	🟡 CVEs importantes e críticos selecionados	✅ Todas as vulnerabilidades (CVEs), independentemente do nível de gravidade
Arquiteturas compatíveis	x86-64, arm64	x86-64, arm64
Cobertura para o espaço do usuário crítico (OpenSSL, glibc)	🟡 Sim, mas apenas para compilações compatíveis com o Ksplice no Oracle Linux (não no Ubuntu) e com uma reinicialização única	✅ Sim
Vida útil dos patches do kernel	🟡 Termina quando o kernel for removido da lista de produtos com suporte ou quando o Suporte Premier expirar	✅ Praticamente ilimitado
Aplicação de patches em tempo real para sistemas operacionais em fim de vida útil	🟡 Apenas por meio do complemento pago “Oracle Linux Extended Support”, com cobertura limitada exclusivamente a erratas críticas	✅ Oracle Linux 6, 7, além do Ubuntu, RHEL, AlmaLinux e muitos outros
Funcionalidade de reversão sem reinicialização	✅ Sim	✅ Sim
Gerenciamento centralizado com isolamento físico	❌ A opção de hospedagem própria não é mais compatível	✅ Incluído (ePortal)
API disponível	✅ Sim	✅ Sim
Entrega personalizada de emblemas	❌ Indisponível	✅ Totalmente gerenciado
Complementos	–	LibCare, emblemas personalizados
Custo	Suporte Premier do Oracle Linux: US$ 1.399 por par de CPUs por ano (Premier Plus: US$ 2.499)	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.

Poucos ambientes operam com apenas uma distribuição; portanto, a primeira coisa a se perguntar sobre uma ferramenta de aplicação de patches é qual a abrangência que ela oferece. No âmbito do Premier Support, a Ksplice mantém os kernels UEK e RHCK da Oracle, bem como o do Ubuntu. É importante ressaltar que a Oracle não mantém mais os patches da Ksplice para o kernel do RHEL; portanto, o próprio RHEL fica fora do escopo de cobertura da ferramenta.

O KernelCare adota uma abordagem oposta. Ele aplica patches em tempo real a mais de 70 versões de distribuições de forma nativa — RHEL, AlmaLinux, Rocky Linux, Ubuntu, Debian, Oracle Linux, Amazon Linux, CloudLinux e muitas outras —, de modo que uma única ferramenta e um único fluxo de trabalho abrangem um ambiente misto.

O objetivo principal da aplicação de patches em tempo real é corrigir vulnerabilidades rapidamente; portanto, a primeira questão é saber quais delas uma ferramenta realmente corrige. De acordo com nossa própria pesquisa, o Ksplice corrige apenas uma seleção até mesmo das CVEs classificadas como Críticas e Importantes. A Oracle também atribui suas próprias classificações de gravidade, que podem ser inferiores à pontuação que um CVE recebe no National Vulnerability Database. Essas classificações pressupõem configurações padrão; portanto, uma falha que a Oracle considera de menor prioridade ainda pode representar um risco real em determinadas configurações. Sem a disponibilidade de um patch em tempo real, a correção ficará pendente até a próxima atualização do kernel e uma reinicialização do sistema.

O KernelCare elimina as incertezas ao aplicar correções em tempo real a todas as vulnerabilidades (CVEs) do kernel, independentemente da classificação de gravidade, de modo que sua cobertura não dependa 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 a maioria das ferramentas nunca altera as bibliotecas críticas do OpenSSL e da glibc. O Ksplice oferece a aplicação de patches críticos no espaço do usuário, mas apenas para versões de bibliotecas compatíveis com o Ksplice, que ainda exigem uma reinicialização única. Como essas bibliotecas estão na base de quase tudo o que você executa, essa reinicialização pode significar a interrupção de grande parte da sua pilha.

O KernelCare preenche essa lacuna com o LibCare, aplicando patches nas bibliotecas compartilhadas do OpenSSL e da glibc na memória em todas as distribuições compatíveis, sem a necessidade de reiniciar os aplicativos que dependem delas. A aplicação de patches em áreas críticas do espaço do usuário sem tempo de inatividade permite que as equipes cumpram os prazos de correção exigidos pela PCI DSS e pela FedRAMP e atendam aos requisitos de segurança da SOC 2 e da HIPAA em sistemas que não podem ser colocados offline.

Com o Ksplice, a aplicação de patches é válida enquanto o kernel permanecer na lista de manutenção da Oracle e sua assinatura Premier estiver ativa. No momento em que qualquer uma dessas condições expirar — seja quando o kernel sair da lista ou quando a assinatura terminar —, você precisará executar o comando `yum update` e reiniciar o sistema para continuar recebendo as correções.

O KernelCare não impõe prazo de validade para a aplicação de patches. Ele aplica patches em um kernel carregado enquanto você continuar executando-o, sem a necessidade de uma reinicialização forçada para manter a proteção.

É comum que as cargas de trabalho continuem em operação após o término do período de suporte de sua distribuição. Quando esse período termina, as atualizações de segurança do fornecedor são interrompidas, e esses costumam ser justamente os sistemas que você menos pode se dar ao luxo de reiniciar ou reinstalar; é por isso que a aplicação de patches em tempo real é tão importante. O Ksplice continua aplicando patches a uma versão após o término desse período somente se você adquirir o Oracle Linux Extended Support, que limita a cobertura a erratas críticas, tem duração de apenas mais alguns anos e se aplica exclusivamente ao Oracle Linux.

O KernelCare, por outro lado, continua a fornecer patches em tempo real para distribuições em fim de vida, como o Oracle Linux 6 e 7, de modo que os sistemas que você não pode desativar dentro do prazo previsto permaneçam protegidos enquanto você planeja a migração de acordo com seu próprio cronograma.

Em qualquer escala real, a aplicação de patches em tempo real precisa ser gerenciada centralmente, cada vez mais em redes sem acesso à internet. Tanto o Ksplice quanto o KernelCare conseguem aplicar patches em uma rede isolada. A diferença está no gerenciamento. Com o Ksplice, o produto auto-hospedado que centraliza o processo, o Oracle Linux Manager, não tem mais suporte, e seu substituto, o OS Management Hub, precisa permanecer conectado à nuvem da Oracle. Em um ambiente verdadeiramente isolado (air gap), você é obrigado a manter espelhos locais e clientes offline manualmente.

O KernelCare inclui o ePortal, um servidor de patches auto-hospedado que opera dentro da rede isolada, sem custo adicional de licença. Ele oferece feeds, implementações em etapas, implantação controlada e inventário localmente, de modo que a camada de gerenciamento fica dentro do air gap, em vez de na nuvem de um fornecedor.

Alguns ambientes precisam de uma correção que o fornecedor ainda não disponibilizou ou de um patch adaptado à sua própria configuração. O Ksplice não oferece nenhum patch personalizado. Seu catálogo se limita ao que a Oracle disponibiliza para os componentes do Oracle Linux; portanto, qualquer coisa fora desse conjunto simplesmente não está disponível.

A KernelCare oferece patches personalizados totalmente gerenciados, que os engenheiros da TuxCare desenvolvem, testam e mantêm para você, incluindo versões especiais e configurações não padronizadas. Você obtém a correção de que precisa sem ter que arcar com o trabalho e o risco de criar patches em produção internamente.

O KernelCare custa a partir de US$ 50 por sistema por ano para a aplicação de patches em tempo real no kernel e funciona no seu sistema operacional existente, sem a necessidade de assinatura da Oracle nem de migração do kernel. 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 Ksplice, por outro lado, não tem custo adicional, mas depende do Oracle Linux Premier Support, cujo preço é de US$ 1.399 por par de CPUs por ano (Premier Plus: US$ 2.499).

A diferença é mais acentuada quando se considera uma frota inteira. A cobertura completa sem necessidade de reinicialização para 100 sistemas custa cerca de US$ 5.000 por ano com o KernelCare. O mesmo conjunto de sistemas, com o Oracle Linux Premier Support, custa aproximadamente US$ 139.900 por ano — cerca de 28 vezes mais — sem contar o custo de engenharia para migrar sistemas que não são da Oracle para o kernel da Oracle.

Se sua empresa já está totalmente comprometida com o Oracle Linux Premier Support, o Ksplice já vem incluído no pacote, e pode parecer a escolha mais óbvia. O objetivo dessa comparação é mostrar o que esse pacote exige de todos os demais:

• Ele corrige dinamicamente apenas uma seleção das vulnerabilidades, mesmo entre as classificadas como “Críticas” e “Importantes”, deixando o restante para a próxima atualização do kernel e uma reinicialização.
• O RHEL e outros sistemas precisam migrar para o kernel da Oracle.
• A aplicação de patches no espaço do usuário requer compilações de bibliotecas compatíveis com o Ksplice e está restrita ao Oracle Linux.
• A cobertura é válida apenas enquanto você mantiver uma assinatura Premier ativa.
• Cada parte disso leva você cada vez mais fundo na pilha de produtos da Oracle.

O KernelCare foi desenvolvido para eliminar essas restrições. Ele aplica patches continuamente no kernel e no espaço do usuário, independentemente da gravidade e mesmo muito além do fim da vida útil, com patches personalizados totalmente gerenciados e gerenciamento em ambiente isolado incluídos, por uma fração do custo de uma assinatura Premier. Portanto, quer você administre um ambiente misto, uma frota de RHEL que prefira não migrar para o kernel da Oracle ou simplesmente queira evitar um maior aprisionamento tecnológico pela Oracle, o KernelCare é a opção mais abrangente, mais simples e muito mais econômica.

A migração para o KernelCare é simples e não requer migração do sistema operacional. Um único script de inicialização rápida instala o agente, e seus sistemas passam a receber correções contínuas em tempo real no kernel e no espaço do usuário crítico.

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.