KernelCare ePortal para infraestruturas de alojamento de maior dimensão

Integrar o KernelCare ePortal na gestão de frotas

KernelCare ePortal é o componente de gestão e distribuição gerido pelo próprio utilizador para os agentes KernelCare em ambientes Linux de grande dimensão. Reúne conjuntos de patches, feeds e chaves de registo num único local controlado. Desta forma, o operador decide não só se os anfitriões devem receber patches, mas também a partir de que fonte local e de acordo com que lógica de aprovação isso ocorre.

Sem o ePortal, os agentes contactam diretamente a infraestrutura da TuxCare. Esta é, na maioria das vezes, a forma mais simples para parques de servidores pequenos, bastante homogéneos e com acesso à Internet: não há nenhuma plataforma central adicional para atualizar, proteger e monitorizar. No entanto, com o aumento do número de sistemas, essa simplicidade torna-se uma desvantagem quando são necessárias autorizações rastreáveis ou saídas de rede limitadas.

Numa frota de alojamento, é frequente que coexistam servidores Web, servidores de bases de dados, hosts de virtualização e sistemas de gestão com diferentes distribuições e séries de kernels. Um elemento central Aquisição de patches permite fornecer a estes grupos técnicos feeds e chaves adequados de forma específica. Assim, o ePortal não é uma alternativa ao agente KernelCare, mas sim amplia a sua capacidade de obtenção de conjuntos de patches, acrescentando controlo e distribuição locais.

Consequentemente, o benefício não decorre apenas do número de servidores. São determinantes os ciclos de atualizações obrigatórios, as obrigações de verificação e comprovação, as especificações de rede, bem como a questão de saber se um serviço central pode, por si só, ser operado de forma fiável. Estes requisitos determinam também se a arquitetura adequada é o espelhamento local, a cache ou o acesso direto.

Distinguir o Live-Patching, o KernelCare e o LibCare

Em Aplicação de patches em direto O agente KernelCare verifica regularmente se existem conjuntos de patches adequados disponíveis. Este descarrega-os, verifica-os e instala-os no kernel em execução. Desta forma, as correções de segurança podem ser ativadas sem que seja necessário reiniciar o kernel para este passo. Os conjuntos de patches aplicáveis dependem do kernel instalado e da distribuição suportada.

KernelCare refere-se ao serviço de patches em tempo real para o kernel. O LibCare deve ser distinguido deste: trata-se de um produto adicional opcional para determinados componentes do espaço do utilizador e não é outro nome para a aplicação de patches no kernel. O ePortal, por sua vez, não aplica patches diretamente no kernel, mas gere conjuntos de patches, feeds e o registo dos agentes do KernelCare numa instalação empresarial local.

A designação anterior «KernelCare Plus» só deve aparecer na classificação de documentação mais antiga. O fabricante descontinuou este produto em março de 2023 e substituiu-o pelo KernelCare. Por isso, para a realização de inventários, é importante não equiparar os agentes instalados, os contratos e a documentação, com base em nomes históricos de produtos, aos componentes ou funcionalidades atuais.

A aplicação de correções em tempo real não substitui um processo de manutenção completo. Programadas Reinícios continuam a ser necessárias, por exemplo, para mudanças regulares do kernel, atualizações de hardware e firmware, alterações de controladores, trabalhos de configuração ou situações de erro que não possam ser resolvidas em tempo real. Um plano operacional deve, por isso, combinar a exposição reduzida através de conjuntos de patches com janelas de reinício que continuem a ser planeadas, em vez de as eliminar sem substituição.

Quando a gestão centralizada de patches é economicamente viável

O ePortal é adequado quando a empresa não só precisa de distribuir patches rapidamente, mas também de controlar de forma vinculativa a sua implementação. Isto aplica-se, por exemplo, a grupos de aprovação separados para hosts Canary, ambiente de teste e produção, regras restritivas de firewall de saída ou registos que indiquem qual o host que estava atribuído a cada feed. Muitos sistemas com plataformas diferentes também beneficiam de uma instância de distribuição gerida centralmente.

O benefício adicional tem de justificar o esforço envolvido. Uma instância do ePortal requer capacidade, atualizações, cópias de segurança, proteção de acesso e monitorização; no caso de alta disponibilidade, acrescentam-se ainda a replicação e a arquitetura de rede. Para um número reduzido de servidores homogéneos com acesso à Internet autorizado, o acesso direto através da infraestrutura da TuxCare continua, por isso, a ser frequentemente mais simples. Menos componentes significam, nesse caso, uma área de operação própria mais reduzida.

