Visión general de seguridad
DevAI Suite gestiona datos regulados de manufactura (APQP, FMEA, PPAP, registros de proveedores y operaciones) para clientes de automoción y aeroespacial. Diseñamos y operamos la plataforma con salvaguardas administrativas, técnicas y organizativas alineadas con NIST CSF 2.0 y las familias de controles de ISO 27001. Esta página es el resumen ejecutivo; el white paper completo de seguridad cubre cada control en profundidad.
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 security@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 (Voyage AI voyage-3-large, 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 (Argon2id), 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 de corta duración con rotación en acciones sensibles. Se almacenan en cookies
HttpOnly; Secure; SameSite=Laxy se validan en servidor en cada solicitud. - 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 (DPA en vigor) 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 /subprocessor-list.html e incluye Cloudflare (DNS / R2 storage / Turnstile), Fly.io (cómputo / Postgres gestionado), Anthropic / OpenAI / Groq (inferencia LLM; opt-in por org), Voyage AI (embeddings), Stripe (facturación), Resend (correo transaccional), 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 headcomo 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
Los backups Point-in-Time de Postgres se conservan durante 5 días con procedimientos de restauración documentados y una cadencia trimestral de simulacros de restauración (última verificación: 2.º trimestre 2026). El RTO objetivo para una restauración full-stack es de 30 minutos. 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.