Seguridad de los datos
SecureCodingHub está diseñado con seguridad en cada capa. Esta página explica cómo protegemos los datos de su organización.
Cifrado
Todos los datos están protegidos con cifrado estándar del sector:
En tránsito
Todos los datos se cifran con TLS 1.2+ entre su navegador y nuestros servidores. Sin transmisión en texto plano.
En reposo
Todos los datos en reposo se cifran con cifrado AES-256. Las copias de seguridad de la base de datos están cifradas.
Infraestructura
- Alojado en AWS (región de EE. UU.)
- Aplicación y base de datos en redes aisladas
- Parches y actualizaciones de seguridad periódicos
- Protección DDoS mediante AWS Shield
- Monitorización y alertas automatizadas
Tratamiento de datos
Esto es lo que almacenamos y por qué:
| Tipo de dato | Almacenado | Propósito |
|---|---|---|
| Correo y nombre del usuario | Sí | Identificación de la cuenta |
| Progreso de retos y puntuaciones | Sí | Seguimiento de la formación |
| Preferencias de stack | Sí | Personalización |
| Tokens de autenticación | Temporal | Gestión de sesión |
| Contraseñas | No | Usamos autenticación sin contraseña |
| Código fuente | No | Los retos son solo del lado del cliente |
Cumplimiento
- Cumple con el RGPD — tratamiento de datos con base de interés legítimo / contrato
- Los usuarios pueden solicitar la exportación o eliminación de sus datos
- Retención de datos: cuentas activas conservadas indefinidamente, cuentas eliminadas purgadas a los 90 días
- Subprocesadores listados en nuestra política de privacidad
Control de acceso
- Control de acceso basado en roles dentro de cada organización (
org_adminylearner) - Aislamiento de datos a nivel de organización (multi-tenant) — cada registro lleva un alcance
organizationIdaplicado en la capa de acceso a datos - Autenticación con token SCIM para las API de aprovisionamiento (condicionada a que SSO esté configurado primero)
- Limitación de tasa por API key en la superficie pública REST y de webhooks (60 peticiones/minuto y 1.000 peticiones/hora por clave); un limitador independiente por IP en el formulario de contacto web anónimo (5 / 15 minutos)
- Tokens bearer JWT para los endpoints de administración y estudiante orientados al navegador; API keys hash de larga duración para la superficie pública — detalles completos en Autenticación
Firma de webhooks
Los webhooks salientes desde SecureCodingHub hacia sus endpoints se firman con HMAC-SHA256 utilizando un secreto por endpoint que se muestra al administrador una sola vez al crear el endpoint y nunca se devuelve después. La cabecera de firma tiene la forma t=<unix_seconds>,v1=<hex>; el payload firmado es <t>.<raw_body>. Los receptores deberían rechazar cualquier entrega cuya marca de tiempo se desvíe más de 5 minutos del reloj del receptor para defenderse de la repetición, y comparar firmas en tiempo constante.
La entrega es al-menos-una-vez. Las entregas fallidas (cualquier respuesta no 2xx o fallo de red) se reintentan con backoff exponencial en un calendario de 1m / 5m / 30m / 2h / intento final. Tras cinco intentos fallidos, el endpoint se desactiva automáticamente y se notifica al administrador de organización mediante el registro de auditoría. Las muestras de código de configuración y verificación están en API → Webhooks.
Tratamiento de secretos a nivel de aplicación
A nivel de aplicación se gestionan tres tipos de secretos; su tratamiento en disco se describe aquí para completar la información junto al cifrado de capa de almacenamiento explicado arriba.
| Secreto | Almacenamiento | Vida útil |
|---|---|---|
| API keys públicas | Solo se persisten el hash SHA-256, el prefijo de 9 caracteres (scs_live_) y los últimos cuatro caracteres. El token completo se muestra una sola vez al crearlo y no puede recuperarse de nuevo desde el servidor. | Indefinida por defecto. Puede establecerse una fecha de caducidad opcional al crear la clave. La revocación surte efecto de inmediato. |
| Secretos de firma de webhooks | Almacenados en texto plano junto al registro del endpoint del webhook porque el servidor necesita el valor en crudo para firmar cada entrega saliente. Se muestran una sola vez al crearlos y nunca se devuelven a través de la API. La rotación requiere eliminar y volver a crear el endpoint. | Vive mientras viva el endpoint del webhook. |
| Magic codes (OTP por correo) | El código de 6 dígitos se persiste como texto plano en la fila del magic code. Los códigos son de un solo uso y están vinculados al correo del usuario; la fila se marca como consumida tras la primera verificación. | Cada código caduca 10 minutos después de su emisión. Los códigos no consumidos caducados permanecen en la tabla como rastro de auditoría hasta que las tareas de mantenimiento los limpian. |
| Secretos de cliente SSO / certificados SAML | Almacenados en texto plano en el registro SchSsoConfig porque el servidor necesita los valores en crudo para negociar con el IdP. No se exponen a través de ningún endpoint de lectura después de guardar la configuración. | Viven mientras viva la configuración SSO. |
Notificación de vulnerabilidades
Si descubre una vulnerabilidad de seguridad, contacte con security@securecodinghub.com. Nos tomamos todos los reportes en serio y aspiramos a responder en un plazo de 48 horas.
Clasificación de datos en SecureCodingHub
Tratamos los datos en nuestro entorno como pertenecientes a tres categorías prácticas. Los datos del cliente son la información que pertenece a su organización y que sus usuarios introdujeron o generaron a través de la plataforma: identificadores de cuenta, direcciones de correo de estudiantes, asignaciones de rol, progreso de formación, puntuaciones frente a retos individuales y preferencias de stack. Esta categoría es la que le preocupa a su DPO y la que tratamos como el nivel de mayor sensibilidad internamente.
La telemetría operativa es la segunda categoría. Cubre registros de peticiones, métricas de rendimiento anonimizadas, trazas de error con identificadores personales eliminados y contadores utilizados para alimentar los paneles de fiabilidad a nivel de plataforma. Estos datos son necesarios para operar el servicio con seguridad y se conservan en una ventana rodante más corta que los datos del cliente. La tercera categoría es el propio contenido de los retos — los ejemplos de código vulnerable, las pistas y las soluciones de referencia que escribimos y enviamos a sus usuarios. Ese contenido es nuestra propiedad intelectual, no la suya, y no se mezcla con los registros de su organización.
Las ventanas de retención difieren en consecuencia. Las cuentas activas de clientes se conservan mientras el contrato esté en vigor. En la eliminación de cuenta purgamos los datos identificables del cliente en un reloj de 90 días, existiendo el retraso para que una eliminación accidental pueda revertirse dentro de la ventana. La telemetría operativa caduca en un ciclo más corto medido en semanas, no en meses. El inventario completo de datos y los detalles de retención están disponibles para los clientes bajo NDA a través del canal de petición listado más abajo, y se resumen para los usuarios finales en la política de privacidad.
Cómo se estructura el cifrado por capas
El cifrado en SecureCodingHub no es un control único — está por capas, y cada capa asume que las demás pueden fallar. Los datos en tránsito entre sus usuarios y la plataforma están protegidos por cifrado a nivel de transporte con una selección moderna de cifradores aplicada en el balanceador de carga, con los protocolos débiles y los cifradores propensos a degradación desactivados. La misma postura de transporte se aplica al tráfico entre los servicios de aplicación y nuestros almacenes de datos gestionados; nada dentro de la VPC de producción se mueve en texto plano a través de un límite de red.
Los datos en reposo se cifran en la capa de almacenamiento utilizando los servicios de cifrado proporcionados por nuestra plataforma de hosting, con la gestión de claves gestionada por el servicio de gestión de claves de ese mismo proveedor en lugar de por material de claves a nivel de aplicación comprometido en nuestro código. Las copias de seguridad heredan la misma postura de cifrado que el almacén principal. Mantenemos deliberadamente la descripción aquí a nivel de política en lugar de publicar algoritmos específicos, longitudes de clave o cadencias de rotación en una página pública, porque publicar esos valores invita a dependencias frágiles y ofrece a los atacantes una lista de objetivos. Los detalles están disponibles bajo NDA para las revisiones de compras.
El aislamiento de tenants es la tercera capa. Cada registro en el nivel de datos del cliente está acotado a un identificador de organización, y ese acotamiento se aplica en la capa de acceso a datos en lugar de depender únicamente de filtros a nivel de aplicación. El efecto práctico es que un error de consulta en una función no puede exponer accidentalmente los datos de otra organización a través de la API, porque el alcance ausente se manifestaría como ningún resultado en lugar de como resultados equivocados. El control de acceso basado en roles dentro de una organización se aplica en la misma capa de acceso a datos, de modo que el alcance de organización del usuario y su rol determinan juntos qué registros son visibles antes de que se ejecute cualquier filtro a nivel de aplicación.
Postura de subprocesadores y residencia de datos
SecureCodingHub se aloja hoy únicamente en regiones de EE. UU. Es una elección operativa deliberada en nuestra escala actual — operar una única región principal simplifica nuestra respuesta a incidentes, reduce la superficie que los auditores deben recorrer y mantiene corta nuestra lista de subprocesadores. Para las organizaciones que nos evalúan desde fuera de EE. UU., este es el dato más importante que comunicar a su responsable de protección de datos desde el principio: los datos cruzan una frontera de EE. UU. por diseño, y se ponen a disposición salvaguardias contractuales, incluidas las cláusulas contractuales estándar, para respaldar esa transferencia.
Si añadimos un despliegue residente en la UE en el futuro, los cambios serán materiales y no cosméticos. Una región principal independiente implica un conjunto independiente de subprocesadores con operaciones residentes en la UE, un conjunto independiente de destinos de copia de seguridad y una adenda actualizada de tratamiento de datos que refleje el nuevo flujo. No transferiremos las organizaciones existentes a una nueva región de forma silenciosa; cualquier movimiento sería una migración opt-in con aviso y una ventana de transición definida. La lista actual de subprocesadores, la declaración de postura regional y un resumen actual de prueba de penetración están disponibles bajo petición en security@securecodinghub.com. Respondemos los cuestionarios de seguridad del proveedor directamente en lugar de únicamente vía portales de confianza compartidos, y no requerimos que la parte solicitante sea un cliente de pago para recibir la lista de subprocesadores actual.