PREMESSA E OPERAZIONI PRELIMINARI

Per venire incontro alle esigenze di diversi teams, i quali richiedevano il raggiungimento di risorse interne utilizzando i protocolli nativi per le connessioni verso questi servizi (Client RDP per connessioni a VDI, Putty o simili per connessioni SSH e portali Web interni in HTTPS) si è scelto di adottare una soluzione ZTNA (Zero Trust Network Access) per gestire queste richieste senza dotare gli utenti di molteplici VPN rispondenti a seconda delle esigenze a porzioni di rete molto frammentate.
Microsoft mette a disposizione dei sui utenti, una soluzione chiamata MGSA (Microsoft Global Secure Access), che si basa su un agent installato sui client, con il quale viene fatta una connessione ZTNA verso Azure (Microsoft Entra Private Access), che gestisce attraverso policy e gruppi, gli accessi alle risorse interne messi a disposizione degli utenti.

Questa soluzione come si può vedere nella figura qui sopra, permette anche di gestire la parte di web filtering e controllo di navigazione internet, ma in questoscenario non è stata attivata e può esser gestita da altri prodotti di terze parti.

PREREQUISITI

Microsoft come per ogni suo prodotto, da dei prerequisiti da seguire per l’implementazione della soluzione GSA.
1. Licenza Microsoft Entra ID P1 o P2
2. I client devono avere a bordo Windows 10 o 11 con la CU 2H22 installata
3. La configurazione può essere eseguita con un’utente che abbia almeno le grant di Global Secure Access Admin
4. L’installazione sui client richiede privilegi di Local Admin
5. Il pc deve essere in join con Azure o in modalità diretta (senza Active directory locale) oppure in modalità Ibrida (Coesione di AD locale e Azure AD). Non sono supportati dispositivi in stato registered

CONFIGURAZIONE DEL GLOBAL SECURE ACCESS

Il GSA richiede per il suo funzionamento di appoggiarsi a dei gruppi di Azure per dare vari tipi di Grant. Abbiamo perciò creato 2 tipi di gruppi differenti:
GSA-AuthenticadedUsers che è il gruppo che autorizza il funzionamento del sistema GSA, che stabilisce il tunnel e che è applicato a tutte le risorse create in fase di configurazione del GSA
GSA-Webportals che è uno dei gruppi che permettono l’accesso ad una delle tipologie di risorse raggiungibili, in questo caso i portali web interni che si vogliono raggiungere in HTTP e HTTPS.
Richiede inoltre di appoggiarsi a uno (Microsoft consiglia almeno 2) server interni sui quali è installato un agent che permette ad Azure di comunicare con le risorse interne.
Noi abbiamo utilizzato la modalità Entra Private Access che è quella per fare ZTNA. Per cui ci baseremo su questo User Case.
Seguirà ora la configurazione del tenant.

ATTIVAZIONE DEL SERVIZIO GSA SU AZURE

L’attivazione e la gestione del GSA attualmente si trova esclusivamente nel portale di EntraId Admin Center, all’indirizzo: https://entra.microsoft.com/
Da qui sul menù di sinistra identifichiamo la sezione Global Secure Access dalla quale gestiremo ogni aspetto del GSA

Lo screenshot qui sopra è stato fatto dopo il completamento della configurazione iniziale, per questo motivo non troviamo la voce Get Started che scompare dopo la prima configurazione.
In fase di configurazione troveremo quindi una voce aggiuntiva per far partire la configurazione guidata dell’attivazione del servizio. È visibile nell’immagine qui di seguito.

Cliccare su Get Started e procedere prima alla verifica dei prerequisiti che ci vengono proposti, ovvero il controllo delle licenze e le grant di amministrazione dell’utente in uso. In seguito cliccare su Activate, attendere il termine della procedura di configurazione
Concluderla Cliccando su Get Started

Al termine di questa procedura la voce di menu chiamata Get Started scomparirà.

INSTALLAZIONE DEI CONNETTORI “PRIVATE NETWORK CONNECTORS”

Nel menù del GSA recarsi su Connectors ed in seguito su Download Connector Service. Qui si scaricherà l’eseguibile da installare sulle macchine che faranno da Proxy verso la nostra rete interna. Microsoft consiglia di averne almeno 2.

L’installazione del Connettore è un semplice Next – Next – Next. Al termine le macchine saranno automaticamente rilevate da Azure
Sul portale si dovrà procedere a creare il Connector Group che racchiuderà l’insieme dei connettori che ci serviranno per raggiungere le applicazioni. Nel nostro caso lo abbiamo chiamato Global Secure Access Connector e abbiamo assegnato a questo connettore le 2 macchine sulle quali abbiamo installato il connettore

CONFIGURAZIONE DEL QUICK ACCESS

Selezionando dal menù del GSA la voce Quick Access si entra nel pannello di configurazione della parte di accesso al sistema. Qui dovremo scegliere un nome da dare al servizio, nel nostro caso ***** Default. A questo assegneremo il Connector group creato in precedenza quindi salveremo la configurazione.

A questo punto configureremo la parte User and Group assegnandogli il gruppo GSA-AuthenticatedUsers

Impostiamo infine le zone di risoluzione DNS interne che vogliamo utilizzare per avere un accesso con FQDN invece che per IP, senza dover censire ogni macchina che vogliamo raggiungere.

Al termine di questa parte più generale, andremo ora ad effettuare le configurazioni di accesso alle singole applicazioni. Ricordarsi che questa feature è in Preview.

CONFIGURAZIONE DELLE ENTERPRISE APPLICATION

