Le contrôle de santé traditionnel fonctionne depuis la couche protocolaire : « port ouvert », « renvoie HTTP 200 », peut-être « le contenu de la page contient tel mot ». Ces réponses disent que le serveur rend un service, mais ne disent pas AVEC QUEL contenu il le rend.
Les problèmes modernes vivent justement dans cet écart. Si un attaquant a franchi le WAAP et déposé un webshell sur le serveur, la sonde de santé continue de dire « serveur sain ». Si un déploiement est sorti défaillant, le serveur répond avec un ancien binary mais c'est encore 200 OK pour la sonde protocolaire. Si un opérateur a modifié manuellement le fichier de config, l'écart par rapport à la baseline opère en silence.
À l'échelle d'un cluster, la situation est encore pire. 9 serveurs sur 10 ont la nouvelle version, 1 ne l'a pas ; la sonde de santé les voit tous sains, la requête utilisateur tombe par malchance sur le serveur obsolète. Ou inversement, sur 1 serveur l'attaquant a déposé un nouveau fichier ; le reste du cluster est propre mais le trafic n'est pas retiré de ce seul serveur car personne ne regarde.
L'ETM Intégrité serveur et intelligence de déploiement comble cet écart : l'état des fichiers, répertoires, binary et config sur le serveur est surveillé en continu ; les changements affluent comme événements vers l'ADC et le SOC ; la décision de routing dépasse la coque externe.
L'agent sur le serveur effectue un contrôle continu au niveau du fichier ; il détecte les changements, se lie en direct à la décision de routing de l'ADC et au système d'événements du SOC.
Un hash périodique est calculé pour les fichiers critiques sélectionnés (contenu du webroot, application binary, fichiers de config, certificats TLS). Un hash agrégé de type Merkle est produit pour les arbres de répertoires. Le changement est détecté instantanément par comparaison de hash.
L'ajout d'un nouveau fichier hors de la baseline attendue, la modification d'un fichier existant ou la suppression d'un fichier attendu produit un événement instantané. Un nouveau fichier .aspx/.php/.jsp déposé dans le webroot est signalé comme suspicion de webshell.
Une comparaison de hash est effectuée entre les serveurs offrant le même service applicatif. Un seul serveur restant hors de la distribution attendue (drift ou compromission) est séparé du cluster ; le trafic est redirigé vers les serveurs cohérents.
Lorsqu'un changement est détecté, la politique de trafic de l'ADC peut réagir automatiquement : période de warm-up, routing progressif, isolation temporaire. Lorsqu'un nouveau déploiement est détecté, le trafic passe en douceur ; lorsqu'un changement non autorisé est détecté, le trafic est coupé.
L'intégrité de fichier et l'intelligence de déploiement ne sont pas seulement de la sécurité, mais une partie du mécanisme de décision opérationnel.
Un hash périodique et une intégrité de l'arbre de répertoires sont calculés pour les fichiers de contenu conservés à la racine des vhost du serveur web (HTML, ASP, ASPX, PHP, JSP, JS, CSS, images). L'opérateur définit par politique quels répertoires sont surveillés et quelles extensions sont considérées sensibles. Un changement inattendu se reflète comme événement instantané.
Lorsqu'un attaquant franchit le WAAP et tente de déposer un webshell sur le serveur, l'ETM capte instantanément la nouvelle extension exécutable déposée dans le webroot (p. ex. .aspx, .php, .jsp). Le serveur peut être automatiquement mis en quarantaine, le trafic peut être coupé, le SOC reçoit une alarme. C'est la dernière couche de défense APRÈS le WAAP.
Un changement de hash de l'application binary ou de l'artifact est interprété comme un événement de déploiement. L'ADC attend cet événement : peu de trafic est dirigé vers le serveur jusqu'à ce que les indicateurs de santé soient stables, le plein trafic est ouvert une fois le warm-up terminé. Les étapes manuelles « sortir du load balancer, déployer, remettre » sont automatisées.
Lorsque des fichiers de configuration comme config Apache, config Nginx, IIS application config, unit systemd, définitions cron dévient de la baseline, une alarme est produite. L'opérateur peut intervenir avant un changement non autorisé ; les changements réguliers sont absorbés par une mise à jour de la baseline.
Le hash des binary système critiques, des fichiers de bibliothèque et des outils auxiliaires est comparé à la baseline. Un changement de binary résultant d'un rootkit, d'une compromission de la supply chain ou d'une intervention manuelle est détecté instantanément ; le serveur est mis en isolation, reste ouvert pour la forensique.
Lorsque le propriétaire, les permissions ou les entrées ACL de fichiers et répertoires critiques changent, un événement est produit. Une élévation de privilèges non autorisée, un changement de propriété de fichier ou l'ouverture d'un droit d'écriture sur une configuration sensible deviennent visibles instantanément.
Une comparaison de hash de baseline est effectuée entre les serveurs offrant le même service applicatif. Si 9 serveurs sur 10 correspondent et 1 diffère, celui qui diffère est suspect de drift ou de compromission. Une quarantaine automatique ou une isolation avec approbation opérateur peut être appliquée.
Lorsque l'opérateur ouvre une fenêtre de maintenance, les changements survenus dans cette fenêtre ne produisent pas d'alarme ; la baseline est mise à jour selon la politique. Un événement de déploiement attendu n'est pas interprété comme un « vrai changement » ; un changement surprise déclenche une alarme.
Si, après une nouvelle version, la télémétrie ETM (temps de GC, error rate, fréquence des restart) montre une dégradation, l'ETM l'associe à l'événement de déploiement. Le routing de l'ADC peut donner priorité aux serveurs ayant la version précédente ; l'équipe de rollback est informée automatiquement.
Chaque changement de fichier/configuration/binary est écrit dans l'enregistrement d'audit ; transmis au SIEM. Sur quel serveur, quand, quel fichier a changé de quel hash vers quel hash — une chaîne de preuves complète est prête pour l'audit. Support en direct pour le GDPR Art 32 et les exigences d'audit sectorielles.
La surveillance de l'intégrité n'est pas seulement une fonctionnalité technique, mais une couche de gestion en direct des processus de déploiement et de sécurité d'entreprise.
Quels répertoires sont surveillés, quelles extensions de fichiers sont considérées sensibles, quels fichiers sont ignorés (log, cache, fichiers temporaires) sont définis par politique. Des profils différents peuvent être définis pour le serveur web, le serveur applicatif et le serveur de base de données.
Les fichiers critiques (binary système, certificat TLS) peuvent être hashés de l'ordre de la seconde ; ceux de priorité moyenne (fichiers de config) de l'ordre de la minute ; ceux de faible priorité (contenu statique) à intervalles horaires. La charge IO disque est maintenue sous contrôle.
Les événements d'intégrité sont liés en direct à la politique de routing de l'ADC. Des règles de politique comme « nouveau fichier détecté + contexte d'attaque WAAP présent → isolation », « drift de hash détecté → priorité réduite », « déploiement détecté → warm-up » sont définies par l'opérateur.
Le pipeline CI/CD peut signaler un événement de déploiement à l'API ETM ; l'ETM interprète cet événement comme un changement attendu, déclenche une coordination de routing au lieu d'une alarme. Une fois le déploiement terminé, l'ETM signe la nouvelle baseline.
Les événements à haute priorité comme la suspicion de webshell, le tampering de binary, le drift de cluster sont transmis directement au SOC avec une alarme. L'événement est enrichi : quel serveur, quel fichier, résultat de comparaison de hash, heure de dernière modification, recommandation d'action.
Chaque événement d'intégrité est inscrit dans l'enregistrement d'audit. Lorsque l'auditeur demande « sur quel serveur quel fichier a changé dans les 30 derniers jours ? », une réponse en direct est fournie. La chaîne de preuves est automatisée pour PCI DSS, le GDPR Art 32 et les exigences d'audit sectorielles.
Même si le WAAP n'a pas détecté l'attaque, le nouveau fichier exécutable déposé dans le répertoire vhost IIS du serveur est capté instantanément par l'ETM. Le serveur est automatiquement retiré du cluster, le trafic est coupé, le SOC reçoit une alarme instantanée ; l'appareil reste ouvert pour la forensique.
Lorsque l'équipe DevOps publie une nouvelle version, l'ETM détecte le changement de hash de l'application binary ; l'ADC fait un routing progressif vers le serveur. Lorsque les métriques de santé (CPU, temps de GC, error rate) restent stables, le plein trafic est ouvert. Les processus manuels « sortir du load balancer, deploy, remettre » disparaissent.
Sur 10 serveurs du cluster de production, 9 correspondent à leur hash de baseline ; 1 montre un hash différent. Version obsolète, intervention manuelle ou compromission ? L'ETM met ce serveur automatiquement en quarantaine ; l'opérateur examine la cause. La requête utilisateur ne tombe pas par malchance sur la mauvaise version.
Après la nouvelle version, la télémétrie ETM montre que le temps de GC s'est allongé, que l'error rate a augmenté et que la fréquence des restart s'est élevée. L'ETM l'associe à l'événement de déploiement ; le routing de l'ADC donne priorité aux serveurs ayant le hash de la version précédente. L'équipe de rollback est informée automatiquement ; la décision de déploiement est appuyée par la donnée.
Lorsque le hash d'un binary système critique d'un serveur dévie de la baseline — suspicion de rootkit, de compromission de la supply chain ou de changement non autorisé — le serveur est séparé du cluster, l'accès internet est coupé, seul le canal de gestion ETM reste ouvert. Le SOC réalise une investigation à distance pour la forensique.
Voyons l'ETM Intégrité serveur en direct sur votre propre backend — planifions une session d'installation couvrant la définition de baseline, le binding ADC et le flux SIEM sur un groupe pilote de serveurs.