Cómo protegemos tus datos en TimeFlow
Documento informativo para clientes · Nuxo · Julio 2026
En Nuxo entendemos que al usar TimeFlow nos confías información valiosa de tu empresa: tu equipo, tus proyectos, tus horas trabajadas. Este documento explica, en lenguaje claro, cómo aseguramos esos datos, qué pasa si algo falla y cuál es nuestra política de acceso a tu información.
1. Cómo está construida la plataforma
TimeFlow funciona sobre un servidor privado dedicado exclusivamente a la plataforma. Toda la información se almacena en PostgreSQL 16, el motor de bases de datos relacional de código abierto usado por bancos, gobiernos y plataformas de misión crítica en todo el mundo. Y lo más importante de nuestro diseño: cada cliente tiene su propia base de datos PostgreSQL, física e independiente. No usamos una base de datos gigante compartida donde los datos de todos los clientes conviven mezclados y separados solo por filtros de software.
Tu equipo ── conexión cifrada (HTTPS / TLS 1.3) ──▶ TimeFlow
│
┌─────────────────────────────┴──────┐
│ PostgreSQL 16 │
│ 🔒 Base de datos — Tu empresa │
│ 🔒 Base de datos — Cliente B │
│ 🔒 Base de datos — Cliente C │
└────────────────────────────────────┘Piensa en ello como bóvedas separadas dentro del mismo edificio, cada una con su propia puerta, en lugar de un solo salón con los archivos de todos. Este diseño hace que mezclar datos de dos clientes por accidente sea estructuralmente imposible, no solo improbable.
2. Las capas de protección
2.1 El servidor y la red
Nosotros aseguramos el servidor con varias barreras acumuladas:
- La base de datos no está conectada a internet. PostgreSQL escucha únicamente en la interfaz interna del servidor (
127.0.0.1): solo los programas que corren dentro del propio servidor pueden hablar con ella. Además, el firewall (UFW) bloquea todo el tráfico entrante salvo el web cifrado (puertos 80/443) y un acceso administrativo restringido. - Toda la comunicación viaja cifrada con TLS. Precisión técnica, porque los términos suelen mezclarse: HTTPS es el protocolo web sobre TLS, el sucesor moderno de SSL (las versiones SSL y TLS 1.0/1.1, ya obsoletas e inseguras, están deshabilitadas). Nuestros servidores aceptan únicamente TLS 1.2 y TLS 1.3; una conexión típica desde tu navegador negocia TLS 1.3 con la suite de cifrado
TLS_AES_256_GCM_SHA384(cifrado simétrico AES-256 en modo GCM, con integridad SHA-384) y certificados ECDSA P-256 emitidos por Let's Encrypt, renovados automáticamente antes de expirar. Es el mismo nivel de cifrado de canal que usa la banca en línea. - Cabeceras de seguridad HTTP. Todas las respuestas de la plataforma incluyen las cabeceras de protección estándar del ecosistema web (vía Helmet): HSTS para forzar HTTPS, y protecciones contra clickjacking, sniffing de contenido y otros ataques del navegador.
- Principio de mínimo privilegio. Los componentes de la plataforma corren con usuarios de permisos limitados, no como administrador (root), de modo que un fallo en una pieza no compromete el resto.
- Las credenciales y llaves del sistema se guardan protegidas en el servidor, fuera del código fuente y con permisos de lectura restringidos al mínimo.
2.2 Quién puede entrar: autenticación en dos etapas
Para llegar a los datos de tu empresa, cada persona de tu equipo pasa por dos verificaciones consecutivas:
- Verificación de identidad con la infraestructura de identidad de Google (Firebase Authentication): la cuenta debe existir, la contraseña ser correcta y el correo estar verificado. Las contraseñas nunca se almacenan en nuestros servidores: las custodia Google con hashing scrypt (no se guardan en claro ni de forma reversible), y la identidad se acredita ante TimeFlow mediante tokens firmados por Google con RSA-SHA256 (RS256), cuya validez y posible revocación se comprueban en cada uso.
- Verificación de membresía: comprobamos que esa persona pertenece a tu organización y con qué rol (administrador, gestor o colaborador). Solo entonces se emite un pase de sesión temporal — un JWT firmado con HMAC-SHA256 (HS256), con emisor, audiencia y algoritmo fijados para impedir tokens falsificados o reutilizados — que caduca a las 12 horas.
Además, la plataforma re-verifica continuamente ese pase contra tu lista de usuarios: si desactivas a alguien de tu equipo, pierde el acceso en cuestión de segundos — no cuando le caduque la sesión. A esto se suman límites automáticos contra intentos de adivinación de contraseñas (rate limiting: máximo 120 peticiones por minuto por dirección IP, con límites aún más estrictos en el inicio de sesión) y validación estricta de todo dato que entra al sistema.
2.3 Tus datos nunca se mezclan con los de otros clientes
Como cada cliente tiene su propia base de datos, la separación no depende de que un programador recuerde poner un filtro en cada consulta: la sesión de cada usuario está ligada criptográficamente a la base de datos de su empresa, y es la única a la que el sistema puede dirigir sus operaciones. Un usuario de otra empresa no puede ver tus datos ni por error ni por manipulación de su sesión, porque su "llave" simplemente no abre tu bóveda.
Este aislamiento también aplica a las copias de seguridad y a los procesos automáticos (recordatorios, notificaciones): cada uno opera bóveda por bóveda.
2.4 Resumen: riesgo → protección
| Riesgo | Cómo lo prevenimos |
|---|---|
| Alguien intenta conectarse a la base de datos desde internet | Imposible: la base de datos no tiene puerta hacia internet |
| Un cliente ve datos de otro | Bases de datos físicamente separadas + sesión ligada a tu empresa |
| Un exempleado tuyo conserva su sesión activa | Re-verificación continua: al desactivarlo, pierde acceso en segundos |
| Robo de contraseñas por fuerza bruta | Límites automáticos de intentos por dirección y por cuenta |
| Interceptación de datos en tránsito | Canal cifrado con TLS 1.2/1.3 (AES-256-GCM), certificados Let's Encrypt |
| Manipulación de pagos | Verificación criptográfica de cada evento con Stripe (nunca almacenamos tarjetas) |
| Configuración insegura tras una actualización | La plataforma se niega a arrancar si detecta configuración incompleta o débil |
3. ¿Qué pasa si el servidor falla? Copias de seguridad
Una caída temporal del servidor (un reinicio, un corte breve) no borra datos: la base de datos está diseñada para ser durable y la plataforma se recupera sola. El servicio puede estar indisponible unos minutos, pero tu información permanece intacta.
Para los escenarios realmente graves —daño del disco, pérdida del servidor, un borrado accidental— mantenemos copias de seguridad automáticas diarias de cada base de datos, incluida la tuya. Cada copia se verifica tras crearse (comprobamos que es restaurable, no solo que existe), se conserva un histórico de dos semanas y replicamos las copias fuera del servidor principal, de modo que ni siquiera la pérdida total del servidor implicaría la pérdida de tus datos. En el peor escenario, el máximo de información en riesgo sería lo registrado desde la última copia diaria.
4. Cifrado de doble llave y acceso a tus datos: nuestra posición
Por qué un cifrado de doble llave es inviable en una plataforma que calcula por ti
TimeFlow no es un archivador pasivo: calcula horas, cierra y aprueba semanas, genera reportes y envía recordatorios automáticamente y de forma continua. Para hacer cada una de esas operaciones, el sistema necesita leer tus datos constantemente — cada minuto del día, sin que nadie de tu equipo esté conectado.
Un cifrado de doble llave (una llave tuya y una nuestra, ambas necesarias para abrir los datos) es incompatible con ese funcionamiento, y no por una limitación de NUXO: es inviable para cualquier sistema que calcule y reporte automáticamente por el usuario. Si los datos estuvieran sellados bajo dos llaves, cada cálculo y cada reporte exigiría tener ambas llaves presentes en todo momento — es decir, la "bóveda de doble llave" tendría que permanecer abierta de forma permanente, lo que equivale a no tenerla. Y la variante extrema, el cifrado de extremo a extremo (los datos se cifran en tu navegador y el servidor solo ve información ilegible), directamente rompe el producto: ninguna función automática podría ejecutarse y TimeFlow quedaría reducido a un archivador de datos que ni siquiera él mismo puede leer.
Esta es una propiedad estructural de este tipo de software, no una decisión comercial: cualquier proveedor que calcule y reporte por ti y a la vez prometa "ni nosotros podemos leer tus datos" está prometiendo algo que técnicamente no cumple.
Quién puede acceder a tus datos, y bajo qué reglas
Con la misma transparencia: como en prácticamente todo software en la nube (CRMs, ERPs, herramientas de RR. HH.), nuestro equipo técnico administra el servidor y por tanto tiene la capacidad técnica de consultar las bases de datos mediante consultas SQL directas. Sobre esa realidad, nuestra política es estricta y verificable:
- NUXO no tiene ni tendrá portales personalizados para visualizar los datos de los clientes. No existe —ni existirá— panel, visor ni herramienta interna alguna que muestre tu información a nadie de nuestro equipo. La única vía técnica posible es el acceso administrativo manual al servidor.
- Un procedimiento de doble control auditado es la única vía de acceso administrativo: todo acceso requiere una justificación previa (soporte solicitado por ti, un incidente, una obligación legal), la aprobación de una segunda persona y queda registrado. Nadie accede a tus datos sin un procedimiento de doble control auditado.
En resumen: en lugar de prometer un cifrado imposible de cumplir, garantizamos lo que sí se cumple al 100 % — aislamiento real por cliente, canal cifrado con TLS 1.2/1.3, copias de seguridad verificadas, cero portales de visualización de datos, y doble control auditado como única vía de acceso administrativo.
5. Nuestros compromisos contigo
- Tu empresa tiene su propia base de datos, aislada de cualquier otro cliente.
- Tus datos viajan siempre cifrados y la base de datos no es accesible desde internet.
- Hacemos copias de seguridad diarias y verificadas, con réplica fuera del servidor principal.
- No existe ni existirá un portal para visualizar datos de clientes; el acceso administrativo es excepcional, justificado, aprobado por dos personas y registrado.
- Si desactivas a un usuario, pierde el acceso en segundos.
- Ante cualquier duda sobre seguridad o privacidad, tienes un canal directo con nosotros y te responderemos con la misma transparencia de este documento.