Medidas técnicas y organizativas (TOMs) – DIRIGENT
Estado: 14.08.2026
Versión: 1.0
Ámbito de aplicación: Art. 32 RGPD, Art. 28 Abs. 3 lit. c RGPD
1. Control de acceso físico
Medidas que impiden que personas no autorizadas accedan a las instalaciones de tratamiento de datos:
- Centro de datos: Los servidores se operan en Hetzner Online GmbH en Falkenstein (Alemania). El centro de datos dispone de un control de acceso físico de varios niveles.
- Control de acceso al centro de datos: Videovigilancia las 24 horas del día, esclusa de personas con control de identificación y biometría, registro de accesos.
- Armario de servidores: Bloqueo físico de los racks de servidores. Acceso solo para personal autorizado de Hetzner.
- Oficinas: Las oficinas de flowgeist están equipadas con un sistema mecánico de cerraduras. Acceso solo para personas autorizadas.
- Gestión de llaves: Gestión estricta de llaves con documentación de la entrega y devolución de llaves.
- Control de visitantes: Los visitantes son registrados y acompañados durante toda su estancia.
2. Control de acceso lógico
Medidas que impiden que personas no autorizadas utilicen sistemas de tratamiento de datos y accedan a datos personales:
- Autenticación: El acceso a sistemas y aplicaciones requiere una autenticación fuerte mediante nombre de usuario y contraseña. Las contraseñas se almacenan con hash Argon2id (usuario demo, si procede, con bcrypt).
- Políticas de contraseñas: Aplicación de políticas de contraseñas (longitud mínima, complejidad, cambio regular).
- Autenticación multifactor (MFA): Obligatoria para todos los accesos administrativos y administradores de tenant. Implementación mediante TOTP (Time-based One-Time Password).
- Inicio de sesión único (SSO): Soporte de SSO para la autenticación centralizada en entornos B2B.
- Control de acceso basado en roles (RBAC): Control de acceso estrictamente basado en roles según el principio de mínimo privilegio. Los usuarios solo reciben los permisos necesarios para su rol.
- Sesión PKCE: Gestión de sesiones en el lado del servidor mediante PKCE (Proof Key for Code Exchange). Las sesiones se gestionan en el servidor, no en cookies del lado del cliente.
- Rotación de refresh-tokens: En cada renovación de token se emite un nuevo refresh-token para prevenir el abuso de tokens.
- Aislamiento multi-tenant: Cada cliente (tenant) obtiene un área de datos aislada. La compartición de datos entre tenants está técnicamente excluida mediante PostgreSQL Row-Level-Security (RLS).
- Registro de accesos: Todos los accesos a sistemas y datos personales se registran (registro de auditoría ISO 27001 conforme a A.12.4).
- Gestión de sesiones: Cierre de sesión automático por inactividad.
- Bloqueo: Bloqueo automático de cuentas tras varios intentos fallidos de inicio de sesión.
- ThrottlerGuard: Rate-limiting para proteger contra ataques de fuerza bruta y abuso.
3. Control de transmisión
Medidas que garantizan que los datos personales no puedan ser leídos, copiados, modificados o eliminados de forma no autorizada durante la transmisión electrónica:
- Cifrado de transporte: Todas las transmisiones de datos se realizan cifradas mediante TLS 1.3 (Transport Layer Security). El uso de protocolos obsoletos (SSL, TLS 1.0, TLS 1.1, TLS 1.2) está desactivado.
- HTTPS: Toda la comunicación web se realiza exclusivamente a través de HTTPS (HSTS activado).
- Cifrado de API: Todos los endpoints de API requieren conexiones cifradas (HTTPS/TLS 1.3).
- Lista blanca de orígenes CORS: En producción, lista blanca estricta de orígenes CORS, sin fallback a localhost.
- Swagger/OpenAPI desactivado: La documentación Swagger/OpenAPI está desactivada en producción (ISO 27001 A.13.1.1).
- Gestión de certificados: Uso de certificados TLS válidos con renovación automática. Supervisión de la validez de los certificados.
- Conexiones a base de datos: Las conexiones a la base de datos PostgreSQL 18 están cifradas (SSL/TLS).
- Conexiones Redis: Las conexiones a Redis están cifradas.
- Transmisión de copias de seguridad: Las copias de seguridad se transmiten cifradas.
- WAF (Web Application Firewall): Uso de un Web Application Firewall para proteger contra ataques a la capa de transmisión.
4. Control de entrada
Medidas que permiten verificar y determinar a posteriori si, por quién y en qué medida se han introducido, modificado o eliminado datos personales en sistemas de tratamiento de datos:
- Registro de auditoría ISO 27001 (A.12.4): Registro de todas las acciones relevantes para la seguridad conforme a ISO 27001, incluyendo:
- Marca de tiempo
- Identificador de usuario
- Identificador de tenant
- Acción (crear, leer, modificar, eliminar)
- Recurso
- Dirección IP
- User-Agent
- Trace-IDs (OpenTelemetry W3C Trace Context)
- Registro de acciones administrativas: Todas las acciones administrativas (gestión de usuarios, cambios de roles, configuración de tenant) se registran.
- Auditoría de overrides: Las anulaciones manuales en el Workflow Engine (listas de verificación de transición, quality gates) se registran completamente.
- Protección de integridad de los registros: Los registros de auditoría se almacenan de forma protegida contra manipulaciones. Almacenamiento de solo lectura con protección criptográfica.
- Conservación de los registros: Los registros de auditoría se conservan durante 3 años.
- Versionado: Los cambios de datos se documentan con versiones, cuando sea aplicable.
5. Control de encargo
Medidas que garantizan que los datos personales tratados por encargo solo se traten conforme a las instrucciones del responsable del tratamiento:
- Vinculación contractual: Celebración de contratos de encargado del tratamiento (AVV) conforme al Art. 28 RGPD con todos los subencargados del tratamiento.
- Vinculación a instrucciones: Tratamiento de datos personales exclusivamente según las instrucciones documentadas del responsable del tratamiento.
- Control de subencargados del tratamiento: Selección cuidadosa y revisión periódica de los subencargados del tratamiento (Hetzner Online GmbH).
- Obligaciones contractuales: Todos los empleados y subencargados del tratamiento están contractualmente obligados a mantener la confidencialidad.
- Documentación: Documentación completa de los procesos de tratamiento e instrucciones.
- Sin servicios externos: La plataforma no utiliza servicios de IA externos, ni servicios de análisis web, ni servicios de pago. No se emplean otros servicios externos.
6. Control de disponibilidad
Medidas que protegen los datos personales contra la destrucción accidental o pérdida:
- Estrategia de copias de seguridad: Copias de seguridad automatizadas periódicas de la base de datos PostgreSQL 18. Las copias de seguridad completas se crean diariamente.
- Conservación de copias de seguridad: Las copias de seguridad se almacenan cifradas (AES-256 en reposo) y se mantienen según los plazos de conservación definidos.
- Prueba de copias de seguridad: Verificación periódica de la restauración de copias de seguridad (pruebas de restore).
- Redundancia: Uso de componentes del sistema redundantes para evitar puntos únicos de fallo.
- Supervisión: Supervisión continua de la disponibilidad y el rendimiento del sistema mediante OpenTelemetry, Loki, Tempo y Grafana (observabilidad interna). Alerta automática ante incidencias.
- Alta disponibilidad: La infraestructura de Hetzner Online GmbH ofrece alimentación eléctrica, refrigeración y conexiones de red redundantes.
- Plan de emergencia: Plan de emergencia documentado (Disaster Recovery Plan) con Recovery Time Objectives (RTO) y Recovery Point Objectives (RPO) definidos.
- Tolerancia a fallos: Reinicio automático ante fallos del sistema. Supervisión de la integridad del sistema.
- Patrón Outbox: El cambio de estado y el evento se escriben en una transacción para garantizar la consistencia y disponibilidad de los datos.
7. Control de separación
Medidas que garantizan que los datos personales recogidos para diferentes finalidades de tratamiento puedan tratarse de forma separada:
- Aislamiento multi-tenant: Separación lógica estricta de los datos entre diferentes clientes (tenants). Cada tenant obtiene un área de datos aislada. La compartición de datos entre tenants está técnicamente excluida.
- PostgreSQL Row-Level-Security (RLS): Los datos de diferentes tenants se separan en la base de datos PostgreSQL 18 mediante Row-Level-Security. En cada transacción se ejecuta
SET LOCAL app.tenant_id, y FORCE ROW LEVEL SECURITY garantiza que las consultas se filtren siempre de forma específica por tenant.
- Propagación del contexto de tenant: El contexto de tenant se propaga mediante JWT-claim y se aplica de forma consistente en cada transacción.
- Separación por roles: Separación funcional mediante RBAC. Los datos para diferentes finalidades de tratamiento (p. ej., registros de auditoría, datos de workflow, notificaciones) se almacenan y gestionan de forma separada.
- Separación de entornos: Separación estricta de entornos de producción, staging y desarrollo. Los datos de producción no se utilizan en entornos que no son de producción.
- Separación de registros: Los registros de auditoría se almacenan separados de los datos operativos para garantizar una conservación protegida contra manipulaciones.
- Aislamiento de módulos: Monolito modular NestJS con aislamiento estricto de módulos. La comunicación entre módulos se realiza exclusivamente a través de rutas API internas.
8. Cifrado
Medidas para garantizar la confidencialidad e integridad de los datos personales mediante cifrado:
- Cifrado de transporte: TLS 1.3 para todas las transmisiones de datos (HTTPS, API, conexiones a base de datos, Redis, transmisión de copias de seguridad).
- Cifrado en reposo: Cifrado AES-256 para datos almacenados (base de datos, copias de seguridad, sistemas de archivos).
- Hashing de contraseñas: Las contraseñas se almacenan con Argon2id, un procedimiento de hashing moderno y seguro. No se almacenan contraseñas en texto plano. Usuario demo, si procede, con bcrypt.
- Secretos MFA: Los secretos TOTP para la autenticación multifactor se almacenan cifrados.
- Gestión de claves: Gestión segura de las claves de cifrado. Las claves se almacenan separadas de los datos cifrados.
9. Seudonimización
Medidas de seudonimización de datos personales:
- Seudonimización de datos de auditoría: Las direcciones IP en los registros de auditoría se seudonimizan o eliminan tras el vencimiento del plazo de conservación.
- Tenant-IDs: La asignación de datos a un cliente determinado se realiza a través de tenant-IDs seudónimos, que no permiten una inferencia directa sobre la identidad del cliente sin acceso a la tabla de asignación.
- Trace-IDs: Los Trace-IDs de OpenTelemetry permiten una correlación seudónima de solicitudes a través de los límites del sistema, sin revelar datos personales.
10. Revisión periódica
Medidas para la revisión y evaluación periódica de la eficacia de las medidas técnicas y organizativas:
- Revisión de los TOMs: Revisión y actualización periódica de las medidas técnicas y organizativas, al menos anualmente.
- ISO 27001: La plataforma se opera conforme a ISO 27001. Revisión periódica de las configuraciones de seguridad y los derechos de acceso en el marco del ISMS.
- Auditorías de seguridad: Revisión periódica de las configuraciones de seguridad y los derechos de acceso.
- Pruebas de penetración: Realización periódica de pruebas de penetración y revisiones de seguridad de la plataforma.
- Gestión de vulnerabilidades: Supervisión continua y resolución de vulnerabilidades conocidas (Vulnerability Management). Actualizaciones y patch-management periódicos.
- Plan de respuesta a incidentes: Proceso documentado para la respuesta a incidentes de seguridad. Definición de responsabilidades y vías de escalado.
- Sensibilización de empleados: Formación y sensibilización periódica de los empleados en materia de protección de datos y seguridad de la información.
- Supervisión: Supervisión continua de sistemas y redes mediante OpenTelemetry/Loki/Tempo/Grafana para la detección de anomalías y posibles incidentes de seguridad.
- Evaluación de registros: Evaluación periódica de registros de auditoría y registros de acceso para la detección de abusos.
11. Subencargados del tratamiento
Los siguientes subencargados del tratamiento se emplean en el marco del tratamiento de datos personales para DIRIGENT:
| Subencargado del tratamiento | Ubicación | Finalidad | Relación con terceros países | AVV | TOMs |
|---|
| Hetzner Online GmbH | Alemania (Falkenstein) | Hosting, base de datos (PostgreSQL 18), Redis, copia de seguridad, observabilidad (OpenTelemetry/Loki/Tempo/Grafana) | Sin terceros países | Sí (Art. 28 Abs. 4 RGPD) | Sí |
Hetzner Online GmbH: Como proveedor de hosting, Hetzner Online GmbH trata datos personales en Alemania (Falkenstein). No se produce ninguna transferencia a terceros países. El stack de observabilidad interno (OpenTelemetry, Loki, Tempo, Grafana) se ejecuta en el mismo servidor de Hetzner, por lo que no hay transferencia a terceros países. Con Hetzner se ha celebrado un contrato de encargado del tratamiento conforme al Art. 28 Abs. 4 RGPD. Hetzner dispone de TOMs propios conforme al Art. 32 RGPD que garantizan el nivel de protección para el tratamiento en Alemania.
Sin otros servicios externos: La plataforma DIRIGENT no utiliza servicios de IA externos, ni servicios de análisis web, ni servicios de pago, ni otros servicios externos. Las integraciones planificadas (Booking-Service y Notification vía MS365 Graph API) se realizarán exclusivamente sobre la base de contratos de encargado del tratamiento separados. La lista de subencargados del tratamiento es completa.
12. Historial de cambios
| Versión | Fecha | Cambios principales |
|---|
| 1.0 | 14.08.2026 | Versión inicial de los TOMs para DIRIGENT |