Seguretat, backup i sobirania de dades (servidors UE) en software esportiu

Una federació esportiva custodia dades de milers de persones: noms, DNIs, dates de naixement de menors, certificats mèdics, fotografies. Si aquestes dades es perden, es filtren o cauen en mans equivocades, el dany és reputacional, legal i humà.

La seguretat informàtica sol tractar-se com un “tema tècnic avorrit” fins al dia que ocorre l’incident. Aquesta guia tradueix els requisits reals a criteris que qualsevol directiu o secretari pot entendre i exigir.

On són les dades (i per què importa)

Servidors a la UE: la línia vermella

Les dades personals de ciutadans europeus s’han d’emmagatzemar preferentment en servidors ubicats físicament a la Unió Europea. No és un suggeriment — és una línia bàsica de compliment del RGPD.

Si el proveïdor allotja les dades als Estats Units, Regne Unit o qualsevol país sense adequació equivalent, necessita justificar:

• Transferència emparada en clàusules contractuals tipus (SCC) actualitzades.
• Avaluació d’impacte (TIA) documentada.
• Consentiment explícit del titular en alguns casos.

Molt més simple: escull un proveïdor amb servidors a la UE. La pregunta correcta al comercial no és “complieu RGPD?” (sempre diran que sí) sinó “on són físicament els vostres servidors?” (la resposta ha de ser concreta: Frankfurt, Amsterdam, París, Madrid, etc.).

El problema dels “servidors als EUA amb compliment RGPD”

Alguns proveïdors americans afirmen complir amb el RGPD gràcies al EU-US Data Privacy Framework. Tot i que legalment és vàlid, té riscos:

• Pot invalidar-se una altra vegada (ja va passar amb Privacy Shield i Safe Harbor).
• Les autoritats dels EUA poden accedir a les dades sota certes lleis (CLOUD Act, FISA 702).
• Un incident diplomàtic pot congelar transferències.

Per a una federació, el risc no compensa. La sobirania de dades a la UE ofereix tranquil·litat jurídica i operativa.

Xifratge: com les protegeixen realment?

Hi ha dues capes de xifratge per exigir:

Xifratge en trànsit (TLS/HTTPS)

Quan les dades viatgen del navegador al servidor, han d’anar xifrades. Això és obligatori i està resolt amb HTTPS, però hi ha matisos:

• TLS 1.2 o 1.3 com a mínim. TLS 1.0 i 1.1 estan desaconsellats.
• Certificats vàlids i emesos per autoritats reconegudes.
• HSTS activat (política que força HTTPS i evita downgrades).
• Cookies segures i amb HttpOnly i SameSite=Strict.

Com verificar-ho: enganxa l’URL del software a SSL Labs Test. Ha de tenir puntuació A o A+.

Xifratge en repòs (at-rest)

Les dades emmagatzemades a la base de dades també han d’estar xifrades. Hi ha nivells:

• Disc complet xifrat (LUKS, BitLocker). Llindar baix.
• Tablespace xifrat (xifra la base de dades sencera).
• Xifratge de columnes sensibles (ideal per a DNI, data naixement, certificats mèdics).

La resposta mínima acceptable del proveïdor: “les dades en repòs estan xifrades amb AES-256, i les columnes sensibles es xifren addicionalment amb claus gestionades per KMS”.

Còpies de seguretat (backup) i recuperació

La pregunta tècnica que més ignora la majoria de federacions és: què passa si un dilluns al matí el sistema no arrenca?

Què exigir

• Freqüència: almenys una còpia diària completa.
• Retenció: l’historial de còpies ha de cobrir almenys 30 dies.
• Localització: les còpies han d’estar en una zona geogràfica diferent del servidor principal (però dins de la UE).
• RTO (temps de recuperació objectiu): en quant de temps el servei torna després d’un incident greu? Menys de 4 hores és el desitjable.
• RPO (punt de recuperació objectiu): quantes dades màxim puc perdre? Menys d’1 hora és el desitjable.

La prova que gairebé ningú fa

Els backups que no es proven no existeixen. Pregunta al proveïdor: quan va ser l’última vegada que vau fer una prova completa de restauració? Si la resposta és “mai” o vaga, mal senyal. L’ideal: prova de restauració trimestral documentada.

Còpies pròpies del client

Tot i que el proveïdor faci backups, la federació hauria de poder descarregar una còpia pròpia de les seves dades regularment (almenys mensual). No fer-ho és confiar 100% en el proveïdor, i encara que confiïs, convé tenir la dada al teu poder.

