Новый завет: приказ ФСТЭК меняет для бизнеса правила защиты персональных данных

Для почтовой инфраструктуры это не формальная смена документа: электронная почта выделена среди отдельных сред защиты наряду с облаками, контейнерами, веб-сервисами и API. Плановая дата вступления проекта в силу — 1 сентября 2026 года.

Старый подход опирался на фиксированный набор мер. Новый проект переносит фокус на контроль всего жизненного цикла данных: сбор, обработку, передачу, использование в аналитике и ИИ-сервисах. Для MTA, корпоративных ящиков, почтовых шлюзов и интеграций это означает необходимость проверять не только периметр, но и каждый маршрут, по которому ПДн покидают систему.

Почтовый контур становится самостоятельным объектом защиты

В проекте прямо названа защита электронной почты. Это важный сдвиг: почтовый сервер больше нельзя рассматривать только как сервис доставки с антиспамом на входе и TLS на внешнем коннекторе.

Проверьте почтовый контур по фактическим потокам данных:

• входящие письма с вложениями и URL;
• исходящая почта сотрудников, CRM и сервисных аккаунтов;
• пересылки на внешние домены;
• журналы MTA, архивы, резервные копии;
• почтовые API и SMTP-реле;
• мобильный и удалённый доступ к ящикам;
• подрядчики, обслуживающие почту, архивирование или антиспам.

Отдельно инвентаризируйте сервисные отправки. Уведомления, формы сайта, тикет-системы и маркетинговые платформы часто используют один SMTP relay, но работают с разными категориями ПДн. Не допускайте общего технического аккаунта без разделения прав, журналирования и контроля отправителей.

SPF, DKIM и DMARC остаются необходимыми механизмами защиты домена от подмены. Но они не закрывают утечку через легитимно скомпрометированный ящик, ошибочную пересылку или внешний API. Не подменяйте защиту ПДн настройкой DNS-записей.

ИИ, API и подрядчики: новые точки контроля

Как сообщает Хабр, проект включает меры защиты при использовании ИИ, а также при взаимодействии с подрядными организациями. Это напрямую касается корпоративной почты: содержимое писем, вложения и обращения в поддержку не должны без отдельного контроля попадать во внешние ИИ-инструменты, облачные классификаторы или API.

Зафиксируйте минимум:

1. Запретите передачу содержимого ящиков, вложений и почтовых архивов во внешние ИИ-сервисы без утверждённого сценария обработки.

2. Определите, какие почтовые данные доступны антиспам-провайдеру, облачному архиву, CRM и сервису рассылок.

3. Установите требования к подрядчику: доступы, журналирование, сроки хранения, порядок уведомления об инцидентах.

4. Ограничьте SMTP/API-учётные записи по IP, правам и назначению. Ротация ключей должна быть процедурой, а не реакцией на утечку.

5. Включите мониторинг аномалий: массовые пересылки, новые правила mailbox forwarding, входы из нетипичных локаций, изменения транспортных маршрутов.

Проект также увязывает защиту с оценкой эффективности реализованных мер: её предполагается проводить не реже одного раза в три года и после компьютерного инцидента. Не ждите утверждения подзаконных методик. Уже сейчас соберите карту потоков ПДн в почте, определите владельцев систем и проверьте, какие контроли можно подтвердить журналами, настройками MTA и регламентами.

Что не следует откладывать

Четыре уровня защищённости ПДн, по данным Хабра, сохраняются. Но сама модель становится менее похожей на закрытый каталог настроек и сильнее зависит от выбранных оператором механизмов. Это повышает цену ошибок в проектировании.

Начните с аудита маршрутизации. Проверьте, где письма принимаются, где фильтруются, где хранятся, кто читает логи и куда уходят копии сообщений. Затем настройте раздельные политики для пользовательской почты, транзакционных отправок и массовых рассылок. После этого закрепите требования к облачным сервисам и подрядчикам.

Почта в этой модели — не канал «между системами». Это информационная система с ПДн, внешними интерфейсами, учётными записями и цепочкой поставщиков. Контролируйте её соответствующим образом.