Dades personals

• Què és una dada personal
  • Categories especials
• Inventari de dades de la botiga
• Bases legals i minimització
• Obligacions que es tradueixen en codi
• A quin nivell protegir
• Tècniques, camp a camp
  • La tècnica depèn de l’ús, no del camp
  • Els camps de la botiga
  • El cas del DNI
  • Les claus
  • El límit de l’anonimització
• Retenció i esborrat
• Què no es registra mai
• Errors típics
• Referències

Persistir dades d’una persona no és el mateix que persistir el catàleg de productes. El catàleg el pots esborrar i tornar a carregar; les dades d’un client les tens perquè ell te les ha confiat, i la llei et diu què en pots fer.

Aquesta pàgina fa servir un exemple únic, una botiga en línia, per respondre les preguntes que apareixen quan la construeixes: quins camps són dades personals, quins xifres i com, quant de temps els guardes i a quina capa del sistema poses cada protecció.

Què és una dada personal

Comencem pel formulari de registre de la botiga: nom, correu electrònic, contrasenya, adreça d’enviament i telèfon. Tots aquests camps són dades personals. Fins aquí, cap sorpresa.

La sorpresa ve després. El Reglament General de Protecció de Dades (RGPD, GDPR en anglès) defineix una dada personal com tota informació sobre una persona física identificada o identificable. La segona paraula és la important: no cal que el camp digui el nom de ningú, n’hi ha prou que permeti arribar a una persona concreta, sol o combinat amb altres dades que tens.

Per tant també són dades personals:

• L’adreça IP que queda al log del servidor web.
• L’identificador de sessió o de galeta que fa seguiment d’un visitant.
• L’historial de comandes, encara que la taula només guardi un client_id.
• Una fotografia o una gravació de veu.

La prova pràctica és senzilla: si amb aquesta dada, i amb el que ja tens a la base de dades, pots assenyalar una persona, és una dada personal.

Un cas que sovint es passa per alt: les dades pseudonimitzades continuen sent dades personals. Substituir el nom per un identificador no treu la informació de l’àmbit del RGPD, perquè algú manté la taula que relaciona l’identificador amb la persona. Només les dades anonimitzades de veritat, aquelles on ja no hi ha manera de desfer el camí, en queden fora.

Categories especials

El RGPD tracta a part unes quantes categories: salut, origen ètnic, conviccions religioses o polítiques, afiliació sindical, dades biomètriques i vida sexual. Guardar-les demana condicions addicionals.

La regla per a una botiga normal és simple: no n’has de tenir cap. Ara bé, cal fixar-s’hi, perquè poden aparèixer sense que les demanis. Si la botiga ven productes de farmàcia o ortopèdia, la línia de comanda revela informació de salut, i aquella taula deixa de ser una taula de vendes qualsevol.

Inventari de dades de la botiga

Abans de decidir res sobre xifrat, cal saber què tens. Aquesta és la taula que hauria d’existir per a qualsevol aplicació que tracti dades de persones:

Aquesta taula és, en petit, el registre d’activitats de tractament que el RGPD demana. Té un efecte secundari molt útil durant el disseny: si no saps omplir una fila, probablement no hauries de demanar aquell camp.

L’última columna avança decisions que encara no hem justificat. Cadascuna té el seu perquè, i el recorregut de la pàgina va precisament d’aquí: primer per què cal cada camp, després a quin nivell es protegeix i finalment amb quina tècnica es guarda.

Bases legals i minimització

No pots tractar dades personals perquè sí. Necessites un motiu dels que la llei reconeix, i per a una botiga n’hi ha prou amb quatre:

• Execució d’un contracte: sense adreça no hi ha lliurament. És la base de gairebé tot el que demana el formulari de comanda.
• Obligació legal: la factura s’ha de conservar encara que el client vulgui marxar.
• Consentiment: el butlletí comercial. Ha de ser una acció separada i voluntària, i s’ha de poder retirar amb la mateixa facilitat amb què es va donar.
• Interès legítim: registrar les IP per detectar frau. Cal poder argumentar que el benefici no aixafa els drets de la persona.

La base legal no és una etiqueta burocràtica: determina quant de temps pots guardar el camp i què hi pots fer. El mateix correu electrònic, guardat per enviar l’avís de lliurament, no et serveix per enviar ofertes.

La minimització és la regla de disseny que en surt: demana només els camps que faràs servir. No demanis el DNI per enviar un paquet ni la data de naixement per vendre samarretes. Cada camp de més és una fila més a la taula anterior, un camp més a protegir i un motiu més perquè algú abandoni el formulari.

