Base de connaissances

Notes de version : version de septembre 2026

release
active-defense
audit-pack
realm-overview

Notes de version : version de septembre 2026

Date de publication : 17 septembre 2026 Public cible : administrateurs d'entreprise, SRE et RSSI

Cette version couvre l'ensemble des changements livrés entre la version 1.2.0 de l'agent StateWarden (13 juillet 2026) et le 17 septembre 2026. La capacité phare est Ransomware Protection (Active Defense) : les agents détectent désormais les schémas d'écriture caractéristiques des ransomwares pendant les sauvegardes et exécutent de façon autonome une politique de réponse configurable, pouvant aller jusqu'au verrouillage réseau de l'hôte affecté. Cette version ajoute également le rapport de preuves Audit Pack pour les audits NIS2/KSC/BSIG, une page cockpit Aperçu du Realm, la propagation des époques de clés sur l'ensemble de la chaîne de sauvegarde, un reporting strict des échecs de sauvegarde, ainsi qu'une série de corrections des analyses Vigil à l'échelle du parc.

Les notes de disponibilité pour les déploiements progressifs figurent à la fin de ce document ; toutes les versions de composants ne sont pas nécessairement disponibles en disponibilité générale au moment de la rédaction.


Ransomware Protection (Active Defense)

Réponse autonome aux ransomwares (agent 1.5.0, 8 septembre)

  • Détection basée sur l'entropie dans le pipeline de sauvegarde : les fragments modifiés sont analysés à la recherche de schémas d'écriture à entropie élevée pendant l'exécution de la sauvegarde. Les seuils de détection sont configurables : nombre minimal de fragments modifiés (50 par défaut, soit environ 50 Mo), plafond d'entropie (7.8 par défaut sur une échelle de 0 à 8) et ratio de données modifiées (0.90 par défaut - 90 % des données modifiées doivent correspondre au schéma).
  • Exécuteur de réponse : en cas de détection, l'agent exécute immédiatement la politique configurée, sans attendre d'instruction du plan de contrôle. L'agent 1.5.0 implémente deux actions : Mettre la sauvegarde en quarantaine (la sauvegarde se termine mais est marquée) et Alerte uniquement (la sauvegarde est interrompue et rapportée comme échouée avec un motif correspondant).
  • Piste d'audit : chaque détection est consignée dans le journal d'audit avec l'action configurée et son résultat d'exécution. Les sauvegardes terminées sous quarantaine sont marquées comme potentiellement infectées et signalées comme telles dans le Dashboard, y compris par un avertissement dans la boîte de dialogue de restauration.
  • Le Dashboard restreint la gestion des politiques de réponse en fonction de la version de l'agent.

Verrouillage réseau et mise hors tension (agent 1.6.0, 9 septembre)

  • Verrouillage réseau : une politique réseau de type « default-deny » appliquée sur l'hôte. Le verrouillage ne préserve que le canal de contrôle Artemis et la cible de stockage Driad active, plus le DNS (udp/53) et le NTP (udp/123) : le canal de gestion reste ainsi opérationnel, ce qui rend le verrouillage réversible à distance. Sous Linux, l'agent utilise nftables (table dédiée inet statewarden_lockdown) avec un repli sur iptables ; les règles utilisateur existantes ne sont jamais purgées. Sous Windows, il configure la politique du profil pare-feu pour bloquer le trafic entrant et sortant, et ajoute des règles d'autorisation déterministes. L'état de verrouillage est persisté sur disque et réappliqué au démarrage : il survit donc à une réinitialisation brutale.
  • Mise hors tension : déclenche une extinction système différée (20 s). Ce délai garantit que les événements d'audit et le rapport de tâche final sont transmis avant l'arrêt de la machine.
  • Réversibilité : un hôte verrouillé peut retrouver un réseau normal depuis le Dashboard. L'action est protégée par un défi MFA et consignée dans le journal d'audit.
  • Ces deux actions exigent l'agent 1.6.0 ou plus récent. Les agents plus anciens (1.5.0) qui reçoivent une politique de verrouillage ou de mise hors tension se replient en toute sécurité sur Alerte uniquement et consignent cette dégradation dans le journal d'audit.

