Filtriranje e-pošte preko VPN-a: gde se pravila o sadržaju zaista izvršavaju
Snimka VPN-a ne prikazuje poruku. Prođite putem pošte od dekapsulacije do SMTP TLS do S/MIME i postavite pravilo o sadržaju tamo gde podaci postoje.
Ovaj zahtev zvuči kao mrežni problem: zaustavite određenu vrstu priloga da ne napusti zgradu, a VPN već postoji, pa ga iskoristite. Taj okvir se lomi na prvom pitanju na koje filter mora da odgovori. Pravila o sadržaju moraju da vide poruku, a poruka postaje vidljiva na drugom sloju od tunela. Ja pratim put pošte prema spolja od paketa i zaustavljam se na prvom mestu gde traženi podaci zaista postoje.
Tri sloja su nezavisna: VPN transport, SMTP TLS veza i sopstveno šifrovanje poruke. Svaki se završava na drugom mestu.
Počnite od sloja koji može da vidi poruku
Dekapsulacija VPN-a daje vam unutrašnji mrežni saobraćaj. Ako je klijent pošte otvorio TLS vezu prema serveru za predaju, unutrašnji saobraćaj još uvek sadrži taj TLS tok, a ne čitljivu poštu.
Zato snimak paketa uzet na ivici tunela odgovara na drugo pitanje od „da li ova poruka sadrži zabranjeni prilog“.
Završetak SMTP TLS-a se završava na koverti
Završavanje SMTP TLS-a na serveru pošte otkriva poruku onako kako je predata tom odredištu. Server vidi zaglavlja, kovertu i MIME strukturu. To je dovoljno za mnoga pravila o sadržaju. Koverta vam kaže pošiljaoca i primaoce onako kako ih je server razumeo.
To nije dovoljno za poruku zaštićenu S/MIME-om. Server prima zaštićeni entitet i bez odgovarajućih ključeva ne može da pročita sadržaj unutar njega. Isto ograničenje važi za šifrovani prilog koji stiže neoštećen.
Ne slabite transportnu bezbednost da biste pasivni snimak učinili čitljivim. To menja arhitekturu umesto da postavi pravilo tamo gde su podaci.
S/MIME se završava tamo gde su ključevi
S/MIME štiti MIME podatke poruke, pa je njegova granica ključni materijal i odobreni raspored dešifrovanja. Filter bez tih ključeva još može da deluje na vidljive metapodatke ili na prisustvo zaštićenog objekta, ali to je drugačiji rezultat.
Ako organizacija pokreće odobreni šifrarni prolaz ili upravljani nadzor krajnjih tačaka, dokumentujte gde postoji otvoreni tekst, koji identitet sme da ga pregleda i kako su ključevi i zapisi zaštićeni. Ne postoji glavni ključ stvoren usmeravanjem saobraćaja kroz VPN.
Zapišite to pre nego što bilo ko obeća klasifikaciju otvorenog teksta. Obećanje je deo koji je teško povući.
Stavite pravilo u platformu pošte
Ako odobreni server pošte prima čitljivu poruku, njegova podržana integracija filtera sadržaja je tačka sprovođenja. To se razlikuje od dopuštanja SMTP veze kroz zaštitni zid. Ta razlika odlučuje da li pravilo može da odbije, stavi u karantin ili samo označi.
Postfix, na primer, dokumentuje filtriranje sadržaja posle reda čekanja: pošta se stavlja u red, prosleđuje filteru i vraća na put dostave. Njegov raspored posle reda razlikuje se od opcija proksija pre reda i Miltera na koje se poziva isti vodič. Izaberite podržanu integraciju i ponašanje pri otkazu za poštansku uslugu koju zaista vodite.
Jedno pravilo za priloge nije potpun program protiv gubitka podataka. Prenosi iz pregledača, deljeno skladište i radnje na krajnjim tačkama trebaju sopstvene kontrole.
Napišite prihvatni test sa sintetičkim porukama
Testirajte sa odobrenim sintetičkim primerima: dozvoljena poruka, zabranjena radnja sa sadržajem i najavljeno postupanje sa šifrovanjem na nivou poruke. Uključite šta poštanska usluga radi kada njen filter nije dostupan.
Koristan rezultat imenuje radnju, tačku sprovođenja i podatke vidljive tamo. „VPN je to dešifrovao“ odgovara na jedan sloj i ne može da zameni model sadržaja i autorizacije poštanske aplikacije.