Aller au contenu
TortueTech
RubriquesGouvernance, droit & économie du risque

Ce qu’un auditeur vérifie dans les preuves de conformité

Ce qu’un auditeur vérifie dans les preuves de conformité

Section intitulée « Ce qu’un auditeur vérifie dans les preuves de conformité »

Une preuve de conformité n’est pas un dossier documentaire bien rangé, ni une capture d’écran prise le jour où tout allait bien. C’est une chaîne vérifiable entre une exigence, une décision d’architecture, un contrôle exécuté, son résultat et le traitement de ses écarts.

→ Lire l’explication complète de la marmotte

L’auditeur vérifie une chaîne d’assertions

Section intitulée « L’auditeur vérifie une chaîne d’assertions »

Un auditeur ne vérifie pas qu’une politique existe. Il vérifie qu’une affirmation peut être suivie jusqu’à une observation indépendante. « Les accès privilégiés sont revus » ne constitue pas une preuve. Il faut relier cette assertion à une population d’identités, une règle de revue, une fréquence, des décisions nominatives, des dates, des exceptions et une approbation attribuable.

La chaîne attendue comporte cinq éléments :

  1. L’exigence : obligation réglementaire, engagement contractuel, politique interne ou exigence de risque. La directive Network and Information Security 2 (NIS2), par exemple, impose des mesures de gestion des risques, mais elle ne livre pas une configuration prête à copier dans un pare-feu. C’est heureux, sinon les vendeurs de slides auraient enfin trouvé le Graal.
  2. Le contrôle : mécanisme qui réduit un risque identifié. Exemple : authentification multifacteur pour les comptes d’administration, journalisation centralisée des élévations de privilèges, ou rotation des secrets.
  3. Le périmètre : actifs, identités, environnements et flux couverts. Un contrôle sans périmètre mesurable permet d’affirmer beaucoup de choses et d’en prouver très peu.
  4. L’exécution : traces datées démontrant que le contrôle tourne réellement, y compris lorsque le résultat est défavorable.
  5. Le traitement des écarts : tickets, acceptation de risque, plan de correction, échéance et responsable. Un écart masqué est une non-conformité aggravée. Un écart documenté et suivi est un élément normal de pilotage.

La recommandation est nette : modéliser la conformité comme un graphe de preuves, pas comme une bibliothèque de documents. On gagne en capacité de démonstration et en détection des angles morts. On paie par une discipline de collecte, de conservation et de normalisation des métadonnées. Ce coût est justifié lorsque le périmètre comprend des services critiques, des données sensibles ou des accès d’administration. Pour un système isolé et non critique, une preuve proportionnée reste préférable à une usine à gaz qui certifie laborieusement l’existence de trois machines virtuelles.

Les principes de gouvernance doivent donc associer chaque contrôle à un propriétaire, une source de vérité et une durée de conservation. Sans cela, l’audit devient une chasse au fichier PDF, sport collectif dont personne ne réclame la retransmission.

Les propriétés d’une preuve exploitable

Section intitulée « Les propriétés d’une preuve exploitable »

Une preuve convaincante possède cinq propriétés. L’absence de l’une d’elles ne rend pas nécessairement le contrôle inexistant, mais rend sa démonstration fragile.

Attribution : il faut identifier le système ou la personne ayant produit la trace. Un export CSV sans origine, sans compte de service identifié et sans journal d’exécution vaut surtout comme souvenir. Pour les actions humaines, l’identité doit être liée à une authentification non partagée. Les comptes génériques d’administration rendent l’attribution impossible, même avec douze pages de procédure.

Intégrité : la preuve doit révéler une modification ultérieure. Un condensat cryptographique, aussi appelé hash, tel que SHA-256, détecte une altération si sa valeur de référence est elle-même protégée. Une signature numérique ajoute l’identité du signataire, à condition que la clé privée soit protégée et que le certificat du signataire soit vérifiable. Stocker le fichier et son hash dans le même répertoire inscriptible par le même compte n’apporte aucune indépendance. C’est un cadenas posé sur une boîte en carton avec la clé scotchée dessous.

Horodatage : la date affichée dans un fichier ne suffit pas. Le système qui produit la trace peut être mal synchronisé ou compromis. Les journaux doivent être synchronisés sur une source de temps surveillée et leurs dérives mesurées. Pour une preuve à forte valeur, recourir à un horodatage tiers ou à un stockage à rétention verrouillée. La valeur recherchée n’est pas l’heure exacte à la microseconde, mais la capacité à établir un ordre fiable et à détecter une antériorité inventée.

Exhaustivité : une sélection manuelle ne prouve pas une population complète. Une revue d’accès doit partir de l’inventaire autoritaire des identités, puis démontrer que chaque entrée a été traitée ou explicitement exclue. Pour les journaux, documenter les sources attendues, les périodes de collecte, les pertes connues et les règles de filtrage. Une extraction limitée aux événements réussis est très propre visuellement. Elle est aussi exactement ce qu’un attaquant préférerait voir.

Reproductibilité : un tiers doit pouvoir refaire le calcul ou vérifier la signature sans dépendre d’un poste personnel. Versionner les scripts, figer les dépendances, conserver les paramètres et documenter les droits requis. La reproductibilité ne signifie pas rejouer une action destructive en production, évidemment. Elle signifie vérifier le résultat, la méthode et le périmètre avec les mêmes entrées.

Les contrôles d’identité méritent une attention particulière. Une preuve d’authentification réussie ne prouve ni que la personne était légitime, ni que son poste était sain, ni que son jeton n’a pas été volé. Les mécanismes décrits dans la section identités complètent la démonstration, mais ne remplacent pas une corrélation entre identité, autorisation, contexte et activité.

Exemple de manifeste signé pour une collecte de preuves

Section intitulée « Exemple de manifeste signé pour une collecte de preuves »

Un manifeste signé constitue une bonne base pour figer un lot de preuves, par exemple les exports d’une revue d’accès, les journaux de sauvegarde et les rapports de configuration. Il ne remplace pas le stockage à accès restreint : il détecte l’altération, pas la suppression ni la collecte incomplète.

Prévoir GNU coreutils 9 ou une version compatible, OpenSSL 3 et une clé de signature dédiée. La clé privée doit résider dans un module matériel ou un service de signature lorsque la valeur de la preuve le justifie. Un fichier PEM copié sur un serveur d’administration n’est pas une gestion de clés, c’est une invitation avec pièce jointe.

#!/usr/bin/env bash
# Génère un manifeste déterministe puis le signe.
# Pré-requis : GNU find, sort, sha256sum et OpenSSL 3.
set -euo pipefail
export LC_ALL=C


EVIDENCE_DIR="./preuves/2026-09"
MANIFEST="./manifest-2026-09.sha256"
SIGNATURE="./manifest-2026-09.sha256.sig"
PRIVATE_KEY="./cle-signature-preuves.pem"


# Exclure le manifeste et sa signature pour éviter une boucle de calcul.
find "$EVIDENCE_DIR" -type f -print0 \
  | sort -z \
  | xargs -0 sha256sum > "$MANIFEST"


# La signature porte sur le manifeste complet, pas sur chaque fichier séparément.
openssl dgst -sha256 -sign "$PRIVATE_KEY" \
  -out "$SIGNATURE" "$MANIFEST"


# Vérification indépendante avec la clé publique publiée du signataire.
openssl dgst -sha256 -verify "./cle-signature-preuves.pub.pem" \
  -signature "$SIGNATURE" "$MANIFEST"


# Vérification de l'intégrité des fichiers référencés par le manifeste.
sha256sum --check "$MANIFEST"

Le manifeste doit inclure un fichier de contexte : identifiant du contrôle, période couverte, systèmes sources, version du script, population attendue, exclusions et identifiant de la clé de signature. Sans ce contexte, la signature prouve qu’un ensemble de fichiers n’a pas changé depuis sa signature. Elle ne prouve pas que cet ensemble répond à la question posée.

La clé de signature exige une rotation documentée. Conserver les clés publiques et la chaîne de certificats nécessaires à la vérification pendant toute la durée de conservation des preuves. Révoquer une clé compromise ne rend pas automatiquement les signatures historiques fausses, mais impose d’établir si la compromission est antérieure à la signature. Sans horodatage fiable, cette distinction devient vite brumeuse, ce qui est rarement apprécié lors d’un audit.

Surface d’attaque des preuves de conformité

Section intitulée « Surface d’attaque des preuves de conformité »

La preuve est elle-même une cible. Un attaquant ayant obtenu des privilèges d’administration cherchera souvent à effacer les journaux, désactiver les alertes ou fabriquer une apparence de normalité. La conformité fondée uniquement sur les systèmes contrôlés par le même administrateur que les systèmes observés manque d’indépendance.

Les attaques courantes sont prévisibles :

  • Altération rétrospective des journaux : contrer par export régulier vers une plateforme distincte, droits d’écriture séparés, rétention verrouillée et alertes sur les ruptures de collecte.
  • Suppression sélective : mesurer le volume attendu, surveiller les trous temporels et comparer les sources. Un journal silencieux n’est pas nécessairement un journal propre.
  • Falsification d’horodatage : surveiller la synchronisation temporelle, journaliser les changements d’heure et croiser avec une source externe.
  • Compromission du compte de collecte : limiter ses droits à la lecture, utiliser une identité dédiée, interdire l’administration interactive et surveiller son utilisation hors cadence.
  • Empoisonnement de la population : un inventaire d’actifs incomplet rend les rapports parfaitement faux. Croiser les sources de découverte réseau, l’orchestrateur, l’annuaire et la gestion de configuration.

