Perché una regola VPN non può fermare il caricamento di un file
Raggiungere un servizio e controllare quali file ne escono sono due requisiti. Metti la regola dove il file è visibile: posta, applicazione o agente endpoint.
Un piccolo team chiede l'accesso remoto ai propri sistemi di lavoro e, nello stesso respiro, chiede che alcuni allegati smettano di uscire dall'azienda. Entrambe le richieste suonano come un solo cambiamento VPN. Sono due requisiti con punti di applicazione diversi, e una regola che soddisfa il primo non fa nulla per il secondo. Inizia dando un nome all'azione e ai dati, poi scegli il componente che può davvero vederli.
Una richiesta, due requisiti
Il primo requisito riguarda la raggiungibilità: quali utenti e dispositivi possono aprire una connessione verso quale servizio. Il secondo riguarda il comportamento una volta che quella connessione esiste: quali documenti possono essere allegati, incollati o caricati. Un tunnel agisce sul primo ed è cieco al secondo per progettazione.
Un controllo a livello IP inoltra pacchetti. Non analizza un caricamento multipart, non ispeziona un PDF e non decide se un foglio di calcolo contiene numeri di conto. Aspettarsi che lo faccia non è un errore di configurazione; è un errore di categoria.
Dì il requisito ad alta voce in quella forma prima di cercare un prodotto. «Gli utenti possono raggiungere il portale dei file» e «gli utenti non possono caricare elenchi di clienti sul portale dei file» sono frasi diverse, e solo la seconda descrive una politica dei contenuti.
Scegli il componente che può vedere il file
L'applicazione deve avvenire dove il file è leggibile. Per la posta è di solito la piattaforma o il gateway di posta, che già gestisce gli allegati e può valutarli prima della consegna. Per i caricamenti dal browser verso un servizio autorizzato, l'applicazione stessa può essere l'unica parte che vede il contenuto. Per un portatile gestito che copia file su supporti rimovibili, un agente endpoint vede l'operazione.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
Alcune suite commerciali di accesso remoto raggruppano un agente endpoint, un controllo web e un modulo di prevenzione della perdita di dati. Questi componenti possono benissimo applicare una politica dei contenuti, ma la capacità appartiene al modulo e non al tunneling. Leggi cosa include davvero la suite prima di promettere il risultato.
La panoramica sulla prevenzione della perdita di dati di Purview di Microsoft è un modello utile per il confronto: descrive le politiche in termini di tipi di informazioni sensibili, posizioni e attività. Quel vocabolario riguarda contenuti e azioni, non prefissi IP.
TLS sopravvive al tunnel, quindi pianificalo
La cifratura dell'applicazione è negoziata tra il client e il servizio, e un tunnel VPN trasporta quei byte senza aprirli. Un gateway sul percorso non acquisisce quindi automaticamente la capacità di classificare un allegato, per quanta parte della rotta possieda.
Per ispezionare i contenuti in transito serve un componente che termini TLS con un certificato attendibile, e questa è una decisione architetturale importante con proprie conseguenze sulla privacy e sulle operazioni. Non è una casella nel profilo VPN. I client devono fidarsi del certificato di ispezione, le applicazioni che fissano i certificati si romperanno e l'operatore ottiene la capacità di leggere traffico che prima non poteva. Queste sono le ragioni per cui questa decisione spetta a un responsabile della sicurezza e non a chi gestisce il tunnel.
Per questo la risposta onesta a «la VPN può bloccare questo caricamento» di solito è no, seguita da un'alternativa concreta. L'alternativa può essere restrizioni a livello di applicazione, una regola di posta o una politica endpoint, e ciascuna ha un responsabile che può cambiarla.
Scrivi il test di accettazione prima della regola
Una regola sui contenuti richiede due esempi, non uno: un'azione consentita che deve continuare a funzionare e un'azione vietata che deve essere fermata. Prova entrambe dalle applicazioni e dai dispositivi nell'ambito, perché una politica che funziona solo in un browser non è la politica che qualcuno ha chiesto.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadLa prima richiesta dovrebbe essere rifiutata dal componente che possiede la regola, e la seconda dovrebbe riuscire. Se entrambe riescono, il controllo non è sul percorso. Se entrambe falliscono, hai rotto il servizio invece di proteggerlo, che è il risultato più comune di una regola scritta senza un esempio consentito.
Decidi in anticipo cosa vede l'utente, chi può concedere un'eccezione e dove un amministratore conferma la decisione in seguito. Un caricamento bloccato senza messaggio produce un ticket di assistenza, e una regola che nessuno può verificare produce una discussione. Entrambe si evitano con una frase di documentazione scritta prima che la politica entri in vigore.
Infine, tieni i due requisiti in ticket separati con responsabili separati. Raggrupparli sotto «VPN» garantisce che al team di rete venga chiesto di risolvere un problema di contenuti e che il problema dei contenuti venga dichiarato risolto quando il tunnel sale.