Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

Sicurezza dei server virtuali: 4 cose da non dimenticare

pittogramma Zerouno

VIRTUALIZZAZIONE

Sicurezza dei server virtuali: 4 cose da non dimenticare

31 Lug 2015

di redazione TechTarget

Quando si parla di sicurezza si perde di vista il concetto di massima disponibilità associato ai sistemi e alle applicazioni software-defined. Il “99,99%” usato come un mantra della perfettibilità non è una garanzia e ha un costo anche nell’ordine delle migliaia di euro. 4 consigli su come progettare la sicurezza dei server virtuali

Proteggere gli ambienti virtuali da rischi e interruzioni non significa soltanto assicurarsi di avere backup, firewall e password adeguati. Quando si  ha a che fare con la virtualizzazione, infatti, non si tratta solo di gestire policy e procedure corrette. 

Gli orizzonti di servizio sono aperti e comportano elementi di raccordo e di collegamento che devono essere ben identificati e risolti. La protezione di un ambiente virtuale (che comprende comunque una parte fisica) va impostata in due fasi: la progettazione iniziale e la definizione funzionale e operativa. Nella gestione della sicurezza, infatti, bisogna sempre considerare che ci sono diverse sfumature di rischio.

Prendiamo ad esempio il caso di un’interruzione del sistema: questa può essere minima oppure catastrofica. Quando le organizzazioni mettono in produzione un qualunque sistema informativo, dovrebbero sempre mettere in conto che, prima o poi, potranno verificarsi delle interruzioni nel servizio. Gli esperti sottolineano che, per quanto a tutti piacerebbe evitare interruzioni e guasti, questi faranno sempre parte dell’ICT. Ecco, duque, 4 cose da tenere a mente.

1) Il mantra del 9 non basta

Anche se non è possibile evitare le interruzioni, si può certamente lavorare per limitare la loro frequenza e il loro tempo di durata. In questi casi si cita il mantra del numero “9”, indicando in questo numero il criterio di massima disponibilità tendente alla perfezione (10, 100, 1000). Ad esempio, un sistema può essere in linea e disponibile al 99% o al 99,9999% del tempo. La differenza fondamentale tra i due non sta semplicemente nell’aggiungere un po’ più tecnologia; addizionare dei nove non porta alla perfezione. Spostare l’asticella, infatti, può avere un costo che può variare da migliaia a centinaia di migliaia di dollari a seconda del tipo di ambiente, quindi è importante capire quali sono i “9” realmente significativi per un’organizzazione.

Un sistema tarato sul 99% di uptime risulta molto altisonante, ma è quando si fanno i calcoli nel corso di un anno che si percepisce, in prospettiva, cosa non funziona comunque.

Guardando al delta temporale di downtime, infatti, è fondamentale ricordare che si tratta sempre di un’interruzione non pianificata, per cui il suo impatto sulla business continuity può avere un valore assai diverso rispetto all’organizzazione. Un tempo di inattività di 3,65 giorni nel corso di un anno può sembrare lo status ideale se si verifica durante il fine settimana, quando non c’è nessuno in ufficio. In realtà le probabilità che si verifichi durante la normale attività lavorativa sono molto alte, e non avere i sistemi in linea si sa quanto possa pesare sull’azienda. Paradossalmente, la Legge di Murphy sulle probabilità negative ancora oggi vale moltissimo.

Certo, l’ideale sarebbe poter contare su 6 volte il numero “9”: il 99,9999% dal punto di vista della business continuity suona davvero un po’ come il nirvana del CIO, ma dal punto di vista economico non è certo la formula più conveniente. Nel computo, ci sono molte variabili che devono essere considerate. Per avere il 99,9999% sono necessari server duplicati, storage dedicati, reti, e sistemi di alimentazione a prova di bomba, se non addirittura interi data center ridondati.

2) Garantire la sicurezza dei server virtuali richiede capacità di analisi

