Il modello di servizio di tutti i cloud provider si fonda sul principio della «shared responsibility». Le conseguenze per la sicurezza dei dati e delle applicazioni non sono sempre ben comprese. E a volte ciò è all’origine di sorprese molto spiacevoli.
Portare applicazioni e dati fuori dal perimetro fisico dell’organizzazione, per metterli nel cloud, può indurre frettolosamente a concludere che altri si occuperanno della loro sicurezza, al posto nostro. Questa è una pia illusione. È sbagliato attendersi che il cloud provider si assuma in toto la responsabilità di quello che succede nella sua infrastruttura. Per definizione, in un ambiente cloud la responsabilità è condivisa. Questo è un principio che non conosce deroghe, qualunque siano il modello adottato e il fornitore prescelto. Anche nella configurazione SaaS (Software as-a-service), il service provider non si assumerà mai la responsabilità per la protezione dei dati e delle interfacce.
Lo schema con cui AWS illustra questo concetto è molto chiaro al riguardo. Il provider si assume la responsabilità della sicurezza «del» cloud, il cliente quella della sicurezza «nel» cloud. In altri termini, AWS si occupa della sicurezza infrastrutturale (i sistemi hardware dislocati nel data center) e del software messo a disposizione del cliente (unità di calcolo, storage, gestione dati e networking). Il cliente, invece, deve badare alle proprie applicazioni, al traffico che insiste su di esse, alla gestione dell’identità degli utenti e alle procedure di accesso, alla configurazione del sistema operativo, della rete e dei firewall, e infine ai dati.
Chi si occupa di cosa: la metafora del condominio
Per essere ancora più chiari, proviamo a spiegarci immaginando la tipica situazione che si verifica in un condominio. La sicurezza fisica delle parti comuni è gestita in genere ricorrendo a un apposito servizio. Il cui costo di questa attività è pagato in base ai millesimi di proprietà: portierato, vigilanza o videosorveglianza. Il condominio, o l’impresa delegata a occuparsene, è responsabile dei risultati di tale servizio. Non spetta invece al condominio presidiare la sicurezza all’interno di ciascun appartamento né stabilire i criteri in base ai quali il singolo proprietario regola gli accessi a casa propria. È il condomino che sceglie a chi prestare le chiavi, a chi aprire la porta, che cosa consentire di fare all’interno del proprio appartamento e per quanto tempo.
Il principio della «shared responsibility» ha una serie di implicazioni per quanto riguarda l’evoluzione delle strategie di cyber security che le aziende dovrebbero mettere in atto. Furto di credenziali o errori di configurazione dell’identità digitale e dei profili autorizzativi degli utenti, per esempio, sono alla base di molti accessi indesiderati alle applicazioni sul cloud. Così come la presenza di applicazioni compromesse è sfruttata per lanciare attacchi, interrompere servizi o trafugare dati. Si tratta, in tutti i casi, di incidenti per i quali il service provider non si assumerà mai la responsabilità.
Per questo occorre dotarsi degli strumenti e della cultura necessari ad affrontare le nuove tipologie di minacce che accompagnano l’inesorabile evoluzione verso il cloud: data breach, ransomware, attacchi DDoS o phishing. Come sempre, la logica vincente è quella della prevenzione. Si tratta di configurare correttamente le autorizzazioni e le identità dell’utente, nonché di definire le misure di protezione dell’infrastruttura e dei dati più adeguate rispetto al contesto applicativo e di business in cui si opera.
Le buone pratiche per una corretta protezione
La sicurezza sul cloud impone il rispetto di alcune buone pratiche. La prima consiste senz’altro nel proteggere la console di gestione e configurazione dei servizi. È infatti attraverso di essa che vengono sferrati, nella maggior parte dei casi, gli attacchi informatici. Per questo occorre regolarne e sorvegliarne rigorosamente l’accesso. Un altro punto debole di un ambiente cloud è rappresentato dagli strumenti di provisioning automatico, che a loro volta devono essere protetti in modo adeguato.
Uno degli errori più diffusi consiste nell’includere nel codice applicativo le chiavi SSH di accesso alle API che vengono usate per avviare e arrestare macchine virtuali o istanziare container. Il codice viene poi reso disponibile all’intero di repository pubbliche come GitHub, da dove è facilmente trafugabile. Per questo è importante rimuovere le chiavi SSH incorporate dalle applicazioni.
Un ulteriore elemento di potenziale vulnerabilità risiede negli strumenti e nei processi di DevOps. Per mitigare i rischi occorre mantenere un rigido controllo sulle console amministrative, limitare al massimo i privilegi di accesso, concedere accessi just-in-time e tramite autenticazione a più fattori, segregare le pipeline, isolare e monitorare le sessioni degli utenti. Tool di Privileged Access Management possono aiutare grandemente a gestire questo tipo di problematiche.
Tuttavia l’impiego di strumenti adeguati non è mai risolutivo. La sicurezza nel cloud – come quella on premise, del resto – presuppone l’adozione di processi sicuri by design e soprattutto una consapevolezza culturale diffusa, in grado di orientare i comportamenti quotidiani dei singoli.
