RODO a logi aplikacji: zgodność JSON i danych osobowych

Cichy problem RODO w twoim systemie logowania

Zaktualizowano w 2026 r.

Większość zespołów kontroluje bazę danych pod kątem danych osobowych. Rzadko kto robi to samo z systemem logowania.

Art. 5 ust. 1 lit. e) RODO ogranicza okres przechowywania danych osobowych. W przypadku baz danych zespoły definiują polityki i uruchamiają zadania usuwania. W przypadku plików logów zasada bywa prostsza: trzymamy wszystko przez 90 dni na potrzeby debugowania.

Problem? Te rekordy zawierają dane osobowe. Wpisy żądań przechowują adresy e-mail użytkowników. Przechwycone błędy zawierają surowe wartości wejściowe. Wpisy dostępu zawierają adresy IP. Każdy z tych elementów kwalifikuje się jako dane osobowe w rozumieniu RODO. Twój zespół potrzebuje podstawy prawnej i planu retencji dla każdego z nich.

Co trafia do plików logów

Standardowe logowanie aplikacji webowej zbiera szeroki zakres danych osobowych.

Rekordy dostępu (nginx/Apache):

• Adresy IP — dane osobowe zgodnie z wytycznymi EROD
• Ciągi user-agent — mogą umożliwiać odcisk palca urządzenia
• Tokeny sesji — jeśli zapisywane do wyjścia

Rekordy aplikacji (ustrukturyzowany JSON):

• Identyfikatory użytkowników i adresy e-mail
• Błędy wejściowe — często zawierają surową nieprawidłową wartość, która może być prawdziwą daną użytkownika
• Zdarzenia biznesowe — identyfikatory zamówień powiązane z kontami klientów
• Zapytania wyszukiwania — mogą zawierać imiona i nazwiska lub adresy

Rekordy bramy API:

• Nagłówki autoryzacji — częściowo przechwytywane w niektórych konfiguracjach
• Parametry zapytań — mogą zawierać identyfikatory użytkowników, imiona i nazwiska lub adresy e-mail
• Treści żądań i odpowiedzi — obecne w konfiguracjach na poziomie debug

Wpisy audytu bazy danych:

• Zapytania SQL z klauzulami WHERE, takimi jak email = 'user@example.com'
• Literalne dane osobowe w parametrach zapytań

To nie dzieje się celowo. Jest to efekt uboczny logowania zbudowanego na potrzeby debugowania, a nie RODO.

Stanowisko EROD w sprawie adresów IP

Europejska Rada Ochrony Danych uznaje adresy IP za dane osobowe. Dostawcy usług internetowych mogą powiązać je z abonentami. Wewnątrz organizacji mogą identyfikować konkretnych użytkowników.

Skutek jest bezpośredni. Rekordy dostępu zawierające adresy IP są rekordami osobowymi. Przechowywanie wyjścia nginx przez 12 miesięcy oznacza przechowywanie danych osobowych przez 12 miesięcy. Wymaga to podstawy prawnej z art. 6. Wymaga też, by okres retencji odpowiadał zadeklarowanemu celowi.

Większość zespołów pomija ten krok. „Przechowujemy wpisy przez 90 dni, bo tak mówi dział bezpieczeństwa” to reguła praktyczna. Nie jest to przegląd w świetle art. 5 ust. 1 lit. e) RODO. Zapoznaj się z naszym przeglądem zgodności prawnej, aby zobaczyć, jak wpasowuje się to w szerszy program.

Jak osiągnąć zgodność

Praktyczna droga dla większości zespołów nie polega na skracaniu okien retencji. Operacyjne i bezpieczeństwa uzasadnienia dłuższych okien są realne. Lepsza ścieżka to maskowanie rekordów przed długoterminowym przechowywaniem.

Dobrze sprawdza się model warstwowy.

0–7 dni: Pełne surowe rekordy do aktywnego debugowania. Siedem dni wystarczy większości zespołów.

