Esperto a tutto tondo: applicazione di patch a macchine virtuali inattive
L'utilizzo di Microsoft Offline Virtual Machine Servicing Tool per applicare patch a macchine virtuali inattive rappresenta un'ottima procedura per prepararle all'attivazione evitando problemi di patch scadute.
Di Greg Shields
Odiate applicare patch? Anche io. L'applicazione di patch si è sempre rivelata un'attività difficile, resa ancora più seccante dal fatto che non implica alcun vantaggio aziendale. Beh, almeno nessun valore aziendale diverso dalla consapevolezza del fatto che si stanno evitando alcune catastrofi sconosciute lungo la strada.
No, ha da sempre rappresentato una seccatura per il mondo IT. Causa principale di lunghe notti insonni, di frenetiche chiamate, la gestione delle patch è l'attività detestata da tutti.
Oggiggiorno, tuttavia, la gestione delle patch non è poi più così mostruosa come in passato. Non molto tempo fa, la manutenzione delle patch richiedeva la gestione di enormi fogli di calcolo che consentivano di collegare ciascuna patch al relativo codice "MS" e "q” nonché il livello di importanza assegnato da Microsoft nell'ambito delle priorità aziendali. Il monitoraggio delle sostituzioni delle patch esistenti con altre comportavo un dispendio di tempo nell'ordine di una mezza giornata ogni mese.
Molto è cambiato con il rilascio del sistema WSUS (Windows Server Update Services). Questo semplice ma fantastico strumento consente di risparmiare notevolmente tempo riducendo al minimo l'intervento manuale nelle attività di applicazione delle patch. Integrando WSUS con dei piccoli script, è possibile persino fare in modo di applicare immediatamente una patch a un computer senza attendere il successivo ciclo pianificato. Ho ancora lo script. Accedete al sito Web concentratedtech.com per scaricare una copia.
L'unica limitazione di WSUS era che il meccanismo automatizzato di applicazione delle patch funzionava solamente quando il server o il desktop a cui era necessario applicare delle patch erano effettivamente attivi. I computer che, per un motivo o un altro, dovevano restare spenti rappresentavano un problema per WSUS. Ciò comportava avviare un ciclo di applicazione patch immediatamente dopo l'accensione della macchina la mattina successiva o lavoro aggiuntivo dell'amministratore per trovarla e accenderla la sera prima.
Oggi conosciamo tutti questa limitazione di WSUS e non è un grosso problema. Se gli utenti lasciano le proprie macchine spente durante il ciclo serale di applicazione delle patch, la mattina successiva, all'accensione, verrà visualizzato un messaggio di notifica per indicare l'inizio dell'installazione delle patch. Anche oggi, i server generalmente rimangono sempre accesi. Ciò significa che rimangono sempre attivi e disponibili a ricevere istruzioni dall'imperturbabile strumento per l'applicazioni delle patch WSUS.
Cambiamento della situazione
Questo ambiente piacevole e statico cambia ancora una volta con il passaggio dei datacenter alla virtualizzazione. Una volta virtualizzati, i nostri server probabilmente rimarranno costantemente accesi. Tuttavia, i server virtuali devono essere basati su qualcosa di concreto. Nella maggioranza dei casi, quel "qualcosa di concreto" deriva dalla clonazione di un modello server.
I modelli server sono utilissimi poiché consentono di configurare rapidamente un nuovo server e di portarlo in linea con il minimo sforzo. Consentono inoltre di garantire che ciascun server venga attivato in base alla stessa configurazione principale. Anche i modelli server hanno un lato negativo. Benché tali computer siano ideali per creare un nuovo server, i modelli non sono da considerarsi delle vere e proprie macchine.
Un modello server esiste come file VHD in una condivisione file dislocata da qualche parte. Se la macchina viene spenta, il file diventa effettivamente inattivo. Non differisce molto da un file Word o Excel di grosse dimensioni. All'accensione, il file inattivo diventa un server perfettamente funzionante in grado di elaborare normali carichi di lavoro o i carichi di lavoro nefandi rappresentati dai malware e da altri exploit.
In breve, se a tali modelli inattivi non vengono applicate patch, potrebbero rappresentare l'origine di una diffusione di massa di malware per il semplice fatto di essere stati attivati.
Mi seguite? Bene, perché questo è il tema centrale di Microsoft Offline Virtual Machine Servicing Tool, attualmente alla versione 2.1. Questo solution accelerator consente di installare un insieme di strumenti di automazione per mantenere aggiornare i modelli di macchine virtuali che altrimenti rimarrebbero inattivi mediante WSUS.
.png)
Figura 1 I tre componenti principali di Microsoft Offline VM Servicing.
Per comprendere gli aspetti essenziali del funzionamento di questa soluzione, esaminate la Figura 1. È possibile osservare come il server che ospita System Center Virtual Machine Manager (VMM) interagisce con una delle condivisioni di libreria, un host Hyper-V e il server di gestione degli aggiornamenti software. Quest'ultimo può essere un server WSUS oppure un server System Center Configuration Manager (SCCM) disponibile. In entrambi i casi, i processi sono sostanzialmente identici.
Offline VM Servicing Tool utilizza quelli che sono comunemente noti come processi del servizio per gestire la distribuzione degli aggiornamenti alle macchine virtuali nella libreria di VMM. I processi del servizio sono essenzialmente attività gestite dall'Utilità di pianificazione di Windows, le quali vengono avviate a orari prestabiliti.
Quando un processo del servizio è pronto per l'attivazione, viene innanzitutto "riattivata" la macchina virtuale dal percorso del relativo modello. Il processo di riattivazione prevede la distribuzione della macchina virtuale in un host Hyper-V e la sua accensione. Dopo che la macchina virtuale è stata accesa, l'agente di Windows Update configurato al suo interno avvia un ciclo di aggiornamento software.
La configurazione dell'agente di Windows Update della macchina virtuale viene impostata allo stesso modo di quella di tutti i computer. La configurazione nella macchina virtuale può essere eseguita tramite l'applicazione di Criteri di gruppo oppure manualmente. Affinché questo processo funzioni, è necessario impostare tutte le configurazioni tipiche di WSUS, ad esempio l'indirizzo del servizio di aggiornamento, eventuali gruppi di computer WSUS, nonché tutte le altre caratteristiche definite dai criteri di sicurezza adottati.
Dopo che la macchina virtuale è stata correttamente aggiornata, essa viene spenta e inserita nuovamente nella libreria. Questo processo automatizzato consente di assicurare l'aggiornamento con le patch corrette delle macchine virtuali nonché di tutto il resto dell'infrastruttura. Offline VM Servicing Tool non aggiunge configurazioni di gestione degli aggiornamenti proprie, bensì si basa sulle impostazioni esistenti già configurate per WSUS o SCCM.
In effetti, l'installazione di Offline VM Servicing Tool prevede l'esecuzione di alcuni passaggi tutt'altro che scontati se non si legge prima l'apposita guida del Solution Accelerator. Sebbene giunto alla versione 2.1, lo strumento è comunque sostanzialmente analogo a una versione precedente. Per installarlo, è necessario un download della console disponibile nel sito Web Microsoft. Per eseguirlo, è necessario scaricare e copiare i file binari di PSExec, ovvero psexec.exe e pdh.dll, nella cartella bin dello strumento che si trova in C:\Programmi\Microsoft Offline Virtual Machine Servicing Tool\bin. È inoltre necessario configurare i criteri di esecuzione di Windows PowerShell per RemoteSigned.
.png)
Figura 2 La console di Offline VM Servicing Tool.
Dopo averla installata, la console dello strumento (illustrata nella Figura 2) identifica solo i gruppi di macchine virtuali per determinare a quali macchine vengono applicate patch e quando. Vengono inoltre identificati i processi del servizio contenenti le caratteristiche delle attività di aggiornamento. Lo strumento funziona inoltre con le macchine virtuali all'interno della libreria di VMM. Ciò significa che eventuali macchine virtuali spente che sono già state distribuite in un host Hyper-V non funzioneranno con lo strumento.
Lo strumento è compatibile con le macchine virtuali che non sono specificatamente modelli, ad esempio eventuali macchine virtuali di riserva a caldo pronte ad essere connesse in caso di problemi o qualora risulti necessario aggiungere altri server. In questi casi, lo strumento consiglia di utilizzare una scheda di rete secondaria nei server di riserva a caldo in combinazione con la distribuzione in una rete isolata. In questo modo è possibile evitare che la riserva a caldo diventi operativa per errore quando si intende esclusivamente applicare le patch correnti.
Microsoft Offline Virtual Machine Servicing Tool potrebbe non rappresentare una soluzione completa per tutte le esigenze di installazione delle patch offline, tuttavia, considerando il basso costo, le sue funzionalità, sebbene limitate, risultano estremamente utili nelle situazioni in cui è sufficiente mantenere aggiornate alcune macchine virtuali inattive. Tenendo conto dell'impegno necessario per eseguire questa attività manualmente e del rischio derivante dalla mancata installazione delle patch qualora essa non venisse eseguita, si capisce quanto sia importante tenere sotto controllo tutte le macchine virtuali inattive, ma potenzialmente pericolose.
.jpg)
Greg Shields*, MVP, è partner in Concentrated Technology. Per ottenere ulteriori suggerimenti da parte dell'esperto Greg Shields è possibile visitare il sito ConcentratedTech.com.*