Защита персональных данных в почтовых системах: требования

Адаптация к новым правилам защиты персональных данных: что менять в почтовой инфраструктуре

72-часовое окно: новые обязанности операторов данных

Законодательство Вьетнама вводит жёсткое требование: при обнаружении инцидента, повлёкшего раскрытие, потерю или нарушение конфиденциальности персональных данных, ответственные лица обязаны уведомить специализированное ведомство в течение 72 часов с момента обнаружения нарушения. Это касается любой угрозы национальной обороне, безопасности, общественному порядку или законным правам субъектов данных.

Для почтового инженера 72 часа — это не запас времени, а потолок. Если в логах MTA, системе подписки или антифрод-модуле обнаружена утечка адресной базы, времени на ручной аудит нет. Система мониторинга инцидентов должна работать автоматически: алерты при нештатном доступе к БД подписчиков, аномальном экспорте, массовом чтении полей email, phone, name.

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

Что проверить в собственной инфраструктуре

Глобальный тренд: юрисдикции по всему миру вводят аналогичные нормы. Молдавские источники также фиксируют необходимость адаптации деловой среды к новым стандартам защиты данных. Если система обслуживает подписчиков из нескольких стран — требования суммируются.

Практический чеклист для почтового инженера:

Хранение и доступ. Определите, где физически хранятся данные подписчиков (основная БД, кэш Redis, логи Postfix/Dovecot, файлы ротации). Каждое хранилище — потенциальная точка утечки. Проверьте ACL на каждом уровне.

Логирование. Убедитесь, что логи MTA и системы подписки фиксируют IP доступа, timestamp, тип операции. Без этого невозможно реконструировать инцидент в рамках 72-часового окна.

Механизм уведомления. Должен существовать регламент: кто, кому и в какой форме сообщает об инциденте. Не на уровне «напишем письмо руководству», а с конкретным шаблоном, контактами регулятора и SLA на формирование отчёта.

Минимизация данных. Закон запрещает обработку сверх необходимого. Если в базе хранятся данные, не требующиеся для доставки писем — удалите. Каждое лишнее поле увеличивает зону ответственности.

Согласие и его подтверждение. Двойной opt-in — не просто хорошая практика, а требование. Лог каждого подтверждения подписки (IP, timestamp, user-agent) должен храниться и быть доступен для аудита.

Действия: команды и проверки

# Проверка текущего объёма логов с персональными данными
grep -rl "email\|phone\|name" /var/log/mail* | wc -l
# Аудит прав доступа к базам подписчиков
find /var/lib/mysql/subscribers -type f -exec stat -c '%a %U %G %n' {} \;
# Проверка шифрования at-rest (если используется LUKS)
cryptsetup status /dev/mapper/subscribers_crypt
# Проверка, что логи не ротируются раньше 72 часов
cat /etc/logrotate.d/mail
# Убедитесь, что minsize/maxage покрывают окно инцидента
# Поиск утечек адресной базы в незащищённых конфигах
grep -rn "password\|api_key\|dsn" /etc/postfix/ /etc/dovecot/ --include="*.cf" --include="*.conf"

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