KernelCare ePortal per infrastrutture di hosting di grandi dimensioni

Integrazione di KernelCare ePortal nella gestione della flotta

KernelCare ePortal È il componente di gestione e distribuzione gestito autonomamente per gli agenti KernelCare in ambienti Linux di grandi dimensioni. Raggruppa set di patch, feed e chiavi di registrazione in un unico punto controllato. In questo modo, l’amministratore non solo decide se gli host devono ricevere le patch, ma anche da quale fonte locale e secondo quale logica di approvazione ciò avvenga.

Senza l’ePortal, gli agenti si connettono direttamente all’infrastruttura di TuxCare. Questa è solitamente la soluzione più semplice per parchi server di piccole dimensioni, sostanzialmente omogenei e connessi a Internet: non è necessario aggiornare, proteggere e monitorare una piattaforma centrale aggiuntiva. Con l’aumentare del numero di sistemi, tuttavia, questa semplicità diventa uno svantaggio quando sono richieste autorizzazioni tracciabili o uscite di rete limitate.

In una flotta di hosting si trovano spesso server web, server di database, host di virtualizzazione e sistemi di gestione con distribuzioni e serie di kernel diverse. Un elemento centrale Acquisto di patch consente di fornire a questi gruppi tecnici feed e chiavi mirati. ePortal non rappresenta quindi un’alternativa all’agente KernelCare, ma ne amplia la gestione dei set di patch con funzionalità di controllo e distribuzione a livello locale.

Il vantaggio non deriva quindi esclusivamente dal numero di server. Sono determinanti i cicli di patch vincolanti, gli obblighi di verifica e di documentazione, le specifiche di rete, nonché la questione relativa alla possibilità di gestire in modo affidabile un servizio centralizzato. Questi requisiti determinano anche se l’architettura più adeguata sia quella basata su mirroring locale, cache o accesso diretto.

Distinguere tra Live-Patching, KernelCare e LibCare

All'indirizzo Patching in tempo reale L'agente KernelCare verifica regolarmente se sono disponibili set di patch compatibili. Li scarica, li verifica e li installa nel kernel in esecuzione. In questo modo, le correzioni di sicurezza possono essere attivate senza che sia necessario riavviare il kernel. La disponibilità dei set di patch dipende dal kernel installato e dalla distribuzione supportata.

KernelCare indica l'offerta relativa alle patch in tempo reale per il kernel. LibCare va distinto da questo: si tratta di un prodotto aggiuntivo opzionale per determinati componenti dello spazio utente e non è un altro nome per indicare l'applicazione di patch al kernel. ePortal, invece, non applica direttamente le patch al kernel, ma gestisce i set di patch, i feed e la registrazione degli agenti KernelCare in un’installazione aziendale locale.

La precedente denominazione "KernelCare Plus" dovrebbe comparire solo nel contesto della classificazione di documentazione obsoleta. Il produttore ha interrotto la commercializzazione di questo prodotto a partire da marzo 2023, sostituendolo con KernelCare. Ai fini dell'inventario, è quindi importante non associare gli agenti installati, i contratti e la documentazione ai nomi storici dei prodotti con i componenti o le funzionalità attuali.

Il live patching non sostituisce un processo di manutenzione completo. Pianificato Reboot rimangono necessari, ad esempio, per i normali cambi di kernel, gli aggiornamenti hardware e firmware, le modifiche ai driver, gli interventi di configurazione o i casi di malfunzionamento che non possono essere risolti in tempo reale. Un piano operativo dovrebbe quindi combinare la riduzione dei tempi di esposizione grazie ai set di patch con il mantenimento delle finestre di riavvio pianificate, anziché eliminarle senza sostituirle.

Quando la gestione centralizzata delle patch è economicamente vantaggiosa

