LA GUIDA PRATICA

Smart working, telelavoro e accesso remoto: soluzioni di sicurezza

Non si può parlare di smart working e telelavoro senza tenere in conto le problematiche di sicurezza correlate all’accesso remoto dei dipendenti alle infrastrutture aziendali. Ecco le soluzioni tecnologiche per consentire il lavoro da casa senza intoppi

26 Mar 2020
I
Antonio Ieranò

Security and privacy architect


In questo periodo di emergenza sanitaria dovuta al coronavirus si fa un gran parlare di smart working come soluzione tecnologica per consentire il lavoro da casa in caso di isolamento da quarantena.

Al di là del fatto che quello che si cerca di implementare dall’oggi al domani è telelavoro e non smart working (quest’ultimo attiene più all’organizzazione e misurazione del lavoro piuttosto che alla locazione) occorre cercare di capire bene di cosa si sta parlando per diversi motivi:

  1. esistono implicazioni tecniche non trascurabili che se disattese possono vanificare gli effort;
  2. esistono implicazioni di sicurezza che vanno considerate;
  3. esistono implicazioni legali e di compliance a regolamenti e leggi (uno su tutti il GDPR) che non sono spariti a causa della emergenza coronavirus e quindi vanno tenuti in conto.

Va anche considerato che quello che si spende oggi per potenziare la connettività potrebbe richiedere ulteriori investimenti in un prossimo futuro per correggere i punti sopra citati. Ma capiremo questo in un secondo tempo.

Smart working, telelavoro e accesso remoto: cosa serve

In primo luogo, è importante capire cosa vuole dire effettuare un accesso remoto alle infrastrutture aziendali.

Tutti possono immaginare una tecnologia di accesso remoto come una tecnologia che consenta di connettere da un punto ad un altro due reti LAN (Local Area Network) come se fossero una sola.

La tipica implementazione è quella di connessioni LAN to LAN dove due LAN differenti sono connesse in qualche modo.

Per ottenere questo risultato si usavano connessioni dedicate offerte dai telco provider: questo consentiva di avere una certa sicurezza ad un costo però non indifferente.

Essendo queste due reti in qualche maniera unificate sotto un’unica struttura logica, le risorse di entrambe son visibili mutualmente: questo significa che le risorse della rete 1 possono essere utilizzate dai client della rete 1 e della rete 2, e viceversa.

Ovviamente nel caso vi siano risorse particolari e critiche deve essere possibile mettere delle limitazioni ai flussi e quindi, ad esempio, impedire che risorse in una rete siano visibili all’altra.

Chiaramente, una delle due reti potrebbe coincidere anche con un solo nodo e rappresentare un remote user.

Questo approccio è entrato in crisi quando, con l’espansione di Internet, ci si è resi conto che era possibile connettere le due entità non attraverso una connessione dedicata ma attraverso una tecnologia che creasse una connessione virtuale che sfruttasse la rete Internet. In altre parole, sfruttare una rete multipunto come Internet per ricreare la connettività punto a punto.

Questa tecnologia viene comunemente associata alle VPN che sono diventate di uso comune tanto per gestire le connessioni di utenze remote puntuali quanto per creare connessioni LAN to LAN

Smart working, telelavoro e accesso remoto: le VPN

Una VPN è essenzialmente una connessione creata tra due punti su una rete non dedicata. L’idea di base è di prendere le informazioni in transito da una parte e dall’altra, criptarle in maniera che solo i due punti in contatto possano leggerle e gestire la connettività in maniera tale che il traffico inviato da un nodo sia intellegibile solo dal nodo di destinazione.

La “sicurezza” di una VPN consiste proprio nel fatto che i pacchetti in transito non sono leggibili da nessuno se non dal destinatario.

Per ottenere questo risultato occorre, ovviamente, qualcosa che sia in grado di creare questi pacchetti criptati e gestisca le connessioni.

Non volendo, in questo articolo, estendere il discorso alle connessioni LAN to LAN, limiterò le mie considerazioni alle connessioni per gli utenti remoti.

Usualmente, nelle VPN questo viene gestito tramite un client e un server: il server è tipicamente un firewall, router o concentratore di VPN nella rete aziendale di destinazione che si prende in carico la ricezione delle richieste di connessione da parte dei client e provvede a inoltrare il traffico dall’utente remoto alla rete aziendale e viceversa.

