Serveur compromis : comment l’Infrastructure as Code accélère la reconstruction

DevActif avait détecté une vulnérabilité critique dans une dépendance utilisée par le logiciel d’un client. Le correctif aurait demandé environ une heure. Nous avions recommandé de l’appliquer immédiatement, mais l’intervention a été reportée.

Environ six mois plus tard, un attaquant a exploité précisément cette vulnérabilité pour infiltrer le serveur. L’analyse technique a confirmé le vecteur d’entrée. La récupération complète a demandé près de 40 heures.

Ce cas demeure volontairement anonyme. L’enjeu n’est pas de raconter l’attaque, mais de comprendre la suite : après une compromission, l’objectif n’est pas seulement de faire redémarrer le logiciel. Il faut retrouver un environnement auquel on peut de nouveau faire confiance.

Cet incident illustre également pourquoi un logiciel doit conserver un budget de maintenance après sa livraison. Notre article complémentaire explique combien prévoir pour la maintenance annuelle d’un logiciel sur mesure.

Un correctif d’une heure devenu une récupération de 40 heures

Le rapport entre une heure et près de 40 heures ne signifie pas que l’Infrastructure as Code aurait éliminé tout ce travail. L’IaC a facilité une partie essentielle de l’intervention : reconstruire une nouvelle machine propre de façon cohérente.

Le reste concernait notamment le confinement, l’analyse, les sauvegardes, la base de données, les secrets, les utilisateurs et la validation. Une récupération après cyberattaque est un ensemble de décisions liées. Remettre le site en ligne trop vite peut masquer la cause, détruire des éléments utiles à l’analyse ou réintroduire un élément compromis.

Pourquoi une machine compromise n’est pas automatiquement fiable

Lorsqu’un fichier ou un processus malveillant est découvert, le supprimer semble être la réponse directe. Cette action peut être nécessaire, mais elle ne prouve pas que le reste de la machine est sain.

Pendant l’accès, un attaquant peut avoir créé des comptes ou ajouté des clés d’accès. Il peut avoir installé un mécanisme de persistance qui lui permet de revenir après un redémarrage, modifié des fichiers système ou récupéré des secrets utilisés pour joindre d’autres services.

Il peut aussi avoir ajouté des tâches planifiées, altéré des journaux ou installé du code difficile à détecter. Une équipe qui retire uniquement l’élément connu risque de laisser derrière elle un autre accès dont elle ignore l’existence.

La destruction et la reconstruction ne sont pas obligatoires dans tous les incidents. La bonne réponse dépend du contexte, de la portée de la compromission, de la qualité des éléments d’analyse et de la capacité à rétablir la confiance dans l’environnement existant.

Lorsque cette confiance ne peut pas être établie de façon raisonnable, mettre l’ancienne machine hors service et reconstruire un serveur propre constitue souvent l’approche prudente. On cesse alors d’essayer de prouver l’absence de chaque modification possible sur une machine inconnue.

Qu’est-ce que l’Infrastructure as Code?

L’Infrastructure as Code, souvent abrégée IaC, consiste à décrire l’infrastructure dans des fichiers de configuration. Ces fichiers peuvent définir les ressources, le réseau, le stockage, les permissions, les règles de sécurité et une partie de la configuration nécessaire à l’application.

Comme le code du logiciel, ces fichiers peuvent être versionnés. Une modification laisse une trace, peut être révisée par une autre personne et peut être testée avant d’atteindre la production.

L’avantage opérationnel est la reproductibilité. Une équipe peut recréer un environnement cohérent à partir d’une description connue plutôt que de répéter une longue série de clics, de commandes et d’ajustements manuels.

Sans IaC, la configuration réelle dépend souvent de notes incomplètes et de la mémoire d’un administrateur. Des changements faits directement sur le serveur peuvent ne jamais être documentés. Au moment de reconstruire, personne ne sait exactement quels réglages étaient nécessaires ni lesquels étaient devenus accidentels.

L’IaC réduit fortement les écarts invisibles. C’est une pratique centrale du DevOps, une discipline qui rapproche développement et opérations. En DevOps au Québec comme ailleurs, savoir reconstruire compte autant que savoir déployer.

Comment l’IaC a facilité la reconstruction

Dans ce cas, l’infrastructure déjà décrite en code a permis à DevActif de créer une nouvelle machine propre sans recréer chaque élément manuellement. La configuration attendue constituait un point de départ versionné et révisable.

L’équipe a pu appliquer les correctifs avant d’exposer le nouvel environnement, puis déployer l’application selon une procédure connue. Cette approche a réduit les risques d’oubli et les écarts entre l’ancien et le nouveau serveur.

Analyse et confinement de l’incident

La réponse aux incidents commence avant la reconstruction. L’ordre exact varie selon la situation, mais les premières actions doivent limiter les dommages sans effacer les éléments nécessaires à la compréhension.

