Prácticas de seguridad

Los campos sensibles almacenados en la base de datos de la plataforma se cifran con AES-256-GCM antes de escribirse en el disco.

Qué	Cómo
Claves API de la cuenta (Anthropic, OpenAI-compat., SMTP)	AES-256-GCM, MASTER_ENCRYPTION_KEY
Hashes de contraseña de usuario	bcrypt (cost 12)
Credenciales de canal IMAP / correo electrónico	AES-256-GCM, MASTER_ENCRYPTION_KEY
Archivos de base de datos en disco	Los campos sensibles se cifran a nivel de aplicación antes del almacenamiento (AES-256-GCM, AAD por cuenta, claves en HashiCorp Vault).

• Todos los endpoints públicos se sirven solo sobre HTTPS; HTTP se redirige a HTTPS (encabezado HSTS de Apache).
• Versiones de TLS admitidas: TLS 1.2 y 1.3 (TLS 1.0 / 1.1 deshabilitado).
• El widget widget.js se sirve con Access-Control-Allow-Origin: * pero los endpoints de API de chat validan widget_key + lista de orígenes permitidos.
• Las llamadas internas entre servicios (Redis, MySQL en localhost) se comunican a través de la interfaz loopback. Ningún dato sale del host sin encriptar.

El siguiente programa de copia de seguridad se aplica a la base de datos de la plataforma y a las bases de datos de cuentas:

Elemento	Frecuencia	Retención	Ubicación
Platform DB (einstein_saas_platform)	Diariamente, por la noche (UTC, automatizado)	7 días en local; copia cifrada en Francia hasta 3 semanas	Volumen local + réplica externa cifrada
DBs de cuentas (einstein_saas_tenant_*)	Diariamente, por la noche (UTC, automatizado)	7 días en local; copia cifrada en Francia hasta 3 semanas	Volumen local + réplica externa cifrada
Archivos cargados / almacenamiento de documentos	Diariamente, por la noche (UTC, automatizado)	Copia cifrada en Francia, aproximadamente un mes	Volumen local + réplica externa cifrada

Las copias de seguridad se ejecutan por base de datos mediante mysqldump --single-transaction, se almacenan comprimidas y cifradas con age, se copian cada día, cifradas de nuevo, a un centro de datos en Francia, en un lugar distinto de nuestros servidores, y cada ejecución se verifica para detectar un volcado no vacío y se registra con estado de éxito/fallo.

Los archivos de copia de seguridad se cifran en reposo con age (X25519 / ChaCha20-Poly1305); la clave de descifrado se guarda por separado de los archivos. Los campos protegidos con cifrado a nivel de columna (AES-256-GCM) permanecen cifrados dentro de cada archivo. La recuperabilidad se verifica mediante una prueba de restauración mensual automatizada.

4.1 Control de acceso basado en roles (RBAC)

Cada usuario del portal recibe un rol. Los roles contienen permisos separados por área. La plataforma comprueba los permisos en el servidor.

4.2 Autenticación de dos factores

• 2FA mediante una app de autenticación (TOTP, RFC 6238 — por ejemplo Google Authenticator o Authy) o mediante un código por correo. Cada usuario la activa en la configuración de su cuenta.
• Cuando la 2FA está activada, la plataforma pide el segundo paso en cada inicio de sesión.
• No hay códigos de recuperación. Quien elige el código por correo no necesita una app aparte.

4.3 Aislamiento de cuentas

La autenticación requiere un contexto de cuenta (inicio de sesión basado en slug). Los tokens de sesión se limitan a una sola cuenta. El acceso a recursos entre cuentas se previene en la capa de aplicación mediante filtros tenant_id obligatorios en las consultas a la base de datos.

Las acciones significativas realizadas en recursos de la plataforma se registran en la tabla audit_log (base de datos de plataforma). Cada entrada captura:

• Actor: ID de usuario, rol e ID de cuenta.
• Acción: verbo (crear, actualizar, eliminar, iniciar sesión, exportar, …).
• Recurso: tipo de entidad e ID.
• Metadatos: nombres de campos modificados y valores antiguos/nuevos (campos sensibles redactados).
• Marca de tiempo: almacenada en UTC (ISO 8601).
• Dirección IP: IP de origen de la solicitud.

Las entradas del registro de auditoría se conservan dos años y después se eliminan automáticamente, también si la cuenta terminó antes. La prueba de que se ejecutó una solicitud de supresión se elimina automáticamente a los 12 meses. El registro es de solo anexado (append-only) a nivel de aplicación.

Las entradas de auditoría las escribe el usuario de base de datos habitual de la aplicación. Un usuario de base de datos independiente de solo inserción solo está configurado para el registro de auditoría de la API de revendedores.

6.1 Monitoreo de CVE

Revisamos las dependencias de Composer con composer audit. Las vulnerabilidades críticas en dependencias de tiempo de ejecución se tratan con prioridad.

6.2 Ciclo de parches

• Actualizaciones de seguridad del sistema operativo: se instalan automáticamente cada día (unattended-upgrades).
• Tiempo de ejecución PHP: PHP 8.5, actualizado con parches de seguridad.
• Servidor web: Apache 2.4.x — mantenido actualizado con las actualizaciones de seguridad de la distribución.

6.3 Divulgación responsable

Los investigadores de seguridad externos están invitados a reportar vulnerabilidades bajo nuestra política de divulgación coordinada. Leer la política de divulgación responsable →

Componente	Detalle
Región de alojamiento	UE — Países Bajos (base de datos), Francia (archivos y copias de seguridad)
Servidor web	Apache 2.4 (mod_rewrite, mod_ssl)
Runtime	PHP 8.5
Base de datos	MySQL / MariaDB (platform + per-tenant)
Caché / sesiones	Redis (loopback, password-protected)
Transferencias de datos transfronterizas	El procesamiento de IA puede realizarse fuera de la UE, por ejemplo en Estados Unidos, salvo que EU-only esté activado (desde Plus). Te indicamos a petición qué proveedores de IA utilizamos.