Filtraggio delle email su una VPN: dove vengono eseguite davvero le regole sui contenuti

Questa richiesta suona come un problema di rete: impedire a un certo tipo di allegato di uscire dall’edificio, e la VPN è già lì, quindi usatela. Questa impostazione si rompe alla prima domanda a cui il filtro deve rispondere. Le regole sui contenuti devono vedere il messaggio, e il messaggio diventa visibile a uno strato diverso da quello del tunnel. Percorro il percorso della posta verso l’esterno dal pacchetto e mi fermo nel primo punto in cui i dati richiesti esistono davvero.

Tre strati sono indipendenti: il trasporto VPN, la connessione SMTP TLS e la cifratura propria del messaggio. Ognuno termina in un punto diverso.

Iniziate dallo strato che può vedere il messaggio

La decapsulazione VPN fornisce il traffico di rete interno. Se il client di posta ha aperto una connessione TLS verso un server di invio, il traffico interno contiene ancora quel flusso TLS, non posta leggibile.

Quindi una cattura di pacchetti presa al bordo del tunnel risponde a una domanda diversa da «questo messaggio contiene un allegato vietato».

La terminazione SMTP TLS termina all’envelope

Terminare SMTP TLS sul server di posta espone il messaggio così com’è stato inviato a quel punto. Il server vede le intestazioni, l’envelope e la struttura MIME. Questo basta per molte regole sui contenuti. L’envelope indica il mittente e i destinatari come il server li ha intesi.

Non basta per un messaggio protetto con S/MIME. Il server riceve un’entità protetta e, senza le chiavi pertinenti, non può leggere il contenuto al suo interno. Lo stesso limite vale per un allegato cifrato che arriva intatto.

Non indebolite la sicurezza del trasporto per rendere leggibile una cattura passiva. Questo cambia l’architettura invece di collocare la regola dove sono i dati.

S/MIME termina dove sono le chiavi

S/MIME protegge i dati del messaggio MIME, quindi il suo confine è il materiale delle chiavi e l’accordo di decifratura autorizzato. Un filtro senza quelle chiavi può ancora agire su metadati visibili o sulla presenza di un oggetto protetto, ma è un risultato diverso.

Se l’organizzazione gestisce un gateway di cifratura autorizzato o un controllo gestito degli endpoint, documentate dove esiste il testo in chiaro, quale identità può ispezionarlo e come sono protetti chiavi e registri. Non esiste alcuna chiave principale creata instradando il traffico attraverso una VPN.

Scrivetelo prima che qualcuno prometta la classificazione del testo in chiaro. La promessa è la parte difficile da ritirare.

Collocate la regola nella piattaforma di posta

Se il server di posta approvato riceve il messaggio leggibile, la sua integrazione di filtraggio dei contenuti supportata è il punto di applicazione. È diverso dal consentire una connessione SMTP attraverso un firewall. Quella distinzione decide se la regola può rifiutare, mettere in quarantena o solo annotare.

Postfix, per esempio, documenta il filtraggio dei contenuti dopo la coda: la posta viene messa in coda, passata a un filtro e restituita al percorso di consegna. La sua disposizione dopo la coda è diversa dalle opzioni proxy prima della coda e Milter a cui fa riferimento la stessa guida. Scegliete l’integrazione supportata e il comportamento in caso di guasto per il servizio di posta che gestite davvero.

Una regola sugli allegati non è un programma completo contro la perdita di dati. I caricamenti dal browser, l’archiviazione condivisa e le azioni sugli endpoint richiedono controlli propri.

Scrivete il test di accettazione con messaggi sintetici

Provate con esempi sintetici approvati: un messaggio consentito, un’azione sui contenuti vietata e la gestione dichiarata della cifratura a livello di messaggio. Includete cosa fa il servizio di posta quando il suo filtro non è disponibile.

Il risultato utile nomina l’azione, il punto di applicazione e i dati visibili lì. «La VPN l’ha decifrato» risponde a uno strato e non può sostituire il modello di contenuto e autorizzazione dell’applicazione di posta.