Investiguer les systèmes

Tout système finit par échouer. Quand cela arrive, votre capacité à comprendre ce qui s'est passé dépend d'une poignée de facteurs : disposer de journaux et de sources d'information adéquats, posséder l'expertise pour les exploiter, et — point souvent négligé — avoir conçu vos systèmes de journalisation dès le départ avec la protection et le contrôle d'accès à l'esprit. Ce chapitre, signé par l'équipe d'investigation de Google, distingue deux activités cousines mais profondément différentes : déboguer un problème de système et investiguer une compromission de sécurité. Toutes deux exigent un accès aux systèmes et aux données — et cet accès, même en lecture seule, crée un risque qu'il faut équilibrer contre les besoins légitimes des ingénieurs.

Du débogage à l'investigation

Le débogage a mauvaise réputation. Les bogues surgissent au pire moment, on peine à estimer quand ils seront corrigés, et écrire du code neuf paraît plus gratifiant que réparer l'existant. Pourtant, vu sous l'angle de l'apprentissage, c'est une discipline qui rend meilleur programmeur — et qui rappelle, salutairement, qu'on est parfois moins malin qu'on ne le croit. Surtout, c'est une compétence qui s'apprend et se pratique, pas un don.

Le livre SRE de Google pose deux prérequis au débogage réussi : savoir comment le système est censé fonctionner, et être systématique — collecter des données, formuler des hypothèses, tester ses théories. Le premier est le plus délicat. Songez au cas canonique du système bâti par un développeur unique qui quitte l'entreprise en emportant toute la connaissance : le système tourne des mois, puis casse un jour sans que personne ne sache le réparer. Aucune astuce ne remplace réellement la compréhension préalable du système.

Distinguer les chevaux des zèbres

Une métaphore médicale guide le diagnostic : quand vous entendez un galop, pensez-vous d'abord à un cheval ou à un zèbre ? La plupart des maux sont communs — la plupart des galops sont des chevaux. Mais à grande échelle, la statistique s'inverse. À mesure qu'une organisation élimine les problèmes fréquents, les problèmes rares apparaissent plus souvent. Comme le dit Bryan Cantrill : « Avec le temps, les chevaux sont trouvés ; il ne reste que les zèbres. »

Considérez la corruption mémoire par retournement de bit (bit flip). Un module à correction d'erreur a moins de 1 % de risque annuel de subir un retournement non corrigible. Mais un service hypothétique de 25 000 machines mobilisant 400 000 puces de RAM, avec un risque de 0,1 % par puce et par an, connaîtra environ 400 occurrences par an — soit une panne mémoire observée presque chaque jour. Le zèbre d'aujourd'hui devient le cheval de demain : en l'an 2000, la corruption matérielle de la mémoire surprenait Google ; aujourd'hui elle est routinière, et l'on s'en protège par des vérifications d'intégrité de bout en bout.

Une boîte à outils pour ne pas rester bloqué

L'exemple fil rouge du chapitre — une base Spanner à court de quota de stockage — a demandé entre cinq et dix heures de travail méthodique. La chaîne causale, remontée maillon par maillon, mérite d'être restituée en entier : des fichiers temporaires créés et supprimés en boucle faisaient enfler le cache d'entrées de répertoire (dentry) dans le noyau Linux ; ce cache dévorait la mémoire du serveur Spanner ; à court de mémoire, le serveur vidait ses écritures bufferisées sous forme d'une myriade de fichiers minuscules sur Colossus, le système de fichiers distribué de Google ; et cette multitude de petits fichiers finissait par épuiser le quota de stockage. L'enchaînement illustre une série de techniques que l'on peut résumer comme un arbre de décision.

JE SUIS BLOQUÉ — que faire ?

├─ Puis-je VOIR ce que fait le code ?
│     → Améliorer l'observabilité : logs structurés, compteurs,
│       traçage distribué (Dapper, Zipkin), endpoints de debug
│
├─ Puis-je REPRODUIRE hors production ?
│     → oui : crasher, corrompre, sur-journaliser librement,
│            impliquer beaucoup de monde sans risque sur les données
│     → non : isoler le plus petit sous-ensemble fautif
│
├─ Mon hypothèse tient-elle face aux DONNÉES réelles ?
│     → profiler avant de spéculer ; les bogues se cachent dans
│       l'écart entre le modèle mental et l'implémentation réelle
│
├─ Le comportement est-il NORMAL ?
│     → établir une baseline ; filtrer le bruit de fond
│       (force brute SSH, scans de ports, fautes de frappe)
│
├─ Ai-je relu la DOC ? nettoyé / supprimé le code mort ?
│
└─ Toujours bloqué ?
      → faire une PAUSE, documenter où j'en suis,
        passer le relais (débogage collaboratif)

