Doogree
Arquitectura · Permisos

Propiedad, uso compartido de dispositivos y API por inquilino

30/06/2026 · ~6 min de lectura
multi-inquilinopermisosMCP3D

Un sistema que gestiona los ordenadores de los clientes debe responder a la vez a dos preguntas opuestas: cómo evitas que distintos inquilinos se vean entre sí, mientras al mismo tiempo sigues permitiendo compartir dispositivos entre usuarios sin perder la propiedad. Así resolvimos ambas.

Aislamiento entre inquilinos — la base

Cada dispositivo (DEVICE) está vinculado a un único espacio de trabajo, y cada consulta del sistema —listar, conectar, borrar e incluso el WebSocket— se filtra por ese mismo espacio de trabajo. Lo verificamos no solo en el código, sino en vivo contra la base de datos: 0 de 12 dispositivos sin asignación, y el acceso entre inquilinos es sencillamente imposible. Incluso la contraseña del dispositivo se cifra con la clave del espacio de trabajo, de modo que un dispositivo que pertenece a un inquilino no puede descifrarse con la clave de otro inquilino.

Propiedad por usuario

Dentro de la misma organización, cada usuario es un inquilino independiente: el dispositivo pertenece a quien lo conectó (owner_id), y es privado para esa persona por defecto. Esta es la separación que faltaba cuando cada miembro del equipo podía verlo todo; ahora un dispositivo no compartido se queda únicamente con su propietario.

Uso compartido — explícito y por dispositivo

Compartir es una acción deliberada: el propietario elige a un usuario de la organización y comparte con él un único dispositivo (device_grants) o todos sus dispositivos (account_grants), eligiendo entre control total y solo lectura. El dispositivo compartido es accesible para ambos y se comporta de forma idéntica, salvo por una cosa:

Solo el propietario puede borrar. Quien conectó el dispositivo (o el administrador de la organización) es el único que puede borrar el DEVICE. Un colaborador solo puede desconectarse a sí mismo —retirar su propio acceso, sin afectar a nadie más—. La desconexión es bidireccional: el propietario puede revocar el uso compartido y el colaborador puede irse.

El panel tiene un área «🔗 Dispositivos compartidos» con dos pestañas —lo que he compartido y lo que se comparte conmigo— para que gestionar el acceso sea claro y cómodo. La criptografía no ha cambiado: el Worker sigue descifrando con la clave del espacio de trabajo, y la fila de concesión (grant) es el permiso. No hay intercambio de claves ni rotación: el mismo modelo de confianza, solo que enfocado por dispositivo en lugar de por organización.

API y MCP por inquilino

Cada inquilino puede emitir su propia clave de API (drk_…) que otorga acceso programático con exactamente el mismo alcance que tiene en el panel, ni más. La clave está aislada por inquilino por definición. Potencia tanto la REST (/api/v1/*) como un servidor MCP alojado (/api/mcp), de modo que puedes conectar un agente de IA (como Claude) y darle herramientas: para listar dispositivos, ver lo que está compartido y obtener un token de conexión de un solo uso. Todo se sitúa detrás del mismo permiso: un agente no puede ver un dispositivo que tú no puedes ver.

Mapa de conexiones 3D

Y por último, una vista al estilo FROG: todos tus dispositivos y servidores como nodos alrededor de un centro («nosotros»), envueltos en un escudo protector translúcido, con flechas de entrada/salida que muestran el tráfico, un pulso de monitorización que se repite por toda la conectividad y un código de color según la salud de cada dispositivo. Enfocado al cliente: cada inquilino ve únicamente sus propias conexiones. Esto no es decoración: es una forma de captar de un vistazo qué está conectado, qué está protegido y qué necesita atención.

En resumen: aislamiento duro entre inquilinos, uso compartido explícito por dispositivo con la propiedad preservada, acceso programático aislado mediante API/MCP y una instantánea visual, todo sobre la misma infraestructura de confianza, sin comprometer la separación.

← Volver al blog