Sécurité en exploitation : journalisation, détection et réponse

La sécurité ne s’arrête pas au déploiement

Les sections précédentes de ce chapitre visent à empêcher les attaques. Aucune prévention n’est parfaite ; les organisations matures conçoivent donc aussi en partant du principe qu’une violation se produira : elles veulent la remarquer rapidement, en limiter les dégâts, s’en remettre proprement et en tirer des leçons. Le chapitre 2 a décrit les tactiques de sécurité comme le fait de résister aux attaques, de les détecter, d’y réagir et de s’en remettre, et a montré comment écrire des scénarios de sécurité avec des réponses mesurables comme un identifiant divulgué est détecté et révoqué en moins de 15 minutes. Cette section porte sur l’architecture et les pratiques qui rendent de telles réponses atteignables.

Une grande partie s’appuie sur les fondations opérationnelles de l’observabilité et de la gestion des incidents du chapitre 9. La différence, c’est l’adversaire : un disque défaillant ne masque pas ses traces, ne supprime pas ses journaux et ne revient pas la semaine suivante par une porte qu’il a laissée ouverte.

La journalisation de sécurité : ce qu’il faut journaliser et ce qu’il ne faut jamais journaliser

Les journaux de sécurité servent à établir, après coup, qui a fait quoi, sur quelle ressource, quand, d’où et avec quel résultat. L’OWASP Logging Cheat Sheet est la référence standard des praticiens. Elle recommande d’enregistrer des événements comme les réussites et les échecs d’authentification, les échecs d’autorisation, les échecs de gestion de session, les échecs de validation des entrées, les erreurs applicatives, les fonctions à haut risque comme les actions d’administration et les exports de données, ainsi que l’utilisation des contrôles de sécurité eux-mêmes. Chaque événement devrait indiquer quand (un horodatage synchronisé), où (application, service, hôte, environnement), qui (l’identité authentifiée, l’adresse source) et quoi (l’action, l’objet, le résultat et la raison).

Il est tout aussi important de savoir ce qui doit en rester exclu. Les journaux sont largement copiés, conservés longtemps et lus par de nombreuses personnes et de nombreux outils : c’est donc un endroit privilégié pour les fuites de secrets et de données à caractère personnel. Ne journalisez jamais les mots de passe, les identifiants de session ou les jetons d’accès (journalisez un hachage ou un identifiant de clé si vous devez corréler), les clés de chiffrement et les chaînes de connexion, les données de carte de paiement ni les catégories particulières de données à caractère personnel. Traitez les données de journal comme des données à caractère personnel lorsqu’elles identifient des personnes, et appliquez les règles de minimisation et de conservation de la section 8.7. Le masquage est mieux appliqué de façon centralisée dans le pipeline de journaux, en plus du code, car une seule instruction de débogage oubliée peut l’annuler.

