PII ховається в журналах застосунків
Журнали застосунків — одна з найбільш недооцінених поверхонь GDPR в розробці. Не тому що інженери ігнорують закон, а тому що дані користувачів потрапляють у журнальні файли випадково.
Один запис JSON-запиту може містити чотири поля PII:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "sarah.johnson@company.com",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0",
"error": "ValidationError: phone format",
"input_value": "+49 176 1234 5678"
}
Цей один запис містить адресу електронної пошти, IP-адресу та номер телефону. Помножте це на мільйони щоденних API-викликів. Результат — масштабна операція з PII, яка потребує правової підстави, обмежень та засобів контролю.
Передача журналів третім сторонам підвищує ризик GDPR
Команди регулярно передають файли журналів стороннім особам:
- Компанії з тестування на проникнення отримують записи для аналізу поведінки застосунку
- Зовнішні консультанти використовують зразки журналів для пошуку вузьких місць
- Журнальні платформи (Elastic, Datadog, Splunk) отримують повні вихідні потоки
- Підрядники SRE отримують доступ до записів під час інцидентів
- Команди розробників у інших юридичних особах отримують файли для налагодження
Кожна така передача піднімає питання Статті 28 GDPR. Чи є одержувач обробником? Чи є угода про обробку даних? Чи є в них правова підстава бачити дані користувачів у цих файлах?
Журнальні платформи — поширена прогалина. Відправлення виводу з реальними адресами електронної пошти та IP-адресами на Elastic Cloud або Datadog створює зв'язок обробки, що потребує угоди про обробку даних, стандартних договірних умов та інструменту передачі для платформ за межами ЄС. Кожне з них вимагає часу та юридичної перевірки.
Простіший шлях: видаліть дані користувачів перед тим, як файли покинуть вашу систему. Ознайомтеся з нашим оглядом відповідності щодо повних правил Статті 28.
Чому структура JSON ускладнює виявлення
Файли журналів JSON різняться за структурою. Загальне сканування тексту недостатнє.
Глибина вкладеності: Дані користувачів з'являються на будь-якій глибині. Поле request.headers.x-forwarded-for містить IP-адреси. Поле response.body.errors[0].field_value може містити введення користувача. Плоске сканування тексту пропускає поля, що ховаються у вкладених шляхах.
Непослідовні схеми: Кожна кінцева точка API виробляє власну форму виводу. Файли автентифікації відрізняються від файлів оплати. Файли оновлення профілю відрізняються від обох. Підхід на основі фіксованих шляхів пропускає дані користувачів, що з'являються за нестандартними шляхами в контекстах помилок.
Технічні значення, змішані з PII: Трасування стека, коди помилок та часові мітки мають залишатися цілими. Суцільне видалення стирає потрібні поля і робить файл марним.
Правильний підхід — виявлення на основі вмісту. Знаходьте дані користувачів за тим, чим вони є — шаблоном електронної пошти, форматом IP, іменованою сутністю — а не за тим, де вони знаходяться в структурі. Це обробляє змінні схеми без налаштування для кожної кінцевої точки.
Послідовна заміна зберігає журнали корисними
Ключова вимога — референційна цілісність. Якщо sarah.johnson@company.com з'являється у 47 записах ланцюжка запитів, всі 47 повинні відображатися на одне й те саме значення.
Правила відображення:
sarah.johnson@company.com→user1@example.com(те саме значення у всьому файлі)82.123.45.67→192.0.2.1(IP-адреса документації RFC 5737 — явно не реальна)+49 176 1234 5678→+49 XXX XXX XXXX(замаскований)
З таким відображенням розробник може відстежити user1@example.com через 47 записів, відтворити ланцюжок запитів та виправити помилку — не бачачи реальних даних жодного користувача.
Ці поля метаданих залишаються без змін:
- Часові мітки (не дані користувача)
- Коди та типи помилок (не дані користувача)
- Трасування стека (можуть містити технічні ідентифікатори, не дані користувача)
- HTTP-методи, шляхи, коди стану (не дані користувача)
- Значення метрик та затримки (не дані користувача)
Результат — файл, придатний для налагодження, що не містить реальних даних користувачів. Дивіться наш глосарій для розуміння різниці між анонімізацією та псевдонімізацією за GDPR.
Варіант використання: передача журналів для тестування на проникнення
SaaS-компанія проводила щоквартальний аудит безпеки із зовнішньою командою тестувальників. Обсяг роботи вимагав 90 днів виробничого API-виводу для аналізу потоків автентифікації та шаблонів помилок.
Сирий обсяг: 180 МБ JSON-файлів. Кількість PII: 4 200 унікальних адрес електронної пошти, 1 800 унікальних IP-адрес, 340 часткових номерів рахунків у контекстах помилок.
Без попереднього видалення даних користувачів передача цих файлів потребувала б:
- Угоди про обробку даних з командою тестувальників
- Інструменту передачі за Статтею 46 GDPR (компанія знаходилась за межами ЄС)
- Перегляду повідомлення для суб'єктів даних
Кожне з них додає юридичну роботу та час.
З застосуванням видалення PII:
- Час обробки: 25 хвилин для 180 МБ
- Результат: 180 МБ структурно ідентичних файлів, усі адреси електронної пошти та IP-адреси замінені на безпечні значення
- Підсумок: команда тестувальників отримала повний контекст; нуль реальних даних користувачів їм не передавався
- Результат GDPR: угода про обробку даних не потрібна — очищений вивід не є даними користувачів за GDPR
Дивіться наш FAQ з поширеними запитаннями про те, що вважається анонімним за GDPR.
Інтеграція видалення PII в CI/CD
Для команд, що регулярно передають вивід, цей крок може виконуватись у наявних конвеєрах.
Ротація журналів:
- Скрипт ротації запускається щоночі
- Крок видалення виконується перед архівуванням або передачею на будь-яку журнальну платформу
- Очищені файли надходять до зовнішніх систем
- Оригінальні файли залишаються внутрішніми з повним терміном зберігання
Скрипт попередньої передачі:
- Інженер потребує передати зразок підряднику
- Запускає скрипт:
input=raw-logs/ output=clean-logs/ - Передає папку
clean-logs/ - Ручна перевірка PII не потрібна
Підхід sidecar:
- Sidecar очищує вихідний потік перед пересиланням
- Очищення в реальному часі зберігає корисність для аналізу журналів
- Платформа отримує нуль реальних даних користувачів
Інтеграція з політикою зберігання
Стаття 5(1)(e) GDPR вимагає обмеження зберігання. Видалення PII вписується в будь-яку політику зберігання.
- Сирий вивід зберігається 7 днів (для щоденної роботи з налагодження)
- Очищені версії зберігаються 90 днів (для аналізу тенденцій та перегляду інцидентів)
- Крок очищення виконується на 7-й день
Це відповідає обмеженню зберігання та усуває ризик тривалого зберігання сирого виводу.