Isolamento de Dados

A Mirox é operada como uma plataforma partilhada por muitos clientes. A sua organização é o seu inquilino: tudo o que lhe pertence — centrais, carteiras, medições, ficheiros, eventos, tickets, relatórios, regras de alerta, membros e tokens de API — está separado de todas as outras organizações. Esta página descreve como essa separação funciona e qual é a única forma sancionada de a atravessar.

Três mecanismos asseguram a separação, cada um para um tipo de dados diferente:

Medições: um inquilino só seu

Cada organização recebe o seu próprio inquilino na base de dados de séries temporais quando é criada. Os agentes das suas centrais entregam as suas medições nesse inquilino e em nenhum outro lugar: um agente autentica-se como o dispositivo registado para a sua central, e esse registo fixa em que central — e, portanto, em que inquilino — os seus dados são escritos.

No sentido inverso, cada leitura parte da central que pede. A plataforma resolve a organização da central, e com ela o inquilino, antes de a consulta ser construída; a consulta corre então dentro desse único inquilino. Não existe nenhuma forma de pedido que leia "todos os inquilinos" ou "todas as centrais" — um gráfico, um KPI, um relatório ou uma exportação nomeia sempre as suas centrais, e cada uma delas é primeiro verificada contra as suas permissões.

Isto aplica-se também ao acesso em bruto às medições. A Exportação de métricas, a API de exportação de métricas e os dashboards do Grafana não falam diretamente com a base de dados. Passam por um proxy que autentica o pedido, resolve as centrais que quem chama pode ver, reescreve a consulta de modo a que só possa corresponder a essas centrais, e só depois a reencaminha. Uma consulta que nomeie uma central que não pode ver não devolve nada para essa central — o proxy não depende de que peça educadamente.

Dados de configuração e operacionais: uma verificação em cada acesso

Centrais, carteiras, membros, eventos, tickets, relatórios, regras de alerta e toda a restante configuração são guardados numa base de dados relacional, e a fronteira entre organizações é imposta pelo sistema de permissões em cada um dos pedidos:

• O pedido é primeiro autenticado; um pedido sem uma sessão válida ou sem token de API é rejeitado antes de qualquer dado ser tocado.
• O sistema de permissões decide depois por recurso. Uma central é verificada contra as suas funções; tudo o que pertence a uma central — os seus componentes, eventos, tickets, ficheiros, comentários, contratos — é verificado contra essa central, nunca contra o subelemento isoladamente.
• As listas são filtradas, não ocultadas: uma lista de centrais, eventos ou relatórios é construída apenas a partir dos recursos que pode ver. Não existe nenhum caminho "mostrar tudo" que seja depois estreitado no browser.
• A verificação corre dentro da mesma transação de base de dados que lê ou altera os dados. Um resultado nunca pode ser montado a partir de linhas que a verificação não cobriu.

O que não pode ver também não existe para si sob qualquer outra forma: não está nos resultados de pesquisa, não está nas notificações, não está nas respostas do assistente de IA e não está nas exportações. O assistente e os assistentes guiados agênticos trabalham exatamente com as permissões da pessoa que os utiliza.

Ficheiros

Documentos, imagens e exportações geradas são guardados no armazenamento de objetos sob a central ou organização a que pertencem. Nunca são servidos diretamente a partir do armazenamento: uma transferência é pedida através da plataforma, que realiza a mesma verificação de permissões que para a própria central e entrega depois uma ligação assinada que expira. Uma ligação não pode ser adivinhada nem reutilizada para outra central.

Dashboards

Cada organização recebe a sua própria organização dentro do Grafana, com a sua própria fonte de dados. Os dashboards, pastas e consultas guardadas de um cliente não são visíveis na organização Grafana de outro, e cada consulta que um dashboard envia passa na mesma pelo proxy descrito acima — a organização Grafana é uma fronteira de conveniência por cima da verdadeira, não um substituto dela.

Agentes

Cada central tem o seu próprio agente Mirox. Os agentes funcionam de forma descentralizada em clusters de agentes, em regiões distintas das da própria plataforma. Os agentes nunca partilham um serviço, uma região de memória ou um túnel, e um agente só pode entregar dados para a central em que está registado. As opções de implementação descrevem como os agentes estão isolados uns dos outros nos clusters de agentes.

Atravessar a fronteira de propósito

Existe exatamente uma forma de alguém fora da sua organização ver os seus dados, e é deliberada, visível e revogável:

• Uma cooperação concede a outra organização acesso a centrais ou carteiras nomeadas. É criada por um Administrador ou Moderador da sua organização, lista o que é partilhado e termina no momento em que é revogada. Nada é copiado — o parceiro lê os mesmos dados sob as mesmas verificações, e o seu acesso é delimitado pelas restrições de cooperação.
• Um membro Externo é convidado para a sua organização com uma função limitada e vê apenas o que essa função permite.
• Um token de API só pode restringir as permissões do utilizador que o criou, nunca alargá-las.

Tudo o resto — outro cliente, uma pesquisa, um identificador adivinhado, uma consulta forjada — termina na fronteira. O registo de auditoria de acessos regista quem acedeu a que central, pelo que pode verificar isto para a sua organização a qualquer momento.

Perguntas frequentes

Outro cliente Mirox pode alguma vez ver as minhas centrais? Não. Os seus pedidos são executados com as permissões dele e dentro do inquilino dele; as suas centrais não fazem parte de nenhum dos dois.

Uma cooperação copia os meus dados para o parceiro? Não. Uma cooperação é uma permissão, não uma cópia. O parceiro lê as centrais partilhadas em direto, e nada fica do lado dele depois de a cooperação ser revogada.

A separação é a mesma para a API e para a aplicação web? Sim. A aplicação web, a aplicação móvel, a API e o assistente de IA passam todos pelo mesmo backend e pelas mesmas verificações. Não existe um segundo caminho com regras mais fracas.

Como posso verificar quem acedeu aos meus dados? Abra o registo de auditoria de acessos da sua organização. Lista cada acesso às suas centrais, incluindo os feitos através de cooperações.

Páginas relacionadas

• Sistema de Permissões — as funções e camadas que decidem cada acesso
• Cooperações e Restrições de Cooperação — a forma sancionada de atravessar a fronteira
• Registo de Auditoria de Acessos — o registo de cada acesso
• Visão Geral da Cloud — como a plataforma é construída