Do ponto de vista económico, o controlo centralizado revela-se particularmente vantajoso nos casos em que a simultaneidade não planeada seria dispendiosa: por exemplo, no caso de muitos servidores web de clientes, clusters de bases de dados ou anfitriões de virtualização. Um Processo de libertação pode, assim, refletir em conjunto a semelhança técnica e o risco comercial. Os grupos não devem ser criados apenas com base na localização, mas também devem ter em conta a distribuição, a série do kernel, o hipervisor, o painel de controlo, o hardware e o perfil do cliente.

A cobertura de segurança não deve, contudo, ser sobrestimada. A KernelCare só disponibiliza, em princípio, patches em tempo real para um kernel enquanto o fornecedor da distribuição publicar atualizações de segurança para a série de kernels em questão. Além disso, a aplicação de patches em tempo real não constitui uma garantia geral de que todas as vulnerabilidades tenham sido corrigidas. O estado das correções, o suporte da distribuição e a manutenção regular devem continuar a ser verificados separadamente.

A decisão operacional não se resume, portanto, a uma regra geral de que „centralizado é melhor“. O ePortal faz sentido quando o controlo local, a distribuição por níveis e a rastreabilidade fiável satisfazem requisitos concretos. Na ausência desses requisitos, o acesso direto, deliberadamente simples, pode revelar-se mais robusto. Na etapa seguinte, o modelo de disponibilização pretendido determina as necessidades de armazenamento e as dependências externas.

Selecionar o espelhamento e a cache adequados

A escolha do modelo de distribuição determina o grau de independência de uma frota de alojamento na obtenção de patches e a quantidade de infraestrutura que esta tem de gerir para o efeito. No caso do acesso direto, os agentes do KernelCare descarregam conjuntos de patches através da infraestrutura da TuxCare. Por outro lado, o ePortal transfere a aprovação, o armazenamento local e a distribuição para uma instância própria; pode espelhar conjuntos de patches como arquivos completos ou filtrados, ou armazená-los temporariamente de acordo com as necessidades.

Um espelhamento completo faz sentido quando os conjuntos de patches já transferidos têm de permanecer disponíveis localmente, mesmo em caso de interrupção da ligação externa, ou quando as aprovações internas obrigatórias assim o exigirem. Um espelhamento filtrado limita o tamanho do arquivo e o tráfego de dados às distribuições efetivamente utilizadas. Para tal, o inventário tem de registar de forma fiável quais as séries de kernels e arquiteturas que a frota utiliza; caso contrário, faltará um arquivo precisamente quando um anfitrião precisar dele.

O Modo de cache poupa espaço de armazenamento, mas não é sinónimo de um funcionamento totalmente isolado. O ePortal carrega metadados e obtém dados binários de patches da fonte, quando necessário; de acordo com a documentação, os dados binários descarregados permanecem no cache local durante duas semanas. Para redes de agentes isoladas, isso pode ser suficiente, desde que o ePortal possa utilizar o caminho de upstream autorizado.

Um servidor ePortal que funcione num ambiente totalmente isolado deve ser avaliado separadamente. Os novos arquivos de patches terão então de ser introduzidos através de uma transferência manual planeada separadamente. Para tal, defina a verificação da origem, o controlo de integridade e de assinatura, a partilha de suportes ou de rede, a ordem de importação e as responsabilidades. Nem o espelhamento filtrado nem o espelhamento completo geram este processo automaticamente; determinam apenas quais os arquivos que o ePortal mantém localmente.

O planeamento do armazenamento não deve limitar-se à dimensão do arquivo atual. A TuxCare indica, como orientação para o ePortal, armazenamento SSD com, pelo menos, 100 IOPS, bem como um crescimento de cerca de 4 a 5 GiB por mês. Estas especificações do fabricante não substituem o planeamento de capacidade: os objetivos de recuperação, as implementações paralelas, as latências de rede, o número de variantes do kernel e os requisitos de monitorização podem influenciar a arquitetura de forma mais significativa do que a capacidade livre em disco.

Criar anéis de patch para frotas de alojamento

Os anéis de patch permitem uma implementação controlada a partir de um conjunto de patches disponível centralmente. Um pequeno grupo «canary» recebe a aprovação em primeiro lugar, seguido da fase de teste, de um grupo de produção limitado e, por fim, da produção em grande escala. Cada anel necessita de parâmetros de monitorização definidos antecipadamente e de um responsável; sem estes critérios, um adiamento apenas adia o risco, em vez de o avaliar.

No que diz respeito aos ciclos de produção, Estável o canal previsto. O Testing é adequado para um processo de avaliação separado e deliberadamente controlado, uma vez que este canal inclui todos os conjuntos de patches disponíveis e, por isso, pode conter conjuntos de patches adicionais que ainda não foram marcados como Stable. De acordo com a documentação, o Unstable é um canal de acesso antecipado e não é recomendado. Por conseguinte, os canais Testing e Unstable não devem ser considerados como prova geral de produção.

Os anéis devem ser agrupados com base na semelhança técnica, em vez de apenas na localização do centro de dados. São relevantes a distribuição e a série do kernel, a plataforma de hardware, a virtualização, o painel de controlo, a pilha do servidor Web e o perfil do cliente. Um host «canary» com uma série de kernel diferente ou outro tipo de virtualização abrange apenas de forma limitada o comportamento de um sistema de destino em produção. No caso da hospedagem partilhada, os perfis de recursos e as configurações do Gestores do CloudLinux LVE nesta avaliação, uma vez que podem influenciar os padrões de carga e de falhas.

É necessário ter especial cuidado com as novas instâncias do ePortal. De acordo com as indicações do fabricante, o ePortal verifica a cada dez minutos se existem novos conjuntos de patches e descarrega-os, mas não os disponibiliza automaticamente em todos os feeds. Quando os arquivos são carregados pela primeira vez, os conjuntos de patches neles contidos recebem a mesma data de publicação. Por conseguinte, um atraso já configurado pode fazer com que todo o conjunto inicial seja transferido para um feed atualizado automaticamente após o seu término.

Por isso, durante a sincronização inicial, suspenda a atualização automática dos feeds produtivos e a respetiva atribuição de chaves produtivas. Carregue o conjunto inicial na íntegra, verifique-o, bem como a configuração do feed, e só depois atribua as chaves de forma controlada aos anéis previstos ou ative a sua atualização automática. A lógica de atraso serve, posteriormente, para conjuntos de patches recém-chegados; não separa de forma fiável o conjunto inicial histórico de uma nova instância.

Separar feeds, chaves e clientes

Os feeds representam a vertente técnica dos anéis de implementação: ligam o canal de patch e a lógica de atraso a um grupo de sistemas. É possível associar chaves de registo aos feeds e definir limites de servidor para as mesmas. Desta forma, um operador pode, por exemplo, fornecer percursos de lançamento distintos a plataformas internas, ofertas de servidores geridos e ambientes de clientes separados, sem ter de alterar individualmente a configuração do agente em cada anfitrião.

No entanto, esta atribuição não constitui um limite de segurança completo. A função opcional Unidades de Negócio suporta a multilocação no ePortal, mas não substitui nem a segmentação de rede, nem um modelo de autorizações, nem as responsabilidades administrativas separadas. Também o registo em log, a gestão de segredos e a verificação de quem está autorizado a criar chaves ou a alterar feeds têm de ser planeados e controlados regularmente, independentemente da funcionalidade do produto.

Em ambientes de clientes, a separação entre a gestão de patches e o restante isolamento de alojamento é particularmente importante. Uma chave pode limitar a atribuição pretendida de feeds e o número de servidores registáveis, mas não impede o acesso cruzado noutros componentes da infraestrutura. O isolamento de processos e do sistema de ficheiros continuam a ser tarefas distintas; a este respeito, o artigo sobre CloudLinux SecureLVE o nível das contas e dos sites.

A partir do ePortal 2.14-1, é possível utilizar chaves API para a API pública como alternativa à autenticação básica. A gestão do ePortal permite, entre outras coisas, que as chaves API sejam revogadas individualmente e que tenham uma data de validade opcional. Isto facilita a concessão de autorizações distintas para ligações à CMDB ou para a automatização da configuração, desde que os direitos da conta de utilizador correspondente sejam deliberadamente limitados.

Armazene os tokens como segredos num sistema de gestão de segredos, e não em playbooks, imagens, históricos de shell ou tickets. Trata-se de uma medida de proteção operacional e não de uma característica imposta automaticamente pelo ePortal. Um processo prático atribui a cada chave um proprietário, uma finalidade, produtos autorizados, um limite de servidores e uma data de rotação.

As chaves API devem ser revogadas de forma específica em caso de mudança de sistema, mudança de função ou quando o acesso à automatização já não for necessário. As chaves de registo devem ser tratadas de forma diferente: de acordo com a documentação, a remoção de uma dessas chaves elimina também todos os servidores registados sob a mesma do ePortal. Por isso, antes de a eliminar, planeie a migração para uma nova chave ou o novo registo dos hosts em questão e, em seguida, verifique a sua atribuição de feeds, bem como o estado de check-in.

