• Cloud, Guide, Microsoft 365, Sicurezza
• 9 Giugno 2026

L’adozione sempre più diffusa di strumenti di intelligenza artificiale generativa e servizi cloud non gestiti sta cambiando profondamente il perimetro della protezione dei dati. Se fino a poco tempo fa Data Loss Prevention (DLP) si concentrava principalmente su endpoint, email e servizi Microsoft 365 oggi diventa sempre più importante controllare anche il traffico web diretto verso applicazioni esterne come ChatGPT, servizi di file sharing e altre destinazioni internet.
È proprio in questo scenario che entra in gioco DLP Network Data Security, una funzionalità che estende le capacità di Microsoft Purview a livello di rete, consentendo di analizzare e proteggere i contenuti in transito attraverso integrazioni con Global Secure Access e con i meccanismi di ispezione del traffico web. In questo modo è possibile intercettare upload di file verso applicazioni AI o destinazioni non gestite, applicando criteri di protezione coerenti con quelli già utilizzati nel resto dell’ecosistema Purview.

A differenza dei controlli tradizionali basati solo sul dispositivo o sul browser, Network Data Security lavora sul traffico HTTP/HTTPS instradato attraverso l’infrastruttura di sicurezza di rete. Questo approccio consente di rilevare e bloccare la condivisione di contenuti sensibili verso applicazioni non gestite, inclusi molti servizi di AI generativa, mantenendo una governance centralizzata in Microsoft Purview.

Figura 1 – Architettura Microsoft Purview DLP Network Data Security con GSA Internet Access

In questo articolo vedremo un esempio pratico di configurazione end-to-end, utilizzando Microsoft Entra Global Secure Access Internet Access come motore di ispezione del traffico e Microsoft Purview DLP come componente di classificazione e enforcement.

L’obiettivo è arrivare fino al test finale di upload di un file su ChatGPT, osservando anche le principali differenze di logging e visibilità rispetto a uno scenario basato su Endpoint DLP.

Nel mio scenario ho strutturato la configurazione nei seguenti passaggi principali:

• configurazione di TLS Inspection in GSA Internet Access;
• configurazione del web content filtering per consentire l’accesso controllato alle applicazioni AI;
• configurazione della content policy per l’ispezione dei file;
• configurazione del security profile in Global Secure Access;
• creazione e assegnazione della Conditional Access Policy;
• creazione di una policy DLP dedicata in Microsoft Purview;
• test finale di upload su ChatGPT e analisi delle differenze rispetto a Endpoint DLP.

Per questa demo ho utilizzato un tenant in cui Microsoft Purview e Microsoft Entra Global Secure Access erano già disponibili. Ho quindi instradato il traffico internet tramite GSA per applicare l’ispezione TLS, il web content filtering e l’integrazione con Purview per analizzare i file in transito.

Di seguito sono riportate le licenze necessarie per questo scenario:

Entra ID Internet Access

Entra ID P1/P2 + Microsoft Entra Suite o Internet Access

Microsoft Purview

Microsoft 365 E3 + Purview Suite oppure Microsoft 365 E5 oppure Microsoft 365 Business Premium + Purview Suite

+

Scan with Purview richiede una sottoscrizione Azure pay-as-you-go

Configurazione di TLS Inspection in Global Secure Access Internet Access

Il primo passaggio è abilitare l’ispezione TLS in Global Secure Access Internet Access. Questa fase è essenziale perché l’analisi dei file inviati verso applicazioni internet richiede la decrittazione del traffico HTTPS, così da applicare i controlli di filtering e inoltrare i contenuti a Microsoft Purview per l’analisi.

In questa fase è importante verificare che il traffico degli utenti sia effettivamente instradato tramite il profilo corretto di Internet Access e che i dispositivi rispettino i prerequisiti del servizio.

L’ispezione TLS costituisce infatti la base tecnica dei controlli successivi di network content filtering.

