La virtualizzazione di un server significherà un altro livello del sistema operativo da patchare e aggiornare, più lavoro e maggiori rischi?

Ho effettuato una ricerca e non ho trovato nulla che risolva problemi relativi a patch e aggiornamenti di sistema. Ho delle linee guida che dicono che i server devono avere le patch necessarie. Se ho un host di macchine virtuali, è un ulteriore livello da patchare e aggiornare, anche con hypervisor bare metal? Al contrario di avere un server in metallo? (vale a dire più lavoro, prove e documentazione secondo le mie linee guida).

Con che frequenza vengono aggiornati i hyper-visor di tipo 1 / bare metal? È importante? Il fatto che si tratti di un livello software aggiuntivo introduce maggiore complessità e rischio (sicurezza e affidabilità)? (ad es. software senza bug del 99% x software senza bug del 99% = sistema senza bug del 98%)?

(La mia esperienza pratica è con VMWare Workstation and Server e VirtualBox.)

Sì, a volte prodotti come VMware dovrebbero essere sottoposti a patch ( gli aggiornamenti sono cumulativi ), ma le patch sono meno frequenti di un sistema operativo principale e il vettore di attacco potenziale è più piccolo: l'hypervisor non dovrebbe essere accessibile pubblicamente .

Userò VMware ESXi versione 5.0 (non 5.1) come esempio ...

ESXi 5.0 ha avuto il seguente programma di aggiornamento:

Tra il 9/2011 e oggi, ci sono stati aggiornamenti TEN al prodotto ESXi 5.0. Tra questi, SIX erano aggiornamenti incentrati sulla sicurezza inseriti nei bundle di aggiornamenti con descrizioni come:

"Vulnerabilità legata all'analisi del traffico NFS ESXi" - CVE-2012-2448 .

Queste vulnerabilità di sicurezza sono reali, poiché a volte rispecchiano i bug generali di sicurezza di Linux, ma penso che la maggior parte delle organizzazioni non siano molto sensibili ai rischi. Tuttavia, spetta all'ingegnere valutare questo rischio. I tuoi utenti vorrebbero enormi tempi di inattività per correggere il seguente exploit ?

"La macro encode_name in misc / mntent_r.c nella libreria GNU C (aka glibc o libc6) 2.11.1 e precedenti, usata da ncpmount e mount.cifs, non gestisce correttamente i caratteri newline nei nomi mountpoint, che consente agli utenti locali per causare una negazione del servizio (corruzione di mtab) o eventualmente modificare le opzioni di montaggio e ottenere privilegi, tramite una richiesta di montaggio predisposta. "

Può essere? Forse no.

Corro Update Manager di VMware , ma solo tendo a aggiornamento se sto influenzati da un bug o richiedono un potenziamento. Quando eseguito in una configurazione cluster, l'applicazione di patch è semplice senza tempi di inattività per le VM in esecuzione. Se non esistono altri motivi urgenti, cercherò semplicemente di aggiornare ogni trimestre. I singoli host richiederanno un riavvio completo, poiché le patch vengono fornite come immagini monolitiche.

Come nota a margine, ogni volta che eredito una configurazione VMware ESXi o lavoro su un sistema che normalmente non gestisco, vedo spesso host in esecuzione a cui non sono mai state applicate patch VMware. Questo è sbagliato!! Ma posso vedere come gli amministratori potrebbero commettere questo errore una volta che i sistemi sono attivi e in esecuzione.

Questa è una buona domanda se sei nuovo alla virtualizzazione con host 'bare metal'. Fare le cose in questo modo richiede una mentalità diversa rispetto all'approccio che potresti adottare con gli hypervisor eseguiti come servizio / applicazione su un sistema operativo convenzionale.

Nella mia esperienza, è probabilmente corretto affermare che ESX e HyperV necessitano in generale di meno patch rispetto ai sistemi operativi convenzionali. Ciò non significa che non necessitino affatto di patch o che l'applicazione di alcune patch non sarebbe vantaggiosa indipendentemente dal "bisogno", ma ciò significa che le interruzioni dei servizi per correggere l'host dovrebbero essere meno frequenti e più sotto il tuo controllo. Esiste un potenziale rischio per la sicurezza dei sistemi operativi dell'hypervisor così come esiste per qualsiasi altro, e mentre è possibile ridurre al minimo l'esposizione a questo rischio (ad es. Esporre solo la gestione dell'hypervisor su una VLAN isolata che non può essere logicamente raggiunta da un server compromesso) sarebbe sciocco fingere che non ci sia alcun rischio.

Quindi, se hai 4 server non virtuali, diciamo, e li sposti tutti sullo stesso host virtualizzato individuale, allora sì, stai aumentando la quantità di interruzioni che potrebbero essere causate dalla necessità di patchare il sistema host (o gestire un problema hardware, ecc.).

Mentre suggerirei che la possibilità che si verifichi questo rischio è relativamente bassa (sto parlando della differenza tra patch di un host virtuale e il tipo di patch che richiede un riavvio che dovresti comunque fare a un sistema autonomo ), non ci si può allontanare dal fatto che l'impatto è elevato.

Allora perché lo facciamo allora?

Il vero vantaggio della virtualizzazione deriva dalla possibilità di impostare più di un host e configurare gli host affinché lavorino insieme, consentendo agli ospiti di essere spostati da un host all'altro nel caso in cui un host fallisca o su cui si desidera pianificare le patch i sistemi host.

Utilizzando questo approccio sono riuscito a correggere 5 host ESX a turno senza alcuna interruzione per i 40 server virtuali in esecuzione su di essi. Questa è semplicemente una questione di economie di scala: una volta che hai abbastanza potenziali macchine guest virtuali per rendere utile creare questo tipo di installazione complessa e gestirla con il tipo di strumenti che @ewwhite menziona nella sua risposta, il rimborso nel ridurre i rischi sei preoccupato che arrivi molto rapidamente.

Un server virtuale richiederà la stessa manutenzione e patch di un server fisico, gli hypervisor bare metal richiederanno aggiornamenti, per motivi di sicurezza, ma anche per correggere bug e migliorare le prestazioni. Più server hai, più lavoro dovrai fare per tenerli aggiornati, non importa se sono fisici o virtuali.

Sulla base delle risposte di cui sopra sembra: la virtualizzazione di un server ha introdotto più complessità e rischi in termini di sicurezza e affidabilità, ma questi devono essere valutati rispetto ai vantaggi di poter ridurre i tempi di inattività virtualizzando un server.

Se il tuo ambiente richiede audit, test e documentazione, il costo-beneficio del carico di lavoro aggiuntivo di un ambiente virtualizzato dovrà essere preso in considerazione con il numero di server e personale di sistema che hai. Nel nostro ambiente non abbiamo il tempo personale / personale per mantenere la pista di controllo per un ambiente virtualizzato. Nei nostri processi aziendali possiamo prendere dei tempi di inattività, ma non possiamo mancare una pista di controllo e documentazione.