Proxy (accès web aux appareils de la centrale)

Le Proxy de la plateforme Mirox permet un accès direct aux interfaces web des appareils du réseau de la centrale — sans client VPN, sans installation locale, uniquement via le navigateur. Les UI de configuration des onduleurs, tableaux de bord des data loggers, UI de caméras, pages web d'armoires de commande ou outils de services auto-hébergés deviennent accessibles via une URL Mirox unique — authentifiée par le compte Mirox de l'utilisateur et entièrement auditée.

Concept

Le Proxy comble le fossé entre le VPN et un tableau de bord cloud classique :

• Pas de VPN nécessaire : aucune installation de profil VPN n'est requise. Tout utilisateur disposant du rôle approprié et d'un navigateur normal peut ouvrir les interfaces d'appareils.
• UI d'appareil authentique : l'utilisateur voit et utilise l'UI originale non modifiée de l'appareil, et non une version simplifiée rendue par Mirox.
• URL unique par appareil : chaque cible accessible possède sa propre URL de la forme <id>.proxy.mirox.io. Cette URL peut être sauvegardée ou partagée (le destinataire doit à son tour être autorisé).
• Entièrement audité : chaque appel, chaque transaction HTTP et chaque connexion WebSocket alimente une piste d'audit conforme KRITIS/NIS2.

Ce que fournit le Proxy

Accès direct aux UI web des appareils

Lorsqu'un exploitant de centrale configure une cible web pour un appareil réseau, cette cible devient accessible via un sous-domaine Mirox unique. Le navigateur voit :

• Une connexion HTTPS classique vers le domaine Mirox avec un certificat wildcard valide
• Le contenu non modifié de l'appareil (HTML, CSS, JavaScript, images, flux, uploads de fichiers, …)
• Une fonctionnalité interactive complète, y compris formulaires, téléchargements de fichiers et flux WebSocket (par exemple consoles en direct, flux vidéo, graphiques en temps réel)

L'utilisateur s'authentifie une seule fois avec Mirox ; la session reste valide pour toutes les UI d'appareils accordées sur toutes les centrales.

Deux couches d'authentification

Important : le Proxy ne gère que le transport et le contrôle d'accès côté Mirox à l'appareil — l'appareil lui-même peut en outre exiger son propre login (généralement nom d'utilisateur/mot de passe, parfois clés API ou tokens spécifiques à l'appareil). Il y a donc deux couches d'authentification indépendantes :

1. Authentification Mirox (appliquée par le Proxy) : qui a le droit d'ouvrir l'appareil ? Vérifié par rapport au login Mirox et aux permissions de la centrale.
2. Authentification de l'appareil (appliquée par l'appareil lui-même) : qui peut effectuer quelles actions sur l'appareil ? Le formulaire de login de l'appareil apparaît simplement dans le navigateur ; l'utilisateur s'authentifie avec les identifiants fournis par le fabricant ou l'exploitant de la centrale.

Mirox enregistre (voir Journalisation d'audit) qui a accédé à quel appareil et à quelles pages — mais l'autorité sur les permissions internes à l'appareil (par exemple « mode maintenance », « changement de configuration ») reste celle du propre login de l'appareil.

Stockage sécurisé des identifiants d'appareil

Afin que chaque membre autorisé du personnel n'ait pas à connaître les identifiants de chaque appareil (et que personne n'ait à mémoriser un mot de passe personnellement ou à le ranger dans un outil non sécurisé), Mirox propose un coffre-fort d'identifiants centralisé et chiffré. Les exploitants de centrale peuvent y stocker une fois les identifiants d'accès de leurs appareils, après quoi ils sont mis à disposition de manière pratique aux utilisateurs autorisés lorsqu'ils ouvrent la cible web — sans distribuer les mots de passe en clair.

Avantages :

• Pas de distribution de mots de passe en clair par e-mail, chat ou post-it.
• Utilisation auditable : qui a accédé à quoi en utilisant les identifiants stockés est capturé dans la piste d'audit KRITIS/NIS2.
• Rotation centralisée : quand un mot de passe d'appareil change, il est mis à jour une seule fois dans Mirox et est immédiatement effectif pour tout le personnel autorisé.
• Liée aux permissions : l'accès aux identifiants stockés suit les mêmes permissions de centrale et de rôle de job que l'accès à l'appareil lui-même.

Accès par défaut et cibles web supplémentaires

Pour chaque appareil réseau découvert par le système, le port web standard est auto-détecté et rendu accessible sans configuration supplémentaire. Les appareils nouvellement découverts peuvent donc être examinés immédiatement dans le navigateur, sans que l'exploitant de la centrale ait à configurer quoi que ce soit au préalable.

