Doogree
Arquitetura · Permissões

Propriedade, compartilhamento de dispositivos e API por inquilino

30/06/2026 · leitura de ~6 min
multi-inquilinopermissõesMCP3D

Um sistema que gerencia os computadores de clientes precisa responder a duas perguntas opostas ao mesmo tempo: como evitar que inquilinos diferentes vejam uns aos outros, ao mesmo tempo em que ainda permite o compartilhamento de dispositivos entre usuários sem perder a propriedade. Veja como resolvemos ambas.

Isolamento de inquilinos — a base

Todo dispositivo (DEVICE) está atrelado a um único workspace, e toda consulta no sistema — listar, conectar, excluir e até o WebSocket — é filtrada por esse mesmo workspace. Verificamos isso não apenas no código, mas ao vivo contra o banco de dados: 0 de 12 dispositivos sem atribuição, e o acesso entre inquilinos é simplesmente impossível. Até a senha do dispositivo é criptografada com a chave do workspace, de modo que um dispositivo pertencente a um inquilino não pode ser descriptografado com a chave de outro inquilino.

Propriedade por usuário

Dentro da mesma organização, cada usuário é um inquilino separado: o dispositivo pertence a quem o conectou (owner_id) e é privado a ele por padrão. Essa é a separação que faltava quando cada membro da equipe podia ver tudo — agora um dispositivo não compartilhado fica apenas com seu proprietário.

Compartilhamento — explícito e por dispositivo

O compartilhamento é uma ação deliberada: o proprietário escolhe um usuário na organização e compartilha um único dispositivo com ele (device_grants) ou todos os seus dispositivos (account_grants), escolhendo entre controle total e somente-visualização. O dispositivo compartilhado fica acessível a ambos e se comporta de forma idêntica — exceto por uma coisa:

Apenas o proprietário pode excluir. Quem conectou o dispositivo (ou o administrador da organização) é o único que pode excluir o DEVICE. Um colaborador só pode desconectar a si mesmo — remover o próprio acesso, sem afetar ninguém mais. A desconexão é bidirecional: o proprietário pode revogar o compartilhamento, e o colaborador pode sair.

O painel tem uma área "🔗 Dispositivos Compartilhados" com duas abas — o que compartilhei e o que foi compartilhado comigo — de modo que gerenciar o acesso é claro e conveniente. A criptografia não mudou: o Worker ainda descriptografa com a chave do workspace, e a linha de concessão é a permissão. Não há troca de chaves nem rotação — o mesmo modelo de confiança, apenas focado por dispositivo em vez de por organização.

API e MCP por inquilino

Cada inquilino pode emitir sua própria chave de API (drk_…) que concede acesso programático exatamente no mesmo escopo que ele tem no painel — nada além. A chave é isolada por inquilino por definição. Ela alimenta tanto o REST (/api/v1/*) quanto um servidor MCP hospedado (/api/mcp), de modo que você pode conectar um agente de IA (como o Claude) e dar-lhe ferramentas: listar dispositivos, ver o que está compartilhado e obter um token de conexão de uso único. Tudo fica atrás da mesma permissão — um agente não pode ver um dispositivo que você não pode ver.

Mapa de conexões em 3D

E, por fim, uma visão no estilo FROG: todos os seus dispositivos e servidores como nós ao redor de um centro ("nós"), envoltos num escudo protetor translúcido, com setas de entrada/saída mostrando o tráfego, um pulso de monitoramento que se repete por toda a conectividade e codificação por cores conforme a saúde de cada dispositivo. Focado no cliente: cada inquilino vê apenas suas próprias conexões. Isto não é decoração — é uma forma de captar num relance o que está conectado, o que está protegido e o que precisa de atenção.

Conclusão: isolamento rígido entre inquilinos, compartilhamento explícito por dispositivo com a propriedade preservada, acesso programático isolado via API/MCP e um retrato visual — tudo sobre a mesma infraestrutura de confiança, sem comprometer a separação.

← Voltar ao blog