Lato client, invece, possiamo avere fondamentalmente o software dedicati (normalmente chiamati VPN client) o connettività gestita via browser Internet usando tecnologia SSL (le cosiddette clientless VPN, che in realtà clientless non sono, semplicemente usano non un software dedicato ma uno già presente).

L’utente che vuole accedere alle risorse aziendali, quindi, non deve far altro che connettersi tramite client VPN dal device in suo possesso solitamente immettendo una username e una password. Anche se criteri più sofisticati di controllo del login sono presenti sul mercato da anni, solitamente questa coppia username e password è, se sono in piedi meccanismi di SSO (Single Sign-On), la medesima di accesso alla rete aziendale, ma questo presuppone che il server VPN sia stato configurato in tal senso.

Una volta effettuato l’accesso, l’utente si trova “virtualmente” all’interno della rete aziendale e può accedere a tutte le risorse, dalla intranet al database aziendale, all’accesso Internet quasi come se fosse connesso localmente.

Apparentemente la cosa è di una semplicità disarmante, a patto di non dover considerare elementi quali la sicurezza informatica, le prestazioni e via dicendo.

Limiti implementativi e complessità strutturale

L’approccio tradizionale alle VPN come si diceva prima, nasce per fornire l’equivalente di una connessione dedicata sfruttando la connettività più economica offerta da Internet.

Spesso, però, si tende a sottovalutare la complessità strutturale che la scelta di fornire accesso remoto porta con sé in termini operativi. Cerchiamo di analizzarne alcuni.

Problematiche di banda

Per ottenere una connessione VPN su Internet è ovvio che occorra da entrambi i lati un accesso Internet. La qualità di quest’ultimo è il primo vincolo alla connettività.

Le problematiche sono su entrambi i fronti, infatti possono essere legate alla qualità di connessione da parte dell’utente remoto, che solitamente utilizza connessioni pubbliche o home based, o alla banda disponibile acquistata dall’azienda.

Utente domestico

Lato utente valgono alcune ovvie considerazioni: la connettività Internet italiana non è uniforme e problematiche legate al digital divide sono presenti e radicate. Non ovunque c’è la fibra e nonostante le entusiastiche dichiarazioni marketing e pubblicitarie dei provider non è raro avere, anche nei paesi attorno alle grandi città, limitazioni di banda importanti con connessioni da 4mb in download e 800k in upload.

Va anche considerato che l’utente domestico condividerà la sua banda Internet anche con tutti i device che si connettono alla Rete, dalle TV a Netflix fino ai cellulari. Il risultato è che la banda disponibile potrebbe essere non sufficiente per i bisogni del telelavoro.

Va considerato, inoltre, che la banda non è l’unico elemento da considerare: vi sono, ad esempio, anche latenze DNS, jitter e altri disturbi che potrebbero rendere la connettività instabile.

Dare per scontato che siccome c’è Internet allora ci si può connettere è quantomeno ottimistico, soprattutto se non si è in una grande città o non si dispone di connettività effettive di almeno 10MB per secondo.

Lato azienda

WHITEPAPER
Una piattaforma, infinite comunicazioni. Come facilitare la collaborazione
Marketing
Unified Communication & Collaboration

Ammesso e non concesso che l’utente remoto riesca a connettersi, dal lato aziendale va ovviamente considerato se il carico di banda richiesto sia coperto dal contratto corrente per l’accesso a Internet.

Spesso non si considera il fatto che se l’utente si connette via VPN al concentratore aziendale e poi, ad esempio, va su Internet, il traffico consumato (al netto di ottimizzazioni e compressioni sempre possibili) è più elevato di una connessione effettuata dall’interno dell’azienda.

La motivazione è ovvia: esiste una connessione diretta dall’utente alla rete aziendale via VPN che richiede un servizio Internet. Questo arriva alla rete aziendale via Internet e riesce via Internet. Il traffico per la stessa richiesta è quindi duplicato.

Questa considerazione va estesa a tutti gli eventuali servizi esterni cui l’utente deve accedere mentre è connesso in VPN e quindi a tutti gli utenti che utilizzano il servizio.

Per fare un calcolo semplice, potremmo dire che per ogni utente in connessione remota va duplicato il traffico Internet al quale si aggiunge il traffico che solitamente genera all’interno della rete per accedere alle sue risorse.

