La sicurezza dei dati nel cloud ibrido non riguarda solo la riservatezza o protezione da intrusioni non autorizzate ma anche altri aspetti come la loro integrità e (se possibile) continua disponibilità. Di frequente si tende a dare troppa importanza al primo aspetto senza valutare attentamente le altre facce della medaglia. Nel post di oggi vediamo come è consigliabile agire in tal senso quando si ha a che fare con “un’infrastruttura ibrida”.
Iniziamo prima di tutto con il definire ciascuno dei termini presentati in apertura:
- per disponibilità si intende l’essere in grado di accedere in qualsiasi momento ai dati con uno standard prestazionale ottimale – nel caso di un attacco DDoS le risorse del sistema sono ad esempio saturate e ciò risulta difficile o impossibile;
- per integrità ci si riferisce alla completezza, accuratezza e consistenza dei dati. Questi ultimi possono essere tanto trafugati quanto corrotti, risultando inservibili e causando un danno all’impresa;
- “riservatezza” è un termine abbastanza ovvio che necessita di spiegazioni.
Abbiamo già visto in passato come errati piani di disaster recovery possano causare seri problemi ad un’azienda: disporre di sistemi resilienti (una parola poco utilizzata in italiano ma molto popolare nella lingua inglese) rappresenta un primo importante passo per preservare la disponibilità dei dati. Prima o poi qualsiasi infrastruttura è destinata ad affrontare un imprevisto (blackout, connettività di rete assente, guasti hardware etc.) ed è in queste situazioni che entrano in gioco i server di appoggio : non appena il principale cessa di funzionare entra immediatamente in funzione “l’ausiliario”.
Qual è la strategia migliore per garantire la resilienza di un’infrastruttura? Le soluzioni a disposizione sono sostanzialmente due: replicare i dati on premise nel cloud e/o viceversa, aggiungendo come ulteriore garanzia la loro copia in una o più region del provider; replicare i dati e l’hardware on premise appoggiandosi ad un secondo data center – soluzione più costosa e che espone il business ad altre problematiche (costi aggiuntivi, tempi di latenza, il disporre di un solo punto di appoggio rispetto ad un setup multi region nel cloud etc.). A questo punto occorre stabilire quali tipologie di dati proteggere e in che modo. E’ difficile applicare un livello di resilienza totale a qualsiasi elemento del sistema: alcune vecchie applicazioni potrebbero essere semplicemente incompatibili, nei restanti casi ciò richiederebbe una spesa elevata per l’azienda.
La copia 1:1 e quasi in tempo reale dei file più importanti (storage del server) è una soluzione popolare il cui livello di efficacia dipende dai mezzi che si hanno a disposizione e dal cloud provider prescelto: alcuni vi forniscono gli strumenti per effettuare facilmente la copia dall’infrastruttura proprietaria al cloud e viceversa (es: AWS Storage Gateway), altri necessitano di un intervento diretto dell’azienda che dovrà creare un sistema per gestire i processi di replica.
Per quanto riguarda le applicazioni dobbiamo considerare più variabili: ad esempio le applicazioni database dispongono già di livelli multipli di replicazione come ad esempio il clustering (copia istantanea dei dati in cui il failover avviene autoamaticamente in caso di problemi del server o del database) ed il log shipping (operazione che richiede invece un intervento manuale) ed occorre procedere solo alla lora corretta configurazione. Per altre sarà invece necessario creare degli appositi script in modo da disporre all’occorrenza di procedure failover e failback.
Il tutto dovrà appoggiarsi ad un fornitore di connettività in grado di garantire l’accesso alla Rete anche in situazioni d’emergenza: senza un collegamento diretto con Internet, lo stesso sistema di copia on premise – cloud risulterà inutilizzabile perchè privo di un canale di comunicazione.
Preservare l’integrità dei dati
L’integrità dei dati è legata a doppio filo alle tematiche di disponibilità dei file e backup. Per assurdo disporre di un sistema ridondante può semplificare la vita dei malintenzionati. Prendiamo come esempio una classica applicazione database i cui dati sono replicati da un repository A ad un repository B: nel caso in cui un malware riesca ad introdursi con successo nel replicator ed a lanciare un DROP DATABASE (per cancellare tutte le tabelle ed il datatabase), avremo in breve tempo perso entrambi i repository. Per innalzare il livello di sicurezza generale (non esistono come detto più volte sistemi sicuri al 100%) si consiglia:
- controllo accurato degli accessi e limitazione dei privilegi per ciascun user ID;
- munirsi di una console centralizzata che possa gestire tanto l’installazione pubblica che privata;
- separare gli elementi d’interfaccia utente da quelli di gestione in modo che, nel caso in cui l’OS del server sia attaccato, non sia possibile accedere all’hypervisor o al layer di gestione dello storage.
Coloro che dispongono nell’infrastruttura privata di un moderno sistema SAN, possono affiancare ai backup del server anche degli snapshot – “un’istantanea che cattura” lo stato dei file in un determinato momento nel tempo, un utile strumento per ripristinare file corrotti e disporre di più punti di ripristino aggiuntivi. Ricordiamo infine che diversi provider consentono di effettuare gli snapshot anche nelle piattaforme cloud pubbliche: risorse permettendo, le aziende più attente riterranno allora conveniente affidarsi ad un doppio sistema di snapshot.
