Retpoŝta filtrado tra VPN: kie la enhavaj reguloj efektive funkcias

Ĉi tiu peto sonas kiel reta problemo: haltigu certan specon de aldonaĵo eliri la konstruaĵon, kaj la VPN jam estas tie, do uzu ĝin. Tiu kadro rompiĝas ĉe la unua demando, kiun la filtrilo devas respondi. Enhavaj reguloj bezonas vidi la mesaĝon, kaj la mesaĝo fariĝas videbla sur alia tavolo ol la tunelo. Mi iras la retpoŝtan vojon eksteren de la paketo kaj haltas ĉe la unua loko, kie la bezonataj datumoj vere ekzistas.

Tri tavoloj estas sendependaj: la VPN-transporto, la SMTP TLS-konekto kaj la propra ĉifrado de la mesaĝo. Ĉiu finiĝas aliloke.

Komencu ĉe la tavolo, kiu povas vidi la mesaĝon

Malenkapsuligo de VPN donas al vi la internan retan trafikon. Se la retpoŝta kliento malfermis TLS-konekton al sendoservilo, la interna trafiko ankoraŭ enhavas tiun TLS-fluon, ne legeblan poŝton.

Do paketa kaptaĵo prenita ĉe la tunela rando respondas al alia demando ol „ĉu ĉi tiu mesaĝo enhavas malpermesitan aldonaĵon“.

Fino de SMTP TLS finiĝas ĉe la koverto

Fini SMTP TLS ĉe la retpoŝta servilo malkaŝas la mesaĝon tiel, kiel ĝi estis sendita al tiu finpunkto. La servilo vidas kapliniojn, la koverton kaj la MIME-strukturon. Tio sufiĉas por multaj enhavaj reguloj. La koverto diras al vi la sendinton kaj la ricevantojn tiel, kiel la servilo komprenis ilin.

Tio ne sufiĉas por mesaĝo protektita per S/MIME. La servilo ricevas protektitan enton, kaj sen la koncernaj ŝlosiloj ĝi ne povas legi la enhavon interne. La sama limo validas por ĉifrita aldonaĵo, kiu alvenas sendifekte.

Ne malfortigu transportan sekurecon por fari pasivan kaptaĵon legebla. Tio ŝanĝas la arkitekturon anstataŭ meti la regulon tie, kie la datumoj estas.

S/MIME finiĝas tie, kie estas la ŝlosiloj

S/MIME protektas la datumojn de MIME-mesaĝo, do ĝia limo estas la ŝlosilmaterialo kaj la rajtigita malĉifra aranĝo. Filtrilo sen tiuj ŝlosiloj ankoraŭ povas agi sur videblaj metadatumoj aŭ sur la ĉeesto de protektita objekto, sed tio estas alia rezulto.

Se la organizo funkciigas rajtigitan ĉifran enirejon aŭ administritan kontrolon de finpunktoj, dokumentu, kie ekzistas klarteksto, kiu identeco rajtas inspekti ĝin, kaj kiel ŝlosiloj kaj rikordoj estas protektitaj. Ne ekzistas ĉefa ŝlosilo kreita per enkursigo de trafiko tra VPN.

Skribu tion antaŭ ol iu promesos klartekstan klasifikon. La promeso estas la parto, kiun estas malfacile retiri.

Metu la regulon en la retpoŝtan platformon

Se la aprobita retpoŝta servilo ricevas la legeblan mesaĝon, ĝia subtenata enhavfiltrila integriĝo estas la deviga punkto. Tio malsamas de permesi SMTP-konekton tra fajroŝirmilo. Tiu distingo decidas, ĉu la regulo povas malakcepti, kvaranteni aŭ nur anoti.

Postfix, ekzemple, dokumentas enhavfiltradon post la atendovico: poŝto estas vicigita, pasigita al filtrilo kaj redonita al la livera vojo. Ĝia aranĝo post la vico malsamas de la antaŭvica prokuraj kaj Milter-opcioj, al kiuj la sama gvidilo referencas. Elektu la subtenatan integriĝon kaj malsukcesan konduton por la poŝta servo, kiun vi efektive funkciigas.

Unu aldonaĵa regulo ne estas kompleta programo kontraŭ datumperdo. Retumilaj alŝutoj, dividita konservado kaj finpunktaj agoj bezonas proprajn kontrolojn.

Skribu la akceptan teston kun sintezaj mesaĝoj

Testu kun aprobitaj sintezaj ekzemploj: permesita mesaĝo, malpermesita enhava ago kaj la deklarita traktado de ĉifrado je mesaĝa nivelo. Inkluzivu, kion la poŝta servo faras, kiam ĝia filtrilo ne haveblas.

La utila rezulto nomas la agon, la devigan punkton kaj la datumojn videblajn tie. „La VPN malĉifris ĝin“ respondas al unu tavolo kaj ne povas anstataŭigi la enhavan kaj rajtigan modelon de la poŝta aplikaĵo.