Seguridad

Autenticación

Las cuentas se gestionan mediante Supabase Auth con correo electrónico y contraseña, OAuth de Google u OAuth de GitHub. Tras el inicio de sesión, su navegador guarda un token de sesión (un JWT) que el middleware de la plataforma renueva automáticamente, de modo que una sesión en curso no expira en silencio a mitad del trabajo.

La API acepta ese token de sesión de dos formas: como la cookie de sesión que el panel ya envía, o como un encabezado Authorization Bearer. El acceso programático sin inicio de sesión en el navegador usa claves de API en su lugar, descritas más abajo. Los endpoints rechazan las solicitudes sin una credencial válida; solo las rutas explícitamente públicas, como la comprobación de salud y el formulario de contacto, funcionan sin autenticación.

Roles y permisos

Cada cuenta tiene exactamente un rol: CLIENT, OPERATOR o ADMIN. Los clientes poseen robots y pagan por sesiones, los operadores controlan robots y ganan con sesiones, y los administradores gestionan la plataforma. Elige entre cliente y operador durante el onboarding; el rol de administrador lo asignan los administradores de la plataforma y no puede autoseleccionarse.

Las comprobaciones de rol ocurren del lado del servidor en cada solicitud, no en la interfaz. Por debajo de la API, el acceso a la base de datos está además restringido con políticas de seguridad a nivel de fila, de modo que incluso un error en un endpoint no se convierte en acceso libre a las filas de otras cuentas.

Claves de API

Las claves de API dan a scripts y servidores acceso sin inicio de sesión en el navegador. Las crea y las revoca en /dashboard/settings; las claves llevan el prefijo ayr_live_ y se envían como un encabezado Authorization Bearer. Una clave actúa con el rol y los permisos de la cuenta que la creó, así que una clave filtrada es exactamente tan grave como una contraseña filtrada.

• Mantenga las claves del lado del servidor. No pertenecen a JavaScript del lado del cliente, aplicaciones móviles ni repositorios públicos.
• Use una clave por integración. Si algo se filtra, querrá revocar un consumidor, no todos.
• Rote sin tiempo de inactividad: cree primero la clave de reemplazo, despliéguela, y después revoque la clave antigua en /dashboard/settings.
• Revoque de inmediato ante cualquier sospecha. Crear una clave nueva cuesta segundos; un atacante con una clave válida puede hacer todo lo que su cuenta puede hacer.

Salvaguardas durante el control en vivo

El control en vivo está ligado a un arrendamiento de sesión. Un robot solo acepta comandos mientras está en exactamente una sesión ACTIVE, y solo del operador que mantiene esa sesión; para todos los demás, el robot queda marcado como IN_SESSION. Un operador puede mantener como máximo una sesión ACTIVE o PAUSED a la vez, lo que descarta que una persona controle nominalmente dos brazos a la vez.

La consola ofrece una parada de emergencia que detiene el brazo de inmediato, y pausar o terminar la sesión detiene el flujo de comandos en conjunto. Además, la plataforma monitoriza la actividad del operador: tras un periodo sin entrada se envía una advertencia de inactividad, y si el operador permanece inactivo, la sesión se detiene automáticamente. Eso protege a ambas partes: al cliente de pagar por tiempo inactivo, y al robot de quedar en un estado sin control bajo un arrendamiento activo.

Registro de auditoría

Cada sesión mantiene un registro de eventos: inicio y fin, pausas y reanudaciones, comprobaciones de actividad, advertencias de inactividad, cambios de operador, solicitudes de extensión y errores, cada uno con marca de tiempo. Cuando se revisa una disputa, este registro de eventos es la evidencia principal, una razón más por la que la plataforma lo escribe automáticamente en lugar de depender de la memoria de nadie.

Más allá de las sesiones, las acciones significativas de la plataforma se registran en un registro de auditoría con el id del usuario que actuó, la acción, el recurso afectado y metadatos. Los cambios de perfil, las transacciones relevantes para pagos y las acciones de administrador dejan todos ellos entradas. Los registros de auditoría los escribe la plataforma y no se pueden editar desde ninguna interfaz orientada al usuario.

Cifrado y protección de datos

Todo el tráfico hacia y desde la plataforma está cifrado en tránsito con TLS, incluidas las transmisiones de video y las señales de control. A nivel de datos, las políticas de seguridad a nivel de fila restringen el acceso a la base de datos por cuenta. Los datos de pago son el límite más claro de todos: las tarjetas y los datos bancarios los gestiona exclusivamente Stripe y nunca tocan los servidores de AY-Robots.

Reportar una vulnerabilidad

Si encuentra un problema de seguridad, repórtelo de forma responsable a través de la página /security o del formulario en /contact usando la categoría Bug Report. Incluya qué encontró, dónde y cómo reproducirlo; no acceda a datos de otros usuarios más allá del mínimo necesario para demostrar el problema, y no publique detalles antes de que hayamos tenido una oportunidad razonable de solucionarlo. Leemos todos los reportes.

Preguntas frecuentes