Ich habe mehrmals gelesen (obwohl ich es momentan nicht finde), dass Rechenzentren große Anstrengungen unternehmen, um sicherzustellen, dass alle Server genau dieselbe Zeit haben. Einschließlich, aber nicht beschränkt auf die Sorge um Schaltsekunden.
Warum ist es so wichtig, dass Server die gleiche Zeit haben? Und was sind die tatsächlichen Toleranzen?
Antworten:
Im Allgemeinen werden Zeitstempel in verschiedenen Authentifizierungsprotokollen verwendet, um Wiederholungsangriffe zu verhindern , bei denen ein Angreifer ein Authentifizierungstoken wiederverwenden kann, das er stehlen konnte (z. B. durch Aufspüren des Netzwerks).
Die Kerberos-Authentifizierung erledigt beispielsweise genau dies. In der in Windows verwendeten Version von Kerberos beträgt die Standardtoleranz 5 Minuten.
Dies wird auch von verschiedenen Einmalpasswort-Protokollen verwendet, die für die Zwei-Faktor-Authentifizierung verwendet werden, z. B. Google Authenticator, RSA SecurID usw. In diesen Fällen liegt die Toleranz normalerweise bei 30-60 Sekunden.
Ohne die derzeitige Synchronisierung zwischen Client und Server wäre eine vollständige Authentifizierung nicht möglich. (Diese Einschränkung wird in den neuesten Versionen von MIT Kerberos aufgehoben, indem der Anforderer und das KDC den Versatz zwischen ihren Uhren während der Authentifizierung ermitteln. Diese Änderungen traten jedoch nach Windows Server 2012 R2 auf und es wird eine Weile dauern, bis sie in Windows angezeigt werden Version. Aber einige Implementierungen von 2FA werden wahrscheinlich immer synchronisierte Uhren benötigen.)
Synchronisierte Uhren erleichtern die Arbeit mit unterschiedlichen Systemen. Das Korrelieren von Protokolleinträgen von mehreren Servern ist beispielsweise viel einfacher, wenn alle Systeme dieselbe Zeit haben. In diesen Fällen können Sie normalerweise mit einer Toleranz von 1 Sekunde arbeiten, die von NTP bereitgestellt wird. Idealerweise möchten Sie jedoch, dass die Zeiten so genau synchronisiert werden, wie Sie es sich leisten können. PTP, das viel engere Toleranzen bietet, kann in der Implementierung viel teurer sein.
makewird auch durch Zeitversatz zwischen Client / Server-NFS verwirrt.
Dies dient hauptsächlich dazu, Vorfälle aus Protokollen auf verschiedenen Geräten zu korrelieren. Angenommen, Sie haben einen Sicherheitsvorfall, bei dem jemand über Ihren Webserver auf Ihre Datenbank zugreift. Sie möchten, dass die Zeitstempel in Ihrer Firewall, Ihrem Load Balancer, Ihrem Webserver und Ihrem Datenbankserver übereinstimmen, damit Sie die Protokolle auf jedem Gerät finden die sich auf den Vorfall beziehen. Idealerweise möchten Sie, dass alles innerhalb weniger Millisekunden ist. Und es muss mit der tatsächlichen externen Zeit synchronisiert sein, damit Sie Ihre Protokolle auch mit Protokollen von Drittanbietern korrelieren können, falls dies erforderlich sein sollte.
Dies ist nicht nur aus administrativer Sicht wichtig, sondern auch aus der Sicht der Korrelation auf Anwendungsebene, wenn Uhren synchronisiert sind. Dies hängt davon ab, wie die Lösung konzipiert ist und wie die ausgeführten Anwendungen ihren Zeitstempel für alle Transaktionen erhalten, mit denen sie möglicherweise arbeiten. Ich habe festgestellt, dass die Transaktionsvalidierung fehlgeschlagen ist, weil eine Anwendung auf einem Server ausgeführt wurde, der im Vergleich zu den anderen Anwendungen, mit denen sie interagierte, einen zu großen Versatz aufwies (in der Zukunft etwa 20 Sekunden).
Auch wenn die Virtualisierung beispielsweise auf einem VMWare ESXi-Server und die Uhrzeit der VM nicht mit der des Hypervisors synchronisiert sind, kann eine Aktion wie vmotion die VM-Uhr erneut mit den Hypervisoren synchronisieren, was wiederum zu unvorhersehbaren Ergebnissen führen kann wenn der Zeitunterschied groß genug ist.
Ich weiß nicht, wie hoch die tatsächlichen Toleranzen sind, da ich denke, dass dies stark von der Art der Systeme abhängt, aber ich denke, dass es im Allgemeinen erreichbar ist, die Server im Rechenzentrum mit einem Abstand von weniger als einer Sekunde zueinander zu belassen.
Da Sie Schaltsekunden erwähnt haben, ist zu beachten, dass diese eine besonders schwierige Handhabung erfordern.
Sie werden normalerweise durch Injizieren einer Sekunde als 23:59:60 hinzugefügt. Dies ist problematisch, wenn Sie Zeitstempel als 0-59 für die Minuten- und Sekundenfelder validieren. Die Alternative, 23:59:59 zu wiederholen, um es 2 Sekunden lang zu machen, ist nicht viel besser, da dies mit allem zu tun hat, das zeitkritisch bis auf eine Stufe pro Sekunde ist.
Google hat vor einiger Zeit eine gute Lösung gefunden, die offenbar noch nicht weit verbreitet ist. Die Lösung bestand darin, einen Sprung "Abstrich" zu machen und die Änderung über einen bestimmten Zeitraum aufzuteilen, wobei der gesamte Prozess von einem NTP-Server verwaltet wurde. Sie haben 2011 einen Blog darüber veröffentlicht , sorgen für eine interessante Lektüre und scheinen für diese Frage relevant zu sein.
Immer wenn Zeitstempel beteiligt sind, können desynchronisierte Geräte logische Inkohärenzen erzeugen, wie z. B .: A sendet eine Anfrage an B, und die Antwort von B kommt mit einem Zeitstempel vor dem der Anfrage, wodurch A sie möglicherweise ignoriert.
Ich stimme dem obigen Punkt zu. Ich möchte mehr Gedanken machen.
Einige Datenbanken wie Cassendra verlassen sich stark auf den Zeitstempel . So geht es mit Parallelität.
Unterschiedliche Zeitstempel zerstören die Datenbank vollständig.