Per al detall del consentiment i de la baixa en campanyes de correu, vegeu captar leads sense infringir la llei.

Obligacions que es tradueixen en codi

Els drets que el RGPD dona a les persones no es compleixen amb un text al peu de pàgina. Cadascun és una funcionalitat que algú ha d’escriure, i si no és al backlog, no existeix:

• Accés i portabilitat: un procés que exporta tot el que tens d’una persona en un format llegible per una màquina. Si l’has de construir a mà cada vegada que algú ho demana, no arribaràs a temps.
• Rectificació: els camps han de ser editables, inclosos els que l’usuari no veu al seu perfil.
• Supressió: la part difícil, i té secció pròpia més avall.
• Oposició i baixa: un enllaç d’un sol clic a cada correu comercial, que funcioni.

A més dels drets, hi ha tres obligacions que afecten directament l’arquitectura:

• Notificació de bretxes: si hi ha una filtració, tens 72 hores per notificar-la a l’autoritat de control. Per poder-ho fer necessites saber quines dades hi havia i qui hi va accedir, i això depèn de tenir l’inventari fet i els accessos registrats. Vegeu Logging i Monitoring.
• Encarregats del tractament: l’allotjament, el servei de correu i la passarel·la de pagament tracten dades dels teus clients per encàrrec teu. Cal contracte amb cadascun i saber on processen les dades.
• Transferències fora de l’Espai Econòmic Europeu: triar la regió del proveïdor de núvol és un requisit contractual, no una preferència tècnica. El context legal el teniu a on són les dades.

L’avaluació d’impacte (DPIA) és obligatòria quan el tractament és arriscat: perfilat sistemàtic, categories especials o volums grans. Una botiga petita normalment no hi arriba, però un recomanador que classifica clients per comportament, sí.

A quin nivell protegir

“Xifrem la base de dades” sona a resposta, però no ho és fins que dius quina capa xifres i de qui et protegeix. El punt de partida són els tres estats de les dades: en repòs, en trànsit i en ús.

La taula següent recorre el sistema de dalt a baix. La primera columna diu quin estat protegeix cada mesura, i la segona a quin nivell actua:

Llegida per files, la taula diu una cosa que sorprèn: l’estat “en ús” no es defensa amb criptografia, sinó amb control d’accés. Mentre l’aplicació treballa, les dades són en pla, i l’única cosa que hi ha entre elles i un atacant són les comprovacions que has escrit tu.

La fila que més sorpreses provoca és la del xifrat del disc. Protegeix contra un escenari molt concret, que algú s’endugui el disc o el fitxer de la base de dades. Davant d’una injecció SQL o d’unes credencials d’aplicació filtrades no fa absolutament res, perquè en aquests casos qui pregunta és l’aplicació, i l’aplicació està autoritzada a desxifrar.

D’aquí en surten dues conclusions pràctiques:

• La decisió es pren camp a camp, no servidor a servidor. Activar el xifrat del proveïdor de núvol està bé i costa poc, però no substitueix decidir què fas amb l’adreça o amb el document d’identitat.
• Comença pel que ja tens. El framework et dona escapament, consultes preparades i gestió de sessions (arquitectura dels frameworks), i el servei de base de dades gestionada et dona xifrat en repòs i còpies. Afegir xifrat a l’aplicació és una capa més, amb un cost que has de justificar.

I abans de qualsevol capa hi ha la mesura més barata de totes: la dada que no tens no es pot filtrar.

Tècniques, camp a camp

Ja sabem a quin nivell posem cada protecció. Falta l’última decisió: amb quina forma es guarda cada camp.

Contra la intuïció, el text pla és un valor per defecte raonable per a la majoria de camps. Ara bé, ho és només si es compleixen totes aquestes condicions:

• Les capes de sota són al seu lloc: control d’accés a l’aplicació, permisos al SGBD, xifrat en repòs de la plataforma i còpies de seguretat xifrades. És el que diu l’OWASP quan recorda que la capa on xifres depèn del model d’amenaces. Xifrar una columna que ningú no ha sabut protegir amb control d’accés no resol res, només desplaça el problema cap a la gestió de la clau.
• El risc del camp és el corrent. El RGPD no obliga a xifrar-ho tot: l’article 32 demana mesures “apropiades al risc” i cita el xifrat i la pseudonimització com a exemples, no com a requisit. Com més mal pugui fer la filtració d’aquell camp, menys val aquest valor per defecte.
• No és un dels camps que mai van en pla. La contrasenya es resumeix, la targeta no es guarda, i les categories especials demanen una justificació molt més exigent.
• Pots assumir el que costa una bretxa amb aquell camp llegible. L’article 34.3.a diu que si les dades filtrades eren inintel·ligibles per a qui no hi està autoritzat, “com ara mitjançant el xifrat”, no cal comunicar la bretxa a cada afectat. Xifrar una columna, doncs, no només protegeix la dada: pot estalviar-te haver d’escriure a tots els teus clients per dir-los que l’has perdut. L’exempció, però, val només per a l’avís als afectats: la notificació a l’autoritat de control dins de les 72 hores continua sent obligatòria.

