Seguridad, backup y soberanía de datos (servidores UE) en software deportivo

Una federación deportiva custodia datos de miles de personas: nombres, DNIs, fechas de nacimiento de menores, certificados médicos, fotografías. Si esos datos se pierden, se filtran o caen en manos equivocadas, el daño es reputacional, legal y humano.

La seguridad informática suele tratarse como un “tema técnico aburrido” hasta el día en que ocurre el incidente. Esta guía traduce los requisitos reales a criterios que cualquier directivo o secretario puede entender y exigir.

Dónde están los datos (y por qué importa)

Servidores en la UE: la línea roja

Los datos personales de ciudadanos europeos deben almacenarse preferentemente en servidores ubicados físicamente en la Unión Europea. No es una sugerencia — es una línea básica de cumplimiento del RGPD.

Si el proveedor aloja los datos en Estados Unidos, Reino Unido o cualquier país sin adecuación equivalente, necesita justificar:

• Transferencia amparada en cláusulas contractuales tipo (SCC) actualizadas.
• Evaluación de impacto (TIA) documentada.
• Consentimiento explícito del titular en algunos casos.

Mucho más simple: elige un proveedor con servidores en la UE. La pregunta correcta al comercial no es “¿cumplís RGPD?” (siempre dirán que sí) sino “¿dónde están físicamente vuestros servidores?” (la respuesta debe ser concreta: Frankfurt, Ámsterdam, París, Madrid, etc.).

El problema de los “servidores en EEUU con cumplimiento RGPD”

Algunos proveedores americanos afirman cumplir con el RGPD gracias al EU-US Data Privacy Framework. Aunque legalmente es válido, tiene riesgos:

• Puede invalidarse otra vez (ya pasó con Privacy Shield y Safe Harbor).
• Las autoridades de EEUU pueden acceder a los datos bajo ciertas leyes (CLOUD Act, FISA 702).
• Un incidente diplomático puede congelar transferencias.

Para una federación, el riesgo no compensa. La soberanía de datos en la UE ofrece tranquilidad jurídica y operativa.

Cifrado: ¿y cómo lo están protegiendo realmente?

Hay dos capas de cifrado que exigir:

Cifrado en tránsito (TLS/HTTPS)

Cuando los datos viajan del navegador al servidor, deben ir cifrados. Esto es obligatorio y está resuelto con HTTPS, pero hay matices:

• TLS 1.2 o 1.3 como mínimo. TLS 1.0 y 1.1 están desaconsejados.
• Certificados válidos y emitidos por autoridades reconocidas.
• HSTS activado (política que fuerza HTTPS y evita downgrades).
• Cookies seguras y con HttpOnly y SameSite=Strict.

Cómo verificarlo: pega la URL del software en SSL Labs Test. Debe tener puntuación A o A+.

Cifrado en reposo (at-rest)

Los datos almacenados en la base de datos también deben estar cifrados. Hay niveles:

• Disco completo cifrado (LUKS, BitLocker). Bajo umbral.
• Tablespace cifrado (cifra la base de datos completa).
• Cifrado de columnas sensibles (ideal para DNI, fecha nacimiento, certificados médicos).

La respuesta mínima aceptable del proveedor: “los datos en reposo están cifrados con AES-256, y las columnas sensibles se cifran adicionalmente con claves gestionadas por KMS”.

Copias de seguridad (backup) y recuperación

La pregunta técnica que más ignora la mayoría de federaciones es: ¿qué pasa si un lunes por la mañana el sistema no arranca?

Qué exigir

• Frecuencia: al menos una copia diaria completa.
• Retención: el historial de copias debe cubrir al menos 30 días.
• Localización: las copias deben estar en una zona geográfica distinta del servidor principal (pero dentro de la UE).
• RTO (tiempo de recuperación objetivo): ¿en cuánto tiempo el servicio vuelve tras un incidente grave? Menos de 4 horas es lo deseable.
• RPO (punto de recuperación objetivo): ¿cuántos datos máximo puedo perder? Menos de 1 hora es lo deseable.

El test que casi nadie hace

Los backups que no se prueban no existen. Pregunta al proveedor: ¿cuándo fue la última vez que hicisteis un test completo de restauración? Si la respuesta es “nunca” o vaga, mala señal. Lo ideal: test de restauración trimestral documentado.

Copias propias del cliente

Aunque el proveedor haga backups, la federación debería poder descargar una copia propia de sus datos regularmente (al menos mensual). No hacerlo es confiar 100% en el proveedor, y aunque confíes, conviene tener el dato en tu poder.

