Pourquoi est-il important que les serveurs aient exactement la même heure?
J'ai lu plusieurs fois (bien que je ne le trouve pas pour le moment) que les centres de données mettent beaucoup d'efforts pour s'assurer que tous les serveurs ont exactement la même heure. Y compris, mais sans s'y limiter, se soucier des secondes intercalaires.
Pourquoi est-il si important que les serveurs aient la même heure? Et quelles sont les tolérances réelles?
Sécurité
En général, les horodatages sont utilisés dans divers protocoles d'authentification pour aider à empêcher rejouer les attaques, où un attaquant peut réutiliser un jeton d'authentification qu'il a pu voler (par exemple en reniflant le réseau).
L'authentification Kerberos fait exactement cela, par exemple. Dans la version de Kerberos utilisée dans Windows, la tolérance par défaut est de 5 minutes.
Ceci est également utilisé par divers protocoles de mot de passe à usage unique utilisés pour l'authentification à deux facteurs tels que Google Authenticator, RSA SecurID, etc. Dans ces cas, la tolérance est généralement d'environ 30 à 60 secondes.
Sans le temps synchronisé entre le client et le serveur, il ne serait pas possible de terminer l'authentification. (Cette restriction est supprimée dans les dernières versions de MIT Kerberos, en demandant au demandeur et au KDC de déterminer le décalage entre leurs horloges lors de l'authentification, mais ces modifications se sont produites après Windows Server 2012 R2 et ce sera un certain temps avant de le voir dans une version Windows. Mais certaines implémentations de 2FA nécessiteront probablement toujours des horloges synchronisées.)
Administration
La synchronisation des horloges facilite le travail avec des systèmes disparates. Par exemple, la corrélation des entrées de journal de plusieurs serveurs est beaucoup plus facile si tous les systèmes ont la même heure. Dans ces cas, vous pouvez généralement travailler avec une tolérance de 1 seconde, ce qui NTP fournira, mais idéalement, vous voulez que les heures soient aussi étroitement synchronisées que vous pouvez vous le permettre. PTP, qui fournit beaucoup plus serré tolérances, peut être beaucoup plus coûteux à mettre en œuvre.
Principalement, c'est pour que vous puissiez corréler les incidents à partir des journaux sur différents appareils. Supposons que vous ayez un incident de sécurité où quelqu'un accède à votre base de données via votre serveur Web - vous voulez que les horodatages sur votre pare-feu, votre équilibreur de charge, votre serveur Web et votre serveur de base de données correspondent tous afin que vous puissiez trouver les journaux sur chaque appareil qui se rapportent à l'incident. Idéalement, vous aimeriez que tout se déroule en quelques millisecondes. Et il doit être synchronisé avec l'heure externe réelle, afin que vous puissiez également corréler vos journaux avec des journaux tiers si cela s'avère nécessaire.
Non seulement c'est important du point de vue de l'administration, mais la synchronisation des horloges peut également être importante du point de vue de la corrélation au niveau de l'application. Cela dépend de la façon dont la solution est conçue, de la façon dont les applications en cours d'exécution obtiennent leur horodatage pour toutes les transactions avec lesquelles elles peuvent travailler. J'ai vu la validation des transactions échouer en raison d'une application exécutée sur un serveur avec un décalage trop important (environ 20 secondes à l'avenir) par rapport aux autres avec lesquelles il interagissait.
De plus, si la virtualisation sur un serveur VMWare ESXi par exemple, et l'heure du VM n'est pas synchronisée avec celle de l'hyperviseur, une action comme vmotion peut resynchroniser le VM horloge avec les hyperviseurs et cela à son tour peut conduire à des résultats imprévisibles si la différence de temps est suffisamment grande.
Je ne sais pas quelles sont les tolérances réelles, car je pense que cela dépend beaucoup du type de systèmes qu'il existe, mais je pense qu'en règle générale, il est possible de garder les serveurs dans le centre de données ayant moins d'une seconde de décalage entre eux.
Comme vous avez mentionné les secondes intercalaires, il convient de noter qu'elles nécessitent une manipulation particulièrement difficile.
Ils sont généralement ajoutés en injectant une seconde à 23:59:60, ce qui pose problème si vous validez des horodatages de 0 à 59 pour les champs minutes et secondes. L'alternative de répéter 23:59:59 pour faire 2 secondes n'est pas beaucoup mieux car cela gâchera tout ce qui est sensible au timing jusqu'à un niveau par seconde.
Google a en fait trouvé une bonne solution il y a quelque temps qui ne semble pas encore avoir été largement adoptée. Leur solution était d'appliquer un "frottis" de saut et de diviser le changement sur une période de temps, l'ensemble du processus étant géré par un serveur NTP. Ils ont publié un blog à ce sujet en 2011, rend la lecture intéressante et semble pertinente pour cette question.
Chaque fois que des horodatages sont impliqués, les appareils désynchronisés peuvent créer des incohérences logiques, comme: A envoie une requête à B, et la réponse de B est accompagnée d'un horodatage plus tôt que celui de la requête, ce qui peut amener A à l'ignorer.
Je suis d'accord avec tout le point ci-dessus. Je veux jeter plus de pensées
Certaines bases de données telles que Cassendra s'appuient fortement sur l'horodatage. C'est ainsi qu'il gère la concurrence.
Un horodatage différent gâchera complètement la base de données.