ScoutAtlas
Seguridad

Cómo protegemos los datos de tu club.
Sin la pelusa de marketing.

La inteligencia futbolística es sensible. Una shortlist filtrada cuesta una operación. Un parte médico filtrado cuesta una carrera. Abajo está el modelo de seguridad completo de Scout Atlas — qué hacemos, cómo lo hacemos y qué elegimos explícitamente no hacer.

Los pilares

Seis compromisos. Auditables.

Pilar 01

Cifrado por defecto

TLS 1.3 en tránsito. AES-256-GCM en reposo. Los mensajes del Deal Room están cifrados extremo a extremo con claves por sala que no podemos leer.

Pilar 02

Identidad verificada

Magic-link con TOTP MFA opcional. Correos corporativos vinculados al dominio. La asignación de roles requiere aprobación de admin, no una casilla auto-marcable.

Pilar 03

Aislamiento por fila

Postgres RLS impone los límites de club a nivel de base de datos. Un bug en la app no puede exponer los datos de otro club.

Pilar 04

Auditoría por defecto

Cada acción autenticada — vista, puntuación, mensaje, anulación — se registra de forma inmutable. Los admins de club pueden exportar el log de auditoría de su organización a demanda.

Pilar 05

Consciente del cumplimiento

GDPR, KVKK, objetivo SOC 2 Type II en Q4 2026. DPO liderado por fundadores que gestiona cada solicitud en menos de 30 días.

Pilar 06

Sin entrenamiento sin consentimiento

Los datasets públicos entrenan Match y Vision. Los datos privados de clubes miembros se cifran con claves por club y nunca se usan para entrenar modelos cruzados sin consentimiento por escrito.

Registro de controles

La lista completa, por área.

Si tu equipo de seguridad tiene un cuestionario de procurement, esta sección responde aproximadamente el 70 %. Rellenamos el resto con gusto.

Autenticación y acceso

  • OTP magic-link de Supabase, TOTP por llave hardware opcional
  • Matriz de permisos por rol aplicada en middleware + RLS
  • Los admins de club controlan invitación, rol y revocación
  • Caducidad de sesión: 7 días en inactividad, 30 días absolutos, configurable por org

Protección de datos

  • AES-256-GCM en reposo para columnas sensibles (PII, biometría)
  • TLS 1.3 en tránsito, HSTS preload, solo cifradores modernos
  • Sobres de claves por club para flujos privados de GPS/biometría
  • Seguridad a nivel de fila en Postgres para cada tabla de ámbito de club

Seguridad de aplicación

  • Content-Security-Policy estricto + Trusted Types
  • Validación de entrada en cada endpoint (allowlist, longitud máx., coerción de tipos)
  • Solo prepared statements — nada de concatenación de strings en SQL
  • Dependabot + secret scanning activos en cada commit

Operacional

  • Pentest trimestral por una firma independiente (a partir del año 2)
  • Ingenieros con verificación de antecedentes; sin contratistas offshore con acceso a producción
  • Backups cifrados, retención 30 días, probados trimestralmente
  • Runbook de respuesta a incidentes con rotación de fundador on-call

Privacidad

  • Solicitudes GDPR + KVKK Artículo 15/Artículo 17 atendidas en menos de 30 días
  • Sin reventa de datos. Sin tracking publicitario. Sin analítica entre contextos.
  • Residencia de datos en región UE disponible desde el tier Analyst
  • Borrado de datos a petición: 30 días de soft delete, luego borrado criptográfico
Arquitectura de cifrado

Cómo se mantienen privados los mensajes de la Deal Room.

La mensajería de la Deal Room se cifra de extremo a extremo con las mismas primitivas que Signal — el acuerdo de claves X3DH y el Double Ratchet — y se ejecuta por completo en el navegador sobre la Web Crypto API. El servidor transmite el texto cifrado y las claves previas públicas; nunca posee las claves que descifran una conversación.

Paso 01

Acuerdo de claves X3DH

