Journalisation d'audit des accès

La plateforme Mirox tient une piste d'audit continue et inaltérable de chaque accès distant aux équipements réseau d'une centrale — chaque session de tunnel VPN (couche 3/4) et chaque requête Proxy (couche 7, HTTP). Cette page décrit exactement ce qui est capturé, jusqu'à quel niveau de détail, qui est autorisé à y accéder et combien de temps les données sont conservées.

La piste d'audit est ce qui rend l'accès aux équipements de la centrale conforme aux règles allemandes KRITIS et à la directive NIS2 de l'UE. Ces réglementations imposent la fenêtre de rétention minimale et les catégories de preuves que l'exploitant doit pouvoir produire — mais le journal d'audit est avant tout un outil de suivi des accès destiné à l'exploitant de la centrale.

Pourquoi cette journalisation d'audit existe

KRITIS et NIS2 obligent les exploitants d'infrastructures critiques (dans notre cas les réseaux des centrales de parcs solaires, parcs éoliens et sites de stockage par batterie) à pouvoir répondre, pour chaque accès distant, aux questions suivantes de manière complète et même des mois plus tard :

• Qui a atteint le réseau interne de cette centrale ?
• Quand la connexion a-t-elle été établie — et pour chaque connexion : quand quel sous-réseau / quel équipement a-t-il été touché pour la première et la dernière fois ?
• Quelle quantité de trafic a été transférée durant la connexion ?
• Quel équipement précis et quel service ont été touchés ?
• Qu'y a-t-il été fait (au niveau HTTP : quelles URL, quelles méthodes) ?

La piste d'audit Mirox couvre toutes ces questions et est conçue pour l'exploitant de la centrale en tant que partie soumise à l'obligation de déclaration — et non pour l'utilisateur qui accède.

Deux voies d'accès, un audit partagé

Les deux mécanismes d'accès de la plateforme sont fusionnés dans une vue d'ensemble unifiée des accès par centrale :

Les deux voies partagent la même base d'identité (le compte Mirox de l'utilisateur) ainsi que la même logique légale de rétention et d'accès. Du point de vue de l'exploitant de la centrale, il existe une seule liste chronologique des accès par centrale, dans laquelle les deux canaux apparaissent côte à côte et peuvent être affinés au besoin.

Profondeur de capture

La piste d'audit est organisée en plusieurs couches de détail. Plus vous descendez dans la hiérarchie, plus l'information devient granulaire :

Couche 1 : Certificat / Identité

La couche supérieure capture, par certificat VPN, un instantané de l'identité de l'utilisateur au moment de l'émission et de la rotation :

• Nom de compte anonymisé
• Adresse e-mail
• Identifiant unique du certificat

Même si l'utilisateur est renommé, supprimé par la suite, ou si le certificat est révoqué, cette identité est préservée.

Couche 2 : Session

Chaque connexion est suivie sous forme de session. Une session est une période d'activité continue du même certificat depuis la même source. Les brèves interruptions de moins de dix minutes comptent toujours comme la même session ; les pauses plus longues créent une nouvelle session.

Par session, nous capturons :

