By: Igor Jardim

Nei primi anni del 2000, il concetto di virtualizzazione ha iniziato ad emergere come una via d'uscita per le grandi aziende. datacenter che si sono trovati ad affrontare sia la mancanza di spazio fisico per la crescita sia lo spreco di potenza di elaborazione sui server, che finivano per rimanere inattivi più a lungo di quanto fossero effettivamente utilizzati.

Nel corso degli anni, questi piscine di server fisici dedicati ha iniziato a cadere drasticamente in disuso e la virtualizzazione è diventata una parte fondamentale di un'infrastruttura IT, sia nell'architettura che nei progetti, data l'agilità che consente nella gestione e nel funzionamento delle aziende.

Mentre i tempi di risposta del reparto IT e dei provider cloud venivano notevolmente migliorati, un problema fino ad allora ignorato si aggravava: la sicurezza dei dati, in particolare quelli su disco.

Oggi, con numerose perdite di dati, e l' GDPR bussa alla porta di tutti, è fondamentale che le aziende risolvano questa passività che non fa che aumentare, mettendo a rischio non solo gli utenti dei sistemi ma anche la continuità stessa dei proprietari delle infrastrutture IT.

Perché la sicurezza dei dati viene trascurata?

Molti amministratori non riescono ad utilizzare la crittografia del disco sui server, ad esempio perché per far decriptare l'HD dopo aver riavviato l'apparecchiatura è necessario immettere una password su ognuno di essi, un'operazione di per sé noiosa che aumenta i tempi di inattività dell'infrastruttura, anche se per pochi minuti.

Oggigiorno, con la facilità con cui si possono creare server virtuali, questa operazione diventa quasi impraticabile e finisce per indurre gli amministratori di sistema a scegliere erroneamente di non crittografare il disco.

Ciò che complica le cose è che il problema è molto più grave sui server virtuali: ogni volta che una macchina virtuale è in pausa o un snapshoot Una volta creata, non solo il contenuto dei dischi finirà sull'HD fisico del server, ma anche i dati in memoria! In altre parole, tutti i dati presenti nella memoria delle applicazioni e dei servizi in esecuzione sulla macchina virtuale, che normalmente includono chiavi crittografiche, dati personali, password, token di autenticazione, ecc., finiranno allo scoperto sul disco del server fisico, esponendo dati che devono essere protetti.

Una soluzione per la sicurezza

Se hai pensato: ma che dire del hypervisor, non lo risolve? La risposta breve è: non da solo.

Per capirci meglio, ricordiamoci: l'hypervisor è un livello software tra l'hardware e il sistema operativo che consente alle macchine virtuali di accedere alle risorse hardware. Opera a un livello del sistema in cui possono utilizzare chiavi per crittografare e decrittografare volumi di dati in modo automatico e trasparente per le macchine virtuali, ogni volta che è necessario, eliminando la necessità di digitare password.

Tuttavia, utilizzare solo chiavi per crittografare/decrittografare un server porta ad un altro problema: trovare un modo per archiviare in modo sicuro queste chiavi, poiché, con la loro perdita, non solo un singolo server, ma un intero gruppo, ovvero più dispositivi collegati che lavorano insieme e in parallelo finiscono per essere vulnerabili.

Utilizzo di KMS per memorizzare le chiavi crittografiche

 

Kryptus kNET HSM operante come KMS.

Kryptus kNET HSM operante come KMS.

 

Per risolvere questo problema e proteggere le chiavi, la soluzione è utilizzare un KMS (Key Management Service). I KMS sono un tipo di sistema in grado di gestire in modo sicuro il ciclo di vita delle chiavi crittografiche sotto forma di servizio. Diversi altri sistemi che supportano la crittografia dei dati possono essere collegati a questo servizio, come un hypervisor, un database e persino SIEM.