Quelques principes méritent d'être soulignés. Consigner ses observations et ses attentes par écrit structure l'enquête, permet à un collègue de reprendre le fil, et — crucial pour la sécurité — fournit une trace prouvant un jour, parfois devant un tribunal, quelles actions furent celles de l'attaquant et lesquelles celles des investigateurs. Connaître le normal évite de déboguer un comportement attendu : un binaire qui appelle abort en fin d'arrêt, ou Chrome qui résout au démarrage trois domaines aléatoires (comme cegzaukxwefark.local) pour détecter une falsification DNS illicite — un comportement que l'équipe d'investigation de Google elle-même a déjà pris pour un logiciel malveillant cherchant un serveur de commande et contrôle.

Enfin, distinguer corrélation et causalité : deux pannes simultanées peuvent avoir des racines distinctes. Un déploiement corrélé à une panne n'en est pas forcément la cause — Google a vu un ancien code si lent qu'il bridait par accident l'ensemble du système ; le nouveau code, plus rapide, a simplement levé ce bridage et surchargé d'autres composants. Et l'on pratique : Google s'entraîne formellement au débogage via le programme DiRT (Disaster Recovery Testing, tests de reprise après sinistre) et des tests d'intrusion, mais des exercices d'une heure à deux ingénieurs suffisent déjà à entretenir les réflexes.

En quoi l'investigation de sécurité diffère du débogage

On attend de tout ingénieur qu'il sache déboguer. En revanche, l'investigation d'une compromission doit être confiée à des spécialistes de la sécurité et de la criminalistique (forensics) formés et expérimentés. La frontière entre « enquête de bogue » et « problème de sécurité » est parfois floue — c'est là que la collaboration entre les deux familles d'experts devient précieuse.

Dimension	Débogage	Investigation de sécurité
Point de départ	Le système connaît un problème	Un soupçon d'activité malveillante
Focale	Le code : quelles données, quel traitement, quel écart d'intention	L'adversaire : que fait ce compte ? quelle autre activité ? un attaquant est-il vivant dans le système ?
Question suivante	Pourquoi ce comportement ?	Que va faire l'attaquant ensuite ?
Gestes risqués	Ajouter du code, supprimer des fichiers, déprécier — souvent utiles	Les mêmes gestes peuvent être contre-productifs : alerter l'attaquant
Urgence & périmètre	Cadrés par l'incident technique	Croissent organiquement : juridique, régulateurs, forces de l'ordre
Qui intervient	Tout ingénieur	Spécialistes formés + Legal, parfois en amont

Les gestes salutaires du débogage peuvent se retourner contre vous. Google a répondu à des incidents où un débogueur supprimait des fichiers « anormaux » dans l'espoir de réparer — fichiers en réalité déposés par l'attaquant, désormais averti de l'enquête. Dans un cas, l'attaquant a riposté en supprimant le système entier. D'où la règle : dès qu'une compromission est plausible, appelez les professionnels de la sécurité avant d'agir.

Collecter des journaux appropriés et utiles

Au fond, journaux et vidages mémoire (crash dumps) sont une même chose : de l'information collectée pour comprendre ce qui s'est passé, accidentel ou intentionnel. Avant de lancer un service, demandez-vous quelles données il stockera pour le compte des utilisateurs et par quels chemins on y accède. Posez comme hypothèse que toute action menant à un accès aux données ou au système entrera un jour dans le périmètre d'une investigation et devra être auditée. Ici, « journaux » désigne des enregistrements structurés et horodatés ; on recommande de traiter aussi les vidages de cœur, de mémoire et les piles d'appel autant que possible comme des journaux.

Concevoir des journaux immuables

Le système qui collecte les journaux doit être immuable : une fois écrite, une entrée doit être difficile à altérer (pas impossible — voir la vie privée plus bas), et toute altération doit laisser une piste d'audit elle-même immuable. Les attaquants effacent typiquement les traces de leur activité dès qu'ils ont pris pied. La parade éprouvée : écrire les journaux à distance, vers un serveur centralisé et distribué. L'attaquant doit alors compromettre deux systèmes au lieu d'un — encore faut-il durcir soigneusement ce serveur de journaux.

Pourquoi journaliser À DISTANCE plutôt que localement

   [ Serveur compromis ]                [ Serveur de journaux ]
        │  écrit                              centralisé + durci
        └────────── log ──────────────────────────►  ✔ trace conservée

   Attaquant veut effacer ses traces :
     local seul   → 1 système à compromettre   ✗ trace perdue
     distant      → 2 systèmes à compromettre  ✔ coût de l'attaque ↑↑

