Cómo manejamos tus datos

Todo el tráfico hacia nuestros servicios viaja por HTTPS con certificados TLS 1.3 renovados automáticamente. No aceptamos conexiones sin cifrar.

• TLS 1.3 en todos los dominios públicos
• HSTS habilitado con max-age extendido
• Renovación automática de certificados (Let's Encrypt + Cloudflare)

Cada cliente es un tenant lógico con Row-Level Security (RLS) de PostgreSQL. Aunque todos los datos viven en la misma base, ninguna query cruza los límites de tenant — enforced a nivel de motor de base de datos, no a nivel de aplicación.

• Políticas RLS en todas las tablas con tenant_id
• Conexiones siempre seteadas con app.tenant_id por sesión
• Auditoría de accesos cruzados por super_admin

Ningún secreto se guarda en código. Los tokens sensibles (API keys de pasarelas, credenciales DIAN) se almacenan cifrados con Fernet antes de tocar la base de datos.

• Archivos .env con chmod 600 en disco
• Token encryption con librería cryptography (Fernet/AES-128)
• Rotación documentada en runbooks internos

VPS dedicado en Alemania (Hetzner), acceso SSH en puerto no-estándar con llave pública únicamente. Fail2Ban bloquea IPs con intentos maliciosos. Docker Socket Proxy limita superficie de ataque de agentes automatizados.

• SSH sin password, llave ED25519
• Fail2Ban activo (jails sshd + nginx-proxy-manager)
• Firewall iptables + UFW con default deny

Respaldos automáticos diarios de todas las bases de datos. Los snapshots se sincronizan a almacenamiento offsite (Cloudflare R2) con retención de 30 días. Restauración probada mensualmente.

• Backups diarios a las 02:00 COT (10 bases de datos)
• Sincronización offsite a Cloudflare R2 a las 04:00
• Retención 30 días, inmutabilidad por object lock

Uptime Kuma monitorea cada servicio crítico cada 60s. Alertas Telegram al operador cuando algo falla. Dashboard público de estado disponible para cualquiera.

• Healthchecks por servicio (cada 60s)
• Alertas Telegram en tiempo real
• Status page público 24/7

Cada operación crítica (cambio de plan, emisión de factura DIAN, eliminación de usuario) queda registrada en audit_logs con user_id + timestamp + contexto. Los agentes automatizados tienen política human-in-the-loop para acciones destructivas.

• Tabla audit_logs con trazabilidad completa
• Firmado HMAC-SHA256 en callbacks de aprobación
• Dry-run por defecto en runbooks destructivos