Quan alguna d’aquestes condicions falla, aquell camp demana una de les tècniques següents.

La columna que decideix la majoria de casos és la de la cerca. El cost del xifrat a l’aplicació no és el rendiment: una columna xifrada no es pot cercar, ordenar ni indexar. Amb això deixa de ser una decisió de seguretat i passa a ser una decisió de model de dades.

La tècnica depèn de l’ús, no del camp

Hi ha camps que apareixen a més d’una fila, i no és cap descuit. La mateixa dada admet tractaments diferents segons què hi facis, i això es concreta de tres maneres:

• Tècnica diferent segons l’operació. El correu va en pla si identifica el compte, i amb resum si només comproves que és en una llista. El DNI i el telèfon, igual.
• Camp partit per trossos. La població i el codi postal et calen per als ports i les estadístiques, i poden anar en pla. El carrer i el número, que són els que assenyalen algú, són el candidat a xifrar.
• Guardar la resposta, no la dada. Si el que necessites és saber si el client té divuit anys, guarda que els té, no la data de naixement. La dada que no deses no s’ha de protegir, ni esborrar, ni justificar.

Els camps de la botiga

• Correu electrònic: en pla i indexat. És la temptació de xifrar que surt més cara, perquè si identifica el compte l’has de poder cercar. El resum amb pebre només hi és una alternativa quan l’única operació que en faràs és comprovar si un valor hi és.
• Adreça: el cas contrari. La mostres i la imprimeixes, però gairebé mai la cerques, i per això és la candidata típica al xifrat a l’aplicació, partida com acabem de dir. El que ho decideix no és l’algorisme sinó on desa la clau, i d’això en parlem a les claus.
• Contrasenya: mai xifrada, sempre resumida amb un KDF. Ja està explicada a registre.
• Targeta: no es guarda. En lloc del número, la passarel·la et dona un testimoni que no en deriva matemàticament i que només val per cobrar al teu propi compte, de manera que no hi ha ni clau que perdre ni número que recuperar. Vegeu pagaments en línia.

El cas del DNI

És el camp que més sovint es demana sense pensar i es protegeix malament, i mereix un apartat propi.

La primera pregunta no és com el guardes sinó si el necessites. Per vendre a un particular pots emetre una factura simplificada, el tiquet de tota la vida, que no ha d’identificar el destinatari. El NIF només et cal quan el client demana factura completa, normalment perquè se la vol deduir, o quan vens a empreses. El camp, doncs, no hauria de ser al formulari de registre: apareix en el moment de facturar, i només quan toca.

Si l’acabes guardant, hi ha una trampa. Un hash no protegeix un DNI, perquè el conjunt de valors possibles és ridículament petit: cent milions de combinacions de vuit xifres, i la lletra no s’escull, es calcula a partir del número. Qui tingui la columna de resums els pot generar tots i comparar-los en qüestió de minuts. El mateix passa amb els telèfons. L’única versió que aguanta és el resum amb un pebre secret que visqui fora de la base de dades, i deixa de servir l’endemà que el pebre es filtri.

D’aquí que el DNI aparegui a dues files de la taula: amb pebre si l’única cosa que en fas és comparar-lo, i xifrat a l’aplicació si l’has de poder tornar a llegir per posar-lo en una factura.

I quan el mostris, no el mostris sencer. Per a les publicacions de les administracions, l’AEPD fixa que se n’ensenyin només quatre xifres centrals (***4567**). La teva botiga no hi està obligada, però és un bon criteri per als llistats, els correus i les pantalles d’atenció al client.

Les claus

Si xifres una columna, la feina de veritat no és xifrar sinó gestionar la clau, i això ja està explicat al lloc que li correspon: gestió de claus cobreix com generar-la, l’esquema de clau de dades protegida per una clau mestra i quan s’ha de rotar, i secrets management cobreix on viu en una aplicació desplegada, que no és ni el codi ni el repositori. El codi per xifrar és a criptografia a Java.

