Seguridad de la cuenta

English version: Account security.

Dialer Digital ofrece capacidades de API para imponer restricciones de acceso a nivel de tenant y para auditar el acceso del soporte de la plataforma. Estas funciones permiten acotar estrictamente la superficie de ataque de una cuenta y garantizan que cualquier suplantación por parte del personal de soporte deje un rastro inmutable.

Política de inicio de sesión (IP y horario)

Disponible desde core v0.95.0: los endpoints /v1/tenant/login-policy.

Un tenant puede publicar una política de inicio de sesión para restringir los accesos al dashboard (sesiones ddu_) a direcciones IP concretas (rangos CIDR) y a ventanas horarias permitidas, configurables por rol (member o account_admin).

Cuando la política está en enforce, la plataforma la evalúa después de que la credencial resulte correcta. Un inicio de sesión desde una dirección fuera de los rangos permitidos, o a una hora fuera del horario permitido, se rechaza con 403 y el código login_policy_denied. El motivo concreto (dirección u hora) no se revela a quien llama, pero queda escrito en el rastro de inicios de sesión del tenant (GET /v1/auth/sign-in-events).

Endpoints de configuración

• GET /v1/tenant/login-policy: devuelve la política de inicio de sesión vigente.
• PUT /v1/tenant/login-policy: publica una nueva versión de la política. Recibe un mode (off, observe o enforce; por defecto observe), ip_allow, windows por rol y timezone.
• GET /v1/tenant/login-policy/history: lista todas las versiones publicadas de la política (solo se añade, nunca se reescribe).

Leer (GET, history) admite una clave dd_ o un login de account_admin; escribir (PUT) exige un login de dashboard de account_admin — una clave dd_ recibe 403 role_forbidden.

Límites que fallan cerrado

• ip_allow admite hasta 64 bloques CIDR o direcciones sueltas, IPv4 e IPv6; una entrada mal formada o un /0 es 422.
• El modo observe registra los fallos en el rastro de inicios de sesión pero nunca niega el acceso.
• Una política que dejaría fuera a quien la escribe se rechaza con 422 would_lock_out_caller; no se guarda nada.

Acceso de soporte auditado

El acceso de soporte de la plataforma permite a un tenant conceder a un operador de Dialer Digital acceso de solo lectura para resolver incidencias.

Por defecto, el acceso de soporte de la plataforma está desactivado. Un operador de soporte no puede suplantar a un usuario sin una concesión activa y limitada en el tiempo.

Conceder el acceso

Un account_admin puede conceder el acceso mediante:

• POST /v1/support-access/grants con un reason (de 1 a 500 caracteres) y un duration_minutes opcional (15–480, por defecto 60); el vencimiento queda fijado al crearla. Una segunda concesión viva es 409 grant_already_live.

Esto crea una única concesión viva por tenant. El acceso es estrictamente de solo lectura (carril dds_) y se puede revocar en cualquier momento:

• DELETE /v1/support-access/grants/{id}

El rastro de auditoría

Cada concesión, revocación, sesión de soporte y petición hecha bajo ella deja un evento de solo anexado en el rastro del tenant:

• GET /v1/support-access/events: devuelve el rastro de eventos de acceso de soporte de la plataforma, del más reciente al más antiguo.
• GET /v1/support-access/active: indica si hay una sesión de soporte abierta ahora mismo (active, expires_at, operator_name) — la puede leer cualquier login de dashboard del tenant, incluido member.

Conceder, revocar y leer el rastro exigen un login de dashboard de account_admin; una clave dd_ recibe 403.

Sesión única por persona

Para evitar credenciales compartidas y sesiones huérfanas, un tenant puede imponer una sesión única por persona.

Esto lo gobierna el flag de plataforma single_session_enforced. Cuando la plataforma lo activa:

• Un nuevo inicio de sesión (password, mfa, sso, etc.) crea una sesión nueva y revoca de inmediato todas las demás sesiones vivas de esa misma persona en el tenant.
• La siguiente petición de una sesión expulsada recibe un 401 con el código session_superseded. Este código específico permite a la interfaz explicar con claridad por qué se cerró la sesión del usuario, en lugar de una caducidad genérica.

Esta función no requiere configuración por API del tenant: opera en silencio en segundo plano una vez activada.