POLÍTICA DE SEGURIDAD DE SESIONES
Versión: CO-2026.10.02-SESS1
Fecha de vigencia: 2 de octubre de 2026
Responsable: DataCred Tech S.A.S.
NIT: 902112751-6
Contacto: app@datacred.org · +57 302 668 4956
1. Objeto
Esta política describe los controles aplicados a sesiones de usuario, portal empresarial y acceso administrativo.
2. Access tokens
El sistema utiliza access tokens JWT firmados con ES256.
La implementación actual contempla access tokens de corta duración.
Los tokens contienen referencias como:
- userId;
- sessionId;
- deviceId;
- roles;
- nivel KYC;
- versión de token.
Un access token no debe contener secretos de autenticación persistentes.
3. Refresh tokens
Los refresh tokens son opacos y se almacenan en servidor mediante hash.
El sistema aplica:
- rotación;
- single-use;
- familia de tokens;
- historial de tokens consumidos;
- detección de replay;
- revocación de toda la familia ante reutilización sospechosa.
4. Replay
Cuando un refresh token ya consumido vuelve a presentarse fuera de la tolerancia de retry legítimo, DataCred puede tratarlo como posible replay.
La respuesta puede incluir:
- revocación de la familia;
- cierre de sesiones;
- evento de seguridad;
- nueva autenticación.
5. Dispositivo
Cada sesión se asocia con un deviceId.
Para operaciones sensibles, el middleware puede validar que:
- la sesión exista;
- pertenezca al usuario;
- no esté revocada;
- no haya expirado;
- el dispositivo coincida;
- la cuenta siga ACTIVE;
- no haya superado idle timeout.
6. Idle timeout
Las operaciones sensibles pueden aplicar validación de inactividad.
Una sesión que exceda el idle timeout debe volver a autenticarse.
7. Caché de sesión
DataCred puede utilizar Redis como caché temporal de validación.
Una caché positiva no reemplaza indefinidamente la fuente de verdad de la sesión.
Los resultados negativos pueden almacenarse brevemente para reducir abuso.
8. Revocación
Una sesión puede revocarse por:
- logout;
- eliminación de cuenta;
- suspensión;
- ban;
- cambio de seguridad;
- compromiso;
- token replay;
- acción administrativa autorizada.
El motivo puede conservarse en el registro de sesión.
9. Portal empresarial
Las sesiones empresariales son separadas y pueden registrar:
- userId;
- partnerId;
- expiración;
- última actividad;
- IP;
- user-agent;
- revocación.
La sesión no debe permitir cruzar de una empresa a otra.
10. Administración
Las sesiones administrativas utilizan controles reforzados.
Determinadas acciones destructivas requieren además un grant reciente de desencriptación o autenticación reforzada.
11. Cookies web
Los navegadores pueden utilizar cookies de sesión y refresh configuradas con controles como HttpOnly y SameSite=Strict cuando corresponda al flujo.
Las credenciales administrativas se mantienen host-only para reducir riesgo entre subdominios.
12. MFA
El modelo admite métodos como:
- TOTP;
- SMS;
- email;
- biometría.
La disponibilidad depende del tipo de cuenta y flujo.
Los secretos MFA no deben aparecer en logs.
13. Almacenamiento del cliente
Los tokens sensibles no deben almacenarse en lugares inseguros del cliente.
La arquitectura debe evitar exponer refresh tokens y credenciales administrativas a JavaScript cuando el flujo web utilice cookies HttpOnly.
14. Sesiones comprometidas
Ante sospecha de compromiso, DataCred puede:
- revocar;
- exigir login nuevo;
- bloquear temporalmente;
- rotar credenciales;
- invalidar familia de tokens;
- registrar evento de seguridad.
15. Datos de sesión
IP, user-agent, geografía aproximada y dispositivo son señales de seguridad.
No constituyen por sí solas prueba concluyente de identidad o fraude.
16. Retención
Las sesiones y su historial siguen la Política de Retención y Supresión de Datos.
Los tokens expirados o revocados no deben conservarse más tiempo del necesario para seguridad y auditoría.
17. Ley aplicable
Esta política se interpreta conforme a la Ley 1581 de 2012, la Ley 1273 de 2009 y demás normas colombianas aplicables.
DataCred Tech S.A.S.
NIT 902112751-6