Flessibilità e sicurezza: un binomio difficile da gestire. Se si vuole andare incontro alle esigenze di tutti i settori, però, è necessario affrontarlo. Meglio farlo non solo offrendo gli strumenti più funzionali, ma anche iniziative di sensibilizzazione verso gli utenti, per non rischiare che la maggiore libertà moltiplichi i rischi cyber.
Questo è il tipo di sfida che si presenta emerge l’esigenza normativa di archiviare e utilizzare le chiavi di crittografia di un’azienda in loco o al di fuori del cloud. Per sbloccare questi casi d’uso, e ampliare ulteriormente il proprio mercato in modo geograficamente trasversale, AWS ha deciso di lanciare una nuova funzionalità dedicata. Con le “avvertenze” in allegato.
La “variante esterna” di AWS KMS, collegata via API
Quando la compliance, per piccoli workload regolamentati, richiede chiavi di crittografia memorizzate e utilizzate al di fuori di un data center AWS, si può optare per External Key Store (XKS). Questa funzionalità, illustrata dall’azienda durante re:Invent 2022, permette di criptare o decriptare i dati con chiavi crittografiche, autorizzazioni indipendenti e audit attraverso un modulo di sicurezza hardware (HSM) gestito in un luogo a scelta. Un sistema non AWS, esterno, ma che comunica con il suo Key Management System (KMS) tramite chiamate API, in sicurezza ma senza spostare le chiavi all’interno del suo ecosistema.
Questa nuova funzionalità si inserisce nel meccanismo di gestione di chiavi crittografiche messo in piedi da AWS ed è importante comprendere come e quando serve. Per proteggere dati a riposo, il “normale” servizio richiede una chiave di crittografia unica a AWS KMS, protetta a sua volta con una chiave “principale”. Seguendo un modello “a busta”, quest’ultima viene archiviata in modo sicuro insieme ai dati che protegge, in un HSM AWS resistente alle manomissioni, da cui le chiavi non vengono mai prelevate.
Questo è l’iter “classico”, in cui si inserisce la variante appena presentata da AWS. Configurando l’External Key Store, infatti, si sceglie di sostituire la gerarchia delle chiavi KMS con una nuova root of trust esterna. Ciò significa che saranno tutte generate e conservate in un HSM fornito e gestito dall’utente e le interazioni con AWS KMS avverranno tramite un proxy, fornito e gestito dall’utente o da un suo fornitore.
Una “responsabilità condivisa” che ha conseguenze importanti
Messi a fuoco i passaggi tecnici, si può guardare alla novità presentata con un occhio più strategico e lungimirante. Saltano subito all’occhio, allora, due grandi cambiamenti. Non solo evolve il modo di gestire l’infrastruttura cloud ma anche, e totalmente, il modello di responsabilità condivisa.
A spiegare come è Julien Groues, General Manager Italia e Francia di AWS. “Secondo le procedure standard del cloud, AWS è responsabile del mantenimento dell’infrastruttura cloud in condizioni operative. Ciò include il patching dei sistemi, il monitoraggio della rete, la progettazione di sistemi ad alta disponibilità e altro ancora. Quando si sceglie di utilizzare XKS, cambiano i meccanismi di sharing responsability. Il cliente diventa responsabile della manutenzione del proxy XKS e dell’HSM, in condizioni operative”.
Questa scelta comporta il “dovere” di assicurare che tutti i componenti coinvolti (strutture fisiche, alimentatori, sistema di raffreddamento, rete, server, sistema operativo) siano protetti, altamente disponibili e dimensionati, per sostenere tutte le eventuali richieste AWS KMS previste. Il pericolo è altrimenti quello di bloccare il meccanismo di protezione tramite crittografia generale. Infatti, spiega Groues, “se la parte dell’infrastruttura sotto la responsabilità del cliente non è disponibile o ha latenze elevate (in genere superiori a 250 ms), AWS KMS non riesce funzionare e trasmette guasti a cascata verso tutti i servizi AWS coinvolti”.
XKY in Italia: Region pronta, imprese da educare
Non è un rischio remoto, come può sembrare, e le conseguenze sono devastanti. Rappresenta il prezzo da pagare per conquistare una maggiore flessibilità. La sfida, per gli utenti, è comprendere quando vale la pena di correrlo. AWS li supporta spiegando in modo più che esplicito il suo punto di vista su XKS. “È un’opzione da considerare solo se si hanno esigenze normative o di conformità che impongono di mantenere le chiavi di crittografia al di fuori di un data center AWS. In ogni caso, meglio mantenere il set di dati protetti da XKS al minimo” precisa Groues.
Questa raccomandazione vale anche per il mercato italiano, sempre più attento al cloud, non solo per abbattere i costi. Molte realtà lo interpretano, infatti, anche come uno strumento per democratizzare la sicurezza IT. La nuova funzionalità XKS, in tal senso, secondo Groues “rappresenta un ulteriore passo avanti, per continuare a mantenere il pieno controllo sui propri dati e sulle opzioni di archiviazione”.
Gli utenti italiani vi hanno accesso grazie alla Region AWS di Milano, scelta per ridurre al minimo la latenza di rete e raggiungere un tempo di andata e ritorno della rete (RTT) di 35 millisecondi o meno. Se una Region AWS italiana è pronta per l’implementazione della nuova funzionalità, lo è l’ecosistema di imprese? Il tema, già ostico, della sharing responsability nella sicurezza cloud si complica ulteriormente. KXS richiede infatti un background e una consapevolezza da non dare per scontati. AWS, per minimizzare i rischi di un’adesione inadeguata e “a sproposito”, ha lanciato diverse risorse, tra cui Skills Builder. Tramite questa piattaforma online, completamente gratuita, offre centinaia di corsi di formazione anche in italiano, su security, crittografia e archiviazione dei dati. Resta una “responsability” dei singoli utenti, scegliere di sfruttarli per usufruire di XKS nel modo corretto.
