⚖ Medidas técnicas y organizativas – DIRIGENT

Medidas técnicas y organizativas – DIRIGENT

v1.2 · 08.08.2026

Medidas técnicas y organizativas – DIRIGENT

Version 1.2 · Stand: 08.08.2026
flowgeist ZERO flowgeist KITA flowgeist TOOL CombiJornada DIRIGENT flowgeist DMS flowgeist UNI

Medidas técnicas y organizativas (TOMs) – DIRIGENT

Estado: 29.08.2026 Versión: 1.1 Á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 (memoria 64 MiB, iteraciones 3, paralelismo 4). Los hashes bcrypt antiguos se migran de forma transparente a Argon2id en el siguiente inicio de sesión exitoso.
  • Políticas de contraseñas: Aplicación de políticas de contraseñas (longitud mínima, complejidad, cambio regular).
  • Autenticación multifactor (MFA): Disponible para todas las cuentas de usuario mediante TOTP (Time-based One-Time Password). Una vez activada MFA para una cuenta, el segundo factor es obligatorio en el inicio de sesión. Una obligatoriedad de MFA basada en roles (p. ej. para administradores) no está técnicamente impuesta actualmente y está planificada.
  • 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 con cookies HttpOnly: PKCE (Proof Key for Code Exchange) con gestión de sesiones en el lado del servidor. Los access- y refresh-tokens se almacenan en cookies HttpOnly, Secure (en producción), SameSite=strict. Los refresh-tokens se almacenan en el lado del servidor en Redis como hash SHA-256.
  • 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 restringida mediante PostgreSQL Row-Level-Security (RLS). FORCE ROW LEVEL SECURITY está activado para las tablas hasta la migración 68; para tablas más recientes (a partir de la migración 69), RLS está activado, pero FORCE RLS está pendiente y planificado.
  • Registro de accesos: Todos los accesos a sistemas y datos personales se registran (registro de auditoría alineado con ISO 27001 A.12.4).
  • Gestión de sesiones: Cierre de sesión automático por inactividad.
  • ThrottlerGuard: Rate-limiting global para proteger contra ataques de fuerza bruta y abuso; los intentos repetidos de inicio de sesión se limitan. Un bloqueo automático de cuenta (lockout) no está implementado actualmente.

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: Las transmisiones de datos se realizan cifradas mediante TLS 1.3 (Transport Layer Security). TLS 1.3 se exige en el servidor como versión mínima; 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 se realizan cifradas mediante TLS en el entorno de producción (sslmode=verify-full).
  • Conexiones Redis: Las conexiones Redis no están cifradas actualmente (TCP plano). TLS para Redis está planificado.
  • Transmisión de copias de seguridad: La transmisión de copias de seguridad se realiza cifrada, siempre que se transmitan copias de seguridad.
  • WAF (Web Application Firewall): Todos los accesos a la API se filtran a través de un Web Application Firewall previo (ModSecurity v3 con OWASP Core Rule Set v4) antes de llegar al backend.

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 alineado con 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 como una cadena de hash particionada y criptográficamente encadenada (SHA-256, sequence/prevHash/hash por entrada). Las modificaciones posteriores de entradas individuales son así detectables (a prueba de manipulación). La supresión se realiza mediante partition detach tras el vencimiento del plazo de conservación.
  • Conservación de los registros: Los registros de auditoría se almacenan particionados y se conservan durante 7 años (configurable).
  • 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 (activos): La plataforma no utiliza actualmente servicios activos de IA externos, web analytics ni servicios de pago. Existen adaptadores para Auth0/Keycloak, SuperOffice, Work4All, Jira, MS365/Graph (Booking/Calendar), AGE, Confluence, FAUST, Handelsregister, MS Dynamics 365, SAP S/4HANA. Las llamadas HTTP a servicios externos están desactivadas por defecto mediante flags *_USE_HTTP. Existen mock-connectors para SharePoint y Leadinfo (ambos backlog). Integraciones planificadas: MS365 Booking y MS365 Graph Email-Notifications.

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 diarias automatizadas de la base de datos PostgreSQL (pg_dump). Las copias de seguridad se replican en forma cifrada (AES-256) a un backend de almacenamiento offsite separado (automatizado mediante systemd timer). Además, se proporcionan snapshots a nivel de infraestructura a través de Hetzner.
  • Conservación de copias de seguridad: Plazos de conservación escalonados para las copias de seguridad offsite — copias diarias 7 días, semanales 4 semanas, mensuales 6 meses.
  • 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. FORCE ROW LEVEL SECURITY está activado para las tablas hasta la migración 68; para tablas más recientes (a partir de la migración 69), RLS está activado, pero FORCE RLS está pendiente y planificado.
  • 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 transmisiones de datos (HTTPS, API). Las conexiones de base de datos están cifradas mediante TLS en el entorno de producción (sslmode=verify-full); las conexiones Redis dentro de la red Docker no están cifradas actualmente, TLS está planificado.
  • Cifrado en reposo: Cifrado AES-256 para datos almacenados (base de datos, sistemas de archivos). Las copias de seguridad offsite se cifran con AES-256 antes de su transferencia.
  • Hashing de contraseñas: Las contraseñas se almacenan con Argon2id (memoria 64 MiB, iteraciones 3, paralelismo 4). No se almacenan contraseñas en texto plano. Los hashes bcrypt antiguos se migran de forma transparente a Argon2id en el siguiente inicio de sesión exitoso.
  • 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 y demás campos identificativos en los registros de auditoría se eliminan completamente tras el vencimiento del plazo de conservación (partition detach) — no se realiza una seudonimización posterior de campos individuales.
  • 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 fue desarrollada con el objetivo de cumplir 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 tratamientoUbicaciónFinalidadRelación con terceros paísesAVVTOMs