1. Contenir et isoler

Il faut d’abord contenir l’incident, puis isoler le serveur compromis des utilisateurs et des autres systèmes selon ce que permet le contexte. Isoler ne signifie pas simplement l’éteindre immédiatement. Une action précipitée peut faire perdre de l’information utile ou perturber d’autres services.

L’équipe préserve les journaux et les éléments nécessaires à l’analyse. Des journaux centralisés sont particulièrement précieux, puisqu’ils restent accessibles même si ceux de la machine ont été modifiés.

2. Établir la période et le vecteur probables

L’analyse cherche ensuite à déterminer la période probable de compromission. Cette fenêtre aide à choisir une sauvegarde et à examiner les actions survenues avant et après l’entrée.

Dans le cas présenté, les éléments techniques ont confirmé que la vulnérabilité connue avait servi de vecteur d’entrée. Cette confirmation permettait de corriger la cause avant toute remise en production.

3. Évaluer la portée

Il faut inventorier les systèmes, comptes, secrets et données potentiellement touchés. Un serveur utilise rarement une seule identité. Il peut accéder à une base de données, à du stockage, à un service de courriel, à des API ou à un outil de déploiement.

Reconstruction du nouvel environnement

Une fois les éléments nécessaires préservés, l’ancienne machine peut être mise hors service selon le plan retenu. La reconstruction se fait dans un nouvel environnement dont la provenance et la configuration sont contrôlées.

Les fichiers IaC créent les ressources prévues. L’équipe révise la configuration afin de s’assurer qu’elle ne reproduit pas elle-même un réglage vulnérable. Une mauvaise règle de réseau ou une permission trop large codée dans l’infrastructure serait autrement recréée fidèlement.

Les versions corrigées du système, des dépendances et de l’application sont installées avant que le serveur soit exposé. Les accès sont limités selon le principe du moindre privilège : chaque compte reçoit seulement les permissions nécessaires à sa tâche.

Cette reproductibilité est un avantage important d’une infrastructure infonuagique bien conçue. Elle sert autant pendant une migration planifiée que lors d’une restauration après intrusion.

Restauration et comparaison des données

Reconstruire le serveur règle l’infrastructure. Il faut ensuite traiter la partie la plus délicate : la base de données et les fichiers d’affaires.

Restaurer simplement la dernière sauvegarde n’est pas toujours prudent. Si elle a été prise après la compromission, elle peut contenir des modifications douteuses. Restaurer une sauvegarde beaucoup plus ancienne peut toutefois faire perdre des transactions légitimes récentes.

L’équipe choisit donc une sauvegarde antérieure jugée fiable en fonction de la période probable d’intrusion et des éléments disponibles. Cette sauvegarde doit réellement être restaurée et vérifiée. Un fichier de sauvegarde qui existe n’est utile que si le processus de restauration fonctionne.

Vient ensuite la comparaison avec les données créées ou modifiées après cette sauvegarde. Il faut distinguer les transactions légitimes des changements potentiellement effectués par l’attaquant. Les différences sont analysées et seules les données jugées fiables sont réintégrées.

Une comparaison automatisée aide à repérer les écarts, mais elle ne confirme pas avec certitude l’intégrité complète de toutes les données. Un changement peut être techniquement valide et tout de même ne pas avoir été autorisé. La conclusion dépend de la qualité des journaux, de la nature des données et du contexte.

Rotation des secrets et des accès

Une nouvelle machine ne neutralise pas un secret déjà copié. Tous les identifiants potentiellement exposés doivent être évalués et, lorsque nécessaire, remplacés.

Cela peut comprendre les mots de passe techniques, clés API, certificats, jetons de déploiement, clés d’accès et autres secrets. Les anciennes valeurs doivent être révoquées, pas seulement retirées du nouveau serveur.

Les sessions et jetons encore actifs sont également révoqués. Les comptes, permissions et accès administratifs sont vérifiés afin de retirer tout compte inconnu, obsolète ou trop privilégié.

Les nouveaux secrets ne devraient pas être inscrits directement dans les fichiers IaC ou dans le dépôt de code. L’infrastructure peut déclarer où un secret est utilisé, tandis que sa valeur demeure dans un mécanisme conçu pour la gestion sécuritaire des secrets.

Réinitialisation des mots de passe des utilisateurs

Dans l’incident présenté, la réponse a aussi compris la réinitialisation forcée du mot de passe de tous les utilisateurs du système. Cette mesure réduit le risque qu’un identifiant potentiellement exposé demeure utilisable.

La communication doit expliquer clairement ce que les utilisateurs doivent faire. Il faut également leur recommander de changer leur mot de passe sur tout autre service où ils auraient utilisé le même.

