Filtratge de correu sobre una VPN: on s’executen realment les regles de contingut

Aquesta petició sona com un problema de xarxa: atureu un cert tipus de fitxer adjunt perquè no surti de l’edifici, i la VPN ja hi és, així que feu-la servir. Aquest plantejament es trenca a la primera pregunta que el filtre ha de respondre. Les regles de contingut necessiten veure el missatge, i el missatge es fa visible en una capa diferent de la del túnel. Recorrec el camí del correu cap enfora des del paquet i m’aturo al primer lloc on les dades necessàries existeixen realment.

Tres capes són independents: el transport VPN, la connexió SMTP TLS i el xifratge propi del missatge. Cadascuna acaba en un lloc diferent.

Comenceu per la capa que pot veure el missatge

La desencapsulació VPN us dona el trànsit de xarxa interior. Si el client de correu ha obert una connexió TLS a un servidor de tramesa, el trànsit interior encara conté aquest flux TLS, no correu llegible.

Per tant, una captura de paquets feta a la vora del túnel respon una pregunta diferent de «conté aquest missatge un fitxer adjunt prohibit».

La terminació d’SMTP TLS acaba al sobre

Terminar SMTP TLS al servidor de correu exposa el missatge tal com es va trametre a aquest punt. El servidor veu les capçaleres, el sobre i l’estructura MIME. Això és suficient per a moltes regles de contingut. El sobre us diu el remitent i els destinataris tal com el servidor els va entendre.

No és suficient per a un missatge protegit amb S/MIME. El servidor rep una entitat protegida i, sense les claus pertinents, no pot llegir el contingut que hi ha a dins. El mateix límit s’aplica a un fitxer adjunt xifrat que arriba intacte.

No debiliteu la seguretat del transport per fer llegible una captura passiva. Això canvia l’arquitectura en lloc de posar la regla on són les dades.

S/MIME acaba on són les claus

S/MIME protegeix les dades del missatge MIME, així que la seva frontera és el material de claus i l’acord de desxifratge autoritzat. Un filtre sense aquestes claus encara pot actuar sobre metadades visibles o sobre la presència d’un objecte protegit, però és un resultat diferent.

Si l’organització executa una passarel·la de xifratge autoritzada o un control gestionat de punts finals, documenteu on existeix text en clar, quina identitat el pot inspeccionar i com es protegeixen les claus i els registres. No hi ha cap clau mestra creada per encaminar el trànsit per una VPN.

Escriviu-ho abans que algú prometi classificació de text en clar. La promesa és la part difícil de retirar.

Poseu la regla a la plataforma de correu

Si el servidor de correu aprovat rep el missatge llegible, la seva integració de filtratge de contingut compatible és el punt d’aplicació. Això és diferent de permetre una connexió SMTP a través d’un tallafoc. Aquesta distinció decideix si la regla pot rebutjar, posar en quarantena o només anotar.

Postfix, per exemple, documenta el filtratge de contingut després de la cua: el correu es posa a la cua, es passa a un filtre i es retorna al camí de lliurament. La seva disposició després de la cua és diferent de les opcions de proxy abans de la cua i Milter que la mateixa guia esmenta. Trieu la integració compatible i el comportament de fallada per al servei de correu que realment executeu.

Una regla de fitxers adjunts no és un programa complet contra la pèrdua de dades. Les pujades des del navegador, l’emmagatzematge compartit i les accions als punts finals necessiten controls propis.

Escriviu la prova d’acceptació amb missatges sintètics

Proveu amb exemples sintètics aprovats: un missatge permès, una acció de contingut prohibida i el tractament declarat del xifratge a nivell de missatge. Incloeu què fa el servei de correu quan el seu filtre no està disponible.

El resultat útil anomena l’acció, el punt d’aplicació i les dades visibles allà. «La VPN ho va desxifrar» respon una capa i no pot substituir el model de contingut i autorització de l’aplicació de correu.