Con così tante variabili possibili, come progettare una cornice di sicurezza dei server virtuale omnicomprensiva e consolidata? Uno degli aspetti della sicurezza associata ai server virtuale è mantenere l’alta disponibilità dei sistemi. Che il motivo dell’interruzione di un servizio sia un attacco denial of service o un blocco del sistema, i vostri clienti non percepiscono la differenza. Negli ambienti di oggi, la virtualizzazione e il consolidamento hanno permesso alle aziende di diventare più efficienti ed efficaci nel rispondere alle esigenze in tempi più rapidi.

Il contraltare in negativo è che più sistemi richiedono meno hardware, più l’hardware diventa critico. La ridondanza è infatti una sfida ma anche una metodologia per chi deve progettare un data center, incorporando la sicurezza: è necessario coprire diversi silos tecnologici.

Spesso, la sicurezza del server virtuale è posto in secondo piano rispetto alla ridondanza mentre, al contrario, la ridondanza spesso dipende da tutta una serie di elementi che, se non sono risolti in ogni aspetto opertivo e funzionale, non garantiscono la protezione necessaria. 

3) L’alimentazione rimane un fattore chiave

È importante guardare ai requisiti di alimentazione della vostra infrastruttura di server, affrontandola in più fasi. Due alimentatori sono spesso un punto di partenza per garantire una protezione contro i guasti a livello hardware. Idealmente, i due alimentatori dovrebbero essere collegati a due gruppi di continuità differenti e relativi generatori. Un sistema di alimentazione ridondata è la chiave per aiutare la vostra infrastruttura a raggiungere i più alti livelli di disponibilità. Tuttavia, se l’infrastruttura non è completamente ridondata per ogni punto di attenzione (ad esempio, ha un unico generatore), si va ad aprire una falla nell’architettura di sicurezza approntata. 

Il sistema di networking è il collegamento tra gli utenti e le applicazioni e i sistemi di cui essi hanno bisogno. Istituire una doppia connessione di rete per un server è solo l’inizio di una messa in sicurezza: se le connessioni terminano sullo stesso switch di rete, ad esempio, la vulnerabilità della rete cresce. Un altro aspetto da considerare e che, se l’impianto si basa su diversi switch e questi possono essere collegati alla stessa sorgente di alimentazione, la questione della vulnerabilità  riporta le problematiche al discorso precedente.

4) Attenzione a IDS e firewall

Anche con una corretta ridondanza a livello di infrastrutture, quali sono i rischi se tutte le connessioni passano attraverso lo stesso sistema di rilevamento delle intrusioni (Intrusion Detection System – IDS) o un firewall? Un IDS o un firewall condiviso possono tradursi in un altro punto di debolezza dei server virtuali. Anche le organizzazioni che hanno data center ridondanti possono ritrovarsi con della falle non previste a livello di sistema.

Mentre molti siti di failover includono strumenti condivisi come, ad esempio, l’Active Directory o un server NTP, questi possono non avere sistemi IDS o firewall correttamente aggiornati. Questo impedirebbe di eseguire il failover ma anche una revisione dei server e il logging. Si tratta di limitazione che spesso sono comprese dai manager, ma i rischi di a livello di gestione non sono ancora sufficientemente documentati. La disponibilità è un aspetto critico del vostro scudo di sicurezza e comporta un insieme di configurazioni diverse.

La disponibilità di un server virtuale significa identificare i singoli punti di guasto e risolverli o – nel peggiore dei casi – riuscire a documentarli. Avere alti livelli di ridondanza aiuta il data center, ma tutto può riverlarsi un castello di carte se si verifica anche un singolo punto di errore. Il che significa che acquistare un server, un software o un qualunque dispositivo hardware con una disponibilità del 99,9999% non basta ad avere una garanzia di sicurezza rispetto ai propri server virtuali.

redazione TechTarget

Argomenti trattati

Approfondimenti

B
Backup

Articolo 1 di 5