Pur essendo negli ultimi anni migliorata la qualità e la copertura della connettività Internet, le problematiche di digital divide sono ancora presenti e spesso le aziende, soprattutto le PMI, non sono in grado di assorbire con i contratti in essere le aumentate richieste di banda legate agli utenti remoti. Questo è anche più vero in casi come quello attuale dove vi è una maggiore ed imprevista richiesta di telelavoro.

Va considerata nell’equazione anche lo stato della connettività Internet del Paese che in questi giorni è in sofferenza.

Dimensionare i concentratori VPN

Il problema non è solo legato alla banda Internet: un altro possibile collo di bottiglia, o quantomeno punto di attenzione, è legato proprio al concentratore VPN (sia esso router, firewall o concentratore tout court).

Il numero di connessioni concorrenti che il concentratore è in grado di accettare e la quantità di traffico totale che è in grado di sopportare, sono i due fondamentali parametri da tenere in considerazione.

Non è detto che il dimensionamento corrente sia adatto a gestire le richieste di un aumento imprevisto di connessioni da remoto, il che potrebbe tradursi in un rifiuto di accettare tutte le connessioni ed un degrado prestazionale che potrebbe coinvolgere anche altri servizi in carico al device che ospita e connessioni.

Va anche considerato, ovviamente, il limite legato alle licenze d’uso per le VPN che solitamente fanno parte di una voce specifica del costo del device.

Visibilità servizi e accessi

Una volta connessi alla rete occorre verificare un punto cardine: può l’utente accedere alle risorse cui deve accedere? E viene l’utente bloccato l’accesso alle risorse cui non deve accedere?

Questo punto è solitamente il più critico della configurazione. La tendenza, ovviamente, è quella di dare a tutti accesso illimitato alla rete, e questo è dovuto al fatto che configurare limitazioni di accesso dalla VPN uguali per tutti non è così semplice.

Questo indipendentemente dalla tipologia di utente che accede via VPN alla rete aziendale.

In realtà, gli utenti che potrebbero avere accesso alla rete potrebbero essere diversi per categoria, bisogno e profilo di rischio. Ma queste distinzioni richiedono di valutare almeno 3 parametri: il profilo dell’utente, la rete da cui si effettua la connessione, le caratteristiche del device.

Sebbene molte soluzioni VPN moderne siano in grado di gestire questi parametri, solitamente la cosa non è semplice in quanto richiede la configurazione non solo del punto di accesso ma anche dell’infrastruttura interna della rete.

Un errore classico è pensare che le attività di login possano sopperire a queste esigenze, ma questo è errato in quanto per poter arrivare ad effettuare un login su un servizio devo poter arrivarci via rete, e questo fatto da solo potrebbe esporre la risorsa a rischi legati a vulnerabilità o attacchi. Si pensi, ad esempio, a vulnerabilità sui server che contengono i servizi, se non ai servizi stessi.

Purtroppo, uno dei limiti delle VPN è che sono dei tubi di comunicazione che connettono l’utente alla rete e sono abbastanza agnostiche rispetto il contenuto che passa attraverso quel tubo.

Questo significa che eventuali attacchi sviluppati sul device remoto potrebbero raggiungere la rete attraverso la VPN anche saltando normali strutture difensive quali quelle offerte dal firewall. A meno di esporre le uscite delle VPN prima del firewall, aumentando la complessità del disegno della rete e della sua gestione.

Smart working, telelavoro e accesso remoto: l’end user device

Un ulteriore aspetto di rischio è legato ovviamente alla qualità del device in uso per effettuare la connessione. Questo deve essere in grado di gestire la connessione, le applicazioni e offrire un opportuno livello di sicurezza.

Essendo la VPN una sorta di tubo agnostico, il rischio che il device remoto sia esposto ad attacchi non è da considerarsi nullo, va d se che questo significa che deve essere gestito e monitorato con attenzione.

Non basta un antivirus, ma occorre valutare l’intera postura di sicurezza del device, quanto più l’utente accede a risorse critiche tanto più i parametri di configurazione del device remoto devono essere precisi.

Oltre all’antivirus e al controllo del patching per vulnerabilità di OS e applicazioni, sono opportuni anche meccanismi di controllo nella gestione dei file e dei dati critici soprattutto se il device entra in contatto con dati che possono sporre l’azienda in caso di data leak o manipolazione a conseguenze legali.

