Visión general de seguridad

1. Cumplimiento y hoja de ruta de certificaciones

Somos una empresa fundada en 2026. Cuando hay certificaciones en curso lo decimos honestamente — el trabajo de preparación está en marcha y las auditorías de terceros están programadas.

Para el calendario completo de auditorías, los nombres de los evaluadores externos y la evidencia de gap pre-auditoría, contacta con admin@devaisuite.com.

2. Aislamiento de datos y multi-tenant

Los datos de cada cliente residen en una única base de datos Postgres compartida, aislados mediante Row-Level Security (RLS) de PostgreSQL. Cada tabla con datos de cliente tiene una política RLS atada al contexto del tenant de la solicitud; la capa de aplicación define el tenant en cada sesión de base de datos a través de un middleware integrado en la cadena de autenticación. Las consultas SELECT entre tenants devuelven cero filas por diseño, incluso si el código de aplicación tiene un bug.

El almacenamiento de documentos para RAG es por tenant: los documentos cargados por cada org viven en prefijos del object-storage definidos por org_id. La búsqueda RAG está limitada por el mismo contexto de tenant. Los embeddings (Cloudflare Workers AI @cf/baai/bge-m3, 1024 dimensiones) se almacenan en pgvector; la lectura de embeddings aplica RLS de igual modo.

3. Cifrado

En tránsito: TLS 1.2+ en todos los endpoints accesibles al cliente. HSTS con includeSubDomains. Solo cipher suites fuertes (AES-GCM y ChaCha20-Poly1305).

En reposo: los datos de Postgres se cifran en reposo mediante el cifrado de volumen del proveedor de nube. El object storage (Cloudflare R2) cifra en reposo por defecto. Las credenciales sensibles de integración se cifran mediante envelope con una clave Fernet por despliegue (DEVAI_CREDENTIALS_ENCRYPTION_KEY); la clave se rota en una cadencia documentada y nunca sale del store de secretos.

4. Autenticación y control de acceso

• Opciones de identidad: correo/contraseña (PBKDF2-HMAC-SHA256, con sal por contraseña; bcrypt para cuentas heredadas), Google SSO, Microsoft Entra ID SSO. Los usuarios solo-SSO tienen contraseña NULL (no hay fallback de contraseña).
• MFA: basado en TOTP, opcional según política de la org y obligatorio para el rol platform-admin.
• Autorización: control de acceso basado en roles con permisos verificados en cada ruta protegida vía ensure_permission. Las decisiones se registran en un log de auditoría append-only.
• Tokens de sesión: JWT con una vida de 8 horas, renovables hasta una duración absoluta de sesión de 30 días. Se almacenan en cookies HttpOnly; Secure; SameSite=Strict y se validan en servidor en cada solicitud. Cerrar sesión la termina en el servidor; un cambio o restablecimiento de contraseña termina las demás sesiones de esa cuenta.
• CAPTCHA: Cloudflare Turnstile protege registro, login, restablecimiento de contraseña y el sandbox público de demo.

5. Registros de auditoría

Los eventos relevantes para seguridad se escriben en una tabla de auditoría append-only definida por org: eventos de autenticación, cambios de rol, accesos a artefactos regulados (envíos PPAP, ediciones FMEA), aceptar/rechazar propuestas de IA, cambios en credenciales de integración y toggle del sandbox. Los logs se envían a un agregador centralizado (breadcrumbs de Sentry sin PII; logs estructurados para operaciones). Los administradores cliente pueden solicitar la exportación del histórico de auditoría de su org vía el flujo DSR.

6. Gestión de proveedores y subencargados

Usamos proveedores externos verificados para infraestructura, IA y entrega de correo. Cada subencargado se revisa por residencia de datos, términos contractuales y postura de seguridad antes de la incorporación. Los cambios se notifican a los clientes según la cadencia del DPA.

La lista actual de subencargados está publicada en /es/subprocessor-list.html e incluye Fly.io (cómputo, UE / Fráncfort), Neon (PostgreSQL + pgvector gestionado, UE / Fráncfort), Cloudflare (DNS / almacenamiento de objetos R2 / Turnstile / embeddings de documentos con Workers AI, no fijados a la UE), Together AI / Anthropic / OpenAI (inferencia LLM), Inngest (orquestación de trabajos en segundo plano), Stripe (facturación), Resend (correo transaccional) y Sentry (seguimiento de errores con PII saneada).

7. Ciclo de vida seguro de desarrollo

• Branch protection en main; revisiones obligatorias en cada PR.
• CI automatizado: type checks, suite de tests unitarios + integración (~3.000 tests), gate de drift en la spec OpenAPI.
• Monitorización de dependencias vía GitHub Dependabot; los parches relevantes para seguridad se aplican en 7 días para advisories de severidad alta.
• Ningún secreto en el código; Fly Secrets store + provisioning por despliegue con chequeo de arranque validate_production_config (rechaza el boot si falta config).
• Las migraciones de base de datos se revisan y son idempotentes; producción ejecuta alembic upgrade head como pre-flight del release.

8. Monitorización, detección y respuesta a incidentes

La monitorización continua cubre errores de aplicación, salud de infraestructura (estado de Fly, Postgres readiness, Redis, R2) y anomalías de rate-limit. La integración con Sentry captura excepciones con saneado de PII aplicado en el filtro de logging. Mantenemos procedimientos documentados de respuesta a incidentes con severidad escalonada, rutas de escalado, plantillas de comunicación en página de estado y cadencia de post-mortem (ver también nuestro runbook de escalado). Cuando la ley lo exige para violaciones de datos personales, la notificación al cliente se realiza dentro de las 72 horas desde la confirmación del incidente.

9. Recuperación ante desastres y continuidad

La base de datos conserva un historial continuo de escrituras: se puede restaurar cualquier momento de las últimas 24 horas (ensayado en staging el 9 de julio de 2026). De forma independiente, cada noche se escribe un volcado en un segundo proveedor en la UE, con retención de 30 días diarios y 12 meses mensuales, y los documentos de los clientes se copian cada noche a un bucket separado en la UE. Hay un simulacro de restauración mensual automatizado, que empezará a ejecutarse en cuanto se cree su credencial de almacenamiento. El RTO de 30 minutos para una restauración full-stack es un objetivo, todavía no una medición. El object storage es de región única (Cloudflare R2); la biblioteca global de plantillas es reproducible desde el código fuente vía la herramienta publish_global_library. El runbook completo de DR es interno pero está disponible para clientes Enterprise bajo NDA.

10. Responsabilidades del cliente (modelo compartido)

La seguridad es compartida. El cliente es responsable de gestionar los usuarios autorizados de su org, proteger las credenciales, habilitar la configuración de seguridad disponible (MFA, dominios de email permitidos), validar las salidas de IA antes de basarse en ellas para decisiones reguladas y evaluar qué datos elige cargar.

11. Contacto