Medidas técnicas y organizativas (TOMs) – flowgeist DMS
Fecha: 27.09.2026
Versión: 1.0
Ámbito de aplicación: Art. 32 RGPD, Contrato de encargo del tratamiento (AVV)
Estas medidas técnicas y organizativas describen las precauciones de seguridad que flowgeist adopta para proteger los datos personales en la plataforma flowgeist DMS.
1. Control de acceso físico (seguridad física)
| Medida | Descripción |
|---|
| Centro de datos | Hetzner Online GmbH, Falkenstein (Alemania). Seguridad física proporcionada por el operador del centro de datos (controles de acceso, videovigilancia, sistema de detección de incendios). |
| Modelo de despliegue | Despliegue Docker en un solo servidor (vdps-prod-01). Sin dispositivos físicos en flowgeist. |
2. Control de acceso lógico (seguridad lógica)
| Medida | Descripción |
|---|
| Hash de contraseñas | scrypt con parámetros OWASP (N=16384, r=8, p=1, salt de 128 bits, hash de 64 bytes). Formato: scrypt:N:r:p:saltB64:hashB64. |
| Autenticación | Keycloak 24 (OpenID Connect/OAuth2), validación JWT mediante JWKS, refresh de token |
| Autenticación multifactor | TOTP (RFC 6238, HMAC-SHA1, ventana de 30 s) disponible para usuarios |
| RBAC | Control de acceso basado en roles con enum DmsRole + tabla RolePermission (catálogo de permisos: module.resource.action, p. ej. crm.customers.read, admin.tenants.manage). Matriz de permisos: Employee→Admin, Admin→Admin+feature flags, Owner→Owner. |
| Aislamiento multi-tenant | Separación estricta de datos de mandantes a nivel de base de datos mediante PostgreSQL Row-Level Security (migraciones V001__tenants.sql + V005__rls_policies.sql); tenant_id en cada tabla; contexto de mandante mediante middleware |
| Gestión de sesiones | Flujo de código OIDC mediante Keycloak; TTL de sesión: 7d acceso / 30d refresh; rememberMe: 30d |
| Bloqueo de cuenta | Detección de fuerza bruta de Keycloak (para cuentas gestionadas) |
| Acceso de soporte | Acceso Admin/Owner mediante flujo de impersonation; verificación de claim específico |
| Gestión de secretos en producción | Infisical — inyección de secretos en runtime (sin secretos en el código); .env.docker.dev solo para desarrollo |
3. Control de acceso a datos
| Medida | Descripción |
|---|
| Políticas RLS | PostgreSQL Row-Level Security en todas las tablas de mandante (V005__rls_policies.sql); variable de sesión app.current_tenant |
| Catálogo de permisos | dms_permission_catalog.csv + dms_role_matrix.csv; verificación de permisos en middleware de rutas |
| Control de acceso a API | Middleware de autenticación en todas las rutas /v1/; guards Require-Role/Require-Permission |
| Permisos granulares | Acciones por recurso: read, write, delete, export |
4. Control de divulgación (transmisión de datos)
| Medida | Descripción |
|---|
| TLS | TLS 1.2 y 1.3 para todas las conexiones (frontend Nginx, ssl_protocols TLSv1.2 TLSv1.3); Let’s Encrypt/certbot |
| Cabeceras de seguridad | HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy |
| API Gateway | APISIX 3.9 (opcional en producción; rutas Nginx directas para proxy Next.js) |
| Seguridad de webhooks | Verificación de firma HMAC-SHA256 para webhooks entrantes; validación de timestamp (protección contra replay) |
| File Transfer Hub | SFTP para transferencias de archivos salientes (P14) |
| Secretos | Infisical; sin secretos en el código |
5. Control de entrada (registro)
| Medida | Descripción |
|---|
| Registro de auditoría | Registro de accesos y acciones relevantes para la seguridad (A.8.15); tabla audit_log append-only (V004__audit_log.sql) — los triggers impiden UPDATE/DELETE; el usuario no puede eliminar/modificar sus propias entradas |
| Auditoría de IA | Cada solicitud de copilot/agente se registra en el registro de IA (ai_decision_audit): hash de entrada, herramienta, modelo, latencia, coste, flags de PII, denegaciones de política; retención de 7 años (política M18) |
| Observabilidad | SigNoz + OpenTelemetry (auto-alojado, ningún dato sale de la infraestructura); trazas OTLP, logs, métricas |
| Documentación | Módulo data-resilience: alineación GoBD; versionado de documentos mediante Mayan EDMS |
6. Control de encargos (control de subencargados)
| Medida | Descripción |
|---|
| Subencargados del tratamiento | Sin subencargados externos más allá de Hetzner (alojamiento); todos los componentes de la plataforma (PostgreSQL, Keycloak, MinIO, OpenSearch, ClickHouse, Kafka, Valkey, Temporal, Novu, Mayan EDMS, ERPNext, Kimai, APISIX, Infisical, SigNoz) son OSS embebidos en la propia infraestructura de Hetzner de flowgeist |
| Tratamiento de IA | Exclusivamente modelos residentes en la UE (Azure OpenAI EU / modelos auto-alojados como Mistral/Llama); sin transmisión a modelos públicos; el registro de IA documenta los sistemas utilizados |
| Integraciones configuradas por el cliente | Los conectores del Integration Hub (OEM, DAT/Schwacke, DATEV, PEPPOL, bancos, redes de carga) solo se activan tras la configuración del cliente; sin flujo automático de datos |
| Documentación | La documentación legal (política de privacidad, AVV) refleja el estado actual |
7. Control de disponibilidad
| Medida | Descripción |
|---|
| Copia de seguridad | Restic para PostgreSQL, MinIO, volcados de base de datos (módulo data-resilience); rclone como capa de transporte (diversos destinos remotos configurables, p. ej., S3, SFTP) |
| Recuperación | Point-in-Time Recovery mediante WAL de PostgreSQL; módulo data-resilience con workflows de restauración |
| Infraestructura | Hardware empresarial de Hetzner; despliegue en un solo servidor con todos los servicios como contenedores Docker |
| Monitorización | SigNoz + OpenTelemetry (auto-alojado): trazas, logs, métricas, alertas |
8. Exigencia de separación (separación de mandantes)
| Medida | Descripción |
|---|
| Aislamiento de mandantes | Separación estricta de los datos de clientes a nivel de base de datos mediante PostgreSQL Row-Level Security; tenant_id en cada tabla; variable de sesión app.current_tenant |
| Aprovisionamiento de mandantes | Aprovisionamiento automatizado de mandantes (V006__tenant_provisioning.sql); sin esquema compartido sin RLS |
| Datos entre mandantes | Solo las tablas globales no vinculadas a mandantes (catálogo de permisos, feature flags) no están vinculadas a mandante |
| Separación de almacenamiento | Almacenamiento de objetos compatible con MinIO/S3 con esquema de rutas por mandante |
9. Medidas organizativas
| Medida | Descripción |
|---|
| Proceso de desarrollo | Revisiones de código, pipeline CI/CD, aislamiento de módulos con anti-corruption layer; AGENTS.md como estándar de desarrollo |
| Gestión de accesos | Modelo RBAC con matriz de permisos; asignación de equipos mediante grupos de Keycloak |
| Documentación | Documentación técnica por módulo (docs/), registro de cumplimiento por cambio |
| Confidencialidad | Todos los empleados están sujetos a obligaciones de confidencialidad |
| Gestión de cambios | Migraciones Flyway (versionadas, append-only); versionado semántico |
| Gobernanza de IA | Registro de IA, filtro de PII, guardrails de RAG, human-in-the-loop para aprobaciones (alineación EU AI Act: riesgo limitado/mínimo) |
10. Revisión
| Versión | Fecha | Cambios |
|---|
| 1.0 | 27.09.2026 | Versión inicial para flowgeist DMS — verificado en código: hash scrypt, autenticación Keycloak, TOTP, aislamiento de mandantes RLS, audit_log append-only, backup Restic, SigNoz, Infisical, APISIX, gobernanza de IA, Integration Hub |