Ovviamente, KMS non può essere una macchina virtuale, quindi i sistemi/servizi di gestione delle chiavi efficaci si basano o utilizzano apparecchiature di protezione crittografica della classe HSM (Modulo di sicurezza hardware), dispositivo schermato, in senso logico e fisico, contro il furto e l'uso improprio delle chiavi crittografiche.

Se stai cercando una soluzione a questo problema, abbiamo due buone notizie!

Il primo è che con il rilascio di vSphere 6.5, VMware ha introdotto la possibilità di crittografare in modo trasparente la macchina virtuale (VM) stessa, indipendentemente dal sistema operativo su cui è in esecuzione, il che risolve i problemi di sicurezza già menzionati, oltre ad aiutare con le normative sulla protezione dei dati come GDPR! Per questa funzionalità, vSphere utilizza un KMS per proteggere le chiavi di crittografia!

La seconda notizia è che il kNET HSM funziona come KMS ed è completamente compatibile con Vmware vSphere.

Comunicazione tra vSphere e kNET

La figura seguente spiega, in termini generali, come viene eseguita la comunicazione tra vSphere di VMware e kNET di Kryptus:

 

inginocchiarsi

 

1- Innanzitutto, deve esserci una relazione di trust tra kNET (KMS) e vCenter;

2- vCenter richiede una chiave da KMS;

3- KMS invia una chiave di crittografia della chiave (KEK) a vCenter;

4- vCenter memorizza solo l'ID chiave e invia il set KEK+ID a ESXi (Hypervisor);

5- ESXi riceve e memorizza la KEK esclusivamente nella memoria;

6- Una volta ricevuta la KEK, ESXi genera la chiave di crittografia dei dati (DEK) per crittografare i file della VM;

7- ESXi ora crittografa i dischi rigidi della VM con DEK e quindi crittografa DEK con KEK;

Nota: quando ESXi si riavvia, vCenter richiede nuovamente la chiave a KMS e l'intero processo si ripete.

Il rapporto di fiducia tra VMware vCenter e Kryptus kNET L'operazione avviene in modo semplice e pratico: utilizzando il protocollo di manipolazione delle chiavi KMIP. A tal fine, il cluster KMS che verrà utilizzato viene aggiunto a vCenter, specificando IP, porta, utente e password di kNET. Viene quindi generata una richiesta di firma del certificato (CSR), che deve essere firmata da KMS e restituita a vCenter, che da quel momento in poi stabilisce la relazione di trust con KMS.

Vantaggi dell'integrazione VMware e kNET

Con questa integrazione, il cluster di server ha due livelli di protezione! Questo perché ogni VM è crittografata con una chiave DEK univoca e ogni chiave DEK è crittografata con una chiave KEK univoca. Ciò significa che anche se un aggressore scopre la chiave DEK, senza la chiave KEK, che è archiviata in modo sicuro all'interno dell'HSM kNET, non può accedere ai file.

"Prima di utilizzare un KMS integrato con VMware per gestire e archiviare le chiavi, dovevamo inserire manualmente le password su ogni server. Ora, questo processo è diventato molto più pratico, oltre a migliorare significativamente la sicurezza dell'ambiente nel suo complesso", afferma Igor, IT Manager di Kryptus.

Igor suggerisce inoltre di prendere in considerazione la configurazione di più di una kNET, creando un cluster KMS, per aumentare la disponibilità del sistema, poiché ESXi, quando viene riavviato e/o istanziato una nuova VM, richiede chiavi che devono essere fornite in caso di rischio di indisponibilità.

VOCÊ PODE GOSTAR:
WhatsApp è sicuro per inviare e ricevere denaro
4790 l blog di lavoro whatsapp pay

WhatsApp è sicuro per inviare e ricevere denaro? C'è il rischio di una truffa? Con il lancio Per saperne di più

V/Cert, un'azienda valida, prende l'iniziativa e adotta l'algoritmo post-quantico con Kryptus HSM
algoritmo post-quantistico

L'aggiornamento del software kNET HSM fornisce protezione a lungo termine contro le violazioni della crittografia Per saperne di più