E-postfiltrering över en VPN: var innehållsreglerna faktiskt körs

Den här förfrågan låter som ett nätverksproblem: hindra en viss sorts bilaga från att lämna byggnaden, och VPN:en finns redan, så använd den. Den ramen brister vid den första fråga som filtret måste besvara. Innehållsregler behöver se meddelandet, och meddelandet blir synligt på ett annat lager än tunneln. Jag följer mejlvägen utåt från paketet och stannar vid den första plats där de nödvändiga uppgifterna faktiskt finns.

Tre lager är oberoende: VPN-transporten, SMTP TLS-anslutningen och meddelandets egen kryptering. Var och en slutar någon annanstans.

Börja vid lagret som kan se meddelandet

VPN-avkapsling ger dig den inre nätverkstrafiken. Om mejlklienten öppnade en TLS-anslutning till en insändningsserver innehåller den inre trafiken fortfarande den TLS-strömmen, inte läsbar post.

Så en paketinsamling vid tunnelkanten svarar på en annan fråga än „innehåller det här meddelandet en otillåten bilaga“.

SMTP TLS-avslutning slutar vid kuvertet

Avslutning av SMTP TLS på mejlservern blottlägger meddelandet så som det lämnades in till den slutpunkten. Servern ser rubriker, kuvertet och MIME-strukturen. Det räcker för många innehållsregler. Kuvertet talar om avsändare och mottagare så som servern förstod dem.

Det räcker inte för ett meddelande som skyddas med S/MIME. Servern tar emot en skyddad enhet och kan utan rätt nycklar inte läsa innehållet inuti. Samma gräns gäller för en krypterad bilaga som anländer intakt.

Försvaga inte transportskyddet för att göra en passiv insamling läsbar. Det ändrar arkitekturen i stället för att placera regeln där data finns.

S/MIME slutar där nycklarna finns

S/MIME skyddar MIME-meddelandets data, så gränsen är nyckelmaterialet och den auktoriserade dekrypteringen. Ett filter utan dessa nycklar kan fortfarande agera på synliga metadata eller på förekomsten av ett skyddat objekt, men det är ett annat resultat.

Om organisationen driver en auktoriserad krypteringsgateway eller en hanterad slutpunktskontroll ska du dokumentera var klartext finns, vilken identitet som får granska den och hur nycklar och register skyddas. Det finns ingen huvudnyckel som skapas genom att dirigera trafik genom en VPN.

Skriv ned det innan någon lovar klartextklassificering. Löftet är den del som är svår att ta tillbaka.

Placera regeln i mejlplattformen

Om den godkända mejlservern tar emot det läsbara meddelandet är dess innehållsfilterintegration som stöds den punkt där regeln verkställs. Det skiljer sig från att tillåta en SMTP-anslutning genom en brandvägg. Den skillnaden avgör om regeln kan avvisa, sätta i karantän eller bara annotera.

Postfix dokumenterar till exempel innehållsfiltrering efter kön: mejl köas, skickas till ett filter och återförs till leveransvägen. Dess ordning efter kön skiljer sig från proxyalternativen före kön och Milter som samma guide hänvisar till. Välj den integration som stöds och felbeteendet för den mejltjänst du faktiskt kör.

En bilageregel är inte ett fullständigt dataläckageskydd. Uppladdningar från webbläsaren, delad lagring och slutpunktsåtgärder behöver egna kontroller.

Skriv acceptanstestet med syntetiska meddelanden

Testa med godkända syntetiska exempel: ett tillåtet meddelande, en otillåten innehållsåtgärd och den deklarerade hanteringen av kryptering på meddelandenivå. Ta med vad mejltjänsten gör när filtret inte är tillgängligt.

Det användbara resultatet namnger åtgärden, verkställighetspunkten och de data som syns där. „VPN:en dekrypterade det“ svarar på ett lager och kan inte ersätta mejlapplikationens innehålls- och auktoriseringsmodell.