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 tenant (Anthropic, OpenAI-compat., SMTP)	AES-256-GCM, MASTER_ENCRYPTION_KEY
Hashes de contraseña de usuario	bcrypt (cost 12)
Cadenas de conexión BYOD	AES-256-GCM, MASTER_ENCRYPTION_KEY
Credenciales de canal IMAP / correo electrónico	AES-256-GCM, MASTER_ENCRYPTION_KEY
Archivos de base de datos en disco	Espacio de tabla MySQL InnoDB en volumen cifrado TODO: confirm full-disk encryption status with ops

• Todos los endpoints públicos se sirven solo sobre HTTPS; HTTP se redirige a HTTPS (encabezado HSTS de Apache).
• Versión mínima de TLS: TLS 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 tenant:

Elemento	Frecuencia	Retención	Ubicación
Platform DB (einstein_saas_platform)	Diariamente, por la noche (UTC, automatizado)	7 copias de seguridad diarias (rotativas)	Volumen local + réplica externa cifrada
Tenant DBs (einstein_saas_tenant_*)	Diariamente, por la noche (UTC, automatizado)	7 copias de seguridad diarias (rotativas)	Volumen local + réplica externa cifrada
Archivos cargados / almacenamiento de documentos	Diariamente, por la noche (UTC, automatizado)	7 copias de seguridad diarias (rotativas)	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 replican a un volumen externo independiente, 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 asignado. Los roles tienen permisos granulares (51+ banderas individuales). La plataforma aplica controles de permisos del lado del servidor en cada endpoint API.

4.2 Autenticación de dos factores

• 2FA vía TOTP (RFC 6238 — Google Authenticator, Authy, etc.) es obligatorio para el rol de propietario y se aplica en el inicio de sesión.
• Los propietarios de cuentas pueden forzar 2FA para todos los miembros del equipo a través del panel de configuración.
• Los códigos de recuperación de respaldo se generan en la inscripción y deben ser almacenados de forma segura por el usuario.

4.3 Aislamiento de tenant

La autenticación requiere un contexto de tenant (inicio de sesión basado en slug). Los tokens de sesión se limitan a un solo tenant. El acceso a recursos entre tenants se previene en la capa de aplicación mediante filtros tenant_id obligatorios en todas las consultas.

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 tenant.
• 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 retienen durante 2 años. El registro es de solo añadir a nivel de aplicación.

Se utiliza un usuario de base de datos dedicado de solo inserción (einstein_audit_writer) para escrituras de auditoría, lo que previene la modificación o eliminación de entradas de registro por el usuario de base de datos de aplicación.

6.1 Monitoreo de CVE

Las dependencias de Composer se supervisan mediante composer audit en cada ejecución de pipeline de implementación. Los CVE críticos en dependencias de tiempo de ejecución desencadenan un parche fuera de banda dentro de 72 horas de la publicación. TODO: confirm SLA with ops

6.2 Ciclo de parches

• Parches de seguridad del SO: aplicados durante la ventana de mantenimiento semanal. TODO: confirm window day/time with ops
• Tiempo de ejecución PHP: mantenido en la última versión secundaria estable de la rama activa (actualmente PHP 8.2.x).
• 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
Servidor de producción	dev01-aionized (Ubuntu)
Servidor web	Apache 2.4 (mod_rewrite, mod_ssl)
Runtime	PHP 8.2+
Base de datos	MySQL / MariaDB (platform + per-tenant)
Caché / sesiones	Redis (loopback, password-protected)
Transferencias de datos transfronterizas	Ninguna por defecto. Las llamadas opcionales de AI en la nube (Anthropic/OpenAI-compat.) están controladas por consentimiento del usuario y cubiertas por Cláusulas Contractuales Tipo.