Figura 2 – Abilitazione profilo Internet Access

Nel Microsoft Entra admin center, aprite Global Secure Access, selezionate Secure e, nella sezione TLS inspection settings, fate clic su Create certificate.

Nella scheda visualizzata, compilate i seguenti parametri con dei riferimenti alla vostra organizzazione:

• Certificate name;
• Common name;
• Organization name.

Figura 3 – Creazione certificato per TLS inspection

Facendo clic su Create CSR, il file viene scaricato automaticamente sul dispositivo.

N.B. Prestate attenzione alla firma del certificato: nel mio ambiente di test ho utilizzato OpenSSL, mentre in produzione è consigliabile usare la Certification Authority aziendale per emettere un certificato intermedio dedicato alla TLS inspection. Per maggiori informazioni, vi rimando alla doc ufficiale Configure Transport Layer Security Inspection Settings – Global Secure Access | Microsoft Learn.

Figura 4 – Upload del certificato firmato TLS inspection

Una volta completata la procedura di firma e del caricamento nel portale, procedete all’abilitazione del certificato.

Figura 5 – Abilitazione del certificato per TLS inspection

A questo punto, spostatevi nella scheda TLS inspection policies e create la policy dedicata.

Figura 6 – Creazione policy TLS inspection

Indicate un nome parlante alla policy e come action selezionate Inspect.

Figura 7 – Creazione policy TLS inspection

A questo punto, come da seguenti immagini, create una regola di TLS inspection per i siti appartenenti alla categoria Artificial Intelligence.

Figura 8 – Creazione della regola TLS inspection

Nella schermata successiva, configurate i parametri della regola, come nome, priorità, stato e azione (Inspection). Come categoria, nel mio caso, ho selezionato Artificial Intelligence.

Figura 9 – Criteri della regola TLS inspection

Figura 10 – Selezione della categoria AI nella regola TLS inspection dedicata

Figura 11 – Summary regola TLS inspection

Configurazione della web content filtering policy (v2) per applicazioni AI

Una volta predisposta l’ispezione TLS, il passaggio successivo consiste nel configurare il web content filtering in modo da consentire l’accesso alle categorie AI necessarie al test. Nel mio scenario ho configurato la categoria relativa alle applicazioni di AI in modalità Allow, così da permettere il raggiungimento di ChatGPT e concentrare il controllo non sull’accesso all’applicazione, ma sul contenuto del file trasferito.

Recatevi nella sezione Web content filtering policies e, come mostrato nelle immagini seguenti, consiglio di configurare la policy utilizzando la nuova versione 2.

Figura 12 – Utilizzo della versione 2 per la creazione della web content filtering policy

Fate clic su Create policy e, come mostrato nelle immagini seguenti, specificate il nome della policy e impostate l’azione su Allow.

Figura 13 – Creazione Web filtering policy

Figura 14 – Nome della web content policy

Figura 15 – Azione della web content policy

Figura 16 – Overview della web content filtering policy

Cliccate sulla policy appena creata e procedete con la creazione della regola per consentire l’accesso ai siti della categoria AI.

Figura 17 – Policy Web Filtering creata

Figura 18 – Creazione della regola di web filtering

Figura 19 – Creazione della regola WF

Configurazione della content policy in GSA Internet Access

A questo punto si può creare una content policy dedicata al traffico internet, utilizzando l’azione Scan with Purview. Questo è l’elemento chiave dell’integrazione: Global Secure Access intercetta il file in transito e lo sottopone all’analisi di Microsoft Purview, che applica classificazione e valutazione in base alle policy DLP definite.
Nel wizard della policy è importante definire correttamente le condizioni di applicazione, la tipologia di traffico da sottoporre a scansione e l’azione desiderata. In questo scenario l’obiettivo non è un semplice filtro per MIME type, ma un’ispezione orientata al contenuto reale del file, così da poter rilevare informazioni sensibili, etichette di sensibilità o altri indicatori gestiti da Purview.

