Pensavamo di essere felici testimoni della fine della storia e invece la storia (molto infelicemente) prosegue. Pensavamo di avere raggiunto la padronanza delle tecnologie per la sicurezza ma lo smart working ci costringe a ripensarle
Uno dei molti effetti del COVID è stato l’adozione massiccia dello smart working. Per fortuna, le tecnologie per l’accesso remoto sicuro erano disponibili, e quindi si è potuto continuare a lavorare da casa. Lo smart working è uno dei due fattori che sta cambiando lo scenario delle architetture di sicurezza, rendendo obsolete quelle consolidate negli ultimi venticinque anni. Il secondo fattore è il Cloud Native Computing (CNC) che, con la possibilità di scomporre le applicazioni in microservizi, porta grandi vantaggi in termini di velocità nella produzione delle applicazioni, flessibilità, scalabilità e riduzione dei costi. Il combinato disposto dei due fattori mette in una crisi probabilmente definitiva i presupposti alla base delle architetture di sicurezza odierne.
Il primo punto in crisi è che ciò che sta all’interno del perimetro aziendale possa essere securizzato usando strumenti consolidati, firewalls, VPN, IPS. Ma nel contesto CNC cosa possiamo dire che sia all’interno del perimetro aziendale? Le applicazioni, decomposte in microservizi, possono girare su diversi tipi di cloud. I sistemi di orchestration stabiliscono quante istanze del singolo microservizio occorrono e in quale cloud (Azure, AWS, private cloud…) girano. Chi lavora da casa si collega alle applicazioni utilizzando il proprio ISP. Dopo le applicazioni in cloud, anche le persone non possono più essere considerate interne al perimetro. In sintesi, il perimetro aziendale non esiste più.
Il secondo punto in crisi è che l’ambiente classico, quello dell’ufficio, sia ben controllato. Lì c’è ancora un perimetro, si lavora su una rete privata e si condividono le risorse. Gli attacchi ransomware sfruttano la relazione di fiducia esistente tra i vari dispositivi collegati sulla rete aziendale per partire dalla vulnerabilità di uno dei dispositivi (una password rubata, un allegato aperto, un sistema non aggiornato …) per portare danni a tutti gli altri dispositivi. Una prima idea superata è che sia possibile utilizzare i dati infrastrutturali fondamentali (gli indirizzi IP) per basare su di loro la sicurezza. Se ti colleghi a una applicazione con un indirizzo IP aziendale sei sicuramente dei nostri, ma se da casa ti colleghi a una applicazione CNC non hai un indirizzo IP aziendale!
Il terzo punto superato è che all’interno del perimetro sia possibile e corretto adottare una relazione di fiducia tra tutti gli attori, condividere risorse e collaborare. Ma il ransomware sfrutta proprio il “lateral movement” basato sulla fiducia estesa per partire da un sistema vulnerabile e colpire tutti gli altri. Le relazioni di fiducia, su cui sono basate le architetture di sicurezza attuali, sono inapplicabili nel primo caso, quello dello smart working in contesto cloud native (non c’è un indirizzo IP aziendale). E inoltre, sono eccessivamente ottimistiche, e vulnerabili ai lateral movements nel caso del ransomware.
La zero trust architecture (ZTA, “non fidarti di nessuno”) è basata sul principio che non esistano relazioni di fiducia by default. Non è sufficiente essere sulla stessa rete per condividere applicazioni, dati e risorse di rete. Alle applicazioni non è sufficiente ricevere una richiesta sintatticamente corretta via API per rispondere. Le relazioni di fiducia vanno create esplicitamente sulla base di fattori quale il ruolo aziendale, il livello di sensitività del microservizio, il tipo di dato il cui accesso è autorizzato, la necessità di accesso per il dipendente. Basata su criteri organizzativi anziché tecnologici, la ZTA risolve non solo la difesa perimetrale in assenza del perimetro, ma anche il problema del ransomware. I meccanismi utilizzati per la realizzazione di una ZTA consentono una relativa semplicità di implementazione e una buona scalabilità.
Paolo Da Ros componente del comitato scientifico di CLUSIT
