Este documento describe las medidas técnicas y organizativas aplicadas por CookieSafe para garantizar un nivel de seguridad adecuado al riesgo (art. 32 RGPD). Forma parte integrante del DPA y se referencia desde la Política de Privacidad y el RAT.
No contiene secretos, configuraciones específicas, IPs, contraseñas, claves ni nombres de personas concretas. Cualquier evidencia detallada se entrega bajo NDA en auditoría.
- IP de Visitantes: nunca se almacena en claro. Se transforma en su recepción mediante `SHA-256(IP || sal_diaria)`. La sal se rota cada 24 horas y la sal anterior se destruye, lo que hace la transformación irreversible más allá del día. Detalle técnico en `docs/adr/ADR-015-hash-ip-sal-diaria.md`. - Identificadores de Visitante: UUID v4 generados en cliente, sin correlación con datos personales directos. - User-agent: truncado a familia (navegador + SO mayor) antes de almacenar. - Datos de pago: nunca atraviesan los sistemas del Encargado; Stripe.js los captura y tokeniza en cliente.
- Autenticación: - Clientes: email + contraseña hasheada con Argon2id + MFA opcional (TOTP). - Personal interno: SSO corporativo + MFA obligatoria (hardware key preferida). - Autorización: control por roles con principio de mínimo privilegio. Roles internos diferenciados (soporte, operación, DPO, administración). Cada rol tiene permisos documentados. - Acceso a producción: limitado a personal estrictamente necesario, mediante bastión SSH, llaves rotadas y registro de sesión. - Revisión periódica: revisión trimestral de privilegios; revocación inmediata al cesar.
- Registro de acceso al panel (inicio/cierre de sesión, cambio de contraseña/MFA, exportaciones, cambios de configuración) durante 12 meses. - Registro de acciones administrativas sobre datos personales durante 24 meses, con identificación del operario. - Registro de fallos de seguridad (intentos fallidos, peticiones malformadas, rate-limit) durante 90 días. - Logs almacenados en sistema separado de la aplicación, sólo lectura para roles no administradores.
- Frecuencia: backup completo diario + WAL continuo de PostgreSQL. - Cifrado: cada backup se cifra con age antes de salir del servidor. - Retención: 30 días en almacenamiento caliente + 90 días en frío. - Prueba de restauración: ensayo de restauración mensual en entorno aislado, con verificación de integridad y registro del resultado. - RPO objetivo: ≤ 1 hora. RTO objetivo: ≤ 4 horas.
- Dependencias: análisis automatizado en CI (SCA) en cada commit. - Análisis estático (SAST) en pipeline; bloqueo de despliegue ante hallazgos críticos. - Análisis dinámico y revisión manual antes de cada release mayor. - Penetration test externo anual. - Parcheado: aplicación de parches críticos en plazo máximo de 7 días desde su disponibilidad; altos en 30 días; medios y bajos según ventana planificada.
- Repositorios privados con revisión de pares obligatoria antes de merge a `main`. - Prohibido subir secretos al repositorio; escaneo automatizado (gitleaks) en pre-commit y en CI. - Entornos `dev`, `staging` y `production` aislados, con datos sintéticos en los dos primeros. - Cambios de esquema y configuración mediante migraciones versionadas.
1. Detección: monitorización 24/7 (alertas de integridad, anomalías, rate-limit, IDS). 2. Contención: aislar el componente afectado y preservar evidencias. 3. Análisis: equipo de respuesta evalúa naturaleza, alcance, datos afectados, riesgo para los interesados. 4. Notificación AEPD: si supone riesgo, dentro de las 72 horas desde el conocimiento, mediante el formulario oficial (art. 33 RGPD). 5. Notificación al interesado: si el riesgo es alto, sin dilación indebida y de forma clara (art. 34 RGPD). 6. Notificación al Responsable (cuando actuemos como encargado): en un plazo máximo de 72 horas con la información del art. 33.3 RGPD. 7. Documentación: registro interno de toda brecha, hayamos o no notificado, conforme al art. 33.5 RGPD. 8. Lecciones aprendidas: revisión post-mortem y mejora del proceso.
Plantilla de notificación al Responsable disponible en la wiki interna.
- Onboarding obligatorio en protección de datos para todo el personal con acceso a datos. - Refresco anual con casos prácticos (phishing, manejo de información, ingeniería social). - Confidencialidad: compromiso de confidencialidad firmado por todo el personal y subcontratistas con acceso. - Política de uso aceptable de equipos y de la red corporativa.
- Selección con due-diligence (certificaciones, contrato, ubicación de tratamiento). - Contratos materialmente equivalentes a este DPA. - Revisión anual o ante incidente. - Lista pública y actualizada en `legal/dpa.md` §8 y notificación al Cliente con 30 días de antelación ante cambios.
El servidor principal (Hestia) se ubica en datacenter en territorio español con: - Control de acceso físico mediante tarjeta + biometría. - CCTV 24/7 con retención según normativa local. - Suministro eléctrico redundante (UPS + grupo electrógeno). - Climatización redundante. - Detección y extinción de incendios.
- Datos en BD: borrado lógico inmediato + purga física en máximo 90 días (ciclo de backups). - Soportes físicos retirados: borrado criptográfico + destrucción certificada. - Cuentas internas: revocación inmediata; rotación de credenciales compartidas si las hubo.
Estas medidas se revisan: - Anualmente con carácter ordinario. - Ante incidente significativo, cambio normativo o cambio sustancial del Servicio. - Las revisiones quedan reflejadas en `version` y `fecha_emision` y se comunican a los Clientes con 30 días de antelación cuando reduzcan garantías.
Cualquier consulta debe dirigirse al DPO ([EMAIL DPO]).