Quels journaux de sécurité conserver

Les ingénieurs sécurité préfèrent souvent « trop » de journaux à « pas assez », mais il faut rester sélectif : le stockage coûte cher, et trier des jeux de données pléthoriques ralentit l'investigateur. Le tableau ci-dessous oppose les sources principales.

Source	Ce qu'elle apporte	Coût / friction
Journaux d'OS (Windows Event, syslog, auditd)	Intégrés, souvent activés par défaut, quasi sans effort	auditd désactivé par défaut pour la performance — l'activer reste un bon compromis
Agents d'hôte (HIDS, agents « next-gen », OSQuery, GRR)	Détection avancée, visibilité temps réel, modélisation comportementale	Impact perf systématique ; agents noyau plus puissants mais plus fragiles ; à évaluer avant déploiement
Journaux applicatifs (SAP, SharePoint, code maison)	Détection sur mesure ; ex. Google Drive pour déterminer si un poste compromis a téléchargé des données sensibles	Demande la collaboration dev/sécurité pour journaliser les actions sensibles
Journaux cloud (Cloud Audit Logs, Stackdriver, BigQuery)	Collecte/stockage faciles et bon marché, détection in situ (Event Threat Detection, CASB)	Surface dynamique ; difficile d'inventorier tous les actifs ; options parfois imposées par le fournisseur
Réseau (NIDS/IPS, logs DNS, proxys web)	Recommandé pour presque toute organisation ; sinkholes DNS, détection de phishing	Coût ; qui triera les alertes ? attention à la vie privée des employés sur les proxys

Budgétiser la journalisation

Un système observé chez Google comptait 100 To de journaux, pour l'essentiel jamais utilisés. Parce que les journaux consomment beaucoup de ressources et sont peu consultés en l'absence de problème, la tentation est de sous-investir. C'est une erreur : selon une étude de 2018, il faut en moyenne environ 200 jours à une organisation pour découvrir une compromission, et certaines enquêtes sur des menaces internes (insider threat) chez Google se sont appuyées sur des journaux d'OS remontant à plusieurs années. Si vous ne gardez qu'une semaine de journaux d'accès, vous ne pourrez tout simplement pas enquêter sur une intrusion ancienne.

Quand le besoin de rétention long terme entre en conflit avec le budget, le réflexe n'est pas d'arrêter la collecte une fois la capacité atteinte, mais de dégrader gracieusement. La synthèse de données (data summarization) est la méthode clé : écrire à la collecte deux fichiers — l'un pleine fidélité, l'autre résumé basse fidélité — pour éviter de relire et reparser plus tard (coûteux). On dédie par exemple 90 % du stockage aux journaux complets et 10 % aux résumés ; en saturant, on supprime les gros fichiers et l'on garde les petits.

Stratégie de rétention par paliers (graceful degradation)

  collecte ──┬──► full-fidelity  ─── chaud (relationnel, indexé) ── N jours
             │       │  ex. captures de paquets complètes
             │       └──► supprimé après N jours
             │
             └──► résumé          ─── froid (stockage hors ligne) ── 1 an
                     ex. données netflow  → coût ↓↓, intel conservée

Les principes d'investissement complètent ce schéma : privilégier les journaux à bon rapport signal/bruit (inutile de stocker tous les paquets bloqués par un pare-feu) ; compresser systématiquement (les journaux regorgent de métadonnées dupliquées) ; séparer le chaud (récent, immédiatement requêtable) du froid (archives bon marché hors ligne) ; et faire tourner les journaux intelligemment, en supprimant les plus anciens d'abord mais en conservant plus longtemps les types les plus importants.

Bons journaux contre mauvais journaux

Critère	Mauvais journal	Bon journal
Format	Texte libre, non horodaté	Structuré, horodaté, requêtable
Localisation	Local uniquement, effaçable	Distant, centralisé, immuable avec audit
Portée	Brut indifférencié, signal noyé dans le bruit	Bon signal/bruit, actions de sécurité explicitées
Rétention	Une semaine « parce que ça coûte »	Calibrée sur ~200 j de détection ; paliers chaud/froid
Vie privée	Données sensibles en clair, métadonnées « non sensibles »	Minimisé, anonymisé/pseudonymisé, chiffré si besoin
Accès	Lisible par tous	Permissions robustes, accès justifié et tracé

La tension vie privée / journalisation