In Microsoft Entra admin center, aprite Global Secure Access, selezionate Secure e, nella sezione Content policies, fate clic su Create policy.

Figura 20 – Creazione content policy in Global Secure Access

Indicate un nome parlate alla policy e procedete con il wizard.

Figura 21 – Definizione nome della content policy in GSA

Nella scheda Rules, fate clic su Add rule.

Figura 22 – Creazione regola per la content policy

Come mostrato nell’immagine seguente, configurate questi parametri:

• Rule name;
• Priority;
• Status: Enabled
• Action: Scan with Purview
• Activities: Upload
• File content types: tipi di file da sottoporre alla scansione di Purview
• Destination: categorie o siti interessati; nel mio caso ho selezionato la stessa categoria usata nelle altre policy, cioè AI.

Figura 23 – Configurazione della content policy rule

Figure 24 – Configurazione della content policy rule

Figura 25 – Configurazione della content policy rule

Configurazione del security profile in Global Secure Access

Completata la configurazione delle policy di TLS Inspection, Web content filtering e content, è necessario associarle a un security profile in GSA. Il security profile rappresenta il contenitore logico che mette insieme le policy di sicurezza da applicare al traffico degli utenti e che viene poi richiamato nel processo di instradamento e applicazione delle regole.

Questo passaggio è particolarmente importante perché consente di collegare le policy in modo coerente nello stesso flusso operativo. In pratica, senza la corretta associazione della policy al security profile, il traffico può transitare nel servizio ma non essere sottoposto ai controlli attesi.

Recatevi nella sezione Security profiles e procedete con la creazione.

Figura 26 – Creazione security profile in GSA

Assegnate al profilo un nome descrittivo, che selezionerete successivamente nella policy di Conditional Access.

Figura 27 -Creazione de Security profile in GSA

Linkate tutte le policy (Web Filtering Policy V2, TLS inspection e Content Policy) create in precedenza.

Figura 28 – Link delle policy al security profile in GSA

Creazione e assegnazione della Conditional Access Policy

Dopo aver definito il security profile, è necessario creare e assegnare una Conditional Access Policy che consenta di applicare in modo mirato il profilo di sicurezza agli utenti o ai gruppi coinvolti nello scenario. Questo passaggio è fondamentale perché rappresenta il collegamento tra l’identità dell’utente, il contesto di accesso e i controlli di sicurezza di rete applicati da Global Secure Access.

Nel mio caso, la policy di Conditional Access viene utilizzata per associare correttamente lo scenario di navigazione protetta agli utenti target, facendo in modo che il traffico diretto verso internet venga valutato secondo il percorso previsto da Global Secure Access.

Il mio consiglio è di creare una policy di Conditional Access dedicata. In fase di configurazione, selezionate come Target resources “All internet resources with Global Secure Access” e, nella sezione Session, il security profile creato in precedenza.

Figura 29 – Creazione policy di Conditional Access per GSA/Scan with Purview

Figura 30 – Definizione del security profile nella policy di Conditional Access

Configurazione della policy DLP dedicata in Microsoft Purview

Dopo aver completato la parte di configurazione lato rete, si passa in Microsoft Purview per creare una policy DLP dedicata allo scenario di Inline Web Traffic o comunque al perimetro di Network Data Security, in base all’esperienza disponibile nel tenant. Qui definiamo le condizioni di rilevamento, ad esempio Sensitive Information Types, etichette o altre condizioni di contenuto, e l’azione da applicare quando un file viene caricato verso una destinazione non gestita.

L’aspetto interessante è che si riutilizzano i meccanismi di classificazione già noti di Purview, mantenendo quindi coerenza con gli altri scenari DLP dell’organizzazione. In questo modo si può proteggere il traffico verso applicazioni AI senza creare una logica di controllo separata rispetto alle policy già usate per endpoint o servizi Microsoft 365.

