Тихото нарушение на GDPR във вашия стек за наблюдение
Повечето инженерни екипи знаят, че обработват лични данни в базата данни на своите приложения. По-малко са одитирали своята система за управление на регистрационни файлове със същата строгост.
GDPR Член 5, параграф 1, буква д) изисква личните данни да се съхраняват „не по-дълго, отколкото е необходимо за целите, за които се обработват личните данни“ — принципът за ограничаване на съхранението. За бази данни с приложения организациите имат политики за задържане, задания за изтриване и процеси за минимизиране на данни.
За регистрационните файлове на приложенията типичната политика е много по-проста: съхранявайте всичко за 90 дни (или 6 месеца, или 1 година) от съображения за работа и сигурност. Периодът на съхранение се определя от нуждите за отстраняване на грешки и одит, а не от анализ на лични данни.
Проблемът: тези регистрационни файлове съдържат лични данни. Всеки регистър на заявки, който включва имейл адреса на потребителя, всеки регистър на грешки, който улавя въведени данни за валидиране, всеки регистър на достъп, който записва IP адрес — това са лични данни по член 4, параграф 1 от GDPR. Организацията има въпрос за правно основание GDPR, на който трябва да отговори за всеки период на съхранение.
Какво всъщност се озовава в регистрационните файлове на приложението
Проучване на често срещани формати на регистрационни файлове на уеб приложения разкрива широчината на PII, която се натрупва:
Дневници за достъп (nginx/Apache):
- IP адреси (директни GDPR лични данни съгласно EDPB ръководство)
- Низове на потребителски агент (може да допринесе за пръстови отпечатъци)
- Токени за сесия (ако са регистрирани)
Регистри на приложението (структурирани JSON):
- Потребителски идентификатори (имейл адреси, потребителски идентификатори, свързани с профили)
- Грешки при проверка на входа (често съдържат невалиден вход - който може да е реални данни на потребителя)
- Регистри на бизнес събития (идентификационни номера на поръчки, свързани с клиентски акаунти, справки за билети за поддръжка)
- Заявки за търсене (може да съдържат лични имена, адреси)
Регистрационни файлове на шлюза на API:
- Заглавки за оторизация (вписани частично в някои конфигурации)
- Параметри на заявката (може да съдържа потребителски идентификатори, имена, имейли)
- Тела на заявка/отговор (в конфигурации за регистриране на грешки)
Регистри на заявки към бази данни (журнали на бавни заявки, регистрационни файлове за одит):
- SQL заявки, включително WHERE клаузи с имейл = 'user@example.com'
- Литерални стойности на лични данни в параметрите на заявката
Натрупването не е умишлено. Това е страничен продукт от стандартните практики за регистриране, които са предназначени за отстраняване на грешки, а не за съответствие със GDPR.
EDPB Позиция на IP адреси в регистрационни файлове
Европейският съвет за защита на данните последователно поддържа, че IP адресите са лични данни съгласно GDPR — те са „идентифицируеми“, тъй като доставчиците на интернет услуги могат да ги свържат с абонати, а в организационен контекст те могат да идентифицират конкретни потребители.
Това има пряко значение за запазването на регистрационните файлове: регистрационните файлове за достъп, съдържащи IP адреси, са регистрационни файлове с лични данни. Запазването на регистрационни файлове за достъп на nginx за 12 месеца е запазване на лични данни за 12 месеца. 12-месечното съхранение изисква законово основание съгласно член 6, а принципът за ограничаване на съхранението изисква периодът на съхранение да е необходим за конкретната цел.
Повечето организации не са анализирали изрично своите периоди на съхранение на регистрационни файлове спрямо тази рамка. „Пазим регистрационни файлове в продължение на 90 дни, защото това казва екипът по сигурността“ е изявление относно оперативната практика, а не анализ на GDPR член 5(1)(e).
Пътят на анонимизирането към съответствие
Практическият път за съответствие на регистрационните файлове GDPR за повечето инженерни екипи не е да се намали задържането на регистрационни файлове (което има оправдания за оперативна сигурност), а да се анонимизират регистрационните файлове преди дългосрочно задържане.
Моделът на многостепенно задържане:
0-7 дни: Пълните необработени регистрационни файлове се запазват за активно отстраняване на грешки. Оперативната обосновка е ясна; периодът на задържане е достатъчно кратък, за да се избегнат проблеми с ограничаване на съхранението за повечето организации.
7-90 дни: Анонимизирани регистрационни файлове се запазват за анализ на тенденции и наблюдение на сигурността. IP адреси, заменени с анонимни IP адреси; потребителски имейли, заменени с последователни токени; маскирани номера на сметки. Технически метаданни (времеви отпечатъци, кодове на грешки, латентност, крайни точки), запазени за оперативен анализ.
90+ дни (ако е необходимо): Само агрегирани регистрационни данни (брой събития, проценти на грешки, разпределение на латентността) — без записи на индивидуално ниво.
Този модел поддържа оперативна полезност на всяко ниво на съхранение, като същевременно отговаря на принципа за ограничаване на съхранението: периодът на съхранение на лични данни е 7 дни; агрегираните оперативни данни се запазват по-дълго без излагане на лични данни.
Запазване на структурата за случаи на използване на наблюдаемост
Основното техническо изискване за анонимизиране на регистрационни файлове, което запазва полезността за наблюдение, е структурно запазване с подмяна на съдържание:
Запазени:
- JSON структура и имена на ключове
- Времеви марки и времеви последователности
- Типове и кодове на грешки
- HTTP методи, пътища, кодове за състояние
- Стойности на латентност и показатели за ефективност
- Видове бизнес събития (направена поръчка, получено плащане)
Заменен:
- Имейл адреси → user1@example.com (последователен токен за оригинален имейл в регистрационния файл)
- IP адреси → RFC 5737 документация адреси (192.0.2.x, 198.51.100.x)
- Номера на сметки → ACCT_XXXXX
- Телефонни номера → +XX XXX XXX XXXX
- Имена от контексти на грешки → [PERSON]
С последователната подмяна на токена оперативният анализ се запазва: проследяване на заявка, следващо user1@example.com през 40 записа в журнала, работи по същия начин за отстраняване на грешки като оригиналния имейл — тъй като токенът е последователен в целия лог файл.
Агрегираните показатели не са засегнати: проценти на грешки за крайна точка, процентили на латентност, изчисления на пропускателната способност — нито едно от тях не изисква познаване на действителния имейл адрес на потребителя, който е задействал заявката.
Практическа интеграция за инженерни екипи
За екип на приложение Django или Node.js, интегрирането на анонимизирането на журнала изглежда така:
Вариант 1: Интеграция на тръбопровода за регистрационни файлове
- Доставчикът на дневници на Fluentd/Logstash прихваща дневници
- Стъпката за анонимизиране се изпълнява на всеки ред в журнала преди препращане
- Платформата за наблюдение (Elastic/Datadog) получава анонимизирани регистрационни файлове
- Не са необходими промени в кода за регистриране на приложението
Вариант 2: Нощно пакетно анонимизиране
- Необработени регистрационни файлове, записани в локално хранилище
- Нощен cron: анонимизиране на вчерашните регистрационни файлове, изтриване на необработената версия
- Анонимизирани регистрационни файлове, изпратени до дългосрочно съхранение
- Необработените регистрационни файлове се съхраняват само за 7 дни
Вариант 3: Анонимизиране преди споделяне
- Необработени регистрационни файлове, съхранявани вътрешно с подходящи контроли за достъп
- При външно споделяне (тестери на писалки, изпълнители): изпълнете анонимизиране, преди да предоставите достъп
- Външните страни винаги получават анонимни версии
За документация за съответствие на GDPR: анонимизирането на регистрационни файлове е „техническа мярка“ съгласно член 32 на GDPR. Документирането на стъпката на анонимизиране — инструмент, конфигурация, политика за запазване — е част от Записите на дейностите по обработка (RoPA), изисквани съгласно член 30.
Източници:
- [GDPR член 5: Принципи за обработка на данни] (https://gdpr-info.eu/art-5-gdpr/)
- EDPB: Становище 5/2019 относно взаимодействието между Директивата за неприкосновеността на личния живот и електронните комуникации и GDPR
- [Sonra.io: Маскиране на PII в JSON и XML данни] (https://sonra.io/paranoid-masking-anonymizing-and-obfuscating-pii-in-xml-and-json-data/)