DLP для корпоративной почты: политики защиты персональных данных и настройка

DLP для корпоративной почты — это программный фильтр на почтовом сервере, который перехватывает исходящие письма с персональными данными до их отправки наружу. Система сканирует тело сообщений и вложения на наличие номеров паспортов, СНИЛС или банковских карт, блокируя утечку информации.

Без такого контроля компания рискует нарушить требования 152-ФЗ, так как стандартные средства защиты вроде SPF и DKIM не анализируют содержимое исходящей корреспонденции. Ответственность за неправомерную передачу данных лежит на операторе независимо от того, была ли утечка умышленной или случайной ошибкой сотрудника.

DLP для корпоративной почты — это набор правил и программных фильтров на почтовом сервере, которые перехватывают исходящие письма с персональными данными до их выхода из периметра компании. Технически это milter или прокси перед MTA, который сканирует тело и вложения на номера паспортов, СНИЛС, банковские карты, ИНН и либо блокирует отправку, либо отправляет письмо в карантин, либо уведомляет офицера ИБ. Задача одна: не дать сотруднику случайно или намеренно переслать базу клиентов на внешний адрес.

Юридическая основа — Федеральный закон № 152-ФЗ «О персональных данных», принятый Государственной Думой 8 июля 2006 года, одобренный Советом Федерации 14 июля 2006 года и подписанный 27 июля 2006 года. Полный текст с актуальной редакцией — на портале КонсультантПлюс. Закон обязывает оператора принимать правовые, организационные и технические меры защиты ПДн — в том числе от неправомерной передачи. Утечка через почту — это именно неправомерная передача, и оператор отвечает за неё независимо от того, был ли это злой умысел или ошибка стажёра.

Без DLP контроль утечки сводится к политике и доверию: админ смотрит в журналы постфактум, когда база уже у конкурента. Классические меры — SPF, DKIM, DMARC, антиспам — защищают входящий поток и внешнее доверие к домену, но не смотрят внутрь исходящих писем. Антивирус ищет вредоносные вложения, а не корпоративные таблицы с клиентской базой. DLP-слой закрывает именно эту слепую зону: содержимое исходящего письма.

Для self-hosted почты это особенно критично. На своём сервере контроль над содержимым писем полный, но и ответственность за защиту ПДн целиком на операторе — и все меры защиты он выполняет сам, без провайдера. В облаке часть мер выполняет провайдер по поручению оператора, но перед субъектом ПДн и там отвечает оператор (часть 5 статьи 6 152-ФЗ); на выделенном сервере компания выполняет и сами меры. Поэтому DLP-политика на self-hosted почте — не «фича корпоративного плана», а обязательный технический элемент выполнения 152-ФЗ.

Ошибочно сводить DLP к покупке «коробки». Любая DLP работает ровно настолько, насколько точно настроены её словари, регулярные выражения и исключения под реальный документооборот компании. Юристу штатно шлют копии паспортов, бухгалтеру — реквизиты карт для возвратов — такие сценарии нужно размечать как легитимные, иначе система за неделю обучит людей обходить её через архивы с паролем. Поэтому DLP-проект начинается не с установки, а с инвентаризации: кто кому и что отправляет законно.

Минимальный набор целевых сущностей для DLP на почте — серия и номер паспорта РФ, СНИЛС, номер банковской карты, ИНН физического лица, а также телефонные номера в российских форматах. Эти категории прямо подпадают под определение ПДн по 152-ФЗ и дают высокий «сигнал-к-шуму»: шаблон строгий, случайных совпадений в деловой переписке мало. ИНН организации к ПДн не относится, но его шаблон полезно держать в словаре как контекстный признак.

Серия и номер паспорта РФ — четыре цифры, пробел или дефис, затем шесть цифр: \b\d{2}[ \-]?\d{2}[ \-]?\d{6}\b. СНИЛС — одиннадцать цифр в формате «XXX-XXX-XXX XX»: \b\d{3}-\d{3}-\d{3}[ \-]\d{2}\b. ИНН физического лица — ровно двенадцать цифр, юридического — десять; оба имеют контрольные разряды, но для первого фильтра достаточно шаблона \b(\d{10}|\d{12})\b с последующей проверкой контрольной суммы на уровне плагина. Банковская карта — тринадцать–девятнадцать цифр, часто сгруппированных по четыре, и проверка по алгоритму Луна.

Пример правил для карты и СНИЛС в формате карт содержимого Rspamd multimap приведён в конце раздела: правила вставляются в /etc/rspamd/local.d/multimap.conf, а сами регулярные выражения лежат в отдельных файлах карт.

Регулярок недостаточно — к ним обязательно прикручивается валидация. Без проверки контрольной цифры карты (Луна) и контрольных разрядов СНИЛС и ИНН система ловит любой заказ, в котором есть длинная последовательность цифр: артикулы товаров, номера договоров, трек-номера посылок. Контрольные проверки существенно снижают долю ложных срабатываний. Для карт также применяется проверка BIN на принадлежность реальному эмитенту.

Отдельно — вложения. Регулярки по телу письма не увидят ПДн в .xlsx или .pdf. Нужен шаг извлечения текста: antiword, pdftotext, xlsx2csv, tika — любой удобный распаковщик, вызываемый из milter или плагина. Для сканированных документов (фото паспорта) потребуется OCR, что повышает нагрузку: обычно OCR включают только для вложений заданных типов и размеров. Определение субъекта ПДн и состав защищаемых сведений — в статье 3 закона № 152-ФЗ.

Словари типовых фраз — второй слой. Регулярки ловят формат, словари ловят контекст: «паспорт серия», «ИНН», «карта оплаты», «реквизиты получателя», «клиент базы», названия внутренних систем. Срабатывание по словарю само по себе не блокирует письмо — оно поднимает вес и в сочетании с найденным форматом ПДн переводит письмо в карантин.

Самый прямой способ построить DLP для корпоративной почты на связке Postfix + Rspamd — вынести DLP-проверки в модуль Rspamd, который уже стоит в тракте проверки писем, и дополнить его milter’ом, когда нужны действия на уровне SMTP-транзакции до постановки в очередь. Rspamd подключается к Postfix по milter-протоколу, видит и входящую, и исходящую почту, и уже умеет применять действия reject / soft reject / add header / rewrite subject.

Включение DLP-проверок — это несколько шагов. Сначала фиксируем направление: политика DLP должна срабатывать на письма, уходящие наружу, а не на внутреннюю переписку. В Rspamd для этого используется селектор user (имя аутентифицированного отправителя) и список local_addrs с внутренними сетями — проверяем, что отправитель аутентифицирован (значит, это наш сотрудник), и что получатель не в локальных доменах.

Фрагмент конфигурации /etc/rspamd/local.d/multimap.conf с символом, который отмечает исходящие письма аутентифицированных пользователей, приведён в конце раздела. Правила PDN_* из предыдущего раздела получают строку require_symbols = "PDN_OUTBOUND_SCOPE"; и срабатывают только для исходящей почты сотрудников.

Правила с регулярками из предыдущего раздела включаются как type = "content" и получают вес. Итоговое действие определяется суммой весов: пороги reject, add_header, greylist настраиваются в /etc/rspamd/local.d/actions.conf. Для DLP имеет смысл отделить порог «карантин» от обычного спам-порога: обычная почта с подозрением на спам уходит в Junk, а письмо с подтверждёнными ПДн — в отдельный ящик офицера ИБ через sieve-правило.

Milter подключается там, где Rspamd недостаточно. Пример — необходимость перехвата крупного вложения до его разбора антивирусом или собственная бинарная проверка (OCR-сервис, DLP-движок стороннего вендора). В Postfix для этого в smtpd_milters указываются адреса и порты фильтров — Rspamd первым, затем собственный milter. Порядок важен: распаковка вложений и антивирус отрабатывают до DLP-правил, а зашифрованный архив, который не удаётся распаковать, DLP-политика сразу отправляет в карантин — иначе архив с паролем пройдёт оба фильтра как «не содержит угроз».

Кейс IT For Prof: в проекте миграции корпоративной почты «Альтер‑2», юридической компании со штатом более 200 сотрудников, мы развернули выделенный сервер на инфраструктуре Selectel со стеком Postfix + Dovecot + SOGo + Rspamd + ClamAV, 200 почтовых ящиков, 4 ТБ данных. Ежемесячные расходы снизились с 92 000 ₽ до 15 000 ₽.

Такой стек — та же база, на которую сверху ложится DLP-слой: Rspamd уже обслуживает трафик, остаётся добавить правила, пороги и действия. Отдельное требование закона — организационные и технические меры безопасности — закреплено в статье 19 «Меры по обеспечению безопасности персональных данных при их обработке».

