Virtualizzazione: le 10 principali procedure consigliate di virtualizzazione
La costante maturazione della tecnologia di virtualizzazione si accompagna alla parallela evoluzione delle procedure consigliate per la sua applicazione. Se la vostra infrastruttura virtuale inizia a perdere colpi, provate a esaminare gli aspetti affrontati in questo articolo.
Wes Miller
Inizialmente utilizzata come tecnologia per infrastrutture di test, la virtualizzazione si è progressivamente affermata come componente essenziale di data center e infrastrutture desktop virtuali. Nel corso di questa evoluzione è stato spesso adottato un approccio approssimativo nei confronti della virtualizzazione, alla quale sono state applicate procedure IT con un livello di efficienza nettamente inferiore rispetto a quelle riservate ai computer fisici. Si tratta di un errore.
Se si disponesse di un budget illimitato si permetterebbe a chiunque nell'organizzazione di ordinare uno o più sistemi nuovi da connettere alla rete? Probabilmente no. Nelle fasi iniziali dell'implementazione della virtualizzazione, il rischio di una proliferazione illimitata e incontrollata è stato in qualche modo arginato dal fatto che le applicazioni hypervisor implicavano un costo. Ciò ha costituito una sorta di difesa contro l'introduzione di macchine virtuali non autorizzate nell'infrastruttura. Questo aspetto non è più rilevante.
Esistono infatti diverse tecnologie hypervisor gratuite, sia di tipo 1 sia di tipo 2. Chiunque in un'organizzazione disponga dei supporti di installazione di Windows può in poco tempo immettere un nuovo sistema nella rete. Quando le macchine virtuali vengono distribuite senza che i membri del team appropriati ne siano a conoscenza, esse possono diventare un ricettacolo indesiderato per nuove vulnerabilità zero-day in grado di disattivare altri sistemi nella rete effettivamente cruciali per l'azienda.
I sistemi virtuali non devono mai essere sottovalutati o dati per scontati. Per le infrastrutture virtuali è necessario adottare le stesse procedure consigliate che si applicano ai sistemi fisici. In questo articolo verranno illustrate 10 procedure consigliate importanti da tenere sempre in considerazione quando si utilizzano sistemi virtuali.
1. Esaminare sia i vantaggi sia gli svantaggi della virtualizzazione
La virtualizzazione sembra essere purtroppo diventata la soluzione a qualsiasi problema. Per rendere più rapido il ripristino dei sistemi, essi vengono virtualizzati. Si utilizza la virtualizzazione per rinnovare server obsoleti. Senza dubbio la virtualizzazione può esercitare un ruolo importante in numerose situazioni ed è opportuno avvalersene in questi casi. Tuttavia, prima di convertire tutti i sistemi fisici esistenti in sistemi virtuali oppure distribuire un nuovo parco di server virtualizzati per un determinato carico di lavoro, è consigliabile accertarsi di comprendere le limitazioni e le caratteristiche reali della virtualizzazione in termini di utilizzo della CPU, memoria e capacità dei dischi.
Ad esempio, è opportuno sapere quanti guest virtualizzati possono essere presenti in uno specifico host, nonché quante CPU o core, quanta memoria RAM e quanto spazio su disco ognuno di essi consuma. Nel caso di SQL Server, ad esempio, è necessario tenere conto dei requisiti da soddisfare per archiviare separatamente sistema, dati e log proprio come si farebbe per un analogo sistema fisico. È inoltre necessario considerare backup, ripristino e failover. La realtà è che le tecnologie di failover per i sistemi virtuali sono per molti versi potenti e flessibili come quelle per i sistemi fisici, anzi probabilmente lo sono di più. In effetti ciò dipende dall'hardware dell'host, dalle risorse di archiviazione e soprattutto dalla tecnologia hypervisor utilizzata.
2. Esaminare i diversi colli di bottiglia delle prestazioni in base al ruolo di ciascun sistema
Ai fini della distribuzione di un sistema virtuale, è necessario tenere conto del ruolo che esso occupa proprio come avviene per i server fisici. Quando si configurano server SQL, Exchange o IIS si utilizzano ovviamente configurazioni diverse tra loro. I requisiti in termini di CPU, spazio su disco e archiviazione sono estremamente diversi. Quando si definiscono le configurazioni per i sistemi virtuali, è necessario adottare il medesimo approccio progettuale che si utilizza per le distribuzioni di sistemi fisici. Per quanto concerne i guest virtuali, ciò significa esaminare le opzioni di server e archiviazione, nonché evitare di sovraccaricare un host con un numero eccessivo di guest oppure impostare carichi di lavoro in conflitto laddove possono esserci conflitti di CPU e disco.
3. Non è possibile sottovalutare la gestione, l'installazione di patch e la sicurezza dei sistemi virtuali
Si sono verificate due nuove epidemie di virus solo nell'ultima settimana. La realtà è che fin troppi sistemi virtuali non vengono aggiornati con le patch oppure queste ultime vengono installate in ritardo, non vengono gestiti correttamente e vengono trascurati dal punto di vista della sicurezza. Studi recenti evidenziano la responsabilità delle unità flash USB nella diffusione dei virus, specialmente per quanto riguarda minacce mirate. In effetti, anche molti sistemi fisici non vengono aggiornati e protetti in modo adeguato. I sistemi virtuali, in particolare quelli non autorizzati, rappresentano una minaccia ancora maggiore. La possibilità di annullare le modifiche apportate al sistema complica ulteriormente il problema laddove consente di rimuovere facilmente, sebbene non intenzionalmente, le patch e le firme di sicurezza. È pertanto consigliabile limitare la proliferazione di macchine virtuali e accertarsi di includere quelle esistenti nelle infrastrutture di installazione delle patch, di gestione e di sicurezza.
4. Non trattare i sistemi virtuali in modo diverso da quelli fisici a meno che non sia assolutamente necessario
Questo punto dovrebbe ormai risultare chiaro, ma è opportuno continuare a ripeterlo. È necessario evitare di trattare i sistemi virtuali in modo diverso da quelli fisici. Infatti, per quanto riguarda i sistemi non autorizzati è opportuno trattarli come ostili. Possono diventare un punto di accesso attraverso il quale può essere introdotto malware in rete.
5. Backup tempestivi e frequenti
I sistemi virtuali, analogamente a quelli fisici, devono essere inclusi nelle strategie di backup. È possibile eseguire il backup di un'intera macchina virtuale o solo dei dati che essa contiene. Il secondo approccio può risultare molto più utile e flessibile. Il backup di un'intera macchina virtuale richiede molto tempo e offre poche opzioni di ripristino rapido. Esattamente come per la protezione dei sistemi fisici più importanti, occorre accertarsi di poter ripristinare rapidamente funzionalità e affidabilità. Accade spesso, inoltre, che il backup dei sistemi venga eseguito ma non verificato, il che equivale a non eseguirlo affatto.
6. Prestare attenzione all'utilizzo delle tecnologie di "annullamento"
Le tecnologie virtuali spesso presentano opzioni di "annullamento", le quali dovrebbero essere utilizzate con estrema cautela. Questo aspetto rappresenta un altro motivo per accertarsi di includere i sistemi virtuali nelle strategie di controllo IT. È estremamente semplice ripristinare uno stato precedente di un disco, risalente a un giorno o addirittura a una settimana prima. Ciò potrebbe riproporre eventuali vulnerabilità a cui si era appena posto rimedio tramite una patch e rendere quindi il sistema veicolo di infezione per il resto della rete.
7. Esaminare la strategia di failover e scalabilità verticale
La virtualizzazione viene spesso pubblicizzata come la soluzione ideale per implementare strategie perfette di failover e scalabilità verticale. Ciò in realtà dipende dall'hardware dell'host, dall'hypervisor, dalla rete e dalle risorse di archiviazione. È necessario collaborare con tutti i propri fornitori per comprendere in che modo è possibile scalare i ruoli virtualizzati per ciascun guest server. È inoltre necessario conoscere le capacità di failover, ovvero sapere per quanto tempo i sistemi guest possono risultare non disponibili durante un failover e che tipo di funzionalità e disponibilità viene garantita durante il passaggio.
8. Controllare la proliferazione delle macchine virtuali
Si tratta di un aspetto di importanza cruciale, nonché uno dei più difficili da affrontare. Esistono diverse applicazioni hypervisor completamente gratuite e anche con quelle commerciali è estremamente semplice "clonare" un sistema guest. Ciò può causare numerosi problemi:
- **Sicurezza: ** i sistemi nuovi e quelli clonati in modo impreciso possono presentare lacune per quanto riguarda la sicurezza oppure causare conflitti con il sistema da cui sono stati clonati.
- Gestione: i conflitti derivanti dalla clonazione possono impedire la gestione dei sistemi in base ai criteri corretti e l'installazione tempestiva delle patch nonché causare ulteriori conflitti e instabilità.
- Implicazioni legali: fino a tempi recenti, Windows non era in grado di rilevare l'installazione in un sistema virtualizzato e soprattutto la duplicazione come nuovo guest (una o più volte). Molto spesso la proliferazione dei sistemi guest è dovuta alla semplicità di duplicazione e a un atteggiamento tollerante nei confronti della pirateria. Si tratta di un atteggiamento pericoloso che dovrebbe essere impedito dalle organizzazioni IT quanto meno attraverso l'applicazione di appositi criteri.
È estremamente facile clonare i sistemi. È necessario accertarsi che l'organizzazione IT sia consapevole dei rischi correlati alla duplicazione non autorizzata di sistemi guest. È invece opportuno distribuire solo macchine virtuali nuove in base agli stessi criteri adottati per i sistemi fisici.
9. Centralizzare l'archiviazione
Una della cause principali della proliferazione delle macchine virtuali è rappresentata dalla dislocazione fisica degli host in tutta l'organizzazione. Se si nota un dipendente che si avvicina a un server fisico con un disco rigido esterno e un CD è possibile verificare che cosa intenda fare. Con i sistemi virtuali, la copia dell'intero sistema guest è estremamente semplice. Ciò rappresenta uno dei motivi principali alla base dell'aumento incontrollato del numero di macchine virtuali. Questa situazione può determinare la perdita di dati. Se non è possibile proteggere fisicamente le macchine virtuali, è consigliabile che i relativi dischi virtuali o fisici siano crittografati in modo da evitare la perdita di dati riservati. Collocando gli host di macchine virtuali e le risorse di archiviazione in ubicazioni sicure e centralizzate, è possibile ridurre la proliferazione e il rischio di perdite di dati.
10. Esaminare il perimetro di sicurezza
Quando si sviluppa software o si gestiscono sistemi, la sicurezza deve essere una tenuta costantemente in considerazione. Quando si definiscono le modalità di gestione e aggiornamento dei sistemi fisici, occorre includere sempre anche i sistemi virtuali. Se si distribuiscono criteri per le password, è consigliabile applicarli anche ai sistemi virtuali. Approntando modalità di controllo appropriate per i sistemi virtuali è infatti possibile ridurre il rischio che vengano clonati. È necessario considerare le macchine virtuali come ostili, a meno che non facciano parte di un preciso piano di controllo IT. Molte applicazioni hypervisor includono ora una versione gratuita o di valutazione di software antivirus in modo da affrontare le potenziali minacce alla sicurezza tra host e guest.
Una tecnologia pronta per il futuro
La virtualizzazione promette di affermarsi sempre più come un componente IT essenziale in futuro. La cosa migliore da fare è individuare modalità di utilizzo e gestione di questa tecnologia fin da subito, piuttosto che ignorare tali aspetti e attendere gli sviluppi. È necessario applicare alle macchine virtuali gli stessi criteri validi per i sistemi fisici, nonché essere a conoscenza del modo in cui la virtualizzazione è utilizzata nell'organizzazione e sottolineare al team i rischi correlati al trattamento delle macchine virtuali in modo diverso rispetto ai sistemi fisici.
.jpg)
Wes Miller* è direttore della divisione Product Management in CoreTrace (CoreTrace.com) a Austin, Texas. In precedenza ha lavorato per Winternals Software e come Program Manager in Microsoft. È possibile contattare Wes Miller all'indirizzo wm@getwired.com.*