🛡

FlowDesk — Requisitos de Seguridad

Security Requirement Extraction · CULTIVA IA / Servicio de Seguridad

v1.0 GDPR OWASP ASVS SOC 2 Type II
Documento de requisitos de seguridad derivados del modelo de amenazas STRIDE para FlowDesk, plataforma SaaS B2B de automatización de workflows. Cada requisito es trazable a una amenaza concreta, tipificado por dominio, priorizado por riesgo y verificable mediante criterios de aceptación y casos de prueba.
ProyectoFlowDesk SaaS B2B
FasePre-lanzamiento · Q3 2026
Amenazas analizadas5 (STRIDE)
Generado16 Jun 2026
OwnerEquipo Seguridad · CULTIVA IA
EstadoDraft — Revisión pendiente
15
Requisitos totales
6
Prioridad Critical
6
Prioridad High
3
Prioridad Medium
5
Amenazas STRIDE
3
Frameworks compliance
⚠
Modelo de Amenazas — STRIDE Input
T-001 · SPOOFING
Suplantación de cuenta de usuario
→ /auth (Sistema de autenticación)
Un atacante obtiene credenciales via phishing o credential stuffing y se hace pasar por un usuario legítimo para acceder a flujos de trabajo y datos de clientes.
CRITICALImpacto: HIGH · Prob: HIGH
T-002 · TAMPERING
Manipulación de workflows activos
→ Motor de ejecución de workflows
Insider threat modifica un flujo activo para alterar su comportamiento, por ejemplo redirigiendo correos salientes a destinos no autorizados.
HIGHImpacto: HIGH · Prob: MEDIUM
T-003 · INFORMATION DISCLOSURE
Exposición de tokens OAuth de terceros
→ Almacén de credenciales de integración
Tokens OAuth de HubSpot/Salesforce/Gmail almacenados sin cifrado expuestos en una brecha de base de datos, comprometiendo el acceso a plataformas de terceros.
CRITICALImpacto: CRITICAL · Prob: MEDIUM
T-004 · DENIAL OF SERVICE
Abuso de la API de triggers
→ /api/v1/trigger (API pública)
Script externo dispara miles de ejecuciones en segundos agotando recursos del servidor y degradando el servicio para todos los tenants.
CRITICALImpacto: HIGH · Prob: HIGH
T-005 · ELEVATION OF PRIVILEGE
Acceso cross-tenant via IDOR
→ Capa de acceso multi-tenant
Fallo en aislamiento de tenants permite a usuario de empresa A acceder a workflows y contactos de empresa B mediante manipulación de IDs en URLs.
MEDIUMImpacto: CRITICAL · Prob: LOW
📋
Requisitos de Seguridad por Dominio
🔐 Authentication 3 requisitos
SR-001 Implementar autenticación robusta para el sistema de autenticación CRITICAL Funcional
El sistema de autenticación debe verificar la identidad de todos los usuarios antes de conceder acceso, soportando MFA para cuentas con permisos elevados y cuentas Enterprise.
Mitiga amenaza: T-001 — Suplantación de cuenta de usuario via credential stuffing o phishing.

✅ Criterios de Aceptación

  • Los usuarios deben autenticarse antes de acceder al sistema de autenticación
  • Los fallos de autenticación quedan registrados y monitorizados
  • MFA disponible para operaciones sensibles y cuentas Enterprise

🧪 Casos de Prueba

  • Test: Acceso no autenticado al sistema de autenticación es denegado (HTTP 401)
  • Test: Credenciales inválidas son rechazadas con mensaje genérico
  • Test: Los tokens de sesión no pueden ser forjados
Trazabilidad: T-001 OWASP V2.1 OWASP V2.2 OWASP V2.3 SOC2
SR-002 Validar tokens de identidad criptográficamente CRITICAL Funcional
Todos los tokens de autenticación (JWT/session cookies) deben ser verificados criptográficamente en cada solicitud. Los tokens expirados, revocados o mal formados deben ser rechazados.
Mitiga amenaza: T-001 — Previene uso de tokens robados o manipulados para suplantar usuarios.

✅ Criterios de Aceptación

  • Los usuarios deben autenticarse antes de acceder a recursos protegidos
  • Los fallos de autenticación quedan registrados y monitorizados
  • MFA disponible para operaciones de alto riesgo

🧪 Casos de Prueba

  • Test: Token manipulado (firma inválida) es rechazado con HTTP 401
  • Test: Token expirado es rechazado y solicita re-autenticación
  • Test: Token de otro tenant no da acceso a recursos del tenant objetivo
Trazabilidad: T-001 OWASP V2.3 OWASP V3.1
SR-003 Gestión segura de sesiones con expiración configurable CRITICAL No Funcional
Las sesiones deben gestionarse de forma segura: tiempo de vida máximo 8h, expiración por inactividad a 30min, invalidación en logout, rotación de tokens tras re-autenticación.
Mitiga amenaza: T-001 — Limita la ventana de explotación de tokens comprometidos.

