Nuestra postura
Un TMS concentra información sensible: rutas, costos de flete, márgenes, datos de conductores y la posición en vivo de las unidades. Una filtración no es un inconveniente, es un problema competitivo y personal a la vez.
Por eso preferimos una página corta y verificable a una lista larga de promesas. Cada control descrito abajo existe hoy en el producto.
1. Certificaciones
Orqia no tiene certificaciones de seguridad
No estamos certificados en ISO/IEC 27001, SOC 2, PCI DSS ni HIPAA, y no mostramos sellos de ninguna de ellas.
Tampoco decimos «cumplimos con el RGPD» ni «100 % seguro». Una certificación es el resultado de una auditoría independiente con alcance y fecha; exhibirla sin tenerla es una afirmación falsa, y en un proveedor de software es exactamente la clase de señal que debería hacerte desconfiar.
Lo que sí podemos afirmar, y es lo que describe esta página, son los controles concretos que están implementados.
2. Identidad y acceso
Autenticación con tokens firmados
Sesiones con JWT firmados con RS256 (clave asimétrica). El token de acceso vive como máximo una hora; la renovación usa un token separado que rota en cada uso, de modo que un token robado deja de servir en cuanto el titular renueva.
Ambos viajan en cookies httpOnly: el JavaScript de la página no puede leerlos.
Revocación inmediata
Cada token lleva un identificador único que se verifica contra una lista de revocados en Redis en cada petición. Cerrar sesión o revocar un acceso surte efecto de inmediato, no al expirar el token.
Segundo factor obligatorio para roles críticos
TOTP compatible con cualquier aplicación de autenticación. Es exigible para los roles administrativos y de torre de control; la lista concreta es configurable por despliegue.
Contraseñas
Se almacenan con bcrypt, nunca en claro ni con funciones hash obsoletas. Hay política de complejidad mínima y bloqueo temporal tras varios intentos fallidos. El mensaje de error no revela si el correo existe, para no facilitar la enumeración de usuarios.
Control de acceso por rol
Cada acción está asociada a un permiso y se verifica en el servidor, en cada handler. Ocultar un botón en la interfaz no es un control de seguridad; aquí la verificación ocurre donde importa.
3. Aislamiento entre empresas
Orqia es multi-empresa: varias organizaciones comparten la misma instalación. El aislamiento entre ellas es el control más importante del sistema.
Filtro de organización en la aplicación
El identificador de organización se toma siempre del token, nunca de un parámetro que pueda manipular el cliente. Toda consulta filtra por él, y buscar un registro de otra organización devuelve «no encontrado», no un error de permisos que confirme su existencia.
Aislamiento en la base de datos
La base de datos aplica políticas de Row-Level Security de PostgreSQL: aunque una consulta olvidara el filtro, la base no devolvería filas de otra organización. Las peticiones de los usuarios se ejecutan con un rol de base de datos sujeto a esas políticas; los procesos de sistema (inicio de sesión, tareas en segundo plano, webhooks entrantes y seguimiento público) usan un rol aparte, que no es superusuario ni dueño de las tablas.
En producción es obligatorio: la aplicación se niega a arrancar si ese modo no está activo, y el despliegue comprueba que cada tabla con datos de clientes tiene su política y que el rol de la aplicación no puede saltársela.
Verificado con pruebas automatizadas
El aislamiento no se da por supuesto: hay pruebas de integración contra base de datos real que intentan acceder a datos de otra organización y comprueban que se rechaza. Se ejecutan en cada cambio.
4. Cifrado
En tránsito
Todo el tráfico va sobre HTTPS. La cabecera Strict-Transport-Security instruye al navegador a no usar HTTP ni aunque se lo pidan.
De secretos de integración
Los secretos de las integraciones (credenciales de agentes y webhooks) se guardan cifrados con AES-256-GCM, con una clave que vive fuera de la base de datos.
En reposo
Datos personales de contacto, cifrados a nivel de campo. Se guardan cifrados con AES-256-GCM, con una clave que vive fuera de la base de datos. Sin esa clave, una copia de la base no permite leerlos. Son:
- De los conductores: documento de identidad, teléfonos, correo y contacto de emergencia.
- De transportistas, almacenes y clientes: nombre y teléfono de contacto, y el correo en transportistas y almacenes.
- De pedidos y paradas: nombre, teléfono y correo de contacto de quien recibe.
- De los usuarios de la plataforma: teléfono y número de WhatsApp.
- De las pruebas de entrega: el nombre de quien firma.
- De los reclamos: documento, teléfono, domicilio y nombre del representante.
Lo que no se cifra a nivel de campo: los nombres completos y las direcciones (se buscan, se ordenan y se convierten en coordenadas para trazar rutas, y cifrarlos impediría hacerlo), el correo con el que los usuarios inician sesión y los datos operativos de los viajes. A esos los protegen el aislamiento entre empresas y el control de acceso, y el cifrado del disco cuando el proveedor de infraestructura lo ofrezca.
Cifrado del disco: aún sin verificar en la infraestructura elegida
El proveedor de infraestructura es Vultr. Todavía no hemos verificado si el disco de los servidores y las copias de respaldo quedan cifrados en reposo, así que no lo afirmamos. Cuando lo verifiquemos, se publicará aquí qué cifrado aplica.
5. Auditoría y trazabilidad
Registro inmutable
Cada mutación relevante deja constancia de quién, qué, cuándo y con qué resultado. El registro es de solo adición: no se modifica ni se elimina, y las correcciones se registran como hechos nuevos.
Bitácora por parada
Cada cambio de estado de una parada registra el actor, el momento, el motivo de lista controlada y las evidencias. Reconstruir qué pasó en una entrega no depende de la memoria de nadie.
Trazas correlacionadas
Cada petición lleva un identificador de traza que se propaga a los eventos que genera, de modo que un incidente se puede seguir de punta a punta.
6. Protección de las APIs
- Límite de peticiones por usuario y por dirección IP, con límites más estrictos para escritura y para autenticación.
- Idempotencia obligatoria en las operaciones de escritura: un reintento no duplica un viaje ni un movimiento.
- Validación de esquema en el borde: toda entrada se valida antes de procesarse.
- Firma HMAC-SHA256 en los webhooks entrantes, en lugar de tokens en la URL.
- Sin trazas de error en las respuestas de producción: un error devuelve un identificador, no el detalle interno.
7. Seguridad de la aplicación
- Content-Security-Policy con nonce por petición, que corta la ejecución de scripts inyectados.
X-Frame-Options: DENY, que impide incrustar la aplicación en un iframe ajeno (clickjacking).X-Content-Type-Options: nosniffy política de referente restrictiva.- Consultas parametrizadas mediante ORM: no se concatena entrada de usuario en SQL.
- Verificación de tipos y pruebas automatizadas en cada cambio, incluidas pruebas de aislamiento entre organizaciones y de control de acceso.
- Escaneo de secretos y de dependencias en cada cambio: el pipeline revisa que no se hayan subido credenciales y que las dependencias no tengan vulnerabilidades conocidas de severidad media o superior.
8. Qué está pendiente
Esta sección existe porque una página de seguridad que solo enumera aciertos no es informativa. Lo siguiente está identificado y no implementado a la fecha de esta versión:
| Pendiente | Estado |
|---|---|
| Prueba de penetración por un tercero independiente | No realizada |
| Copias de respaldo fuera del servidor y prueba de restauración periódica | Hay una copia diaria automática de la base, conservada 14 días en el mismo servidor. Falta una copia en otro lugar y la prueba de restauración |
| Plan de continuidad y recuperación ante desastres documentado y probado | No documentado |
| Gestión de secretos en un gestor dedicado | Hoy por variables de entorno; migración pendiente |
9. Incidentes
Orqia mantiene un procedimiento de respuesta a incidentes que cubre detección, clasificación, contención, investigación, recuperación, documentación y post-mortem, e incluye la evaluación de si hay datos personales comprometidos.
El Reglamento de la Ley N.º 29733 establece un plazo de 48 horas para notificar determinados incidentes a la Autoridad y, cuando corresponda, a las personas afectadas. Ese deber subsiste aunque el incidente se haya resuelto internamente. Ver la Política de Privacidad.
10. Reportar una vulnerabilidad
Si encuentras un fallo de seguridad, escríbenos a orqia.pe@gmail.com con los pasos para reproducirlo.
Nos comprometemos a acusar recibo, investigarlo, informarte del resultado y no emprender acciones contra quien reporte de buena fe, sin acceder a datos de terceros más allá de lo necesario para demostrar el fallo y sin degradar el servicio.