KNOWLEDGE BASE

Knowledge Base
1Backup
Acronis
Antivirus
Email
Firewall
GFI Software
Mail
Monitoring
N-Able
Sicurezza
TSPlus
Diventa Autore per CoreTech | Scopri di più

Vai al Video

Cyber Security nel Cloud Computing

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.

Introduzione - Shared Responsibility Model

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.

Infrastruttura Cloud On Premise o affidarsi a un CSP?

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:

  • in relazione allo Shared Responsibility Model, conosco i miei doveri riguardo alla protezione dei dati dei clienti?
  • tengo traccia delle azioni effettuate dagli utenti?
  • effettuo la cifratura della comunicazione tra me e il Data Center e l’ambiente Cloud?
  • come gestirò un eventuale processo di migrazione verso un altro Cloud Service Provider?”.
  • chi può visualizzare i dati all'interno dell'ambiente Cloud?
  • dove risiedono fisicamente i dati?
  • effettuo regolarmente dei test di sicurezza?

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?

Rischi legati alla violazione del Least Privilege e ai servizi Serverless

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:

  • permettere l’accesso dall’esterno a una certa istanza (per esempio un’istanza che potrebbe essere una EC2);
  • eseguire servizi con privilegi Root o Admin;
  • la mancanza di procedure per l’esecuzione di eventuali modifiche alle configurazioni di sicurezza dell’architettura.

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.

Aumentare la sicurezza nella Shared Responsibility Model

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:

  • aggiornare il sistema operativo ed applicare le relative patch;
  • configurare i servizi correttamente;
  • assicurarsi che i dati sensibili non siano condivisi tra le applicazioni in modo inadeguato;
  • analizzare il comportamento degli utenti e rilevare eventuali comportamenti non appropriati.

Ora vediamo alcuni esempi di attività che invece sono in carico al fornitore del servizio Cloud:

  • garantire la continuità del servizio;
  • garantire la corretta configurazione e sicurezza dei dispositivi di rete;
  • implementare un piano di Disaster Recovery efficiente.

Tornando, invece, sugli aspetti legati ai termini del contratto, al fine di identificare correttamente rischio dobbiamo porci le seguenti domande.

  1. Teniamo traccia di ogni è azione che viene effettuata dagli utenti sia tramite user-interface che tramite API? Ad esempio su Amazon AWS possiamo Abilitare il servizio CloudTrail che ci permette di registrare ogni singola azione compiuta da utenti, processi eccetera.
  2. Le comunicazioni tra i server all’interno dell’ambiente e dall’esterno verso Data Center sono cifrate? Per quanto riguarda il primo punto, Amazon AWS rende disponibile uno strumento che ci permette di segmentare la rete nell’ambiente Cloud, quindi proprio di definire la sottorete e quale traffico può passare tra le varie sottoreti. Per quanto riguarda la comunicazione dall’esterno verso Data Center possiamo utilizzare quattro tipi di connessione VPN che Amazon ci mette a disposizione (altri fornitori del servizio Cloud avranno comunque strumenti che ci permetteranno di fare la stessa cosa).
  3. Effettuiamo regolarmente dei Penetration Test all’interno del nostro ambiente Cloud? A riguardo notate che su Amazon AWS è possibile effettuare un Penetration Testing andando a inviare una richiesta specifica che permetterà di testare diversi servizi tra cui EC2 oppure relazionali RDS. Su Microsoft Azure, per il Penetration Testing si dovrà effettuare una richiesta specifica riguardante gli eventuali servizi.

Violazione del Least Privilege: quali contromisure?

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.

Security Check e sicurezza delle Istanze: due imperativi

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.

Segmentare adeguatamente la rete

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.

Considerazioni finali sulla sicurezza Cloud

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.