Filtriranje e-pošte prek VPN: kje se pravila o vsebini v resnici izvajajo

Ta zahteva zveni kot omrežna težava: ustavite določeno vrsto priponke, da ne zapusti zgradbe, VPN pa je že tam, zato ga uporabite. Ta okvir se zlomi pri prvem vprašanju, na katero mora filter odgovoriti. Pravila o vsebini morajo videti sporočilo, sporočilo pa postane vidno na drugi plasti kot tunel. Sledim poti pošte navzven od paketa in se ustavim na prvem mestu, kjer zahtevani podatki res obstajajo.

Tri plasti so neodvisne: prenos VPN, povezava SMTP TLS in lastno šifriranje sporočila. Vsaka se konča drugje.

Začnite s plastjo, ki vidi sporočilo

Dekapsulacija VPN vam da notranji omrežni promet. Če je poštni odjemalec odprl povezavo TLS do strežnika za pošiljanje, notranji promet še vedno vsebuje ta tok TLS, ne berljive pošte.

Zato zajem paketov na robu tunela odgovarja na drugo vprašanje kot „ali to sporočilo vsebuje prepovedano priponko“.

Zaključek SMTP TLS se konča pri ovojnici

Zaključevanje SMTP TLS na poštnem strežniku razkrije sporočilo tako, kot je bilo predano tej točki. Strežnik vidi glave, ovojnico in strukturo MIME. To zadostuje za mnoga pravila o vsebini. Ovojnica vam pove pošiljatelja in prejemnike tako, kot jih je strežnik razumel.

To ne zadostuje za sporočilo, zaščiteno s S/MIME. Strežnik prejme zaščiteno entiteto in brez ustreznih ključev ne more prebrati vsebine v njej. Enaka omejitev velja za šifrirano priponko, ki prispe nepoškodovana.

Ne slabite varnosti prenosa, da bi pasivni posnetek postal berljiv. To spremeni arhitekturo, namesto da bi pravilo postavilo tja, kjer so podatki.

S/MIME se konča tam, kjer so ključi

S/MIME ščiti podatke sporočila MIME, zato je njegova meja ključni material in odobrena ureditev dešifriranja. Filter brez teh ključev lahko še vedno deluje na vidne metapodatke ali na prisotnost zaščitenega predmeta, vendar je to drugačen rezultat.

Če organizacija upravlja odobren prehod za šifriranje ali upravljani nadzor končnih točk, dokumentirajte, kje obstaja čisto besedilo, katera identiteta ga sme pregledati in kako so zaščiteni ključi in zapisi. Nobenega glavnega ključa ne ustvari usmerjanje prometa skozi VPN.

Zapišite to, preden kdo obljubi klasifikacijo čistega besedila. Obljuba je del, ki ga je težko preklicati.

Postavite pravilo v poštno platformo

Če odobreni poštni strežnik prejme berljivo sporočilo, je njegova podprta integracija filtra vsebine točka uveljavljanja. To se razlikuje od dovoljenja povezave SMTP skozi požarni zid. Ta razlika odloči, ali lahko pravilo zavrne, da v karanteno ali le doda opombo.

Postfix na primer dokumentira filtriranje vsebine po čakalni vrsti: pošta se uvrsti v čakalno vrsto, posreduje filtru in vrne na pot dostave. Njegova ureditev po čakalni vrsti se razlikuje od možnosti posrednika pred vrsto in Milter, na katere se sklicuje isti vodnik. Izberite podprto integracijo in vedenje ob napaki za poštno storitev, ki jo res upravljate.

Eno pravilo za priponke ni popoln program proti izgubi podatkov. Nalaganja iz brskalnika, skupna shramba in dejanja na končnih točkah potrebujejo svoje nadzore.

Napišite sprejemni test s sintetičnimi sporočili

Preizkusite z odobrenimi sintetičnimi primeri: dovoljeno sporočilo, prepovedano dejanje z vsebino in napovedano ravnanje s šifriranjem na ravni sporočila. Vključite, kaj poštna storitev naredi, ko njen filter ni na voljo.

Uporaben rezultat poimenuje dejanje, točko uveljavljanja in tam vidne podatke. „VPN ga je dešifriral“ odgovori na eno plast in ne more nadomestiti modela vsebine in avtorizacije poštne aplikacije.