7–90 dni: Zamaskowane rekordy do analizy trendów i przeglądu bezpieczeństwa. Adresy IP są zastępowane. Adresy e-mail użytkowników stają się stabilnymi tokenami. Numery kont są maskowane. Kluczowe pola — znaczniki czasu, kody błędów, opóźnienia, punkty końcowe — pozostają bez zmian.

90+ dni (w razie potrzeby): Wyłącznie zagregowane dane wyjściowe. Liczby zdarzeń, wskaźniki błędów, zakresy opóźnień. Żadnych rekordów na poziomie użytkownika.

Dane osobowe kończą się po siedmiu dniach. Zagregowane dane wyjściowe można przekazywać dalej bez narażania kogokolwiek. Więcej szczegółów znajdziesz w sekcji Bezpieczeństwo i zgodność.

Zachowanie struktury na potrzeby monitorowania

Dobre maskowanie zachowuje strukturę JSON w nienaruszonym stanie. Zamienia tylko zawartość. Dzięki temu dane wyjściowe pozostają przydatne do debugowania i alertów.

Zachowane bez zmian:

• Klucze JSON i zagnieżdżenie
• Znaczniki czasu i porządek chronologiczny
• Typy błędów i kody statusu HTTP
• Metody HTTP, ścieżki i wartości opóźnień
• Typy zdarzeń biznesowych

Zastępowane:

• Adresy e-mail → stabilny token dla oryginału (np. user1@example.com)
• Adresy IP → zakresy RFC 5737 (192.0.2.x)
• Numery kont → ACCT_XXXXX
• Numery telefonów → +XX XXX XXX XXXX
• Imiona i nazwiska w treści błędów → [OSOBA]

Stabilne tokeny zachowują przydatność śladów. Ślad dla user1@example.com obejmujący 40 wpisów działa tak samo jak oryginał. Metryki zagregowane — wskaźniki błędów, opóźnienia, przepustowość — nie potrzebują w ogóle danych osobowych. Zapoznaj się ze słownikiem dotyczącym terminów pseudonimizacja i anonimizacja.

Trzy sposoby integracji

Trzy wzorce obejmują większość zespołów inżynierskich.

Opcja 1 — Maskowanie w potoku: Fluentd lub Logstash przechwytuje każdą linię przed jej dalszym przekazaniem. Krok maskowania działa inline. Elastic lub Datadog otrzymuje wyłącznie oczyszczone rekordy. Nie są wymagane żadne zmiany w kodzie aplikacji.

Opcja 2 — Nocna partia: Surowe rekordy trafiają do lokalnego magazynu. Nocne zadanie maskuje dane wyjściowe z poprzedniego dnia i usuwa surową wersję. Zamaskowane rekordy trafiają do długoterminowego magazynu. Surowe dane wyjściowe są przechowywane wyłącznie przez siedem dni.

Opcja 3 — Maskowanie przed udostępnieniem: Surowe rekordy pozostają wewnętrzne z ścisłą kontrolą dostępu. Przed udostępnieniem testerom penetracyjnym lub zewnętrznym wykonawcom uruchamiaj przebieg maskowania. Strony zewnętrzne zawsze otrzymują oczyszczone wersje.

W dokumentacji RODO maskowanie jest „środkiem technicznym” w rozumieniu art. 32. Udokumentuj narzędzie, jego konfigurację oraz politykę retencji w Rejestrze Czynności Przetwarzania (RCP) prowadzonym na podstawie art. 30. Odpowiedzi na typowe pytania dotyczące RCP znajdziesz w naszym FAQ.

Chcesz zobaczyć przykład z życia? Zajrzyj do case studies, gdzie znajdziesz konkretne szczegóły wdrożenia. Możesz też sprawdzić nasze cenniki, aby dowiedzieć się, który plan zawiera wbudowane potoki maskowania.

Źródła

• Art. 5 RODO: Zasady przetwarzania danych — ZWERYFIKOWANE ZEWNĘTRZNIE
• Opinia EROD 5/2019 w sprawie dyrektywy ePrivacy i RODO — ZWERYFIKOWANE ZEWNĘTRZNIE
• Sonra.io: Maskowanie PII w danych JSON i XML — ZWERYFIKOWANE ZEWNĘTRZNIE