Скритият GDPR риск в стека с журнали
Актуализирано за 2026 г.
Повечето екипи проверяват базата данни за лична информация. По-малко правят същото за своята журнална система.
Член 5(1)(д) от GDPR ограничава колко дълго можете да съхранявате лична информация. За бази данни екипите задават политики и изпълняват задачи за изтриване. За журнални файлове правилото е по-просто: пазете всичко 90 дни за отстраняване на грешки.
Проблемът? Тези записи съдържат лична информация. Записите на заявките съдържат имейли на потребители. Записите за грешки съдържат сурови входни стойности. Записите за достъп съдържат IP адреси. Всяко от тях се счита за лична информация по GDPR. Вашият екип се нуждае от правно основание и план за задържане за всяко едно.
Какво се озовава в журналните файлове
Стандартното регистриране на уеб приложения включва широк спектър от PII.
Записи за достъп (nginx/Apache):
- IP адреси -- лична информация съгласно насоките на EDPB
- Низове за потребителски агент -- може да позволяват fingerprinting на устройства
- Сесийни токени -- ако се записват в изхода
Записи на приложението (структуриран JSON):
- Потребителски ID и имейл адреси
- Грешки при вход -- често включват суровата невалидна стойност, която може да е реална потребителска информация
- Бизнес събития -- ID на поръчки, свързани с клиентски сметки
- Заявки за търсене -- може да съдържат имена или адреси
Записи на API gateway:
- Auth заглавки -- частично уловени в някои конфигурации
- Параметри на заявките -- може да съдържат ID на потребители, имена или имейли
- Тела на заявки и отговори -- присъстват при debug-ниво конфигурации
Записи за одит на база данни:
- SQL заявки с WHERE клаузи като
email = 'user@example.com' - Буквални лични стойности в параметри на заявки
Това не се прави нарочно. Това е страничен ефект от регистрирането, изградено за отстраняване на грешки, а не за GDPR.
Насоките на EDPB за IP адресите
Европейският съвет за защита на данните гласи, че IP адресите са лична информация. ISP могат да ги свържат с абонатите. Вътре в организацията те могат да идентифицират конкретни потребители.
Въздействието е пряко. Записите за достъп с IP адреси са лични записи. Пазенето на nginx изходни данни за 12 месеца означава пазене на лична информация за 12 месеца. Това изисква правно основание по член 6. Изисква също периодът на задържане да съответства на заявената цел.
Повечето екипи прескачат тази стъпка. "Пазим записи 90 дни, защото отдел Сигурност го изисква" е правило на палеца. Не е преглед по член 5(1)(д) от GDPR. Вижте нашия преглед на правното съответствие за начина, по който това се вписва в по-широка програма.
Как да постигнете съответствие
Практическият маршрут за повечето екипи не е да съкращават прозорците за задържане. Оперативните и причините за сигурност за по-дълги прозорци са реални. По-добрият начин е да маскирате записите преди дългосрочно съхранение.
Модел на нива работи добре.
0-7 дни: Пълни сурови записи за активно отстраняване на грешки. Седем дни е достатъчно кратко за повечето екипи.
7-90 дни: Маскирани записи за анализ на тенденции и преглед на сигурността. IP адресите са заменени. Имейлите на потребителите стават стабилни токени. Номерата на сметките са маскирани. Ключовите полета -- времеви маркери, кодове за грешки, латентност, endpoints -- се пазят непроменени.
90+ дни (ако е необходимо): Само обобщени изходни данни. Брой на събитията, нива на грешки, диапазони на латентност. Не остават записи на ниво потребители.
Личната информация спира след седем дни. Обобщените изходни данни могат да продължат без излагане на когото и да е. Вижте Сигурност и съответствие за повече подробности.
Запазете структурата непокътната за мониторинг
Доброто маскиране запазва JSON структурата непокътната. Само замества съдържанието. Това запазва полезността на изходните данни за отстраняване на грешки и сигнали.
Запазено непроменено:
- JSON ключове и влагане
- Времеви маркери и хронологичен ред
- Типове грешки и HTTP кодове за статус
- HTTP методи, пътища и стойности на латентност
- Типове бизнес събития
Заменено:
- Имейл адреси --> стабилен токен на оригинал (напр.
user1@example.com) - IP адреси --> диапазони RFC 5737 (
192.0.2.x) - Номера на сметки -->
ACCT_XXXXX - Телефонни номера -->
+XX XXX XXX XXXX - Имена в текст за грешки -->
[PERSON]
Стабилните токени запазват следите полезни. Следа за user1@example.com в 40 записа работи по същия начин като оригинала. Обобщените метрики -- нива на грешки, латентност, пропускателна способност -- не се нуждаят изобщо от лична информация. Вижте Речника за термините псевдонимизация и анонимизация.
Три начина за интегриране
Три модела покриват повечето инженерни екипи.
Вариант 1 -- Маскиране в тръбопровода: Fluentd или Logstash прихваща всеки ред преди изпращане нататък. Стъпка за маскиране работи вградено. Elastic или Datadog получава само почистени записи. Не се изискват промени в кода на приложението.
Вариант 2 -- Нощна групова обработка: Суровите записи попадат в локално хранилище. Нощна задача маскира предходния ден и изтрива суровата версия. Маскираните записи отиват в дългосрочно хранилище. Суровите изходни данни се пазят само седем дни.
Вариант 3 -- Маскиране преди споделяне: Суровите записи остават вътрешни при строги контроли за достъп. Преди споделяне с тестери на проникване или външни изпълнители, стартирайте проход за маскиране. Външните страни винаги получават чисти версии.
За документацията по GDPR маскирането е "техническа мярка" по член 32. Запишете инструмента, неговата конфигурация и политиката за задържане в Записите за дейностите по обработване (RoPA) по член 30. Вижте нашите ЧЗВ за чести въпроси относно RoPA.
Искате реален пример? Разгледайте казусите за конкретни подробности за внедряване. Можете също да прегледате нашите цени, за да видите кой план включва вградени тръбопроводи за маскиране.