E-mailfiltrering over en VPN: hvor indholdsreglerne faktisk kører

Denne anmodning lyder som et netværksproblem: stop en bestemt slags vedhæftning i at forlade bygningen, og VPN’en er der allerede, så brug den. Den ramme bryder sammen ved det første spørgsmål, filteret skal besvare. Indholdsregler skal kunne se meddelelsen, og meddelelsen bliver synlig i et andet lag end tunnelen. Jeg følger postens vej udad fra pakken og stopper ved det første sted, hvor de nødvendige data faktisk findes.

Tre lag er uafhængige: VPN-transporten, SMTP TLS-forbindelsen og meddelelsens egen kryptering. Hvert af dem ender et forskelligt sted.

Begynd ved det lag, der kan se meddelelsen

VPN-afkapsling giver dig den indre netværkstrafik. Hvis mailklienten åbnede en TLS-forbindelse til en afsendelsesserver, indeholder den indre trafik stadig den TLS-strøm, ikke læsbar post.

Så en pakkeoptagelse ved tunnelkanten besvarer et andet spørgsmål end „indeholder denne meddelelse en forbudt vedhæftning“.

SMTP TLS-afslutning ender ved konvolutten

Afslutning af SMTP TLS på mailserveren blotlægger meddelelsen, som den blev afleveret til det endepunkt. Serveren ser headere, konvolutten og MIME-strukturen. Det er nok til mange indholdsregler. Konvolutten fortæller dig afsender og modtagere, som serveren forstod dem.

Det er ikke nok til en S/MIME-beskyttet meddelelse. Serveren modtager en beskyttet enhed, og uden de relevante nøgler kan den ikke læse indholdet indeni. Den samme begrænsning gælder for en krypteret vedhæftning, der ankommer intakt.

Svæk ikke transportsikkerheden for at gøre en passiv optagelse læsbar. Det ændrer arkitekturen i stedet for at placere reglen der, hvor dataene er.

S/MIME ender der, hvor nøglerne er

S/MIME beskytter MIME-meddelelsesdata, så dens grænse er nøglematerialet og den autoriserede dekrypteringsordning. Et filter uden disse nøgler kan stadig handle på synlige metadata eller på tilstedeværelsen af et beskyttet objekt, men det er et andet resultat.

Hvis organisationen kører en autoriseret krypteringsgateway eller en administreret endepunktskontrol, så dokumentér, hvor klartekst findes, hvilken identitet der må inspicere den, og hvordan nøgler og registreringer beskyttes. Der findes ingen hovednøgle, som skabes ved at rute trafik gennem en VPN.

Skriv det ned, før nogen lover klartekstklassificering. Løftet er den del, der er svær at trække tilbage.

Sæt reglen i mailplatformen

Hvis den godkendte mailserver modtager den læsbare meddelelse, er dens understøttede indholdsfiltreringsintegration håndhævelsespunktet. Det er noget andet end at tillade en SMTP-forbindelse gennem en firewall. Den forskel afgør, om reglen kan afvise, sætte i karantæne eller kun annotere.

Postfix dokumenterer for eksempel indholdsfiltrering efter køen: post sættes i kø, sendes til et filter og returneres til leveringsvejen. Dets ordning efter køen er forskellig fra proxyvalgene før køen og Milter, som samme vejledning henviser til. Vælg den understøttede integration og fejladfærd for den mailtjeneste, du faktisk kører.

Én vedhæftningsregel er ikke et fuldstændigt datatab-program. Browseruploads, delt lager og endepunktshandlinger har brug for deres egne kontroller.

Skriv accepttesten med syntetiske meddelelser

Test med godkendte syntetiske eksempler: en tilladt meddelelse, en forbudt indholdshandling og den erklærede håndtering af kryptering på meddelelsesniveau. Medtag, hvad mailtjenesten gør, når dens filter ikke er tilgængeligt.

Det nyttige resultat navngiver handlingen, håndhævelsespunktet og de data, der er synlige der. „VPN’en dekrypterede den“ besvarer et lag og kan ikke erstatte mailapplikationens indholds- og autorisationsmodel.