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
  • Esborrat lògic
  • Anonimització
  • Esborrat lògic o anonimització
  • El que en diu la llei
  • Purga i còpies de seguretat
• 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 camp de l’inventari té un termini de conservació: uns diuen com a màxim quant de temps el pots guardar, i altres, com la factura, com a mínim quant l’has de guardar. Complir-ho és una funcionalitat, no una intenció, i demana distingir tres coses que sovint es confonen: marcar una fila com a no vigent, treure’n la persona i esborrar-la de veritat.

Esborrat lògic

L’esborrat lògic (soft delete) no és un esborrat. Marcar actiu = false deixa totes les dades on eren, i per tant no respon al dret de supressió. Tot i això el fa servir gairebé tothom, perquè resol un problema diferent: un negoci gairebé mai vol perdre el que ha passat.

Pensa en la botiga. Retires un producte del catàleg amb un DELETE. L’endemà les comandes de l’any passat apunten a un producte que ja no existeix, l’informe de vendes del trimestre anterior dona un resultat diferent del que vas imprimir, i ningú pot dir qui el va retirar ni quan. La informació que has destruït no era del producte: era de les vendes.

D’aquí surten els motius per marcar en lloc d’esborrar:

• Les dades històriques han de continuar quadrant. Un informe d’un període tancat ha de donar sempre el mateix, encara que el catàleg d’avui hagi canviat.
• Les referències no es trenquen. La línia de comanda pot seguir apuntant al producte, i el tiquet antic es pot tornar a imprimir.
• Es pot desfer. Una baixa per error es recupera amb un UPDATE; un DELETE es recupera restaurant una còpia de seguretat, amb tot el que això arrossega.
• Queda rastre de qui i quan. L’acte de donar de baixa és, ell mateix, informació de negoci.

El significat exacte de la marca és “això ja no és vigent”, no “això no ha existit mai”. Per això serveix per a catàlegs, tarifes, usuaris interns o categories, i no serveix, tot sol, quan un client exerceix el dret de supressió.

A l’hora d’implementar-lo:

• Marca amb data, no amb booleà. esborrat_el TIMESTAMP NULL diu el mateix que actiu = false i a més quan va passar. Amb esborrat_per tens també qui.
• Filtra en un sol lloc. Una vista productes_vigents, o l’àmbit per defecte del repositori. Si cada consulta ha de recordar WHERE esborrat_el IS NULL, tard o d’hora una se n’oblidarà i ressuscitarà una fila donada de baixa.
• Revisa els índexs únics. Amb files donades de baixa a la mateixa taula, un codi de producte únic impedeix reutilitzar el codi d’un producte retirat. La solució és un índex únic parcial: CREATE UNIQUE INDEX ... ON productes (codi) WHERE esborrat_el IS NULL.
• Decideix què veu cada informe. Els llistats operatius volen només el vigent; els informes històrics volen també el que ja no ho és. És una decisió per consulta, no global.
• Combina’l amb la purga. L’esborrat lògic conserva files; la retenció de l’inventari continua manant. El que ha caducat s’esborra de veritat, encara que estigués marcat.

Quan el que necessites no és saber si una fila és vigent sinó com ha anat canviant, l’esborrat lògic es queda curt i el que toca és guardar versions: una taula d’històric amb el període de validesa de cada versió, o les taules temporals que alguns SGBD ja ofereixen.

Anonimització

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.

Sobre fins a quin punt una fila així és realment anònima, vegeu el límit de l’anonimització.

Esborrat lògic o anonimització

Les dues tècniques són la mateixa jugada: conservar la fila en lloc d’esborrar-la, i treure’n només el que ja no toca. El que canvia és què treuen i, per tant, per a què serveix cadascuna.

D’aquí surt la regla per triar. Si el que ha de desaparèixer és la vigència de la fila, marca-la. Si el que ha de desaparèixer és la persona, anonimitza. Marcar el client donat de baixa i deixar-hi el nom i el correu no compleix res: la dada personal continua a la taula, i l’única cosa que has fet és amagar-la de la pantalla.

La baixa d’un client de la botiga necessita les dues alhora, i per motius diferents:

• L’anonimització de la fila de clients respon al dret de supressió: el nom, el correu i l’adreça desapareixen, i les comandes continuen quadrant perquè ja tenien copiades les dades de facturació.
• L’esborrat lògic de la mateixa fila conserva l’identificador, i amb ell les claus foranes de les comandes, i deixa constància que aquell compte va existir i quan es va donar de baixa.

Per això l’UPDATE d’abans buida els camps personals i posa esborrat_el en una sola sentència.

El que en diu la llei

Cap de les dues tècniques és una invenció dels programadors: totes dues tenen nom i article.

L’esborrat lògic és obligatori, i es diu bloqueig. L’article 32 de la LOPDGDD diu que el responsable “estarà obligat a bloquejar les dades quan procedeixi a la seva rectificació o supressió”. El bloqueig consisteix a identificar i reservar les dades, amb mesures tècniques i organitzatives, per impedir-ne el tractament, “inclosa la seva visualització”, excepte per posar-les a disposició de jutges, fiscalia o administracions competents mentre no prescriguin les responsabilitats. Passat aquest termini, s’han de destruir.

Això apuja el llistó del WHERE esborrat_el IS NULL. Una fila bloquejada no és una fila que l’aplicació filtra i que qualsevol pot tornar a consultar: ha de quedar fora de l’abast de l’ús ordinari, amb accés restringit i amb una data de destrucció. L’apartat 4 del mateix article dona una sortida quan el sistema no permet bloquejar o adaptar-lo costaria un esforç desproporcionat: fer-ne una còpia segura amb evidència digital de l’autenticitat, de la data del bloqueig i de la no manipulació.

Per això la comanda es queda. El dret de supressió no és absolut: l’article 17.3 l’exceptua, entre altres casos, quan el tractament cal per complir una obligació legal (lletra b) o per formular o defensar reclamacions (lletra e). I els terminis existeixen: l’article 30.1 del Codi de comerç obliga a conservar llibres i justificants sis anys des de l’últim assentament, i l’article 66 de la Llei general tributària fixa en quatre anys la prescripció tributària. La columna “anys” de l’inventari té números concrets.

L’anonimització funciona perquè treu la dada del reglament. El considerant 26 diu que el RGPD no s’aplica a la informació anònima ni a les dades convertides en anònimes de manera que l’interessat ja no sigui identificable, i que la identificabilitat es jutja pels mitjans “raonablement probables” d’utilitzar, tenint en compte cost, temps i tecnologia. Si la fila ja no assenyala ningú, no hi ha res a suprimir.

El dictamen 05/2014 del Grup de l’Article 29 hi posa dues condicions que decideixen si el que has fet val: anonimitzar és irreversible i, si no ho és, el que tens és pseudonimització, que continua sent dada personal; i anonimitzar és, en si mateix, un tractament, o sigui que necessita la seva base legal i s’ha de registrar com qualsevol altre.

Purga i còpies de seguretat

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ó.
• Fer esborrat lògic i oblidar el filtre en alguna consulta, o deixar un índex únic que impedeix reutilitzar el codi d’una fila retirada.
• 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
• Opinion 05/2014 on Anonymisation Techniques (WP29)
• 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)