ePortal è la soluzione ideale quando l’azienda non deve solo distribuire rapidamente le patch, ma deve anche gestirne l’implementazione in modo vincolante. Ciò riguarda, ad esempio, gruppi di approvazione separati per host Canary, staging e produzione, regole restrittive del firewall in uscita o prove relative all’assegnazione di un host a un determinato feed. Anche molti sistemi con piattaforme diverse traggono vantaggio da un’istanza di distribuzione gestita centralmente.

Il valore aggiunto deve giustificare lo sforzo richiesto. Un’istanza di ePortal richiede capacità, aggiornamenti, backup, protezione degli accessi e monitoraggio; in caso di elevata disponibilità, si aggiungono la replica e l’architettura di rete. Per un numero limitato di server simili con accesso a Internet autorizzato, l’accesso diretto tramite l’infrastruttura di TuxCare rimane quindi spesso più semplice. Un numero minore di componenti comporta in questo caso una minore superficie operativa propria.

Dal punto di vista economico, la gestione centralizzata diventa particolarmente importante laddove una simultaneità non pianificata comporterebbe costi elevati: ad esempio nel caso di numerosi server web dei clienti, cluster di database o host di virtualizzazione. Un Processo di rilascio In questo modo è possibile rappresentare contemporaneamente la somiglianza tecnica e il rischio aziendale. I gruppi non dovrebbero essere creati solo in base alla sede, ma dovrebbero tenere conto anche della distribuzione, della serie di kernel, dell'hypervisor, del pannello di controllo, dell'hardware e del profilo del cliente.

Non bisogna però sopravvalutare la copertura di sicurezza. KernelCare fornisce patch in tempo reale per un kernel solo fintantoché il fornitore della distribuzione pubblica aggiornamenti di sicurezza per la serie di kernel in questione. Inoltre, l’applicazione di patch in tempo reale non costituisce una garanzia assoluta della correzione di tutte le vulnerabilità. Lo stato delle patch, il supporto della distribuzione e la manutenzione regolare devono essere verificati separatamente.

La scelta operativa non è quindi genericamente „centralizzato è meglio“. ePortal è utile quando il controllo locale, la distribuzione a più livelli e una tracciabilità affidabile soddisfano requisiti concreti. In assenza di tali requisiti, l’approccio diretto, volutamente semplice, può rivelarsi più solido. Nella fase successiva, il modello di distribuzione desiderato determina il fabbisogno di memoria e le dipendenze esterne.

Scegliere la mirroring e la cache appropriate

La scelta del modello di distribuzione determina il grado di autonomia di una flotta di hosting nel recupero delle patch e la quantità di infrastruttura che deve gestire a tal fine. Nel caso dell’approvvigionamento diretto, gli agenti KernelCare scaricano i set di patch tramite l’infrastruttura TuxCare. ePortal, invece, trasferisce l’approvazione, la conservazione locale e la distribuzione in un’istanza dedicata; può replicare i set di patch come archivio completo o filtrato oppure memorizzarli temporaneamente in base alle esigenze.

Un mirroring completo è utile quando i set di patch già scaricati devono rimanere disponibili localmente anche in caso di interruzione della connessione esterna, oppure quando ciò è richiesto da autorizzazioni interne vincolanti. Un mirroring filtrato limita le dimensioni dell’archivio e il traffico dati alle distribuzioni effettivamente utilizzate. A tal fine, l’inventario deve rilevare in modo affidabile quali serie di kernel e architetture vengono utilizzate dalla flotta; in caso contrario, mancherà proprio quell’archivio nel momento in cui un host ne avrà bisogno.

Il sito Modalità cache consente di risparmiare spazio di archiviazione, ma non è sinonimo di funzionamento completamente isolato. ePortal carica i metadati e, se necessario, recupera i file binari delle patch dalla fonte; secondo la documentazione, i file binari scaricati rimangono nella cache locale per due settimane. Per le reti di agenti isolate, ciò può essere sufficiente, purché ePortal possa utilizzare il percorso upstream consentito.