Pour être maximalement utiles à une investigation, les journaux doivent être aussi complets que possible : chaque action d'un utilisateur (ou d'un attaquant usurpant son compte), l'hôte depuis lequel il s'est connecté, les horaires exacts. Or les techniques de préservation de la vie privée poussent, à l'inverse, à ne pas retenir de données sensibles. Cette tension est inhérente, et les journaux sont eux-mêmes une cible : un attaquant qui les lit reconstitue votre activité.

Plusieurs leviers concilient les deux exigences, à arbitrer avec vos collègues juridiques et vie privée :

• Profondeur de journalisation : convenir d'une politique organisationnelle sur ce qu'il est acceptable de journaliser.
• Rétention : décider collectivement combien de temps garder, en tenant compte du délai moyen de détection.
• Contrôles d'accès et d'audit : protéger journaux et métadonnées comme n'importe quelle autre donnée.
• Anonymisation / pseudonymisation : on peut concevoir un système où investigateurs et débogueurs ne peuvent pas identifier l'utilisateur, mais reconstituent la chronologie de ses actions au sein d'une session. L'anonymisation est délicate à réussir — consultez des spécialistes.
• Chiffrement asymétrique : une clé publique non sensible permet d'écrire les journaux ; seule la clé privée déchiffre. Des paires de clés quotidiennes laissent un débogueur obtenir un petit sous-ensemble récent, tout en empêchant l'extraction massive de journaux en agrégat. Réfléchissez soigneusement au stockage des clés.

Un accès de débogage robuste et sûr

Pour déboguer, il faut accéder aux systèmes et aux données qu'ils stockent. Deux questions doivent rester ouvertes : un débogueur malveillant ou compromis peut-il voir des informations sensibles ? Et — puisque tout système échoue, y compris un système de sécurité — saura-t-on le réparer sans se verrouiller dehors ?

Côté fiabilité, la journalisation est elle aussi une façon d'échouer (disque plein, par exemple). Planifiez le débogage des systèmes de sécurité eux-mêmes : conservez un jeu d'identifiants d'urgence (emergency-only credentials), hors ligne en lieu sûr, déclenchant une alarme à haute confiance lors de leur usage. Lors d'une panne réseau récente, le système d'authentification de Google, ne pouvant joindre un backend, a échoué en mode fermé (failed closed) ; ce sont précisément ces identifiants d'urgence qui ont permis aux intervenants de s'authentifier et de réparer le réseau.

Côté sécurité, les endpoints de débogage — de l'usurpation d'identité (un système de support permettait aux administrateurs d'« incarner » un utilisateur et de voir son interface) jusqu'à l'accès brut à la base — doivent être sécurisés. Bonne nouvelle : beaucoup d'incidents ne requièrent pas l'accès aux données utilisateur. Pour diagnostiquer un problème TCP, la vitesse et la qualité des octets sur le fil suffisent souvent ; chiffrer les données en transit les protège des tiers et permet d'ouvrir l'accès aux captures de paquets à davantage d'ingénieurs. Quand l'analyse exige de vraies données (trouver pourquoi un compte reçoit des milliers d'emails par heure), le réseau zéro confiance (zero trust networking) encadre l'accès au cas par cas.

À retenir

• Déboguer et investiguer sont deux activités distinctes : le débogage est centré sur le code et incombe à tout ingénieur ; l'investigation de sécurité est centrée sur l'adversaire et doit être menée par des spécialistes formés — les gestes utiles au débogage peuvent alerter un attaquant.
• Le débogage est une compétence systématique (connaître le normal, formuler et tester des hypothèses sur des données réelles, distinguer corrélation et causalité), à entretenir par la pratique — DiRT, débogage collaboratif, Wheel of Misfortune.
• Concevez la journalisation dès le départ : journaux structurés, horodatés, immuables, écrits à distance vers un serveur centralisé et durci, pour augmenter le coût d'effacement par l'attaquant.
• Budgétisez la journalisation à l'avance et dégradez gracieusement (synthèse de données, paliers chaud/froid, compression, bon signal/bruit) : la détection prend ~200 jours en moyenne, garder seulement une semaine rend l'enquête impossible.
• La vie privée est en tension avec l'utilité des journaux : minimiser les données sensibles, anonymiser/pseudonymiser, chiffrer (clés asymétriques quotidiennes), et ne jamais traiter les métadonnées comme anodines.
• Les journaux sont une cible : protégez-les — et l'accès aux endpoints de débogage — par des permissions robustes, un accès justifié et tracé, même pour des systèmes a priori non sensibles.
• Préparez la défaillance des systèmes de sécurité eux-mêmes : identifiants d'urgence hors ligne et alarmés, et accès aux données encadré par le zéro confiance — car chance favorise les esprits préparés.