​Ora che siamo a metà del guado, quello che ci porta da essere sempre in ufficio a lavorare spesso da casa o da ovunque, è il caso di ragionare su come lavoriamo da fuori, e se sia il modo migliore di farlo.

Una premessa:
Da parte nostra, e siamo in una ampia compagnia, crediamo che prima di tutto dovremmo ragionare sulla questione "dentro o fuori": da quando esiste internet i sistemi informativi sono costruiti intorno a questo paradigma. La rete interna, il dentro, in cui si può fare tutto e tutti sono buoni. E poi il fuori, dove tutti sono potenzialmente cattivi e non ci si deve fidare di nessuno.

Questa distinzione evidentemente è la causa di uno dei problemi del lavorare "da fuori". Non dovrei fidarmi, ma se si tratta di un dipendente devo consentire l'accesso al "dentro". E se mi sbaglio sono guai.

Crediamo che la distinzione vada tolta. Ma non nel senso che mi fido di tutti, anzi l'opposto. Non mi fido di nessuno. Non c'è più il dentro, ma solo il fuori. Perché nell'istante in cui mi fido e faccio entrare qualcuno, posso sbagliarmi. Quindi "zero trust". Non mi fido di nessuno.

A parte questo, il problema dell'accedere "da fuori" rimane. Come faccio?
Anzi, le domande sono probabilmente molte, tra cui queste due:

1. Come deve essere fatta una applicazione perché sia facile esporla in sicurezza, renderla accessibile da fuori?
2. Per le applicazioni che ho già, cosa posso fare per esporle senza espormi, e senza rifarle?

Alla prima sappiamo più o meno come rispondere, almeno genericamente. Fai una applicazione web, la esponi con un reverse proxy o con un gateway che ti piace, usi Azure AD per pre-autenticare gli accessi e abilitare MFA (autenticazione a più fattori) e conditional access (accedo solo se lo faccio da un posto  compatibile col mio ruolo, ad esempio). Con questo dovrei essere  ragionevolmente al sicuro da attacchi, di phishing o diretti all'applicazione.

Il problema è la seconda, perché non tutte le applicazioni soddisfano i requisiti per essere esposte in sicurezza, e molte nemmeno se si rinuncia alla sicurezza. E non posso pensare di rifare tutto.

La soluzione banale (almeno in teoria) è la VPN: in sostanza una connessione virtuale tra il pc dell'utente e la rete interna. Il pc, pur essendo remoto, è connesso alla rete interna proprio come se fosse "dentro". Ma in pratica la VPN più che essere parte della soluzione finisce per essere parte del problema, per diversi motivi:

1. Non è semplice da far funzionare per l'utente.
2. Non sempre funziona, ad esempio certi firewall potrebbero bloccarla.
3. Mettere un pc "estraneo" nella rete interna non è di per sé cosa sicura o opportuna, e anche un pc "amico" che non vedo e non controllo non necessariamente è affidabile ("zero trust!").

Quest'ultimo limite è spesso mitigato dai produttori di soluzioni VPN con protezioni aggiuntive che oltre a realizzare la connessione VPN controllano lo stato del pc, aggiungono protezioni che garantiscano una autenticazione certa dell'utente, limitano il tipo di traffico che può attraversate la connessione. Tutto questo ha però l'effetto di acuire i primi due difetti.
Aggiungiamo anche che le VPN rallentano la connessione, proprio per applicazioni (quelle "vecchie") che non sono state progettate per accessi da remoto e che per questo spesso soffrono particolarmente di connessioni lente o con latenza elevata.

Un ulteriore limite delle VPN, almeno dal punto di vista di una azienda di consulenza, è la difficoltà di farne convivere più di una. Spesso i consulenti lavorano da remoto con collegamenti VPN forniti dai clienti. E se hanno molti clienti, ognuno con la sua soluzione sono costretti ad avere molteplici configurazioni, che spesso non convivono volentieri.
Per far connettere terze parti (clienti, fornitori, auditors ecc.) sarebbe quindi preferibile non usare VPN, per evitare di mettere in rete un pc estraneo e poco (affatto) controllabile, e per rendere più semplice la configurazione all'utente.

Da qui l'esigenza di una soluzione differente.

Un possibile approccio è di non mettere il pc remoto nella rete interna, ma di utilizzare in remoto un pc interno, trasmettendo solo il desktop. L'esperienza utente può essere molto simile all'utilizzo del pc locale, ma in questo modo si ottengono numerosi benefici:

1. Non serve la VPN. Si utilizza un unico accesso verso un singolo servizio, che per sua natura è adatto ad essere accessibile dall'esterno, un po' come un server web
2. Non si proietta il pc remoto nella rete interna. Quindi non interessa (quasi) se sul pc remoto è presente malware e non è necessario preoccuparsi di come il pc è configurato
3. Le applicazioni "girano" in macchine interne, in un ambiente controllato. Quindi il pc esterno può essere di qualsiasi tipo e con qualsiasi sistema operativo. Le applicazioni non ne saranno influenzate
4. La trasmissione del solo desktop richiede molto meno banda rispetto a quanto necessario alle applicazioni, e non soffre della latenza. L'applicazione gira su una macchina vicina ai server e risponde con tempi che non dipendono dalla rete o dalla connessione.

Il modo classico, quasi vecchio, di fare tutto questo è utilizzare RDS (Remote Desktop Services), in sostanza un server che ospita diversi ambienti utente (diversi desktop). Sul server sono installate le componenti client delle applicazioni e gli utenti (anche molti contemporaneamente) le utilizzano in remoto.
Sebbene questa soluzione sia un netto progresso rispetto alla VPN rimangono (anzi sorgono) alcuni inconvenienti:

1. Non sempre una applicazione può essere utilizzata contemporaneamente da tanti utenti sulla stessa macchina. Un esempio banale potrebbe essere una applicazione che usa dei file di lavoro che stanno in un posto fisso con un nome fisso. Due copie dello stesso file non ci possono essere.
2. Il lavoro di un utente può disturbare quello di un altro, ad esempio eseguendo una applicazione che rallenta tutto il sistema.
3. Vecchie applicazioni possono richiedere autorità amministrative per l'esecuzione. Questo è poco compatibile con un ambiente condiviso (e poco opportuno in generale).
4. Un ambiente condiviso è necessariamente uguale per tutti, mentre utenti diversi con ruoli differenti facilmente hanno esigenze diverse. E spesso le vecchie applicazioni fanno fatica a convivere nello stesso ambiente. Si possono preparare tanti server RDS quante le configurazioni richieste, ma ci si complica la vita.

La soluzione più moderna a questo dilemma è di dedicare una macchina virtuale a ogni utente. L'accesso avviene sempre tramite RDS, non a un server condiviso ma a una sua macchina, configurata come serve a lui. Questa vm potrebbe essere dedicata a quella persona oppure essere condivisa, non nel senso che più utenti la usano contemporaneamente, ma che la vm non è "di proprietà", e che quindi possiamo immaginare che si possa cavarsela con un numero di vm pari al numero di utenti contemporanei.

L'inconveniente principale è il dover avere tante (tantissime?) macchine virtuali, più un insieme di strumenti che le gestiscano, le creino quando serve e ne garantiscano la configurazione.

Per questo parliamo di VDI - Virtual desktop infrastructure e di WVD - Windows Virtual Desktop

L'infrastruttura (la VDI!) non è però banale. L'esempio qui sotto, preso dalla documentazione Microsoft per la VDI su Azure, non lascia dubbi: (https://docs.microsoft.com/en-us/azure/architecture/example-scenario/wvd/windows-virtual-desktop):



Alcune componenti sono fondamentali e rappresentano il punto di forza di questa soluzione quando realizzata su Azure: rendere quasi semplice ciò che potrebbe non esserlo affatto. Nel disegno, in alto (azzurro) si vedono i due strati di infrastruttura che fornisce Azure, oltre alle vm vere e proprie:

• Azure Active Directory: il meccanismo di autenticazione e gestione dei profili utente, che in questo caso immaginiamo sincronizzato con l'active Directory di sede tramite AD Connect
• Web access: il punto di ingresso web a cui si accede. L'autenticazione è gestita da Azure Active Directory o dalla AD locale e consente anche l'autenticazione multi-fattore
• Gateway: il responsabile di girare il traffico verso la vm giusta. Si accede qualunque piattaforma (Windows, iOS, Linux, Android) e il traffico è incapsulato in un collegamento SSL
• Broker: accende le vm e associa le sessioni con le vm, decide quali vm usare e bilancia il carico. Inoltre il broker riconnette le sessioni che fossero cadute a causa di perdite connettività.
• Diagnostics: memorizzazione e analisi degli eventi per identificare eventuali anomalie
• Rest API: punti di accesso per consentire la gestione da parte di applicazioni esterne o l'automazione di operazioni sulla infrastruttura.