Los datos del núcleo de su negocio, cifrados dos veces, con primitivos que un computador cuántico no rompe.
Las organizaciones corren sobre Dexon BPM sus procesos más sensibles: fiscalización tributaria, cuentas médicas, aprobación de créditos, expedientes ciudadanos. Esta página describe cómo se protege esa información, en el lenguaje que un área de seguridad usa para evaluar a un tercero.
Cifrado en tránsito
Dos capas, no una
TLS protege el canal. Pero TLS se termina: en balanceadores, en proxies corporativos, en dispositivos de inspección. Dexon BPM añade una segunda capa que sobrevive a esa terminación.
Capa 1 — TLS 1.3
Solo HTTPS, en todos los extremos: la API rechaza el tráfico sin TLS. TLS 1.3 preferido, con la versión mínima fijada por política en cada extremo y verificada en cada despliegue, y HSTS.
Capa 2 — AES-256 a nivel de aplicación →
Cada cuerpo de petición y respuesta entre el navegador y la API viaja además cifrado con AES-256, bajo claves derivadas por sesión con PBKDF2 y SHA-512, con material aleatorio nuevo por mensaje. Cada mensaje lleva además autenticación criptográfica que se verifica antes de descifrar: un mensaje alterado o falsificado se rechaza, nunca se procesa. Donde el TLS se inspecciona, el inspector ve la envolvente, no el dato de negocio.
También antes del login
Las credenciales y el propio token de sesión nunca viajan en claro, ni siquiera dentro de TLS. El intercambio previo a la autenticación va cifrado bajo una credencial propia de cada consumidor de integración, generada por el administrador del cliente y revocable sin afectar a las demás: Dexon no custodia esos secretos.
Cifrado en reposo
Por columna, dentro de la base de datos
Sobre el cifrado de plataforma del hosting (cifrado transparente de datos y de almacenamiento en Azure, o el que el cliente disponga on-premises), Dexon BPM cifra con AES-256 a nivel de columna las categorías de datos designadas: la configuración de la plataforma, las credenciales de las integraciones y los campos de negocio que el cliente o el producto clasifican como confidenciales — incluida la bitácora de eventos de cada caso.
Un actor con acceso de solo lectura a la base de datos —un DBA, un respaldo exfiltrado, un disco copiado— no obtiene esos contenidos en claro. Las llaves de cifrado no se almacenan junto a los datos. Y se protege la integridad, no solo la confidencialidad: cada valor cifrado y cada documento almacenado lleva autenticación criptográfica, de modo que un dato alterado o falsificado se rechaza antes de procesarse.
Cadena de suministro
Código firmado, dependencias gestionadas
Resistencia cuántica
Qué significa aquí «resistente a la computación cuántica», con precisión
La amenaza relevante hoy es harvest now, decrypt later: capturar tráfico o respaldos cifrados ahora para descifrarlos cuando exista un computador cuántico criptográficamente relevante. Lo que ese computador rompe (algoritmo de Shor) es la criptografía asimétrica clásica: RSA, curvas elípticas. Lo que no rompe en ningún sentido práctico son los primitivos simétricos: el algoritmo de Grover reduce AES-256 a unos 128 bits de fuerza post-cuántica, todavía inviable, y SHA-512 conserva márgenes amplios.
Las dos capas de cifrado propias de Dexon BPM —el cifrado de aplicación de los payloads y el cifrado por columna en reposo— usan exclusivamente primitivos simétricos: AES-256, SHA-512, PBKDF2, los que la CNSA 2.0 de la NSA mantiene como resistentes a la computación cuántica. Sus claves se derivan de secretos compartidos y nunca viajan por un intercambio asimétrico. El dato de negocio capturado hoy en esas capas no queda, por tanto, expuesto a un descifrado cuántico futuro.
Dexon BPM ofrece confidencialidad resistente a la computación cuántica del dato de negocio en tránsito y en reposo, a través de sus capas de cifrado propias — que usan solo primitivos simétricos alineados con CNSA 2.0.
Identidad y aislamiento
La plataforma vive en su tenant, no en el nuestro
SSO con Microsoft Entra ID
El registro de aplicación lo crea y gobierna el administrador del propio cliente, en el tenant del cliente. Sus políticas de MFA, acceso condicional, riesgo de inicio de sesión y revocación aplican íntegras. Dexon no posee credenciales de su tenant.
Acceso local endurecido
Las cuentas locales tienen una política de contraseñas robusta —12 caracteres o más con complejidad, rechazo de contraseñas comunes o que contengan el usuario, y cambio obligatorio al ingresar— cuya longitud mínima sube hasta la de su propia política; hash irreversible con sal; segundo factor TOTP propio; reto anti-robot en cada ingreso; intentos de ingreso con límite de frecuencia y cada fallo registrado; sesión única por usuario; y cierre por inactividad con aviso previo y extensión en un clic.
Denegación por defecto →
Cada pantalla y cada función de la API exigen un permiso explícito del perfil del usuario; lo no concedido no se muestra ni se ejecuta, y un permiso retirado surte efecto de inmediato. Cada documento exige además su propia regla: técnico asignado, autor, nivel de acceso. Los enlaces de un solo uso enviados por correo abren solo su propio registro, y los enlaces a archivos vencen. El acceso a datos puede acotarse por compañía, categoría o grupo, evaluado en el servidor, con rastro de cada bloqueo.
Un cliente, una base de datos →
En el modelo SaaS cada cliente recibe un par dedicado de aplicaciones y su propia base de datos. El aislamiento no depende de un discriminador de tenant en tablas compartidas. On-premises, Dexon no tiene acceso permanente.
Integraciones con alcance mínimo →
Correo de Microsoft 365 por Microsoft Graph con autenticación moderna app-only, listo para el retiro de EWS, con el acceso acotado a los buzones de la mesa —por RBAC for Applications, sin permiso de correo sobre el tenant— y verificable por su área de seguridad. Correo saliente firmado con el certificado de la organización y cifrado para cada destinatario (S/MIME). Bot de Teams single-tenant bajo su propia identidad, disponible desde noviembre de 2026. Webhooks con firma.
Una auditoría que su SIEM puede leer →
Los eventos de seguridad —ingresos correctos y rechazados con su causa, funciones no concedidas, cambios de contraseña— y las tablas de auditoría de la plataforma se envían a su SIEM como registros estructurados CEF o JSON, por syslog o a un archivo —listos para Microsoft Sentinel, Splunk, QRadar o ArcSight—, sin contraseñas, tokens ni direcciones de destinatarios. En la plataforma, una sola consulta audita a cada usuario —sesiones, cambios, documentos consultados, control remoto y lectura de registros sensibles— con un permiso propio, separado de la administración; los registros críticos guardan cada versión con el valor anterior y el nuevo.
Documentos cifrados antes de salir →
En Azure Blob Storage, los documentos se comprimen y se cifran en la aplicación —AES-256 con autenticación HMAC-SHA512 y una llave propia de cada despliegue—, de modo que ni el nombre del archivo ni su contenido son legibles en el almacenamiento, y cada ambiente usa su propio contenedor con un acceso acotado a él. Los documentos que se guardan en el disco del propio servidor quedan sellados con el mismo sobre, y los archivos anteriores se re-sellan de fondo, verificando cada copia antes de reemplazar el original.
Agentes de IA con sus permisos →
Los agentes descubren las herramientas de la plataforma con su esquema; cada argumento se valida, cada herramienta exige el mismo permiso que la pantalla que la respalda, y toda llamada —incluidas las rechazadas— queda auditada. Microsoft 365 Copilot, Claude o sus propios agentes se conectan por MCP con la identidad de Entra ID de cada persona, nunca con una cuenta de servicio.
Validación
Pruébelo usted mismo
Dexon pone a disposición un marco de validación de seguridad alineado a OWASP Top 10:2025, OWASP API Security Top 10:2023, ASVS 5.0 y WSTG, con proceso NIST SP 800-115 y mapeo a NIST SP 800-53 Rev. 5 y CSF 2.0 — con checklist accionable y plan de pentest activo. Los clientes ejecutan pruebas autorizadas bajo reglas de enfrentamiento, con credenciales de prueba y entorno de staging.
Los hallazgos de pentests contratados por clientes se gestionan con severidad CVSS y remediación priorizada. Los cuestionarios de seguridad de terceros —SIG, CAIQ, los propios del cliente— se atienden bajo NDA.
Lo certificado es la madurez de procesos de la plataforma: PinkVERIFY en 12 procesos ITSM.
Pida el documento que su área de seguridad va a querer
La postura de seguridad completa —arquitectura, resumen criptográfico, controles de las integraciones y el mapeo a NIST CSF 2.0— está disponible bajo NDA. Escriba a security@dexon.us, o traiga su cuestionario.