Филтриране на имейл през 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 го дешифрира“ отговаря на един слой и не може да замени модела за съдържание и оторизация на пощенското приложение.