Rdem Systems
AppelerPrendre RDV

Audit pré-ISO 27001 : prouver la synchronisation temporelle (contrôle 8.17)

Publié le 18 mai 2026 — Cas type reconstitué à partir de missions RDEM

Cas type reconstitué. Les chiffres et la chronologie reflètent ce que nous voyons régulièrement chez des PME/ETI françaises se préparant à une certification ISO 27001:2022 ou à un contrôle NIS 2. Aucun client n'est nommé ici — l'objectif est de partager la mécanique d'audit, pas un nom commercial.

Pourquoi le contrôle 8.17 surprend

Depuis la révision ISO/IEC 27001:2022, l'Annexe A introduit un contrôle dédié : 8.17 — Clock synchronization (Synchronisation des horloges). Il impose à l'organisation de prouver que les horloges des systèmes impactant la sécurité de l'information sont synchronisées sur une ou plusieurs sources de temps approuvées.

Dans la pratique, la majorité des organisations qu'on accompagne pensent être conformes (« on est configuré sur pool.ntp.org, donc c'est bon »). L'auditeur, lui, demande des preuves : liste des sources, hiérarchie stratum, mesures d'offset, gestion des falsetickers, et surtout — protection contre la falsification du temps, qui depuis 2026 implique très concrètement la question NTS (Network Time Security, RFC 8915).

Au-delà d'ISO 27001, l'article 21 de NIS 2 (transposé en droit français en 2025) impose des exigences voisines aux entités essentielles et importantes. Le contrôle 8.17 a donc cessé d'être anecdotique : il est devenu un point de friction d'audit.

Diagnostic initial — ce qu'on trouve en arrivant

Première étape sur ce type de mission : dresser un inventaire honnête de l'existant. Quatre observations reviennent presque systématiquement.

Sources de temps non documentées

Chaque admin a configuré au fil des années : pool.ntp.org, le DC, parfois time.windows.com, parfois plus rien. Hiérarchie réelle inconnue, aucune carte des dépendances.

Sources qui dérivent en silence

Une source publique qui passe en Stratum 16 (unsynchronized) continue de répondre aux requêtes — Chrony l'écartera comme falseticker si elle est minoritaire, mais sans alerte dédiée personne ne voit l'incident. Sur les appliances anciennes qui n'ont qu'une seule source, c'est ce trou qui se matérialise après un reboot.

Aucun chiffrement (NTS absent)

NTP classique n'authentifie rien. Un attaquant interne ou un MITM peut décaler l'heure d'un serveur — l'auditeur ISO 2022 demande comment ce risque est couvert.

Pas de monitoring continu

L'offset n'est jamais collecté, donc impossible de produire un historique quand l'auditeur demande : « montrez-moi 30 jours de dérive sur ce KDC ».

Le pendant éditorial de ce diagnostic est synthétisé sur notre article Désynchronisation NTP : menaces sur l'infrastructure IT. Il sert souvent de support à la première réunion avec le RSSI.

L'intervention RDEM, étape par étape

1

Trois NTP internes de référence, peer entre eux

On monte trois serveurs NTP internes dédiés (Chrony sur Debian) qui deviennent l'unique référence temporelle du parc. Trois plutôt que deux pour permettre à Chrony de détecter et écarter un falseticker par vote majoritaire ; idéalement répartis sur trois hyperviseurs distincts, eux-mêmes sur deux ou trois sites différents pour absorber la perte d'un rack, d'un routeur ou d'un site sans casser la synchro du parc. Leurs upstreams sont délibérément mixés pour ne dépendre d'aucun opérateur temps unique — c'est précisément ce que l'auditeur cherche quand il pose la question « que se passe-t-il si votre fournisseur tombe ? » :

  • Sources NTS multi-opérateurs : Cloudflare, Netnod, et notre pool NTS RDEM. Trois entités juridiques différentes, trois infrastructures différentes, toutes en TLS 1.3 authentifié.
  • Sources NTP classiques de confiance : notre Stratum 1 GPS/Galileo opéré en interne et pool.ntp.org pour la diversité géographique. Le non-NTS reste un secours utile : pas tous les appliances upstream parlent NTS aujourd'hui.

Les trois NTP internes sont configurés en peer mutuel (chrony.conf directive peer) pour qu'ils se surveillent entre eux et que la défaillance d'un upstream soit absorbée sans propagation jusqu'aux clients.

2

Bascule totale du parc sur les trois NTP internes

Tous les serveurs, hyperviseurs, contrôleurs de domaine, switches, firewalls et appliances pointent désormais exclusivement sur les trois NTP internes. Pas de mélange avec des sources publiques côté client, pas de fallback exotique. La hiérarchie stratum devient simple à expliquer à l'auditeur : trois sources internes documentées, point.

3

Logging firewall : détecter les serveurs oubliés