Control d’accessos

Autenticació forta

• Contrasenyes robustes: política mínima de 10 caràcters, amb requisits.
• Doble factor (2FA): obligatori per a comptes d’administrador. Recomanat per a tothom.
• SSO opcional: integració amb proveïdors d’identitat per a federacions grans (Microsoft, Google).
• Bloqueig per intents fallits: després de 5 intents fallits, bloqueig temporal.

Autorització granular

Com hem vist a la guia de gestió multi-club, cada rol ha de veure només el seu. No és només una qüestió d’UX — és una mesura de seguretat crítica. Si un club es veu compromès, el dany es limita a les seves dades, no a les de tota la federació.

Logs d’auditoria

Cada accés i cada modificació important ha de deixar rastre. Un bon log registra:

• Usuari que realitza l’acció.
• Timestamp exacte.
• IP i user-agent.
• Acció realitzada (veure, crear, modificar, esborrar).
• Entitat afectada (quina persona, quina llicència, quin pagament).

Aquests logs s’han de conservar almenys 1 any, ser immutables (no esborrables pel mateix administrador) i estar disponibles per a auditoria.

Protecció davant amenaces comunes

Atacs web habituals

El software s’ha de protegir de:

• Injecció SQL: ús de consultes parametritzades sempre.
• XSS (Cross-Site Scripting): sanitització i escapament de tot input.
• CSRF: tokens anti-forgery a cada formulari.
• Clickjacking: capçaleres X-Frame-Options i Content-Security-Policy.
• Enumeració d’usuaris: missatges d’error genèrics.

Això és responsabilitat del proveïdor, però una auditoria externa periòdica (pentest) és un bon senyal.

Ransomware

El ransomware és la major amenaça actual per a organitzacions. La defensa es recolza en:

• Backups fora de línia o immutables.
• Segregació de xarxes de l’entorn de producció.
• Actualitzacions puntuals de sistema operatiu i dependències.
• EDR/antivirus en servidors.
• Monitoratge de trànsit anòmal.

Pregunta al proveïdor: “quina política teniu davant ransomware?”. La resposta hauria d’incloure almenys backups immutables i monitoratge 24/7.

Enginyeria social

La porta d’entrada més comuna a les dades d’una federació no és tècnica — és humana. Un correu fals simulant ser el banc o la federació nacional pot enganyar el secretari i obtenir credencials. Mesures:

• Formació periòdica de tots els administradors.
• Política interna de mai compartir credencials per email o Whatsapp.
• Procediment de verificació per a sol·licituds econòmiques per email.

Pla de continuïtat de negoci

Un pla de continuïtat documenta què fer quan tot surt malament:

• Qui és responsable de prendre decisions durant un incident.
• Quines alternatives temporals fer servir (procés en paper d’emergència, per exemple).
• Com comunicar a federats i clubs durant una caiguda.
• Terminis esperats de recuperació.
• Qui notifica l’autoritat en cas de bretxa.

Sense pla escrit, l’incident es gestiona improvisant, i la improvisació sol implicar errors.

Checklist de seguretat per avaluar proveïdors

Abans de signar amb un proveïdor, demana que responguin per escrit:

• On són físicament els servidors?
• Teniu certificació ISO 27001, SOC 2 o similar?
• Quin és el vostre protocol de notificació de bretxes?
• Amb quina freqüència feu prova de restauració de backup?
• Suporteu 2FA? SSO?
• Quines dades es xifren en repòs? Amb quin algoritme?
• Quan va ser l’últim pentest extern? Podeu compartir-ne un resum?
• Quin SLA oferiu de disponibilitat (uptime)?
• Quin és el vostre pla de continuïtat documentat?
• Com es gestionen els accessos del vostre personal a les meves dades?

Un proveïdor seriós respon amb claredat. Un que evadeix o contesta amb vaguetat et diu més del que creus.

La seguretat no és un estat, és un procés

La seguretat perfecta no existeix. El que existeix és la reducció consistent de risc: millor xifratge, millors backups, millor formació, auditories periòdiques. Una federació que qüestiona, exigeix i mesura els seus proveïdors està més protegida que una que signa i s’oblida.

El dia que ocorri l’incident — i tard o d’hora ocorrerà alguna cosa — la diferència entre una crisi gestionada i una catàstrofe es redueix a les preguntes incòmodes que vas fer abans de signar.