Traçabilité des accès

Fonctionnalité Pro

Nécessite un abonnement MIA Pro.

La traçabilité conserve, décision par décision, l'histoire de chaque accès : qui a été ouvert, quand, pourquoi, par quel canal, et surtout qui l'a fermé — MIA, ou quelqu'un directement dans l'application. C'est la pièce que réclame un auditeur ISO 27001 au titre des contrôles A.5.18 (droits d'accès) et A.8.15 (journalisation).

Comment ça marche

1. MIA enregistre une entrée à chaque décision prise sur un accès : ouverture, fermeture, échec de fermeture, dissociation, révision des accès, demande d'accès, compte orphelin, arbitrage d'une suppression massive, suppression d'une application.
2. Chaque entrée porte son origine : action manuelle, planification, cascade de départ, kit d'applications, demande d'accès, synchronisation, inventaire initial…
3. L'écran Traçabilité vous laisse filtrer par application, événement, origine et période, puis exporter en CSV exactement ce que vous voyez — le format dont un auditeur a besoin pour tirer un échantillon et le recouper.
4. Chaque nuit, les entrées de la journée sont scellées par lots et chaînées au lot précédent, puis la chaîne entière est vérifiée — lot par lot, sceau par sceau. Le panneau « Intégrité » affiche le résultat de cette vérification et la date à laquelle elle a été faite.

Un inventaire n'est pas une ouverture

Brancher une application de deux cents comptes ne produit pas deux cents ouvertures d'accès : MIA découvre ce qui existait déjà, et l'écrit comme un inventaire. Même chose lorsqu'une application change sa façon d'identifier les comptes, ou lorsqu'une application manuelle devient automatique. Modifier le périmètre qu'une application synchronise relève du même principe : les comptes que vous en retirez quittent l'inventaire, ceux que vous y ajoutez l'intègrent, et aucun accès n'a été ouvert ni fermé sur l'application. Deux autres situations relèvent du même principe : l'import d'un scan d'applications fantômes, qui fait entrer dans MIA des comptes que vos collaborateurs avaient ouverts eux-mêmes bien avant, et le rattachement d'un compte orphelin, qui dit à qui appartient un accès déjà existant sans en ouvrir aucun. Sans cette distinction, votre registre annoncerait des centaines de révocations un mardi matin — ce qu'un auditeur ne lit pas comme un journal, mais comme un incident.

Une fermeture qui échoue

Quand MIA ne parvient pas à fermer un accès, l'échec est inscrit au journal : à chaque tentative pour la suppression d'un utilisateur ou d'un accès et pour la fermeture immédiate d'une demande d'accès, une seule fois pour une fermeture programmée, lorsque ses reprises automatiques sont épuisées. L'entrée porte le code d'erreur de l'application (statut HTTP et code technique), jamais son message, qui cite souvent le compte refusé.

Si l'application refuse la suppression mais que le compte ne figure déjà plus dans sa liste, MIA inscrit l'accès comme fermé hors de MIA plutôt que comme un échec : il l'était déjà.

Une fermeture faite à la main à la demande de MIA

Sur une application où MIA ne peut pas fermer de compte, c'est vous qui fermez le compte, à la date que MIA vous rappelle. Cette fermeture suit le processus de MIA : elle est inscrite comme fermée par MIA, avec la mention d'une fermeture manuelle dans les détails, dès que vous supprimez l'accès en confirmant la fermeture, ou dès que la synchronisation constate la disparition du compte. Sans date de fin, supprimer un tel accès l'inscrit seulement comme dissocié.

Supprimer une application

Supprimer une application de MIA ne ferme aucun compte sur l'application. Le journal inscrit chacun de ses accès comme dissocié et chacun de ses comptes orphelins comme résolu, avec l'origine « Suppression de l'application ». Reconnecter l'application les réinventorie.

Rectifier le journal

Le journal ne se modifie jamais : une entrée reste telle qu'elle a été écrite. Lorsqu'une entrée s'avère fausse, le support de MIA inscrit, à votre demande, une rectification : une nouvelle entrée d'origine « Support MIA » qui cite l'entrée concernée, sous l'une de trois formes.