Gestion des politiques de réponse (WebAPI 0.7.0 / 0.8.0, 9 septembre)

  • Valeurs par défaut du Realm et remplacements par appareil : les politiques de réponse sont gérées au niveau du Realm, avec des remplacements par appareil. Toute modification de politique exige une confirmation MFA et est consignée dans le journal d'audit du realm.
  • Push de la politique effective : la politique effective (remplacement de l'appareil, sinon valeur par défaut du realm, sinon valeurs intégrées) est calculée côté serveur et poussée automatiquement vers les agents. Les agents ne résolvent jamais l'héritage eux-mêmes. Les machines virtuelles sont couvertes par la politique de l'agent de leur hyperviseur parent - un agent applique une politique.
  • Valeur par défaut intégrée : les Realms sans politique enregistrée restent protégés : la valeur par défaut intégrée déclenche une alerte et met la sauvegarde en quarantaine, avec les seuils standard. Effacer une politique ramène à cette valeur par défaut au lieu de désactiver la protection.

Dashboard : page Protection anti-ransomware

  • Une nouvelle page Protection anti-ransomware (/active-defense) gère les valeurs par défaut du realm : sélection de l'action de réponse (Mettre la sauvegarde en quarantaine / Alerte uniquement / Verrouillage réseau / Mise hors tension), seuils d'entropie avec exemples en ligne, et méthodes de détection.
  • Un onglet de remplacement par appareil dans la boîte de dialogue des détails de l'appareil affiche chaque champ avec un badge HÉRITÉ ou PERSONNALISÉ, avec réinitialisation en un clic vers l'héritage.
  • Le verrouillage réseau et la mise hors tension ne sont sélectionnables que pour les appareils exécutant l'agent 1.6.0 ou plus récent ; les appareils sous des agents plus anciens sont étiquetés en conséquence et se replient sur Alerte uniquement.
  • Les appareils sous verrouillage actif affichent un badge VERROUILLAGE RÉSEAU avec une action Rétablir le réseau. Les sauvegardes infectées affichent un badge POTENTIELLEMENT INFECTÉE dans les listes de sauvegardes et une bannière d'avertissement dans le flux de restauration.

Fiabilité des sauvegardes et gestion des clés

Propagation des époques de clés (agent 1.3.0, 3 septembre)

La rotation des clés laissait auparavant des lacunes pouvant produire des sauvegardes silencieusement non restaurables (manifestes mélangeant ancienne et nouvelle clé) ou rapporter comme completed des sauvegardes écrites avec une clé révoquée. Les époques de clés se propagent désormais de bout en bout :

  • Blocage préliminaire en cas de clé obsolète : lorsque l'époque de clé du serveur est plus récente que celle de l'agent, la sauvegarde est interrompue avant toute écriture de données, avec un motif d'échec explicite, au lieu de produire une sauvegarde invalide.
  • Validation d'époque CBT : l'état de suivi incrémental lié à une époque de clé précédente est abandonné et ré-étalonné sous Linux comme sous Windows ; la première sauvegarde après une rotation est automatiquement une base complète.
  • Sauvegardes complètes forcées : une base complète est forcée automatiquement chaque fois que la chaîne l'exige - lors d'un déclenchement manuel, sur une chaîne de sauvegarde vide ou lors d'un changement d'époque de clé. Chaque sauvegarde consigne l'époque de clé sous laquelle elle a été écrite.
  • Dashboard : les sauvegardes écrites sous une époque de clé précédente affichent l'état CLÉ OBSOLÈTE, et Sauvegarder maintenant propose un chemin « Forcer une sauvegarde complète ».

Résilience des échecs de sauvegarde (agent 1.4.0, 6 septembre)

  • Reporting honnête des échecs : les sauvegardes planifiées et tous les chemins de code Proxmox rapportent désormais Failed au lieu d'abandonner silencieusement les erreurs ; une sauvegarde de VM ne rapporte plus Completed lorsque le téléversement du manifeste a échoué.
  • Détection des tâches bloquées : Artemis détecte les sauvegardes sans progression pendant 30 minutes. Les agents arrêtés en pleine sauvegarde sont détectés grâce à un journal en vol sur disque et à un rapport de statut final envoyé lors d'un arrêt propre.
  • Des conséquences visibles : les sauvegardes échouées reçoivent un motif d'échec structuré, sont purgées du stockage (artefacts de la sauvegarde uniquement - les fragments partagés avec des sauvegardes saines ne sont jamais touchés), apparaissent dans l'interface avec un motif localisé et déclenchent une notification par e-mail aux membres du realm.
  • Reporting de progression : la progression des sauvegardes est désormais rapportée en pourcentage réel, en plus des compteurs d'octets.

Améliorations de l'UX de sécurité (Dashboard 0.6.0 / WebAPI 0.9.0, 14 septembre)

  • Le panneau APPAREILS PRIORITAIRES de la page Paysage des menaces classe le parc selon les détections critiques, les détections actives et le score de risque, avec des liens profonds vers le triage.
  • Triage des vulnérabilités : filtre par appareil avec compteurs, vue regroupée par appareil, liens profonds (?device=<uuid>), lignes cliquables avec boîte de dialogue de détails de la constatation, et décisions de triage groupées pour jusqu'à 500 constatations à la fois.
  • Exports et rapports : export CSV respectant les filtres actifs, et rapports PDF par appareil ou par realm générés à la demande, avec une section de notes lignée optionnelle pour les flux de travail papier.
  • Les réponses de constatations incluent désormais le nom d'appareil/nom d'hôte, et la recherche dans l'historique correspond aux noms d'appareils.
  • Badge Aucune donnée : les appareils jamais analysés (par ex. les VM sans agent) n'affichent plus un badge vert « Sécurisé » - ils affichent un état neutre « Aucune donnée » jusqu'à la fin de la première analyse.

Corrections des analyses Vigil (agent 1.6.2, 14 septembre)

Trois bogues indépendants et multiplateformes s'étaient cumulés et avaient silencieusement désactivé les analyses de sécurité planifiées sur une grande partie du parc :

  • Analyses du système de fichiers en échec sur tout le parc depuis avril : un défaut dans le téléversement des rapports d'analyse entraînait le rejet comme non autorisé de chaque rapport d'analyse de logiciels malveillants. Corrigé ; la première analyse du système de fichiers réussie à l'échelle du parc depuis le 24/04/2026 a été enregistrée la nuit même.
  • Planification d'analyse par défaut manquante : les agents n'ayant jamais reçu de push de configuration n'avaient aucune planification de sécurité. Le planificateur se replie désormais sur des valeurs intégrées (inventaire toutes les 1440 min, analyse de logiciels malveillants toutes les 720 min) et s'auto-répare à l'exécution suivante - les appareils affectés se rétablissent sans intervention manuelle au fil de leur mise à jour.
  • Analyses planifiées à zéro fichier : le déclencheur d'analyse manuelle pouvait fuiter dans les chemins d'analyse planifiée, produisant des analyses à zéro fichier. Cela est désormais empêché côté agent.
  • Visibilité des échecs : les échecs d'analyse sont désormais consignés comme événements d'audit (Artemis 0.6.1), visibles dans les journaux des appareils et les notifications, et les heures de fin d'analyse sont correctement enregistrées.

Audit Pack (WebAPI 0.10.0 / Dashboard 0.7.0, 14 septembre)

Rapports de preuves d'audit

  • Jeu de données de preuves d'audit : l'Audit Pack produit un jeu de données structuré de preuves d'audit pour une période sélectionnable (90 jours par défaut, 400 maximum) et un profil de juridiction. L'accès exige la permission realm.view_audit_logs ; chaque génération de rapport est elle-même consignée dans le journal d'audit.
  • La nouvelle page Dashboard /audit-pack génère à la demande un PDF pour les audits NIS2, avec des profils de juridiction pour le socle UE, la Pologne (KSC), l'Allemagne (BSIG/NIS2UmsuCG) et la France (ReCyF - clairement indiqué comme en attente de promulgation).
  • L'ossature du rapport est une matrice de couverture des exigences associant chaque exigence légale à ses preuves (couvert / partiellement couvert / non couvert), plus des annexes de preuves (membres, sessions, événements d'authentification, audit des modifications, posture de sauvegarde, historique des restaurations, posture de sécurité, infrastructure, versions).
  • Les exigences organisationnelles qu'un logiciel ne peut pas démontrer (formation, politique de gestion des risques, chaîne d'approvisionnement, RH, sécurité physique) sont couvertes par une liste d'attestation client imprimée sous la mention CUSTOMER DECLARATIONS.