• Qui est connecté (instantané du compte et de l'e-mail au moment de la connexion — préservé même si le compte est supprimé ultérieurement)
• Heure de connexion
• Adresse IP source et attribution géographique (ville, pays)
• Région et nœud ayant terminé la connexion (pour l'analyse de latence)
• Volume total de données (entrant et sortant)

Couche 3 : Volume par sous-réseau (VPN uniquement)

Au sein d'une session, nous capturons, par sous-réseau de centrale touché :

• Quel parc et quel sous-réseau ont été touchés
• Volume de données transféré et nombre de paquets par session et par sous-réseau
• Heure du premier et du dernier contact
• Instantanés du nom du parc et de l'organisation au cas où la centrale serait renommée ou supprimée par la suite

Le bruit tel que les requêtes DNS, le multicast mDNS, les pings ICMP et les comportements de type balayage de ports est filtré et/ou limité en débit, de sorte que la piste d'audit ne contienne que les événements d'usage réels.

Couche 4 : Contacts avec les équipements (VPN uniquement)

La couche VPN la plus fine capture, par équipement cible précis :

• IP de l'équipement, protocole (TCP, UDP, ICMP, ICMPv6, SCTP) et port
• L'équipement correspondant dans l'inventaire de la centrale (nom, type) — s'il est enregistré
• Heure du premier contact au sein de la session
• Nombre d'événements de connexion dans cette session
• Instantanés de tous les identifiants au moment du premier contact

Les interactions sous le seuil (par ex. de simples réinitialisations TCP dues à des clics erronés) sont capturées de manière conservatrice, mais restent reconnaissables comme telles.

Couche 4' : Sessions HTTP (Proxy uniquement)

En parallèle, le Proxy capture, par session au niveau HTTP :

• Compte et e-mail de l'utilisateur qui accède
• Quelle cible web ou quel accès par défaut à l'équipement a été utilisé
• Équipement cible (nom, IP) — avec instantané pour les cas ultérieurs de suppression ou de renommage
• Navigateur, système d'exploitation, adresse IP publique, localisation géographique
• Début et fin de session (fin de session : 10 minutes d'inactivité)
• Nombre de requêtes et leurs méthodes HTTP (par ex. {"GET": 42, "POST": 3, "PUT": 1})
• Volume de données entrant et sortant
• Une trace d'activité de la session basée sur les URL (les chaînes de requête sont caviardées, plafonnée à l'activité la plus récente dans une limite fixe)
• Une courte description de l'activité de la session générée par l'IA pour un tri rapide. Si l'IA est indisponible à la clôture de la session, la description est complétée ultérieurement — elle n'est pas optionnelle mais fait partie intégrante de chaque session proxy clôturée.

Profondeur de détail maximale possible

La profondeur de détail maximale est donc la suivante :

Exemple d'accès VPN :

« L'utilisateur X s'est connecté via VPN le 2026-05-13 à 13:44 depuis l'IP publique 198.51.100.7 (région eu-central, Munich, DE), a adressé le sous-réseau 10.90.69.0/24 du parc 'Parc Solaire Annaburg' durant cette session (12 Mo transférés, premier contact 13:45, dernier 13:54), touchant précisément l'équipement 'Bloc Onduleur 3' (10.90.69.12, TCP/443) (premier contact 13:45, 41 connexions). »

Exemple d'accès Proxy :

« L'utilisateur Y a accédé à la cible web 'Bloc Onduleur 3 – Interface de service' via le Proxy le 2026-05-13 entre 13:46 et 13:55 depuis l'IP publique 203.0.113.42 (région eu-central, Francfort, DE) sur Mobile Safari 26.4 / iOS 18.7 (87 requêtes, dont 84 GET, 3 POST ; 2,3 Mo de volume de réponse, résumé IA : 'Modification de configuration des réglages du tracker MPP'). »

Le VPN comme le Proxy capturent l'IP source publique, la région de terminaison et l'attribution géographique (ville, pays) de la connexion. Pour le Proxy, les informations sur le navigateur et le système d'exploitation entrent en plus dans la piste d'audit (via le User-Agent envoyé par le navigateur), puisqu'elles transitent de toute façon au niveau HTTP. Pour un accès purement VPN (couche 3/4), ces informations sur le client applicatif sont intrinsèquement indisponibles — la plateforme n'y voit que le flux de paquets IP, pas le client applicatif.

Un niveau de détail plus profond (contenu des paquets, corps HTTP complets) n'est délibérément pas capturé, car cela serait à la fois problématique pour la confidentialité et inutile sur le plan opérationnel.

Qui est autorisé à voir l'audit ?

L'accès à la piste d'audit est délimité par la fonction qu'un utilisateur occupe sur la centrale :

• Un Technical Manager ou supérieur sur la centrale peut consulter la piste d'audit de cette centrale. En pratique, cela signifie un Exploitant, un Technical Manager ou un Asset Manager sur la centrale. Les Admins et les Modérateurs sont automatiquement qualifiés, car leur rôle d'organisation correspond à une fonction qualifiante sur chaque centrale de leur organisation (voir le Système d'autorisations pour la correspondance complète rôle-fonction).
• Les coopérants sont inclus : un technicien qui atteint une centrale via une coopération avec la fonction requise peut également voir la piste d'audit de cette centrale. L'accès à l'audit suit le même verrou de fonction que le reste des contrôles de la centrale.
• Les Spectateurs sont refusés. Un Spectateur (et quiconque se situe sous le niveau Technical Manager) ne voit aucune piste d'audit. Le frontend masque entièrement l'onglet du journal d'accès pour les utilisateurs en dessous du seuil.

La plateforme expose la vue d'audit via un point de terminaison d'API dédié au journal d'accès et une vue d'interface correspondante. La modification ou la suppression des enregistrements d'audit n'est pas prise en charge.

Période de rétention et inaltérabilité

• Au moins 730 jours de rétention pour toutes les couches d'audit (certificat, session, volume par sous-réseau, contacts avec les équipements, sessions HTTP). La période de rétention est alignée entre les couches afin que les renvois croisés entre elles se résolvent toujours dans la fenêtre d'audit complète.
• Les champs instantanés de chaque enregistrement d'audit (par ex. nom du parc, nom de l'équipement, nom de l'organisation, compte, e-mail) sont écrits une seule fois : ils sont apposés à la première insertion et jamais mis à jour. Cela garantit l'identité forensique même si l'enregistrement d'origine (utilisateur, centrale, équipement) est supprimé ou renommé par la suite.
• Résolution en direct avec repli : tant que les entités référencées (utilisateur, parc, organisation, équipement) existent encore, la vue d'audit affiche leur nom actuel (par ex. après que la centrale a été renommée). Une fois l'entité supprimée, la vue se replie automatiquement sur l'instantané apposé. La piste d'audit reste ainsi lisible — même des mois ou des années plus tard, après des changements de personnel ou des cessions de centrale.
• Aucun chemin de suppression ou de modification accessible à l'utilisateur : les tables d'audit ne peuvent être modifiées par les opérations normales de l'interface ou de l'API. Elles ne sont touchées que par des événements d'audit automatisés et par le balayage de rétention nocturne après l'expiration des 730 jours.

Comportement en cas de suppressions

Protection contre la falsification des données d'audit

• Les sessions qui ne peuvent pas être attribuées (par ex. parce qu'un en-tête a été retiré) sont tout de même capturées avec une identité vide plutôt que d'être écartées. Une analyse ultérieure peut alors enquêter spécifiquement sur ces cas.
• Les sessions HTTP ne sont pas clôturées par les seuls composants SaaS mais sont clôturées et déclarées par l'agent de la centrale lui-même, de sorte que la plateforme SaaS ne puisse pas sous-déclarer en silence le nombre de requêtes ou le volume.
• Les conditions de concurrence inférieures à la milliseconde lors de la lecture des chaînes de compteurs sont acceptées comme « perte par conception » et documentées comme conformes à KRITIS ; elles ne peuvent au pire affecter qu'un seul cycle de compteur, jamais des sessions entières ou des contacts avec des équipements.

Filtrage et recherche dans la vue d'audit

La vue d'audit permet à un utilisateur autorisé de réduire l'ensemble des résultats :

• Par compte utilisateur
• Par sous-réseau ou IP d'équipement
• Par protocole ou port (voie VPN)
• Par cible web ou équipement précis (voie proxy)
• Par plage temporelle (de … à …)
• Tri par défaut sur « dernière activité »

Le tri par défaut regroupe naturellement par session, de sorte que la question « L'utilisateur X a touché les équipements A et B durant cette session 18:43–19:00, et l'équipement C lors d'une deuxième session 13:44–14:30 » est directement visible sans regroupement supplémentaire côté client.

Confidentialité et divulgation

Ce que la piste d'audit contient :

• Des champs d'identité dérivés du compte Mirox habituel (compte, e-mail)
• Les adresses IP sources de la connexion (légalement requises pour KRITIS)
• L'attribution géographique de la source (ville, pays)
• Volume de données, nombre de requêtes, distribution des méthodes, horodatages

Ce que la piste d'audit ne contient pas :

• Le contenu des corps HTTP individuels
• Le contenu des paquets VPN
• Les frappes au clavier ou les enregistrements d'écran
• Des données non requises pour la déclaration KRITIS / NIS2

Que faire en cas de demande réglementaire

Pour les demandes d'informations consécutives à un incident adressées à l'autorité compétente (par ex. le BSI dans le cadre de KRITIS), toutes les données nécessaires sont disponibles dans la fenêtre de 730 jours via la vue d'audit. Une fonction d'export (par ex. CSV) est prévue en tant qu'action distincte et auditée individuellement, fournie à la demande — un tel export est lui-même une opération soumise à audit, afin qu'il soit documenté qui a exporté quelles données d'audit et quand (« audit de l'audit »).

Fonctionnalités associées

• VPN — tunnel personnel avec capture d'audit complète en couche 3/4
• Proxy — accès via navigateur avec capture d'audit complète en couche 7
• Système d'autorisations — la correspondance rôle-fonction qui décide qui peut ouvrir la vue d'audit
• Coopérations — comment un technicien coopérant se voit accorder (et auditer pour) l'accès à la centrale
• Restrictions de coopération — les limites qui maintiennent l'accès partagé dans le périmètre choisi par le propriétaire