Sicuramente da evitarsi in quest’ottica, a meno che non vi sia un opportuno disegno delle applicazioni in uso ed un agreement contrattuale tra le parti, l’uso di device personali in luogo di quelli aziendali.

Paradossalmente, una delle ragioni per dire ciò è legato al fatto che se è vero che la VPN è un tubo agnostico, non è necessariamente vero che un’infezione debba per forza fare il tragitto utente remoto-azienda. È altresì molto probabile anche il percorso inverso: in questo caso, l’azienda sarebbe responsabile degli eventuali danni che subisce l’utente remoto alle sue pertinenze personali.

Connettività inbound e outbound: differenze

Un problema sotteso alle VPN è che le connessioni in ingresso sono generalmente in outbound per gli utenti remoti e in inbound per i concentratori VPN

Da questo punto di vista questo aumenta l’esposizione al rischio dei concentratori, in quanto devono essere pronti a processare e ricevere connessioni provenienti dall’esterno da una sorgente virtualmente ignota. Per quanto minimo, questo significa esporre il concentratore ad un rischio in caso vi siano vulnerabilità che possano essere sfruttate per forzare ingressi non leciti dentro la rete aziendale.

Rischio minimo, ma eventi del genere sono già capitati per diversi vendor, quindi minimo non vuol dire nullo.

Va da sé che in questo caso un attaccante motivato potrebbe accedere facilmente a tutte le aree di rete raggiungibili.

Più risorse, significa maggiore complicazione

Lo scenario sin qui disegnato può ovviamente complicarsi nel caso le risorse da raggiungere risiedano su più nodi che richiedano connessioni VPN dedicate.

In questo tipo di scenario l’utente potrebbe essere costretto a creare connessioni VPN distinte per specifiche necessità applicative. Questo creerebbe un ulteriore overlay di complicazione rispetto gli scenari visti prima rendendo anche più complessa la user experience e, quello che è peggio, il monitoraggio delle connessioni aumentando il rischio di breach non riconosciuti od evidenziati in tempo utile.

Se aggiungiamo la presenza dei moderni servizi SaaS e l’acceso ad Internet risulta chiaro come un modello che richieda un accesso ad un nodo specifico per accedere a risorse specifiche possa risultare estremamente complicato da gestire.

Ma esistono alternative?

Cambio di paradigma: la Zero Trusted Network

La VPN come idea richiede che si possano definire, all’interno della LAN che si raggiunge, un set di regole che la rende sicura, e l’utente remoto proiettato via rete all’interno della LAN possa quindi agire con un discreto livello di sicurezza.

Questo paradigma è poco convincente se analizziamo quello che succede nel mondo reale della security. Le stesse reti aziendali non sono sicure, e aggiungere elementi di accesso remoto non ne diminuisce certamente la esposizione al rischio.

Ma allora come fare a indirizzare il problema?

L’idea nasce diversi anni fa e consiste nel disaccoppiare la rete aziendale e l’utente remoto attraverso una rete terza che non offra accesso indiscriminato alle risorse aziendali o dell’utente.

L’idea di massima è quella di offrire un sistema in cui si crea una rete virtuale separata dalla LAN dove vengono esposte le risorse aziendali che devono essere raggiunte da remoto e a cui gli utenti si connettono in maniera sicura.

Questo approccio si chiama Zero Trusted Network (ZTN). Il concetto di Zero Trust ha 10 anni quando è stato menzionato per la prima volta da Forrester nel 2010.

Le componenti di una ZTN sono fondamentalmente la micro segmentazione e la next generation access control:

  1. la segmentazione parla di dare agli utenti l’accesso solo alle applicazioni di cui hanno bisogno, non a grandi parti dell’infrastruttura di rete;
  2. Next Generation Access Control si riferisce al fatto che non dovremmo solo autenticare gli utenti sulla connessione, ma anche continuare a verificare la loro identità e applicare i loro criteri per tutta la sessione dell’applicazione, anche a livello di pacchetto.

Portare questi elementi su una rete terza esterna alla LAN consente da un lato di ridurre la complessità gestionale all’interno della LAN stessa in quanto la esposizione delle risorse nella ZTN è limitata e monitorata alle sole risorse che si vuole far vedere, e non comporta modifiche interne alla LAN medesima.

Dall’altro consente la creazione di policy di accesso basate sulla postura dell’utente e del suo device per verificare cosa possa essere raggiunto e cosa no che vengono verificate per tutta la sessione.