La regla que ho resumeix tot: la clau no pot viure al costat de les dades que protegeix.

Només hi afegirem una conseqüència pràctica per a una columna xifrada: desa al costat de cada valor l’identificador de la clau amb què el vas xifrar. Rotar una clau vol dir rexifrar les dades, i amb milions de files això no es pot fer d’una tirada. Si cada fila diu amb quina clau està xifrada, pots anar convertint-les a poc a poc mentre l’aplicació continua funcionant amb les dues.

El límit de l’anonimització

L’anonimització de veritat és més difícil del que sembla. En una botiga amb pocs clients, el codi postal, la franja d’edat i tres compres ja assenyalen una persona. Si el resultat encara permet reidentificar algú, el que has fet és pseudonimitzar, i el RGPD continua aplicant-se.

Retenció i esborrat

Cada fila de l’inventari té una data de caducitat. Complir-la és una funcionalitat, no una intenció.

L’esborrat lògic no és un esborrat. Marcar actiu = false deixa totes les dades on eren. És útil per a la integritat de l’aplicació, però no respon al dret de supressió.

Una comanda no es pot esborrar sense més. La normativa comptable obliga a conservar les factures durant anys, i aquesta obligació legal pesa més que la petició de supressió. La sortida habitual és separar les dues coses:

-- El client desapareix, la factura es manté amb les dades que la llei exigeix
UPDATE clients
   SET nom = 'Client donat de baixa',
       email = NULL,
       telefon = NULL,
       adreca = NULL,
       esborrat_el = CURRENT_TIMESTAMP
 WHERE id = ?;

Perquè això funcioni, la comanda ha de tenir copiades les dades de facturació que necessita, en lloc de llegir-les sempre del client. És una desnormalització deliberada, una excepció conscient a la regla de no duplicar dades (bones pràctiques): la factura ha de poder explicar-se sola anys després, quan el client ja no hi sigui.

La purga s’ha de programar. Un procés periòdic esborra el que ha passat de data: sessions caducades, cistelles abandonades, logs vells, comptes inactius. Com tota funcionalitat, necessita proves; un esborrat que falla en silenci és pitjor que no tenir-lo, perquè creus que el tens.

Les còpies de seguretat són el cas incòmode. No pots reescriure una còpia per treure’n una persona. La resposta acceptada és documentar-ho: les còpies tenen una retenció limitada i pròpia, i si mai se’n restaura una, l’esborrat es torna a aplicar. Convé que això estigui escrit abans que algú ho pregunti.

Què no es registra mai

Els logs són el lloc on les dades personals s’escapen sense que ningú ho hagi decidit. Van a parar a un servei extern, els llegeix mig equip i sovint es conserven més temps que les dades originals.

No hi han d’aparèixer mai: números de targeta, contrasenyes, testimonis de sessió, claus d’API, adreces completes ni documents d’identitat. Al cos d’un error tampoc: el detall va al servidor i l’usuari rep un identificador de correlació, tal com explica gestió segura d’errors.

El que sí que has de registrar és qui ha accedit a dades sensibles i quan. És el que et permetrà respondre després d’un incident.

Sobre el mecanisme de registre en Java, vegeu logging.

Errors típics

Una llista curta per repassar abans de posar la botiga en producció:

• Guardar el CVV de la targeta. No es pot guardar mai, en cap circumstància.
• Xifrar la columna i deixar la clau a la mateixa base de dades, o al repositori.
• Tenir una taula clients_backup_2023 que ningú recorda i que no apareix a l’inventari.
• Exportar un CSV de clients per a una prova i deixar-lo al repositori o al disc de portàtil.
• Copiar la base de dades de producció a l’entorn de desenvolupament sense anonimitzar-la.
• Confondre l’esborrat lògic amb el dret de supressió.
• Demanar camps que no faràs servir mai.

Referències

• Reglament (UE) 2016/679, RGPD
• GDPR, text consolidat i cercable per articles
• Llei orgànica 3/2018, LOPDGDD
• Agència Espanyola de Protecció de Dades
• Guia per a la gestió i notificació de bretxes de seguretat (AEPD)
• Orientacions de l’AEPD sobre la publicació del DNI (DA7 LOPDGDD)
• Autoritat Catalana de Protecció de Dades
• Comitè Europeu de Protecció de Dades
• Data pseudonymisation: advanced techniques and use cases (ENISA)
• Cryptographic Storage Cheat Sheet (OWASP)
• User Privacy Protection Cheat Sheet (OWASP)
• Logging Cheat Sheet (OWASP)