Фільтрація пошти через 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 це розшифрував» відповідає на один рівень і не може замінити модель вмісту й авторизації поштового застосунку.