Il tutto in una rete dedicata e costruita appositamente il che garantisce una facile implementazione ed anche un monitoraggio puntuale e più preciso.

Va da sé che maggiore e più disparato è il numero delle risorse da raggiungere più un approccio ZTN risulta efficiente rispetto un approccio VPN.

Una ricaduta interessante è che in un ambiente ZTN le reti originarie sono mascherate, e quindi anche l’eventuale presenza di sovrapposizioni IP (ad esempio reti con lo stesso dominio IP) vengono saltate rendendo tutta la gestione degli accessi estremamente più facile.

In un modello ZTN non si accede quindi alle reti che contengono le risorse, ma si espongono le risorse in un network separato cui gli utenti remoti possono accedere. Tutto ciò che non è dichiarato all’interno della ZTN è invisibile agli utenti.

Mascherare la rete interna con connessioni outbound

Apparentemente il modello ZTN assomiglia a quello VPN, l’utente si connette tramite un apposito client ad una rete, ma questa rete non è quella aziendale ma una ZTN appositamente creata in cui sono esposte solo le risorse che possono essere accendibili da remoto. Differenti utenti sulla stessa rete avranno diritti di accesso diversi alle risorse gestiti direttamente dalla ZTN il tutto in maniera assolutamente trasparente alle reti di provenienza delle risorse.

Una ZTN moderna è in grado di fornire accesso anche a risorse SaaS e Internet, risolvendo tra l’altro uno dei problemi classici delle VPN, l’aumento di banda necessaria per raggiungere risorse diverse che richiedano, ad esempio, salti di datacenter. Le risorse esposte (ivi compresa Internet) infatti si affacciano direttamente sulla ZTN limitando il numero di HOP richiesti, le reti ZTN infatti sono in gradi di creare mesh opportuni di connettività individuando i percorsi migliori per raggiungere la specifica risorsa.

Se il servizio ZTN è implementato su Internet con pop offerti dal vendor risultano chiari poi gli eventuali risparmi di banda su strutture complesse dove altrimenti potrebbe essere richiesto un instradamento di andata e ritorno come descritto nella sezione inerente le VPN.

Uno dei grandi vantaggi delle connessioni ZTN è che, siccome le risorse da raggiungere sono direttamente esposte nella rete, l’utente può raggiungerle dalla sua connessione senza dover connettersi e disconnettersi, ed inoltre il sistema per ogni singola applicazione istraderà i pacchetti con il percorso migliore offrendo, tra l’altro, maggiore resilienza.

Da non sottovalutare, inoltre, un altro aspetto. L’esposizione delle risorse dalla rete alla ZTN avviene in outbound, tradotto è la risorsa che deve aprire una connessione verso la ZTN, si risolve quindi anche la problematica di avere un firewall o un concentratore VPN sempre in attesa di ricevere una connessione da una sorgente sconosciuta.

Questo diminuisce la esposizione al rischio della rete che espone le risorse invece che aumentarlo come accade con le connessioni VPN tradizionali

Più sicurezza con un semplice management di risorse e utenti

Essendo la ZTN il gestore della connettività e delle risorse esposte, mette a disposizione strumenti di monitoraggio e definizione delle policy indipendenti dalle strutture su cui risiedono, questo consente di avere un’unica piattaforma di definizione di policy e monitoring degli accessi, quale che sia la risorsa esposta.

Il vantaggio in termini di sicurezza è evidente, potendo monitorare in maniera omogenea risorse che potenzialmente vengono da reti con caratteristiche profondamente diverse l’hypervisor di una ZTN diminuisce la complessità e quindi rende le analisi più rapide ed efficienti.

Inoltre, il poter definire policy per utente/gruppo sono possibili anche tecniche di micro segmentazione basate per gruppi di utenze.

Sul mercato queste soluzioni sono valide alternative allo sviluppo di strutture VPN complesse, e spesso sono anche economicamente vantaggiose, riducendo, ad esempio, sensibilmente gli investimenti hardware dedicati alla gestione della connettività remota e dando una maggiore flessibilità operativa.

FORUM PA 6 - 11 LUGLIO
Costruire la fiducia digitale: cybersecurity e privacy
Network Security
Privacy

Ed essendo generalmente offerte come servizio, lasciano i mal di testa sulla gestione della banda altrove.

@RIPRODUZIONE RISERVATA

Articolo 1 di 5