Si un appareil possède plusieurs interfaces web pertinentes (par exemple une UI de service, un tableau de bord de diagnostic séparé et une page de configuration), l'exploitant de la centrale peut définir des cibles web supplémentaires. Chaque cible web reçoit un nom significatif et sa propre URL Mirox, afin que toutes les interfaces soient disponibles proprement côte à côte.

Chaque cible web — y compris l'accès par défaut — peut être individuellement activée ou désactivée par l'exploitant de la centrale. Une cible web désactivée n'est plus accessible via le proxy, tandis que toutes les autres cibles de l'appareil et de la centrale continuent de fonctionner. Cela rend l'accès proxy contrôlable à une granularité fine, sans verrouiller toute la centrale.

Protocoles pris en charge

• HTTP (toutes méthodes, y compris uploads de fichiers de taille arbitraire)
• Endpoints HTTPS (TLS se termine à l'agent de la centrale)
• WebSockets, entièrement bidirectionnels
• Server-Sent Events (SSE) et autres flux à longue durée (pas de limite de temps sur l'ensemble de la session)
• Téléchargements de fichiers (en streaming, pas de limite de taille)

Messages d'erreur résilients

Lorsque quelque chose ne fonctionne pas, le proxy renvoie un message d'erreur clair avec des informations de diagnostic au lieu d'une page 502 anonyme. L'utilisateur peut voir, par exemple, si

• l'appareil cible n'est pas joignable,
• l'agent de la centrale n'est pas encore prêt,
• la centrale n'a pas d'agent data-scraper installé,
• ou si une réponse est effectivement venue de l'appareil lui-même.

Ces informations sont utiles pour le dépannage sans que l'utilisateur ait à consulter des fichiers de log.

Sécurité et contrôle

Authentification via le compte Mirox

Le Proxy nécessite un cookie Mirox valide. Les navigateurs non connectés sont redirigés vers la page de login Mirox classique et, après une connexion réussie, automatiquement redirigés vers l'appareil demandé.

Vérification de permission par centrale

À chaque requête, le système vérifie si l'utilisateur connecté a la permission nécessaire pour cette centrale spécifique. La vérification respecte l'ensemble du système de permissions, y compris l'appartenance à l'organisation, les coopérations et les rôles de job. Sans la permission requise, l'utilisateur reçoit une réponse 403.

Gestion sûre des redirections

Si l'appareil cible émet ses propres redirections (par exemple après un login vers une URL interne différente), le proxy les normalise afin que le navigateur ne voie jamais d'adresses internes Mirox ni d'IP de centrale. L'URL reste systématiquement sous la forme <id>.proxy.mirox.io.

Endpoint de diagnostic pour les vérifications de connectivité

Un endpoint de diagnostic réservé permet à un opérateur de vérifier que l'authentification côté plateforme et le routage fonctionnent correctement — sans contacter un appareil spécifique. Cela permet de distinguer les problèmes de plateforme des problèmes de centrale.

Audit et conformité

Chaque appel via le Proxy alimente une piste d'audit conforme KRITIS/NIS2 au niveau 7 (HTTP). La piste d'audit capture :

• Qui a effectué la session (snapshot du compte et de l'e-mail au début de la session)
• Quel appareil et quelle cible web ont été utilisés
• Quand la session a commencé et s'est terminée
• Nombre de requêtes et méthodes HTTP utilisées
• Volume de données transféré (entrée/sortie)
• Les URL réellement appelées (les query strings sont expurgées)
• Adresse IP publique, localisation et informations du navigateur de l'utilisateur
• Une courte description générée par IA de l'activité (« Changement de configuration sur onduleur », « Accès en lecture à la page de diagnostic » …). Si l'IA est indisponible à la clôture de la session, la description est complétée ultérieurement — elle fait partie intégrante de chaque session, elle n'est pas optionnelle.

Une session est automatiquement fermée lorsque 10 minutes d'inactivité se sont écoulées. Toute activité ultérieure démarre une nouvelle session.

La piste d'audit du Proxy est présentée dans un aperçu d'accès unifié avec la piste d'audit du VPN pour l'exploitant de la centrale et est conservée pendant au moins 730 jours. Pour plus de détails, voir Journalisation d'audit.

Distinction par rapport aux fonctionnalités liées

Fonctionnalités associées

• VPN — tunnel personnel pour les outils au-delà du navigateur
• Journalisation d'audit des accès — aperçu d'accès unifié de toutes les sessions VPN et Proxy
• Système de permissions — rôles, permissions au niveau du job et coopérations
• Inspecteur de réseau local — découverte automatique de nouveaux appareils réseau