Un server ePortal funzionante in modalità completamente isolata va valutato separatamente. I nuovi archivi di patch devono quindi essere importati tramite un trasferimento manuale pianificato separatamente. A tal fine, definire la verifica delle fonti, il controllo dell’integrità e della firma, l’autorizzazione dei supporti o della rete, l’ordine di importazione e le responsabilità. Né la replica filtrata né quella completa generano automaticamente questo processo; esse determinano solo quali archivi ePortal conserva localmente.

La pianificazione dello spazio di archiviazione non dovrebbe limitarsi alle dimensioni dell’archivio attuale. TuxCare indica come riferimento per ePortal uno spazio di archiviazione SSD con almeno 100 IOPS e una crescita di circa 4-5 GiB al mese. Queste specifiche del produttore non sostituiscono in alcun modo la pianificazione della capacità: gli obiettivi di ripristino, le implementazioni parallele, le latenze di rete, il numero di varianti del kernel e i requisiti di monitoraggio possono influenzare l’architettura in misura maggiore rispetto alla capacità disponibile su disco.

Creare anelli di patch per le flotte di hosting

Gli anelli di patch consentono di effettuare un’implementazione controllata a partire da un set di patch disponibile a livello centrale. Un piccolo gruppo “canary” riceve per primo l’approvazione, seguito dalla fase di staging, da un gruppo di produzione limitato e infine dall’intera produzione. Ogni anello richiede metriche di monitoraggio predefinite e un responsabile; senza questi criteri, un ritardo si limita a rinviare il rischio, anziché valutarlo.

Per gli anelli di produzione è Stabile il canale previsto. Il canale "Testing" è adatto a un processo di valutazione separato e deliberatamente controllato, poiché include tutti i set di patch disponibili e può quindi contenere set di patch aggiuntivi che non sono ancora stati contrassegnati come "Stable". Secondo la documentazione, il canale "Unstable" è un canale di accesso anticipato e non è raccomandato. Testing e Unstable non devono quindi essere considerati come prova generale di produzione.

I gruppi dovrebbero essere composti in base alla somiglianza tecnica, anziché solo in base all’ubicazione del data center. Sono rilevanti la distribuzione e la serie del kernel, la piattaforma hardware, la virtualizzazione, il pannello di controllo, lo stack del server web e il profilo del cliente. Un host Canary con una serie di kernel diversa o un altro tipo di virtualizzazione riflette solo in modo limitato il comportamento di un sistema di destinazione in produzione. Nel caso dell’hosting condiviso, i profili delle risorse e le configurazioni del CloudLinux LVE Managers in questa valutazione, poiché possono influire sui profili di carico e di errore.

È necessario prestare particolare attenzione alle nuove istanze di ePortal. Secondo le indicazioni del produttore, ePortal verifica ogni dieci minuti la presenza di nuovi set di patch e li scarica, ma non li rende automaticamente disponibili per ogni feed. Quando gli archivi vengono caricati per la prima volta, ai set di patch in essi contenuti viene assegnata la stessa data di pubblicazione. Un ritardo già configurato può quindi comportare che l’intero stock iniziale, una volta scaduto tale ritardo, venga trasferito in un feed aggiornato automaticamente.

Durante la sincronizzazione iniziale, sospendi quindi l’aggiornamento automatico dei feed di produzione e la relativa assegnazione delle chiavi di produzione. Carica completamente il dato iniziale, verifica sia questo che la configurazione dei feed e solo successivamente assegna le chiavi in modo controllato agli anelli previsti oppure attiva il loro aggiornamento automatico. La logica di ritardo viene poi utilizzata per i set di patch in arrivo; essa non separa in modo affidabile il primo set storico di una nuova istanza.

Separare feed, chiavi e mandanti

