Скрытый риск GDPR в вашем стеке журналирования
Обновлено для 2026 года
Большинство команд проверяют базу данных на наличие персональных данных. Свою систему журналирования проверяют значительно реже.
Статья 5(1)(e) GDPR ограничивает срок хранения персональных данных. Для баз данных команды устанавливают политики и запускают задания удаления. Для журнальных файлов правило проще: хранить всё 90 дней для отладки.
Проблема в том, что эти записи содержат персональные данные. Записи запросов содержат email-адреса пользователей. Записи ошибок содержат необработанные входные значения. Записи доступа содержат IP-адреса. Каждое из них является персональными данными по GDPR. Вашей команде нужно законное основание и план хранения для каждого.
Что оказывается в ваших журнальных файлах
Стандартное журналирование веб-приложений захватывает широкий спектр ПДн.
Записи доступа (nginx/Apache):
- IP-адреса — персональные данные согласно руководству EDPB
- Строки user-agent — могут позволить идентификацию устройства
- Токены сессий — если записываются в вывод
Записи приложения (структурированный JSON):
- Идентификаторы пользователей и адреса электронной почты
- Ошибки ввода — часто включают необработанное некорректное значение, которое может быть реальными данными пользователя
- Бизнес-события — идентификаторы заказов, связанные с аккаунтами клиентов
- Поисковые запросы — могут содержать имена или адреса
Записи API-шлюза:
- Заголовки авторизации — частично фиксируются в некоторых конфигурациях
- Параметры запросов — могут содержать идентификаторы пользователей, имена или email
- Тела запросов и ответов — присутствуют в конфигурациях уровня отладки
Аудиторские записи базы данных:
- SQL-запросы с условиями WHERE типа
email = 'user@example.com' - Литеральные персональные значения в параметрах запросов
Это происходит не намеренно. Это побочный эффект журналирования, созданного для отладки, а не для соответствия GDPR.
Руководство EDPB об IP-адресах
Европейский совет по защите данных признаёт IP-адреса персональными данными. Интернет-провайдеры могут связать их с абонентами. Внутри организации они могут идентифицировать конкретных пользователей.
Воздействие прямое. Записи доступа с IP-адресами — это персональные записи. Хранение вывода nginx 12 месяцев означает хранение персональных данных 12 месяцев. Это требует законного основания по статье 6. А также соответствия срока хранения заявленной цели.
Большинство команд пропускают этот шаг. «Мы храним записи 90 дней, потому что так требует служба безопасности» — это эмпирическое правило. Это не проверка по статье 5(1)(e) GDPR. Подробнее о том, как это вписывается в более широкую программу, см. в нашем обзоре правового соответствия.
Как достичь соответствия требованиям
Практический путь для большинства команд — не сокращать окна хранения. Операционные и сопутствующие задачи безопасности для более длительных окон вполне реальны. Лучший подход — маскировать записи перед долгосрочным хранением.
Хорошо работает многоуровневая модель.
0–7 дней: полные необработанные записи для активной отладки. Семи дней достаточно для большинства команд.
7–90 дней: замаскированные записи для анализа трендов и проверки безопасности. IP-адреса заменяются. Email-адреса пользователей становятся стабильными токенами. Номера аккаунтов маскируются. Ключевые поля — временны́е метки, коды ошибок, задержки, эндпоинты — сохраняются как есть.
90+ дней (при необходимости): только агрегированные данные. Количество событий, частота ошибок, диапазоны задержек. Записей на уровне пользователя не остаётся.
Персональные данные останавливаются на 7-м дне. Агрегированные данные могут продолжаться без раскрытия кого-либо. Подробнее см. в разделе Безопасность и соответствие требованиям.
Сохранение структуры для мониторинга
Качественное маскирование сохраняет структуру JSON нетронутой. Заменяется только содержимое. Это сохраняет ценность вывода для отладки и оповещений.
Сохраняется как есть:
- Ключи JSON и вложенность
- Временны́е метки и хронологический порядок
- Типы ошибок и HTTP-коды статуса
- HTTP-методы, пути и значения задержки
- Типы бизнес-событий
Заменяется:
- Адреса электронной почты → стабильный токен для каждого оригинала (например,
user1@example.com) - IP-адреса → диапазоны RFC 5737 (
192.0.2.x) - Номера аккаунтов →
ACCT_XXXXX - Номера телефонов →
+XX XXX XXX XXXX - Имена в тексте ошибок →
[ЧЕЛОВЕК]
Стабильные токены сохраняют полезность трасс. Трасса user1@example.com по 40 записям работает так же, как оригинальная. Агрегированные метрики — частота ошибок, задержка, пропускная способность — вообще не нуждаются в персональных данных. Термины псевдонимизация и анонимизация объяснены в нашем Глоссарии.
Три способа интеграции
Три паттерна охватывают большинство инженерных команд.
Вариант 1 — Маскирование в конвейере: Fluentd или Logstash перехватывает каждую строку перед отправкой. Шаг маскирования выполняется встроенно. Elastic или Datadog получают только очищенные записи. Изменения кода приложения не требуются.
Вариант 2 — Ночной пакет: Необработанные записи сохраняются в локальное хранилище. Ночное задание маскирует вывод предыдущего дня и удаляет необработанную версию. Замаскированные записи поступают в долгосрочное хранилище. Необработанный вывод хранится только семь дней.
Вариант 3 — Маскирование перед передачей: Необработанные записи хранятся внутри при строгом контроле доступа. Перед передачей пентестерам или внешним подрядчикам выполняется проход маскирования. Внешние стороны всегда получают чистые версии.
Для документации GDPR маскирование является «техническим мероприятием» по статье 32. Зафиксируйте инструмент, его конфигурацию и политику хранения в реестре операций по обработке (RoPA) по статье 30. Часто задаваемые вопросы о RoPA см. в нашем FAQ.
Реальные примеры? Ознакомьтесь с кейсами для конкретных деталей реализации. Вы также можете ознакомиться с нашими тарифами, чтобы узнать, какой план включает встроенные конвейеры маскирования.