Мовчазне порушення GDPR у вашому стеку спостереженості
Більшість команд розробників знають, що вони обробляють персональні дані у своїй базі даних застосунків. Менше з них провели аудит своєї системи управління журналами з тією ж ретельністю.
Стаття 5(1)(e) GDPR вимагає, щоб персональні дані зберігалися «не довше, ніж це необхідно для цілей, для яких вони обробляються» — принцип обмеження зберігання. Для баз даних застосунків у організацій є політики зберігання, завдання видалення та процеси мінімізації даних.
Для журналів застосунків типова політика набагато простіша: зберігати все протягом 90 днів (або 6 місяців, або 1 року) з операційних і безпекових міркувань.
Проблема: ці журнали містять персональні дані.
Типові патерни PII у JSON-журналах
{
"timestamp": "2025-03-15T09:23:41Z",
"event": "user_login",
"user_email": "sarah.johnson@example.com",
"ip_address": "192.168.1.47",
"user_agent": "Mozilla/5.0..."
}
{
"timestamp": "2025-03-15T09:24:12Z",
"event": "payment_processed",
"customer_name": "Sarah Johnson",
"amount": 99.99,
"account_id": "ACC-4521893"
}
Кожна з цих записів містить персональні дані GDPR. Обидві типово записуються у ваш стек спостереженості (ELK, Datadog, Splunk, CloudWatch).
Технічний підхід: маскування PII у журналах у реальному часі
Рівень структурованих журналів: Анонімізуйте перед записом — не після. У вашому коді програмного забезпечення:
# Перед:
logger.info(f"Вхід користувача: {user.email} від {request.ip}")
# Після:
masked_email = anonymize(user.email) # → EMAIL_ADDRESS_1
masked_ip = anonymize(request.ip) # → IP_ADDRESS_1
logger.info(f"Вхід користувача: {masked_email} від {masked_ip}")
Для наявних журналів: Пакетна обробка наявного архіву журналів для видалення PII перед настанням кінця терміну зберігання.
Джерела: