Doogree
Réponse · Remédiation

Corriger avec consentement : remédier sans franchir la ligne

06/07/2026 · ~5 min de lecture
RemédiationNIST RespondTOFUCanal de contrôle signé

La détection n'est que la moitié du travail. L'autre moitié, c'est la correction — mais une remédiation automatique aveugle est exactement aussi dangereuse que le problème lui-même. L'approche de Doogree est simple : nous ne corrigeons pas dans votre dos. Chaque problème corrigible apparaît sous forme de suggestion, quelqu'un l'approuve, et alors seulement une action connue, encadrée et réversible se met en route.

L'anatomie d'une suggestion de correction

Chaque problème corrigible ne s'exécute pas de lui-même — il est proposé. L'opérateur voit trois boutons : Approuver / Corriger, Pas maintenant, Ignorer. Toucher Approuver envoie une action modélisée, sur liste d'autorisation — et non une commande shell arbitraire — puis le système revérifie l'état et exécute à nouveau la boucle jusqu'à ce que le problème soit résolu ou ignoré. Il n'y a pas de « tout corriger d'un clic » tournant dans l'ombre ; il y a une courte chaîne : suggestion → approbation → action → vérification.

Une suggestion, pas une exécution. Par défaut, c'est toujours l'humain (ou, plus tard, une politique définie) qui reste dans la boucle. Une action significative ne se produit jamais sans consentement explicite, et chacune dispose d'une piste d'audit complète — qui a approuvé, ce qui a été envoyé, et quel a été le résultat.

Pourquoi il n'y a pas de shell libre — le modèle de confiance

Le secret, c'est que les actions ne sont pas « exécute cette commande ». Les actions contre un serveur sont envoyées sur un canal de contrôle signé et épinglé par TOFU (Trust On First Use) : la forme canonique de la commande est signée, de sorte qu'un rejeu ou une altération est détecté immédiatement. Il n'y a pas de shell libre — seulement des actions issues d'une liste d'autorisation, appelées par leurs noms explicites. La conséquence pratique : même si un cloud ou une base de données est compromis, un attaquant ne peut pas forger une commande et la transformer en RCE sur le parc. La frontière entre « détecter » et « exécuter du code sur un appareil » est gardée avec zèle.

Le moindre privilège en action. Chaque action sait exactement ce qu'elle a le droit de faire, et rien de plus. Il n'y a pas de « clé passe-partout » — il y a des clés spécifiques sur liste d'autorisation, chacune n'ouvrant qu'une seule porte et laissant une trace.

Incident critique → bouton de confinement

La correction avec consentement se connecte directement au moteur d'incidents. Lorsque le moteur SIEM-lite replie plusieurs alertes en un incident corrélé de gravité élevée/critique, il propose automatiquement un bouton de confinement. Approuver le bouton agit sur le même canal de contrôle signé — le même modèle de confiance, la même liste d'autorisation, le même audit. Ainsi, la chaîne d'attaque n'est pas seulement détectée et étiquetée — elle reçoit une action de réponse réversible à un clic.

Pourquoi c'est crucial pour une petite entreprise

Une petite entreprise n'a généralement pas d'ingénieur sécurité à temps plein. La correction avec consentement offre à un dirigeant non-expert un bouton « corriger ceci » sûr — entièrement documenté — sans nécessiter un SOC coûteux. Et lorsqu'il s'agit de quelque chose de significatif, l'humain reste dans la boucle ; plus tard, vous pouvez l'encadrer par une politique avec approbation 2FA (approbation par notification push), afin qu'une action risquée ne parte qu'après vérification.

Le cadre théorique : c'est l'étape Respond du NIST — non pas seulement détecter, mais répondre de manière contrôlée. Tout est bâti sur le moindre privilège et sur la sécurité de la chaîne d'approvisionnement : il n'existe aucun canal par lequel un cloud compromis pourrait injecter des commandes arbitraires dans les appareils. La remédiation — oui. Franchir la ligne — jamais.

← Retour au blog · Comment ça marche →