Spezifikation Infrastrukturkomponenten: Zeitdienst

Transcription

Einführung der Gesundheitskarte
Spezifikation
Infrastrukturkomponenten:
Zeitdienst
Version:
1.3.0
Revision
main/rel_main/5
Stand:
20.06.2008
Status:
freigegeben
gematik_INF_Spezifikation_Zeitdienst.doc
Version: 1.3.0
Seite 1 von 49
© gematik
Stand: 20.06.2008
Spezifikation Infrastruktur komponenten:
Zeitdienst
Dokumentinformationen
Änderungen zu den Vorversionen
Anforderungen an die Verfügbarkeiten und SLA für den Zeitdienst wurden bislang in
diesem Dokument genannt, da bis dato keine einheitlichen Vorgaben existieren. Diese
Daten werden im Rahmen von Betriebsvereinbarungen definiert und sind somit nicht
mehr Bestandteil dieses Dokumentes.
Die Definition der Anzahl von Serversystemen im Stratum 1 und Stratum 2 Bereich in
dieser Spezifikation wird ergänzt um das Wort „mindestens“. So soll herausgestellt
werden, dass es einem Bieter/Betreiber durchaus gestattet ist, die genannte
Mindestanzahl an Serversystemen zu überschreiten, aber niemals zu unterschreiten.
Im Rahmen der gematik-internen Tests zum Zeitdienst wurde festgestellt, dass die durch
das ISC veröffentlichten stabilen NTP-Versionen (stable releases) bis einschließlich ntp4.2.4p2 in Kombination mit Linux Kerneln kleiner Version 2.6.19 Fehler bei der
Zeitsynchronisation reproduzierbar verursachen. Stabile NTP-Versionen kleiner 4.2.4p0
können weiterhin trotz korrekter Kompilierungsparameter keine Timingstatistiken
erzeugen. Die genannten Fehler sind in der aktuellen Version 4.2.4p3 ff behoben. Eine
entsprechende Einsatzempfehlung dieser Version wird eingefügt.
In den bisherigen Versionen dieses Dokumentes werden die Anbieter und Betreiber von
Services in der Telematikinfrastruktur bereits gehalten, Rechnersysteme und
Komponenten mit den zentralen Zeitservern der Stratum 2 Ebene zu synchronisieren.
Rückfragen von Betreibern als auch Tickets führen allerdings zu dem Schluss, dass die
bisherigen Definitionen noch nicht eindeutig genug waren. Zur weiteren Verdeutlichung,
welcher Betreiber sich wie zu synchronisieren hat, werden Ergänzungen in den
Abschnitten 5.1.1.10 und 5.1.1.16 vorgenommen.
Aus redaktionellen Gründen wurde des bisherige Anhang A7 als Anhang A eingeordnet,
die Verzeichnisse finden sich jetzt in Anhang B.
Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind farblich gelb
markiert. Sofern ganze Kapitel eingefügt wurden, wurde zur besseren Lesbarkeit lediglich
die Überschrift durch gelbe Markierung hervorgehoben.
Referenzierung
Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter:
[gemNTP]
gematik: Einführung der Gesundheitskarte Spezifikation Infrastrukturkomponenten: Zeitdienst
Dokumentenhistorie
Version: 1.3.0
Seite 2 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Version Stand
Kap./
Seite
Grund der Änderung, besondere Hinweise
Bearbeitung
0.0.01
bis
0.0.12
09.03.06
Neuerstellung des Konzepts
AG8
0.0.13
13.03.06
Korrekturen nach AG – interner QS
Redaktionelle Überarbeitung im Bereich der
Anforderungen sowie Kapitel 5 und 6
AG8
0.014
04.04.06
AG8
Redaktionelle Änderungen nach AG –
interner QS,
Kapitel 6 „Autokey“ wird als „offen“ deklariert,
da Tests zum Autokey Verfahren noch nicht
abgeschlossen sind.
0.0.15
06.04.06
Letzte Änderungen vor Übergabe an interne
QS
AG8
0.0.16
12.04.06
Änderungen durch QS
IQS
0.0.17
29.05.06
Änderungen nach gematik interner QS,
Reorganisation Anforderungen und
Annrahmen sowie deren Referenzierungen
AG8
0.9.0
30.05.06
Freigabe zur Vorkommentierung
gematik
1.0.0
16.08.06
Freigabe nach Einarbeitung der Kommentare gematik
1.0.1
10.01.07
1.1.0
16.01.07
freigegeben
gematik
1.1.1
12.04.07
Zusätzliche Stratum 2 Server
AG8
1.2.0
04.05.07
freigegeben
gematik
1.2.1
05.09.07
Anforderungen an SLA- und Verfügbarkeiten
wurden im Rahmen von
Betriebsvereinbarungen entfernt,
Ergänzung der Definition der Anzahl von
SPE/ZD
AG8
Anpassung an aktuelle Entwicklungen:
Autokey Protokoll wird nicht verwendet, daher
Entfernung aller relevanten Textpassagen
A6
und Vermerk im Anhang A6 –
Entscheidungen und Annahmen,
5.1.1.7, Änderung hinsichtlich der Mindestentfernung
5.1.1.10 von Rechenzentren zueinander
5
Aufnahme von Hersteller- und Anbieterneutralität,
6
Anpassung betrieblicher Aspekte an aktuelle
Gegebenheiten, (Beispiel: Kompilierung von
ntp für den Einsatz in der Telematikinfrastruktur)
Version: 1.3.0
Seite 3 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Version Stand
Kap./
Seite
Grund der Änderung, besondere Hinweise
Bearbeitung
Serversystemen um das Wort „mindestens“
Aktualisierte Informationen zur Verwendung
von NTP-Versionen
Aktualisierung externer Links zu ntp.isc.org,
da die ISC auf ein neues Content
Management System migriert hat und sich die
URL’s geändert haben.
1.3.0
20.06.08 5.1.1.10 Ergänzungen in der Definition, welche
Betreiber vpn Fachanwendungen und –
diensten sowie Komponenten sich mit
Zeitservern der Stratum 2 Ebene (zentral) zu
synchronisieren haben.
5.1.1.16 Festlegung der Synchronisationsintervallen
5.1.1.5 Deklaration von GPS Empfängern als
Zeitquelle nur für den Notfall
3.3
Die Tabelle „Anforderungen“ wurde auf die
aktuelle Formatvorlage umgestellt, hat
inhaltlich keine Änderung erfahren.
SPE/ZD
20.06.08 Anhang Restrukturierung: A7 jetzt A, A1 bis A6 jetzt
B1 bis B6
QM
20.06.08
gematik
freigegeben
Version: 1.3.0
Seite 4 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Inhaltsverzeichnis
Dokumentinformationen ..................................................................................... 2
Inhaltsverzeichnis................................................................................................ 5
1
Zusammenfassung ....................................................................................... 7
2
Einführung ..................................................................................................... 8
2.1
Zielsetzung und Einordnung des Dokumentes ..............................................8
2.2
Zielgruppe .........................................................................................................8
2.3
Geltungsbereich ...............................................................................................8
2.4
Arbeitsgrundlagen............................................................................................9
2.5
Abgrenzung des Dokumentes .........................................................................9
2.5.1
Qualifizierte Zeitstempel/Qualifizierte und akkreditierte Zeitstempel...........9
2.6
3
4
5
Verwendung von Schüsselworten...................................................................9
Anforderungen und Annahmen ................................................................. 10
3.1
Einleitung ........................................................................................................10
3.2
Nomenklatur ...................................................................................................10
3.3
Anforderungen................................................................................................10
3.4
Annahmen.......................................................................................................14
Systemüberblick ......................................................................................... 15
4.1
Zweck ..............................................................................................................15
4.2
Funktionsumfang ...........................................................................................16
4.3
Grobstruktur des Dienstes.............................................................................16
4.4
Rahmenbedingungen .....................................................................................17
Realisierung................................................................................................. 19
5.1
Topologie der Zeitdienste ..............................................................................19
5.1.1
Grundsätzlicher Aufbau............................................................................19
5.1.1.1
Network Time Protocol v4 ...................................................................19
5.1.1.2
Netzwerkprotokoll................................................................................19
5.1.1.3
Hierarchische Konzeption....................................................................19
5.1.1.4
Betriebsarten NTP...............................................................................20
5.1.1.5
Zeitquellen der Stratum 1 Server.........................................................20
5.1.1.6
Betriebsverantwortung der Zeitserver..................................................20
Version: 1.3.0
Seite 5 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
5.1.1.7
Technische Realisierung der Stratum 1 Ebene....................................21
5.1.1.8
Verfügbarkeiten der Stratum 1 Ebene .................................................21
5.1.1.9
Realisierung der Ebene Stratum 2 dezentral .......................................21
5.1.1.10 Realisierung der Ebene Stratum 2 zentral ...........................................22
5.1.1.11 Zeitquelle der Stratum 2 Ebene ...........................................................23
5.1.1.12 Verfügbarkeit der Stratum 2 Ebene (zentral und dezentral) .................23
5.1.1.13 Technische Konzeption der Stratum 3 Ebene......................................24
5.1.1.14 Verfügbarkeit der Stratum 3 Ebene .....................................................24
5.1.1.15 Abwehrmechanismen gegen NTP-DoS/NTP-DDoS ............................24
5.1.1.16 Synchronisationsintervalle...................................................................24
5.1.1.17 Kurzzeitgenauigkeit der Stratum 1 Server ...........................................27
5.1.1.18 Freilaufgenauigkeit der Zeitserver .......................................................27
5.1.1.19 Skalierbarkeit des Dienstes .................................................................27
5.1.1.20 Berücksichtigung von Zeitzonen..........................................................27
5.1.1.21 Berücksichtigung von Laufzeitvarianzen..............................................28
5.1.2
Aufbau und Funktionsweise des Zeitdienstes ..........................................28
5.1.3
Administration des Zeitdienstes ...............................................................31
5.1.4
Funktionen und Redundanz .....................................................................31
5.1.4.1
Dienstnutzung .....................................................................................31
5.2
Skalierung .......................................................................................................32
5.2.1
Lastannahmen .........................................................................................33
6
Erweiterte Funktionen und Betrieb............................................................ 36
6.1
Telematikinfrastruktur-Betrieb der NTP-Server............................................36
Anhang A – Beispiel Kompilierung von NTP................................................... 37
A1 – Empfehlungen zu den zu verwendenden Versionen von ntp ........................37
A2 – Vorbereitungen zur Übersetzung des ntp tarballs .........................................38
A3 – Entfernen alter NTP-Installationen ..................................................................38
A4 – Kompilierung von NTP .....................................................................................38
A2 –Kompilierung .....................................................................................................39
A3 – Betriebssystemabhängige Pakete / Binärdistributionen ...............................39
Anhang B............................................................................................................ 40
B1 - Abkürzungen .....................................................................................................40
B2 – Glossar ..............................................................................................................41
B3 – Abbildungsverzeichnis.....................................................................................44
B4 - Tabellenverzeichnis ..........................................................................................44
B5 - Referenzierte Dokumente .................................................................................45
B6 – Entscheidungen und Annahmen .....................................................................47
B6.1 – Annahmen ......................................................................................................47
B6.2 – Entscheidungen.............................................................................................48
Version: 1.3.0
Seite 6 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
1 Zusammenfassung
Mit Verabschiedung des Gesetzes zur Modernisierung der gesetzlichen
Krankenversicherung (GKV-Modernisierungsgesetz – GMG) wurde die Einführung der
elektronischen Gesundheitskarte beschlossen, die ebenso die Einführung einer zentralen
Telematikinfrastruktur, kurz TI, impliziert. Die in dieser Infrastruktur untergebrachten
Systeme sowie die so genannten dezentralen Komponenten sind zwingend auf eine stets
verfügbare, exakte Uhrzeit angewiesen.
Ohne diese Informationen wäre es beispielsweise nicht möglich, die Signatur eines
elektronischen Dokumentes mit einer verlässlichen Information über den Signierzeitpunkt
auszustatten, ohne gleich auf qualifizierte Zeitstempel ausweichen zu müssen.
Die hier vorliegende Spezifikation des Zeitdienstes beschreibt ein Verfahren, das
basierend auf existenten und weltweit jahrelang erprobten Technologien für alle zentralen
und dezentralen Komponenten und Systeme, bis hinunter zu den Primärsystemen der
Leistungserbringer eine bundesweit einheitliche Systemzeit gewährleistet1.
1
Der Begriff „Einheitliche Systemzeit“ ist relativer Natur, die Schwankungen bewegen sich je nach
Qualität der Systemkomponenten im Millisekunden- bis hinunter zum Picosekundenbereich.
Version: 1.3.0
Seite 7 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
2 Einführung
2.1 Zielsetzung und Einordnung des Dokumentes
Das vorliegende Dokument dient als Spezifikation zur Realisierung eines Zeitdienstes auf
Basis allgemein gültiger und anerkannter Verfahren, die über Jahre hinweg bereits
weltweit erprobt worden sind. Es enthält Mindeststandards zur Umsetzung der Lösung,
schließt jedoch auf der anderen Seite auch Funktionalitäten aus, die im Umfeld einer
Telematikinfrastruktur unpraktikabel und wenig sinnvoll erscheinen.
Auch ökonomische Aspekte sind berücksichtigt worden. Zeigt sich in den kommenden
Jahren, dass die Lastanforderungen zu niedrig angesetzt worden sind, so kann der
Zeitdienst horizontal skaliert werden, um den erhöhten Anforderungen gerecht zu werden.
Auch die Sicherheit und Verfügbarkeit des Dienstes muss selbstverständlich betrachtet
werden. Die Verfügbarkeit wird durch allgemein gebräuchliche Hochverfügbarkeitsarchitekturen sichergestellt.
Im Rahmen der Einführung der elektronischen Gesundheitskarte nach § 291a SGBV
wurde bereits in den Vorprojekten bIT4health und protego.net identifiziert, dass ein
Zeitdienst zwar primär keinen Einfluss auf die eigentliche Einführung der eGK hat, für den
Betrieb der Telematikinfrastruktur (ohne die eine elektronische Gesundheitskarte wenig
sinnvoll erscheint) jedoch unerlässlich ist.
2.2 Zielgruppe
Dieses Dokument richtet sich an die Betreiber von zentralen Infrastrukturdiensten und
Telematik-Zugangsprovider, die diesen Dienst zur Verfügung stellen müssen.
Komponenten und (Fachdienst-)Systeme greifen auf den Zeitdienst zurück und
synchronisieren die jeweilige Systemzeit.
Anbieter von Konnektoren müssen auf den Zeitdienst der Telematikinfrastruktur
zurückgreifen, um eine korrekte Systemzeit zu beziehen. Wiederum kann der Konnektor
den Primärsystemrechnern gegenüber als Anbieter eines Zeitdienstes (NTP) auftreten.
Dies beinhaltet jedoch nicht die Funktion eines qualifizierten und akkreditierten
Zeitstempels.
Primärsystemhersteller können die Systemzeiten der Primärsystemrechner mit dem durch
den Konnektor ggf. angebotenen Zeitdienst synchronisieren.
2.3 Geltungsbereich
Dieses Dokument ist bindend für die in 2.2 genannte Zielgruppe mit Ausnahme der
Primärsystemrechner, bei denen die Nutzung des Zeitdienstes lediglich empfohlen
werden kann.
Version: 1.3.0
Seite 8 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Die in diesem Dokument getroffenen Festlegungen sind als verbindlich zur Realisierung
eines Zeitdienstes anzusehen.
2.4 Arbeitsgrundlagen
Als Grundlage für die Spezifikation eines Zeitdienstes dienen die Dokumente
• gematik Gesamtarchitektur [gemGesArch],
• gematik Sicherheitskonzept [gemSiKo],
• gematik Schutzbedarfsfeststellung [gemSiKo#Anh.C],
• Konnektorspezifikation [gemSpec_Kon]
aus denen sich die in diesem Papier aufgestellten Anforderungen an den Zeitdienst
ergeben.
2.5 Abgrenzung des Dokumentes
2.5.1 Qualifizierte Zeitstempel/Qualifizierte und akkreditierte Zeitstempel
Obgleich eng miteinander verwandt, ist der qualifizierte Zeitstempel bzw. der qualifizierte
und akkreditierte Zeitstempel nicht Gegenstand der Betrachtungen in diesem Dokument.
Rechtssichere, qualifizierte und akkreditierte Zeitstempel können nur von akkreditierten
Anbietern erstellt werden. Das Verfahren ist im SigG festgeschrieben und findet ggf. im
Rahmen der Spezifikation der PKI Beachtung.
2.6 Verwendung von Schüsselworten
Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden
die dem RFC 2119 [RFC2119] entsprechenden kapitalisierten, deutschen Schlüsselworte
verwendet:
• MUSS/MÜSSEN. Absolutgültige und normative FESTLEGUNGEN sind durch
das Schlüsselwort MUSS gekennzeichnet.
• DARF NICHT/DÜRFEN NICHT. Absolutgültige und normative Ausschlüsse
sind durch das Schlüsselwort DARF NICHT gekennzeichnet.
• SOLL/SOLLEN. Empfehlungen sind durch das Schlüsselwort
gekennzeichnet. Abweichungen sind in begründeten Fällen möglich.
SOLL
• SOLL NICHT/SOLLEN NICHT. Empfehlungen zu Ausschlüssen sind durch
das Schlüsselwort SOLL NICHT gekennzeichnet. Abweichungen sind in
begründeten Fällen möglich.
• KANN/KÖNNEN. Vollständig fakultative Eigenschaften sind durch das
Schlüsselwort KANN gekennzeichnet und haben keinen Normierungs- und
keinen allgemeingültigen Empfehlungscharakter.
Version: 1.3.0
Seite 9 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
3 Anforderungen und Annahmen
3.1 Einleitung
Grundsätzlich wird unterschieden zwischen Anforderungen und Annahmen.
Anforderungen beschreiben Ansprüche an einen Dienst, die aus Spezifikationen und
Dokumenten anderer gematik Arbeitsgruppen oder gesetzlichen Grundlagen resultieren
und im Anforderungsmanagement erfasst wurden.
Annahmen umschreiben Vorgaben, die notwendigerweise festgelegt werden müssen, um
anstelle noch nicht definierter Anforderungen ein Ziel erreichen zu können.
Sowohl Anforderungen als auch Annahmen werden jeweils nach funktionalen- und nichtfunktionalen Aspekten unterschieden
3.2 Nomenklatur
Funktionale und nicht-funktionale Anforderungen und Annahmen werden jeweils
fortlaufend nummeriert, um eine bessere rekursive Nachverfolgung von
Anforderungen/Annahmen und deren Lösungsansätze zu ermöglichen. Die
Nummerierung ist folgendermaßen aufgebaut:
• AF-ZD-010
Funktionale Anforderung – Zeitdienst – lfd. Nr. 010
• AN-ZD-010
Nicht-funktionale Anforderung – Zeitdienst – lfd. Nr. 010
• AnF-ZD-010
Funktionale Annahme – Zeitdienst – lfd. Nr. 010
• AnN-ZD-010
Nicht-funktionale Annahme – Zeitdienst – lfd. Nr. 010
3.3 Anforderungen
Der Zeitdienst dient der Synchronisation aller zentralen und dezentralen Komponenten in
der Gesundheitstelematik und KANN auch den Primärsystemrechnern als
Synchronisationsquelle dienen.
In der nachfolgenden Tabelle sind die funktionalen Anforderungen an den Zeitdienst mit
einer fortlaufenden Nummerierung versehen und beschrieben.
Version: 1.3.0
Seite 10 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Tabelle 1: Anforderungen
Afo-ID
Kla Titel
sse
Quelle
Beschreibung
Release
Umgesetzt
durch
(ohne)
Der Zeitdienst MUSS auf ein Protokoll
aufsetzen, das ohne patent- und
lizenzrechtliche Einschränkungen frei
verwendet werden darf. Das Protokoll
MUSS bereits weltweit verbreitet und
erprobt sein.
2.2.1
Abschnitt
5.1.1.1
-
-
AF-ZD- F
010
Zeitdienst:
Protokolle
AF-ZD- F
020
Authentizität
der Zeitserver /
Sicherheitsanforderungen
(Entfallen)
AF-ZD- F
030
Konzeption der
tertiären Ebene
Konnektoren repräsentieren die Zeitserver 2.2.1
der tertiären Ebene.
Die hierarchische Organisation des
Zeitdienstes ist der Funktionalen Annahme
ZD-FAnn-030 beschrieben.
Zum einen nutzen sie die von der
sekundären Ebene bezogene Systemzeit
zur genauen Eigenprotokollierung von
Ereignissen, zum anderen können (im
Sinne von KANN) sie den Primärsystemen
als Zeitsynchronisationsquelle dienen.
Sofern ein Konnektor nicht als Zeitserver
gegenüber den Primärsystemen auftritt,
MUSS er als Client die Zeitinformationen
der sekundären Ebene nutzen.
Abschnitt
5.1.1.7,
5.1.1.13
AF-ZD- F
040
Abwehrmechanismen
Zum Selbstschutz sind Verfahren
2.2.1
vorzusehen, mit dessen Hilfe der Zeitdienst
die Anzahl der an ihn gerichteten Anfragen
unterdrücken beziehungsweise
beeinflussen MUSS.
Abschnitt
5.1.1.15
AF-ZD- F
050
Netzwerkprotokoll
In Anlehnung an AF-ZD-010 MÜSSEN
ausschließlich bereits bei der IANA zu
diesem Zweck registrierte Ports
Verwendung finden (vgl.: [IANA-PORT]).
2.2.1
Abschnitt
5.1.1.2
AF-ZD- F
060
Betriebsarten
vom Zeitdienst
Zum Einsatz MUSS ausschließlich die
Betriebsart „Client – Server“, kommen,
andere Konzepte sind unter Last- und
Sicherheitsaspekten nicht vorgesehen.
2.2.1
Abschnitt
5.1.1.4
AF-ZD- F
070
Zeitquellen
Der Zeitdienst MUSS seine Zeitinformation 2.2.1
von der gesetzlichen Zeit für die
Bundesrepublik Deutschland oder einem
Äquivalent beziehen können.
Abschnitt
5.1.1.5
AF-ZD- F
080
Technisch –
konzeptionelle
Anforderungen
an die primäre
Ebene
Die Systeme der primären Ebene MÜSSEN 2.2.1
hochverfügbar ausgelegt werden.
Sie MÜSSEN derart ausgestaltet sein, dass
sie auch den in [AnN-ZD-030] gestellten
Anforderungen genügen
Abschnitt
5.1.1.7
AF-ZD- F
090
Technisch –
konzeptionelle
Anforderungen
Diese Systeme der sekundären Ebene
werden in den Rechenzentren der
Telematik-Zugangsprovider aufgebaut und
Abschnitt
5.1.1.9
Version: 1.3.0
2.2.1
Seite 11 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Afo-ID
Kla Titel
sse
Quelle
Beschreibung
Release
Umgesetzt
durch
an die
sekundäre
Ebene Stratum
2 dezentral
von diesen betrieben.
Die sekundären Zeitserver eines TelematikZugangsproviders dürfen sowohl bis zur
öffentlichen Internet-Infrastruktur als auch
bis zum nicht-öffentlichen TelematikNetzwerk jeweils keinen gemeinsamen
Single-Point-of-failure besitzen.
Dies beinhaltet neben der physikalischen
Ausgestaltung des Aufstellungsortes auch
eine getrennte Netzinfrastruktur inklusive
der jeweils redundanten Anbindungen
AF-ZD- F
100
Fehlerresistenz
der Zeitserver,
sekundäre
Ebene
Die sekundäre Ebene (Stratum 2 zentral
2.2.1
und dezentral) MUSS derart realisiert
werden, dass Möglichkeiten zur Erkennung
von byzantinischen Fehlern und permanent
falschen Zeitinformationen gegeben sind.
Dabei MUSS jeweils mindestens ein Server
mit fehlerhaften Zeitinformationen
erkennbar sein.
Dies gilt auch während des Ausfalls einer
Plattformhälfte im anderen Brandabschnitt
bzw. Rechenzentrum – allerdings nicht für
byzantinische Fehler.
Abschnitt
5.1.1.9
AF-ZD- F
110
Technisch –
konzeptionelle
Anforderungen
an die
sekundäre
Ebene Stratum
2 zentral
2.2.1
Damit Anbieter von zentralen
Telematikinfrastrukturdiensten und
Betreiber einzelner
Fachanwendungssysteme nicht jeweils
eigene Server der sekundären Ebene
aufbauen müssen, betreibt/verantwortet die
gematik entsprechende Server.
Betreiber von Fachanwendungsdiensten
sowie zentralen Infrastrukturdiensten
KÖNNEN eigene Zeitserver betreiben, sind
jedoch nicht dazu verpflichtet. Sofern sie
eigene Zeitserver betreiben, MÜSSEN sie
mit den Zeitservern der primären Ebene
synchronisieren.
Abschnitt
5.1.1.10
AF-ZD- F
120
Kurzzeitgenauigkeit der
Systeme der
primären Ebene
Die Kurzzeitgenauigkeit von Systemen der 2.2.1
primären Ebene MUSS 1ms nicht
überschreiten
AF-ZD- F
130
ZeitserverFreilaufgenauig
keit
Die Freilaufgenauigkeit von Systemen der 2.2.1
primären Ebene MUSS mindestens ±1ppm
(~32s in 365 Tagen) betragen.
Die Freilaufgenauigkeit von Systemen der
sekundären Ebene MUSS mindestens
±100 ppm (52,6 Minuten in 365 Tagen)
betragen
Abschnitt
5.1.1.18
AF-ZD- F
Anforderungen
an die
Entfallen
-
2
3
-
Abschnitt
5.1.1.17
2
Unter Kurzzeitgenauigkeit wird die Abweichung der internen Uhr des NTP-Servers vom zuletzt
empfangenen Zeitsignal verstanden.
3
Genauigkeit des Zeitservers ohne Synchronisation
Version: 1.3.0
Seite 12 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Afo-ID
Kla Titel
sse
Quelle
Beschreibung
Release
Umgesetzt
durch
140
Netzwerkplanun
g, insbes. NAT
AF-ZD- F
150
Berücksichtigun
g von Zeitzonen
Der Zeitdienst muss in der Lage sein, ein
einheitliches System zur Berücksichtigung
von Zeitzonen abzubilden.
2.2.1
Abschnitt
5.1.1.20
AFZD160
F
Berücksichtigun
g von
Laufzeitvarianze
n
Der Zeitdienst ist derart auszugestalten,
dass Laufzeitvarianzen innerhalb eines
Netzwerkes berücksichtigt werden
2.2.1
Abschnitt
5.1.1.21
ANZD010
N
Synchronisation
srhythmus
Systeme der primären Hierarchieebene
2.2.1
MÜSSEN die Zeitinformation permanent
abgleichen.
Systeme der sekundären Ebene MÜSSEN
die Zeitinformation mehrmals pro Stunde
abrufen können.
Systeme der tertiären Ebene
synchronisieren die Zeitinformation im
Regelbetrieb mindestens einmal täglich.
Die hierarchische Organisation des
Zeitdienstes ist der Funktionalen Annahme
AN-ZD-020 beschrieben.
Abschnitt
5.1.1.16
AN-ZD- N
020
Hierarchie
Der Zeitdienst MUSS hierarchisch
organisiert werden.
2.2.1
Abschnitt
5.1.1.3
AN-ZD- N
030
Verfügbarkeit
der primären
Ebene
Anforderungen an die Verfügbarkeiten der
primären Ebene ergeben sich aus
Betriebsvereinbarungen und werden in
diesem Dokument nicht behandelt.
-
-
AN-ZD- N
040
Verfügbarkeit2
der sekundären
Ebene
Anforderungen an die Verfügbarkeiten der
primären Ebene ergeben sich aus
Betriebsvereinbarungen und werden in
diesem Dokument nicht behandelt.
-
-
AN-ZD- N
050
Verfügbarkeit
der tertiären
Ebene
Sofern der Konnektor den Primärsystemen 2.2.1
einen Zeitdienst anbieten KANN (vgl.: [AFZD-030]), richtet sich die Verfügbarkeit des
Zeitdienstes im Konnektor nach der
Verfügbarkeit des Konnektors selber und
findet in diesem Dokument keine
Betrachtung.
Behandlun
g in Spezifikation
[gemSpec_
Kon]
AN-ZD- N
060
Skalierbarkeit
des Dienstes
Der Zeitdienst ist derart auszugestalten,
dass er skaliert werden kann.
2.2.1
Abschnitt
5.1.1.19
AN-ZD- N
070
Antwortzeiten
Anforderungen an die Antwortzeiten des
Zeitdienstes werden in
Betriebsvereinbarungen behandelt.
-
-
AN-ZD- N
080
Netzwerksicher
heit
Die Zeitdienstserver sind durch geeignete
2.2.1
Maßnahmen vor Zugriffen außerhalb der
NTP-Spezifikation zu schützen.
Dies kann zum einen durch das Abschalten
unnötiger Dienste als auch durch die
Absicherung durch vorgeschaltete Firewalls
realisiert werden. Eine Kombination beider
Varianten ist am sinnvollsten.
Version: 1.3.0
Blattanforderun
g
Seite 13 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Klasse: F (funktional), N (nicht-funktional), S (Sicherheit), L (Leistungsanforderung), I
(informative Anforderungen)
3.4 Annahmen
In der nachfolgenden Tabelle sind die Annahmen an den Zeitdienst beschrieben:
Tabelle 2: Annahmen
Lfd. Nummer
Beschreibung der nicht-funktionalen Annahme
AnN-ZD-010
Betrieb der Zeitserver
Die primären Zeitserver sind durch die gematik zu betreiben bzw. zu
verantworten, da sie die Zeitquelle für die gesamte Telematikinfrastruktur
darstellen.
Der Betrieb von weiteren Zeitservern MUSS nach zweckmäßigen
Gesichtspunkten erfolgen. Zu berücksichtigen sind dabei unter anderem
geringe Paketlaufzeiten, Verfügbarkeiten und Performance der zu
betreibenden Server.
AnN-ZD-020
Wartungsintervalle/Katastrophentest
Wartungsintervalle und Katastrophentests werden im Rahmen von
AnN-ZD-030
Physikalische Sicherheit
Alle NTP-Server MÜSSEN durch organisatorische und physikalische
Schutzmaßnahmen gegen unbefugten (physikalischen) Zugriff durch Dritte
gesichert werden.
Die Maßnahmen sind weiterhin so festzulegen, dass durch lokale
Katastrophenfälle (Flugzeugabsturz, Brand, Überschwemmung) ein
Dienstausfall vermieden werden kann (im Sinne von MUSS).
AnN-ZD-040
System Monitoring
Das Monitoring des Zeitdienstes wird in [gemSysSLM] behandelt.
AnN-ZD-050
Reporting
Das Reporting wird in [gemSysSLM] behandelt.
Version: 1.3.0
Seite 14 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
4 Systemüberblick
4.1 Zweck
Die Architektur von Computersystemen beinhaltet stets einen Zeitgeber, aus dem das
Betriebssystem die aktuelle Systemzeit ableiten kann. Nachteil dieser lokalen Zeitgeber
ist, dass diese Komponenten in der Regel über eine geringe Ganggenauigkeit verfügen
und die Systemzeit von der realen Uhrzeit (oder gar vom Datum) abweichen kann. Bei
einzeln betriebenen Systemen ist dies nicht von Bedeutung, in vernetzten Umgebungen
mit verteilter Datenhaltung und komplexer Kommunikation kann dieses Manko jedoch
fatale Folgen haben: Systeme, die etwa Daten von unterschiedlicher Herkunft vorhalten,
können als Ordnungskriterium die Uhrzeit von Fremdsystemen nicht mehr heranziehen,
wenn diese jeweils unsynchronisierte Systemzeiten verwenden. Im schlimmsten Fall kann
so ein zentrales Protokoll für den Zweck der Auswertung unbrauchbar werden, da die
temporale Ordnung auf asynchronen Systemzeiten basiert. Selbst bei Protokollen, die
durch die einzelnen Systeme selbst vorgehalten werden, ist eine Fehlersuche bei
unterschiedlichen Systemzeiten quasi unmöglich, wenn mehrere Systeme parallel
untersucht werden müssen.
Der zentrale Zeitdienst löst diese Problematik. Verwendung findet das Network Time
Protocol – NTP in der Version 4.
Er dient der Synchronisation von zentralen und dezentralen Systemen innerhalb der
Telematikinfrastruktur und der Primärsystemrechner.
Die Kernfunktion eines NTP-Dienstes beruht auf der Idee, aus vier Zeitinformationen
• Client-Zeit bei Versand der Anforderung,
• Server-Zeit bei Empfang der Anforderung,
• Server-Zeit bei Versand der Antwort und
• Client-Zeit bei Empfang der Antwort
unter Berücksichtigung verschiedener Korrekturmechanismen eine Aussage über die
Differenz zwischen Client-Zeit und Server-Zeit zu treffen und diese zur Korrektur der
Client-Zeit zu verwenden.
Die Nähe der Server-Zeit zu einer geeichten Normal-Zeit (z. B. Atomuhr o. ä.) wird dabei
durch das sog. Stratum ausgedrückt. Der Wert des Stratums ist Null für einen NTPServer, der seine Zeit direkt mit einer geeichten Quelle synchronisiert. Server, die ihre
Zeitinformation direkt von einer Cäsium Atomuhr beziehen, können selbst als Stratum-0Server fungieren. Der hierarchisch eine Stufe tiefer angeordnete Server, der seine
Zeitinformationen vom Stratum 0 Server bezieht bzw. etwa per DCF-77 Funksignal erhält,
bezeichnet sich als Stratum 1 Server.
Mit dieser Lösung kann eine temporale Ordnung hinsichtlich der Nachvollziehbarkeit und
Protokollierung hergestellt werden.
Version: 1.3.0
Seite 15 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Ziel ist es,
• bestmögliche Genauigkeit unter Berücksichtigung von Netzwerk- und
Servereinflüssen zu erlangen4,
• Resistenz gegenüber einer Vielzahl von Fehlern und Attacken zu erlangen.
4.2 Funktionsumfang
Primär dient der Zeitdienst dem Austausch von Zeitinformationen unter Verwendung von
in der [RFC1305] (NTP Version 3) und [Draft_NTPv4] spezifizierten Algorithmen.
Selbstschutzautomatismen zur Behandlung von zu häufig gestellten Anfragen werden
implementiert und sind in [Draft_NTPv4] beschrieben.
Folgende Möglichkeiten werden durch die Verwendung von NTP geschaffen:
• Redundanter Aufbau mehrerer Zeitdienstserver
• Automatische Auswahl des besten Zeitsignals bei Verwendung mehrerer
Zeitserver
• Die Verwendung von Durchschnitts- und Clusteralgorithmen berücksichtigen
den qualitativ besten Zeitserver und erkennen Zeitserver mit fehlerhaften
Zeitinformationen.
• Berechnung der Gewichtung von Zeitversatzinformationen
• Ausgleich von Schwankungen auf Netzwerkprotokollebene.
4.3 Grobstruktur des Dienstes
Das Network Time Protocol ist grundsätzlich streng hierarchisch organisiert. In diesem
Modell gibt es primäre Zeitserver, so genannte Stratum 1 Server (Stratum 0 bezeichnet
die Uhr an sich bzw. direkt damit verbundene Serversysteme).
Stratum 2 Server für die Versorgung der Fachdienste und der zentralen TI-Komponenten
mit Zeitinformationen werden ebenfalls von der gematik zentral bereitgestellt und
verantwortet und als „Stratum 2 zentral“ bezeichnet.
Weitere Stratum 2 Server für die Versorgung der Konnektoren mit Zeitinformationen
werden durch die Telematik-Zugangsprovider bereitgestellt und als „Stratum 2 dezentral“
bezeichnet.
Die Konnektoren wiederum können den
Synchronisation der Systemuhren dienen.
Primärsystemen
als
Zeitquelle
zur
Die nachfolgende Grafik visualisiert das hierarchische Konzept des NTP-Dienstes.
4
Die Genauigkeit von NTP ist mit max. 232 picosekunden definiert, was „auch für die exotischsten
Anwendungen ausreichen sollte“ (Zitat: [Draft_NTPv4], Seite 6, Absatz 3, letzter Satz)
Version: 1.3.0
Seite 16 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Abbildung 1: Hierarchischer Aufbau des Zeitdienstes
Generell besteht die Möglichkeit, dass die Zeitinformationen neben den bekannten ClientServer Modell auch per Broadcast durch die Zeitserver verbreitet werden. Letzteres
verbietet sich aus Gründen der schlecht kalkulierbaren Netzlast.
4.4 Rahmenbedingungen
Die Notwendigkeit zum Einsatz eines Zeitdienstes innerhalb der Telematikinfrastruktur
ergibt sich neben allgemein üblichen betrieblichen Konzepten aus den in Kapitel 2.4
genannten Spezifikationen der gematik.
Die Entscheidung zum Einsatz von NTP ergab sich aus der weltweiten Verbreitung und
Akzeptanz des Protokolls und den ausgezeichneten Möglichkeiten, den Dienst
hochverfügbar und hochgradig skalierbar anbieten zu können.
Die detaillierten Protokollspezifikationen von NTP werden in diesem Dokument nicht
beschrieben. Wir verweisen auf die exakten Definitionen von Protokoll und Algorithmen in
den Dokumenten
• The Network Time Protocol Version 4 Protocol Specifications [Draft_NTPv4]
und
• Network Time Protocol (Version 3): Specification, Implementation and
Analysis [RFC1305].
Version: 1.3.0
Seite 17 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Die gematik schreibt den Einsatz von NTP in der Version 4 vor, auch wenn sich diese
Protokollversion noch im Draft Zustand befindet. Da jedoch selbst die PTB (wie viele
andere Anbieter auch) mittlerweile NTPv4 im Produktiveinsatz betreibt und das Draft
mittelfristig in einer RFC mündet, steht einem Einsatz innerhalb der TI nichts im Wege.
Der Unterschied zwischen der NTPv4- und der NTPv3-Spezifikation sei an dieser Stelle
dennoch einmal besonders hervorgehoben:
„Der einzige signifikante Unterschied zwischen den NTPv4 und den NTPv3 Header
Formaten ist das 4 Oktett lange Reference Identifier Feld, das primär zur Erkennung und
Vermeidung von Synchronisationsschleifen dient“ (vgl. [Draft_NTPv4], Seite 4, letzter
Absatz, Satz 2).
Version: 1.3.0
Seite 18 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
5 Realisierung
In den nachfolgenden Abschnitten werden konkrete Realisierungsmöglichkeiten
aufgezeigt, die auf einer Hardware- oder Betriebssystemplattform durchgeführt werden.
Grundsätzlich sind die gezeigten Maßnahmen auf allen unterstützten Betriebssystem- und
Hardwareplattformen uneingeschränkt möglich, so dass eine Hersteller- und
Anbieterneutralität gewährleistet wird.
5.1 Topologie der Zeitdienste
5.1.1 Grundsätzlicher Aufbau
5.1.1.1
Network Time Protocol v4
Für die Realisierung des Zeitdienstes findet das Network Time Protocol in der Version 4
Verwendung (Referenz: [AnN-ZD-010]).
Die Spezifikation von NTPv4 liegt bislang zwar nur als Draft vor [Draft_NTPv4], die
Begründung zu dieser Entscheidung findet sich unter [ZD-E-010].
Komponenten aus der Telematikinfrastruktur, die trotz moderner Technologie noch nicht
in der Lage sind, NTPv4 zu nutzen, muss die Möglichkeit geboten werden, NTPv3 zu
verwenden.
SNTPv4 [RFC4330] ist eine Untermenge von NTPv4 und darf nur für Konnektoren und
Komponenten der Telematikinfrastruktur verwendet werden, die nicht als Quelle für die
Synchronisation der Systemzeiten anderer Komponenten dienen.
5.1.1.2
Netzwerkprotokoll
Als Netzwerkprotokoll verwenden sowohl NTP als auch SNTP das User Datagram
Protocol (UDP), das wiederum auf dem Internet Protocol aufsetzt. Sowohl als Source- als
auch Destination Port soll ausschließlich Port 123 verwendet werden. Es wird
ausschließlich Unicast eingesetzt, Multicast findet keine Berücksichtigung
(Referenz::[AF-ZD-050]. Die Entscheidung ist in [ZD-E-020] begründet.)
5.1.1.3
Hierarchische Konzeption
Die Zeitserver werden streng hierarchisch in 3 Schichten organisiert.
Stratum 1 Server stellen die oberste Hierarchiestufe dar, die bei Rückgriff auf offizielle
Zeitquellen der Bundesrepublik Deutschland (PTB) abgebildet werden kann und dienen
der gesamten Telematikinfrastruktur als primäre Zeitquelle. Die Stratum 2 Ebene stellt die
mittlere Ebene dar, Stratum 3 die unterste. Stratum 3 Systeme synchronisieren sich
ausschließlich mit Systemen der Stratum 2 Ebene, Systeme dieser Schicht ausschließlich
mit der Stratum 1 Ebene.
(Referenz: [AN-ZD-020])
Version: 1.3.0
Seite 19 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
5.1.1.4
Betriebsarten NTP
Die Zeitserver werden ausschließlich in der Betriebsart Client/Server eingesetzt.
Ausnahme: Stehen Stratum 1 Server nicht zur Verfügung, werden die Stratum 2 Systeme
im Peer Betrieb gefahren, um weiterhin eine konsistente Zeitinformation bieten zu können.
Peer Betrieb bedeutet in diesem Kontext, dass sich die Server der Stratum 2 Ebene
gegenseitig synchronisieren und so für die gesamte Telematikinfrastruktur auch ohne
Stratum 1 Server stets eine konsistente Zeitinformation zur Verfügung stellen können.
(Referenz: [AF-ZD-060])
5.1.1.5
Zeitquellen der Stratum 1 Server
Server der Stratum 1 Ebene nutzen folgende Zeitquellen zur Synchronisation in der
angegebenen Reihenfolge:
• DCF77–Empfänger für den Empfang des offiziellen deutschen Zeitsignals vom
Sender DCF77/Mainflingen,
• Alternativ: Einwahl per Modem in das TDS (Time Distribution System) der
Physikalisch-Technischen Bundesanstalt (PTB) Braunschweig (+49 . (0) 5 31 .
51 20 38)
• Alternativ: GPS Empfänger (ausschließlich für den Notfall, dass DCF77 nicht
zu empfangen ist und das TDS nicht verfügbar ist.)
Mit dieser Maßgabe ist sichergestellt, dass die für die Bundesrepublik Deutschland
geltende gesetzliche Zeit verbreitet wird.
Die Maßgabe, die per GPS (Global Positioning System) ausgestrahlten Zeitinformationen
ausschließlich in dem Fall zu verwenden, wenn DCF77 über einen längeren Zeitraum
nicht mehr zu empfangen ist, ergibt sich aus der Tatsache, dass GPS kein
Verbreitungsmedium für die offizielle gesetzliche Zeit in Deutschland ist.
(Referenz:[AF-ZD-070])
5.1.1.6
Betriebsverantwortung der Zeitserver
Zeitserver der Ebene „Stratum 1“ werden durch die gematik verantwortet, da sie als
primär relevante Zeitquelle für alle zentralen und dezentralen Komponenten der
Telematikinfrastruktur dienen.
Zeitserver der Ebene „Stratum 2 dezentral“ werden durch die Telematik-Zugangsprovider
betrieben und stellen den Zeitdienst für die ihr zugeordnete Region/für den ihr
zugeordneten Sektor zur Verfügung.
Zeitserver der Ebene „Stratum 2 zentral“ werden durch die gematik verantwortet und
stellen den Zeitdienst für Komponenten und Fachanwendungssysteme innerhalb der
Telematikinfrastruktur zur Verfügung.
Version: 1.3.0
Seite 20 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Zeitserver der Ebene „Stratum 3“ sind im Konnektor enthalten und können auch den
Primärsystemen als Zeitquelle zur Verfügung stehen. Die Betriebsverantwortung für den
Konnektor ist nicht Gegenstand dieses Dokumentes.
(Referenz: [AnN-ZD-010])
5.1.1.7
Technische Realisierung der Stratum 1 Ebene
Die Stratum 1 Ebene besteht aus mindestens 4 dedizierten Servern. Virtualisierte
Serversysteme, zum Beispiel mit VMware usw., sind nicht zulässig.
Die Systeme sind in zwei getrennten Rechenzentren zu betreiben. Die räumliche
Trennung dient der Abwehr von Elementarschäden wie etwa Flugzeugabstürzen oder
Hochwasser- und Feuerschäden, die bei Betrieb in einem RZ zu einem Totalausfall des
Dienstes führen könnten. Der Betreiber hat darzulegen, dass die angegebene Entfernung
der RZ zueinander ausreichend ist.
Innerhalb der Rechenzentren
Brandabschnitten zu betreiben.
sind
die
Server
in
je
zwei
unterschiedlichen
Die Systeme eines Rechenzentrums sind jeweils hochverfügbar mit Switches, Firewalls
und Routern aufzubauen und an das Backbone des Telematik-Netzes anzubinden.
Im Zuge der Nutzung mit weiteren zentralen Diensten der Telematikinfrastruktur (etwa
interne DNS Root Server) können die hochverfügbar ausgelegten Komponenten
(Switches, Router und Firewalls) gemeinsam genutzt werden.
(Referenzen: [AF-ZD-080] und [AnN-ZD-030])
5.1.1.8
Verfügbarkeiten der Stratum 1 Ebene
Der Zeitdienst der Ebene „Stratum 1“ hat eine Verfügbarkeit von 99,9% p. a. zu
gewährleisten (=525,6 Minuten = 8,76 Stunden Ausfall pro Jahr). Durch die Konzeption
der Stratum 1 Ebene kann auch der Ausfall von drei Stratum 1 Servern oder der Ausfall
von 3 Anbindungen an das Backbone des Telematik-Netzes nicht zu einem Ausfall der
gesamten Stratum 1 Ebene führen.
Die planmäßigen Wartungsintervalle sind nicht Bestandteil der Verfügbarkeitsberechnung
und sind vertraglich festzulegen.
Verfügbarkeiten der Systeme der Stratum 1 Ebene werden im Rahmen von
(Referenzen: [AN-ZD-030] und [AnN-ZD-020])
5.1.1.9
Realisierung der Ebene Stratum 2 dezentral
Die Systeme der Ebene Stratum 2 dezentral werden in den Rechenzentren der TelematikZugangsprovider aufgebaut und von diesen betrieben.
Die Systeme sind als Mindestvoraussetzung in zwei Plattformhälften, d. h.
Brandabschnitten innerhalb eines Rechenzentrums aufzubauen. Alternativ kann der
Aufbau in zwei voneinander unabhängigen Rechenzentren erfolgen.
Version: 1.3.0
Seite 21 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Die Systeme der Stratum 2 Ebene eines Telematik-Zugangsproviders sind hochverfügbar
mit Switches, Firewalls und Routern aufzubauen.
Im Zuge der Nutzung mit weiteren zentralen Diensten des Telematik-Zugangsproviders
(etwa TI DNS Server) können die hochverfügbar ausgelegten Komponenten (Switche,
Router und Firewalls) gemeinsam genutzt werden.
Je Telematik-Zugangsprovider werden im Testbetrieb mindestens 4 NTP-Server
betrieben. Dies stellt die Mindestanforderung zur Erkennung von Truechimer-, Falsetickerund Falsespeaker-Systemen dar.
Truechimer liefern unter Berücksichtigung von
Driftberechnungen das qualitativ stets beste Zeitsignal.
Paketlaufzeiten,
Offset-
und
Ein Falseticker ist eine Uhr (NTP-Server), die konsistent eine falsche Uhrzeit liefert (z. B.
um 1h verschoben). Bei nur zwei verfügbaren NTP-Servern ist es einem Client nicht
möglich, zu identifizieren, welcher Server eine falsche Uhrzeit liefert. Um robust
gegenüber diesem Fehler zu sein, werden mindestens 3 Stratum 2 Server benötigt.
Der Falsespeaker ist eine Uhr (NTP-Server), die nicht nur eine falsche Zeit liefert, sondern
auch jedem anfragenden System eine andere falsche Zeit liefert („byzantinischer Fehler“).
Um robust gegenüber „Falsespeakern“ zu sein, sind mindestens 3n+1 Zeitserver
notwendig, wobei n die Anzahl der Uhren (NTP-Server) mit diesem Fehlertyp ist, die
erkannt werden sollen. Es wird gefordert, dass genau ein „Falsespeaker“ erkannt werden
muss, wodurch mindestens 4 Stratum 2 Zeitserver benötigt werden.
Im Wirkbetrieb wird die Zahl der NTP-Server auf mindestens 3 je Plattformhälfte erhöht,
um nach dem Ausfall einer Plattformhälfte immerhin noch die Erkennung eines Falseticker
zu gewährleisten. Eine Erkennung von byzantinischen Fehlern (Falsespeakern) ist für
diesen (temporären) Fall nicht erforderlich. Siehe Abschnitt 7.7.3.1 („Zeitsynchronisation“)
in [gemSiKo].
Überregional operierende Telematik-Zugangsprovider sollen je Bundesland mindestens
zwei NTP-Server vorhalten, die Anzahl aller Systeme darf 4 nicht unterschreiten. Die
Festlegung „je Bundesland“ erfolgt aufgrund der Überlegung, die Paketlaufzeiten der
NTP-Datenpakete so gering wie möglich zu halten.
(Referenzen: [AF-ZD-090] und [AF-ZD-100])
5.1.1.10 Realisierung der Ebene Stratum 2 zentral
Damit Anbieter von zentralen Diensten und/oder Fachanwendungen (auch die Netzwerkund Backbonebetreiber) innerhalb der Telematikinfrastruktur nicht jeweils eigene Stratum
2 Server aufsetzen müssen, betreibt bzw. verantwortet die gematik den Betrieb von
insgesamt mindestens acht Stratum 2 Servern. Diese Systeme dienen außerdem der
Zeitsynchronisation von Infrastrukturkomponenten wie Routern oder Firewalls.
Betreiber von zentralen Diensten (etwa DNS) und/oder Fachanwendungen (wie etwa
VODD, VSDD, Broker etc.) sowie Betreiber von zentralen Infrastrukturdiensten und
Komponenten (Router, Firewalls etc.) MÜSSEN ihre Komponenten und Systeme mit den
zentralen Stratum 2 Servern der Telematikinfrastruktur synchronisieren.
Dazu synchronisieren sich die Systeme und Komponenten direkt mit den zentralen
Stratum 2 Servern oder die Anbieter verwenden zusätzliche (eigene) NTP-Server, die als
Version: 1.3.0
Seite 22 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Zeitquelle die zentralen Stratum 2 Server der Telematikinfrastruktur nutzen und das
Zeitsignal per NTP (als Stratum 3 Server) in die eigens betriebene Infrastruktur verteilen.
Von dieser Anforderung ausgenommen sind Anbieter/Betreiber von PKI-Dienstleistungen,
da diese bereits die hohen Anforderungen aus [SigG] und [SigV] umsetzen, welche mit
denen aus diesem Dokument zumindest gleichwertig sind.
Ebenso von dieser Anforderung ausgenommen sind Anbieter/Betreiber des MPLSBackbones mit den dazugehörenden Komponenten. Hier kann der Anbieter/Betreiber auf
eigene Zeitsynchronisationsquellen zurückgreifen, sofern dargelegt werden kann, dass
die Anforderungen aus diesem Dokument ansonsten erfüllt werden.
Anbietern/Betreibern von Komponenten und Fachanwendungen, die außerhalb der
Systemgrenzen der Telematikinfrastruktur liegen, wird an der Schnittstelle der
Systemgrenze das NTP der zentralen Stratum 2 Server zur Verfügung gestellt. Es wird
dringend empfohlen, dieses Angebot zur Herstellung einer einheitlichen temporalen
Ordnung zumindest für die Frontendsysteme zu nutzen.
Je mindestens vier Zeitserver-Systeme sind in zwei getrennten Rechenzentren zu
betreiben. Die räumliche Trennung dient der Abwehr von Elementarschäden wie etwa
Flugzeugabstürzen oder Hochwasser- und Feuerschäden, die bei Betrieb in einem RZ zu
einem Totalausfall des Dienstes führen könnten. Der Betreiber hat darzulegen, dass die
angegebene Entfernung der RZ zueinander ausreichend ist.
Innerhalb eines jeden Rechenzentrums werden die Server in zwei voneinander
unabhängigen Brandabschnitten aufgestellt, also je Rechenzentrum und je
Brandabschnitt mindestens 2 bzw. im Wirkbetrieb mindestens 3 Serversysteme.
Die Systeme eines Rechenzentrums werden hochverfügbar mit Switches, Firewalls und
Routern an das Backbone des Telematik-Netzes angebunden. Im Zuge der Nutzung mit
weiteren zentralen Diensten der Telematikinfrastruktur können die genannten
Komponenten gemeinsam genutzt werden.
Hinsichtlich der Fehlerresistenz gelten die in 5.1.1.9 beschriebenen Lösungen.
5.1.1.11 Zeitquelle der Stratum 2 Ebene
Als Zeitquelle der Stratum 2 Server dienen die zentralen Stratum 1 Server (Siehe 5.1.1.8).
5.1.1.12 Verfügbarkeit der Stratum 2 Ebene (zentral und dezentral)
Die Telematik-Zugangsprovider, die Regional-/Sektoralnetzbetreiber und die gematik (für
Stratum 2 zentral) haben eine Verfügbarkeit von 99,7% pro Jahr für den Zeitdienst
innerhalb seiner Verantwortung zu gewährleisten. Dies entspricht einer NichtVerfügbarkeit von 26½ Stunden pro Jahr für den gesamten Dienst des jeweiligen
Anbieters.
Die planmäßigen Wartungsintervalle sind nicht Bestandteil der Verfügbarkeitsberechnung
und sind vertraglich festzulegen.
Verfügbarkeiten der Systeme der Stratum 1 Ebene werden im Rahmen von
Version: 1.3.0
Seite 23 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
5.1.1.13 Technische Konzeption der Stratum 3 Ebene
Konnektoren repräsentieren die Zeitserver der Stratum 3 Ebene. Konnektoren sind im
Bereich der Leistungserbringer aufgebaut und stellen die Systemgrenze der
Telematikinfrastruktur dar. Zum einen nutzen sie die von den Stratum 2 Servern der
Telematik-Zugangsprovider bezogene Zeitinformation zur Eigensynchronisation und somit
auch zur zeitgenauen Protokollierung von Ereignissen, zum anderen können sie den
Primärsystemen als Zeitsynchronisationsquelle dienen.
5.1.1.14 Verfügbarkeit der Stratum 3 Ebene
Die Verfügbarkeit des Zeitdienstes der Stratum 3 Ebene (NTP-Server im Konnektor)
richtet sich nach der Verfügbarkeit des Konnektors und findet an dieser Stelle keine
weitere Betrachtung.
5.1.1.15 Abwehrmechanismen gegen NTP-DoS/NTP-DDoS
Zur Abwehr von nicht böswilligen NTP basierten Denial-of-Service bzw. DistributedDenial-o´-Service Angriffen bedient sich NTPv4 des so genannten Kiss-o’-Death
Verfahrens. Mit Hilfe dieses Verfahrens kann der NTP-Server die Anzahl der an ihn
gerichteten Anfragen von korrekt implementierten und hierarchisch untergeordneten NTPServern beeinflussen.
Dazu versendet der NTP-Server als Antwort das entsprechende „Kiss-o’-Death“ Paket.
Dieses „Antwort - Paket“ enthält im Header folgende Informationen:
• Stratum-Feld = 0
• Reference-Identifier Feld = String der Länge 4 Zeichen, bei Überlast (zu viele
parallele Anfragen) gefüllt mit dem Wert RATE.
Die exakte Beschreibung zu Kiss-o’-Death findet sich in [Draft_NTPv4] auf Seite 35.
Dieses Verfahren ist nicht geeignet, anderweitige DoS/DDoS Angriffe abzuwehren, für
diese Szenarien MUSS das Telematiknetz entsprechende Schutzmechanismen zur
Verfügung stellen.
5.1.1.16 Synchronisationsintervalle
Systeme der Stratum 1 Ebene synchronisieren ihre Systemzeit permanent mit den in
5.1.1.5 genannten Zeitquellen.
Systeme der Stratum 2 und Stratum 3 Ebene beziehen ihre Zeitinformation über das Netz
der Telematikinfrastruktur. Für diesen Fall sieht das Network Time Protocol die
Möglichkeit vor, die Synchronisationsintervalle zu reglementieren. Die Angabe der
Version: 1.3.0
Seite 24 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Intervalle wird dabei in Form einer Zweierpotenz angegeben und entspricht dem
Synchronisationsintervall in Sekunden.
Weiterhin
besteht
die
Möglichkeit,
Synchronisationsintervall vorzugeben.
ein
minimales
und
ein
maximales
In der nachfolgenden Tabelle sind die entsprechenden Zweierpotenzen und deren
Entsprechung in Zeiteinheiten angegeben:
Tabelle 3: Pollingintervalle für NTP-Serverkonfigurationen
2^
Sekunden
Minuten
Stunden
Bemerkungen
2
4
unrealistisch, zu hohe Netzlast
3
8
4
16
5
32
6
64
7
1,0 6
Intervall noch zu kurz, zu hohe
Netzlast
128
2,13
Optimal für Stratum 2 Server als
minimale Polling Intervalle
8
256
4,26
Geeignet im Stratum 2 Bereich
9
512
8,53
10
1024
17,06
11
2048
34,13
Optimal für Stratum 2 Server als
maximale Polling Intervalle
12
4096
68, 26
1,137
13
8192
136,53
2,275
14
16384
273,06
4,551
Minimale Polling Intervalle für
Stratum 3 Server
15
32768
546,13
9,102
Geeignet für Stratum 3 Server
16
65536
1092, 26
18,204
Geeignet für Stratum 3 Server
17
131072
2184,53
36, 408
Maximale Polling Intervalle für
Stratum 3 Server
_
Für Stratum 2 Server wird entsprechend folgende Konfiguration innerhalb der
Konfigurationsdatei ntp.conf vorgesehen:
Version: 1.3.0
Seite 25 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
server
server
server
server
10.20.30.10
10.20.30.11
10.21.10.20
10.21.10.21
minpoll
minpoll
minpoll
minpoll
7
7
7
7
maxpoll
maxpoll
maxpoll
maxpoll
11
11
11
11
Für Stratum 3 Systeme wird entsprechend folgende Konfiguration innerhalb der
Konfigurationsdatei ntp.conf vorgesehen, die einen Synchronisationsrhythmus von
mindestens einer Synchronisation pro Tag im Regelbetrieb ermöglicht.
server
server
server
server
10.40.30.100
10.40.30.101
10.41.10.200
10.41.10.201
minpoll
minpoll
minpoll
minpoll
14
14
14
14
maxpoll
maxpoll
maxpoll
maxpoll
17
17
17
17
Hinweis: Die Angabe der IP-Adressen 10.20.30.10 usw. sind lediglich Beispielangaben
und entsprechen keinesfalls der Realität!
Vorgaben für die Betreiber von zentralen Diensten und/oder Fachanwendungen oder den
Anbietern/Betreibern von zentralen Infrastrukturdiensten und Komponenten (siehe
5.1.1.10) hinsichtlich der Synchronisationsintervalle werden nicht definiert.
Vielmehr DÜRFEN die Betreiber NICHT die Angabe von MINPOLL und MAXPOLL
Parametern verwenden. In diesem Fall ermittelt NTP die entsprechenden Werte anhand
des Network Jitter und der Taktfrequenzabweichung des Hostsystems automatisch
[CNTS, S. 85] und stellt somit jederzeit eine synchronisierte Systemzeit sicher.
Mit der bei einer permanenten Synchronisation zu erzielenden Genauigkeit, die im
Bereich von etwa 3x10-3 bis 3x10-5 Sekunden erwartet wird (Erfahrungswerte), wird eine
mehr als ausreichend genaue Basis für Replay Detection Mechanismen und
Zertifikatsprüfungen geschaffen.
Hinweise zur Erstsynchronisation
Da bei entsprechender Konfiguration die Erstsynchronisation (bei Erstinbetriebnahme
bzw. nach Wartungsarbeiten) der NTP-Server sehr lange dauern kann – mehrere Stunden
sind nicht selten – empfiehlt es sich, nach manueller Einstellung der Systemzeit etwa über
das BIOS/NVRAM o. ä. bzw. über entsprechende Betriebssystemtools mit Hilfe des im
NTP-Paket enthaltenen Tools ntpdate die Systemzeit erstmalig manuell mit dem
übergeordneten Zeitserver zu synchronisieren und so die Systemzeitänderung zu
erzwingen. Dazu sollte der ntpd (Network Time Protocol Daemon) heruntergefahren sein.
Das entsprechende Kommando dazu lautet
ntpdate –b <IP-Adresse>
Hinweis: Das genannte Kommando sollte nur unmittelbar nach dem Systemstart mit
weitestgehend heruntergefahrenen Diensten abgesetzt werden, da die Systemzeit unter
Umständen auch auf einen vorherigen Wert zurückgestellt werden kann, was bei einer
längeren Uptime der Systeme zu durchaus unkalkulierbaren Folgen führen kann.
Version: 1.3.0
Seite 26 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Zur Umgehung der genannten Probleme kann das ntpdate Kommando auch in das
entsprechende Startup Script eingebunden werden.
Ist dies nicht möglich, sollte der ntpd regulär gestartet werden. Je nach Abweichung von
der realen Zeit wird die Systemuhr so lange „beschleunigt“ beziehungsweise
„abgebremst“, bis die Differenz nahe null geht. Während dieser Zeit wird das „Leap
Indicator“ Feld im NTP-Paketheader auf „11“ binär (entspr. 3 dezimal) gesetzt. Dies
entspricht der so genannten „Alarm condition – clock not synchronized“, und der Server
wird bei Synchronisationsanfragen von untergeordneten Servern nicht berücksichtigt. Ist
die Uhr synchronisiert, wird sie wieder auf normale Ganggeschwindigkeit gesetzt, das
Leap Indicator Feld erhält den Status 0 und der Server wird wieder bei der
Synchronisation von untergeordneten NTP-Servern berücksichtigt.
5.1.1.17 Kurzzeitgenauigkeit der Stratum 1 Server
Die Kurzzeitgenauigkeit von Stratum 1 Servern darf 1ms nicht überschreiten.
5.1.1.18 Freilaufgenauigkeit der Zeitserver
Die Freilaufgenauigkeit der Stratum 1 Zeitserver muss mindestens ±1ppm (~32s in 365
Tagen) betragen.
Die Freilaufgenauigkeit der Stratum 2 Zeitserver muss mindestens ±100 ppm (52,6
Minuten in 365 Tagen) betragen.
5.1.1.19 Skalierbarkeit des Dienstes
Der Zeitdienst auf Basis von NTPv4 ist beliebig skalierbar.
Wird zukünftig festgestellt, dass bestehende Systemkomponenten des Zeitdienstes
überlastet sind (Load auf Netzwerkinterfaces und/oder CPU(s) an mehr als 8 Stunden pro
Tag größer 80% oder zu Spitzenzeiten > 90%), so kann der Zeitdienst durch Hinzufügen
und Einbinden zusätzlicher NTP-Server bzw. durch Austausch gegen leistungsfähigere
Serversysteme beliebig skaliert werden.
(Ref. Funktionale Annahmen: [AN-ZD-060])
5.1.1.20 Berücksichtigung von Zeitzonen
Das Network Time Protocol verwendet zur Übermittlung von Zeitinformationen
ausschließlich die UTC (Coordinated Universal Time) Zeit.
Die (server- und clientseitige) Darstellung der Uhrzeit inklusive Berücksichtigung der
Zeitzonen und regionalen Besonderheiten (Sommerzeit = Daylight Saving Times) wird
betriebssystemseitig geregelt.
Version: 1.3.0
Seite 27 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
5.1.1.21 Berücksichtigung von Laufzeitvarianzen
Das Network Time Protocol ist seit seiner ersten Version durch die Berücksichtigung von
vier jeweils übertragenen Zeitinformationen und der Verwendung verschiedener
Korrekturmechanismen in der Lage, netzwerkbedingte Laufzeitvarianzen zu erkennen und
entsprechend zu berücksichtigen (vgl. Kapitel 4.1).
(Ref. Funktionale Annahmen: [AF-ZD-160])
5.1.2 Aufbau und Funktionsweise des Zeitdienstes
MPLS Backbone
In der nachfolgenden Grafik ist der grundsätzliche Aufbau des Zeitdienstes dargestellt.
Abbildung 2: Topologie der Zeitdienste
In der linken Bildhälfte sind die zentralen NTP-Server der Stratum 1 und Stratum 2 Ebene
zu erkennen.
Die Stratum 1 Server beziehen ihre Zeitinformationen über das DCF-77 Funksignal und
alternativ über GPS oder TDS-System. Sie dienen ausschließlich als primäre
Synchronisationsquelle für die in der Hierarchieebene untergeordneten Stratum 2 Server.
Die Systeme der Ebene „NTP Stratum 2 zentral“ dienen als Synchronisationsquelle für
zentrale Komponenten und Fachanwendungssysteme der Telematikinfrastruktur. So wird
vermieden, dass jeder Fachdienstbetreiber gezwungen wird, eigene Stratum 2 Server zu
Version: 1.3.0
Seite 28 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
implementieren und diese zu betreiben und stellt somit eine ökonomisch sinnvolle
Zusammenlegung von zentralen TI-Diensten dar.
Die Systeme sind jeweils hochverfügbar mit Switches, Firewalls und Routern an das
Backbone des Telematik-Netzes anzubinden, wobei diese Komponenten für den Einsatz
weiterer Dienste wie etwa DNS genutzt werden können. Davon ausgeschlossen sind
jedoch jegliche Fachanwendungen.
Weitere Stratum 2 Server („Stratum 2 dezentral“) werden durch die TelematikZugangsprovider implementiert (Bildmitte), um die Konnektoren der Leistungserbringer
synchronisieren zu können.
Konnektoren stellen die Stratum 3 Ebene dar (im Bild rechts). Sie sind räumlich den
Leistungserbringern zugeordnet und stellen die Systemgrenze der Telematikinfrastruktur
dar. Sie beziehen ihre Zeitinformationen ausschließlich von den Stratum 2 Servern der
Telematik-Zugangsprovider.
Die nachfolgende Grafik veranschaulicht die Funktionsweise des Zeitdienstes bei der
Kommunikation zweier NTP-Server:
Version: 1.3.0
Seite 29 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Stratum n+1
Stratum n (max. 4 Server)
ntpd start
Lokale
Systemuhr
ntpd
ntpd
Auslesen
Konfiguration
(ntp.conf)
Anfrage an
Stratum n
Server
übergibt u.a.: LI=unsync. clock,
unidentified Reference clock,
transmit timestamp.
Verarbeitet
Antwort
geht
vor
Systemuhr
beschleunigen
geht
nach
Systemuhr:
beschleunigen
bis Normal
Systemuhr:
verlangsamen
bis Normal
Lokale
Uhr
verlangsamt
beschleunigt
Sendet
Antwort
korrekt
Zustand
lokale Uhr
Geschwindigkeit
normal
Systemuhr
verlangsamen
übergibt u.a.: eigene Reference clock,
eigenen Stratum, eigene Präzision,
Originate, transmit u. receive timsetamp
Verarbeitet
Anfrage
Setzt
Parameter*
Bereit für
Anfragen
Warten auf
nächsten
Poll
Initiiert
nächsten
Poll
*= unter anderem:
Leap Indicator = 00(bin) = „Syncronized clock“,
Stratum = n+1
Reference clock = Stratum n Server
Clock precision = Präzision der eigenen Uhr
Abbildung 3: Funktionsweise des Zeitdienstes
Version: 1.3.0
Seite 30 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
5.1.3 Administration des Zeitdienstes
Die Systeme der Ebene Stratum 1 und Stratum 2 zentral werden von der gematik
verantwortet und zentral betrieben beziehungsweise administriert. Administrationspunkte
könnten hier die Switche sein, mit denen die Zeitserver physikalisch verbunden sind. Die
Administration muss über ein von der TI separiertes Administrationsnetz erfolgen.
Die Systeme der Stratum 2 Ebene (dezentral) werden durch die TelematikZugangsprovider betrieben und administriert. Administrationspunkte könnten hier die
Switches sein, mit denen die Zeitserver physikalisch verbunden sind. Die Administration
muss über ein von der TI separiertes Administrationsnetz erfolgen.
5.1.4 Funktionen und Redundanz
5.1.4.1
Dienstnutzung
Die Funktionen sind bereits eingehend in den vorhergehenden Kapiteln beschrieben. An
dieser Stelle finden Betrachtungen zu Ausfallszenarien und deren Auswirkungen statt.
Generell müssen zwei unterschiedliche Störfallszenarien betrachtet werden:
• Ausfall von Zeitservern und/oder deren Netzanbindung sowie
• Ausfall der Zeitquellen beziehungsweise der Synchronisationsmedien, über
die die Zeitserver die Uhrzeit synchronisieren.
Das Ergebnis ist in allen Fällen das Gleiche: Eine unsynchronisierte Uhrzeit ist die Folge.
Dennoch findet eine kurze Betrachtung der Auswirkungen statt.
Tabelle 4: Ausfallszenarien
Szenario
Konsequenzen
Erläuterung
Ausfall von max. 3 von 4
Stratum 1 Servern
Keine
Die Stratum 2 Server
synchronisieren mit dem noch
vorhandenen einen Stratum 1
Server.
Ausfall aller Stratum 1
Server/aller Netzanbindungen
der Stratum 1 Server
Stratum 2 Server können nicht
mehr synchronisieren, schalten
um auf lokale Uhrzeit und
synchronisieren sich auf peer
Stratum 2 Ebene, bieten
weiterhin NTP an (Empfohlen)
Ausfall aller Zeitquellen der
Stratum 1 Server
Siehe nachfolgende Grafik
unterhalb dieser Tabelle
Ausfall/Nicht-Verfügbarkeit
einzelner Stratum 2 Server bei
verschiedenen TelematikZugangsprovidern und/oder in
Keine, so lange mindestens ein
Server verfügbar ist.
Version: 1.3.0
Da in jedem
Zugangsprovidernetz
mindestens vier Stratum 2
Server vorhanden sein
Seite 31 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Szenario
Konsequenzen
dem von der gematik
verantworteten Segment.
Ausfall/Nicht Erreichbarkeit
jeglicher Stratum 2 Server bei
einem TelematikZugangsprovider
Erläuterung
müssen, ist der Ausfall
einzelner Systeme ohne
Relevanz.
Innerhalb der
Synchronisationszeiträume von
Konnektoren: Keine.
Ansonsten abhängig von den in
der Konnektorspezifikation
getroffenen Festlegungen
Abbildung 4: Szenario "Ausfall aller Stratum 1 Server"
5.2 Skalierung
Die Skalierung des Dienstes wird im Wesentlichen durch Hardwarekomponenten
realisiert.
Basis der geplanten Komponenten sind Aussagen von deutschen Stratum 1
Serverbetreibern (PTB), deren drei Serversysteme bis zu 6 Millionen Anfragen in 24
Stunden beantworten können.
Sollten sich dennoch Engpässe in den Systemen zeigen, können diese durch den Aufbau
weiterer Servergruppen beseitigt werden. Auf Stratum 1 und Stratum 2 Ebene werden
Version: 1.3.0
Seite 32 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
dazu entsprechende Maschinen hinzugefügt bzw. existente Maschinen im Rahmen der
Wartungsfenster durch leistungsfähigere ersetzt.
Neben dem Hinzufügen MUSS durch Anpassen der Konfiguration der entsprechend
höheren Hierarchiestufe eine Lastverteilung vorgenommen werden. Ohnehin kann ein
NTP-Server/Client maximal 9 Server parallel abfragen, eine größere Anzahl ist nicht
möglich.
Sinnvoll ist die Konfiguration von jeweils mindestens 4 Servern, die abgefragt werden,
damit auch Truechimer, Falseticker und Falsespeaker erkannt werden können.
5.2.1 Lastannahmen
Es wurden 3 Lastberechnungen mit gemittelten Lastanforderungen durchgeführt. Dabei
wurden jeweils unterschiedliche Synchronisationsintervalle sowohl im Stratum 2 als auch
im Stratum 3 zu Grunde gelegt.
Tabelle 5: Lastannahmen - Minimalanforderungen
Minimalanforderungen
Anzahl Stratum 1 Server gematik
4
8
Anzahl Zugangsnetze
10
Anzahl Stratum 2 Server je Zugangsnetz
4
Anzahl Stratum 2 Server gesamt
48
Stratum 2 Server je Stratum 1 Server
12
Sync-Zeitraum je Stratum 2 Server
dies entspricht Synchronisationen pro Stunde
Anzahl Stratum 3 Server (Konnektoren)
Stratum 3 Server je Stratum 2 Server*
60 min
1
300000
7500
13,7 h
0,072993
Syncs je Stratum 1 Server pro Stunde
12
547,4
*= ohne Strat. 2 Server der gematik, da
diese ausschließlich für Fachdienstserver
und TI Komponenten verfügbar sind
Version: 1.3.0
Seite 33 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Tabelle 6: Lastannahmen – Mittlere Anforderungen
Mittlere Anforderungen
4
8
Anzahl Zugangsnetze
10
4
48
12
30 min
2
300000
7500
9,1 h
0,10989
24
824,2
Version: 1.3.0
Seite 34 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Tabelle 7: Lastannahmen - Maximale Anforderungen
Maximale Anforderungen
4
8
Anzahl Zugangsnetze
10
4
48
12
2 min
30
300000
7500
4,5
0,222222
360
1666,7
Mit diesen Anforderungen ist ein sicherer Betrieb ohne Einschränkungen selbst bei
maximaler Last möglich. (Tests haben gezeigt, dass z. B. der Meinberg LANTIME/GPS
NTP-Server bis zu 6.000 Requests pro Sekunde verarbeiten kann.)
Sollte die Last dennoch größere Anforderungen an die Systeme stellen, so kann durch
Hinzufügen weiterer NTP-Server und Anpassung der Konfiguration an der
untergeordneten Hierarchieebene ausgezeichnet skaliert werden.
Version: 1.3.0
Seite 35 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
6 Erweiterte Funktionen und Betrieb
6.1 Telematikinfrastruktur-Betrieb der NTP-Server
Die technischen Anforderungen an den Betrieb des Zeitdienstes ergeben sich aus den
technischen und organisatorischen Anforderungen dieses Dokumentes.
Der Betrieb von Stratum 1 und Stratum 2 Servern erfordert eine genau definierte und
personalisierte Kommunikations- und Eskalationsstruktur für den Regelbetrieb.
Diese Regelungen und insbesondere auch die KPI (Key Performance Indikatoren) können
nicht Bestandteil dieses technisch orientierten Dokumentes sein und finden sich in
Betriebskonzepten und einzelvertraglichen Vereinbarungen wieder.
Die Methodik der Bereitstellung der KPI ist in dem Dokument [gemSysSLM] dargestellt.
In einem iterativen Prozess gemeinsam mit der gematik werden Anforderungen an die
Betriebsführung des Zeitdienstes in das Gesamtbetriebskonzept einfließen und von dort
zu einem späteren Zeitpunkt final in diesem Dokument technisch umgesetzt werden.
Version: 1.3.0
Seite 36 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Anhang A – Beispiel Kompilierung von NTP
Die an dieser Stelle aufgezeigten Beispiele sollen verdeutlichen, welche Schritte
notwendig sind, um NTP nach dem Herunterladen des Sourcecode Tarballs so zu
übersetzen, dass er den Anforderungen für den Einsatz in der Telematikinfrastruktur
gerecht wird. Dies betrifft insbesondere die beispielhafte Einbindung eines dedizierten
DCF77 Empfängers und die Verwendung von Statistiken zur Auswertung für den
Betreiber und der gematik.
Die Beispiele sind ausgeführt worden auf den Betriebssystemen
• SuSE Linux Enterprise Server 9
• SuSE Linux Professional 9.2 und 10.1 sowie
• Fedora Core 5 und 6 sowie CentOS 5
Sinngemäß lassen sie sich jedoch
Hardwareplattformen 1:1 umsetzen.
auch auf
anderen
Betriebssystemen und
A1 – Empfehlungen zu den zu verwendenden Versionen von ntp
(Stand: 05.09.2007)
Bislang wurde in diesem Dokument stets die Version ntp-4.2.2p4 als Ausgangsversion
behandelt.
Bei gematik internen Tests wurde festgestellt, dass diese Version trotz der ./configure
– Option --enable-timing-stats keine Timingstatistiken generiert und somit nicht
vollständig für den Einsatz in der Telematikinfrastruktur geeignet ist.
Dieser Fehler wurde mit der Stable-Release ntp-4.2.4p0 behoben.
Werden die Stable-Releases ntp-4.2.4p0 bis ntp-4.2.4p2 in Zusammenhang mit dem
Betriebssystem Linux in den Kernelversionen kleiner 2.6.19 betrieben, so treten
sporadisch „kernel time sync error 0001“ auf. Mit der Umstellung von ntp-4.2.3 auf
ntp-4.2.4 haben die ntp-Entwickler die time sync error message Routinen modifiziert, um
sinnvollere Fehlerbeschreibungen loggen zu können und vor allem vollständig POSIX
konform zu werden. Seit dieser Modifikation trat der kernel time sync error 0001 auf.
Zeitgleich hat die Linux Community Änderungen am Kernelsource vorgenommen:
Die ursprünglich in den (Source) Dateien /kernel/timer.c und /kernel/time.c enthaltenen
Funktionen zur ntp Synchronisation des Kernels [ntp_adjtime() und ntp_gettime()] sind
nun in die Datei /kernel/time/ntp.c gewandert. Diese Codebereinigung ist offensichtlich
misslungen: Was bei den älteren NTP-Versionen nie aufgefallen ist, führte nun zum
Problem. Seit dem Linux Kernel 2.6.19 und der gleichzeitigen Vorstellung der NTP StableRelease 4.2.4p3 ff. ist der Bug behoben.
Daher wird bei Verwendung von Linux-Systemen der Einsatz der Version ntp-4.2.4p3
unter einem Kernel 2.6.19 oder neuer dringend empfohlen. Bei anderen Betriebsystemen
Version: 1.3.0
Seite 37 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
sollen die Versionen ntp-4.2.4p0 oder
Timingstatistiken generieren zu können.
neuer
eingesetzt
werden,
um
auch
A2 – Vorbereitungen zur Übersetzung des ntp tarballs
Der entsprechende Tarball ist auf dem Zielsystem bereitzustellen.
A3 – Entfernen alter NTP-Installationen
Es SOLL sichergestellt werden, dass sich keinerlei alte NTP-Installationen mehr auf den
Systemen befinden.
A4 – Kompilierung von NTP
Schritt 1: Entfernen alter Sourcen
Alte Sourcecode-Verzeichnisse sollten vom Zielsystem entfernt werden, da sie nicht mehr
benötigt werden. Es ist davon auszugehen, dass der Betreiber die Kompilierung und den
Betrieb des neuen Tarballs vorher eingehend auf einer identischen Zielplattform getestet
hat!
Schritt 2: Entpacken des tarballs
Der bereitgestellte tarball ist auf dem Zielsystem zu entpacken. Es entsteht ein
Unterverzeichnis, etwa ntp-4.2.4-p3, in das gewechselt werden muss.
Schritt 3: Konfiguration und Vorbereitungen
Die Konfiguration (das Erzeugen des Makefiles) für die Kompilierung der Sourcen auf der
Zielplattform erfolgt mit Hilfe des enthaltenen configure – Scripts. Der Aufruf erfolgt mit
dem Kommando:
./configure –-enable-RAWDCF –-enable-step-slew 8
–-enable-ntpdate-step –enable-LOCAL-CLOCK 8
–enable-timing-stats –-enable-MEINBERG >> ../ntp-configure.out
Das Kommando configure bereitet die Kompilierung des Sourcecodes anhand der
übergebenen Optionen vor und überprüft gleichzeitig, ob die für die Übersetzung
notwendigen Bibliotheken auf dem System installiert sind. Die Optionen bedeuten im
Einzelnen:
• –-enable-RAWDCF: Unterstützung
STRATUM 1 Server)
des
DCF77
Rohsignals
(wichtig
für
• --enable-step-slew: Ermöglicht es dem ntpd, die Geschwindigkeit der
Systemuhr moderat zu reduzieren und somit eine vorgehende Uhr an die
korrekte Uhrzeit anzupassen.
• –-enable-ntpdate-step: Ermöglicht es auch dem Kommando ntpdate, die
Geschwindigkeit der Systemuhr moderat zu reduzieren und somit eine
vorgehende Uhr an die korrekte Uhrzeit anzupassen.
Version: 1.3.0
Seite 38 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
• --enable-LOCAL-CLOCK: Ermöglicht es, dass auch der lokale Systemzeitgeber
als Referenzuhr herangezogen wird.
• –-enable-MEINBERG: Ermöglicht den Einsatz von DCF77 Empfängern des
Herstellers Meinberg (wichtig für Stratum 1 Server; im Gegensatz zu vielen
anderen – vorwiegend amerikanischen GPS-Empfängern werden die
Meinberg Boxen durch das configure Kommando standardmäßig nicht
berücksichtigt.
• --enable-timing-stats: Ermöglicht das Schreiben von Timing-Statistiken, die
Auskunft über die Prozess-Verarbeitungszeiten von ntpd erteilen.
• >> ../ntp-configure.out: Sämtliche Ausgaben von configure werden von
STDOUT umgeleitet in die Datei ../ntp-configure.out. Dies dient der besseren
Nachvollziehbarkeit, ob alle gewünschten Optionen berücksichtigt worden
sind. Lediglich schwerwiegende Fehler (ERROR:), die zu einem Abbruch von
configure führen, werden noch über STDOUT ausgegeben.
Je nach verwendetem DCF-77 oder GPS Empfänger kann es notwendig sein, dem
configure Kommando weitere Parameter zu übergeben.
A2 –Kompilierung
Der Start des eigentlichen Compilerlaufs erfolgt mit dem Kommando
make >> ../ntp-make.out
ruft den Compiler (gcc) auf und kompiliert die Sourcen anhand der mit configure
generierten Vorgaben und Prüfungen. Wie auch bei configure werden sämtliche
Ausgaben von make von STDOUT umgeleitet in die Datei ../ntp-make.out.
make
Installation
Die Installation der durch den Compiler erzeugten Binaries in das Verzeichnis
/usr/local/bin/ erfolgt mit dem Befehl
make install >> ../ntp-make-install.out
A3 – Betriebssystemabhängige Pakete / Binärdistributionen
Für eine Vielzahl von Betriebssystemen lassen sich bereits fertig kompilierte NTPVersionen beziehen, so etwa beispielsweise für Microsoft® Windows™, SUN Solaris oder
verschiedene Linux Distributionen. Leider sind die vorkompilierten Pakete meist nicht für
den Einsatz in der Telematikinfrastruktur geeignet, da während der Konfiguration der
Pakete die configure – Option --enable-timing-stats nicht berücksichtigt worden ist.
Es bleibt den Betreibern jedoch überlassen, zur Softwareverteilung eigene Pakete zu
erstellen.
Version: 1.3.0
Seite 39 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Anhang B
B1 - Abkürzungen
Kürzel
Erläuterung
DDoS
Distributed Denial of Service
DNS
Domain Name Service
DoS
Denial of Service
FAQ
Frequently Asked Questions – Häufig gestellte Fragen
GPS
Global Positioning System
IP
Internet Protocol
KPI
Key Performance Indikatoren
MPLS
Multi Protocol Label Switching
NAT
Network Address Translation
NTP
Network Time Protocol
PKI
Public Key Infrastructure
ppm
engl.: Parts per million (dt.: Anzahl je Millionen [Maßeinheit])
PTB
Physikalisch Technische Bundesanstalt mit Sitz in Braunschweig.
RFC
Request For Comments
RZ
Rechenzentrum
SGBV
Sozialgesetzbuch, Band V
SigG
Signaturgesetz
SNTP
Simple Network Time Protocol
TCP
Transmission Control Protocol
TDS
Time Distribution System (Zeitverteilungssystem der PTP für
Modemeinwahl)
TI
Telematikinfrastruktur
UDP
User Datagram Protocol
UTC
Coordinated Universal Time
Version: 1.3.0
Seite 40 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
B2 – Glossar
Das Glossar wird als eigenständiges Dokument zur Verfügung gestellt.
Begrifflichkeiten, die im vorgenannten Kontext besondere Bedeutung haben, werden des
besseren Verständnisses wegen, nachfolgend als Auszug wiedergegeben. Diese Begriffe
werden wegen ihrer spezifischen Ausrichtung auf den vorliegenden Kontext in der Regel
im allgemeinen Glossar nicht wiederholt.
Tabelle 8: Glossar
Begriff
Erläuterung
BIOS
Basic Input Output System
Basis-Betriebssystem eines jeden x86 konformen Rechnersystems
(unabhängig davon, ob es sich um einen PC oder einen Server
handelt). Es ist die Software, die der Rechner direkt nach dem
Einschalten lädt. Sie steuert den POST (Power On Self Test) und steht
dem Steuerwerk der CPU direkt zur Verfügung. Es ist – wie eine
Firmware auch – im Allgemeinen in einem nicht flüchtigen Speicher
(Non volatile RAM) abgelegt.
IANA
Internet Assigned Numbers Authority.
Diese nicht-kommerzielle Organisation ist unter anderem für die
Zuweisung von im Internet-Protokoll verwendeten Portnummern
zuständig.
ISP (Internet
Service
Provider)
Die Internet Service Provider verbinden den Leistungserbringer mit dem
Internet, das als Transportnetz für den VPN Tunnel zum TelematikZugangsprovider dient.
Kiss-o’-death
Mit Hilfe dieses Verfahrens kann der NTP-Server die Anzahl der an ihn
gerichteten Anfragen von korrekt implementierten und hierarchisch
untergeordneten NTP-Servern beeinflussen. Das Verfahren ist in
Abschnitt 5.1.1.16 des Dokumentes „Spezifikation
Infrastrukturkomponenten: Zeitdienst“ beschrieben.
Masquerading
Masquerading (engl.) oder Adressmaskierung ist eine spezielle Form
von NAT und wird zumeist verwendet, um mehreren Computern in
einem Local Area Network Zugriff auf das Internet zu ermöglichen.
Dabei werden im Gegensatz zu NAT nicht nur die IP-Adressen,
sondern auch Port-Nummern umgeschrieben.
NAT
Network Adress Translation
Verfahren, das im Zuge der Verknappung von öffentlichen IPv4
Adressen entwickelt wurde und eine 1:n Umsetzung von einer
öffentlichen IP Adresse auf n private Adressen erlaubt. Beispiele dafür
finden sich am häufigsten bei geschäftlich genutzten, breitbandigen
Internetanbindungen, die eine Vielzahl von im LAN vernetzten PC’s
(privates Netzwerk) über eine öffentliche Adresse mittels NAT mit dem
Internet verbinden.
NTP
Network Time Protocol, The
Version: 1.3.0
Seite 41 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Begriff
Erläuterung
Ein Netzwerkprotokoll, das mit dem Hintergrund entwickelt wurde, eine
Vielzahl von vernetzten Systemen mit einer einheitlichen
Zeitinformation zu versorgen, so dass diese Systeme auch tatsächlich
über eine einheitliche Systemzeit verfügen. Die Entwicklung lässt sich
zurückverfolgen bis zu einer Vorführung während der US National
Computer Conference im Jahr 1979, während derer erste Gedanken zu
einer weltweiten Computerzeitsynchronisation geäußert wurden
(Quelle: [CNTS])
NTP-DDoS
Prinzipiell gleiches Verfahren wie bei NTP-DoS, jedoch erfolgen die
Anfragen von einer Vielzahl Clients aus gleichzeitig (daher auch
Distributed). Daraus resultierend ergibt sich eine mit der Anzahl der
anfragenden Clients linear ansteigende Last.
Um über eine ausreichende Anzahl von Clients zu verfügen, verteilt der
Angreifer im Allgemeinen so genannte Backdoor Programme (mit
eigenen Verteilungsroutinen, die Schwachstellen in Betriebssystemen
ausnutzen). Über diese Routinen kann der Angreifer dann koordiniert
die DDoS Angriffe starten. Dieses Szenario ist auch für NTP denkbar.
NTP-DoS
Der Begriff „Denial of Service (DoS)“ bezeichnet einen Angriff auf einen
Host oder Service mit dem Ziel, einen oder mehrere Dienste durch
Überlastung arbeitsunfähig zu machen.
Dazu belasten die Angriffe die Dienste eines Servers mit einer derart
hohen Anzahl von Anfragen, dass der Server diese nicht mehr oder nur
noch mit einer unzureichend langen Antwortzeit (Timeout) reagieren
kann.
Dieses Szenario ist auch für NTP denkbar.
NTP-Server
Serversysteme, die mittels NTPd (NTP Daemon)
Zeitsynchronisationsdienste anbieten und sich selber mit einer
Zeitquelle synchronisieren können. In Deutschland bietet die PTB
beispielsweise öffentliche Stratum 1 Server an, die unter den Namen
ptbtime1.ptb.de und ptbtime2.ptb.de erreichbar sind.
NVRAM
Non Volatile Random Access Memory → Nicht flüchtiger Speicher mit
wahlfreiem Zugriff.
In ihm wird in einem Rechnersystem das BIOS oder die Firmware
abgelegt.
PTB
Physikalisch Technische Bundesanstalt
mit Sitz in Braunschweig. Sie hat per Deutschem Zeitgesetz von 1978
den Auftrag, die amtliche Deutsche Zeit zur Verfügung zu stellen. Zur
Ermittlung der Zeit wird auf das physikalische Verhalten von Cäsium
133 zurückgegriffen, aus dem sich eine Sekunde herleiten lässt: "Die
Sekunde ist das 9 192 631 770-fache der Periodendauer der dem
Übergang zwischen den beiden Hyperfeinstrukturniveaus des
Grundzustandes von Atomen des Nuklids 133CS entsprechenden
Strahlung."
Die PTB verfügt über verschiedene Cäsium- und Cäsium-FontänenUhren.
Version: 1.3.0
Seite 42 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Begriff
Erläuterung
Stratum
Die Nähe einer Server-Zeit zu einer geeichten Normal-Zeit
(z. B. Atomuhr o. ä.) wird durch das sog. Stratum ausgedrückt. Der
Wert des Stratums ist Null für einen NTP-Server, der seine Zeit direkt
mit einer geeichten Quelle synchronisiert. Server, die ihre
Zeitinformation direkt von einer Cäsium Atomuhr beziehen, können
selbst als Stratum-0-Server fungieren. Der hierarchisch eine Stufe tiefer
angeordnete Server, der seine Zeitinformationen vom Stratum 0 Server
bezieht bzw. etwa per DCF-77 Funksignal erhält, bezeichnet sich als
Stratum 1 Server.
TDS
Time Distribution System
Verfahren zur Distribution der amtlichen Deutschen Zeit. Dabei besteht
die Möglichkeit, per Modem das TDS der PTB anzuwählen und so ein
Zeitsignal zur Uhrsynchronisation zu erhalten. Es ist – wie auch per
DCF77 und GPS – geeignet, Stratum 1 Server aufzubauen.
TelematikZugangsprovider
Die Telematik-Zugangsprovider sind mehrfach redundant und
breitbandig mit dem Internet als Transportnetz verbunden und stellen
den Tunnelendpunkt für die VPN Verbindungen ausgehend vom
Konnektor zur Verfügung. Weiterhin stellen sie die physikalische
Anbindung an das MPLS-Backbone bereit.
UDP
User Datagram Protocol
Auf Transportebene (Schicht 4) neben TCP als zweites Protokoll
implementiert. Es garantiert gegenüber TCP keine Ende-zu-Ende
Kontrolle. Es setzt auf dem Internet Protocol (IP) auf Schicht 3 auf.
UTC
(engl.) Coordinated Universal Time → Koordinierte Weltzeit.
Sie stellt die aktuelle Weltzeit dar und hat in dieser Funktion die vielen
geläufige, Greenwich Mean Time abgelöst. Sie ist eine Kombination
aus der internationalen Atomzeit TAI und der Universalzeit UT. Die
Zeitzonen werden als positive oder negative Abweichung von UTC
angegeben (z. B. UTC + 2 entspricht der MESZ). UTC ist unter
anderem die Referenzzeit im Internet und auch vielfach in
Computersystemen.
Zeitdienst
Er beschreibt ein Verfahren, das basierend auf existenten und weltweit
jahrelang erprobten Technologien (NTP) für alle zentralen und
dezentralen Komponenten und Systeme der Telematikinfrastruktur im
Deutschen Gesundheitswesen, bis hinunter zu den Primärsystemen der
Leistungserbringer eine bundesweit einheitliche Systemzeit
gewährleistet.
Zugangsprovider
Siehe Telematik-Zugangsprovider
Version: 1.3.0
Seite 43 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
B3 – Abbildungsverzeichnis
Abbildung 1: Hierarchischer Aufbau des Zeitdienstes ......................................................17
Abbildung 2: Topologie der Zeitdienste............................................................................28
Abbildung 3: Funktionsweise des Zeitdienstes.................................................................30
Abbildung 4: Szenario "Ausfall aller Stratum 1 Server" ....................................................32
B4 - Tabellenverzeichnis
Tabelle 1: Anforderungen ................................................................................................11
Tabelle 2: Annahmen.......................................................................................................14
Tabelle 3: Pollingintervalle für NTP-Serverkonfigurationen ..............................................25
Tabelle 4: Ausfallszenarien..............................................................................................31
Tabelle 5: Lastannahmen - Minimalanforderungen ..........................................................33
Tabelle 6: Lastannahmen – Mittlere Anforderungen.........................................................34
Tabelle 7: Lastannahmen - Maximale Anforderungen......................................................35
Tabelle 8: Glossar ...........................................................................................................41
Tabelle 9: NTP RFC Historie ...........................................................................................47
Tabelle 10: Entscheidungen ............................................................................................48
Version: 1.3.0
Seite 44 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
B5 - Referenzierte Dokumente
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument
referenzierten Dokumente der gematik. Der mit dem vorliegenden Dokument
korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen, die im Rahmen
des Vorhabens zur Einführung der Gesundheitskarte veröffentlicht werden, wird pro
Release in einer Dokumentenlandkarte definiert. Version und Stand der referenzierten
Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Die jeweils gültige
Version und das Freigabedatum der aufgeführten gematik-Dokumente entnehmen Sie
bitte der von der gematik veröffentlichten Dokumentenlandkarte (aktuell
[gemDokLK_2.3.4]), wobei jeweils der aktuellste Releasestand maßgeblich ist, in dem die
vorliegende Version aufgeführt wird. Zur Unterstützung der Zuordnung wird in der
Dokumentenlandkarte im Kapitel 4 eine Übersicht über die Dokumentenversionen und
deren Zuordnung zu den verschiedenen Releases bereitgestellt.
[Quelle]
Herausgeber (Erscheinungsdatum): Titel
[gemDokLK_2.3.4
]
gematik: Einführung der Gesundheitskarte –
Dokumentenlandkarte Releasestand 2.3.4 – Online Feldtest 10.000
Festlegung der Versionsstände
[gemGesArch]
gematik: Einführung der Gesundheitskarte Gesamtarchitektur
[gemSiKo]
gematik: Einführung der Gesundheitskarte Übergreifendes Sicherheitskonzept
[gemSiKo#AnhC]
Übergreifendes Sicherheitskonzept der Telematikinfrastruktur
Anhang C: Schutzbedarfsanalyse
[gemSpec_Kon]
gematik: Einführung der Gesundheitskarte Konnektorspezifikation
[gemSysSLM]
Spezifikation System und Service Level Monitoring
Weitere Referenzierungen:
[Quelle]
[CNTS]
CRC Press Taylor & Francis Group (März 2006):
Computer Network Time Synchronization The Network Time
Protocol, David L. Mills (ISBN: 0-8493-58051)
[Draft_NTPv4]
J. Burbank, J. Martin (Juli 2005):
The Network Time Protocol (SNTP) Version 4 Protocol
Specifications
http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-01.txt
[IANA-PORT]
IANA Port number registration (last update: Mai 2006):
Version: 1.3.0
Seite 45 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
[Quelle]
Die IANA (Internet Assigned Numbers Authority) vergibt unter
anderem die Portnummern des Internet Protocols (IP).
Der aktuelle Stand ist jederzeit unter
http://www.iana.org/assignments/port-numbers abrufbar.
[NTP-FAQ]
The NTP FAQ and HOWTO (Oktober 2005):
Understanding and using the Network Time Protocol (A first try on a
non-technical Mini-HOWTO and FAQ on NTP)
Veröffentlicht unter http://www.ntp.org/ntpfaq/NTP-a-faq.htm
[NTP-Src]
Der Sourcecode der NTP v4 Software Suite ist im Internet unter
http://www.ntp.isc.org/bin/view/Main/SoftwareDownloads
unter den Bedingungen der folgenden Copyright notice frei
verfügbar:
Copyright (c) David L. Mills 1992-2003
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appears in all
copies and that both the copyright notice and this permission
notice appear in supporting documentation, and that the name
University of Delaware not be used in advertising or publicity
pertaining to distribution of the software without specific, written
prior permission. The University of Delaware makes no
representations about the suitability this software for any
purpose. It is provided "as is" without express or implied
warranty.
[RFC1305]
RFC 1305 (März 1992):
Network Time Protocol (Version 3) Specification, Implementation
and Analysis
http://www.ietf.org/rfc/rfc1305.txt
[RFC2119]
RFC 2119 (März 1997):
Key words for use in RFCs to Indicate Requirement Levels
S. Bradner, http://www.ietf.org/rfc/rfc2119.txt
[RFC4330]
RFC 4330 (Januar 2006):
Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
OSI
ftp://ftp.rfc-editor.org/in-notes/rfc4330.txt
[STime]
RFC, D. Mills (August 2003):
The Autokey Security Architecture, Protocol and Algorithms,
veröffentlicht unter
http://www.eecis.udel.edu/%7Emills/database/reports/stime/stime.pd
f
Die genannten Dokumente referenzieren auf eine Reihe weiterer RFC’s (RFC = Request
for Comment), insbesondere deren Vorläufer, die durch diese Dokumente abgelöst und
für ungültig erklärt worden sind.
Version: 1.3.0
Seite 46 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
NTP RFC Historie
Tabelle 9: NTP RFC Historie
RFC
Name
Status
Ersetzt durch
RFC0958 Network Time Protocol (NTP)
Unknown
RFC1059
RFC1119
RFC1305
RFC1059 Network Time Protocol (version 1)
specification and implementation.
Unknown
RFC1119
RFC1305
RFC1119 Network Time Protocol (version 2)
specification and implementation.
Standard
RFC1305
RFC1305 Network Time Protocol (Version 3)
Specification, Implementation and
Analysis.
Draft Standard
RFC1361 Simple Network Time Protocol (SNTP)
Informational
RFC1769
Informational
RFC2030
RFC4330
Version 4 for IPv4, IPv6 and OSI
Informational
RFC4330
Version 4 for IPv4, IPv6 and OSI
Informational
Konfigurationsinformationen für Truechimer und Falseticker
http://ntp.isc.org/bin/view/Support/SelectingOffsiteNTPServers
finden
sich
unter
B6 – Entscheidungen und Annahmen
B6.1 – Annahmen
Annahmen werden in Kapitel 3 behandelt.
Version: 1.3.0
Seite 47 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
B6.2 – Entscheidungen
Tabelle 10: Entscheidungen
Lfd.Nummer
Beschreibung und Begründung der Entscheidung
ZD-E-010
Verwendete Protokollversion
Als Protokoll des Zeitdienstes findet NTP in der Version 4 Verwendung –
auch wenn diese Protokollversion bislang nur als Draft vorliegt (vgl.:
[Draft_NTPv4])
Begründung:
• NTP- oder SNTP-Server, die mit Protokollversion 4 arbeiten, sind
clientseitig nicht von Protokollversion 3 zu unterscheiden.
• NTPv4 verwendet das Standard NTP Timestamp Format aus NTPv3
[RFC1305].
• NTP- oder SNTP-Server sind abwärtskompatibel und kommunizieren
mit den Clients entsprechend der clientseitigen Protokollversion.
• NTPv4 findet bereits weltweit ein hohes Maß an Verbreitung, selbst die
offiziellen Zeitserver der Bundesrepublik Deutschland (Physikalisch
Technische Bundesanstalt, Braunschweig, ptbtime1.ptb.de sowie
ptbtime2.ptb.de) verwenden bereits NTPv4.
•
NTPv4 unterstützt umfangreiche Authentisierungsverfahren in
Kombination mit komfortablem Management.
Weiterführende Erläuterungen dazu finden sich im Dokument
[Draft_NTPv4] auf Seite 4 im letzten Absatz.
ZD-E-020
Netzwerkprotokoll
Sowohl NTP als auch SNTP setzen auf dem User Datagram Protocol
(UDP) auf, das wiederum auf dem Internet Protocol (IP) aufsetzt.
Verwendung findet der UDP Port 123, sowohl als Source als auch
Destination Port.
Es wird ausschließlich Unicast in einem hierarchischen Konzept
verwendet.
Begründung:
Alternativ könnte Multicast Verwendung finden, das aber in umfangreich
segmentierten Netzen zu unkalkulierbaren Netzlasten führen kann. Im
Kontext der Telematikinfrastruktur ist daher ein streng hierarchischer
Aufbau vorzuziehen.
Die Portvorgabe orientiert sich an der Portvorgabe von [Draft_NTPv4],
Seite 7, letzter Absatz. Des Weiteren verwenden die meisten NTP Client
Standardinstallationen diese Konfiguration.
ZD-E-030
Zeitquellen für Stratum 1 Server
Für den Aufbau der Stratum 1 Ebene finden folgende Zeitquellen
Verwendung:
•
DCF77 – Empfänger für den Empfang des offiziellen deutschen
Zeitsignals vom Sender DCF77/Mainflingen,
Version: 1.3.0
Seite 48 von 49
© gematik
Stand: 20.06.2008
Zeitdienst
Lfd.Nummer
Beschreibung und Begründung der Entscheidung
•
•
ggf. GPS-Empfänger
Einwahl per Modem in das TDS (Time Distribution System) der
Physikalisch-Technischen Bundesanstalt (PTB) Braunschweig (+49 .
(0) 5 31 . 51 20 38)
ZD-E-040
Nutzung des Zeitdienstes
Der angebotene Zeitdienst wird durch alle Systeme genutzt, die sowohl
zentrale Dienste als auch Fachanwendungen anbieten. Als dezentrale
Komponenten nutzen Konnektoren den Zeitdienst und können ihn als
Stratum 3 Server auch den Primärsystemen anbieten.
ZD-E-050
Authentizität der Zeitserver
Die Überprüfung der Authentizität der Zeitserver untereinander mit Hilfe
des Autokey-Verfahrens wird nicht verwendet.
Begründung:
In einem Gespräch mit Mitarbeitern des BSI vom 16.10.2006 wurde
dargestellt, dass der Zeitdienst keine medizinischen oder
personenbezogenen Daten berührt, sondern ausschließlich zur
Herbeiführung einer telematikweiten, temporalen Ordnung dient.
Der Zeitdienst findet keine Verwendung bei der Erstellung von
qualifizierten, akkreditierten elektronischen Zeitstempeln.
Die NTP-Server werden allesamt in gesicherten Rechenzentrumsumgebungen unter Kontrolle und Verantwortung der gematik betrieben,
ein externer (unautorisierter) Zugriff ist nur durch Einbruch in die TI
möglich.
Der Einsatz ohne kryptografische Authentizitätsprüfung ist millionenfach im
Internet bewährt (Best Practice) und bedarf keiner zusätzlichen
Anpassungen für den Einsatz in der Gesundheitstelematik.
Die Verwendung der kryptographischen Funktionen wäre aus betrieblicher
Sicht nicht durchführbar, da das Schlüsselmaterial manuell auf allen
Komponenten aufgebracht werden muss.
Diese Gründe führten zu der Entscheidung, dass von der Verwendung von
kryptographischen Authentizitätsprüfungen (Autokey Protokoll) und
eventuellen Evaluierungen des Zeitdienstes nach den Maßgaben der
Common Criteria abgesehen wird.
ZD-E-060
Räumliche Entfernung der Rechenzentren zueinander
Die in den Abschnitten 5.1.1.7 und 5.1.1.10 ursprünglich vorgenommene
Entfernungsangabe von mindestens 25 Kilometern wurde ersetzt durch
„geeignete Entfernung“.
Begründung:
Es ist einem Anbieter/Betreiber nicht zuzumuten, nur aufgrund der
Festlegung auf eine Mindestentfernung von 25 Kilometern möglicherweise
aus dem Bieterverfahren auszuscheiden, auch wenn seine Rechenzentren
etwa nur 20 Kilometer voneinander entfernt sind, aber dennoch
ausreichenden Schutz vor Elementarschäden sicherstellen können.
Version: 1.3.0
Seite 49 von 49
© gematik
Stand: 20.06.2008

Spezifikation Infrastrukturkomponenten: Zeitdienst

Transcription

Similar documents

PDF Gebrauchsanweisung

inhalt - Intenso

Ein Referenzmodell zur Integration der

Skript zum Internetrecht, September 2007

EHEALTHCOMPASS

Spezifikation eHealth-Kartenterminal

MySQL-Referenzhandbuch

MySQL 4.0 Referenzhandbuch - MySQL Community Downloads

MySQL 5.1 Referenzhandbuch

LR-16 Bedienungsanleitung

Quick Installation Guide Installatie handleiding Guide d

MM-Line pdf Dokument

Konfigurieren eines autorisierenden Zeitservers in Windows 2000

medical appointment scheduling software

PDF - Polytech Systeme AG

TimeDesign - Zeiterfassung - Zugangskontrolle TIDE

Aufbauanleitung Spielturm Art. 261700