Alcance
Este resumen cubre la aplicación NEXEFII y sus módulos operados directamente, incluidos NEXE Store, Master Control y el asistente Smartbot, en la medida en que forman parte de la misma plataforma.
No describe la postura de seguridad de sistemas de terceros, de integraciones contratadas por clientes, ni de entornos fuera del control directo de NEXEFII. Los procesadores externos, como el procesador de pagos, se rigen por sus propios términos y controles.
Autenticación y control de acceso
La plataforma ofrece autenticación multifactor (MFA) y adopta control de acceso basado en roles (RBAC). Los roles de organización disponibles son propietario (owner), administrador (admin), gerente (manager), miembro (member) y visor (viewer), con permisos diferenciados por rol.
Las decisiones de acceso se evalúan de forma restrictiva (fail-closed): una configuración inválida o insuficiente resulta en denegación, no en una concesión silenciosa.
Aislamiento entre organizaciones (multi-tenant)
La plataforma es multi-tenant y los datos están delimitados por organización (tenant). La intención del diseño es que los datos de una organización no sean accesibles por otra.
Este aislamiento es un control central de la arquitectura, aplicado de forma consistente a las operaciones de lectura y escritura de los módulos.
Seguridad de sesión
Las sesiones tienen expiración por inactividad (aproximadamente 45 minutos), con aviso previo y cuenta regresiva antes del cierre, además de un tiempo de vida absoluto de la sesión (aproximadamente 24 horas).
Existe sincronización entre pestañas del navegador y la capacidad de revocar sesiones del lado del servidor, permitiendo finalizar el acceso de forma centralizada cuando sea necesario.
Cookies, transporte y cabeceras de seguridad
Las cookies de autenticación se marcan como HttpOnly y Secure. Los tokens de sesión se firman con un único algoritmo fijo, y la configuración débil se rechaza de forma restrictiva (fail-closed).
El tráfico se protege en tránsito mediante TLS/HTTPS. No se afirma aquí el cifrado de datos en reposo; los datos se alojan en infraestructura de nube gestionada y los detalles de reposo se remiten a revisión.
El intercambio de recursos de origen cruzado (CORS) se restringe a una lista de orígenes permitidos explícita. Se aplican cabeceras de respuesta de seguridad.
Controles preparados, aún no impuestos
La Política de Seguridad de Contenido (Content-Security-Policy) está actualmente en modo solo-informe (report-only): supervisa e informa, pero aún NO se impone como bloqueo. Lo indicamos de forma honesta para no sugerir una protección que aún no está en vigor.
Las protecciones contra CSRF están preparadas, pero aún no se imponen de forma generalizada. Ninguno de estos controles preparados debe leerse como ya activo en modo de bloqueo.
Auditoría y verificación continua del pipeline
Las acciones administrativas sensibles se registran en trazas de auditoría inmutables, apoyando la trazabilidad y la rendición de cuentas.
El pipeline de desarrollo incluye escaneo automatizado de secretos y escaneo automatizado de vulnerabilidades en dependencias, como parte de la higiene continua de seguridad.
Limitaciones y lo que no afirmamos
Ningún sistema es perfectamente seguro. No afirmamos ausencia de incidentes, seguridad absoluta, invulnerabilidad, ni ningún nivel de protección que no podamos sostener honestamente.
En este momento no reivindicamos ninguna certificación de conformidad (por ejemplo, SOC 2, ISO 27001, PCI DSS). Cualquier certificación futura solo se mencionará una vez efectivamente obtenida y verificable.
Algunos detalles de seguridad no se divulgan públicamente por razones de seguridad.
Divulgación responsable
Si identifica una posible vulnerabilidad de seguridad, le pedimos que la informe de forma responsable, sin explotación más allá de lo necesario para demostrarla, a través del contacto de seguridad: contact@nexefii.com.
Nos comprometemos a analizar los informes recibidos de buena fe; el tratamiento formal y los plazos se rigen por nuestra política de divulgación responsable.
Última revisión
Última revisión editorial registrada el 2026-07-11. Este resumen se revisa periódicamente y puede actualizarse a medida que los controles evolucionan.
Postura de acceso de soporte
NEXEFII no mantiene acceso permanente ni continuo al entorno de ningún cliente. No hay inicio de sesión con credenciales compartidas del cliente y ningún operador utiliza la contraseña del cliente. Cuando se requiere soporte remoto, el acceso ocurre únicamente con la autorización explícita del cliente.
El acceso de soporte está diseñado para ser nominativo (vinculado a un usuario de soporte identificado), temporal (con un plazo de expiración), delimitado al tenant del cliente, de privilegio mínimo, de solo lectura por defecto (con escritura solo cuando sea necesario y esté autorizado), protegido por MFA, vinculado a una justificación o ticket, revocable por el cliente y registrado en una traza de auditoría (inicio, fin y acciones relevantes).
Un mecanismo de aprovisionamiento just-in-time (JIT), con elevación temporal limitada por tiempo, se describe solo como una mejora futura y aún NO está implementado. Hasta entonces, el acceso sigue el procedimiento nominativo y transitorio realizado por el propio cliente. Las consultas sobre la postura de acceso de soporte pueden dirigirse a contact@nexefii.com.