L'approche d'enregistrement de session par défaut consiste à prendre une capture d'écran toutes les quelques secondes. Le résultat est un index rempli d'images qui se ressemblent — l'utilisateur lit la page, l'utilisateur lit la page, l'utilisateur lit encore la page — avec de vrais événements importants intercalés, quelque part entre deux instantanés qui arrivent trop tard et ne montrent que le résultat.
La capture périodique manque aussi la réponse à la question la plus importante pour tout audit ou investigation : qu'a fait l'utilisateur ? Un instantané pris 1,5 seconde après un clic ne montre pas ce qui a été cliqué. Un instantané pris 3 secondes après une soumission de formulaire ne montre pas ce qui a été saisi. L'enregistrement d'audit contient des événements sans contexte ; les captures d'écran contiennent du contexte sans événement. Les relier est un travail manuel qui passe mal à l'échelle avec le nombre de sessions.
ZeroLeak utilise une approche différente. Les captures d'écran sont déclenchées non par un minuteur, mais par les événements eux-mêmes. Les navigations capturent deux captures d'écran — la page avant le clic et l'après chargement de la nouvelle page — de sorte que cause et effet sont préservés en paire. La position de la souris est dessinée sur chaque capture, pour qu'on puisse voir ce qui a été cliqué. Les saisies clavier sont mises en mémoire tampon en mots lisibles. En dessous, une vidéo continue est enregistrée, de sorte que les intervalles entre les événements capturés restent rejouables si nécessaire.
Pour chaque session, trois sous-systèmes d'enregistrement fonctionnent en parallèle : captures d'écran déclenchées par événement aux instants critiques, vidéo FFmpeg continue à la fréquence d'images configurée, et enregistrement d'événements structuré avec saisie clavier mise en mémoire tampon par mots et activité complète du presse-papiers. Chacun peut être activé et désactivé par service protégé ; par défaut, les trois fonctionnent ensemble, de sorte que la reconstitution est toujours possible.
Les captures sont déclenchées par les actions réelles de l'utilisateur — clics, navigations de page, soumissions de touche, soumissions de formulaire, opérations du presse-papiers. Pas de polling temporel qui remplit le disque d'images vides. Chaque capture d'écran saisit un instant important ; l'index est court et informatif, et non long et bruyant.
Sur chaque capture d'écran prise, la position de la souris est marquée par un indicateur visible — un point rouge aux coordonnées exactes du clic ou du survol. Vous voyez ce sur quoi l'utilisateur a cliqué, et non la page résultant du clic. Une reconstitution de l'intention en une seule image, et non un puzzle à plusieurs images.
Lorsque l'utilisateur navigue, deux captures d'écran sont prises — l'une de la page avant le clic, l'autre de la page cible après le chargement complet du nouveau contenu. Cause et effet sont préservés en paire. Le réviseur voit « l'utilisateur a cliqué sur le lien X, la page suivante chargée était Y » sous forme de deux images contiguës.
Les événements de touche individuels s'accumulent dans un tampon vidé sur l'espace, l'entrée, la tabulation ou une courte pause. Le résultat se lit comme le texte que l'utilisateur a saisi, et non comme un déversement d'événements touche par touche. Les retours arrière sont préservés comme marqueur [BS], de sorte que les corrections sont visibles. Les touches répétées (maintenues) sont filtrées. Les opérations du presse-papiers sont enregistrées séparément avec leur contenu réel.
Chaque mécanisme de capture peut être configuré indépendamment par service protégé et fonctionne sans impact sur les performances de la session utilisateur. Les trois flux (captures d'écran, vidéo, enregistrement d'événements) sont alignés par horodatage, de sorte que le réviseur peut passer de l'un à l'autre sans rupture.
Les captures d'écran sont déclenchées aux clics de l'utilisateur, aux navigations (avec paire avant-et-après), aux soumissions de formulaire, aux soumissions de touche (Entrée), aux opérations du presse-papiers (copie, coupe, collage), aux captures déclenchées manuellement depuis la console opérateur et à plusieurs autres types d'événements importants. La liste complète des événements se configure par service protégé.
Lors d'une navigation, la capture d'écran de la cible n'est prise qu'après la fin du chargement de la nouvelle page — en attendant la mise au repos du réseau plus un court délai de rendu supplémentaire. La capture d'écran prise montre la page telle que l'utilisateur la verra réellement, et non un état intermédiaire à moitié chargé.
Sous les captures d'écran déclenchées par événement, la session est enregistrée en continu sous forme de vidéo en utilisant x11grab de FFmpeg. La fréquence d'images est configurable (10 fps par défaut pour des fichiers compacts ; des fréquences plus élevées sont disponibles pour une capture à haut détail). La vidéo est segmentée pour un flux et un replay sûrs ; les segments sont horodatés pour s'aligner avec les flux de captures d'écran et d'enregistrement d'événements.
Les événements de touche s'accumulent dans un tampon vidé aux frontières de mots (espace, entrée, tabulation) ou après une courte pause inactive. La chaîne vidée se lit comme du texte — « bonjour le monde [BS][BS][BS][BS][BS]salut le monde » — préservant l'intention et les corrections de l'utilisateur sans le bruit de chaque événement keydown individuel.
Les opérations de copie, coupe et collage sont enregistrées séparément des saisies clavier, y compris le contenu réel du presse-papiers concerné. Un réviseur voit exactement ce qui a été copié et collé, et non seulement qu'un événement de presse-papiers s'est produit.
Les captures d'écran sont numérotées séquentiellement (0001, 0002, ...) et stockées avec l'horodatage et les métadonnées d'événement. La console opérateur les liste avec l'événement qui les a déclenchées, de sorte que le réviseur peut sauter directement à l'instant qui l'intéresse — par exemple toutes les captures déclenchées par le presse-papiers dans une session, ou la paire de navigation autour d'une URL précise.
Au-delà des captures d'écran et de la vidéo, un enregistrement d'événements structuré capture l'historique d'interaction de l'utilisateur avec le contexte complet. Chaque événement a un type, un horodatage, une référence de capture d'écran associée (le cas échéant) et son payload pertinent. C'est ce qui rend l'enregistrement non seulement parcourable visuellement, mais recherchable et analytiquement utile.
Chaque événement de clic enregistre les coordonnées x/y et l'élément DOM sous le curseur (balise, classe, ID, contenu texte lorsqu'il est présent). Le réviseur peut rechercher dans l'enregistrement de session les clics sur un bouton ou un lien précis, sans avoir à parcourir les captures d'écran pour en chercher un.
Les changements de position de défilement sont enregistrés de manière throttled pour éviter le spam de journaux. Une résolution suffisante pour reconstituer où l'utilisateur regardait sur les longues pages, mais sans produire des milliers d'événements de défilement superflus par minute.
Chaque navigation — chargements de page complets, changements pushState d'applications monopage, changements de position programmatiques — est journalisée avec l'URL source, l'URL cible, le déclencheur (clic de lien, manuel, programmatique) et le temps d'achèvement. Les navigations SPA que la journalisation traditionnelle manque sont captées par la couche de polling d'URL de ZeroLeak.
Lorsque l'utilisateur soumet un formulaire, l'enregistrement d'événements capture l'URL d'action du formulaire, sa méthode et les noms des champs. Les valeurs réelles des champs sont capturées via l'enregistrement de la saisie clavier (afin que l'historique de saisie soit préservé), et ne sont pas répétées dans l'événement de formulaire.
La couche d'entrée de session surveille l'activité de l'utilisateur. Les transitions entre les états actif et inactif sont enregistrées avec horodatages, de sorte que les réviseurs peuvent voir les périodes d'attention et l'inactivité — utile pour la revue de conformité et les questions d'audit basées sur le temps.
En fin de session, des métadonnées de synthèse sont enregistrées : durée totale, répartition inactif-actif, total d'événements par type, captures d'écran produites, références des fichiers vidéo et motif de terminaison (expiration, terminaison manuelle, erreur). Si un webhook de coordinateur est configuré, ce résumé lui est aussi déclenché.
Des régulateurs qui demandent ce qu'ont fait des utilisateurs précis dans des sessions précises — revue HIPAA d'accès aux dossiers patient, conformité des salles de marché financières, audits de traitement des données publiques. La capture déclenchée par événement produit par session une trace courte et informative que les réviseurs peuvent parcourir rapidement.
Lorsqu'une fuite ou une violation de politique est suspectée, l'enquêteur doit savoir exactement ce que l'utilisateur a fait — et pas seulement quand. Les captures d'écran séquentielles avec marquage de souris, les saisies clavier mises en mémoire tampon par mots et le contenu complet du presse-papiers rendent la session rejouable en détail sans regarder des heures de vidéo.
Des utilisateurs externes recevant un droit de consultation uniquement sur votre environnement. Un enregistrement complet par session — accompagné d'un filigrane visible qui identifie l'utilisateur — assure la responsabilité pour tout ce qu'ils ont vu et chaque action qu'ils ont effectuée pendant la fenêtre d'accès.
Après un événement inattendu sur une console SCADA ou opérationnelle, l'enregistrement montre exactement ce que l'opérateur a vu dans les instants précédents et sur quels contrôles il a cliqué. La paire avant-et-après à la navigation accélère grandement le diagnostic des erreurs en cascade.
Nous ouvrirons une session, cliquerons sur quelques liens, remplirons quelques formulaires, copierons du contenu et montrerons l'index de captures d'écran résultant, l'enregistrement clavier et les segments vidéo — ainsi que la façon dont un réviseur reconstitue la session à partir d'eux.