Tiché riziko GDPR vo vasom logovom zasobniku
Aktualizovane pre rok 2026
Vacsina timov kontroluje svoju databazu kvoli osobnym udajom. Menej z nich robi to iste pre svoj logovaci system.
GDPR clanok 5(1)(e) obmedzuje, ako dlho mozete ukladat osobne udaje. Pre databazy timy nastavuju politiky a spustaju vymazavacie ulohy. Pre logove subory je pravidlo jednoduchsie: uchovat vsetko 90 dni na ladenie.
Problemon? Tieto zaznamy obsahuju osobne udaje. Zaznamy poziadaviek obsahuju emaily pouzivatelov. Zachytenia chyb obsahuju surove vstupne hodnoty. Zaznamy pristupov obsahuju IP adresy. Kazda z tychto hodnot sa pocita ako osobne udaje podla GDPR. Vas tim potrebuje pravny zaklad a plan uchovannia pre kazdu z nich.
Co skoncuje vo vasich logových suboroch
Standardne logovanie webovych aplikacii prinas siroky rad OOU.
Zaznamy pristupov (nginx/Apache):
- IP adresy - osobne udaje podla usmernenia EDPB
- Retazce user-agent - mozu umoznit snimanie odtlacku zariadenia
- Tokeny relacii - ak su zapisane do vystupu
Zaznamy aplikacie (strukturovany JSON):
- ID pouzivatelov a emailove adresy
- Chyby vstupu - casto obsahuju surovu neplatnu hodnotu, ktora moze byt skutocna informacia pouzivatela
- Obchodne udalosti - ID objednavok prepojene so zakazn ickymi uctmi
- Vyhladavacie dotazy - mozu obsahovat mena alebo adresy
Zaznamy API brany:
- Autentifikacne hlavicky - ciastocne zachytene v niektorch nastaveniach
- Parametre dotazu - mozu obsahovat ID pouzivatelov, mena alebo emaily
- Tela poziadaviek a odpovedi - pritomne v nastaveniach na urovni ladenia
Auditove zaznamy databazy:
- SQL dotazy s klauzulami WHERE ako
email = 'pouzivatel@example.com' - Doslovna osobne hodnoty v parametroch dotazu
Toto sa nedeje umyselne. Je to vedlajsi efekt logovania vytvoreho pre ladenie, nie GDPR.
Usmernenie EDPB k IP adresam
Europska rada pre ochranu udajov uvadza, ze IP adresy su osobne udaje. Poskytovatelia internetovych sluzieb ich mozu priradit k odberatelom. V ramci organizacie mozu identifikovat konkretnych pouzivatelov.
Dopat je priamy. Zaznamy pristupov s IP adresami su osobne zaznamy. Uchovanie vystupu nginx 12 mesiacov znamena uchovanie osobnych udajov 12 mesiacov. To potrebuje pravny zaklad podla clanku 6. Potrebuje tiez, aby period uchovavania zodpovedal vasmu deklarovanemu ucelu.
Vacsina timov tento krok preskoci. "Uchovame zaznamy 90 dni, lebo to hovori bezpecnost" je palcova pravidlo. Nie je to prezkum GDPR clanku 5(1)(e). Pozrite si nasu prirucku k pravnemu sulaadu pre to, ako toto zapadda do srirsieho programu.
Ako dosiahnut sulaad
Prakticka cesta pre vacsinu timov nie je skratit okna uchovavania. Operacne a bezpecnostne dovody pre dlhsie okna su opodstatnene. Lepsia cesta je maskovat zaznamy pred dlhodobym ukladanim.
Dobre funguje vrstveny model.
0-7 dni: Plne surove zaznamy pre aktivne ladenie. Sedem dni je dostatocne kratke pre vacsinu timov.
7-90 dni: Maskovane zaznamy pre analyzu trendov a bezpecnostnu kontrolu. IP adresy su vymnenene. Uzivatelske emaily sa stanú stabilnymi tokenmi. Cisla uctov su maskovane. Klucove polia - casove razitka, chybove kody, latencia, endpointy - su zachovane.
90+ dni (ak je potrebne): Iba agregatny vystup. Pocty udalosti, miery chyb, rozsahy latencie. Nezostanu ziadne zaznamy na urovni pouzivatela.
Osobne udaje sa zastavia na siedmich dnoch. Agregatny vystup moze pokracovat bez ohrozenia kohokovek. Pozri Bezpecnost a suland pre viac detailov.
Zachovajte strukturu neporosenou pre monitoring
Dobre maskovanie zachovava strukturu JSON nerusene. Iba zameni obsah. To zachovava uzitocnost vystupu pre ladenie a upozornenia.
Ponechane nezmenene:
- Kluce JSON a vnorenie
- Casove razitka a casove poradie
- Typy chyb a stavove kody HTTP
- HTTP metody, cesty a hodnoty latencie
- Typy obchodnych udalosti
Vymenenene:
- Emailove adresy -> stabilny token pre povodny (napr.
user1@example.com) - IP adresy -> rozsahy RFC 5737 (
192.0.2.x) - Cisla uctov ->
ACCT_XXXXX - Telefonne cisla ->
+XX XXX XXX XXXX - Mena v chybovom texte ->
[OSOBA]
Stabilne tokeny zachovavaju tracky uzitocnymi. Trace pre user1@example.com napriec 40 zaznammi funguje rovnako ako povodny. Agregatne metriky - miery chyb, latencia, priepustnost - nepotrebuju vobec osobne udaje. Pozri Glosár pre pojmy pseudonymizacia a anonymizacia.
Tri sposoby integracie
Tri vzory pokryvaju vacsinu inzinierskych timov.
Moznost 1 - Maskovanie v pipeline: Fluentd alebo Logstash zachyti kazdy riadok pred jeho odoslanim. Krok maskovania bezi inline. Elastic alebo Datadog dostanu iba ocistene zaznamy. Nie su potrebne zmeny kodu aplikacie.
Moznost 2 - Nocna davka: Surove zaznamy pristuju do lokalneho ukladania. Nocna uloha maskuje vystup z predchazdajuceho dna a vymaze surovu verziu. Maskovane zaznamy idu do dlhodobeho ukladania. Surovy vystup je uchovavany iba sedem dni.
Moznost 3 - Maskovanie pred zdielanim: Surove zaznamy zostanu interne s prisnymi kontrolami pristupu. Pred zdielanim s penetracnymi testermi alebo externymi dodavatelmi spustite maskovaci prechod. Externie strany vzdy dostanu ciste verzie.
Pre dokumentaciu GDPR je maskovanie "technickym opatrenim" podla clanku 32. Zaznamente nastroj, jeho nastavenie a vasu politiku uchovavania v zaznamoch o cinnostiach spracovania (RoPA) podla clanku 30. Pozri nase FAQ pre bezne otazky k RoPA.
Chcete realny priklad? Pozrite sa na pripadove studie pre konkretne detaily implementacie. Moze tiez prezriet nase cennik a zistit, ktory plan zahrnuje vstavane maskovacie pipeline.