I feed rappresentano l'aspetto tecnico degli anelli di rollout: collegano il canale di patch e la logica di ritardo a un gruppo di sistemi. Le chiavi di registrazione possono essere associate ai feed e dotate di limiti di server. In questo modo, un operatore può, ad esempio, fornire a piattaforme interne, offerte di server gestiti e ambienti clienti separati percorsi di autorizzazione diversi, senza dover modificare singolarmente la configurazione degli agenti su ogni host.

Tale classificazione non costituisce tuttavia un limite di sicurezza completo. La funzione opzionale Unità aziendali Supporta il multi-tenancy nell'ePortal, ma non sostituisce né la segmentazione della rete, né un modello di autorizzazioni, né competenze amministrative separate. Anche la registrazione degli eventi, la gestione delle chiavi segrete e la verifica di chi è autorizzato a creare chiavi o modificare i feed devono essere pianificate indipendentemente dalla funzionalità del prodotto e controllate regolarmente.

Negli ambienti multi-cliente, la separazione tra la gestione delle patch e il resto dell’isolamento dell’hosting è particolarmente importante. Una chiave può limitare l’assegnazione prevista dei feed e il numero di server registrabili, ma non impedisce gli accessi incrociati in altri componenti dell’infrastruttura. L’isolamento dei processi e del file system rimangono compiti a sé stanti; a tal proposito, l’articolo su CloudLinux SecureLVE a livello di account e siti web.

A partire dalla versione 2.14-1 di ePortal, è possibile utilizzare le chiavi API per l'API pubblica in alternativa all'autenticazione di base. La gestione di ePortal consente, tra le altre cose, di revocare singolarmente le chiavi API e di impostare una data di scadenza opzionale. Ciò facilita la definizione di autorizzazioni separate per le integrazioni con il CMDB o l'automazione della configurazione, a condizione che i diritti dell'account utente associato siano deliberatamente limitati.

Archivia i token come “Secret” in un sistema di gestione dei Secret, non nei playbook, nelle immagini, nelle cronologie della shell o nei ticket. Si tratta di una misura di protezione operativa e non di una proprietà imposta automaticamente da ePortal. Un processo pratico assegna a ogni chiave un proprietario, uno scopo, i prodotti consentiti, un limite di server e una data di rotazione.

Le chiavi API dovrebbero essere revocate in modo mirato in caso di cambio di sistema, cambio di ruolo o quando l'accesso all'automazione non è più necessario. Le chiavi di registrazione vanno gestite in modo diverso: secondo la documentazione, la rimozione di una chiave di questo tipo comporta anche la rimozione da ePortal di tutti i server registrati sotto di essa. Pertanto, prima di procedere alla cancellazione, pianifica la migrazione verso una nuova chiave o la nuova registrazione degli host interessati e verifica successivamente la loro assegnazione ai feed e lo stato di check-in.

Gestione della replica e del protocollo TLS in modo affidabile

Per un Distribuzione di patch ad alta disponibilità Vengono combinati più nodi ePortal in modo tale che gli agenti KernelCare si colleghino a un nome DNS di cluster comune o a un bilanciatore di carico HTTP. Per le attività amministrative, invece, si utilizza un endpoint amministrativo controllato e specifico per ogni nodo. Secondo il produttore, l’endpoint comune del cluster non deve essere utilizzato per le operazioni nell’interfaccia di amministrazione di ePortal.

Prima della messa in produzione, l’architettura non dovrebbe considerare solo il guasto di un server ePortal. Sono rilevanti anche la risoluzione DNS, il bilanciatore di carico, i certificati, lo spazio di archiviazione per gli archivi delle patch, la connessione alla fonte delle patch e l’accessibilità da ogni segmento di rete. Un secondo nodo privo di un sistema coordinato di monitoraggio della rete e del funzionamento migliora la disponibilità solo in misura limitata; in caso di errore, può addirittura nascondere condizioni anomale.