Il funzionamento riguardante la suddivisione degli accessi ad applicazioni, basate su gruppi di utenti viene fatta tutta in questa sezione del GSA ovvero Enterprise Application
Possiamo suddividere il traffico in gruppi differenti come per esempio:

1. GSA – Network Appliance: Questa E. App. abilità gli utenti assegnati a raggiungere i devices di rete come Switch e Network Appliance
2. GSA – File Servers: Questa E. App. abilita gli utenti assegnati a raggiungere le risorse del File Server
3. GSA – EXT Web Portal: Questa E. App. abilita gli utenti assegnati a raggiungere i portali Web per i clienti esterni azienda
4. GSA – RDP: Questa E. App. abilita gli utenti assegnati a raggiungere i server in RDP
5. GSA – Company Portal: Questa E. App. abilita gli utenti assegnati a raggiungere i Portali interni che cono condivisi tra utenti interni ed esterni
6. GSA – SSH: Questa E. App. abilita gli utenti assegnati a raggiungere le risorse in SSH
7. GSA – Web Portal: Questa E. App. abilita gli utenti assegnati a raggiungere i portali Web Interni
8. GSA – Domain Services: Questa E. App. abilita tutti gli utenti a contattare i servizi AD interni
9. GSA – EXT RDP: Questa E. App. abilita gli utenti assegnati a raggiungere i server e le Jump esterne all’azienda in RDP

Ogni Enterprise Application deve essere configurata parametrizzando 3 opzioni fondamentali:

 Users and Group

In questa sezione va inserito il gruppo di EntraID che sarà autorizzato a raggiungere le risorse gestire da questa APP.

Network Access Properties

In questa sezione si inseriscono i segmenti che devono essere raggiunti attraverso questa APP e viene assegnato un connector group per assegnare i Proxy.

Ogni nuova entry va inserita tramite il tasto Add Application Segment inserendo poi una di queste 4 categorie indicando poi, oltre alla network (IP address), anche il servizio (Ports ad esempio 22 per SSH) e il tipo di traffico (Protocol TCP, UDP o Entrambi):
1. IP
2. FQDN
3. Network
4. IP Range

Conditional Access Policy

La documentazione ufficiale richiede la creazione di una CAP per mettere in sicurezza l’app appena pubblicata. Benchè questa operazione sia fortemente consigliata, non è obbligatoria e di fatto il sistema funzionerà anche senza. Noi comunque abbiamo creato una CAP con le seguenti caratteristiche:
• Applicazione al gruppo GSA – Authenticated Users
• Valida solo per le APP del GSA
• Che abbia come condizioni di grant l’obbligo contemporaneamente di MFA attiva dell’utente e il device segnato come compliant. (Questo permette di essere molto flessibili sulle compliance del device)

Con il salvataggio della policy abbiamo terminato la configurazione del GSA. Ora procederemo con l’attivazione del Private Access.

 INSTALLAZIONE DELL’AGENT GSA

Essendo una soluzione basata su comunicazione agent, è necessario che sul client che vuole utilizzare per entrare nella ZTNA, sia installato il GSA Agent. L’agent può essere installato tramite soluzioni MDM come per esempio INTUNE oppure manualmente effettuando il download dal portale GSA.

L’installazione sarà un semplice Next – Next – Next.

NOTA BENE: L’installazione sul client prevede privilegi amministrativi

ATTIVAZIONE DEL PROVATE ACCESS (ZTNA)

Per attivare il servizio, cliccare su Connect ed in seguito su Traffic forwarding. Qui verremo portati alla pagina delle attivazioni dei profili di traffico.

Quello che ci interessa è Private Access profile.

Portando il selettore su ON si attiva il servizio e dopo qualche minuto tutti i client GSA si attiveranno e instraderanno il traffico dichiarato nelle APP attraverso il tunnel ZTNA

Il client GSA Agent dovrà avere lo stato della figura seguente per funzionare correttamente. Nel caso di Agent disconnesso non sarà possibile raggiungere le risorse in ZTNA

PROBLEMI RISCONTRATI

In fase di test abbiamo riscontrato alcuni problemi.

Qui di seguito indicheremo le possibili soluzioni.

• Il client non si connette malgrado la configurazione corretta. In questo caso abbiamo riscontrato che alcuni client VPN installati sul PC interferiscono con l’agent bloccandone di fatto il funzionamento. (Microsoft dichiara nella documentazione ufficiale di essere compatibile con tutti i client VPN ma in realtà non con tutti) La disinstallazione e/o la reinstallazione di questi client risolve il problema

• Casualmente viene richiesto il login dell’agent con un messaggio ZTNA Accesso non consentito. Escludendo che l’utente stia provando ad entrare in una risorsa a lui non permessa, in questo caso sarebbe un errore e sarebbe indicata l’app che lo blocca, questo si verifica quando il client in Hybrid Join (per cui di fatto ancora in AD locale) tenta di contattare il dominio di AD tramite i servizi dedicati (kerberos ecc..). Questo si risolve creando una App per permettere il traffico di tutti i servizi legati all’AD. Da documentazione Microsoft: 88,389,464,636 TCP/UDP – 135,139,445,593,3268,3269,9389,49152-65535 TCP – 123,137,138 UDP

• In alcuni casi le richieste tramite DNS vanno in timeout. La risoluzione DNS del GSA è in PREVIEW e quindi Microsoft stessa dichiara che non è perfettamente affidabile. Nel nostro caso risolviamo semplicemente ricaricando la pagina