Con l’aumentare delle aziende che si avvalgono di un Cloud Service Provider (CSP) come parte integrante del loro business, aumentano le domande riguardo alla sicurezza nel cloud e a come di fatto i dati siano ivi protetti e se tali misure siano sufficienti.
Ormai tutti i grandi attori di questo settore offrono servizi crittografici che permettono di proteggere la confidenzialità e l’integrità dei dati che vengono trasferiti nel cloud.
In particolare, sono due i servizi crittografici messi a disposizione da AWS, GCP e Azure (il cloud di Amazon, Google e Microsoft, rispettivamente), i quali vengono usati in combinazione con gli altri servizi offerti dai vari CSP (ad esempio S3, il servizio di stoccaggio dei dati di AWS) per aumentare la protezione delle applicazioni e servizi fatti girare sui cloud stessi.
Tali servizi crittografici sono, da una parte, il Key Management Service (KMS) e, dall’altra, il Cloud Hardware Security Module (Cloud HSM).
Indice degli argomenti
Ecco perché usare i crypto-servizi nel cloud
Prima di addentrarci sulle differenze e il funzionamento di questi due tipi di servizi crittografici offerti dai maggiori attori nell’industria del cloud, sorge spontanea la seguente domanda. Ovvero: qual è il vantaggio di usare i servizi crittografici di AWS, GCP e Azure rispetto all’implementarsi le primitive crittografiche necessarie da sé? Non è forse quest’ultimo un metodo più sicuro, visto che non richiede di dare alcuna fiducia (trust) ai CSP?
Tali domande sono legittime e in effetti è vero che occuparsi della crittografia da sé diminuisce la dipendenza del proprio sistema da un sistema di terzi che, per forza di cose, non sarà mai completamente trasparente e sotto controllo.
Il punto però è che fare crittografia, o meglio, implementarla in maniera davvero sicura non è esattamente la più facile delle mansioni. Sono moltissime le vulnerabilità introdotte involontariamente dagli sviluppatori di applicazioni che richiedono l’uso di crittografia e che possono venire sfruttate facilmente da un hacker per accedere ai dati sensibili che dovrebbero invece essere protetti.
In questo contesto, le primitive crittografiche vengono implementate in software, direttamente come parte integrante del codice dell’applicazione stessa.
Inoltre, le chiavi crittografiche stesse vengono stoccate nella Virtual Machine dove l’applicazione è fatta girare, se non addirittura all’interno del codice dell’applicazione stessa.
Questo espone tutto il sistema di protezione dati a rischi elevati: anche se il codice relativo alle singole primitive crittografiche è corretto e non introduce vulnerabilità, un’implementazione e una gestione poco accurata dell’applicazione in generale la potrebbe comunque compromettere la sicurezza di tutto il sistema.
L’applicazione potrebbe infatti essere implementata in modo tale da lasciar fuoriuscire delle informazioni verso un’altra applicazione gestita da un altro utente, potenzialmente un hacker.
Tale hacker potrebbe dunque agilmente accedere alle chiavi crittografiche usate per la cifratura dei dati sensibili generati dall’applicazione che lo sviluppatore voleva inizialmente proteggere, esponendo pertanto tutti i dati sensibili precedentemente crittati.
Ecco perché molto spesso conviene delegare la parte crittografica di un’applicazione o un servizio a terzi, specialmente nel caso in cui il team di sviluppatori non ha un forte background in crittografia. Vediamo ora dunque più nel dettaglio i due servizi crittografici accennati di sopra, ovvero il KMS e il Cloud HSM.
Sicurezza nel cloud: come funziona un servizio di KMS
Un KMS è un servizio in cui un utente richiede che venga generata una Master Key, la quale poi verrà usata per crittare delle Data Keys. Saranno le Data Keys poi ad essere portate all’interno dell’applicazione che l’utente sta già facendo girare in Cloud e ad essere usate per la cifratura dei dati sensibili in uso o prodotti dall’applicazione stessa.
Tali dati cifrati potranno poi essere stoccati, in combinazione con il rispettivo servizio del CSP scelto, in un data base gestito ancora una volta dal CSP in questione.
La Master Key non viene di fatto mai usata per la protezione dei dati. Viene usata solamente per la protezione di quelle chiavi che a loro volta saranno usate come input dell’algoritmo di cifratura scelto dall’utente per la protezione dei dati sensibili, prima del loro stoccaggio.
Questo perché i CSP permettono di crittare con la Master Key che pochi kilobyte (addirittura Azure meno di un byte), il che è completamente insufficiente per crittare dati (basti pensare che nel caso di fotografie, si parla già di qualche Megabyte di memoria).
Per ragioni di conformità a determinati standard di cyber security in vigore in certe industrie, potrebbe darsi il caso che venga caldamente consigliato allo sviluppatore dell’applicazione Cloud di non fidarsi della Master Key generata dal KSM.
In questo caso, quello che succede è che lo sviluppatore deve prendersi a carico la generazione di tale Master Key all’interno della propria infrastruttura (on premise), secondo le indicazioni dello standard di riferimento stesso.
AWS, GCP e Azure offrono tutti la possibilità di far generare la Master Key all’utente e di poi trasmetterla all’interno del proprio KMS in maniera crittata.
Sarà all’interno del KSM che poi la Master Key dell’utente, detta anche Customer Master Key, verrà decrittata e utilizzata poi per crittare le Data Keys, che a loro volta verranno usate dall’applicazione per crittare i dati sensibili. Questo tipo di configurazione viene detto Bring Your Own Key (BYOK), ovvero “porta la tua chiave”.
Quando avvalersi di un servizio di Cloud HSM e come funziona
Un servizio crittografico come quello di KSM (con o senza l’opzione di BYOK) potrebbe non essere sufficiente a soddisfare, sia da un punto di efficienza che da un punto di vista di funzionalità, il tipo di crittografia messa a disposizione dell’utente.
In particolare, un KSM genera e cifra chiavi in software, che è molto più lento rispetto alle rispettive implementazioni in hardware. Inoltre, un KMS non offre che una ristretta suite di primitive crittografiche, normalmente gli algoritmi di cifratura e di firma più comuni.
Nel caso di operazioni di Key Derivation (come quella richiesta in Bitcoin) o di un numero di transazioni di compiere molto velocemente, un servizio come quello del KMS non è ottimale.
Una migliore soluzione viene invece offerta del servizio di Cloud HSM, che mitiga i problemi di efficienza e funzionalità descritti sopra.
Grazie ad un servizio di Cloud HSM, sia la Master Key che le Data Keys vengono stoccate in hardware (ovvero all’interno del HSM) senza poterne lasciare il perimetro.
Anche le primitive crittografiche (molte di più rispetto a quelle offerte da un KMS) sono implementate in hardware, il che ne aumenta la velocità di esecuzione. Tali HSM, che possono essere condivisi da più utenti Cloud oppure usati singolarmente (ad un costo maggiore, ovviamente).
Gli HSM sono conformi allo standard FIPS, l’ente americano che certifica che la suite di primitive crittografiche e di algoritmi di generazione di chiavi sia ben implementata senza vulnerabilità o errori. Inoltre, un servizio di Cloud HSM consente di firmare e di crittare i dati sensibili all’interno del HSM stesso, senza dunque dover esporre le Data Keys in chiaro nell’applicazione software come nel caso del servizio di KMS.
Sicurezza nel cloud: qual è il miglior servizio di crypto-cloud
Come spesso accade, non esiste un servizio di crittografia che sia migliore in assoluto. Dipende sempre dal tipo di applicazione che si vuole far migrare nel cloud e dal tipo e dalla quantità di dati sensibili o di operazioni critiche di cui si ha bisogno.
Il tutto va scelto anche in termini di costo e del tipo di investimento che si vuole fare per rendere un’applicazione o un servizio sicuro.