Control de accesos

Autenticación fuerte

• Contraseñas robustas: política mínima de 10 caracteres, con requisitos.
• Doble factor (2FA): obligatorio para cuentas de administrador. Recomendado para todos.
• SSO opcional: integración con proveedores de identidad para federaciones grandes (Microsoft, Google).
• Bloqueo por intentos fallidos: tras 5 intentos fallidos, bloqueo temporal.

Autorización granular

Como vimos en la guía de gestión multi-club, cada rol debe ver solo lo suyo. No es solo una cuestión de UX — es una medida de seguridad crítica. Si un club se ve comprometido, el daño se limita a sus datos, no a los de toda la federación.

Logs de auditoría

Cada acceso y cada modificación importante debe dejar rastro. Un buen log registra:

• Usuario que realiza la acción.
• Timestamp exacto.
• IP y user-agent.
• Acción realizada (ver, crear, modificar, borrar).
• Entidad afectada (qué persona, qué licencia, qué pago).

Estos logs deben conservarse al menos 1 año, ser inmutables (no borrables por el propio administrador) y estar disponibles para auditoría.

Protección frente a amenazas comunes

Ataques web habituales

El software debe protegerse de:

• Inyección SQL: uso de consultas parametrizadas siempre.
• XSS (Cross-Site Scripting): sanitización y escape de todo input.
• CSRF: tokens anti-forgery en cada formulario.
• Clickjacking: cabeceras X-Frame-Options y Content-Security-Policy.
• Enumeración de usuarios: mensajes de error genéricos.

Esto es responsabilidad del proveedor, pero una auditoría externa periódica (pentest) es buena señal.

Ransomware

El ransomware es la mayor amenaza actual para organizaciones. La defensa se apoya en:

• Backups fuera de línea o inmutables.
• Segregación de redes del entorno de producción.
• Actualizaciones puntuales de sistema operativo y dependencias.
• EDR/antivirus en servidores.
• Monitorización de tráfico anómalo.

Pregunta al proveedor: “¿qué política tenéis frente a ransomware?”. La respuesta debería incluir al menos backups inmutables y monitorización 24/7.

Ingeniería social

La puerta de entrada más común a los datos de una federación no es técnica — es humana. Un correo falso simulando ser el banco o la federación nacional puede engañar al secretario y obtener credenciales. Medidas:

• Formación periódica de todos los administradores.
• Política interna de nunca compartir credenciales por email o Whatsapp.
• Procedimiento de verificación para solicitudes económicas por email.

Plan de continuidad de negocio

Un plan de continuidad documenta qué hacer cuando todo sale mal:

• Quién es responsable de tomar decisiones durante un incidente.
• Qué alternativas temporales usar (proceso en papel de emergencia, por ejemplo).
• Cómo comunicar a federados y clubes durante una caída.
• Plazos esperados de recuperación.
• Quién notifica a la AEPD en caso de brecha.

Sin plan escrito, el incidente se gestiona improvisando, y la improvisación suele implicar errores.

Checklist de seguridad para evaluar proveedores

Antes de firmar con un proveedor, pide que respondan por escrito:

• ¿Dónde están físicamente los servidores?
• ¿Tenéis certificación ISO 27001, SOC 2 o similar?
• ¿Cuál es vuestro protocolo de notificación de brechas?
• ¿Con qué frecuencia hacéis test de restauración de backup?
• ¿Soportáis 2FA? ¿SSO?
• ¿Qué datos se cifran en reposo? ¿Con qué algoritmo?
• ¿Cuándo fue el último pentest externo? ¿Podéis compartir un resumen?
• ¿Qué SLA ofrecéis de disponibilidad (uptime)?
• ¿Cuál es vuestro plan de continuidad documentado?
• ¿Cómo se gestionan los accesos de vuestro personal a mis datos?

Un proveedor serio responde con claridad. Uno que evade o contesta con vaguedad te está diciendo más de lo que crees.

La seguridad no es un estado, es un proceso

La seguridad perfecta no existe. Lo que existe es la reducción consistente de riesgo: mejor cifrado, mejores backups, mejor formación, auditorías periódicas. Una federación que cuestiona, exige y mide sus proveedores está mejor protegida que una que firma y se olvida.

El día que ocurra el incidente — y tarde o temprano ocurrirá algo — la diferencia entre una crisis gestionada y una catástrofe se reduce a las preguntas incómodas que hiciste antes de firmar.