✅ Criterios de Aceptación

  • Sesión expira tras 30min de inactividad
  • Logout invalida el token en servidor (no solo cliente)
  • Sesiones concurrentes desde IPs distintas generan alerta

🧪 Casos de Prueba

  • Test: Sesión inactiva 31min devuelve 401 en siguiente request
  • Test: Token usado tras logout devuelve 401
  • Test: Sesión supera 8h y es invalidada automáticamente
Trazabilidad: T-001 OWASP V3.2 OWASP V3.3
🔒 Data Protection & Cryptography 4 requisitos
SR-004 Cifrado de tokens OAuth en reposo con KMS CRITICAL Restricción
Los tokens OAuth de HubSpot, Salesforce, Slack y Gmail deben almacenarse cifrados con AES-256-GCM gestionado por KMS (AWS KMS o equivalente) con rotación de claves automática cada 90 días. Nunca en texto plano en BBDD ni logs.
Mitiga amenaza: T-003 — Una brecha de BBDD no expone tokens OAuth que otorgan acceso a plataformas de terceros de los clientes.

✅ Criterios de Aceptación

  • Datos sensibles en almacén de credenciales están cifrados
  • Acceso a datos sensibles queda registrado en audit log
  • Los mensajes de error no revelan información sensible

🧪 Casos de Prueba

  • Test: Volcado directo de BBDD no muestra tokens en texto plano
  • Test: Datos del almacén de credenciales están cifrados en tránsito (TLS 1.3)
  • Test: Los mensajes de error del endpoint no incluyen stack traces ni tokens
Trazabilidad: T-003 GDPR Art. 32 GDPR Art. 25 OWASP V6.1 OWASP V8.3
SR-005 Control de acceso basado en necesidad de conocimiento (need-to-know) CRITICAL Funcional
El acceso a credenciales OAuth y datos sensibles de clientes debe estar restringido: solo el servicio de ejecución de workflows puede leer tokens en runtime. Ningún endpoint de API expone tokens en respuestas. Los administradores ven solo metadatos.
Mitiga amenaza: T-003 — Minimiza la superficie de exposición de tokens incluso con acceso legítimo comprometido.

✅ Criterios de Aceptación

  • Datos sensibles en el almacén están cifrados
  • Todo acceso a datos sensibles queda auditado
  • Errores no revelan información sensible

🧪 Casos de Prueba

  • Test: GET /integrations/{id} no devuelve access_token en respuesta
  • Test: Usuario con rol "viewer" no puede acceder a credenciales
  • Test: Logs de aplicación no contienen tokens OAuth
Trazabilidad: T-003 GDPR Art. 25 OWASP V8.1 OWASP V8.2
🧹 Input Validation 3 requisitos
SR-006 Validar toda entrada al motor de ejecución de workflows HIGH Funcional
Todas las definiciones de workflow (JSON/YAML) deben ser validadas contra un schema estricto antes de su persistencia o ejecución. Caracteres de control, scripts embebidos y referencias a recursos externos deben ser rechazados.
Mitiga amenaza: T-002 — Previene inyección de lógica maliciosa en definiciones de workflow.

✅ Criterios de Aceptación

  • Toda entrada al motor de workflows es validada
  • La integridad de datos es verificada antes del procesamiento
  • Los intentos de modificación no autorizados disparan alertas

🧪 Casos de Prueba

  • Test: Payload con campo extra no schema es rechazado con 422
  • Test: Inyección de script en nombre de workflow es saneada
  • Test: Workflow con paso de tipo desconocido es rechazado
Trazabilidad: T-002 OWASP V5.1 OWASP V5.2 OWASP V5.3
⚡ Availability — Rate Limiting 3 requisitos
SR-009 Rate limiting por tenant en API de triggers CRITICAL Restricción
La API /api/v1/trigger debe aplicar rate limiting por tenant y por API key: máximo 100 req/min en plan Free, 1.000 req/min en Pro, configurable en Enterprise. Exceder el límite devuelve HTTP 429 con cabecera Retry-After.
Mitiga amenaza: T-004 — Previene que un tenant malicioso o comprometido sature el servidor y degrade el servicio del resto.

✅ Criterios de Aceptación

  • Rate limiting está aplicado en la API de triggers
  • El sistema degrada con gracia bajo alta carga
  • El agotamiento de recursos dispara alertas automáticas

🧪 Casos de Prueba

  • Test: Llamada 101 en plan Free devuelve HTTP 429 con Retry-After
  • Test: Burst de 500 req en 5s no causa timeout a otros tenants
  • Test: Los límites se reinician correctamente tras la ventana de tiempo
Trazabilidad: T-004 SOC2 OWASP V5.1
🔑 Authorization — Multi-Tenant Isolation 3 requisitos
SR-012 Aplicar autorización con aislamiento de tenant en capa de datos MEDIUM Funcional
Cada query a la base de datos multi-tenant debe incluir obligatoriamente el filtro tenant_id del usuario autenticado. El ORM/query builder debe aplicar este filtro a nivel de middleware, sin depender de que cada controlador lo añada manualmente.
Mitiga amenaza: T-005 — Previene IDOR y acceso cross-tenant por manipulación de IDs en URL o payload.

