Seguridad de cuenta y API

Autenticación

Rediacc admite múltiples métodos de autenticación:

• Contraseña: Inicio de sesión tradicional con correo electrónico y contraseña
• Magic Link: Inicio de sesión sin contraseña mediante enlace por correo (expira en 15 minutos)
• Autenticación de dos factores (2FA): Basada en TOTP con códigos de respaldo

Cuando 2FA está habilitado, el inicio de sesión requiere tanto la contraseña (o magic link) como un código TOTP de 6 dígitos.

Tokens de API

Los tokens de API autentican operaciones de máquina a máquina (activación de licencias CLI, verificaciones de estado).

Alcances:

• license:read — Consultar el estado de suscripción y licencia
• license:activate — Activar máquinas y emitir licencias de repositorio
• subscription:read — Leer detalles de la suscripción

Funciones de seguridad:

• Vinculación de IP: un token solo vale para la dirección IP de su primera solicitud; una dirección nueva requiere una verificación TOTP o un nuevo inicio de sesión (ver más abajo)
• Alcance por equipo: los tokens pueden restringirse a un equipo específico
• Revocación automática: los tokens se revocan cuando el creador es eliminado de la organización

Crear un token:

# A través del portal: API Tokens > Create
# El valor del token se muestra una vez -- guárdelo de forma segura

Cuando cambia la dirección IP

Un token vinculado a una dirección IP se rechaza desde cualquier otra, por ejemplo cuando el proveedor de Internet asigna una dirección nueva. La CLI se encarga del traslado:

• Terminal interactiva con 2FA activada: la CLI pide el código de 6 dígitos de la app de autenticación, traslada el token a la nueva dirección y vuelve a ejecutar el comando. Los códigos de respaldo no sirven para un traslado.
• Scripts y CI (sin terminal): el comando falla e indica las dos soluciones: ejecutar una vez cualquier comando rdc en una terminal interactiva (por ejemplo rdc subscription status) e introducir el código, o ejecutar rdc subscription login.
• 2FA desactivada: el token no se puede trasladar. rdc subscription login emite uno nuevo y, con la 2FA activada, el próximo traslado solo necesita un código.
• Códigos incorrectos: 5 códigos incorrectos en 15 minutos bloquean el traslado, primero durante 5 minutos y luego el doble cada vez, hasta 1 hora. Tras 4 bloqueos, el traslado queda desactivado para ese token hasta el siguiente rdc subscription login.
• Los tokens de executor con vinculación de IP unbound o cloudflare no se ven afectados.

Cada traslado aparece en el registro de actividad del portal, con la dirección anterior y la nueva.

Flujo de código de dispositivo

La CLI puede autenticarse en máquinas sin pantalla utilizando el flujo de código de dispositivo:

rdc subscription login
# Muestra: Ingrese el código XXXX-XXXX-XX en https://www.rediacc.com/account/authorize
# Después de la aprobación, la CLI recibe credenciales automáticamente

Config Storage

Para configuración cifrada y sincronizada con el servidor, consulta Config Storage para la guía completa. Config storage utiliza:

• Cifrado de conocimiento cero (el servidor nunca ve texto plano)
• Derivación de claves basada en passkey (WebAuthn + PRF)
• Tokens rotativos con rotación por solicitud

Seguridad de sesión

Tipo de token	Duración	Almacenamiento	Actualización
Access Token (JWT)	15 minutos	Cookie HttpOnly	Automático vía refresh token
Refresh Token	7 días	Cookie HttpOnly	Rotado en cada uso
Sesión elevada	10 minutos	Lado del servidor	Activado por reautenticación

Las sesiones elevadas son necesarias para operaciones sensibles: cambios de contraseña, cambios de correo electrónico, configuración de 2FA, transferencias de propiedad y acciones administrativas destructivas.

Modelo de permisos

Rediacc utiliza tres capas de permisos independientes:

Capa 1: Rol del sistema — Determina el acceso a los endpoints de administración del sistema.

Capa 2: Rol de organización — Controla lo que un usuario puede hacer dentro de su organización (owner, admin, member).

Capa 3: Rol de equipo — Limita el acceso a recursos específicos del equipo (team_admin, member). Los propietarios y administradores de la organización omiten las verificaciones de rol de equipo.

Cada solicitud de API pasa por todas las capas aplicables en secuencia. Una solicitud a un endpoint de ámbito de equipo debe cumplir con la autenticación de sesión, la membresía de organización y el acceso al equipo.

Canales de actualización

La CLI admite dos canales de lanzamiento:

• stable (predeterminado): Promovido desde edge tras un período de prueba de 7 días; elige este canal para una cadencia de actualización conservadora
• edge: Últimas funciones, actualizado en cada lanzamiento

rdc update --channel edge      # Cambiar a edge
rdc update --channel stable    # Volver a stable
rdc update --status            # Mostrar canal actual

Postura de seguridad de la CLI para agentes de IA

Los agentes de código que invocan rdc son una superficie de amenaza real, por lo que los tratamos como un principal separado. Cada invocación de rdc se clasifica al inicio como humano o agente según señales del entorno (CLAUDECODE, GEMINI_CLI, COPILOT_CLI, CURSOR_TRACE_ID, REDIACC_AGENT) más un recorrido de ascendencia Linux /proc. La detección es de mejor esfuerzo. Un wrapper determinado puede falsificar variables de entorno, por eso importa la ascendencia. Los agentes obtienen un conjunto de permisos reducido: las mutaciones de configuración sensibles requieren la compuerta de conocimiento (--current <antiguo>), el editor interactivo se rechaza sin una anulación REDIACC_ALLOW_CONFIG_EDIT verificada por ascendencia, y --reveal en cualquier comando de visualización está bloqueado. Cada decisión (permitir, rechazar o conceder --reveal) escribe una línea JSONL encadenada por hash en ~/.config/rediacc/audit.log.jsonl. Ejecuta rdc config audit verify para comprobar la integridad de la cadena.

Consulta Seguridad y salvaguardas de agentes de IA para la matriz completa de lo que los agentes pueden y no pueden hacer, ejemplos de la compuerta de conocimiento y la mecánica de anulación de alcance.