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