Journalisation d'audit étendue

  • Un nouveau journal d'audit des comptes consigne les événements d'authentification, de MFA, de session, d'enregistrement et de paramètres de compte, avec l'adresse IP et l'agent utilisateur.
  • La couverture du journal du realm a été étendue aux changements d'appartenance IAM, aux modifications de politiques de sauvegarde, au cycle de vie des codes d'appairage, aux règles de suppression et aux décisions de triage des vulnérabilités.
  • Artemis 0.7.0 ajoute des événements d'audit pour l'ensemble du cycle de vie de l'appairage : appairage d'appareil, appairage de récupération et tentatives d'appairage rejetées.

Agent 1.7.0 : mises à jour vérifiées et événements d'audit de restauration/mise à jour

  • Vérification des mises à jour OTA (double mode) : l'updater vérifie le hash SHA256 des charges utiles de mise à jour. Un hash bien formé est appliqué en mode fail-closed (non-concordance = mise à jour rejetée) ; les charges utiles sans hash bien formé empruntent le chemin historique, élèvent l'événement de début de mise à jour au niveau WARNING et marquent tous les événements de mise à jour comme non vérifiés par hash. Le TLS vers le serveur de distribution est désormais strict (certificat reconnu publiquement exigé). L'application du hash deviendra obligatoire dans une version future, une fois que le parc exécutera le nouvel updater.
  • Nouveaux événements d'audit : le démarrage de l'agent, le cycle de vie des mises à jour, le début des sauvegardes et les résultats des restaurations bare-metal sont désormais consignés.
  • Résultats de restauration véridiques : les restaurations Proxmox partiellement échouées sont désormais rapportées comme échouées au lieu de terminées, et ne redémarrent plus automatiquement la VM après un échec partiel. Les restaurations réussies rapportent les nombres de fragments et d'octets.

