Les dades personals s'amaguen als registres d'aplicacio
Els registres d'aplicacio son una de les superficies del RGPD mes ignorades en l'enginyeria. No perque els enginyers ignorin la llei. Sino perque els detalls dels usuaris entren als fitxers de registre per accident.
Un sol registre de peticio JSON pot tenir quatre camps de dades personals:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "sarah.johnson@company.com",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0",
"error": "ValidationError: phone format",
"input_value": "+49 176 1234 5678"
}
Aquesta sola entrada conte un correu electronic, una IP i un numero de telefon. Multipliqueu-ho per milions de trucades API diaries. El resultat es una activitat de dades personals major. Necessita una base legal, limits i controls.
Compartir registres amb tercers augmenta el risc del RGPD
Els equips comparteixen fitxers de registre amb parts externes tot el temps:
- Empreses de proves de penetracio reben registres per mapejar el comportament de l'aplicacio
- Consultors externs utilitzen mostres de registres per trobar punts lents
- Plataformes de registre (Elastic, Datadog, Splunk) reben fluxos de sortida complets
- Contractistes SRE accedeixen als registres durant incidents
- Equips de desenvolupament en altres entitats legals reben fitxers per a la depuracio
Cada comparticio planteja preguntes de l'Article 28 del RGPD. El destinatari es un encarregat del tractament? Hi ha un Acord de Tractament de Dades? Tenen una base legal per veure els detalls de l'usuari en aquests fitxers?
Les plataformes de registre son una bretlla habitual. Enviar la sortida amb correus electronics d'usuaris reals i IPs a Elastic Cloud o Datadog crea un vincle de tractament. Aquest vincle necessita un ATD, clausules estandard i un instrument de transferència si la plataforma es troba fora de la UE. Cadascun d'aquests requereix temps i revisio legal.
La via mes senzilla: elimineu els detalls de l'usuari abans que els fitxers surtin del vostre sistema. Llegiu la nostra descripcio general del compliment per a les regles completes de l'Article 28.
Per que l'estructura JSON fa la deteccio dificil
Els fitxers de registre JSON varien en estructura. L'escaneig generic de text no es suficient.
Profunditat d'anidament: Els detalls de l'usuari apareixen a qualsevol profunditat. El camp request.headers.x-forwarded-for conte adreces IP. El camp response.body.errors[0].field_value pot contenir entrada de l'usuari. Un escaneig de text pla omet els camps enterrats en rutes anidades.
Esquemes inconsistents: Cada punt final de l'API produeix la seva propia forma de sortida. Els fitxers d'autenticacio no s'assemblen als de pagament. Els fitxers d'actualitzacio de perfil no s'assemblen als dos anteriors. Un enfocament de ruta fixa omet els detalls de l'usuari que apareixen en rutes estranyes en contextos d'error.
Valors tècnics barrejats amb dades personals: Els rastres de pila, els codis d'error i les marques de temps han de romandre intactes. L'eliminacio massiva esborra els camps necessaris i fa el fitxer inutil.
L'enfocament correcte es la deteccio basada en contingut. Trobeu les dades personals pel que son --patro de correu electronic, format d'IP, entitat nomenada-- no per on es troben en l'estructura. Aixo gestiona esquemes variables sense necessitat de configuracio per punt final.
Una substitucio consistent manté els registres utils
El requisit clau es la integritat referencial. Si sarah.johnson@company.com apareix en 47 entrades al llarg d'una cadena de peticions, totes les 47 han de mapar-se al mateix valor.
Regles de mapatge:
sarah.johnson@company.com->user1@example.com(el mateix valor al llarg de tot el fitxer)82.123.45.67->192.0.2.1(IP de documentacio RFC 5737 -- clarament no real)+49 176 1234 5678->+49 XXX XXX XXXX(emmascarada)
Amb aquest mapatge, un desenvolupador pot rastrejar user1@example.com a traves de 47 entrades, reconstruir la cadena de peticions i corregir el problema, sense veure cap detail real de l'usuari.
Aquests camps de metadades romanen sense canvis:
- Marques de temps (no son dades d'usuari)
- Codis i tipus d'error (no son dades d'usuari)
- Rastres de pila (poden contenir IDs tecnics, no dades d'usuari)
- Mètodes HTTP, rutes, codis d'estat (no son dades d'usuari)
- Valors mètrics i xifres de latència (no son dades d'usuari)
El resultat es un fitxer que funciona per a la depuracio. No conte cap detail real de l'usuari. Vegeu el nostre glossari per a la diferència entre anonimitzacio i pseudonimitzacio en virtut del RGPD.
Cas d'us: compartir registres en proves de penetracio
Una empresa SaaS va dur a terme una revisio de seguretat trimestral amb un equip extern de proves de penetracio. L'abast requeria 90 dies de sortida d'API de produccio per mapejar els fluxos d'autenticacio i analitzar els patrons d'error.
Volum brut: 180 MB de fitxers JSON. Recompte de dades personals: 4.200 correus electronics d'usuari unics, 1.800 IPs uniques, 340 numeros de compte parcials en contextos d'error.
Sense eliminar primer els detalls de l'usuari, compartir aquests fitxers hauria requerit:
- Un ATD amb l'empresa de proves de penetracio
- Un instrument de transferència de l'Article 46 del RGPD (l'empresa es trobava fora de la UE)
- Una revisio de l'aviso als interessats
Cadascun d'aquests afegeix treball legal i temps.
Amb l'eliminacio de dades personals aplicada:
- Temps de processament: 25 minuts per a 180 MB
- Sortida: 180 MB de fitxers estructuralment identics, tots els correus electronics i IPs substituits per valors segurs
- Resultat: l'equip de proves de penetracio va rebre el context complet; cap detail real de l'usuari els va arribar
- Resultat del RGPD: no es requereix ATD, la sortida eliminada no es dada d'usuari en virtut del RGPD
Vegeu les nostres preguntes freqüents per a preguntes habituals sobre que compta com a anonim en virtut del RGPD.
Integracio de l'eliminacio de dades personals en CI/CD
Per als equips que comparteixen sortida de manera regular, aquest pas pot executar-se dins dels pipelines existents.
Rotacio de registres:
- El script de rotacio s'executa cada nit
- El pas d'eliminacio s'executa abans d'arxivar o enviar a qualsevol plataforma de registre
- Els fitxers eliminats van als sistemes externs
- Els fitxers originals romanen interns amb plena retencio
Script previ a la comparticio:
- L'enginyer necessita compartir una mostra amb un contractista
- Executa el script:
input=raw-logs/ output=clean-logs/ - Comparteix la carpeta
clean-logs/ - No cal revisio manual de dades personals
Enfocament de sidecar:
- El sidecar elimina el flux de sortida abans de reenviar-lo
- L'eliminacio en temps real manté la utilitat per a l'analisi de registres
- La plataforma no rep cap detail real de l'usuari
Integracio de la politica de retencio
L'Article 5(1)(e) del RGPD requereix la limitacio de conservacio. L'eliminacio de dades personals s'adapta a qualsevol politica de retencio.
- Sortida bruta conservada durant 7 dies (per a la depuracio diaria)
- Versions eliminades conservades durant 90 dies (per a l'analisi de tendències i la revisio d'incidents)
- El pas d'eliminacio s'executa el dia 7
Aixo satisfa la limitacio de conservacio. Elimina el risc de conservar la sortida bruta a llarg termini.