Política de Seguridad

1. Cifrado y contraseñas

• Todo el tráfico entre tu navegador y LicitaRD va cifrado con TLS, certificado renovado automáticamente (Let's Encrypt) y HSTS activo — no hay ninguna ruta de la plataforma servida por HTTP plano.
• Tu contraseña nunca se guarda en texto plano: se hashea con Argon2id (memoria 64 MiB, 3 iteraciones, 4 hilos — parámetros alineados a la recomendación OWASP 2023).
• Las sesiones usan tokens JWT de corta duración más un refresh token con rotación: cada vez que se usa, se invalida y se emite uno nuevo. Si detectamos que un refresh token ya usado vuelve a presentarse (señal de robo), se revoca toda la familia de tokens de esa sesión y se te pide iniciar sesión de nuevo.
• La base de datos corre con roles segregados en Postgres — el backend nunca opera con el usuario superadministrador de la base de datos.

2. Control de acceso a la infraestructura

El servidor que aloja LicitaRD no tiene el puerto de administración expuesto a internet: el acceso operativo (SSH) solo es posible dentro de una red privada (Tailscale/VPN), nunca desde una IP pública abierta.

• Las credenciales de servicio (claves de API, contraseñas de base de datos, secretos de facturación) viven en archivos con permisos restringidos en el servidor — nunca en el repositorio de código.
• Aplicamos el principio de menor privilegio: cada servicio (API, sincronización, procesador de alertas) usa su propio usuario de base de datos con permisos acotados a lo que necesita.
• El acceso administrativo humano se limita al equipo operador de LicitaRD; no compartimos credenciales de infraestructura con terceros.

3. Respaldos y continuidad

La base de datos se respalda automáticamente todos los días. Mantenemos las copias más recientes en el propio servidor (14 días) y una réplica adicional fuera del servidor principal (30 días), para poder recuperar el servicio si el servidor de producción falla.

Los respaldos contienen datos personales — se tratan con el mismo nivel de acceso restringido que la base de datos en vivo, no quedan copias sueltas fuera de ese ciclo controlado.

4. Monitoreo y detección

Registramos los intentos de acceso a rutas de autenticación (login, cambio de contraseña) y aplicamos límites de tasa (rate limiting) sobre esas rutas para frenar ataques de fuerza bruta y credential stuffing. Los accesos a datos personales quedan en logs de auditoría, como exige la Ley 172-13.

5. Reportar una vulnerabilidad

Si encontraste un problema de seguridad en LicitaRD — una fuga de datos, un bypass de autenticación, una forma de ver información que no te corresponde — te pedimos que nos escribas antes de publicarlo en cualquier otro lado: security@licitard.com.

Confirmamos recepción en un plazo de 72 horas y te mantenemos informado del progreso hasta que quede corregido. Hoy no operamos un programa formal de recompensas (bug bounty), pero reconocemos públicamente — con tu permiso — a quien reporte de buena fe una vulnerabilidad real.

6. Qué hacemos ante un incidente

Si ocurre un incidente de seguridad que afecte datos personales, seguimos este proceso:

1. Detectar — vía monitoreo interno o un reporte externo.
2. Contener — pausamos o aislamos el servicio afectado para frenar el impacto.
3. Documentar — registramos qué pasó, qué datos estuvieron expuestos y a cuántos usuarios afecta.
4. Corregir — cerramos la causa raíz, no solo el síntoma.
5. Post-mortem — revisamos qué falló en el proceso para que no se repita.

Si el incidente afecta tus datos personales, te lo notificamos en un plazo no mayor a 72 horas desde que lo confirmamos, como se establece en nuestra Política de Privacidad.

7. Lo que todavía no tenemos

Somos una plataforma en crecimiento y preferimos decirte con qué no contamos hoy antes que dejarte asumirlo:

• No tenemos certificación formal ISO 27001, SOC 2 ni una auditoría de penetración externa contratada de forma recurrente todavía — es parte de nuestra hoja de ruta a medida que crecemos.
• La infraestructura corre sobre un proveedor de hosting único (sin redundancia activa entre múltiples regiones o proveedores). Mitigamos ese riesgo con respaldos diarios fuera del servidor principal, no con failover automático.
• No operamos todavía un programa formal de recompensas por vulnerabilidades.

8. Contacto