Для DLP на почте применяются три режима действий: блокировка (отказ в приёме письма на этапе SMTP), карантин (письмо принимается, но помещается в отдельный ящик до решения ИБ) и уведомление (письмо уходит, но параллельно формируется алерт). Выбор режима — не технический, а организационный: от него зависит, сломается ли бизнес-процесс при ложном срабатывании.

Блокировка — самый жёсткий режим. Rspamd возвращает SMTP-код 5xx, Postfix отбрасывает письмо, отправитель получает non-delivery report. Плюс: ПДн гарантированно не выходят наружу. Минус: любой ложный срабатывающий паттерн ломает отправку, пользователь узнаёт о проблеме сразу и несёт её в helpdesk. Блокировку разумно включать только для сущностей с минимумом ложных срабатываний и после нескольких недель наблюдения в «мягком» режиме.

Карантин — компромисс. Rspamd добавляет заголовок (X-DLP-Action: quarantine), письмо принимается, Postfix через header check или Sieve перенаправляет его в отдельный служебный ящик. Офицер ИБ разбирает ящик по расписанию: подтверждает блокировку или возвращает письмо адресату (обычно ресендом с админского аккаунта). Карантин терпим к ложным срабатываниям и подходит для сущностей с «серой» точностью — например, для словарных словосочетаний.

Уведомление — самый мягкий режим, используется либо на этапе обучения политики, либо для сущностей, где блокировка недопустима для бизнес-процесса (например, обязательная переписка с госорганами). Rspamd пишет метку, письмо уходит получателю, по SIEM или web-hook уходит алерт офицеру ИБ: кто, кому, что отправил. Это даёт реакцию постфактум — важно и для внутреннего разбирательства, и для уведомления субъекта и уполномоченного органа, когда это требуется по статье 21 закона № 152-ФЗ: о неправомерной передаче ПДн оператор сообщает в Роскомнадзор в течение 24 часов, о результатах внутреннего расследования — в течение 72 часов (часть 3.1). За неуведомление статья 13.11 КоАП (часть 11) грозит юрлицу штрафом от 1 000 000 до 3 000 000 ₽, за утечку данных от 1 000 до 10 000 субъектов — от 3 000 000 до 5 000 000 ₽ (часть 12), а повторная утечка наказывается оборотным штрафом от 1 до 3% выручки, но не менее 20 000 000 и не более 500 000 000 ₽ (часть 15).

Как правило, политики смешиваются. Паспорт, карта и СНИЛС — блокировка в исходящую. Клиентская база (словарь внутренних наименований) — карантин. Отдельные ключевые слова («конфиденциально», «коммерческая тайна») — только уведомление. Такой слоёный пирог даёт жёсткость там, где риск очевиден, и гибкость там, где возможны легитимные бизнес-кейсы.

Отдельная ветка — исключения. Любая DLP быстро обрастает «белым списком»: email адреса контрагентов, которым штатно передают оригиналы документов (нотариусы, аудиторы, государственные порталы), и внутренние адреса (архив, бухгалтерия). Исключения описываются либо парой «отправитель → получатель», либо тегом политики, который снимает блокировку. Без этого слоя DLP ломает рабочие сценарии в первые часы после включения.

Пороги фиксируются в actions.conf и multimap.conf, но принципиально важнее — журналировать каждое действие в читаемом виде, иначе разбор инцидентов превратится в чтение сырого syslog.

Журнал инцидентов DLP — обязательный элемент, без которого политика превращается в «чёрный ящик»: сработало — непонятно почему, не сработало — тоже непонятно. По 152-ФЗ оператор обязан документировать меры защиты и реагирование на инциденты, то есть журнал — не только инструмент отладки, но и доказательство исполнения требований закона.

Технически источник событий — Rspamd и Postfix. Rspamd пишет в свой лог символы, веса и итоговое действие по каждому письму; Postfix фиксирует SMTP-транзакцию, отправителя, получателей, Message-ID. Обе строки сшиваются по Message-ID и обогащаются содержимым: какой паттерн сработал, в теле или во вложении, с какой маскировкой. Маскировка обязательна: ПДн нельзя логировать в открытом виде, иначе журнал сам становится точкой утечки.

