Medidas técnicas y organizativas

Estado: abril de 2026. Estas MTO se adaptan periódicamente al estado de la técnica. Las modificaciones sustanciales se comunican al cliente.

1. Confidencialidad

El encargado del tratamiento gestiona una empresa individual sin empleados adicionales con acceso a los datos. Todos los subencargados utilizados (véase el DPA § 7) están obligados a la confidencialidad. Los propios dispositivos finales (estaciones de trabajo de desarrollo) están cifrados con FileVault, protegidos mediante Touch ID y contraseñas robustas, así como provistos de bloqueo automático de pantalla.

2. Seudonimización (art. 32 apdo. 1 lit. a del RGPD)

• En los registros, las direcciones de correo electrónico no se referencian en texto plano, sino exclusivamente como tenant_id o ID de usuario anonimizado (redacción de registros de pino).
• Las direcciones IP se «hashean» para la limitación de tasa mediante un IP_HASH_SALT secreto (HMAC-SHA-256); las IP originales no se almacenan de forma persistente.
• IPv4 se normaliza a /32 e IPv6 a /64, para restringir adicionalmente la trazabilidad.

3. Cifrado (art. 32 apdo. 1 lit. a del RGPD)

3.1 Cifrado en tránsito

• Todas las conexiones: HTTPS / TLS 1.2+ (HSTS activado).
• Conexiones SMTP a IONOS mediante STARTTLS, TLS 1.2+ forzado.
• Conexiones de base de datos internas mediante socket UNIX o TLS.

3.2 Cifrado en reposo

• Tokens OAuth (redes sociales): «envelope encryption» AES-256-GCM con claves versionadas (ENCRYPTION_KEY, ENCRYPTION_KEY_V2…V16). Formato: v{N}:iv:tag:ct. El contexto AAD está vinculado a tenantId:socialAccountId:platform — la manipulación del contexto de la fila hace fracasar el descifrado.
• Contraseñas: Argon2id con los parámetros OWASP 2024 (m=19456 KiB, t=2, p=1). Los hashes heredados de bcrypt se detectan al iniciar sesión y se vuelven a calcular de forma transparente a Argon2id.
• Cifrado del disco de la VM: la infraestructura cloud de IONOS ofrece cifrado de disco a nivel de proveedor.
• Secretos: los archivos .env exclusivamente con permisos de archivo 0600, nunca en el repositorio Git.

4. Control de acceso físico (físico / infraestructura)

• El sistema productivo funciona en los centros de datos de IONOS en Alemania (certificados ISO 27001, ISO 22301). El acceso físico está salvaguardado por parte del proveedor (servicio de seguridad 24/7, biometría, videovigilancia).
• Acceso SSH a los servidores: exclusivamente mediante clave pública (sin inicio de sesión por contraseña), a través de un puerto SSH no estándar (2222), con Fail2ban contra ataques de fuerza bruta, y con la imposición de IdentitiesOnly=yes.
• El cortafuegos (firewalld) restringe las conexiones entrantes a los puertos 2222 (SSH), 80 (redirección HTTP a HTTPS) y 443 (HTTPS).
• SELinux en modo Enforcing.

5. Control de acceso lógico (a nivel de aplicación)

• Autenticación: correo electrónico + contraseña (Argon2id) o SSO (Google / Microsoft / Apple). Tokens de sesión basados en JWT con firmas ES256 y rotación de kid (ranura de clave CURRENT + opcionalmente PREVIOUS para una rotación sin tiempo de inactividad).
• Rotación de tokens de actualización: rotación basada en familias con una ventana de gracia de 10 segundos en Redis; ≥3 aciertos de gracia del mismo ID de token antiguo activan theft_detected y la revocación de la familia.
• Aislamiento multiinquilino mediante seguridad a nivel de fila (RLS) de Postgres: las conexiones de la aplicación se ejecutan con el rol de BD castloop_app (sin BYPASSRLS). Cada transacción establece app.tenant_id mediante SET LOCAL. Las migraciones se ejecutan con castloop_migrator (con BYPASSRLS). Ni siquiera una inyección SQL puede salir del ámbito del propio inquilino (defensa en profundidad).
• Limitación de tasa: script Lua de Redis (comprobación+incremento atómicos) contra ataques de fuerza bruta y abuso.
• CSRF: cookies SameSite=Strict + tokens CSRF.
• CSP: Content Security Policy con nonce por solicitud y strict-dynamic, que evita el XSS.
• Acceso SSH al servidor: únicamente un administrador individual (el titular).