Aperçu du Realm (WebAPI 0.11.0 / Dashboard 0.8.0, 16 septembre)

  • Un nouveau cockpit /overview répond à la question « que se passe-t-il dans mon realm en ce moment » à partir d'une vue d'ensemble unique calculée côté serveur.
  • Tuiles KPI : état du parc (en ligne/hors ligne, couverture de protection sur 7 jours), sauvegardes des dernières 24 h (octets transférés inclus), posture de sécurité, action Active Defense effective protégeant le realm (avec un indicateur Par défaut/Personnalisé), quota de stockage avec coloration par seuil, taux de déduplication avec une répartition en trois étapes (taille de restauration → taille des données dédupliquées → sauvegardes + métadonnées physiquement stockées), et fiabilité des sauvegardes (taux de réussite sur 30 jours, nombre de points de restauration, point de restauration le plus ancien).
  • Graphiques : activité des sauvegardes sur 30 jours (colonnes segmentées par jour, terminées vs échouées) et graphique du flux de données protégées (octets logiques vs transférés par jour).
  • Attention requise : une liste calculée côté serveur des sauvegardes échouées, des sauvegardes potentiellement infectées, des constatations critiques, des appareils hors ligne et des appareils sans politique de sauvegarde, chacun avec un lien profond vers la page concernée. Un flux d'activité récente complète la page.
  • Permissions par section : chaque section est protégée par la même permission que sa page dédiée ; les sections que l'utilisateur ne peut pas voir sont entièrement omises plutôt qu'affichées en grisé. La page s'actualise toutes les 30 secondes.

Maintenance de la plateforme et des agents

  • Agent 1.2.2 : rotation des journaux - journaux quotidiens avec nettoyage automatique des fichiers de plus de 7 jours sous Linux et Windows.
  • Agent 1.2.3 : correction du démontage iSCSI.
  • Agent 1.2.7 : intégration de la cryptographie en cascade.
  • Agent 1.2.11 : corrections de la sauvegarde incrémentale CBT (journal USN) sous Windows.
  • Agents 1.3.1-1.3.4 : corrections d'Instant Mount iSCSI sous Windows - signatures de disque MBR randomisées pour éliminer les collisions de signatures entre disques de sauvegarde montés, et correction de l'attribut OFFLINE persisté par Partmgr qui empoisonnait l'instance de disque PnP réutilisée et forçait chaque montage après le premier démontage à apparaître hors ligne.
  • Agent 1.6.1 : correction du tampon de lecture QMP - les sauvegardes de VM Proxmox échouaient sur les VM dont les réponses QMP dépassaient le tampon de ligne de 4 Kio de l'agent (dépendant de la configuration matérielle, par ex. VM multi-disques).
  • WebAPI 0.8.1 : les codes d'appairage sont désormais générés en majuscules uniquement (A-Z0-9), avec saisie, révocation et appairage insensibles à la casse ; correction du reporting de la taille de restauration (les sauvegardes historiques terminées affichent des tailles de restauration correctes sans aucune migration de données).
  • Installeur MSI Windows : correction d'un échec sur les installations Windows 10 fraîches. Le MSI embarquait auparavant un binaire compilé avec MSVC exigeant le VC++ Redistributable ; il livre désormais le même build de la chaîne d'outils GNU que tous les autres artefacts Windows, et la CI rejette tout binaire Windows qui importe VCRUNTIME140/MSVCP140.

Disponibilité

  • Les agents 1.3.x-1.6.2 sont en disponibilité générale et sont déployés sur le parc via OTA.
  • L'agent 1.7.0 (vérification des hash OTA, nouveaux événements d'audit, résultats de restauration véridiques) est disponible uniquement sur le canal de test au 17 septembre ; le déploiement à l'ensemble du parc suivra la validation du canal de test.
  • L'Aperçu du Realm (WebAPI 0.11.0 / Dashboard 0.8.0) est déployé progressivement, la WebAPI avant le Dashboard. Jusqu'à la fin du déploiement, la page Aperçu peut être indisponible ou afficher des données partielles.

Versions des composants

  • Agent principal (sw) : 1.7.0 (canal de test ; le parc général reste en 1.6.2)
  • WebAPI : 0.11.0
  • Dashboard : 0.8.0
  • Artemis : 0.7.0
  • Vigil : 1.4.0
  • Driad : 0.7.0
  • Hermes : 0.2.0

Cet article vous a-t-il été utile ?