Cloud security: buone pratiche dalle città fortificate

Con la diffusione dei sistemi Cloud individuare un provider "fidato" diventa fondamentale, la fiducia e l'affidabilità di una piattaforma può fare la differenza in diversi contesti e le aziende investono continuamente per implementare nuovi protocolli di sicurezza.

Il problema della "fiducia" e dell'affidabilità di un sistema di sicurezza ha attraversato varie epoche storiche della società umana, è così possibile apprendere delle strategie da applicare nei sistemi di Cloud computing perfino dalle città fortificate del Medioevo. A notare queste affinità è stato Wolfram Hempel, fondatore di Arcentry, un'azienda che sviluppa tool per monitorare in tempo reale le infrastrutture Cloud.

Secondo l'autore, nel tempo le città fortificate hanno risolto vari problemi di sicurezza tramite 5 strategie chiave che è possibile applicare anche in ambito informatico:

1. Creazione di una zona "high trust". Anziché proteggere ogni casa individualmente. le città si circondavano di muri massicci e quasi impenetrabili. All'interno vi erano unicamente persone di fiducia, gli altri dovevano invece essere controllati e dimostrare la loro affidabilità per ottenere l'accesso.
2. Creazione di una zona di "lower trust" per strutture con esposizione esterna (stalle, foresterie..) situate al di fuori dalle mura principali ma circondate da recinzioni e alla portata degli arcieri in cima alle mura principali.
3. Interdizione dell'accesso diretto e dell'accesso limitato, implementando sistemi di ingresso per persone e mezzi pesantemente difeso e studiato per evitare possibili intrusioni tramite percorsi tortuosi, saracinesche e posti di blocco.
4. Limitazione dei punti d'accesso, il traffico in entrata e in uscita dalla città doveva passare attraverso due soli cancelli.
5. Implementazione di un insieme di controlli e criteri di accesso per l'ingresso, dai semplici face-check alle lettere di raccomandazione.

Le trusted zone

Nei sistemi Cloud il primo passo per creare un ambiente sicuro e affidabile è appunto realizzare un'area di massima sicurezza "fortificata" dove solo un piccolo sottoinsieme di applicativi ha effettivamente accesso alla rete, mentre tutto il resto del sistema (application logic, database, cache..) ne è di fatto escluso. Questo si ottiene comunemente tramite l'uso di una VPN (Virtual Private Network) o di una VPC (Virtual Private Cloud).

Le VPN sono di fatto delle reti di comunicazioni dati private. Spesso vengono usate per ottenere e scambiare dati tra più utenti in modo anonimo e sicuro. Una VPC si comporta invece come una rete isolata, dunque scollegata da internet, si tratta di un costrutto puramente virtuale che può essere configurato per funzionare in modo indipendente dalla posizione e dall'hardware su cui si basa. Può quindi essere implementata per uniformare gli strumenti di un provider Cloud con quelli locali.

Le VPC permettono quindi di racchiudere le potenzialità di un'infrastruttura globalmente distribuita in un sistema simile ad una LAN locale. Le VPC possono essere organizzate anche in più zone isolate chiamate subsnet, ciascuna con il proprio spazio IP e le impostazioni di accesso.

È prassi comune avere almeno due subnet, una privata che ospita i server, i database ecc, ed una pubblica che può accedere a Internet.

La lower trusted zone

La lower trusted zone include Web service che richiamano API esterne e si interfacciano con servizi di terze parti. È anche possibile implementare una DMZ (demilitarized zone) per creare un ambiente completamente isolato per i web-facing service ed i reverse proxy. Le subnet usano inoltre due costrutti addizionali per assicurare l'accesso alla rete: un NAT (Network Address Translation) ed un Internet Gateway.

Il NAT è paragonabile ad un ufficio postale, riceve tutte le richieste e le instrada verso i sistemi corretti. L'Internet Gateway si invece occupa di regolare la comunicazione e lo scambio di dati fra due o più reti con protocolli diversi.

Nessun accesso diretto/accesso tramite proxy

Nei sistemi VPN/VPC le comunicazioni verso l'esterno sono regolate da protocolli di autorizzazione, proxy e API gateway ne sono un esempio. Tali sistemi fungono da primo livello di difesa per i dati all'interno dell'infrastruttura e per accedervi è necessario convalidare la propria identità tramite credenziali (le "lettere di raccomandazione"), token di sessione e convalida dei privilegi d'accesso da parte dell'amministratore di sistema. Le richieste non convalidate non vengono nemmeno considerate dal sistema andando quindi a risparmiare risorse.

Ridurre al minimo i punti d'accesso

Creare zone isolate con controlli agli accessi non basta, le VPC sono comunque vulnerabili se non si limitano i punti di accesso disponibili. I server tendono ad esporre le proprie GUI di amministrazione e le monitoring port, nei sistemi inoltre è possibile eseguire processi in background che creano vulnerabilità sempre presenti nel tempo.

Per assicurarsi che solo alcuni sistemi, quelli "fortificati", siano accessibili pubblicamente, è prassi comune chiudere tutti i percorsi di accesso di default e tenere aperti solo quelli strettamente necessari. Ecco perché si esegue sempre una configurazione di gruppi di sicurezza per limitare il traffico a specifici IP, si aprono solo alcune webfacing port e si impostano firewall per il prefiltraggio delle connessioni in entrata.

Limitando le vie d'accesso al sistema è quindi più semplice creare un sistema di validazione delle credenziali e vari checkpoint per il flusso di dati in entrata ed in uscita dalle VPC. Tali credenziali possono essere concesse dall'amministratore di sistema o da provider di terze parti (third party oauth) affidabili.

Una volta implementate tali strategie un sistema è relativamente sicuro e protetto da attacchi. Ma a seconda del tipo di infrastruttura aziendale potrebbe essere necessario pensare anche a difese contro attacchi provenienti dall'interno della propria rete. Magari impostando permessi di accesso ai dati più severi per gli utenti già validati.

Inoltre, gran parte dei sistemi di sicurezza sono messi alla prova da strategie di ingegneria sociale, il furto delle credenziali non è infatti sempre brutale e diretto, ma può anche essere eseguito dopo mesi di osservazione per carpire nostre credenziali. In alcuni contesti è infatti utile sfruttare le debolezze umane e non quelle di un sistema informatico.

Via Wolfram Hempel