No results found
Il rischio di subire attacchi informatici non esiste solo nelle infrastrutture IT fisiche e quindi nelle reti aziendali, ma è qualcosa che coinvolge anche il mondo del Cloud, anzi, si può dire che l’infrastruttura virtualizzata sia ancor più appetibile per chi vuole “far danni” o delinquere, in quanto si possono utilizzare le stesse tecniche ma soprattutto il Cloud ha due peculiarità: vi si trova non solo la rete di un’azienda ma le infrastrutture di molti, perciò una volta entrati il piatto è più ricco; se per portare un attacco a una rete aziendale fisica significa dover superare il firewall ed entrare in quella rete, con il Cloud Computing si possono carpire i dati anche “solo” intercettandoli mentre viaggiano dai server locali dei clienti a quelli Cloud nei Data Center.
Ecco perché la Cyber Security nel Cloud è un argomento d’attualità, cui dedichiamo questo tutorial, che sarà praticamente diviso in due parti: nella prima cercheremo di analizzare quali sono i rischi che derivano da una non corretta gestione della sicurezza informatica in ambito Cloud e nella seconda cercheremo di mettere a fuoco le Cloud Security best practice, quindi quali sono le regole generali che in ambito Cloud si dovrebbe cercare di applicare.
Allora, innanzitutto introduciamo un modello molto importante chiamato Shared Responsibility Model, che entra in ballo quando si parla di sicurezza in ambito Cloud; praticamente è un modello che ci indica quali sono i doveri in termini di security best practice in Cloud del Service Provider, ossia del fornitore del servizio Cloud (potrebbe essere Amazon vs Google Cloud ecc.) e quali invece sono a carico del cliente che usufruisce di tali servizi.
Praticamente è un modello di responsabilità condivisa che mette in chiaro e assegna compiti specifici a ciascuna delle parti in causa, ossia il Cloud Provider e l’utente, nell’ottica di alzare il livello di sicurezza ed anche, se occorre, identificare le responsabilità in caso di incidente.
Un esempio di tale modello è proposto nell’immagine seguente, che riporta per il servizio AWS di Amazon tutte quelle attività che sono in carico al cliente (in blu) e al fornitore (in giallo); al cliente spetta ad esempio il dover aggiornare il sistema operativo, l’effettuare il patching del sistema operativo, di occuparsi delle configurazioni di rete, firewall ecc
Poi abbiamo una parte in carico al fornitore del servizio, quindi ad esempio il fatto che l’architettura hardware sia sempre disponibile, che le regioni, le zone di disponibilità e le edge location siano disponibili e via di seguito.
Questa ripartizione e assegnazione sono il primo passo per riuscire a valutare come implementare queste best practice di sicurezza.
Semplificando, possiamo affermare che il Cloud Service Provider si occupa del mantenimento e della scalabilità dell’infrastruttura in Cloud in generale, mentre il cliente è responsabile delle specifiche configurazioni di tale infrastruttura; questo vale in linea generale.
Il problema è che la maggior parte dei clienti ha frainteso questo modello ed è convinta che la sicurezza nell’ambiente Cloud non sia di sua competenza, perché dal momento che sta pagando per un certo servizio in Cloud e che si affida a un fornitore in un servizio Cloud, ritiene scontato che la sicurezza sia ad esso delegata; comunque non prende in seria considerazione la sicurezza e questo è un punto di vista totalmente errato.
Va notato che le Security Best Practice hanno inizio ancora prima di firmare il contratto con il fornitore del servizio Cloud, quindi bisogna porsi alcune domande:
Il concetto di sicurezza in ambito Cloud è strettamente legato a quello di fiducia e in questo contesto bisogna porsi alcune domande: innanzitutto, è preferibile realizzare la propria infrastruttura Cloud on premise o affidarsi a un Cloud Service Provider? La risposta ha delle implicazioni dirette sulla sicurezza dell’infrastruttura e quindi questa è poi è una delle prime valutazioni da fare; inoltre stimola una serie di considerazioni.
Affidarsi a un Cloud Service provider significa delegare a quest'ultimo tutta la parte di progettazione, realizzazione e mantenimento dell'infrastruttura, compresa la sicurezza; quindi sarà il fornitore del servizio Cloud ad avere in carico buona parte della gestione legata alla sicurezza; viceversa, se invece vogliamo una struttura Cloud on premises saremo noi responsabili di tutto ciò che riguarda l'hardware, quindi i dispositivi di rete e firewall, nonché dell’hardening dei sistemi, degli aggiornamenti e test di sicurezza.
Un’altra considerazione che dobbiamo fare è che il fornitore del servizio Cloud può cambiare a propria discrezione i termini del contratto di fornitura e questo è un aspetto che spesso viene sottovalutato; ma nel cambiare questo questi termini del contratto spesso ci sono delle implicazioni relative anche agli aspetti di sicurezza.
Altra considerazione: i Cloud Service Provider possono essere costretti da vari enti governativi a fornire dati e informazioni sensibili dei clienti, quindi e di conseguenza i Cloud Service Provider spesso si affidano ad altri fornitori; anche qui abbiamo un problema, perché non riusciamo a capire con esattezza dove possono risiedere i nostri dati: potrebbero addirittura risiedere in Data Center posti in nazioni dove vigono altre giurisdizioni.
Altro problema da affrontare è quello del vendor lock-in: quanto ci si vincola ad un provider e quali difficoltà si devono incontrare se si desidera migrare verso un altro, ovvero, quando il provider può “tenerci per il collo”?
Un’ultima considerazione riguarda la sicurezza intesa come garanzia di operatività: la sicurezza di un’infrastruttura Cloud è strettamente legata al concetto di Points of failure, ossia cosa accade in caso un’istanza, una regione o un container va down?
Cambiando punto di vista, soffermiamoci sul fattore umano, che anche nel Cloud è rilevante e può esporre a diverse tipologie di rischio; facciamo alcuni esempi, partendo dal caso in cui le procedure operative non siano formalizzate correttamente: se ad esempio non viene formalizzato cosa succede in caso di un incidente, ossia di un evento che va direttamente a colpire la sicurezza, è difficile reagire ad esso.
Ancora, la mancata formazione necessaria relativamente ai servizi utilizzati: siccome il fornitore del servizio Cloud rende disponibili molti servizi, a volte è difficile entrare nel merito e nel dettaglio ogni singolo servizio perché leggere la documentazione comprendere bene il funzionamento non è immediato.
Il basso grado di automatizzazione delle procedure è un’altra fonte di rischio, perché operare manualmente aumenta sensibilmente il rischio. Quindi il fatto ad esempio di dover assegnare un utente a determinati gruppi, se viene automatizzato si è sicuri di svolgere correttamente questa operazione, mentre se l’operatore deve stare a ricordarsi quel certo utente in quale gruppo va inserito e quali privilegi deve avere assegnati, aumenta sicuramente il rischio di sbagliare.
Altro problema è la violazione del Least Privilege; tale termine significa praticamente che bisogna cercare di dare all’utente o comunque a qualsiasi entità meno privilegi possibile, ovvero quelli strettamente necessari affinché possa svolgere l'operazione. Questo è un punto importante perché spesso si tende a dare più dei privilegi necessari a poter svolgere il proprio lavoro; per esempio:
Ecco, tutti questi aspetti sono legati alla violazione del Least Privilege.
Un’altra considerazione riguarda l’errata gestione delle Private Key: un esempio è quello di chiavi SSH custodite in un repository pubblico, liberamente accessibile a sviluppatori e programmatori; anche questo aspetto va a colpire quella che è la sicurezza dell’ambiente Cloud.
Altro problema può sorgere nell’utilizzo di servizi serverless, ossia tutti quei servizi di cui non conosciamo il sottostante ma ci limitiamo solo ad utilizzare la parte più esterna.
Un un esempio è Amazon Lambda, che ci permette di incollare direttamente il nostro codice e di eseguirlo ma non abbiamo alcuna conoscenza della struttura sottostante, quindi non sappiamo né cosa avviene con quel codice, né quali sono le possibilità di utilizzo da parte di terzi fuori dal nostro controllo. Proprio relativamente al servizio lambda, potrebbe far insorgere delle problematiche relative alla sicurezza tra cui la mancata conoscenza del “sottostante” e l’errata gestione dei permessi di esecuzione del codice, proprio perché non ci è dato di sapere se gestibili e con quali regole.
Adesso che abbiamo analizzato i principali rischi possiamo quindi dedurre quali contromisure applicare nei contesti Cloud; per rendere più chiara l’esposizione prenderemo ad esempio i servizi Amazon AWS, però praticamente i concetti sono validi anche per tutti gli altri fornitori Cloud, perché forniscono un servizio equivalente e magari più o meno la funzione svolta è molto simile, pur cambiando il nome.
Ripartiamo dallo Shared Responsibility Model e vediamo quali condotte possiamo attuare; per quanto riguarda tale modello, la best practice è di leggere con attenzione il contratto del fornitore del servizio Cloud e implementare delle procedure specifiche relativamente agli aspetti di gestione che saranno in carico al cliente.
Quindi bisogna comprendere molto bene il modello, quali procedure sono in carico noi e quali procedure invece sono in carico al fornitore Cloud così da implementare il tutto al meglio. Dunque, al cliente spetta:
Ora vediamo alcuni esempi di attività che invece sono in carico al fornitore del servizio Cloud:
Tornando, invece, sugli aspetti legati ai termini del contratto, al fine di identificare correttamente rischio dobbiamo porci le seguenti domande.
Abbiamo esaminato i rischi connessi alla violazione della Least Privilege, quindi adesso cerchiamo di capire che contromisure possiamo attuare. Allora, quando si creano le IAM policy (Access Management Policy, ossia sono le policy relative alla gestione degli utenti, gruppi, identità, accessi) è necessario fornire solo i permessi che servono per effettuare un certo task e nient’altro, quindi ridurre al minimo tutti i privilegi che eventualmente dobbiamo dare.
In Amazon AWS troviamo documentazione ben nutrita relativamente a questo aspetto, dove abbiamo tutta una serie di IAM molto dettagliate, che passo dopo passo ci guidano nel definire nel miglior modo possibile le policy.
Oltre a questo è consigliato revisionare regolarmente le IAM policy e soprattutto abilitare la MFA-Multi Factor Authentication sull’utente root e su tutti gli utenti che hanno l’accesso alla console; sicuramente farlo sull’utente root è prioritario perché è quello che ha più privilegi e che può compiere più operazioni.
Poi dobbiamo attivare la Multi Factor Authentication quando si deve eliminare dati da qualsiasi elemento di storage, perché un eventuale attaccante esterno che ha compromesso un account, sicuramente cercherà di coprire le proprie tracce e di conseguenza di cancellare i log; essendo questi situati all’interno di uno storage, affinché un eventuale attaccante non possa eliminare gli accessi che ha compiuto.
Altra cosa, dovete abilitare comunque la Multi Factor Authentication su tutti gli utenti IAM, dal momento che quest’ultima è spesso l’ultimo meccanismo di difesa contro la compromissione di un account
Ancora, bisogna creare le IAM Policy per gruppo, perché se le definiamo per singolo utente, ogni volta per singolo utente rischiamo di commettere degli errori, anche perché è difficile ricordarsi tutto per ogni utente; il fatto invece di creare un gruppo sicuramente diminuisce il rischio di commettere degli errori.
Altro aspetto interessante è implementare dei criteri adeguati per la creazione delle password: questa è una best practice comunque generale che non si applica solo agli ambienti Cloud, perché il fatto di definire adeguate policy di creazione delle password diminuisce le probabilità di successo di un eventuale attacco di tipo Brute Force.
Altra contromisura è il non utilizzare certificati SSL e TLS scaduti, perché i certificati scaduti o non validi aumentano le probabilità di eventuali errori all’interno dei servizi e delle applicazioni.
Poi ci sono alcuni servizi che sono specifici ma che comunque hanno anche gli altri fornitori, sotto altri nomi; ad esempio l’Access Advisor (Amazon AWS), che permette di gestire in maniera efficiente le IAM policy, che farà presente se ci sono policy inutilizzate o che è necessario rimuovere.
Un altro servizio utile di Amazon AWS è IAM Policy Simulator, che permette di visualizzare tutte le correlazioni tra le varie IAM Policy, così da vedere se abbiamo implementato delle policy inutili o che magari si possono eliminare perché sono inglobate in altre policy. Il tutto contribuisce a migliorare la gestione delle IAM policy.
Altra cosa importante è effettuare regolarmente dei Security Check; a riguardo va detto che tutti i fornitori Cloud hanno dei servizi specifici che si occupano proprio di ciò e che vanno a definire quello che è un modello di security best practice: un modello che poi verrà applicato all’infrastruttura specifica e a quel punto fornirà suggerimenti che il provider del servizio Cloud ci dà al fine di rendere l’infrastruttura sicura e più efficiente.
Facendo riferimento ad Amazon AWS, si tratta del servizio AWS Trusted Advisors che si occupa proprio di questo; come mostra l’immagine seguente, il servizio, relativamente a 5 aspetti che sono Cost Optimization, Performance, Security, Fault Tolerance e Service Limits, compie un’analisi e restituisce un certo esito relativamente alla necessità di azioni aggiuntive o se non è Stato rilevato alcun problema.
Quindi eseguire questi controlli periodici è anche facilitato dai Cloud Service Provider e aiuta molto.
Tra le azioni importanti abbiamo anche la sicurezza delle istanze, la quale riveste un ruolo fondamentale; per sicurezza delle istanze si intende il fatto di configurare correttamente i Security Group, quindi verificare che abbiamo solo le porte aperte necessarie al funzionamento delle istanze e dei servizi. Avere un range di porte aperte troppo ampio, sicuramente aumenta la possibilità che un attaccante riesca a portare a termine una scansione delle vulnerabilità.
Ancora, bisogna restringere l’accesso inbound alle istanze; anche qui dobbiamo configurare i security group in maniera adeguata, così da evitare degli eccessivi permessi di accesso alle istanze stesse, oppure considerare l’utilizzo di White List dove vengono specificati con esattezza gli indirizzi IP che sono autorizzati ad accedere alle istanze.
Un’altra best practice è l’utilizzare per le istanze uno Standard Naming, perché quando ci troviamo a gestire decine di distanze, se non utilizziamo una nomenclatura standard rischiamo di confonderci e di commettere anche degli errori che poi vanno a impattare negativamente sulla sicurezza. Quindi il consiglio è di utilizzare un sistema di identificazione... un sistema di tagging delle istanze adeguato.
Ultimo aspetto da valutare è la cifratura dei servizi di database utilizzati: dal momento che tutti i fornitori di servizi Cloud ci mettono a disposizione servizi di database (ad esempio i servizi RDS database relazionale) che tra le varie opzioni ci offrono la possibilità di cifrare i dati contenuti.
Alla sicurezza concorre il fatto di segmentare la rete adeguatamente; allo scopo in Amazon AWS vi sono i WPC, che sono quelli che ci permettono di creare le reti e sottoreti e di gestirle.
Il fatto di non avere una rete piatta ma segmentata adeguatamente è un aspetto molto importante, perché se un’eventuale attaccante riesce ad accedere all’interno di una certa sottorete non è detto che poi riesca ad accedere a tutte le altre; è ovvio che se la rete è piatta, l’attaccante riuscirà ad avere l’accesso a tutte le macchine che fanno parte di questa rete.
Un altro aspetto rilevante è quello di rimuovere elementi inutilizzati dell’infrastruttura: per esempio ridurre il numero di gruppi IAM dell’infrastruttura aiuta a ridurre il rischio di confondersi nella gestione, che così diventa più efficiente. Ancora, bisogna eliminare le Access Key non utilizzate, perché mantenerle aumenta la “superficie di attacco”; quindi, per esempio, ogni 30 giorni si può decidere che le access key inutilizzate vengano eliminate.
Altro suggerimento è disabilitare l’accesso agli account IAM non attivi; come best practice si suggerisce di eliminare tutti gli account IAM che non abbiano effettuato alcun accesso in un arco temporale di 90 giorni.
Ancora, eliminare chiavi pubbliche SSH non usate, perché cancellarle riduce il rischio che queste possano essere utilizzate per effettuare accessi non autorizzati.
Le Security Best Practice che abbiamo analizzato fin qui si possono applicare a qualsiasi contesto Cloud, non importa se stiamo parlando di Amazon AWS, di Google e via di seguito.
Diciamo che esistono delle regole generali e che poi ogni fornitore del servizio Cloud avrà dei servizi proprietari che permettono di svolgere determinati task: per esempio in Amazon AWS esiste una serie di servizi legati alla sicurezza, identità e conformità, quindi ognuno di questi aspetti va ad applicarsi a una specifico parte dell’infrastrutture e della relativa sicurezza. Per esempio Amazon Cognito, AWS Secrets Manager oppure AWS WAF (Windows Application Firewall).
Quindi servizi proprietari che vanno analizzati nel dettaglio aiutandosi con la documentazione e che poi possiamo applicare. Come consiglio generale è importante innanzitutto applicare le Security Best Practice generiche viste fin qui e poi andarsi a studiare nel dettaglio tutti i servizi di sicurezza specifici che sono offerti dai fornitori del servizio Cloud, qui a partire dalle Security best practice generiche, andare ad analizzare tutti i vari servizi di sicurezza che il provider Cloud ci mette a disposizione.