Comme on le fait sur notre propre infrastructure (firewalls de bordure de l' AS206014), on accompagne le client pour appliquer la même règle sur ses propres firewalls de sortie : logger tout trafic NTP (UDP 123) sortant qui n'émane pas des trois NTP internes de référence. Cette règle révèle exactement ce qu'on cherche : les machines avec une vieille config (0.pool.ntp.org hardcodée, time.windows.com, IP d'un ancien serveur NTP interne qui n'existe plus, appliance qui tape un serveur du constructeur). Sans ce log, ces reliques restent invisibles parce qu'elles ne provoquent pas d'incident visible — jusqu'au reboot où elles n'arrivent plus à se synchroniser.

4

Monitoring continu et stockage des preuves

On collecte l'offset (chronyc tracking, w32tm /stripchart) toutes les minutes, on le pousse dans la supervision client, et on conserve l'historique pour produire le rapport d'audit. C'est ce qu'on attend d'un service d' infogérance qui prend l'astreinte.

5

Documentation de la chain of trust

L'auditeur ne lit pas votre chrony.conf. Il lit un document daté qui dit : « voici les trois NTP internes, voici leurs upstreams NTS et non-NTS, voici la règle firewall qui bloque/log le reste, voici l'historique d'offset sur 90 jours ». C'est cette matérialisation qui transforme une config technique en preuve d'audit.

Ce que l'auditeur regarde vraiment

Sur les missions de pré-audit qu'on accompagne, voici les pièces qu'un auditeur 27001:2022 demande de manière à peu près systématique pour le contrôle 8.17 :

  • Liste exhaustive des sources de temps, avec leur stratum et leur AS d'origine.
  • Preuve d'authentification de la source (NTS, sinon justification écrite du risque résiduel).
  • Historique de l'offset sur au minimum 30 jours pour un échantillon représentatif : KDC, contrôleur de domaine, hyperviseur, syslog central, équipement de sécurité.
  • Procédure documentée en cas de dérive critique (qui alerte, qui décide d'arrêter le service, quel délai d'investigation).
  • Test de récupération sur incident temporel (équivalent d'un PCA/PRA appliqué à NTP).

Pour aller plus loin sur la lecture juridique exacte du contrôle, la fiche dédiée au contrôle 8.17 sur online-ntp-validator.com reprend le texte et le mappe sur NIS 2, DORA et PCI-DSS — utile à joindre au dossier d'audit. Le même site héberge une checklist audit NTP pour RSSI qu'on utilise pour préparer la séance de revue.

Pourquoi une source RDEM passe l'audit

L'auditeur cherche à éliminer les zones grises. Sur le NTP, deux questions reviennent : « qui opère cette source ? » et « comment savez-vous qu'elle reste fiable ? ».

  • AS public + diversité réseau. La majorité de nos serveurs NTP sont annoncés par notre propre AS206014, opéré en France. Pour la résilience, nous opérons également des serveurs sur d'autres AS partenaires — l'auditeur peut tracer le path BGP de chaque source et constater qu'il n'y a pas de point de défaillance unique côté réseau.
  • Stratum 1 GPS/Galileo/PPS — une de nos sources primaires. Notre antenne GNSS et son récepteur PPS sont opérés et monitorés en interne ; ils ne constituent qu'une des sources primaires du pool RDEM, mélangée à du peering NTP/NTS avec d'autres opérateurs de référence pour la diversité.
  • NTS public par défaut. Tous nos serveurs publics RDEM (hors le Stratum 1 lui-même) servent NTS publiquement, accessible à tous sans demande préalable. La question de l'authentification est tranchée d'emblée.
  • Continuité opérationnelle traçable. RDEM contribue au pool NTP mondial depuis 2005 — la maîtrise du sujet est documentée sur cette durée, même si les machines elles-mêmes ont été renouvelées au fil du temps. La persistance opérationnelle s'appuie aujourd'hui sur des hostnames techniques stables (ntp-*.rdem-systems.com) et sur les pools NTP et NTS RDEM créés en 2025, conçus pour garantir la continuité même quand une machine sous-jacente est déplacée ou remplacée.

Checklist réutilisable

Si vous préparez un audit ISO 27001:2022 ou un contrôle NIS 2, voici les étapes minimales pour ne pas être pris au dépourvu sur le contrôle 8.17 :

  1. Trois NTP internes de référence (Chrony), upstreams mixés NTS + NTP classique, configurés en peer mutuel.
  2. Bascule totale du parc sur ces trois références — aucun client ne pointe directement vers une source publique.
  3. Règle firewall : log (et idéalement blocage) de tout trafic NTP sortant qui n'émane pas des trois NTP internes. Révèle les configurations héritées.
  4. Collecte continue de l'offset, conservation 90 jours minimum.
  5. Procédure d'incident temporel testée au moins une fois par an.
  6. Mise à jour annuelle du document « chain of trust temporelle ».

Pour une équipe qui n'a pas le temps de tout faire en interne, c'est typiquement le périmètre d'un audit RDEM : 2 à 5 jours de mission selon la taille du parc, livrable de pré-audit, recommandations priorisées.

Pour aller plus loin

Vous préparez un audit ISO 27001 ou NIS 2 ?

On déroule une mission de pré-audit ciblée sur la synchronisation temporelle (contrôle 8.17) en 2 à 5 jours, livrable d'audit inclus. Vous repartez avec un dossier prêt à présenter à votre auditeur.

Planifier un appel de 15 minDemander un devis
01 77 62 42 42