Un team di data center che eredita un’infrastruttura in cui SCCM gestisce Windows, Satellite Linux e AWS Systems Manager le istanze cloud non ha necessariamente ereditato un’architettura sbagliata. Ha ereditato tre decisioni distinte, ciascuna delle quali aveva una propria logica nel momento in cui è stata presa. Il problema non sono gli strumenti in sé, ma il costo di coordinamento che si accumula quando tre soluzioni, caratterizzate da cadenze di aggiornamento, console e formati di report differenti, devono essere gestite come se costituissero un unico sistema coerente. In realtà, non lo sono.
Lo stato delle patch di Windows è aggiornato. Linux è in ritardo di due mesi, perché Satellite richiede un coordinamento manuale con ogni team applicativo prima di poter procedere con un aggiornamento del kernel. I software server di terze parti, come il runtime Java sul server applicativo, la versione di Apache Tomcat nello stack middleware e Nginx sui sistemi perimetrali, non dispongono di alcun flusso di lavoro dedicato alle patch, perché nessuno dei tre strumenti è stato progettato per gestirli. Questa lacuna nella copertura non emerge in nessuna delle tre dashboard, poiché ogni strumento segnala esclusivamente ciò che gestisce.
Questo articolo analizza i costi operativi di tale lacuna, illustra l’architettura di una piattaforma consolidata in un ambiente distribuito e spiega come realizzare il deployment senza imporre una migrazione radicale e immediata dagli strumenti esistenti.
Quanto costa davvero coordinare tre strumenti
Utilizzare tre strumenti di patch management non significa dover applicare le patch tre volte. Significa gestire tre flussi di lavoro separati, privi di dati condivisi e di risultati uniformi, che richiedono una riconciliazione manuale ogni volta che serve una visione d’insieme.
Per preparare un report di conformità, rispondere a una richiesta di audit o verificare lo stato delle patch durante la gestione di un incidente, qualcuno deve recuperare le informazioni da tre console differenti e ricostruire manualmente la risposta.
In assenza di automazione degli script prima del deployment, il coordinamento avviene attraverso telefonate, ticket e pianificazioni. Il processo è lento.
L’analisi Total Economic Impact di Forrester relativa al consolidamento del patch management automatizzato ha rilevato che i team passati a un’unica piattaforma hanno recuperato il 95% del tempo precedentemente dedicato all’applicazione manuale delle patch in ambienti cloud. Il recupero di produttività non rappresenta soltanto un argomento economico: misura quanto tempo degli ingegneri venga assorbito da strumenti frammentati, sottraendolo ad altre attività.
La copertura delle applicazioni server di terze parti: la lacuna che nessuno monitora
Nel patch management dei server si tende tradizionalmente a considerare il sistema operativo come la principale superficie di rischio. Un presupposto che da anni non rispecchia più la realtà.
Il runtime Java, il web server, il livello middleware e il connettore del database presentano ciascuno i propri flussi di vulnerabilità CVE, cicli di rilascio delle patch e periodi di esposizione. Log4Shell, per esempio, era una vulnerabilità di una libreria Java, non una vulnerabilità del sistema operativo. Le organizzazioni dotate di processi maturi per l’aggiornamento dei sistemi operativi, ma prive di un flusso di lavoro per il software server di terze parti, non avevano modo di monitorare o correggere questa vulnerabilità attraverso le procedure ordinarie.
SCCM non offre una copertura nativa delle applicazioni server di terze parti. Lo stesso vale per Satellite. Anche la maggior parte degli strumenti di patching cloud-native presenta questa lacuna. Di conseguenza, una parte della superficie di attacco dei server rimane in una sorta di zona franca del patch management nella maggior parte delle imprese.
Patch Manager Plus copre oltre 1.100 applicazioni di terze parti, mettendo a disposizione patch preconfezionate e pretestate, pronte per il deployment. Il catalogo comprende aggiornamenti di sicurezza, aggiornamenti non legati alla sicurezza, service pack, feature pack, definizioni antivirus e aggiornamenti cumulativi (rollup).
La copertura comprende Windows Server e Linux dalla stessa console: un’unica scansione, un solo flusso di deployment e un unico report.
Architettura dei server di distribuzione per ambienti con più data center
Un server centrale di patch management che distribuisce gli aggiornamenti a server collocati in diverse aree geografiche può generare problemi di larghezza di banda. I file delle patch sono voluminosi e trasferirli attraverso collegamenti WAN verso i diversi data center regionali a ogni ciclo di aggiornamento può saturare le connessioni e creare code di deployment, rallentando l’intero processo.
Patch Manager Plus affronta il problema attraverso server di distribuzione (distribution server) installati nelle diverse regioni dei data center.
Il server centrale, situato nel data center principale, gestisce il catalogo delle patch, le policy e la reportistica. I server di distribuzione nelle sedi regionali scaricano le patch una sola volta dal server centrale e le distribuiscono localmente ai server gestiti nella propria area. Il traffico WAN viene così limitato alla sincronizzazione iniziale tra server centrale e server di distribuzione, anziché essere necessario per ogni singolo endpoint gestito durante il deployment.
Lo stesso modello si applica agli ambienti cloud. Patch Manager Plus gestisce server su Azure, AWS, GCP e Oracle Cloud Infrastructure attraverso una console centrale, con la possibilità di distribuire punti di distribuzione specifici per ciascun ambiente cloud.
Le organizzazioni che preferiscono non gestire direttamente l’infrastruttura del server centrale possono scegliere Patch Manager Plus Cloud, la versione SaaS che elimina questo onere mantenendo la stessa struttura di console e reportistica.
Controlli prima e dopo il deployment per i server di produzione
Nella maggior parte delle organizzazioni, i cicli di aggiornamento di Linux arrivano a durare 90 giorni non per ragioni tecniche, ma organizzative.
Prima di riavviare un server, il team dei sistemi deve sapere quali applicazioni vi sono in esecuzione e quali potrebbero essere coinvolte. I responsabili applicativi devono ricevere un preavviso e occorre pianificare le finestre di manutenzione. Senza automazione nel flusso di deployment, ogni riavvio diventa un’attività che richiede coordinamento.
Patch Manager Plus affronta il problema attraverso script configurabili da eseguire prima e dopo il deployment. Prima del riavvio, lo script preliminare arresta le applicazioni interessate. Al termine del riavvio, lo script successivo le riavvia.
Il team IT configura questa procedura una sola volta per ciascun gruppo di server. Da quel momento, il flusso di lavoro viene eseguito senza richiedere un coordinamento manuale a ogni ciclo.
Il portale self-service consente inoltre ai responsabili delle applicazioni di visualizzare le vulnerabilità pertinenti ai propri sistemi e di pianificare il deployment delle patch all’interno delle finestre di manutenzione autorizzate.
Integrazione ITSM e gestione delle modifiche
Negli ambienti di produzione che adottano processi formali di change management, il deployment delle patch deve passare attraverso un comitato di approvazione delle modifiche, il Change Advisory Board (CAB), prima di raggiungere i sistemi di produzione.
Negli ambienti caratterizzati da strumenti di patching frammentati, il problema è spesso l’incoerenza dei processi. Una situazione che emerge chiaramente quando gli auditor verificano la gestione delle modifiche come meccanismo di controllo.
Patch Manager Plus si integra con ServiceDesk Plus e ServiceNow attraverso API e webhook. Quando viene pianificato un deployment, la piattaforma crea automaticamente una richiesta di modifica nel sistema ITSM.
La richiesta comprende:
- La tipologia di modifica, standard o di emergenza.
- L’elenco dei server interessati.
- Il piano di rollback.
- Una sintesi dei rischi e degli impatti.
- I risultati delle scansioni allegate.
Il Change Advisory Board esamina e approva la richiesta attraverso la piattaforma ITSM. Patch Manager Plus riceve l’approvazione e procede con il deployment.
Dopo l’installazione, lo strumento esegue una nuova scansione di tutti i server interessati e registra la percentuale di conformità, le patch mancanti, gli aggiornamenti non riusciti e lo stato dei riavvii.
Questi dati consentono di chiudere la richiesta di modifica. La traccia di audit, dalla scansione al deployment fino alla verifica finale, viene generata direttamente dallo strumento, senza dover assemblare manualmente i risultati provenienti da sistemi differenti.
Migrare da SCCM e Satellite senza un passaggio forzato
La migrazione da un insieme frammentato di strumenti di patching a una piattaforma consolidata non richiede di rimuovere le soluzioni esistenti prima di aver convalidato quella sostitutiva. Patch Manager Plus può essere implementato insieme a SCCM e Satellite, assumendo progressivamente la gestione delle diverse aree dell’infrastruttura.
Il percorso di migrazione si articola in tre fasi.
Fase iniziale: visibilità e reportistica unificate. Patch Manager Plus offre una visione centralizzata e una reportistica unificata, mentre SCCM e Satellite continuano a occuparsi del deployment. Il team ottiene immediatamente una dashboard unica per l’intero parco server, senza rischi per la continuità dei processi di aggiornamento in produzione.
Fase di coesistenza: estensione della copertura. Patch Manager Plus assume il controllo del deployment negli ambienti cloud e per le applicazioni di terze parti, ambiti nei quali gli strumenti esistenti non offrono comunque una copertura adeguata. SCCM continua a gestire Windows on-premise, mentre Satellite mantiene la gestione di Linux on-premise.
Fase di consolidamento: migrazione progressiva. Patch Manager Plus assume la gestione dei deployment di Windows e Linux on-premise, procedendo per regione geografica o data center. SCCM e Satellite vengono dismessi soltanto dopo aver convalidato l’intero ciclo operativo in ciascuna regione.
Non è prevista una data obbligatoria per il passaggio definitivo. La migrazione procede secondo i tempi stabiliti dall’organizzazione.
Dal punto di vista dei cicli di aggiornamento, i risultati documentati nei deployment aziendali indicano il passaggio da cicli di 90 giorni a cicli di 30 giorni per Windows, Linux e applicazioni di terze parti, con automazione completa per tutte e tre le categorie.
Il vero problema è il costo del coordinamento
La questione più importante non riguarda le capacità di SCCM, Satellite o degli strumenti di patching cloud-native. La maggior parte delle imprese ha adottato queste soluzioni per ragioni valide, in momenti diversi della crescita della propria infrastruttura.
Il problema emerge quando decisioni separate devono convergere in un unico processo di aggiornamento, esteso a server on-premise, workload cloud, macchine virtuali e livelli applicativi di terze parti, che nessuno degli strumenti originari era stato progettato per gestire congiuntamente.
Con il tempo, lo sforzo necessario per coordinare strumenti non collegati tra loro, team differenti, finestre di manutenzione e flussi di reportistica può diventare superiore a quello richiesto dall’attività di patching vera e propria.
A quel punto, il consolidamento non consiste più semplicemente nel ridurre il numero di strumenti presenti nell’infrastruttura. Diventa una scelta operativa per ridurre gli oneri di coordinamento, abbreviare i tempi di correzione delle vulnerabilità e realizzare un processo di aggiornamento in grado di scalare in modo coerente sull’intero parco server.
A cura di Hari Prasadh T
Hari è product marketer per la soluzione Unified Endpoint Management and Security di ManageEngine. È appassionato di tecnologie complesse e del modo in cui possono essere rese comprensibili, trasformando concetti tecnici in storie semplici e accessibili.