Prima di creare la policy DLP, verificate di aver configurato nel portale la sottoscrizione Azure e un resource group dedicato a Purview nella sezione Settings > Account.

Figura 31 – Purview Azure resource link pay-as-you-go

Ora potete procedere con la configurazione della policy DLP dedicata. Nella fase iniziale, selezionate l’opzione Inline web traffic.

Figura 32 – Inline web traffic DLP policy

Figura 33 – Definizione nome policy DLP

Figura 34 – Selezione delle cloud app da coprire con la policy DLP

Nella schermata successiva, selezionate Adaptive app scopes e fate clic su All unmanaged AI apps.

Figura 35 – Selezione delle app AI unmanaged come scope della policy DLP

Poiché questa guida è focalizzata sull’integrazione con Global Secure Access, nella schermata successiva ho mantenuto come ambito di rilevamento Network and non-Microsoft secure browser.

Figura 36 Network and non-Microsoft secure browser

Nel mio scenario ho configurato una regola per rilevare contenuti sensibili (custom SIT) nei file caricati verso applicazioni AI, impostando per il test un’azione di blocco. In base alle vostre esigenze, potete definire i criteri di rilevamento più adatti per la policy DLP. Per approfondire condizioni e configurazione, vi rimando al blog post dedicato Microsoft Purview: Data Loss Prevention (DLP) – ICT Power.

Figura 37 – Criterio policy DLP

Infine, definite l’azione da applicare, ad esempio il blocco dell’upload dei file.

Figura 38 – Azione di blocco nell’upload di file nella policy DLP

Test finale su ChatGPT e differenze rispetto a Endpoint DLP

Con la configurazione completata, il passaggio finale consiste nell’effettuare un test reale di upload di un file verso ChatGPT. Questo consente di verificare che il traffico venga intercettato da Global Secure Access, analizzato attraverso la content policy e valutato da Microsoft Purview in base alle condizioni DLP configurate.

Dal punto di vista operativo, uno degli aspetti più interessanti è il confronto con Endpoint DLP. In uno scenario Endpoint DLP la visibilità e il controllo sono legati al dispositivo, al browser e all’integrazione locale del client. Con Network Data Security, invece, la prospettiva è diversa: il controllo avviene sul traffico che attraversa il layer di sicurezza di rete, con log e segnali che riflettono il passaggio del contenuto attraverso Global Secure Access e l’integrazione con Purview.

Figura 39 – User Experience nell’upload di file su Chatgpt

Figure 10 – Traffic log Internet Access

Figura 41 – DLP rule match – Network Data Security

Figure 42 – DLP rule match – Esempio Endpoint DLP rule match

Questo significa che i due approcci non sono necessariamente alternativi, ma complementari: Endpoint DLP offre un punto di osservazione strettamente legato all’azione dell’utente sul device, mentre Network Data Security permette di estendere il controllo a livello di traffico web, soprattutto in scenari di upload verso servizi esterni e applicazioni AI non gestite.

Nei log ci si può quindi aspettare una diversa granularità e una diversa origine dell’evento: nel caso della protezione di rete, il match è strettamente associato al flusso HTTP/HTTPS e alla relativa scansione inline del file, mentre in Endpoint DLP l’evento è più strettamente connesso al contesto applicativo e all’azione eseguita sul dispositivo.

Conclusioni

Microsoft Purview DLP Network Data Security rappresenta un’estensione molto interessante del modello di protezione dei dati, perché consente di portare la classificazione e l’enforcement anche sul traffico web verso applicazioni esterne, incluse le piattaforme di AI generativa. Integrando Global Secure Access con Microsoft Purview, si ottiene un controllo più ampio rispetto ai soli scenari endpoint, con la possibilità di intercettare upload di file e applicare protezioni coerenti con le policy aziendali.

Per chi volesse approfondire, vi riporto la documentazione ufficiale Learn about Microsoft Purview Network Data Security | Microsoft Learn