Тивкиот GDPR Ризик во Вашиот Систем за Дневници
Ажурирано за 2026 година
Повеќето тимови ја проверуваат базата на податоци за лични информации. Помалку го прават истото за нивниот систем за дневници.
GDPR Член 5(1)(е) го ограничува времето колку долго можете да чувате лични информации. За бази на податоци, тимовите поставуваат политики и извршуваат задачи за бришење. За дневнички фајлови, правилото е поедноставно: чувај сé 90 дена за дебагирање.
Проблемот? Тие записи содржат лични информации. Записите за барања содржат е-пошти на корисниците. Записите за грешки содржат сурови вредности на внес. Записите за пристап содржат IP адреси. Секоја од нив се смета за лични информации под GDPR. Вашиот тим треба правна основа и план за задржување за секоја од нив.
Што Завршува во Вашите Дневнички Фајлови
Стандардното логирање на веб апликации повлекува широк опсег на лични податоци.
Записи за пристап (nginx/Apache):
- IP адреси — лични информации според насоките на EDPB
- Низи на кориснички агент — може да овозможат отпечаток на уред
- Токени за сесија — ако се запишани во излез
Записи на апликацијата (структуриран JSON):
- Корисничките ID-а и е-пошта адреси
- Грешки во внес — честопати ја вклучуваат суровата неважечка вредност, која може да биде вистинска корисничка информација
- Деловни настани — ID-а на нарачки поврзани со кориснички сметки
- Пребарувачки прашања — може да содржат имиња или адреси
Записи на API портата:
- Auth заглавија — делумно фатени во некои поставки
- Параметри на прашања — може да носат корисничките ID-а, имиња или е-пошти
- Тела на барања и одговори — присутни во поставки за ниво на дебагирање
Записи за ревизија на базата на податоци:
- SQL прашања со WHERE клаузули, како
email = 'user@example.com' - Буквални лични вредности во параметрите на прашањата
Ова не се прави намерно. Тоа е несакан ефект на логирање изградено за дебагирање, а не за GDPR.
Насоки на EDPB за IP Адреси
Европскиот одбор за заштита на податоци вели дека IP адресите се лични информации. ИСП-ите можат да ги поврзат со претплатниците. Во рамките на организацијата, тие можат да идентификуваат специфични корисници.
Влијанието е директно. Записите за пристап со IP адреси се лични записи. Чувањето nginx излез 12 месеци значи чување лични информации 12 месеци. За тоа е потребна правна основа под Член 6. Исто така бара периодот на задржување да одговара на вашата наведена цел.
Повеќето тимови го прескокнуваат овој чекор. "Чуваме записи 90 дена затоа што безбедноста го вели" е практично правило. Тоа не е преглед по GDPR Член 5(1)(е). Видете го нашиот Преглед за правна усогласеност за тоа како ова се вклопува во поширока програма.
Како да Постигнете Усогласеност
Практичниот пат за повеќето тимови не е намалување на прозорците за задржување. Оперативните и безбедносните причини за подолги прозорци се реални. Подобриот пат е маскирање на записите пред долгорочно складирање.
Слоевит модел функционира добро.
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.
Сакате реален пример? Проверете ги студиите на случај за конкретни детали за имплементација. Исто така можете да го прегледате нашето ценување за да видите кој план вклучува вградени процеси за маскирање.
Извори
- GDPR Член 5: Начела за обработка на податоци — VERIFIED-EXTERNAL
- EDPB Мислење 5/2019 за Директивата за е-приватност и GDPR — VERIFIED-EXTERNAL
- Sonra.io: Маскирање на лични податоци во JSON и XML — VERIFIED-EXTERNAL