Operar a replicação e o TLS de forma robusta

Para um distribuição de patches de alta disponibilidade Vários nós do ePortal são combinados de forma a que os agentes do KernelCare acedam a um nome DNS comum do cluster ou a um equilibrador de carga HTTP. Para tarefas administrativas, por outro lado, utiliza-se um ponto de extremidade de administração controlado e específico de cada nó. De acordo com o fabricante, o ponto de extremidade comum do cluster não deve ser utilizado para operações na interface de administração do ePortal.

Antes da entrada em produção, a arquitetura não deve considerar apenas a falha de um servidor ePortal. São também relevantes a resolução de DNS, o balanceador de carga, os certificados, o armazenamento de arquivos de patches, a ligação à fonte de patches e a acessibilidade a partir de qualquer segmento de rede. Um segundo nó sem monitorização de rede e de funcionamento coordenada melhora a disponibilidade apenas de forma limitada; em caso de falha, pode até ocultar estados anormais.

Os nós sincronizam as alterações através da replicação. Esta sincronização nem sempre é visível de imediato. Especialmente no método Round-Robin, um agente que acabou de se registar pode aceder primeiro ao nó para o registo e, imediatamente a seguir, a um nó ainda não sincronizado para a atualização. Por isso, as automatizações devem prever um breve período de espera ou uma lógica de nova tentativa com um número limitado de repetições, em vez de considerarem uma obtenção de patch imediatamente a seguir como um estado final fiável.

As interrupções mais prolongadas também fazem parte do cenário de falha. De acordo com a documentação, os protocolos de replicação são mantidos durante sete dias; se um nó permanecer desligado por mais tempo, poderá deixar de registar algumas alterações. O Atraso na replicação Trata-se, portanto, de um estado operacional e não apenas de um valor de diagnóstico. Após falhas na rede, deve, por isso, verificar as atribuições de feeds, o conjunto de chaves e o arquivo de patches no nó que está a regressar, antes de este voltar a responder normalmente às solicitações dos agentes.

A replicação é efetuada através de HTTP. Sem uma proteção TLS adequada, os dados de replicação são, portanto, transmitidos sem encriptação. Segmente este tráfego de dados, no mínimo, para uma rede de confiança ou implemente o TLS de forma adequada à arquitetura. Para pontos finais de agentes acessíveis externamente ou entre redes, uma cadeia de certificados verificável constitui uma componente importante da Terminação TLS; a desativação da verificação de certificados não constitui uma solução duradoura aceitável.

Se existir um proxy reverso à frente do ePortal, é necessário configurar os nomes de host autorizados para que o ePortal limite os pedidos de cabeçalho de host. Além disso, o proxy deve reencaminhar corretamente o cabeçalho de host original, bem como o X-Forwarded-Proto. Caso contrário, podem ocorrer URLs externas incorretas, problemas de redirecionamento ou uma identificação errada do protocolo utilizado. Por conseguinte, esta configuração dos cabeçalhos deve fazer parte de qualquer alteração no proxy e da respetiva aceitação.

Implementar registos, cópias de segurança e monitorização

A aplicação de patches em tempo real controlável requer comprovações recorrentes, e não apenas uma instalação inicial bem-sucedida. Registe, no mínimo, a atribuição de feed de cada host, o último check-in do agente, o estado de atualização relatado e o estado das chaves de registo. Complemente estes dados com as equipas responsáveis e uma decisão de aprovação rastreável. Desta forma, em caso de um alarme de segurança, é possível determinar de forma específica qual o grupo que utiliza cada via de implementação.

Outros controlos fixos dizem respeito ao crescimento do espaço de armazenamento, ao espaço livre para arquivos, ao estado da replicação e à rotação ou revogação de chaves que já não são necessárias. As chaves API são mais adequadas para consultas automatizadas do que as palavras-passe de administrador partilhadas, uma vez que podem ser geridas individualmente, revogadas e, opcionalmente, dotadas de uma data de validade. Guarde-as num sistema de gestão de segredos como medida de proteção operacional, e não em imagens, manuais de procedimentos ou tickets.

Para um cluster existente, a seguinte chamada de verificação, que não altera nada, constitui um componente adequado para monitorização ou para uma verificação de integridade planeada. Fornece um estado resumido legível por máquina, incluindo o atraso na replicação. Em caso de problema, a chamada termina com o código de saída 1; o monitorização deve alertar para esta situação, mas deve também identificar a causa com base nos dados dos nós e da rede.