Cada miembro posee una clave de firma Ed25519 y una clave ECDH X25519. Para abrir un canal, el iniciador obtiene el paquete de claves previas del destinatario — una clave previa firmada y, cuando está disponible, una clave previa de un solo uso — y ejecuta un intercambio Diffie-Hellman triple (3-DH). La clave previa firmada prueba que el paquete pertenece al destinatario y no a un servidor que lo suplanta.

Paso 02

Double Ratchet

El secreto compartido alimenta un Double Ratchet. Una cadena de claves simétricas HKDF-SHA256 avanza con cada mensaje, de modo que una clave filtrada no revela nada sobre los mensajes anteriores (secreto hacia adelante). Un paso de trinquete Diffie-Hellman con nuevas claves efímeras sana la sesión tras un compromiso breve de un dispositivo (seguridad tras compromiso).

Paso 03

Sello de mensaje AES-256-GCM

Cada clave por mensaje sella el texto plano con AES-256-GCM (cifrado autenticado, IV de 96 bits). El servidor solo almacena el texto cifrado, el IV y la clave efímera pública del remitente. No tiene acceso a las claves de mensaje derivadas en el cliente.

Conocimiento cero

Claves que el servidor nunca posee.

Las claves privadas de identidad, previas y de trinquete se generan y se conservan en los dispositivos de los miembros. El endpoint del paquete solo almacena claves previas públicas opacas; las claves de mensaje existen únicamente en la memoria del navegador. La consecuencia práctica: ni siquiera Scout Atlas puede leer el contenido de la Deal Room — no hay una clave del lado del servidor que se pueda exigir.

Estado honesto

Dónde estamos hoy.

Este es el diseño de cifrado que se publica actualmente en una etapa temprana (v0). La criptografía está implementada y se ejercita mediante pruebas, pero aún no ha pasado una auditoría independiente de terceros y todavía no la describimos como reforzada para producción. El canal de claves previas se degrada de forma elegante — las claves previas de un solo uso mantienen una reserva mínima, de modo que un grupo agotado recurre a X3DH solo con clave previa firmada en lugar de fallar de forma abierta. Actualizaremos esta página a medida que el diseño madure y sea revisado.

Residencia de datos

Residencia en la región de la UE y base de transferencia.

Los clubes miembros con sede en la UE pueden solicitar la residencia de datos en la región de la UE en el nivel Analyst y superiores. Cuando se transfieren datos personales fuera del EEE o el Reino Unido, nos basamos en las Cláusulas Contractuales Tipo (SCC) de la Comisión Europea o en una decisión de adecuación aplicable; las transferencias fuera de Türkiye se realizan bajo las garantías exigidas por el artículo 9 de la KVKK. La política completa figura en nuestro aviso de protección de datos.

Lo que no hacemos

Aquello en lo que no transigimos.

No haremos

Vender o compartir tus datos.

Sin reventa de datos, sin partnerships con brokers, sin datasets “anonimizados” en la trastienda. Tu plantilla es tuya.

No haremos

Entrenar modelos con datos privados sin consentimiento.

Las entradas privadas de clubes miembros (GPS, biometría, médicas) no entrenan ningún modelo. Punto. Los datasets públicos están públicamente declarados.

No haremos

Leer tus mensajes del Deal Room.

La mensajería del Deal Room está cifrada extremo a extremo. Aunque lo solicitara una orden judicial, no podríamos producir el contenido.

No haremos

Enterrar incidentes.

Cualquier incidente de seguridad que afecte a datos de miembros se comunica a los clubes afectados en menos de 72 horas, con un post-mortem por escrito en menos de 14 días.

Divulgación de vulnerabilidades

¿Encontraste un fallo? Queremos saberlo.

Operamos un programa abierto de divulgación responsable. Escribe a security@scoutatlas.co con detalles y pasos de reproducción. Respondemos en menos de 48 horas y damos crédito a los investigadores en el changelog cuando los parches salen.