Módulo 12 · Seguridad de la cuenta

Read in English: Module 12 · Account security.

Objetivo: proteger el acceso al panel mediante el segundo factor (2FA) o inicio de sesión único (SSO), acotar cuándo y desde dónde se entra, controlar el acceso de soporte de la plataforma, entender la sesión única y saber cómo auditar quién ha entrado a la cuenta. Tiempo: ~10 minutos · Necesitas: un usuario con rol de account_admin (para SSO y auditoría) o cualquier usuario (para tu propio 2FA).

1. Verificación en dos pasos (2FA)

El segundo factor (2FA) con una app autenticadora (TOTP) no es obligatorio por defecto, pero cada persona puede (y debe) activarlo para su propia cuenta. Se configura desde la sección Seguridad del menú lateral.

Al activarlo, la plataforma te dará el código QR para tu app (como Google Authenticator o Authy) y códigos de recuperación. Guarda los códigos de recuperación en un lugar seguro: cada uno sirve una sola vez y son tu única vía de acceso si pierdes tu dispositivo.

¿Qué pasa si alguien pierde su dispositivo y sus códigos?

Si una persona de tu equipo pierde su app autenticadora y no guardó los códigos de recuperación, no podrá entrar. Sin embargo, la cuenta no está perdida:

Un usuario con rol de administrador de la cuenta (account_admin) del mismo tenant puede ir a Seguridad → Usuarios de consola, seleccionar a la persona y quitar el segundo factor de su cuenta. Para hacerlo, el panel exigirá que el administrador escriba un motivo (que quedará sellado en el registro de auditoría). Una vez quitado, la persona podrá volver a entrar solo con su contraseña y configurar el 2FA de nuevo.

El admin no puede quitar el suyo propio desde esa pantalla

Un administrador no puede usar el botón de la lista de usuarios para su propia cuenta — debe usar la pestaña de su propio 2FA y confirmar con un código.

2. Auditoría de accesos

Para saber quién entra a la plataforma y cuándo, los administradores de la cuenta tienen acceso a la Auditoría de accesos (dentro de la sección Seguridad).

Este registro muestra cada intento de inicio de sesión registrado en tu cuenta, del más reciente al más antiguo: cuándo ocurrió, qué persona, con qué método (contraseña, verificación en dos pasos o SSO) y si salió bien o falló.

3. Inicio de sesión único (SSO / SAML)

Si tu empresa ya usa un proveedor de identidad (como Entra ID, Okta o Google Workspace), un administrador puede configurar el Inicio de sesión único (SSO) en la pestaña correspondiente de Seguridad.

Una vez configurado y activado:

• Las personas entran delegando la autenticación a tu proveedor de identidad.
• Puedes compartir a tu equipo un enlace directo y copiable con el formato /login?sso=<tu-tenant-id>. Con ese enlace, la pantalla de inicio sabrá exactamente a qué proveedor enviarlos sin que tengan que recordar o escribir el ID de la organización.

4. Política de inicio de sesión (por dirección y por horario)

Un administrador de la cuenta puede limitar cuándo y desde dónde entra la gente al panel. Está en Seguridad → Política de inicio de sesión (/security/login-policy). Sólo la ven los administradores de la cuenta y no depende de ningún interruptor de la plataforma: viene sin política escrita, así que el inicio de sesión funciona como siempre hasta que alguien publique una.

Qué se define:

• Modo: Desactivada (nadie queda restringido), Observar (a nadie se le rechaza; cada acceso que la política habría rechazado queda anotado) o Aplicar (un acceso desde una dirección o a una hora fuera de la política se rechaza).
• Direcciones permitidas: una dirección o rango (CIDR, IPv4 o IPv6) por línea, hasta 64. Vacío significa sin restricción por dirección.
• Horario de acceso, por rol (Miembros y Administradores de la cuenta): marca los días abiertos y fija su hora de inicio y de fin. Un rol sin ningún día abierto no tiene restricción horaria; un día sin marcar queda cerrado.
• Zona horaria (nombre IANA, por ejemplo America/Chicago): obligatoria si fijas algún horario.
• Motivo: opcional; queda en el historial.

La plataforma comprueba la política cuando la contraseña es correcta y antes de abrir sesión. Cada cambio añade una versión nueva y nada se edita en su sitio: el Historial de versiones las lista todas, la más reciente primero.

Empieza en modo Observar