Минимальный пайплайн — Rspamd → Elasticsearch (есть встроенный модуль elastic) или Rspamd → Loki через Grafana Alloy. Дашборд в Kibana или Grafana даёт три представления: лента инцидентов (кто, когда, какое правило), агрегат по правилам (какие срабатывают чаще — кандидаты в тюнинг), агрегат по отправителям (кто чаще всего триггерит DLP — повод обучить сотрудника или подозревать инсайдера).

Ложные срабатывания разбирают по рабочему циклу. Срабатывание попадает в карантин, офицер ИБ смотрит и принимает одно из решений: подтвердить блокировку, разрешить и внести отправителя-получателя в исключение, разрешить и ослабить правило. Третье решение — самое опасное: ослабление правила «от каждого случая» через месяц превращает политику в решето. Правильный процесс: сначала фиксируется паттерн ложного срабатывания, затем правило уточняется структурно (сузить регулярку, добавить проверку контрольной суммы, добавить словарь контекста), только после этого ослабляется вес.

Пример конкретной типовой ситуации: регулярка карты срабатывает на длинные артикулы 12345-67890-123. Проверка Луна не прошла — но до валидации письмо уже отмечено. Решение — не ослаблять порог, а включить проверку Луна на уровне плагина и логировать два разных символа: PDN_CARD_CANDIDATE и PDN_CARD_VALID. На первом — только лог, на втором — действие.

Второй частый сценарий: СНИЛС в подписи кадровика, который легитимно рассылает справки сотрудникам. Решение — исключение по паре kadry@... → *@внутренний_домен и запрет этой же пары на внешние домены. Исключения привязываются к ролевым ящикам, а не к конкретным людям: при увольнении сотрудника правила не нужно переписывать.

Хранение журнала — отдельный вопрос. Логи DLP содержат чувствительные метаданные (кому и что сотрудник пытался отправить) и сами должны быть защищены: ограниченный доступ, шифрование диска, срок хранения — по политике компании, но не меньше установленного регламентом по инцидентам срока. Порядок реагирования закрепляется в локальном акте о процедурах предотвращения и выявления нарушений — оператор-юрлицо обязан его издать, см. статью 18.1 «Меры, направленные на обеспечение выполнения оператором обязанностей».

Главное отличие — где физически находятся правила, журналы и само содержимое писем. В self-hosted DLP на своём почтовом сервере контроль, конфигурация и логи целиком у оператора ПДн; в Яндекс 360, МегаФон DLP и Контур.Эгиде часть этого контура — у провайдера, провайдер работает по поручению оператора, но перед субъектом ПДн отвечает сам оператор.

Яндекс 360 для бизнеса предлагает интеграцию почты с внешними DLP-системами через правила маршрутизации и API. Это не встроенная DLP, а точка подключения: сам DLP-движок компания покупает отдельно, правило маршрутизации пересылает копии исходящих писем на адрес DLP-системы. Такая модель избавляет от администрирования почтового сервера, но требует отдельного DLP-вендора и ещё одного контракта. Порядок настройки и схемы подключения — в документации Яндекс 360 для бизнеса.

МегаФон DLP — услуга оператора на базе российских DLP-систем. ПО ставится на рабочие станции, трафик разбирает отдельный сервер — собственный или в МегаФон Облаке; подключение — от 5 рабочих станций. Плюс — быстрый старт, проект ведёт аккаунт-менеджер оператора. Минус — при размещении в МегаФон Облаке чувствительные метаданные о переписке (кто, когда, кому, какие правила триггерят) попадают в контур оператора связи, что по 152-ФЗ требует отдельного оформления и согласований.

Контур.Эгида — линейка продуктов внутренней безопасности СКБ Контур; DLP-функции в ней выполняет Staffcop, агент которого перехватывает почту на рабочей станции, поэтому тип почтового сервера (облачный или self-hosted) для него не важен. Это ближе к классической коробочной модели: отдельный продукт, собственный сервер, собственные правила и сложная настройка под документооборот компании.

Self-hosted DLP на Rspamd + плагинах — другой полюс: ноль лицензионных платежей, полный контроль над правилами и журналом, но и полная ответственность за эксплуатацию. Нужны администратор, умеющий тюнить Rspamd и писать плагины на Lua, процесс разбора инцидентов и регулярная работа над словарями. Экономика выигрывает только там, где уже есть собственная почта и команда, — иначе суммарно выйдет дороже коробки.

