Sécurité et architecture

• Le capteur tourne sur votre hébergement, depuis le planificateur, hors du dossier public. Il n'a aucune règle propre. Il collecte des empreintes et les envoie.
• Le serveur central détient les règles, compare chaque rapport au dernier état sain et décide. La liste des fichiers à surveiller est fixée ici, pas par le capteur.
• Les copies saines de vos fichiers critiques sont conservées sur notre infrastructure, pas sur votre hébergement. Quelqu'un qui entre dans votre compte d'hébergement ne peut pas les remplacer.

• Il s'exécute avec votre propre utilisateur d'hébergement. Il n'a pas besoin d'accès root et n'installe rien sur le serveur.
• Il lit les fichiers de code et, dans la base de données, uniquement les comptes administrateur, les réglages de paiement et quelques réglages de la plateforme, comme l'adresse du site et la liste des extensions.
• Il n'écrit que dans un seul cas : lorsque le serveur central ordonne la restauration d'un fichier de paiement.
• Il ne supprime jamais de fichier. Avant d'en remplacer un, il conserve la version remplacée dans un dossier privé.

• Envoyés : les empreintes des fichiers, le contenu des fichiers de code critiques qui ont changé, les noms d'utilisateur des administrateurs, et les empreintes (pas les valeurs) des e-mails et mots de passe des administrateurs et des réglages de paiement.
• Jamais envoyés : les commandes, les clients, les numéros de carte, ni aucune page vue par vos visiteurs.
• Chaque message est signé dans les deux sens et porte un horodatage et un numéro à usage unique, de sorte qu'il ne peut être ni modifié ni rejoué.

La décision est prise par des règles fixes, pas par une IA. Les mêmes faits donnent donc toujours la même décision, et chacune peut être expliquée. Toutes les conditions suivantes doivent être réunies :

• le fichier est un fichier de paiement ou de commande,
• la modification ajoute une destination de paiement que nous ne reconnaissons pas,
• aucune mise à niveau de la plateforme ou de cette extension n'est en cours,
• une copie saine vérifiée existe.

Toute autre modification est signalée et attend votre approbation. Elle n'est pas annulée.

Avant d'écrire, le capteur vérifie que le fichier sur le disque est toujours exactement celui qui a été analysé, qu'il n'est pas un lien vers un autre endroit et qu'il se trouve bien dans votre site. L'écriture se fait en une seule étape, pour qu'aucun fichier à moitié écrit ne puisse rester. Le capteur confirme ensuite le résultat au serveur central.

La version modifiée est conservée comme preuve. Si la modification était la vôtre, vous la remettez en place depuis votre panneau en un clic. Chaque restauration automatique est accompagnée d'un relevé de décision : la règle, le fichier, la destination, la présence ou non d'une mise à niveau et les empreintes avant et après.

Tests contrôlés sur des boutiques de test, version 1.12 :

• Délai entre l'altération et la restauration, avec un contrôle chaque minute. Nous avons changé l'adresse de paiement dans un fichier de paiement 8 fois, à des moments aléatoires dans la minute. Les 8 fois, la modification a été trouvée et le fichier sain remis en place dès le contrôle suivant : entre 8 et 57 secondes après l'altération, 33 en moyenne. Une fois le contrôle lancé, la détection et la restauration prennent moins d'une seconde ; l'attente dépend donc de l'intervalle de votre formule.
• 100 modifications contrôlées de six types, sur des boutiques de test OpenCart et WooCommerce. Les 100 ont été trouvées et le fichier sain remis en place. Dans la même série, nous avons fait 100 modifications ordinaires de développeur : aucune n'a été annulée et aucune n'a déclenché d'alarme.
• Le fichier change de nouveau entre l'analyse et la restauration. La restauration n'a pas été appliquée, la version plus récente est restée en place et a été contrôlée au passage suivant.
• Le fichier est remplacé par un lien (symlink) avant la restauration. Le capteur a refusé d'écrire et une alerte critique a été envoyée.
• Le même message est envoyé deux fois, ou altéré en chemin. Le second a été rejeté comme rejeu, l'altéré pour signature invalide.
• Le serveur central est indisponible. Le capteur n'a rien changé sur le site. Au retour du serveur, la modification faite entre-temps a été trouvée et le fichier restauré. Tant que le serveur ne répond pas, aucun contrôle n'a lieu.
• Un mot de passe de panneau volé. La connexion était possible, mais pas l'approbation d'une modification : elle exige le code envoyé à l'e-mail du propriétaire. Six codes devinés ont échoué et le propriétaire a été averti.
• Annulation d'une restauration depuis le panneau. Avec le code reçu par e-mail, la modification a été remise en place au contrôle suivant.
• Le fichier du capteur lui-même est modifié, ou il signale soudain beaucoup moins de fichiers. Alerte critique au contrôle suivant.
• Un script provenant d'un domaine ressemblant et un formulaire envoyant des données ailleurs apparaissent sur la page publique. Le contrôle externe a déclenché une alerte critique.
• Ce sont nos propres tests contrôlés sur des boutiques de test, sur la même machine que le serveur central. Ils ne constituent pas un audit indépendant, et une installation réelle ajoute le délai du réseau.

• Les rapports et les approbations ne sont accessibles qu'après connexion. Il n'existe aucun lien de rapport ouvert.
• Les mots de passe sont stockés sous forme hachée. Après cinq tentatives erronées, le compte est verrouillé pendant quinze minutes.
• Approuver une modification ou annuler une restauration demande aussi un code envoyé à ce moment-là à votre adresse e-mail. Un mot de passe de panneau volé ne suffit pas.
• Chaque approbation et chaque annulation est enregistrée avec l'utilisateur et l'adresse d'où elle provient, et envoyée par e-mail au propriétaire et à notre équipe.

Toutes les six heures, notre serveur ouvre aussi vos pages publiques comme le ferait un visiteur, et compare les domaines externes qu'elles chargent avec la fois précédente. Un nouveau script provenant d'un domaine ressemblant ou d'un service ouvert d'hébergement de code, ou un formulaire qui se met à envoyer des données ailleurs, déclenche une alerte. Ce contrôle ne dépend pas du capteur.

• L'historique des événements est conservé 90 jours.
• Les copies saines sont conservées tant que l'abonnement est actif et supprimées à son terme.

• HachiGuard ne remplace ni un pare-feu, ni un antivirus, ni un scan PCI. C'est la couche qui remarque et annule une modification une fois que quelqu'un est entré.
• Un script chargé sur votre page de paiement depuis le serveur d'un tiers peut être modifié sur ce serveur sans qu'aucun de vos fichiers ne change. Nous remarquons un nouveau domaine externe, mais pas une modification à l'intérieur d'un script déjà présent.
• Si l'ensemble de votre compte d'hébergement est pris, un capteur qui tourne à l'intérieur ne peut plus être pleinement fiable. C'est pourquoi les copies saines, les règles et les décisions se trouvent à l'extérieur, et pourquoi un capteur silencieux ou altéré déclenche une alarme.
• Les fichiers encodés ne peuvent pas être lus. Nous les suivons par leur empreinte et signalons chaque modification, mais nous ne les restaurons pas automatiquement.
• Le premier contrôle considère l'état actuel comme sain. Vérifiez vos administrateurs et vos adresses de paiement avant qu'il ne s'exécute.
• La détection se fait à l'intervalle de votre formule. Une modification faite juste après un contrôle est vue au suivant.