Isolation des données
Mirox est exploité comme une plateforme partagée entre de nombreux clients. Votre organisation est votre locataire : tout ce qui lui appartient — centrales, portefeuilles, mesures, fichiers, événements, tickets, rapports, règles d'alerte, membres et jetons API — est séparé de toute autre organisation. Cette page décrit comment cette séparation fonctionne et à quoi ressemble la seule manière autorisée de la franchir.
Trois mécanismes assurent la séparation, chacun pour un type de données différent :
| Données | Où elles se trouvent | Comment elles sont séparées |
|---|---|---|
| Mesures (puissance, énergie, tensions, états, …) | Base de données de séries temporelles | Un locataire dédié par organisation. Une requête s'exécute à l'intérieur d'un seul locataire et ne peut jamais en couvrir deux. |
| Données de configuration et d'exploitation (centrales, membres, événements, tickets, rapports, règles d'alerte, …) | Base de données relationnelle | Chaque accès est autorisé par le système d'autorisations avant qu'une ligne ne soit renvoyée ou modifiée. |
| Documents, images et exports | Stockage objet | Stockés sous la centrale ou l'organisation à laquelle ils appartiennent ; servis uniquement via la plateforme, après la même vérification des autorisations, par des liens signés à durée limitée. |
Mesures : un locataire rien que pour vous
Chaque organisation reçoit son propre locataire dans la base de données de séries temporelles dès sa création. Les agents de vos centrales livrent leurs mesures dans ce locataire et nulle part ailleurs : un agent s'authentifie en tant qu'appareil enregistré pour sa centrale, et cet enregistrement fixe dans quelle centrale — et donc dans quel locataire — ses données sont écrites.
Dans l'autre sens, chaque lecture part de la centrale que vous demandez. La plateforme résout l'organisation de la centrale, et avec elle le locataire, avant que la requête ne soit construite ; la requête s'exécute ensuite à l'intérieur de ce seul locataire. Il n'existe aucune forme de requête qui lirait « tous les locataires » ou « toutes les centrales » — un graphique, un indicateur, un rapport ou un export nomme toujours ses centrales, et chacune d'elles est d'abord vérifiée par rapport à vos autorisations.
Cela vaut aussi pour l'accès brut aux mesures. L'Export de données, l'API Metric Export et les tableaux de bord Grafana ne dialoguent pas directement avec la base de données. Ils passent par un proxy qui authentifie la requête, résout les centrales que l'appelant peut voir, réécrit la requête de sorte qu'elle ne puisse correspondre qu'à ces centrales, et ne la transmet qu'ensuite. Une requête qui nomme une centrale que vous ne pouvez pas voir ne renvoie rien pour cette centrale — le proxy ne compte pas sur votre bonne volonté.
Données de configuration et d'exploitation : une vérification à chaque accès
Les centrales, portefeuilles, membres, événements, tickets, rapports, règles d'alerte et toute autre configuration sont conservés dans une seule base de données relationnelle, et la frontière entre organisations est appliquée par le système d'autorisations à chaque requête, sans exception :
- La requête est d'abord authentifiée ; une requête sans session valide ni jeton API valide est rejetée avant qu'aucune donnée ne soit touchée.
- Le système d'autorisations décide ensuite par ressource. Une centrale est vérifiée par rapport à vos rôles ; tout ce qui appartient à une centrale — ses composants, événements, tickets, fichiers, commentaires, contrats — est vérifié par rapport à cette centrale, jamais par rapport au sous-élément seul.
- Les listes sont filtrées, pas masquées : une liste de centrales, d'événements ou de rapports n'est construite qu'à partir des ressources que vous pouvez voir. Il n'existe aucun chemin « tout afficher » qui serait ensuite restreint dans le navigateur.
- La vérification s'exécute dans la même transaction de base de données que celle qui lit ou modifie les données. Un résultat ne peut jamais être assemblé à partir de lignes que la vérification n'a pas couvertes.
Ce que vous ne pouvez pas voir n'existe pas non plus pour vous sous une autre forme : ni dans les résultats de recherche, ni dans les notifications, ni dans les réponses de l'assistant IA, ni dans les exports. L'assistant et les assistants agentiques travaillent avec exactement les autorisations de la personne qui les utilise.
Fichiers
Les documents, images et exports générés sont stockés dans le stockage objet sous la centrale ou l'organisation à laquelle ils appartiennent. Ils ne sont jamais servis directement depuis le stockage : un téléchargement est demandé via la plateforme, qui effectue la même vérification des autorisations que pour la centrale elle-même, puis délivre un lien signé qui expire. Un lien ne peut être ni deviné ni réutilisé pour une autre centrale.
Tableaux de bord
Chaque organisation reçoit sa propre organisation dans Grafana, avec sa propre source de données. Les tableaux de bord, dossiers et requêtes enregistrées d'un client ne sont pas visibles dans l'organisation Grafana d'un autre, et chaque requête envoyée par un tableau de bord passe toujours par le proxy décrit ci-dessus — l'organisation Grafana est une frontière de commodité par-dessus la vraie frontière, pas un substitut à celle-ci.
Agents
Chaque centrale a son propre agent Mirox. Les agents fonctionnent de manière décentralisée sur des clusters d'agents, dans des régions distinctes de celles de la plateforme elle-même. Les agents ne partagent jamais un service, une zone mémoire ni un tunnel, et un agent ne peut livrer des données que pour la centrale à laquelle il est enregistré. Les options de déploiement décrivent comment les agents sont isolés les uns des autres sur les clusters d'agents.
Franchir la frontière volontairement
Il existe exactement une manière pour une personne extérieure à votre organisation de voir vos données, et elle est délibérée, visible et révocable :
- Une coopération accorde à une autre organisation l'accès à des centrales ou portefeuilles nommés. Elle est créée par un Admin ou un Modérateur de votre organisation, liste ce qui est partagé et prend fin dès qu'elle est révoquée. Rien n'est copié — le partenaire lit les mêmes données sous les mêmes vérifications, et son accès est délimité par les restrictions de coopération.
- Un membre Externe est invité dans votre organisation avec un rôle limité et ne voit que ce que ce rôle permet.
- Un jeton API ne peut que restreindre les autorisations de l'utilisateur qui l'a créé, jamais les étendre.
Tout le reste — un autre client, une recherche, un identifiant deviné, une requête forgée — s'arrête à la frontière. Le journal d'audit des accès enregistre qui a accédé à quelle centrale, de sorte que vous pouvez le vérifier à tout moment pour votre organisation.
Questions fréquentes
Un autre client Mirox peut-il voir mes centrales ? Non. Ses requêtes sont exécutées avec ses autorisations et à l'intérieur de son locataire ; vos centrales ne font partie ni de l'un ni de l'autre.
Une coopération copie-t-elle mes données chez le partenaire ? Non. Une coopération est une autorisation, pas une copie. Le partenaire lit les centrales partagées en direct, et rien ne subsiste de son côté une fois la coopération révoquée.
La séparation est-elle la même pour l'API et pour l'application web ? Oui. L'application web, l'application mobile, l'API et l'assistant IA passent tous par le même backend et les mêmes vérifications. Il n'existe pas de second chemin aux règles plus faibles.
Comment puis-je vérifier qui a accédé à mes données ? Ouvrez le journal d'audit des accès de votre organisation. Il liste chaque accès à vos centrales, y compris ceux effectués via des coopérations.
Pages associées
- Système d'autorisations — les rôles et les couches qui décident de chaque accès
- Coopérations et Restrictions de coopération — la manière autorisée de franchir la frontière
- Journal d'audit des accès — l'enregistrement de chaque accès
- Vue d'ensemble du cloud — comment la plateforme est construite