E-posfiltering oor 'n VPN: waar inhoudsreëls werklik uitgevoer word

Hierdie versoek klink na 'n netwerkprobleem: keer dat 'n sekere soort aanhegsel die gebou verlaat, en die VPN is reeds daar, so gebruik dit. Daardie raamwerk breek by die eerste vraag wat die filter moet beantwoord. Inhoudsreëls moet die boodskap sien, en die boodskap word op 'n ander laag as die tonnel sigbaar. Ek volg die e-posroete uitwaarts vanaf die pakkie en stop by die eerste plek waar die vereiste data werklik bestaan.

Drie lae is onafhanklik: die VPN-vervoer, die SMTP TLS-verbinding en die boodskap se eie enkripsie. Elkeen eindig op 'n ander plek.

Begin by die laag wat die boodskap kan sien

VPN-ontsluiting gee jou die binneste netwerkverkeer. As die e-poskliënt 'n TLS-verbinding na 'n indieningsbediener oopgemaak het, bevat die binneste verkeer steeds daardie TLS-stroom, nie leesbare e-pos nie.

Dus beantwoord 'n pakkie-opname by die tonnelrand 'n ander vraag as “bevat hierdie boodskap 'n verbode aanhegsel”.

SMTP TLS-beëindiging eindig by die koevert

Om SMTP TLS by die e-posbediener te beëindig, lê die boodskap bloot soos dit by daardie eindpunt ingedien is. Die bediener sien koptekste, die koevert en die MIME-struktuur. Dit is genoeg vir baie inhoudsreëls. Die koevert vertel jou die afsender en ontvangers soos die bediener hulle verstaan het.

Dit is nie genoeg vir 'n S/MIME-beskermde boodskap nie. Die bediener ontvang 'n beskermde entiteit, en sonder die betrokke sleutels kan hy nie die inhoud daarbinne lees nie. Dieselfde beperking geld vir 'n geënkripteerde aanhegsel wat ongeskend aankom.

Moet nie vervoersekuriteit verswak om 'n passiewe opname leesbaar te maak nie. Dit verander die argitektuur in plaas daarvan om die reël te plaas waar die data is.

S/MIME eindig waar die sleutels is

S/MIME beskerm MIME-boodskapdata, so sy grens is die sleutelmateriaal en die gemagtigde ontsluitingsreëling. 'n Filter sonder daardie sleutels kan steeds op sigbare metadata of op die teenwoordigheid van 'n beskermde objek reageer, maar dit is 'n ander resultaat.

As die organisasie 'n gemagtigde enkripsiepoort of 'n bestuurde eindpuntbeheer bedryf, dokumenteer waar gewone teks bestaan, watter identiteit dit mag inspekteer en hoe sleutels en rekords beskerm word. Daar is geen meestersleutel wat geskep word deur verkeer deur 'n VPN te lei nie.

Skryf dit neer voordat iemand gewone-teks-klassifikasie belowe. Die belofte is die deel wat moeilik is om terug te trek.

Plaas die reël in die e-posplatform

As die goedgekeurde e-posbediener die leesbare boodskap ontvang, is sy ondersteunde inhoudsfilter-integrasie die handhawingspunt. Dit verskil van om 'n SMTP-verbinding deur 'n firewall toe te laat. Daardie onderskeid bepaal of die reël kan verwerp, in kwarantyn kan plaas of net kan annoteer.

Postfix dokumenteer byvoorbeeld inhoudsfiltrering na die tou: e-pos word in die tou geplaas, aan 'n filter oorgedra en na die afleweringsroete teruggekeer. Sy reëling na die tou verskil van die voor-die-tou-volmag en die Milter-opsies waarna dieselfde gids verwys. Kies die ondersteunde integrasie en falinggedrag vir die e-posdiens wat jy werklik bedryf.

Een aanhegselreël is nie 'n volledige program teen datalekkasie nie. Blaaier-oplaaie, gedeelde berging en eindpuntaksies benodig hul eie beheermaatreëls.

Skryf die aanvaardingstoets met sintetiese boodskappe

Toets met goedgekeurde sintetiese voorbeelde: 'n toegelate boodskap, 'n verbode inhoudsaksie en die verklaarde hantering van boodskapvlak-enkripsie. Sluit in wat die e-posdiens doen wanneer sy filter onbeskikbaar is.

Die nuttige resultaat noem die aksie, die handhawingspunt en die data wat daar sigbaar is. “Die VPN het dit ontsyfer” beantwoord een laag en kan nie die e-posprogram se inhouds- en magtigingsmodel vervang nie.