GDPR и логи почтового сервера: что, сколько и зачем хранить журналы с IP и адресами
Строка mail.log с client IP, from/to и SASL-логином — это уже обработка персональных данных по GDPR. Разбираем, какие поля журналов являются PII, сколько реально нужно хранить каждый тип лога, почему обрезание октета IP — это псевдонимизация, а не анонимизация, и как настроить logrotate, journald и rsyslog так, чтобы срок хранения был принудительным, а не «когда-нибудь grep -v».
EvilMail Team2 августа 2026 г.13 мин чтения
Одна строка из /var/log/mail.log рабочего сервера:
Здесь пять идентификаторов человека в одной записи: client IP, PTR-имя хоста, envelope from, envelope to и SASL-логин. Это не «технический шум» и не «просто лог» — по определению из ст. 4(1) GDPR это персональные данные, а факт их записи на диск и хранения — обработка. И когда придёт DSAR («на каком основании и как долго вы держите мой IP?») или запрос надзорного органа, у большинства администраторов почты не найдётся ни правового основания, ни задокументированного срока, ни механизма удаления.
Задача этой статьи — не «удалить всё и бояться логов». Задача инженерная: точно знать, что мы храним, зачем, и до какого числа
— так, чтобы ответ выдержал проверку. Пишу с позиции оператора почтовой инфраструктуры и temp-mail, где объём логов огромен, а чувствительность полей особенно высока.
Что в логах Postfix/Dovecot считается персональными данными
Разберём поля. В строке Postfix выше персональными данными являются:
client IP (203.0.113.45) — прямой идентификатор. Дело CJEU C-582/14 (Breyer, 2016) установило: даже динамический IP является персональными данными для оператора, у которого есть *законные средства* сопоставить его с личностью — обычно через провайдера по судебному запросу. У почтового оператора такие средства практически всегда есть.
PTR / HELO hostname — часто содержит домен и косвенно указывает на организацию или человека.
envelope from / to — сам email адрес по ст. 4(1) идентифицирует физлицо напрямую.
SASL username — аутентифицированный пользователь, максимально прямой идентификатор.
Message-ID — связывает событие с конкретным сообщением и цепочкой.
Важно разделить content и metadata: тело письма мы (надеюсь) не логируем, но metadata — кто, кому, откуда, когда — по GDPR такие же персональные данные и часто чувствительнее содержимого, потому что структурированы и легко коррелируются. Ключевой момент: ст. 4(1) не делает исключения для формата хранения. «Это же строка syslog, а не база профилей» — не аргумент. Псевдоним (обрезанный IP, хеш) остаётся персональными данными, пока возможна реидентификация; анонимными данные становятся, только когда сопоставление с человеком необратимо невозможно.
Правовое основание и минимизация (ст. 5, 6)
Обработка без правового основания незаконна. Для операционных mail-логов рабочее основание — ст. 6(1)(f), законный интерес. Recital 47 прямо называет предотвращение мошенничества законным интересом, а Recital 49 — сетевую и информационную безопасность. Это покрывает то, зачем логи действительно нужны:
анти-спам и анти-абьюз (разбор жалоб, отслеживание источников рассылок);
диагностика доставки (bounce, отложенные очереди, разбор «письмо не дошло»);
Законный интерес требует пройти трёхчастный тест: (1) цель легитимна, (2) обработка необходима для цели, (3) баланс интересов не перевешивается правами субъекта. Что этот тест не покрывает: маркетинг, профилирование, продажу данных и знаменитое «пусть полежит, вдруг пригодится». Отсутствие цели = провал теста необходимости = нет основания хранить.
Дальше — принципы ст. 5, которые превращаются в конкретную инженерную настройку:
ст. 5(1)(c), минимизация — не логировать поля, которые не нужны цели.
ст. 5(1)(e), ограничение хранения (storage limitation) — срок хранения привязывается к цели, а не к объёму диска. Это значит: у каждого типа журнала свой TTL, а не один общий «пока не кончится место».
ст. 5(2), подотчётность (accountability) — вы обязаны уметь это доказать, а не просто заявить.
Сколько хранить: сроки по типам журналов
Магического «числа GDPR» не существует — регламент нигде не пишет «X дней». Есть принцип: чем дольше срок, тем сильнее должно быть обоснование необходимости. Годовое хранение сырых mail-логов почти всегда проваливает тест необходимости. Ниже рабочая матрица — как инженерная норма, а не как норма закона.
Пояснения к матрице:
Операционные mail-логи — 7–30 дней. Этого хватает на типичный цикл разбора жалоб на доставку и bounce. Всё, что дольше, — уже не «диагностика», обоснуйте отдельно.
Security / anti-abuse — 30–90 дней. Здесь баланс сдвинут в сторону безопасности (Recital 49), поэтому срок больше. Естественная граница — параметры самого механизма: bantime/findtime в fail2ban задают, сколько событие реально влияет на решения.
Агрегаты без PII — бессрочно. Счётчик «отклонено N писем в час» персональных данных не содержит и под GDPR не подпадает — при условии, что анонимизация настоящая (об этом ниже).
Биллинг и налоговые записи — 6–10 лет по нац. праву. Это не mail-лог и храниться должен в отдельной системе. Смешивать их с mail.log — грубая ошибка: вы либо удалите то, что обязаны хранить, либо будете годами держать IP-адреса «за компанию» с накладными.
Анонимизация и псевдонимизация IP — что реально выводит из-под GDPR
Здесь чаще всего ошибаются. «Я обрезаю последний октет IP, значит данные анонимны» — нет. Обрезание IPv4 до /24 (обнуление последнего октета) или маскирование — это псевдонимизация, а не анонимизация. Recital 26 и Article 29 WP, Opinion 05/2014 on Anonymisation Techniques прямо говорят: данные анонимны, только если исключены три риска — *singling out* (выделение записи), *linkability* (связывание с другими наборами) и *inference* (вывод). Обрезанный IP по-прежнему связывается с остальными полями строки (SASL-логин, Message-ID) и через провайдера реидентифицируется. Псевдонимизированные данные остаются под GDPR со всеми обязанностями.
Что действительно анонимизирует: полное удаление IP, необратимое хеширование с недоступной (выброшенной) солью плюс агрегация, k-анонимность на выходе. Просто хеш IP не спасает — пространство IPv4 мало, радужную таблицу строят за минуты. И отдельное предупреждение по IPv6: обрезка до /64 оставляет идентификатор подсети (у многих провайдеров это один клиент/дом), а до /48 — тем более. /64 — это не аноним.
Практический вывод: разделяйте два конвейера. Горячие полные логи с реальным IP живут коротко (дни) и нужны для отладки здесь и сейчас. Холодные агрегаты без PII живут долго и отвечают на вопросы статистики.
Реализация: ротация, TTL и маскирование
Срок хранения должен быть машинно-принудительным, а не «когда-нибудь зайду и почищу». Три уровня.
logrotate с реальным retention для mail-логов (/etc/logrotate.d/rsyslog на Debian):
rotate 14 + maxage 14 = ничего старше 14 дней на диске не остаётся, даже если ротаций накопилось больше. dateext даёт понятные имена, compress экономит место.
systemd-journald — второй источник, о котором забывают. Если journald держит копию, ваш maxage на файлах бесполезен. В /etc/systemd/journald.conf:
Убрав ненужные поля, вы уменьшаете и объём PII, и риск.
И главная ловушка — внешние агрегаторы и бэкапы. TTL на локальном файле не действует на копию, уехавшую в Elasticsearch, Loki или ночной бэкап. Для ELK настройте ILM с delete-фазой; для Loki — retention_period в limits_config плюс retention_enabled: true в compactor. Иначе mail.log с полными IP спокойно проживёт год в индексе, пока вы гордитесь maxage 14 на файле.
Документирование: как обосновать срок для аудита
Настройки без бумаги не проходят ст. 5(2). Минимальный комплект:
RoPA (ст. 30) — запись об обработке: категории данных (IP, email-metadata, SASL-логин), цель (безопасность, доставка, анти-абьюз), основание (6(1)(f)), срок (по матрице выше), получатели (SIEM-хостинг, суб-процессоры).
LIA — Legitimate Interest Assessment (рекомендация ICO), три строки: цель / необходимость / баланс. Именно LIA связывает *конкретный срок* с *конкретной целью* в письменном виде.
DSAR-готовность. Если субъект запросил свои данные, а логи уже удалены по TTL — это законный и полный ответ: «данные удалены согласно политике хранения, срок X дней». Удаление по расписанию — не пробел, а соответствие требованиям.
DPA с суб-процессорами — тот, кто хостит ваш SIEM или лог-хранилище, обрабатывает те же PII.
