Прихований ризик GDPR у вашому стеку журналювання
Оновлено для 2026 року
Більшість команд перевіряють свою базу даних на наявність персональної інформації. Набагато менше — свою систему журналювання.
Стаття 5(1)(e) GDPR обмежує час зберігання персональної інформації. Для баз даних команди встановлюють політики та запускають завдання видалення. Для журнальних файлів правило простіше: зберігати все 90 днів для налагодження.
Проблема? Ці записи містять персональну інформацію. Записи запитів містять адреси електронної пошти користувачів. Записи помилок містять сирі вхідні значення. Записи доступу містять IP-адреси. Кожне з них є персональною інформацією за GDPR. Вашій команді потрібна правова підстава та план зберігання для кожного.
Що потрапляє у ваші журнальні файли
Стандартне журналювання веб-застосунків тягне за собою широкий спектр PII.
Записи доступу (nginx/Apache):
- IP-адреси — персональна інформація згідно з рекомендаціями EDPB
- Рядки user-agent — можуть уможливити відбиток пристрою
- Токени сесій — якщо записуються у вивід
Записи застосунку (структурований JSON):
- ІД користувачів та адреси електронної пошти
- Помилки введення — часто містять сире невалідне значення, яке може бути реальною інформацією користувача
- Бізнес-події — ІД замовлень, пов'язані з рахунками клієнтів
- Пошукові запити — можуть містити імена або адреси
Записи API-шлюзу:
- Заголовки авторизації — частково захоплені в деяких конфігураціях
- Параметри запиту — можуть містити ІД користувачів, імена або адреси електронної пошти
- Тіла запитів і відповідей — присутні в конфігураціях рівня налагодження
Записи аудиту бази даних:
- 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-адреси замінюються. Адреси електронної пошти стають стабільними токенами. Номери рахунків маскуються. Ключові поля — часові мітки, коди помилок, затримка, кінцеві точки — залишаються як є.
90+ днів (за потреби): Лише агрегований вивід: кількість подій, частота помилок, діапазони затримки. Записи на рівні користувача відсутні.
Персональна інформація зупиняється на сьомому дні. Агрегований вивід може зберігатися далі без розкриття будь-кого. Дивіться Безпеку та відповідність для отримання додаткової інформації.
Зберігайте структуру цілою для моніторингу
Якісне маскування зберігає структуру 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. Дивіться наш FAQ з поширеними запитаннями щодо RoPA.
Хочете реальний приклад? Ознайомтеся з кейсами для детальної інформації про впровадження. Також перегляньте наші тарифи, щоб дізнатися, який план включає вбудовані конвеєри маскування.