6. Control de separación

• Bases de datos separadas por proyecto en el servidor compartido (BD de Postgres propia castloop con usuario propio castloop_user, sin acceso a otras BD).
• Los entornos de producción, staging y desarrollo están separados entre sí; los secretos de producción nunca llegan a staging/dev.
• Modo estricto de claves de Mollie: en producción exclusivamente claves live_*, en staging/dev exclusivamente claves test_* — forzado mediante superRefine de zod.

7. Integridad (art. 32 apdo. 1 lit. b del RGPD)

• La RLS evita la manipulación de datos entre inquilinos (véase 5).
• Los bloqueos de aviso (advisory locks) de Postgres (clave 821912301) regulan las migraciones de Drizzle: dos despliegues paralelos no pueden migrar al mismo tiempo.
• El cifrado de tokens OAuth vinculado a AAD: la manipulación del contexto de la fila hace fracasar el descifrado (protección de integridad mediante la etiqueta AES-GCM).
• La idempotencia de los webhooks de Mollie: tabla dedicada mollie_webhook_events con clave de idempotencia (resource_id, payload_hash) (sha256 sobre JSON canónico).
• La validación de entradas en el lado del cliente y del servidor (esquemas de zod).

8. Disponibilidad

• Reinicio automático de pm2: castloop-api, castloop-worker y castloop-app se ejecutan bajo la supervisión de pm2 y se reinician automáticamente en caso de fallo.
• Apagado controlado: SIGTERM/SIGINT drenan las solicitudes HTTP y los trabajos de BullMQ; con un límite estricto mediante SHUTDOWN_TIMEOUT_MS.
• Endpoint de comprobación de estado para la monitorización.
• Copias de seguridad por instantáneas de VM: gestionadas por el proveedor IONOS, con rotación diaria. Sin copias de seguridad pg_dump propias — la capa de instantáneas del proveedor se considera suficiente.

9. Resiliencia

• La limitación de tasa protege contra la sobrecarga.
• BullMQ con mecanismos de reintento (retroceso exponencial) para el renderizado de clips y la publicación en plataformas.
• El barredor de huérfanos de la ingesta de Mollie (intervalo de 60 s, gracia de 120 s, deduplicación con jobId=eventId de BullMQ) evita la deriva de pagos en caso de webhooks fallidos.
• Conexiones de ioredis independientes para BullMQ frente al código de la aplicación evitan colisiones de prefijos de clave.

10. Recuperabilidad (art. 32 apdo. 1 lit. c del RGPD)

• Instantáneas de VM con rotación diaria (gestionadas por IONOS).
• El despliegue mediante Git + rsync permite una reversión a un commit anterior en cuestión de minutos.
• Las migraciones idempotentes y reguladas por bloqueos de aviso permiten una reejecución segura en caso de fallos parciales.

11. Procedimiento de revisión periódica

• Actualizaciones de dependencias (npm audit, Dependabot) al menos mensualmente.
• Parches del SO (AlmaLinux) al menos mensualmente.
• Monitorización de registros: registros de pino con redacción de campos sensibles (contraseñas, tokens, JWT, cabeceras authorization/cookie, claves de API, DATABASE_URL, REDIS_URL, SMTP_PASS).
• Revisión interna anual de las MTO, en su caso adaptación al estado de la técnica.
• En caso necesario / a petición del cliente, pruebas de penetración externas.

12. Control de los encargos

• Contratos de DPA por escrito con todos los subencargados utilizados (véase el DPA § 7), en la medida en que estos deban clasificarse, en términos de protección de datos, como encargados del tratamiento.
• Vías de instrucción documentadas: panel del cliente, corpus contractual de AGB/DPA, correo electrónico sin formalidades a info@castloop.de.
• No se utilizan otros subencargados sin un aviso previo de 30 días al cliente (véase el DPA § 7).

Estado: abril de 2026 · Versión 1.0 · Anexo 1 al DPA