Seguridad

Entorno de producción

El entorno de producción se ejecuta en la UE (Frankfurt) bajo una cuenta en la nube dedicada y totalmente aislada, separada de cualquier otro producto. El cómputo, las redes, el almacenamiento, los secretos y el registro están dedicados por completo a Syncanix. La residencia en la UE se aplica en el código: un despliegue mal configurado se niega a ejecutarse si se resuelve en cualquier región fuera de la UE.

Aislamiento de tenants, con pruebas

Los datos de cada tenant están separados por cuatro capas de cumplimiento independientes; cualquiera de ellas basta por sí sola para detener una petición entre tenants:

1. Frontera: toda petición autenticada debe resolverse a un tenant, o se rechaza en el borde.
2. Contexto de la petición: la identidad del tenant se vincula a la petición y se propaga a cada capa inferior — nunca se pasa a mano.
3. Consultas: cada acceso a datos está acotado explícitamente al tenant solicitante.
4. Base de datos: políticas de seguridad a nivel de fila en cada tabla multi-tenant imponen la misma frontera dentro del propio Postgres — ni siquiera una hipotética comprobación omitida más arriba podría cruzarla.

Esto se prueba, no se afirma: la seguridad a nivel de fila se demuestra con una suite de integración que se ejecuta contra una base de datos Postgres real, y una matriz de sondas nocturna intenta lecturas, escrituras, acceso a logs, acceso a secretos y acceso a búsqueda vectorial entre tenants — se exige que todas las sondas pasen antes de cada despliegue. Los revisores de seguridad pueden solicitar el paquete de evidencias completo en admin@syncanix.com.

Cifrado

Todos los datos de los clientes se cifran en reposo con AES-256. Cada almacén de datos —bases de datos, almacenamiento de objetos, volúmenes adjuntos y registros— se cifra con claves gestionadas que rotan según una cadencia gestionada.

Todos los datos en tránsito usan como mínimo TLS 1.3. El sitio de marketing, el panel de cliente en app.syncanix.com y el endpoint de la API redirigen HTTP a HTTPS y aplican HSTS con un max-age de dos años, incluidos los subdominios y con preload. BYOK (bring-your-own-key) se admite en el plan enterprise: las claves aportadas por el cliente se usan para el sobre de datos del propio cliente sin aparecer jamás en la salida de registros de Syncanix.

Identidad y autenticación

La autenticación del panel la gestiona Auth0. Cada endpoint de la API está protegido por una capa de autenticación que valida la firma del JWT frente al endpoint JWKS del proveedor, verifica el audience y el issuer, y rechaza los tokens caducados. La protección está activada por defecto; un endpoint solo es público cuando se marca de forma explícita. No existe el modo de fallo «olvidé añadir la autenticación»: el valor por defecto se aplica de forma obligatoria.

Autorización

Las comprobaciones de permisos residen en la capa de servicio, no en el borde de la API. Un servicio que responde a «editar el proyecto Y» verifica que quien lo invoca tiene al menos el rol de Editor sobre el proyecto Y antes de acceder a la base de datos. Las llamadas de servicio a servicio usan un esquema de autenticación independiente (sobres firmados o endpoints autenticados por la plataforma): nunca JWT de usuario.

IAM y privilegios mínimos

Cada rol de carga de trabajo lleva la política más reducida posible. Las políticas se escriben de forma explícita; ningún rol utiliza comodines amplios. Cuando la delimitación por recurso no es suficientemente expresiva, las políticas delimitan por etiqueta. No existen claves de acceso de larga duración en CI: la canalización asume un rol mediante OIDC; el desarrollo local utiliza credenciales de corta duración.

Seguridad de la aplicación

Cada argumento de la API y cada cuerpo de solicitud se analiza mediante un esquema estricto antes de llegar al código de servicio. Las consultas a la base de datos están totalmente parametrizadas: sin interpolación de cadenas con entradas del usuario. Las escrituras usan API tipadas, nunca expresiones en bruto construidas a partir de entradas del usuario.

Las cabeceras de seguridad HTTP se incluyen en cada respuesta destinada al cliente:

• Content-Security-Policy con una lista de permitidos estricta (Auth0, origen propio, sin scripts en línea).
• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload.
• X-Frame-Options: DENY (protección contra clickjacking).
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin.
• Permissions-Policy: geolocalización, micrófono y cámara, todos denegados por defecto.

CORS se aplica en dos capas independientes, cada una con una lista explícita de orígenes permitidos. Un origen comodín se rechaza en tiempo de compilación: un despliegue de producción sin orígenes explícitos no puede continuar.

Gestión de secretos

Los secretos de producción residen en un gestor de secretos dedicado, bajo un espacio de nombres por entorno. La configuración no secreta reside en un almacén de parámetros independiente. Los secretos se exponen a las cargas de trabajo en el arranque: nunca residen en el control de versiones. Las credenciales de base de datos rotan automáticamente; los tokens de terceros (Paddle, Anthropic, OpenAI) rotan manualmente con una cadencia trimestral.

Registro y auditoría

Los registros son JSON estructurado con una retención de 14 días por defecto. Cada línea de registro lleva un ID de correlación (ID de solicitud) para poder reconstruir de extremo a extremo el flujo de un único usuario. Una lista de redacción enmascara automáticamente los campos token / password / secret / authorization; la PII completa nunca llega al registro. Los fallos de autenticación emiten una línea WARN con la IP de origen y el motivo, nunca con el contenido del token.

Higiene de dependencias

Las auditorías automatizadas de dependencias se ejecutan en CI; los avisos altos o críticos hacen fallar la compilación. Renovate y Dependabot están habilitados en el manifiesto de dependencias y en el archivo de bloqueo. Cada nueva biblioteca de código abierto pasa por una revisión documentada previa a su adopción (seguridad, mantenimiento, licencia, dependencia excesiva, rendimiento).

Certificaciones y auditorías

La recopilación de evidencias para SOC 2 Type I comienza a través de Vanta en el mes posterior al lanzamiento comercial de Syncanix, con un informe Type I previsto para el T3 2026. SOC 2 Type II le sigue a los ~9 meses. Las evidencias de ISO 27001 se recopilan de forma concurrente (70-80 % de solapamiento de controles con SOC 2); la certificación está prevista para el T4 2026. Estado completo de cumplimiento →

Respuesta a incidentes

La divulgación de vulnerabilidades se envía a admin@syncanix.com —se acusa recibo en un plazo de 24 horas y se clasifica en un plazo de 72 horas. Las brechas confirmadas con impacto en los clientes se notifican a los clientes afectados en un plazo de 24 horas desde la confirmación, conforme al compromiso del Artículo 33 del DPA. Un runbook documentado de respuesta a incidentes se ensaya trimestralmente.