• Correction : l'entrée dit quelque chose de faux, la rectification donne les faits exacts (événement, origine, heure réelle, type d'acteur).
• Annulation : l'événement n'a jamais eu lieu.
• Ajout tardif : un événement réel n'avait pas été inscrit.

La rectification est datée du jour où elle est écrite, jamais antidatée : l'heure réelle de l'événement fait partie des faits qu'elle porte. À l'écran, l'entrée rectifiée garde son libellé d'origine et porte une pastille « Rectifiée » qui en donne le détail et la raison. Dans l'export, deux colonnes ajoutées en fin de ligne, « Identifiant de l'entrée » et « Rectification », relient les deux lignes. Les filtres et les décomptes portent sur ce qui a été écrit : une rectification ne se fait jamais passer pour l'événement qu'elle corrige.

La raison d'une rectification est inscrite en clair, pour vous et pour vos auditeurs, et ne nomme jamais une personne : elle reste lisible même après l'effacement d'une identité.

Rechercher une personne, effacer une personne

L'identité inscrite dans le journal est chiffrée avec une clé propre à chaque personne. Deux conséquences :

• la recherche par personne se fait sur une adresse e-mail exacte : ni recherche partielle, ni tri alphabétique ;
• effacer quelqu'un au titre du RGPD consiste à détruire sa clé. Ses lignes restent en place et comptabilisées — leur date, leur application, leur type et leur origine demeurent lisibles — mais l'identité devient définitivement illisible. C'est ce qui permet de concilier le droit à l'effacement avec un registre qui doit rester vérifiable.

L'effacement se déclenche depuis l'écran Traçabilité, jamais depuis la suppression d'un utilisateur : c'est une action rare et irréversible, qu'il ne faut pas pouvoir déclencher par réflexe.

MIA le refuse tant que la personne figure encore dans vos utilisateurs, ou tant qu'un compte orphelin porte encore son adresse sur l'une de vos applications : la synchronisation horaire le retrouverait et réinscrirait l'adresse au journal, ce qui rendrait l'effacement fictif. La fenêtre de confirmation vous dit alors quoi nettoyer d'abord.

Si la même adresse revient plus tard — une réembauche, par exemple —, la personne est de nouveau journalisée sous son nom, normalement. Ses lignes d'avant l'effacement, elles, restent définitivement illisibles : l'effacement porte sur ce qui a été écrit jusque-là, jamais sur ce qui viendra ensuite. En recherchant l'adresse, vous retrouvez les deux : les anciennes lignes sous « Personne effacée », l'entrée « Identité effacée » qui en porte la date et l'auteur, puis les nouvelles.

Lien avec la révision des accès

Chaque décision individuelle d'une campagne de révision des accès est inscrite au journal au moment où elle est prise. La clôture d'une campagne remet les statuts à zéro, mais la preuve de la recertification, elle, reste — c'est exactement l'évidence attendue au titre d'A.5.18.

Bon à savoir

• Le journal est conservé 36 mois, une durée fixe et non paramétrable : un réglage permettrait d'abaisser la rétention et de détruire la preuve que la fonctionnalité sert à produire.
• Il est écrit pour tous les comptes, y compris gratuits. Un compte qui passe à Pro découvre donc immédiatement son historique.
• Aucune reprise du passé n'est possible : le journal démarre à sa mise en service.
• La vérification de la chaîne tourne chaque nuit, pas à chaque ouverture de l'écran : elle relit et recalcule l'empreinte de toutes les entrées conservées. Le verdict affiché est donc daté — et une altération est détectée sous 24 h même si personne ne consulte l'écran.
• Le scellement détecte une modification qui ne recalcule pas la chaîne — une écriture directe en base, un bug, un script. Il ne protège pas contre MIA elle-même, ce qui demanderait un dépôt de preuve hors de MIA. Et il prouve l'intégrité du registre, jamais la véracité de ce qui y a été écrit.
• Un compte orphelin sans adresse e-mail est identifié par son identifiant distant : un effacement piloté par une adresse e-mail ne l'atteindra pas.