Hetzner Online GmbHAlemania (Falkenstein)Hosting, base de datos (PostgreSQL 18), Redis, copia de seguridad, observabilidad (OpenTelemetry/Loki/Tempo/Grafana)Sin terceros paísesSí (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 activos: La plataforma DIRIGENT no utiliza actualmente servicios activos de IA externos, web analytics, servicios de pago ni otros servicios externos. Existen adaptadores para sistemas externos (Auth0/Keycloak, SuperOffice, Work4All, Jira, MS365/Graph, AGE, Confluence, FAUST, Handelsregister, MS Dynamics 365, SAP S/4HANA); las llamadas HTTP están desactivadas por defecto mediante flags *_USE_HTTP. Mock-connectors para SharePoint y Leadinfo (backlog). Integraciones planificadas: MS365 Booking y MS365 Graph Email-Notifications. Estas se realizarán exclusivamente sobre la base de contratos de encargado del tratamiento separados. La lista de subencargados del tratamiento activos es completa.

12. Historial de cambios

VersiónFechaCambios principales
1.014.08.2026Versión inicial de los TOMs para DIRIGENT
1.129.08.2026Alineación con código: bcrypt en lugar de Argon2id documentado, sesión PKCE con cookies HttpOnly corregida, limitación de FORCE RLS documentada, TLS 1.2/1.3 en lugar de 1.3-only, TLS de DB/Redis marcado como planificado, WAF marcado como no implementado, WORM marcado como convencional, automatización de backups marcada como planificada, adaptadores externos y mock-connectors documentados
1.222.09.2026Revisión de código (matriz de afirmaciones): Argon2id verificado como algoritmo hash primario (migración de bcrypt antiguo en el inicio de sesión); PostgreSQL 18 verificado en el servidor (pg18, 18.6); conexiones DB cifradas con TLS (sslmode=verify-full); retención de auditoría corregida a 7 años
1.322.09.2026Revisión de código (puntos restantes): FORCE RLS actualizado a migración 68; WORM/cadena de hash elevada a implementado (tabla de auditoría particionada, SHA-256 sequence/prevHash/hash); obligatoriedad MFA precisada (disponible + impuesta una vez activada, obligatoriedad por rol planificada); afirmación de bloqueo sustituida por rate limiting ThrottlerGuard; seudonimización de IP sustituida por supresión vía partition detach; sección de backups elevada a la realidad offsite cifrada (systemd timer, retención 7d/4s/6m); TLS de DB en §8 hecho consistente con §3
1.422.09.2026Verificación de servidor: PostgreSQL 18 confirmado en el servidor de producción (pg18, 18.6); dominio canónico corregido a dirigent.flowgeist.de (digitallydriven.flowgeist.de retirado); WAF elevado a implementado (ModSecurity v3 + OWASP CRS v4); TLS 1.3-only exigido en el servidor

© 2026 flowgeist – Ralf Carsjens · Todos los derechos reservados