La séparation des rôles reste le contrôle le plus rentable : l’équipe qui administre le système ne doit pas pouvoir modifier silencieusement la preuve qui évalue son propre travail. Une séparation totale est rarement possible. Une séparation partielle, complétée par des alertes indépendantes et une revue périodique, est déjà nettement meilleure qu’un dossier partagé administré par tous.

Exploitation, conservation et limites de la conformité démontrée

Section intitulée « Exploitation, conservation et limites de la conformité démontrée »

Une preuve doit survivre aux rotations d’équipe, aux changements de fournisseur et aux incidents. Définir la durée de conservation à partir des exigences applicables et du délai de détection réaliste des incidents. Conserver aussi les outils de lecture, les schémas de données et les clés publiques. Une archive chiffrée dont la clé a disparu est parfaitement conforme à la physique, mais peu exploitable.

Sauvegarder les preuves suivant une règle distincte de celle des données métier : copie hors du domaine d’administration courant, tests de restauration et contrôle d’accès minimal. Documenter l’objectif de point de reprise, c’est-à-dire la perte maximale de données acceptable, ainsi que l’objectif de délai de reprise, c’est-à-dire le temps maximal avant remise à disposition. Ces objectifs doivent couvrir les journaux et les preuves, pas seulement les applications. Restaurer une plateforme sans son historique de sécurité revient à remettre en marche un avion dont on aurait effacé le carnet de maintenance.

Superviser la chaîne elle-même : échec d’export, absence de signature, volume anormal, certificat proche de l’expiration, sauvegarde non testée, compte de collecte utilisé en dehors de son créneau. La supervision doit produire des alertes et des tickets, puis conserver la trace de leur traitement. Une alerte ignorée pendant des mois devient une preuve, mais pas celle espérée.

Enfin, une preuve de conformité ne garantit pas l’absence d’incident, la sécurité effective d’une architecture, ni le respect automatique d’une obligation juridique. Elle démontre seulement qu’un contrôle défini a été exécuté sur un périmètre donné, avec un niveau de fiabilité donné. L’analyse de menace, les tests techniques et les décisions de risque restent nécessaires. Les fondations techniques décrites dans l’architecture cyber sont la source de la sécurité ; le dossier de preuves en est le relevé, pas le moteur.

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Sans chaîne de preuves reliant exigence, contrôle, périmètre, exécution et écarts, l’absence d’événement devient indiscernable de l’absence de collecte : rien ne permet de trancher entre un contrôle qui a tourné sans anomalie et un contrôle qui ne tournait plus depuis des semaines. Lors d’une investigation, la fenêtre de compromission ne peut plus être bornée, ce qui oblige à traiter l’intégralité de la période comme suspecte et à élargir les remédiations (rotation de secrets, réinitialisation d’accès) bien au-delà du nécessaire. Les délais réglementaires de notification deviennent difficiles à respecter faute de pouvoir qualifier les données et systèmes concernés. Face à un tiers ou un fournisseur, aucune imputation n’est possible : sans attribution, horodatage fiable ni exhaustivité démontrable, une affirmation ne pèse pas plus que la contraire, et un auditeur retient alors l’hypothèse la plus défavorable.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

Pour démontrer qu’une organisation respecte une règle, il faut d’abord écrire précisément cette règle et dire quels systèmes, comptes ou données elle concerne. Ensuite, un contrôle est choisi pour réduire un risque : par exemple vérifier régulièrement qui possède des droits d’administration.

La preuve doit montrer que cette vérification a réellement eu lieu. Elle doit indiquer la période examinée, la liste complète des comptes concernés, les décisions prises et les personnes responsables. Si un compte n’est pas traité, il faut expliquer pourquoi et conserver la décision de l’accepter temporairement ou de le corriger.

Les fichiers produits doivent pouvoir être reliés à leur origine et protégés contre une modification discrète. Une empreinte numérique permet de détecter qu’un fichier a changé. Une signature numérique permet aussi de vérifier quelle clé a validé le fichier. Cela ne prouve pas que les informations de départ étaient complètes : il faut donc contrôler les sources et surveiller les absences de données.

Les preuves doivent être conservées, sauvegardées et restaurables. Il faut également surveiller les échecs de collecte, les signatures absentes et les accès anormaux aux preuves. Si la collecte s’arrête ou si la clé de signature est compromise, la période concernée doit être identifiée et examinée. Une preuve montre l’exécution d’un contrôle ; elle ne prouve jamais, à elle seule, qu’aucun incident n’a eu lieu.

À lire aussi

Pages voisines

La citent

Ce qu’un auditeur vérifie dans les preuves de conformité

Elle cite