I nodi sincronizzano le modifiche tramite replica. Questa sincronizzazione non è necessariamente visibile immediatamente. Soprattutto nel caso del Round-Robin, un agente appena registrato può raggiungere il primo nodo per la registrazione e, subito dopo, un nodo non ancora sincronizzato per l’aggiornamento. Le automazioni dovrebbero quindi prevedere un breve intervallo di attesa o una logica di riprova con un numero limitato di tentativi, anziché considerare il recupero immediato della patch come uno stato finale affidabile.

Anche le interruzioni prolungate rientrano nello scenario di errore. Secondo la documentazione, i protocolli di replica vengono conservati per sette giorni; se un nodo rimane disconnesso più a lungo, potrebbe perdere alcune modifiche. Il Ritardo di replica Si tratta quindi di uno stato operativo, non semplicemente di un valore diagnostico. In caso di malfunzionamenti di rete, verifica quindi le assegnazioni dei feed, l'inventario delle chiavi e l'archivio delle patch sul nodo che si sta ripristinando, prima che riprenda a gestire regolarmente le richieste degli agenti.

La replica avviene tramite HTTP. Senza un’adeguata protezione TLS, i dati di replica vengono quindi trasmessi in chiaro. Segmenta questo traffico dati almeno in una rete affidabile oppure configura il TLS in modo adeguato all’architettura. Per gli endpoint degli agenti accessibili dall'esterno o tra reti diverse, una catena di certificati verificabile è una componente fondamentale della Terminazione TLS; la disattivazione della verifica dei certificati non rappresenta una soluzione duratura accettabile.

Se è presente un proxy inverso a monte di ePortal, è necessario configurare i nomi host consentiti affinché ePortal limiti le richieste relative all’header host. Il proxy deve inoltre inoltrare correttamente l’header host originale e il campo X-Forwarded-Proto. In caso contrario, potrebbero verificarsi URL esterni errati, problemi di reindirizzamento o una valutazione errata del protocollo utilizzato. La configurazione di queste intestazioni dovrebbe quindi far parte di ogni modifica al proxy e del relativo collaudo.

Implementare registrazioni, backup e monitoraggio

Il live patching controllabile richiede verifiche periodiche, non solo un’installazione iniziale riuscita. Registra almeno l’assegnazione del feed di ogni host, l’ultimo check-in dell’agente, lo stato delle patch segnalato e lo stato delle chiavi di registrazione. Integra questi dati con i team responsabili e una decisione di approvazione tracciabile. In questo modo, in caso di segnalazione di sicurezza, è possibile determinare in modo mirato quale gruppo utilizzi quale canale di distribuzione.

Altri controlli fissi riguardano la crescita dello spazio di archiviazione, lo spazio libero per gli archivi, lo stato della replica e la rotazione o la revoca delle chiavi non più necessarie. Le chiavi API sono più adatte alle richieste automatizzate rispetto alle password amministrative condivise, poiché possono essere gestite singolarmente, revocate e, facoltativamente, dotate di una data di scadenza. Come misura di protezione aziendale, conservale in un sistema di gestione dei segreti, non in immagini, playbook o ticket.

Per un cluster esistente, la seguente chiamata di verifica non distruttiva costituisce un elemento adeguato per il monitoraggio o per un controllo di integrità pianificato. Fornisce uno stato sintetico leggibile dal sistema, compreso il ritardo di replica. In caso di problema, la chiamata termina con il codice di uscita 1; il monitoraggio dovrebbe segnalare questo stato, ma individuare la causa in modo più preciso sulla base dei dati relativi ai nodi e alla rete.

kc.eportal replication --short-status

ePortal distingue tra un’operazione di archiviazione di backup dei dati e un semplice backup del database. La sintassi completa del comando è la seguente: kc.eportal backup <path_to_archive>; crea un archivio di backup che include i file del set di patch. Con kc.eportal backup-db <path_to_backup> In questo modo, invece, si eseguono il backup solo dei database senza i file del set di patch. Questo secondo metodo è adatto per i dati di configurazione e quelli del server, ma non per l'archiviazione locale delle patch.