La réutilisation d’un mot de passe peut étendre les conséquences à des comptes qui n’ont aucun lien direct avec le logiciel compromis. Un mot de passe unique pour chaque service, idéalement géré par un gestionnaire de mots de passe, limite cette propagation. L’authentification multifacteur ajoute une protection importante lorsqu’elle est disponible.

Données confidentielles, documentation et avis

Le travail ne s’arrête pas lorsque l’application fonctionne de nouveau. L’organisation doit déterminer quelles données confidentielles ont pu être consultées ou exfiltrées et identifier les personnes potentiellement concernées.

Elle doit documenter l’incident, les éléments observés, les décisions prises et les mesures appliquées. Cette chronologie soutient autant l’analyse technique que la gestion interne et les communications.

Il faut ensuite évaluer les risques associés à l’accès aux données, aviser les personnes concernées lorsque requis et effectuer les déclarations nécessaires auprès des autorités compétentes lorsque requis. Les communications doivent être compréhensibles et préciser les actions demandées aux utilisateurs.

Les obligations exactes dépendent notamment des données touchées, du risque pour les personnes, du territoire et des lois applicables. Cette section ne constitue pas un avis juridique. Une organisation devrait consulter les ressources professionnelles appropriées à sa situation.

Ce que l’IaC ne règle pas

L’Infrastructure as Code est un puissant outil de reconstruction, mais elle ne remplace pas une réponse complète aux incidents.

• Elle n’identifie pas automatiquement le vecteur d’entrée.
• Elle ne garantit pas qu’une sauvegarde est saine ou restaurable.
• Elle ne vérifie pas l’intégrité de la base de données.
• Elle ne récupère pas un secret déjà exposé et ne remplace pas la rotation des accès.
• Elle ne révoque pas automatiquement toutes les sessions actives.
• Elle ne gère pas les communications destinées aux utilisateurs.
• Elle ne remplace pas les obligations liées à un incident de confidentialité.
• Elle ne remplace ni la surveillance ni l’analyse après la remise en production.
• Elle peut reproduire une mauvaise configuration aussi efficacement qu’une bonne.

Les fichiers d’infrastructure sont eux-mêmes sensibles. Ils doivent être protégés, versionnés, révisés et accessibles seulement aux personnes et systèmes qui en ont besoin. Les changements devraient passer par un processus de revue plutôt que par des modifications directes non documentées.

Les mesures à préparer avant un incident

La meilleure reconstruction est celle que l’organisation a déjà répétée. Les mesures suivantes réduisent le temps d’incertitude et améliorent la sécurité infonuagique avant qu’un incident survienne :

• décrire et versionner l’infrastructure;
• rendre les déploiements reproductibles;
• automatiser les sauvegardes et tester périodiquement leur restauration;
• centraliser les journaux et prévoir une durée de conservation adéquate;
• surveiller les vulnérabilités et appliquer régulièrement les correctifs;
• conserver les secrets dans un mécanisme sécurisé et planifier leur rotation;
• activer l’authentification multifacteur;
• appliquer le principe du moindre privilège;
• maintenir un inventaire des systèmes, dépendances, comptes et propriétaires;
• préparer un plan de réponse aux incidents avec rôles et coordonnées;
• documenter une procédure de communication destinée aux utilisateurs;
• exercer périodiquement la reconstruction d’un environnement isolé.

Notre réalisation sur la mise à niveau d’une infrastructure infonuagique illustre comment l’automatisation, la surveillance et des environnements mieux structurés peuvent réduire le risque opérationnel. Si l’application elle-même est ancienne, notre approche de reprise de logiciel existant permet d’en cartographier les dépendances avant une modernisation.

Reconstruire la confiance, pas seulement le serveur

L’IaC a simplifié la création d’une nouvelle machine propre dans l’intervention décrite. Elle a fourni une configuration versionnée, révisable et reproductible. Elle n’a toutefois pas éliminé l’analyse, la restauration des données, la rotation des secrets, la gestion des utilisateurs ni la surveillance.

C’est la distinction essentielle. Reconstruire un serveur est une tâche d’infrastructure. Retrouver un environnement fiable est un travail de réponse aux incidents qui couvre l’ensemble du système.

L’application régulière des correctifs demeure beaucoup moins coûteuse qu’une récupération après compromission. Pour structurer cet effort, consultez notre guide sur le coût de la maintenance d’un logiciel sur mesure.

DevActif peut évaluer la reproductibilité de votre infrastructure, vos sauvegardes, vos procédures de restauration, votre gestion des secrets, votre capacité à reconstruire un serveur et votre plan de réponse. Nous pouvons aussi vérifier les versions et vulnérabilités de vos dépendances.

Discutez de votre environnement avec notre équipe. L’objectif est d’identifier les écarts concrets et de préparer un plan réaliste avant qu’une urgence impose les priorités.