Publica la política en Observar y mira el informe A quién habría dejado fuera: se lee de tu registro real de accesos y muestra qué personas, y cuántos accesos correctos, habría rechazado la política. Cuando el informe salga vacío o aceptable, pasa a Aplicar. Para aplicarla hace falta al menos una dirección o un horario.

No te dejes fuera

Cuando guardas en modo Aplicar, la plataforma comprueba que tu propia dirección, tu rol y la hora actual cumplen la política. Si no la cumplieran, no se guarda nada y se te explica por qué. En Observar esa comprobación no se hace (sólo se exige que tu dirección se pueda identificar si hay lista de direcciones): mira el informe antes de pasar a Aplicar.

Si una celda no mide la dirección desde la que entra la gente, la pantalla lo avisa y en ella sólo se pueden definir horarios, no una lista de direcciones.

Los intentos rechazados por la política quedan en la Auditoría de accesos (sección 2).

5. Acceso de soporte de la plataforma

El Acceso de soporte (Seguridad → Acceso de soporte, /security/support-access) es el consentimiento temporal que tú das para que una persona del soporte de la plataforma mire tu cuenta. Sólo los administradores de la cuenta ven estos controles.

Quién lo enciende: viene apagado. Es un interruptor de la plataforma que sólo cambia el founder, y además la celda debe tener abierto su techo; con el techo cerrado ningún cliente puede usarlo. Tus pantallas de concesión, revocación e historial siguen respondiendo en cualquier caso, para que siempre puedas revocar y revisar lo que ya existe.

Qué ve soporte: una sesión de soporte es de solo lectura. Sólo puede consultar un conjunto cerrado de pantallas de datos (por ejemplo campañas, agentes, números, estadísticas y disposiciones) y no puede escribir, exportar ni crear o ver credenciales. Todo lo demás se le deniega. Además, cada sesión de soporte dura como máximo 60 minutos, y nunca más allá del vencimiento de la concesión.

Cómo se concede:

1. Entra en Seguridad → Acceso de soporte, apartado Conceder acceso.
2. Escribe el Motivo (de 1 a 500 caracteres): nombra el ticket de soporte o el motivo concreto.
3. Indica la Duración en minutos, de 15 a 480 (si no indicas ninguna, 60). La plataforma fija el vencimiento al crear la concesión y nunca se mueve.
4. Pulsa Conceder acceso de soporte.

Una concesión registra tu consentimiento; no abre por sí sola una sesión de soporte. Sólo puede haber una concesión vigente por cuenta: si ya hay una, la plataforma rechaza la segunda hasta que revoques la primera.

Cómo se revoca: en el historial, pulsa Revocar concesión y confirma con Sí, revocar. Puedes hacerlo en cualquier momento antes del vencimiento.

Qué queda registrado: el Historial de acceso lista, del más reciente al más antiguo, cada evento: concesión creada, concesión revocada, sesión de soporte abierta, sesión de soporte revocada, lectura servida y lectura denegada, con el actor y el detalle. Los eventos sólo se añaden; no se editan ni se borran.

Mientras hay una sesión de soporte abierta, todo el equipo ve un aviso en el panel: «El soporte de la plataforma está dentro de esta cuenta», con quién es y hasta cuándo.

6. Sesión única por persona

Con la sesión única, cada persona puede tener una sola sesión del panel a la vez. Evita credenciales compartidas y sesiones olvidadas en otro equipo.

Quién la enciende: viene apagada y sólo la cambia el founder, a petición del cliente; no tiene pantalla de configuración en tu cuenta. Está apagada porque desconecta a una persona del puesto donde trabajaba.

Cuando está encendida:

• Cada nuevo inicio de sesión (contraseña, segundo factor, alta forzosa del segundo factor o SSO) cierra las demás sesiones abiertas de esa misma persona.
• En el equipo que se quedó fuera, la siguiente acción lleva a la pantalla de inicio con este aviso: «Tu sesión terminó porque volviste a entrar desde otro dispositivo o navegador. Entra aquí para continuar; solo se permite una sesión por persona.»
• Cada sesión cerrada deja una fila en un registro que sólo se añade.
• No afecta a las llaves de API (dd_) ni al widget: no son sesiones de persona. Las sesiones que ya estaban abiertas al encenderla se respetan hasta el siguiente inicio de sesión de esa persona.

Si está apagada, los inicios de sesión nunca tocan otra sesión y nada cambia.