Questi backup dell'ePortal non includono automaticamente l'intero ambiente. La configurazione del sistema operativo, quella del proxy inverso e del bilanciatore di carico, i certificati TLS e le chiavi private, le impostazioni DNS, nonché le configurazioni esterne relative al firewall o alla gestione dei segreti richiedono regole di backup e ripristino specifiche. Per ogni tipo di backup, definisci lo scopo, il periodo di conservazione, la posizione di archiviazione e la procedura di ripristino da seguire.

In caso di ripristino, è necessario arrestare il servizio ePortal. Pianifica questa interruzione del servizio, informa, se necessario, i team operativi interessati e verifica successivamente in modo mirato la coerenza dei dati e l'accessibilità per gli agenti. Un backup è considerato valido solo dopo una pianificazione controllata Ripristino come affidabile. In questo contesto, un test non deve modificare inavvertitamente i feed produttivi o le assegnazioni delle chiavi.

Valutare i sintomi di malfunzionamento e prendere decisioni operative

Se le patch attese non vengono rilasciate, occorre innanzitutto distinguere tra mancata disponibilità, mancato download e mancata approvazione. Verifica la versione installata dell’agente e dell’ePortal, le chiavi e i feed associati, la distribuzione corretta compresa la serie del kernel, nonché la connessione alla fonte delle patch. Una patch può inoltre mancare se la serie di kernel in questione non riceve più aggiornamenti di sicurezza dal fornitore della distribuzione; il live patching non supera questo limite.

Le note storiche del produttore relative a versioni precedenti dei componenti non devono essere interpretate come specifiche di versione definitive. Una nota del dicembre 2025 riguardava, tra l’altro, KernelCare-Agent 3.x ed ePortal 2.20 nel contesto di un nuovo formato di patch firmato. Prima di effettuare gli aggiornamenti, verifica quindi la versione attuale Matrice di compatibilità, le versioni effettivamente installate e l'ordine di aggiornamento approvato internamente.

In modalità cache, un errore di cache (cache miss) in presenza di un accesso esterno limitato può ritardare il download della patch, poiché il file binario necessario non è ancora disponibile localmente. Ciò non costituisce una prova di un funzionamento completamente isolato. Per le zone soggette a restrizioni, definisci quali connessioni sono consentite, come vengono trasferiti gli archivi mancanti e chi è responsabile dell’autorizzazione, dell’integrità e della tempistica di tale trasferimento.

Un altro scenario di errore è un rollout inaspettatamente esteso dopo il primo download degli archivi delle patch su una nuova istanza. Poiché gli archivi caricati per la prima volta appaiono contemporaneamente come nuovi per la logica di ritardo, un ritardo impostato in precedenza non protegge in modo affidabile da una distribuzione simultanea. Sospendi gli aggiornamenti automatici dei feed e le mappature delle chiavi in produzione durante la sincronizzazione iniziale, verifica lo stato iniziale e solo successivamente attiva gli anelli di produzione in modo controllato.

I ritardi nella replica a seguito di un'interruzione prolungata del nodo e i reverse proxy difettosi richiedono misure diverse: i primi richiedono un allineamento dello stato del nodo, i secondi una verifica del TLS, dei nomi host consentiti e delle intestazioni inoltrate. Entrambi i casi devono essere inseriti in runbook con una chiara procedura di escalation. Un riavvio generico non risolve né la mancanza di dati né un limite di fiducia errato.

ePortal è particolarmente utile quando sono effettivamente richiesti anelli di patch, distribuzione locale, uscite di rete controllate o autorizzazioni verificabili. Per un parco server di piccole dimensioni, omogeneo e connesso a Internet, spesso risulta più semplice ricorrere direttamente all’infrastruttura di TuxCare. La decisione dovrebbe quindi valutare l’onere operativo aggiuntivo rispetto a specifici obblighi di controllo e di rendicontazione, non solo in relazione al numero di server.