Филтрирање е-пошта преку VPN: каде всушност се извршуваат правилата за содржина

Ова барање звучи како мрежен проблем: спречете одреден вид прилог да ја напушти зградата, а VPN-от веќе е таму, затоа користете го. Таа рамка се распаѓа при првото прашање на кое филтерот мора да одговори. Правилата за содржина треба да ја видат пораката, а пораката станува видлива на различен слој од тунелот. Ја следам поштенската патека нанадвор од пакетот и застанувам на првото место каде што потребните податоци навистина постојат.

Три слоја се независни: VPN транспортот, SMTP TLS врската и сопственото шифрирање на пораката. Секој завршува на различно место.

Започнете од слојот што може да ја види пораката

Декапсулацијата на VPN-от ви го дава внатрешниот мрежен сообраќај. Ако клиентот за е-пошта отворил TLS врска до сервер за поднесување, внатрешниот сообраќај сѐ уште го содржи тој TLS тек, а не читлива пошта.

Затоа снимањето пакети на работ на тунелот одговара на друго прашање од „содржи ли оваа порака забранет прилог“.

Завршувањето на SMTP TLS завршува на пликото

Завршувањето на SMTP TLS на серверот за е-пошта ја открива пораката онака како што била поднесена до таа крајна точка. Серверот ги гледа заглавијата, пликото и структурата MIME. Тоа е доволно за многу правила за содржина. Пликото ви ги кажува испраќачот и примачите онака како што серверот ги разбрал.

Тоа не е доволно за порака заштитена со S/MIME. Серверот прима заштитен ентитет и без соодветните клучеви не може да ја прочита содржината внатре. Истото ограничување важи и за шифриран прилог што пристигнува недопрен.

Не ја ослабувајте безбедноста на транспортот за да направите пасивно снимање читливо. Тоа ја менува архитектурата наместо да го постави правилото таму каде што се податоците.

S/MIME завршува таму каде што се клучевите

S/MIME ги штити податоците на MIME пораката, па неговата граница се клучниот материјал и одобрениот распоред за дешифрирање. Филтер без тие клучеви сѐ уште може да дејствува на видливи метаподатоци или на присуство на заштитен објект, но тоа е различен резултат.

Ако организацијата управува со одобрен портал за шифрирање или управувана контрола на крајни точки, документирајте каде постои чист текст, кој идентитет смее да го прегледа и како се заштитени клучевите и записите. Нема главен клуч што се создава со пренасочување на сообраќајот низ VPN.

Запишете го тоа пред некој да вети класификација на чист текст. Ветувањето е делот што е тешко да се повлече.

Поставете го правилото во платформата за е-пошта

Ако одобрениот сервер за е-пошта ја прими читливата порака, неговата поддржана интеграција за филтрирање содржина е точката на спроведување. Тоа е различно од дозволување SMTP врска низ огнен ѕид. Таа разлика одлучува дали правилото може да одбие, да стави во карантин или само да забележи.

На пример, Postfix документира филтрирање содржина по редот: поштата се става во ред, се предава на филтер и се враќа на патеката за доставување. Неговиот распоред по редот се разликува од опциите за прокси пред редот и Milter на кои се повикува истиот водич. Изберете ја поддржаната интеграција и однесувањето при грешка за поштенската служба што навистина ја управувате.

Едно правило за прилози не е целосна програма против губење податоци. Прикачувањата од прелистувач, споделеното складиште и дејствата на крајните точки бараат свои контроли.

Напишете го тестот за прифаќање со синтетички пораки

Тестирајте со одобрени синтетички примери: дозволена порака, забрането дејство со содржина и најавеното постапување со шифрирањето на ниво на порака. Вклучете и што прави поштенската служба кога нејзиниот филтер не е достапен.

Корисниот резултат го именува дејството, точката на спроведување и податоците видливи таму. „VPN-от го дешифрираше“ одговара на еден слој и не може да го замени моделот за содржина и авторизација на апликацијата за е-пошта.