{
  "ts": "2026-10-21T19:42:07.318Z",
  "event": "authz.denied",
  "service": "orders",
  "env": "prod",
  "actor": {"type": "user", "id": "cust_4411", "session": "sha256:7c1e..."},
  "client": {"ip": "203.0.113.24", "ua_family": "iOS app 7.3"},
  "action": "GET /orders/81723",
  "resource_owner": "cust_9902",
  "reason": "not_owner",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Les journaux doivent aussi être protégés contre les attaquants, dont le premier geste après avoir obtenu un accès est souvent d’effacer les preuves. Envoyez rapidement les journaux de sécurité vers un compte ou un service distinct que les identifiants propres à l’application ne peuvent pas modifier ; stockez-les avec une conservation à écriture unique ; restreignez et journalisez l’accès à ces journaux ; et gardez les horloges synchronisées pour que les événements de systèmes différents concordent. Traitez le contenu des journaux comme une entrée non fiable : un attaquant capable d’insérer un saut de ligne dans un champ journalisé peut forger de fausses entrées (injection dans les journaux, ou log injection) ; encodez ou rejetez donc les caractères de contrôle, et souvenez-vous que Log4Shell était déclenché par la journalisation d’un texte contrôlé par l’attaquant.

Les pistes d’audit

Une piste d’audit est une forme de journal plus étroite et plus forte : un enregistrement complet, chronologique et dont toute altération est détectable, portant sur des actions définies et conservé pour établir les responsabilités. Les journaux de débogage sont échantillonnés, soumis à rotation et modifiés au gré des développeurs ; une piste d’audit doit être complète dans son périmètre (chaque remboursement, chaque changement de rôle, chaque accès au dossier d’assistance d’un client), immuable, attribuable à une identité authentifiée et conservée pendant une durée définie. Les réglementations et les normes en exigent souvent une ; PCI DSS, par exemple, exige que l’historique des journaux d’audit soit conservé au moins douze mois, les trois derniers mois étant immédiatement disponibles pour analyse.

Sur le plan architectural, concevez la piste d’audit comme un produit du domaine, et non comme un sous-produit de la journalisation. Émettez les événements d’audit depuis le service qui possède l’action, au moment où l’action est validée (l’outbox transactionnelle garantit que les deux se produisent ou qu’aucun ne se produit), vers un stockage en ajout seul dont l’accès en écriture est restreint. La détection des altérations peut s’obtenir par chaînage de hachages, où chaque enregistrement inclut un hachage du précédent, ou en ancrant périodiquement ailleurs un condensé signé. Les systèmes en event sourcing en obtiennent une grande partie gratuitement, comme l’a montré la section 7.5. Les journaux d’audit du plan de contrôle des fournisseurs de cloud, qui enregistrent chaque appel d’API effectué sur le compte cloud, font partie du même tableau et doivent être activés dans chaque compte et chaque région.

La détection : SIEM, règles et automatisation de la réponse

Un système de gestion des informations et des événements de sécurité (SIEM) collecte la télémétrie de sécurité de l’ensemble du parc, la normalise, corrèle les événements et déclenche des alertes quand des motifs correspondent à des règles de détection : de nombreuses connexions échouées suivies d’une réussite, un compte de service utilisé depuis un nouveau pays, un rôle qui reçoit des droits d’administrateur hors d’une fenêtre de changement, un gros export à trois heures du matin. Les sources typiques sont l’API gateway, les événements de sécurité applicatifs, le fournisseur d’identité, les journaux d’audit du cloud, les journaux d’audit de Kubernetes et les agents de détection et de réponse sur les terminaux (EDR) installés sur les ordinateurs portables du personnel et sur les serveurs.

Une bonne détection se construit ; elle ne s’achète pas. Tirez les règles du modèle de menaces et de MITRE ATT&CK, une base de connaissances publique des tactiques et techniques d’attaquants réels, tenue par MITRE depuis 2015 ; écrivez-les sous forme de code dans un format partagé comme Sigma, versionnez-les, et testez-les en simulant l’attaque qu’elles doivent détecter. Mesurez la qualité des alertes : une règle qui se déclenche cinquante fois par jour et se révèle toujours bénigne apprend aux gens à l’ignorer, et c’est par la fatigue d’alerte que de vraies attaques passent inaperçues. Des pièges peu coûteux et très parlants aident : les honeytokens (jetons leurres), comme une fausse clé d’accès ou une fausse fiche client qu’aucun processus légitime ne touche jamais, ne produisent presque aucune fausse alerte. Les outils d’orchestration, d’automatisation et de réponse de sécurité (SOAR) exécutent ensuite des playbooks pour les alertes bien comprises, comme désactiver un utilisateur, révoquer une clé ou isoler un conteneur, afin que les humains se consacrent aux décisions qui demandent du jugement.

L’ingestion dans un SIEM est souvent facturée au volume, ce qui incite les équipes à abandonner des journaux. Une conception à plusieurs niveaux aide : les événements de sécurité à forte valeur vont au SIEM pour une détection en temps réel ; les journaux volumineux vont vers un stockage à écriture unique moins cher, où ils peuvent être fouillés pendant une enquête.

La gestion des vulnérabilités

De nouvelles vulnérabilités sont publiées chaque jour dans les logiciels que vous exécutez. Un identifiant CVE (Common Vulnerabilities and Exposures), comme CVE-2021-44228, donne à chaque vulnérabilité publiquement connue un nom unique ; le programme, lancé par MITRE en 1999, attribue les identifiants par l’intermédiaire de centaines de CVE Numbering Authorities, parmi lesquelles de grands éditeurs et des fondations open source. La National Vulnerability Database américaine ajoute des analyses comme les identifiants des produits concernés et des scores, mais un arriéré dans cet enrichissement à partir de 2024, et une brève alerte en avril 2025 lorsque le contrat finançant le programme CVE a failli expirer, ont montré le risque de dépendre d’une source unique ; la plupart des organisations combinent désormais plusieurs sources, dont la base d’avis de sécurité de GitHub et la base open source OSV.

CVSS (le Common Vulnerability Scoring System, maintenu par le FIRST ; la version 4.0 a été publiée en novembre 2023) évalue la gravité de 0 à 10, avec les niveaux faible (0,1 à 3,9), moyen (4,0 à 6,9), élevé (7,0 à 8,9) et critique (9,0 à 10,0). Le score de base publié décrit la vulnérabilité en général ; les métriques de menace et d’environnement de la version 4.0 l’ajustent en fonction de l’activité d’exploitation et de votre propre environnement. Un score de base ne mesure pas votre risque. Deux signaux améliorent considérablement la priorisation : l’Exploit Prediction Scoring System (EPSS, également du FIRST), qui estime la probabilité qu’une vulnérabilité soit exploitée dans les 30 prochains jours, et le catalogue Known Exploited Vulnerabilities (KEV) de la Cybersecurity and Infrastructure Security Agency américaine, qui recense les vulnérabilités dont l’exploitation réelle est avérée. Combinez-les avec l’atteignabilité (la fonction vulnérable est-elle utilisée ?) et l’exposition (le service est-il exposé à Internet ?), et la plupart des centaines de constats d’un scanner rejoignent la file courante, tandis qu’une poignée exige une action dès aujourd’hui.

Convenez à l’avance des délais de correction, pour que chaque constat ne devienne pas une négociation, et mesurez le délai de correction. Les chiffres ci-dessous sont des illustrations typiques, pas une norme ; les environnements réglementés peuvent imposer les leurs : PCI DSS, par exemple, exige que les correctifs de sécurité critiques soient installés dans le mois qui suit leur publication.

Tests d’intrusion, bug bounties et divulgation

Un test d’intrusion est une tentative autorisée et limitée dans le temps, menée par des testeurs compétents, de pénétrer dans un système, idéalement en connaissant son architecture et avec un périmètre convenu par écrit. Il trouve des classes de problèmes que les scanners manquent, comme les défauts d’autorisation au niveau des objets et l’abus de la logique métier (utiliser deux fois le même bon de réduction grâce à une situation de compétition, ou race condition). Commandez-en un avant un lancement majeur, après un changement architectural important et périodiquement ; un exercice de red team va plus loin, en testant la détection et la réponse par la simulation d’un véritable adversaire pendant des semaines.

Des chercheurs extérieurs trouveront eux aussi des problèmes, et ils ont besoin d’un moyen sûr de les signaler. Une politique de divulgation des vulnérabilités indique comment signaler, quels tests sont autorisés et que la recherche de bonne foi ne fera pas l’objet de menaces juridiques ; un fichier security.txt placé à l’adresse /.well-known/security.txt (RFC 9116, 2022) indique aux chercheurs où envoyer leurs signalements. Un bug bounty (programme de prime aux bogues) ajoute une rémunération pour les constats valides, souvent via une plateforme qui trie les soumissions. Les normes ISO/IEC 29147 (divulgation) et ISO/IEC 30111 (traitement) décrivent les processus, et le règlement sur la cyberrésilience impose aux fabricants des produits relevant de son champ d’application d’avoir une politique de divulgation coordonnée des vulnérabilités. Un bug bounty ne remplace pas le travail de sécurité interne : lancé sur un système non testé, il tend à produire un afflux de signalements que l’équipe ne peut pas absorber.

Réponse aux incidents

La réponse aux incidents est le traitement organisé d’un incident de sécurité, de sa détection jusqu’au rétablissement et aux enseignements. Pendant plus de dix ans, la référence standard a été la publication NIST SP 800-61 révision 2 (2012), avec son cycle de vie en quatre phases : préparation ; détection et analyse ; confinement, éradication et rétablissement ; et activité post-incident. La révision 3, publiée en avril 2025 sous le titre Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, remplace ce cycle de vie par les six fonctions du NIST Cybersecurity Framework 2.0. Gouverner, Identifier et Protéger constituent une préparation continue qui rend les incidents moins probables et la réponse plus efficace ; Détecter, Répondre et Rétablir constituent la réponse elle-même ; et les enseignements tirés alimentent l’amélioration de toutes ces fonctions au lieu de constituer une phase finale.

En pratique, une bonne réponse exige des rôles nommés (un coordinateur d’incident (incident commander) qui coordonne et décide, des responsables techniques qui enquêtent et agissent, un responsable de la communication, un scribe qui tient la chronologie, et un accès rapide aux conseillers juridiques et au délégué à la protection des données), des niveaux de gravité qui déterminent qui est réveillé, et un canal hors bande, car un attaquant présent dans votre messagerie ou votre système de chat peut lire la réponse. Le confinement est un compromis : couper rapidement l’accès à un attaquant limite les dégâts mais peut détruire des preuves et l’alerter ; préservez donc les preuves (snapshots, journaux, captures mémoire) avant de reconstruire, et assurez-vous d’avoir trouvé toutes ses positions d’appui avant d’annoncer qu’il est parti. Ensuite, une revue sans reproche examine comment le système et ses processus ont permis l’incident, et produit des actions architecturales.

La résilience face aux rançongiciels

Un rançongiciel chiffre les systèmes d’une organisation et exige un paiement contre la clé ; la plupart des groupes volent désormais aussi les données au préalable et menacent de les publier. Les défenses architecturales sont celles de tout ce chapitre (MFA, moindre privilège, segmentation, correctifs, détection), mais le rétablissement dépend avant tout d’une chose : des sauvegardes que l’attaquant ne peut pas atteindre. Les attaquants dotés de droits d’administrateur cherchent d’abord les sauvegardes et les suppriment ou les chiffrent.

Conservez au moins une copie des données critiques immuable ou hors ligne : un stockage objet avec des verrous de conservation à écriture unique que même un administrateur ne peut pas raccourcir, ou des supports physiquement déconnectés du réseau. Placez les sauvegardes dans un compte ou un tenant distinct, avec des identifiants et une MFA distincts, afin que la compromission des identités de production ne les atteigne pas. La règle traditionnelle 3-2-1 (trois copies, sur deux types de supports, dont une hors site) est une base raisonnable. Surtout, testez régulièrement les restaurations par rapport au RTO et au RPO convenus avec le métier, y compris l’ordre de reprise : les services d’identité et le DNS passent en premier, car rien d’autre ne peut être reconstruit sans eux. En 2017, la compagnie maritime Maersk a reconstruit son réseau mondial après que le logiciel malveillant NotPetya eut détruit ses contrôleurs de domaine Windows ; la reprise a reposé sur le seul contrôleur de domaine qui avait survécu, au Ghana, parce qu’une coupure de courant l’avait mis hors ligne pendant l’attaque.

Violations de données à caractère personnel et délais de notification

Une violation de données à caractère personnel est, au sens de l’article 4, point 12, du RGPD, une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel, ou l’accès non autorisé à de telles données. La notion est plus large que le vol : une attaque par rançongiciel qui rend les données indisponibles, ou un e-mail envoyé aux mauvais destinataires, peut en relever. En vertu de l’article 33, le responsable du traitement doit notifier la violation à l’autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, à moins qu’elle ne soit pas susceptible d’engendrer un risque pour les droits et libertés des personnes ; une notification plus tardive doit être accompagnée des motifs du retard. En vertu de l’article 34, le responsable du traitement doit aussi informer les personnes concernées dans les meilleurs délais si la violation est susceptible d’engendrer un risque élevé pour elles. L’article 33, paragraphe 5, exige que toute violation, notifiée ou non, soit documentée. Le RGPD britannique prévoit les mêmes règles, les notifications étant adressées à l’Information Commissioner’s Office.

D’autres régimes peuvent s’appliquer en parallèle, avec leurs propres délais, destinataires et seuils, et les contrats ajoutent souvent des obligations envers les clients et les partenaires. Le tableau résume les principaux délais de l’UE et du Royaume-Uni. La proposition d’omnibus numérique de la Commission européenne de novembre 2025 porterait le délai du RGPD à 96 heures et limiterait la notification à l’autorité aux violations à haut risque, mais, à la date de rédaction, elle n’a pas été adoptée et la règle des 72 heures s’applique.

La leçon d’architecture est qu’un délai compté en heures ne peut être tenu que si les systèmes peuvent établir, rapidement et preuves à l’appui, quelles données ont été touchées, à qui elles appartenaient et si elles ont réellement été consultées. Cela exige la cartographie des données de la section 8.7, des journaux d’accès aux données sur les stockages de données à caractère personnel, et un chiffrement susceptible de rendre incompréhensible une copie divulguée. Comme pour le reste de ce chapitre, il s’agit d’informations sur la façon dont le droit influe sur les systèmes, et non d’un conseil juridique ; la décision de notifier appartient au responsable du traitement, conseillé par son DPD et ses avocats.

Les runbooks

Un runbook (procédure d’exploitation) est une procédure écrite et testée pour une situation précise : révoquer et renouveler un identifiant divulgué, isoler un conteneur compromis, restaurer la base de données des commandes à partir d’une sauvegarde immuable, réagir à une suspicion de violation de données à caractère personnel. Un bon runbook indique son déclencheur, les personnes à impliquer, les étapes et commandes exactes, comment vérifier que chaque étape a fonctionné, comment revenir en arrière et quelles preuves conserver. Les runbooks sont du code dans l’esprit : conservez-les sous gestion de versions à côté des systèmes qu’ils décrivent, automatisez les parties mécaniques, et répétez-les lors de game days et d’exercices sur table, car une procédure qui n’a jamais été exécutée échoue généralement à l’étape trois. Chaque règle de détection devrait renvoyer au runbook de son alerte.

La chronologie montre pourquoi l’exploitation fait partie de l’architecture. Chaque étape qui s’est bien passée dépendait d’une décision de conception prise des mois plus tôt : la détection de secrets et les journaux d’audit alimentant le SIEM, les journaux d’accès au niveau des objets sur le bucket d’exports, une cartographie des données qui a indiqué au DPD à qui appartenaient les données qu’il contenait, et une conception des identités qui a permis de reconstruire le rôle de déploiement sans clés à longue durée de vie. Chaque étape qui s’est mal passée (l’existence même d’une clé à longue durée de vie, un bucket d’exports clients dont plus personne n’avait besoin) relevait aussi d’un choix architectural.