kc.eportal replication --short-status

O ePortal distingue entre um processo de arquivamento de cópia de segurança de dados e uma cópia de segurança apenas da base de dados. A sintaxe completa do comando é a seguinte: kc.eportal backup <path_to_archive>; cria um arquivo de cópia de segurança que inclui os ficheiros do conjunto de patches. Com kc.eportal backup-db <path_to_backup> Por outro lado, se apenas fizer o backup das bases de dados sem os ficheiros do conjunto de patches. Esta segunda opção é adequada para dados de configuração e do servidor, mas não para o arquivo local de patches.

Estas cópias de segurança do ePortal não abrangem automaticamente todo o ambiente. A configuração do sistema operativo, a configuração do proxy inverso e do balanceador de carga, os certificados TLS e as chaves privadas, as definições de DNS, bem como as configurações externas de firewall ou de gestão de segredos, requerem regras próprias de cópia de segurança e recuperação. Defina, para cada tipo de cópia de segurança, a finalidade, o período de retenção, o local de armazenamento e o procedimento de recuperação responsável.

Durante uma restauração, o serviço ePortal tem de ser interrompido. Planeie esta interrupção do serviço, informe, se for caso disso, as equipas operacionais afetadas e, em seguida, verifique de forma específica a consistência dos dados, bem como a acessibilidade para os agentes. Uma cópia de segurança só é válida após uma interrupção planeada e controlada Restaurar como resistente. Nesse contexto, um teste não deve alterar inadvertidamente feeds produtivos ou atribuições de chaves.

Avaliar os padrões de falha e tomar decisões operacionais

Caso os patches esperados não sejam disponibilizados, deve-se, em primeiro lugar, distinguir entre falta de disponibilidade, falta de descarregamento e falta de aprovação. Verifique a versão instalada do agente e do ePortal, a chave e o feed atribuídos, a distribuição adequada, incluindo a série do kernel, bem como a ligação à fonte do patch. Além disso, uma correção pode estar em falta se a série de kernels em questão já não receber atualizações de segurança do fornecedor da distribuição; a aplicação de correções em tempo real não elimina esta limitação.

As notas históricas do fabricante relativas a versões mais antigas de componentes não devem ser interpretadas como especificações de versão definitivas. Uma nota de dezembro de 2025 referia-se, entre outros, ao KernelCare-Agent 3.x e ao ePortal 2.20 no contexto de um novo formato de patch assinado. Por isso, antes de efetuar atualizações, verifica a versão atual Matriz de compatibilidade, as versões efetivamente instaladas e a ordem de atualização aprovada internamente.

No modo de cache, uma falha de cache com acesso externo restrito pode atrasar a obtenção do patch, uma vez que o ficheiro binário necessário ainda não se encontra localmente. Isto não constitui prova de um funcionamento totalmente isolado. Para zonas restritivas, defina quais as ligações permitidas, como serão transferidos os arquivos em falta e quem é responsável pela autorização, integridade e momento dessa transferência.

Outro cenário de erro é uma implementação inesperadamente ampla após o primeiro download de arquivos de patches numa nova instância. Uma vez que os arquivos carregados pela primeira vez aparecem simultaneamente na lógica de atraso, um atraso definido previamente não protege de forma fiável contra uma implementação conjunta. Retém as atualizações automáticas dos feeds e as atribuições de chaves em ambiente de produção durante a sincronização inicial, verifica o inventário inicial e só depois ativa os anéis de produção de forma controlada.

As lacunas de replicação após uma interrupção prolongada de um nó e os proxies reversos com falhas exigem medidas diferentes: as primeiras requerem uma sincronização do estado do nó; as segundas, uma verificação do TLS, dos nomes de host autorizados e dos cabeçalhos reencaminhados. Ambos os casos devem ser incluídos em manuais de intervenção com um processo de escalamento claro. Um reinício generalizado não resolve nem a falta de dados nem um limite de confiança incorreto.

O ePortal é particularmente útil quando são efetivamente necessários ciclos de atualizações, distribuição local, saídas de rede controladas ou autorizações verificáveis. Para um conjunto de servidores pequeno, homogéneo e com acesso à Internet, o acesso direto através da infraestrutura da TuxCare é, muitas vezes, mais simples. A decisão deve, portanto, ponderar o esforço operacional adicional em relação às obrigações concretas de controlo e comprovação, e não apenas em relação ao número de servidores.