Пример-расчёт для условной компании: допустим, компания среднего размера уже перешла на self-hosted почту (Postfix + Rspamd). Внедрение DLP для неё — это работа по описанию политики, настройке правил и обучению офицера ИБ плюс поддержка. Это десятки инженерных часов на старте и единицы часов в месяц на сопровождение. Если бы та же компания покупала облачную DLP, в сопоставимую сумму она бы вкладывалась ежемесячно — но получила бы готовую консоль и SLA провайдера. Поэтому self-hosted выгоден при наличии инженерного ресурса, облачный — при его отсутствии.

Критерий выбора простой: кто читает журнал инцидентов. Если офицер ИБ в штате и готов работать с Rspamd — self-hosted. Если ИБ-функция аутсорсится или нужна «коробка под ключ» — облачный сервис или коммерческая DLP с внедрением.

Чек-лист внедрения DLP для корпоративной почты сводится к семи шагам: инвентаризация потоков ПДн, фиксация политики на бумаге, настройка правил на тестовом профиле, запуск в режиме «только лог», постепенное ужесточение, обучение офицера ИБ и сотрудников, формализация процесса разбора инцидентов. Пропуск любого из первых двух шагов — и дальше технические меры не выполнят своей задачи.

Шаг первый, инвентаризация. Кто кому отправляет письма с ПДн легитимно: HR, бухгалтерия, юридический отдел, продажи. Какие сущности встречаются (паспорт, СНИЛС, карта), в каком виде (тело, PDF, Excel), на какие внешние адреса. Без этой карты правила будут либо гнаться за фантомами, либо игнорировать реальные потоки.

Шаг второй, политика на бумаге. Короткий документ: какие категории ПДн под защитой, какие режимы (блокировка, карантин, уведомление) применяются к каким категориям, кто имеет право одобрять исключения, какие сроки хранения журнала. Политика — то, на что потом ссылается журнал инцидентов и чем обосновывается конкретное действие DLP.

Шаг третий, тестовый профиль. Правила включаются на одного-двух пользователей ИБ-службы, которые имитируют реальный документооборот. Это ловит грубые ошибки в регулярках и пороговых значениях до того, как они встретят живого бухгалтера.

Шаг четвёртый, режим «только лог». Несколько недель политика работает без действий, только пишет события. Собираются данные о ложных срабатываниях, строятся исключения, уточняются регулярки. Именно здесь закрывается большинство проблем, которые иначе съели бы helpdesk после жёсткого включения.

Шаг пятый, постепенное ужесточение. Сначала включается уведомление, затем карантин, затем блокировка — и только по тем сущностям, где доля ложных срабатываний в логе за наблюдаемый период стабильно низкая. На этом шаге критически важна кнопка отката: политика откатывается до прошлого уровня одной командой, иначе каждый сбой рабочей почты держит в напряжении всю команду.

Типовые ошибки повторяются из проекта в проект. Включение жёсткой блокировки с первого дня — переписка встаёт, DLP выключают через неделю. Регулярки без проверки контрольных сумм — поток ложных срабатываний такой, что офицер ИБ перестаёт их разбирать. Отсутствие исключений по ролевым ящикам — HR и бухгалтерия ломаются первыми. Логи DLP без маскировки — журнал сам становится точкой утечки. Нет регулярного пересмотра политики — через год правила не отражают текущих бизнес-процессов, покрытие ПДн деградирует.

Отдельно — соблюдение прав сотрудников. Любая DLP-система, которая читает содержимое писем работников, должна быть описана в локальных нормативных актах, а сотрудники — уведомлены под роспись. Эта процедура опирается и на трудовое законодательство, и на 152-ФЗ в части обязанностей оператора. Без этой бумажной основы любое DLP-внедрение юридически уязвимо, независимо от качества технической настройки.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — основатель и инженер IT For Prof. Сопровождает корпоративную ИТ-инфраструктуру российского бизнеса: серверы, почтовые системы, мониторинг, корпоративные мессенджеры и платформы вроде Битрикс24. Делится практикой импортозамещения и self-hosted-решений в блоге и GitHub-организации IT-for-Prof. В рубрике о корпоративной почте пишет о миграциях, отказоустойчивости и защите почтовых серверов. Кейс по теме: Миграция корпоративной почты: 200 ящиков с VK Workspace на свой сервер.