✅ Criterios de Aceptación

  • La autorización es verificada para todas las operaciones en la capa de acceso multi-tenant
  • Los usuarios no pueden acceder a recursos más allá de sus permisos
  • Los cambios de privilegios quedan registrados y monitorizados

🧪 Casos de Prueba

  • Test: GET /workflows/{id_de_otro_tenant} devuelve 403 o 404
  • Test: Intentos de escalada de privilegios son bloqueados y logueados
  • Test: No hay vulnerabilidades IDOR (fuzzing de IDs con Burp/OWASP ZAP)
Trazabilidad: T-005 GDPR Art. 32 SOC2
📝 Audit Logging 2 requisitos
SR-013 Log inmutable de eventos de seguridad en motor de workflows HIGH Funcional
Todos los eventos de seguridad relevantes (modificaciones de workflow, cambios de permisos, accesos a integraciones, fallos de autenticación, activaciones de rate limit) deben quedar registrados con timestamp, user_id, tenant_id, acción e IP. Los logs no deben ser modificables por usuarios regulares.
Mitiga amenaza: T-002 — Permite detectar y forense la manipulación de workflows por insiders.

✅ Criterios de Aceptación

  • Todas las acciones en el motor de workflows quedan registradas con identidad del usuario
  • Los logs no pueden ser modificados por usuarios regulares
  • La retención de logs cumple con requisitos de compliance (mín. 1 año)

🧪 Casos de Prueba

  • Test: Modificación de workflow genera entrada en audit log con todos los campos
  • Test: Los logs incluyen suficiente detalle para reconstruir la secuencia de eventos
  • Test: La integridad de logs está protegida (hash de cadena o append-only store)
Trazabilidad: T-002 GDPR Art. 30 SOC2 OWASP V7.1
🗺
Matriz de Trazabilidad Amenaza → Requisito
Amenaza Descripción Categoría STRIDE Requisitos derivados Prioridad
T-001 Suplantación de cuenta via credential stuffing SPOOFING
SR-001 SR-002 SR-003
CRITICAL
T-002 Manipulación de workflows activos (insider) TAMPERING
SR-006 SR-007 SR-013
HIGH
T-003 Exposición de tokens OAuth en brecha de BBDD INFO DISCLOSURE
SR-004 SR-005 SR-008
CRITICAL
T-004 Abuso API triggers — agotamiento de recursos DENIAL OF SERVICE
SR-009 SR-010 SR-011
CRITICAL
T-005 Acceso cross-tenant via IDOR en capa de datos PRIV ESCALATION
SR-012 SR-014 SR-015
MEDIUM
⚖
Mapeo a Frameworks de Cumplimiento
Framework Control Descripción Requisitos FlowDesk
GDPR Art. 25 Privacy by Design and by Default
SR-004SR-005SR-012
GDPR Art. 30 Records of Processing Activities
SR-013SR-014
GDPR Art. 32 Security of Processing — cifrado y confidencialidad
SR-004SR-008SR-012
OWASP ASVS V2 (Auth) Authentication Verification Requirements
SR-001SR-002SR-003
OWASP ASVS V3 (Session) Session Management Verification Requirements
SR-003
OWASP ASVS V5 (Input) Validation, Sanitization & Encoding
SR-006SR-007SR-009
OWASP ASVS V6 (Crypto) Stored Cryptography Verification Requirements
SR-004SR-008
OWASP ASVS V7 (Errors) Error Handling & Logging Verification
SR-013SR-014
OWASP ASVS V8 (Data) Data Protection Verification Requirements
SR-004SR-005SR-008
SOC 2 CC6.1 Logical and Physical Access Controls
SR-001SR-002SR-012
SOC 2 CC7.2 System Monitoring — alertas y detección
SR-009SR-011SR-013
🔍
Análisis de Gaps — Cobertura de Compliance
Framework Área Estado cobertura Observación
GDPR Cifrado de datos en reposo (Art. 32) ✓ Cubierto SR-004 cubre AES-256-GCM + KMS. Verificar cobertura de backups.
GDPR Registro de actividades de tratamiento (Art. 30) ⚠ Cobertura débil SR-013/14 cubren audit logs pero falta política de retención documentada formalmente.
GDPR Derecho al olvido — eliminación de datos ✗ Sin cobertura No hay requisito de seguridad que cubra el borrado seguro de datos de clientes. Añadir SR-16.
OWASP Autenticación y gestión de sesiones (V2/V3) ✓ Cubierto SR-001 a SR-003 cubren todos los controles ASVS Level 2 de autenticación.
OWASP Validación de entrada (V5) ✓ Cubierto SR-006/007 cubren validación. Pendiente: test de fuzzing automatizado en CI/CD.
SOC 2 Disponibilidad y continuidad (CC7) ⚠ Cobertura débil SR-009/010/011 cubren rate limiting pero falta requisito de RTO/RPO y plan de DR.
SOC 2 Gestión de accesos privilegiados (CC6.3) ✗ Sin cobertura No hay requisito para accesos privilegiados de administradores de FlowDesk. Añadir SR-17.