Einführung der Gesundheitskarte Spezifikation Infrastrukturkomponenten: Zeitdienst

Größe: px
Ab Seite anzeigen:

Download "Einführung der Gesundheitskarte Spezifikation Infrastrukturkomponenten: Zeitdienst"

Transkript

1 Einführung der Gesundheitskarte Spezifikation Infrastrukturkomponenten: Version: Revision main/rel_main/5 Stand: Status: freigegeben gematik_inf_spezifikation_.doc Seite 1 von 49

2 Dokumentinformationen Änderungen zu den Vorversionen Anforderungen an die Verfügbarkeiten und SLA für den 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 wurde festgestellt, dass die durch das ISC veröffentlichten stabilen NTP-Versionen (stable releases) bis einschließlich ntp p2 in Kombination mit Linux Kerneln kleiner Version 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 und 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: Dokumentenhistorie gematik_inf_spezifikation_.doc Seite 2 von 49

3 Version Stand bis Kap./ Seite Grund der Änderung, besondere Hinweise Neuerstellung des Konzepts AG Korrekturen nach AG interner QS Redaktionelle Überarbeitung im Bereich der Anforderungen sowie Kapitel 5 und Redaktionelle Änderungen nach AG interner QS, Kapitel 6 Autokey wird als offen deklariert, da Tests zum Autokey Verfahren noch nicht abgeschlossen sind Letzte Änderungen vor Übergabe an interne QS Änderungen durch QS IQS Änderungen nach gematik interner QS, Reorganisation Anforderungen und Annrahmen sowie deren Referenzierungen Bearbeitung AG8 AG8 AG8 AG Freigabe zur Vorkommentierung gematik Freigabe nach Einarbeitung der Kommentare gematik A , Anpassung an aktuelle Entwicklungen: Autokey Protokoll wird nicht verwendet, daher Entfernung aller relevanten Textpassagen und Vermerk im Anhang A6 Entscheidungen und Annahmen, Änderung hinsichtlich der Mindestentfernung von Rechenzentren zueinander Aufnahme von Hersteller- und Anbieterneutralität, Anpassung betrieblicher Aspekte an aktuelle Gegebenheiten, (Beispiel: Kompilierung von ntp für den Einsatz in der Telematikinfrastruktur) AG freigegeben gematik Zusätzliche Stratum 2 Server AG freigegeben gematik Anforderungen an SLA- und Verfügbarkeiten wurden im Rahmen von Betriebsvereinbarungen entfernt, Ergänzung der Definition der Anzahl von SPE/ZD gematik_inf_spezifikation_.doc Seite 3 von 49

4 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise 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. Ergänzungen in der Definition, welche Betreiber vpn Fachanwendungen und diensten sowie Komponenten sich mit Zeitservern der Stratum 2 Ebene (zentral) zu synchronisieren haben. Festlegung der Synchronisationsintervallen Deklaration von GPS Empfängern als Zeitquelle nur für den Notfall Die Tabelle Anforderungen wurde auf die aktuelle Formatvorlage umgestellt, hat inhaltlich keine Änderung erfahren Anhang Restrukturierung: A7 jetzt A, A1 bis A6 jetzt B1 bis B6 Bearbeitung SPE/ZD freigegeben gematik QM gematik_inf_spezifikation_.doc Seite 4 von 49

5 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokumentes Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokumentes Qualifizierte Zeitstempel/Qualifizierte und akkreditierte Zeitstempel Verwendung von Schüsselworten Anforderungen und Annahmen Einleitung Nomenklatur Anforderungen Annahmen Systemüberblick Zweck Funktionsumfang Grobstruktur des Dienstes Rahmenbedingungen Realisierung Topologie der e Grundsätzlicher Aufbau Network Time Protocol v Netzwerkprotokoll Hierarchische Konzeption Betriebsarten NTP Zeitquellen der Stratum 1 Server Betriebsverantwortung der Zeitserver...20 gematik_inf_spezifikation_.doc Seite 5 von 49

6 Technische Realisierung der Stratum 1 Ebene Verfügbarkeiten der Stratum 1 Ebene Realisierung der Ebene Stratum 2 dezentral Realisierung der Ebene Stratum 2 zentral Zeitquelle der Stratum 2 Ebene Verfügbarkeit der Stratum 2 Ebene (zentral und dezentral) Technische Konzeption der Stratum 3 Ebene Verfügbarkeit der Stratum 3 Ebene Abwehrmechanismen gegen NTP-DoS/NTP-DDoS Synchronisationsintervalle Kurzzeitgenauigkeit der Stratum 1 Server Freilaufgenauigkeit der Zeitserver Skalierbarkeit des Dienstes Berücksichtigung von Zeitzonen Berücksichtigung von Laufzeitvarianzen Aufbau und Funktionsweise des es Administration des es Funktionen und Redundanz Dienstnutzung Skalierung Lastannahmen Erweiterte Funktionen und Betrieb 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 gematik_inf_spezifikation_.doc Seite 6 von 49

7 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 es 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ährleistet 1. 1 Der Begriff Einheitliche Systemzeit ist relativer Natur, die Schwankungen bewegen sich je nach Qualität der Systemkomponenten im Millisekunden- bis hinunter zum Picosekundenbereich. gematik_inf_spezifikation_.doc Seite 7 von 49

8 2 Einführung 2.1 Zielsetzung und Einordnung des Dokumentes Das vorliegende Dokument dient als Spezifikation zur Realisierung eines es 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 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 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 zurück und synchronisieren die jeweilige Systemzeit. Anbieter von Konnektoren müssen auf den der Telematikinfrastruktur zurückgreifen, um eine korrekte Systemzeit zu beziehen. Wiederum kann der Konnektor den Primärsystemrechnern gegenüber als Anbieter eines es (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 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 es lediglich empfohlen werden kann. gematik_inf_spezifikation_.doc Seite 8 von 49

9 Die in diesem Dokument getroffenen Festlegungen sind als verbindlich zur Realisierung eines es anzusehen. 2.4 Arbeitsgrundlagen Als Grundlage für die Spezifikation eines es 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 ergeben. 2.5 Abgrenzung des Dokumentes 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 SOLL gekennzeichnet. Abweichungen sind in begründeten Fällen möglich. 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. gematik_inf_spezifikation_.doc Seite 9 von 49

10 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 lfd. Nr. 010 AN-ZD-010 Nicht-funktionale Anforderung lfd. Nr. 010 AnF-ZD-010 Funktionale Annahme lfd. Nr. 010 AnN-ZD-010 Nicht-funktionale Annahme lfd. Nr Anforderungen Der 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 mit einer fortlaufenden Nummerierung versehen und beschrieben. gematik_inf_spezifikation_.doc Seite 10 von 49

11 Tabelle 1: Anforderungen Afo-ID Kla sse Titel Quelle Beschreibung Release Umgesetzt durch AF-ZD- 010 F : Protokolle (ohne) Der 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 Abschnitt AF-ZD- 020 F Authentizität der Zeitserver / Sicherheitsanforderungen (Entfallen) - - AF-ZD- 030 F Konzeption der tertiären Ebene Konnektoren repräsentieren die Zeitserver der tertiären Ebene. Die hierarchische Organisation des es ist der Funktionalen Annahme ZD-FAnn-030 beschrieben Abschnitt , 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. AF-ZD- 040 F Abwehrmechanismen Zum Selbstschutz sind Verfahren vorzusehen, mit dessen Hilfe der die Anzahl der an ihn gerichteten Anfragen unterdrücken beziehungsweise beeinflussen MUSS Abschnitt AF-ZD- 050 F 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]) Abschnitt AF-ZD- 060 F Betriebsarten vom Zum Einsatz MUSS ausschließlich die Betriebsart Client Server, kommen, andere Konzepte sind unter Last- und Sicherheitsaspekten nicht vorgesehen Abschnitt AF-ZD- 070 F Zeitquellen Der MUSS seine Zeitinformation von der gesetzlichen Zeit für die Bundesrepublik Deutschland oder einem Äquivalent beziehen können Abschnitt AF-ZD- 080 F Technisch konzeptionelle Anforderungen an die primäre Ebene Die Systeme der primären Ebene MÜSSEN hochverfügbar ausgelegt werden. Sie MÜSSEN derart ausgestaltet sein, dass sie auch den in [AnN-ZD-030] gestellten Anforderungen genügen Abschnitt AF-ZD- 090 F Technisch konzeptionelle Anforderungen Diese Systeme der sekundären Ebene werden in den Rechenzentren der Telematik-Zugangsprovider aufgebaut und Abschnitt gematik_inf_spezifikation_.doc Seite 11 von 49

12 Afo-ID AF-ZD- 100 AF-ZD- 110 AF-ZD- 120 AF-ZD- 130 Kla sse F Titel Quelle Beschreibung Release an die sekundäre Ebene Stratum 2 dezentral Fehlerresistenz der Zeitserver, sekundäre Ebene F Technisch konzeptionelle Anforderungen an die sekundäre Ebene Stratum 2 zentral F F Kurzzeitgenauigkeit der Systeme der primären Ebene Zeitserver- Freilaufgenauig keit AF-ZD- F Anforderungen an die von diesen betrieben. Die sekundären Zeitserver eines Telematik- Zugangsproviders dürfen sowohl bis zur öffentlichen Internet-Infrastruktur als auch bis zum nicht-öffentlichen Telematik- Netzwerk 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 Die sekundäre Ebene (Stratum 2 zentral 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. 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. Die Kurzzeitgenauigkeit 2 von Systemen der primären Ebene MUSS 1ms nicht überschreiten Die Freilaufgenauigkeit 3 von Systemen der 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 Umgesetzt durch Abschnitt Abschnitt Abschnitt Abschnitt Entfallen Unter Kurzzeitgenauigkeit wird die Abweichung der internen Uhr des NTP-Servers vom zuletzt empfangenen Zeitsignal verstanden. 3 Genauigkeit des Zeitservers ohne Synchronisation gematik_inf_spezifikation_.doc Seite 12 von 49

13 Afo-ID Kla sse Titel Quelle Beschreibung Release 140 Netzwerkplanun g, insbes. NAT Umgesetzt durch AF-ZD- 150 F Berücksichtigun g von Zeitzonen Der muss in der Lage sein, ein einheitliches System zur Berücksichtigung von Zeitzonen abzubilden Abschnitt AF- ZD- 160 F Berücksichtigun g von Laufzeitvarianze n Der ist derart auszugestalten, dass Laufzeitvarianzen innerhalb eines Netzwerkes berücksichtigt werden Abschnitt AN- ZD- 010 N Synchronisation srhythmus Systeme der primären Hierarchieebene MÜSSEN die Zeitinformation permanent abgleichen. Systeme der sekundären Ebene MÜSSEN die Zeitinformation mehrmals pro Stunde abrufen können Abschnitt Systeme der tertiären Ebene synchronisieren die Zeitinformation im Regelbetrieb mindestens einmal täglich. Die hierarchische Organisation des es ist der Funktionalen Annahme AN-ZD-020 beschrieben. AN-ZD- 020 N Hierarchie Der MUSS hierarchisch organisiert werden Abschnitt AN-ZD- 030 N 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- 040 N 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- 050 N Verfügbarkeit der tertiären Ebene Sofern der Konnektor den Primärsystemen einen anbieten KANN (vgl.: [AF- ZD-030]), richtet sich die Verfügbarkeit des es im Konnektor nach der Verfügbarkeit des Konnektors selber und findet in diesem Dokument keine Betrachtung Behandlun g in Spezifikation [gemspec_ Kon] AN-ZD- 060 N Skalierbarkeit des Dienstes Der ist derart auszugestalten, dass er skaliert werden kann Abschnitt AN-ZD- 070 N Antwortzeiten Anforderungen an die Antwortzeiten des es werden in Betriebsvereinbarungen behandelt. - - AN-ZD- 080 N Netzwerksicher heit Die server sind durch geeignete Maßnahmen vor Zugriffen außerhalb der NTP-Spezifikation zu schützen Blattanforderun g 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. gematik_inf_spezifikation_.doc Seite 13 von 49

14 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 beschrieben: Tabelle 2: Annahmen Lfd. Nummer AnN-ZD-010 AnN-ZD-020 AnN-ZD-030 AnN-ZD-040 AnN-ZD-050 Beschreibung der nicht-funktionalen Annahme 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. Wartungsintervalle/Katastrophentest Wartungsintervalle und Katastrophentests werden im Rahmen von Betriebsvereinbarungen behandelt. 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). System Monitoring Das Monitoring des es wird in [gemsysslm] behandelt. Reporting Das Reporting wird in [gemsysslm] behandelt. gematik_inf_spezifikation_.doc Seite 14 von 49

15 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 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 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. Mit dieser Lösung kann eine temporale Ordnung hinsichtlich der Nachvollziehbarkeit und Protokollierung hergestellt werden. gematik_inf_spezifikation_.doc Seite 15 von 49

16 Ziel ist es, bestmögliche Genauigkeit unter Berücksichtigung von Netzwerk- und Servereinflüssen zu erlangen 4, Resistenz gegenüber einer Vielzahl von Fehlern und Attacken zu erlangen. 4.2 Funktionsumfang Primär dient der 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 server 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 Primärsystemen als Zeitquelle zur Synchronisation der Systemuhren dienen. 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) gematik_inf_spezifikation_.doc Seite 16 von 49

17 Abbildung 1: Hierarchischer Aufbau des es Generell besteht die Möglichkeit, dass die Zeitinformationen neben den bekannten Client- Server 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 es 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]. gematik_inf_spezifikation_.doc Seite 17 von 49

18 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). gematik_inf_spezifikation_.doc Seite 18 von 49

19 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 e Grundsätzlicher Aufbau Network Time Protocol v4 Für die Realisierung des es 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 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.) 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]) gematik_inf_spezifikation_.doc Seite 19 von 49

20 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]) 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) ) 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]) 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 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 für Komponenten und Fachanwendungssysteme innerhalb der Telematikinfrastruktur zur Verfügung. gematik_inf_spezifikation_.doc Seite 20 von 49

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

Network Time Protocol NTP

Network Time Protocol NTP Network Time Protocol NTP Autor: Luca Costa, HTW Chur, luca.costa@tet.htwchur.ch Dozent: Bruno Wenk, HTW Chur, bruno.wenk@fh-htwchur.ch Inhaltsverzeichnis 1 Network Time Protocol... 3 1.1 Einleitung...

Mehr

Zeitsynchronisation Windows Server 2008 R2 PDC Master der FRD mit einer externen Zeitquelle

Zeitsynchronisation Windows Server 2008 R2 PDC Master der FRD mit einer externen Zeitquelle Zeitsynchronisation Windows Server 2008 R2 PDC Master der FRD mit einer externen Zeitquelle Wie funktioniert die Zeitsynchronisation in Windows Netzwerken: http://support.microsoft.com/kb/816042 MSDN Blog

Mehr

Kapitel 4 Zugriffsbeschränkungen

Kapitel 4 Zugriffsbeschränkungen Kapitel 4 Zugriffsbeschränkungen In diesem Kapitel erfahren Sie, wie Sie Ihr Netzwerk durch Zugriffsbeschränkungen des 54 MBit/s Wireless Router WGR614 v6 schützen können. Diese Funktionen finden Sie im

Mehr

Konfigurieren eines autorisierenden Zeitservers in Windows

Konfigurieren eines autorisierenden Zeitservers in Windows Seite 1 von 5 Suche in -> Deutsche Artikel Konfigurieren eines autorisierenden Zeitservers in Windows 2000 Dieser Artikel wurde zuvor veröffentlicht unter D42387 Artikel-ID : 216734 Dieser Artikel ist

Mehr

Bericht über Kooperation zwischen JOIN/Fa. Meinberg

Bericht über Kooperation zwischen JOIN/Fa. Meinberg Meinberg Lantime und IPv6-Integration Bericht über Kooperation zwischen JOIN/Fa. Meinberg Copyright 2003 by Christian Strauf (JOIN) 39. Betriebstagung des DFN in Berlin 11.-12.

Mehr

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7.

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7. Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr

Projekt IT-Sicherheitskonzept.DVDV

Projekt IT-Sicherheitskonzept.DVDV Projekt IT-Sicherheitskonzept.DVDV Dokumentation.Sicherheitsrichtlinie.Server DVDV Dienstleister Bundesverwaltungsamt BIT 3 Barbarastr. 1 50735 Köln 10. Mai 2006 Dokumentinformationen Projekt IT-Sicherheitskonzept.DVDV

Mehr

Uhrensynchronisation. Dipl.-Inf. J. Richling Wintersemester 2003/2004

Uhrensynchronisation. Dipl.-Inf. J. Richling Wintersemester 2003/2004 Uhrensynchronisation Dipl.-Inf. J. Richling Wintersemester 2003/2004 Motivation Zeit kann in Anwendungen eine große Rolle spielen, insbesondere bei Echtzeitsystemen Häufig wichtiger noch als korrekte Zeit:

Mehr

Übung zur Vorlesung Echtzeitsysteme

Übung zur Vorlesung Echtzeitsysteme Technische Universität München Fakultät für Informatik Forschungs- und Lehreinheit Informatik VI Übung zur Vorlesung Echtzeitsysteme Aufgabe 3 Nadine Keddis keddis@fortiss.org Stephan Sommer sommerst@in.tum.de

Mehr

Kundeninfo Anbindung externer Standorte an die Uptime Cloud

Kundeninfo Anbindung externer Standorte an die Uptime Cloud Kundeninfo Anbindung externer Standorte an die Uptime Cloud 1 Einleitung Uptime IT bietet seinen Kunden Infrastructure as a Service (IaaS) Leistungen auf Basis der Uptime Cloud an 2 Standorten an. Für

Mehr

Synchronisation des Temperatur-Loggers

Synchronisation des Temperatur-Loggers Synchronisation des Temperaturloggers Juni 10, 2010 1 / 7 Synchronisation des Temperatur-Loggers Einführung Zwei oder mehr Installationen der Temperaturlogger-Software können so zusammen geschaltet werden,

Mehr

Verteilte Systeme - Synchronisation

Verteilte Systeme - Synchronisation Verteilte Systeme - Synchronisation... alois.schuette@h-da.de Alois Schütte 25. Februar 2014 1 / 24 Inhaltsverzeichnis Die Synchronisationsmethoden bei Einprozessorsystemen (z.b. Semaphore oder Monitore)

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777

KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777 KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777 Fernzugriff mit der ETS Achatz 3 84508 Burgkirchen Tel.: 08677 / 91 636 0 Fax:

Mehr

... relevante Ports für Streaming bzw. Remote Control!

... relevante Ports für Streaming bzw. Remote Control! ... relevante Ports für Streaming bzw. Remote Control! Wenn Sie mit der Installation des IO [io] 8000 / 8001 beginnen, ist es am sinnvollsten mit einem minilan zu beginnen, da dies mögliche Fehlrequellen

Mehr

Information Security Policy für Geschäftspartner

Information Security Policy für Geschäftspartner safe data, great business. Information Security Policy für Geschäftspartner Raiffeisen Informatik Center Steiermark Raiffeisen Rechenzentrum Dokument Eigentümer Version 1.3 Versionsdatum 22.08.2013 Status

Mehr

BSI Technische Richtlinie

BSI Technische Richtlinie BSI Technische Richtlinie Bezeichnung: IT-Basisinfrastruktur IT-Sicherheit Anwendungsbereich: De-Mail Kürzel: BSI TR 01201 Teil 1.3 Version: 1.2 Bundesamt für Sicherheit in der Informationstechnik Postfach

Mehr

56. UKW Tagung Weinheim 2011 Zeitsynchronisation mit NTP (Network Time Protocol)

56. UKW Tagung Weinheim 2011 Zeitsynchronisation mit NTP (Network Time Protocol) (Network Time Protocol) Warum NTP? Grundlagen von NTP Netzarchitektur Zeitserver (Einzelsystem, Pool) Clientkonfiguration UNIX / Linux Clientkonfiguration Windows Literaturquellen Diskussion Referent:

Mehr

Bestätigung. TÜV Informationstechnik GmbH - ein Unternehmen der RWTÜV-Gruppe - Zertifizierungsstelle Am Technologiepark 1.

Bestätigung. TÜV Informationstechnik GmbH - ein Unternehmen der RWTÜV-Gruppe - Zertifizierungsstelle Am Technologiepark 1. Bestätigung von Produkten für qualifizierte elektronische Signaturen gemäß 15 Abs. 7 und 17 Abs. 4 Gesetz über Rahmenbedingungen für elektronische Signaturen und 11 Abs. 3 Verordnung zur elektronischen

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

Technischer Anhang. Version 1.2

Technischer Anhang. Version 1.2 Technischer Anhang zum Vertrag über die Zulassung als IP-Netz-Provider im electronic cash-system der deutschen Kreditwirtschaft Version 1.2 30.05.2011 Inhaltsverzeichnis 1 Einleitung... 3 2 Anforderungen

Mehr

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Seite 1 von 6 Autor: G. Raptis Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Gültigkeitsmodelle beschreiben den Algorithmus nach dem ein Client oder Dienst entscheidet,

Mehr

ISA 2004 Netzwerkerstellung von Marc Grote

ISA 2004 Netzwerkerstellung von Marc Grote Seite 1 von 7 ISA Server 2004 Mehrfachnetzwerke - Besonderheiten - Von Marc Grote Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Einleitung In meinem ersten Artikel habe

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen Konzept für eine Highperformance- und Hochverfügbarkeitslösung für Anforderungen : einen Anbieter von Krankenhaus Abrechnungen Es soll eine Cluster Lösung umgesetzt werden, welche folgende Kriterien erfüllt:

Mehr

Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur

Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur Einheitliche Methoden der Informationssicherheit Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur Version: 1.1.0 Revision: \main\rel_online\17 Stand: 30.05.2013 Status: freigegeben

Mehr

Powermanager Server- Client- Installation

Powermanager Server- Client- Installation Client A Server Client B Die Server- Client- Funktion ermöglicht es ein zentrales Powermanager Projekt von verschiedenen Client Rechnern aus zu bedienen. 1.0 Benötigte Voraussetzungen 1.1 Sowohl am Server

Mehr

ESA SECURITY MANAGER. Whitepaper zur Dokumentation der Funktionsweise

ESA SECURITY MANAGER. Whitepaper zur Dokumentation der Funktionsweise ESA SECURITY MANAGER Whitepaper zur Dokumentation der Funktionsweise INHALTSVERZEICHNIS 1 Einführung... 3 1.1 Motivation für den ESA Security Manager... 3 1.2 Voraussetzungen... 3 1.3 Zielgruppe... 3 2

Mehr

Eingeschränkter Zugriff für Server

Eingeschränkter Zugriff für Server Eingeschränkter Zugriff für Server Firewallrichtlinien In diesem Kapitel: Designfragen für Infrastrukturserver 292 Zeitsynchronisation 292 Windows Update 298 Windows-Produktaktivierung 300 Zusammenfassung

Mehr

Recordersoftware Version 7.1.4 SP C

Recordersoftware Version 7.1.4 SP C Technische Mitteilung Recordersoftware Version 7.1.4 SP C DLS-Recorder Deutsch Version 1.1 / 2011-12-19 1 Zusammenfassung Dieses Dokument beinhaltet Informationen über Neuerungen und Änderungen, die mit

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

optipoint 150 S Konfigurationshinweise für den VoIP-Anbieter bluesip

optipoint 150 S Konfigurationshinweise für den VoIP-Anbieter bluesip optipoint 150 S Konfigurationshinweise für den VoIP-Anbieter bluesip bktoc.fm Inhalt Inhalt 0 1 Einführung............................................................ 2 1.1 Voraussetzungen für die Konfiguration......................................

Mehr

Universal Mobile Gateway V4

Universal Mobile Gateway V4 PV-Electronic, Lyss Universal Mobile Gateway V4 Autor: P.Groner Inhaltsverzeichnis Allgemeine Informationen... 3 Copyrightvermerk... 3 Support Informationen... 3 Produkte Support... 3 Allgemein... 4 Definition

Mehr

VRRP. Bild 004482 zeigt die Adressangaben in einem IP-Paket bei dessen Übermittlung über die Grenze eines IP-Subnetzes hinweg.

VRRP. Bild 004482 zeigt die Adressangaben in einem IP-Paket bei dessen Übermittlung über die Grenze eines IP-Subnetzes hinweg. VRRP Virtual Router Redundancy Protocol Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3824540662 Netzwerke auf Basis des Internet Protocol (IP)

Mehr

Aktuelles von der gematik: Testvorbereitungen

Aktuelles von der gematik: Testvorbereitungen Aktuelles von der gematik: Testvorbereitungen Benno Herrmann Leiter Unternehmenskommunikation und Marketing gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße 136 10117

Mehr

Redundantes Speichern

Redundantes Speichern Redundantes Speichern Höchste Verfügbarkeit und größtmögliche Datensicherheit durch paralleles Speichern in EBÜS Status: Freigegeben Dieses Dokument ist geistiges Eigentum der Accellence Technologies GmbH

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

Einfache VPN Theorie. Von Valentin Lätt (www.valentin-laett.ch)

Einfache VPN Theorie. Von Valentin Lätt (www.valentin-laett.ch) Einfache VPN Theorie Von Valentin Lätt (www.valentin-laett.ch) Einführung Der Ausdruck VPN ist fast jedem bekannt, der sich mindestens einmal grob mit der Materie der Netzwerktechnik auseinandergesetzt

Mehr

Elektronisches Fahrgeldmanagement in NRW

Elektronisches Fahrgeldmanagement in NRW Elektronisches Fahrgeldmanagement in NRW Inbetriebnahmehinweise eticketpvmanager Version 1_1 - Stand: 27.10.2015 0 Allgemeines 0.1 Inhaltsverzeichnis Kapitel Seite 0 Allgemeines... 2 0.1 Inhaltsverzeichnis...

Mehr

Service- Level- Agreement (SLA)

Service- Level- Agreement (SLA) Service- Level- Agreement (SLA) Einführung Bestimmung Dieses Dokument beschreibt die Service-Level der für ihre Hosting-Dienstleistungen und gilt während der Vertragslaufzeit der entsprechenden Produkte.

Mehr

Technische Anforderungen. zum Empfang. von XML-Nachrichten

Technische Anforderungen. zum Empfang. von XML-Nachrichten Technische Anforderungen zum Empfang von XML-Nachrichten 25.11.2004 Peer Uwe Peters 2 1 Inhaltsverzeichnis 1 INHALTSVERZEICHNIS... 2 2 ZIEL DIESES DOKUMENTS... 3 3 KONTEXT... 3 4 SENDEWEG... 4 5 ERREICHBARKEIT...

Mehr

Grundsätzliches. Grundsätzliche Überlegungen zu Netzwerken Stand : Juli 2006

Grundsätzliches. Grundsätzliche Überlegungen zu Netzwerken Stand : Juli 2006 Grundsätzliches Grundsätzliche Überlegungen zu Netzwerken Stand : Juli 2006 Netzanforderungen und - probleme Radikale Designänderungen während des Baus / der Gestaltung von Netzwerken, daher unberechenbare

Mehr

IPv6. Autor Valentin Lätt Datum 09.07.2010 Thema IPv6 Version V 1.0

IPv6. Autor Valentin Lätt Datum 09.07.2010 Thema IPv6 Version V 1.0 Autor Datum 09.07.2010 Thema Version V 1.0 Inhaltsverzeichnis Inhaltsverzeichnis... - 2-1 Das ISO/OSI Modell... - 3-1.1 Internet Protocol Grundlagen... - 3-1.2 Transmission Control Protocol Grundlagen...

Mehr

Handbuch Notruf. Notrufe über Voice over IP: Grundlagen und Praxis. www.handbuch-notruf.at. Karl Heinz Wolf nic.at GmbH. Ausschnitt aus dem

Handbuch Notruf. Notrufe über Voice over IP: Grundlagen und Praxis. www.handbuch-notruf.at. Karl Heinz Wolf nic.at GmbH. Ausschnitt aus dem Karl Heinz Wolf nic.at GmbH Ausschnitt aus dem Handbuch Notruf Notrufe über Voice over IP: Grundlagen und Praxis www.handbuch-notruf.at Handbuch Notruf 3 4 IETF-Notrufarchitektur Bei der IETF wird derzeit

Mehr

TimePunch SQL Server Datenbank Setup

TimePunch SQL Server Datenbank Setup TimePunch TimePunch SQL Server Datenbank Setup Benutzerhandbuch 26.11.2013 TimePunch KG, Wormser Str. 37, 68642 Bürstadt Dokumenten Information: Dokumenten-Name Benutzerhandbuch, TimePunch SQL Server Datenbank

Mehr

WLAN: Single SSID + Multiple VLANs = Multicast-Problem

WLAN: Single SSID + Multiple VLANs = Multicast-Problem WLAN: Single SSID + Multiple VLANs = Multicast-Problem Forum Mobile IT, 62. DFN Betriebstagung, 4.3.2015 Rechenzentrum Agenda Motivation Wie funktioniert Single SSID + Multiple VLANs? Wie funktioniert

Mehr

Scopevisio AG Abteilung Auftragsdatenverarbeitung Rheinwerkallee 3

Scopevisio AG Abteilung Auftragsdatenverarbeitung Rheinwerkallee 3 Scopevisio AG Abteilung Auftragsdatenverarbeitung Rheinwerkallee 3 53227 Bonn Copyright Scopevisio AG. All rights reserved. Seite 1 von 11 Copyright Scopevisio AG. All rights reserved. Seite 2 von 11 Inhalt

Mehr

Aktualisierung der ISO/IEC 27001 (ISMS): Entstehung, Änderungsbedarf und Handlungsempfehlungen für Unternehmen

Aktualisierung der ISO/IEC 27001 (ISMS): Entstehung, Änderungsbedarf und Handlungsempfehlungen für Unternehmen Aktualisierung der ISO/IEC 27001 (ISMS): Entstehung, Änderungsbedarf und Handlungsempfehlungen für Unternehmen Bearbeitet von Stefan Beck 1. Auflage 2015. Taschenbuch. 148 S. Paperback ISBN 978 3 95934

Mehr

NovaTec. Konfigurationsanleitung RMCS

NovaTec. Konfigurationsanleitung RMCS NovaTec Konfigurationsanleitung RMCS Version 1.1 / Stand: 09.09.2011 Änderungen vorbehalten copyright: 2011 by NovaTec Kommunikationstechnik GmbH Technologiepark 9 33100 Paderborn Germany Inhaltsverzeichnis

Mehr

VPN (Virtual Private Network) an der BOKU

VPN (Virtual Private Network) an der BOKU VPN (Virtual Private Network) an der BOKU Diese Dokumentation beschreibt Einsatzmöglichkeiten von VPN an BOKU sowie Anleitungen zur Installation von VPN-Clients. Zielgruppe der Dokumentation: Anfragen

Mehr

Datenübernahme easyjob 3.0 zu easyjob 4.0

Datenübernahme easyjob 3.0 zu easyjob 4.0 Datenübernahme easyjob 3.0 zu easyjob 4.0 Einführung...3 Systemanforderung easyjob 4.0...3 Vorgehensweise zur Umstellung zu easyjob 4.0...4 Installation easyjob 4.0 auf dem Server und Arbeitsstationen...4

Mehr

Use Case Beschreibung:

Use Case Beschreibung: <Name (Nummer)> Dokument-Art UC Geltungsbereich Use Case Beschreibung: Version Autor Ausgabe vom Ersetzt Dokument Ausgabestelle Prüfstelle Freigabestelle

Mehr

Whitepaper. bi-cube SSO SSO in einer Terminal Umgebung. T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g

Whitepaper. bi-cube SSO SSO in einer Terminal Umgebung. T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Whitepaper bi-cube SSO T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Inhalt 1 DIE SITUATION...3 2 ZIELSTELLUNG...4 3 VORAUSSETZUNG...5 4 ARCHITEKTUR DER LÖSUNG...6 4.1 Biometrische

Mehr

Standard Inhaltsverzeichnis für Software-Anforderungsspezifikation

Standard Inhaltsverzeichnis für Software-Anforderungsspezifikation Standard Inhaltsverzeichnis für Software-Anforderungsspezifikation Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Software-Anforderungsspezifikation... 1 2.2 Freigabe

Mehr

Zeitsynchronisation in drahtlosen Sensornetzen Verfahren und Anwendungen

Zeitsynchronisation in drahtlosen Sensornetzen Verfahren und Anwendungen Zeitsynchronisation in drahtlosen Sensornetzen Verfahren und Anwendungen Dipl.-Inf. Stefan Schramm Wissenschaftlicher Mitarbeiter Internationale wissenschaftliche Konferenz Mittweida Mittweida, 05.11.2014

Mehr

Gauß-IT-Zentrum. DHCP für Institute. Zielgruppe: DV Koordinatoren. Version 1.0

Gauß-IT-Zentrum. DHCP für Institute. Zielgruppe: DV Koordinatoren. Version 1.0 Gauß-IT-Zentrum DHCP für Institute Zielgruppe: DV Koordinatoren Version 1.0 1 DHCP für Institute Inhalt Dynamic Host Configuration Protocol (DHCP) für Institute 2 DHCP-Interface im KDD 2 DHCP beantragen

Mehr

Sicheres Netz der KVen Formular Ergänzende Erklärung zur Zertifizierung zum KV-SafeNet-Provider

Sicheres Netz der KVen Formular Ergänzende Erklärung zur Zertifizierung zum KV-SafeNet-Provider Formular Ergänzende Erklärung zur Zertifizierung zum KV-SafeNet-Provider [KBV_SNK_FOEX_KV-SafeNet] Dezernat 6 Informationstechnik, Telematik und Telemedizin 10623 Berlin, Herbert-Lewin-Platz 2 Kassenärztliche

Mehr

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

Mehr

www.uni-math.gwdg.de/linuxuebung

www.uni-math.gwdg.de/linuxuebung 14 Netzwerküberwachung und -steuerung Überblick SNMP Simple Network Management Protocol Datendefinitionen SNMP Implementierungen unter Linux Kommandos zur Datenbeschaffung Konfiguration des Net-SNMP Agenten

Mehr

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Message Broker (MB) Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße

Mehr

Aufbau des Internets. Nelson & Bruno Quellen: Netplanet

Aufbau des Internets. Nelson & Bruno Quellen: Netplanet Aufbau des Internets Nelson & Bruno Quellen: Netplanet Inhaltsverzeichnis Arten von Netzwerken Host-Architekturen Schichtenmodelle TCP/IP - Haussprache des Internet Übertragung im Netz Routing Topologie

Mehr

Architektur und Funktionsweise des Konnektors für Krankenhausinformationsund Arztpraxissysteme

Architektur und Funktionsweise des Konnektors für Krankenhausinformationsund Arztpraxissysteme Architektur und Funktionsweise des Konnektors für Krankenhausinformationsund Arztpraxissysteme Stefan Menge Siemens Medical Solutions Copyright Siemens AG 2007. All rights reserved. Agenda Überblick Gesamtarchitektur

Mehr

A-CERT Certificate Policy

A-CERT Certificate Policy ARGE DATEN A-CERT Certificate Policy [gültig für Testzertifikate für einfache Signaturen] Version 1.2/Juli 2009 - a-cert-freecert-policy.doc OID-Nummer: 1.2.40.0.24.1.1.4.1 Gültigkeitshistorie OID-Nummer:

Mehr

IPv6 Vorbereitungen auf die neuen IP-Adressen

IPv6 Vorbereitungen auf die neuen IP-Adressen IPv6 Vorbereitungen auf die neuen IP-Adressen CableTech - 16. März 2011 Michael Neumann Was ist IPv6 IPv6 = Internet Protokoll Version 6 Nachfolger von IPv4 Neuer Standard für Datenübermittlung Synonym

Mehr

A023 DNS Services. IKT-Architekturvorgabe. Ausgabedatum: 2015-01-20. Version: 1.02. Ersetzt: 1.01

A023 DNS Services. IKT-Architekturvorgabe. Ausgabedatum: 2015-01-20. Version: 1.02. Ersetzt: 1.01 Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB A023 DNS Services Klassifizierung: Typ: Nicht klassifiziert IKT-Architekturvorgabe Ausgabedatum: 2015-01-20 Version: 1.02

Mehr

Zusammenarbeit mit Partnern

Zusammenarbeit mit Partnern Zusammenarbeit mit Partnern BMW Group Anforderungen an ein BMW Satellitenbüro Folie 1 (Besetzung im Satellitenbüro durch BMW und externe Mitarbeiter) Grundsätze Die Geheimhaltung ist zwischen den Partnern

Mehr

TCP/IP Protokollstapel

TCP/IP Protokollstapel TCP/IP Protokollstapel IP: Hauptaufgabe ist das Routing (Weglenkung) und Adressierung IP ist ein ungesichertes, verbindungsloses Protokoll Arbeitet auf Schicht 3 UDP: User Datagram Protocol UDP ist ein

Mehr

SMC Integrationsserver 5.0 Versionsinformationen

SMC Integrationsserver 5.0 Versionsinformationen SMC Integrationsserver 5.0 Versionsinformationen SMC IT AG Pröllstraße 24 86157 Augsburg Tel. (0821) 720 62-0 Fax. (0821) 720 62-62 smc-it.de info@smc-it.de Geschäftsstelle Ettlingen Pforzheimer Straße

Mehr

Zulassung Produkte der Telematikinfrastruktur hier: gematik Root-CA

Zulassung Produkte der Telematikinfrastruktur hier: gematik Root-CA Einführung der Gesundheitskarte Verfahrensbeschreibung Zulassung Produkte der Version: 1.0.0 Revision: \main\17 Stand: 15.05.2014 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [gemzul_prod_x509root]

Mehr

dpa-infocom - Datenlieferung

dpa-infocom - Datenlieferung dpa-infocom - Datenlieferung Copyright 2006 von dpa-infocom GmbH Status des Dokuments: FINAL Inhaltsverzeichnis Inhaltsverzeichnis...1 1. Verzeichnisstrukturen...2 2. Nachrichtenmanagement...2 3. Datenübertragung...3

Mehr

Verteilte Systeme. Synchronisation I. Prof. Dr. Oliver Haase

Verteilte Systeme. Synchronisation I. Prof. Dr. Oliver Haase Verteilte Systeme Synchronisation I Prof. Dr. Oliver Haase 1 Überblick Synchronisation 1 Zeit in verteilten Systemen Verfahren zum gegenseitigen Ausschluss Synchronisation 2 Globale Zustände Wahlalgorithmen

Mehr

DIE GRUNDLAGEN DER FERNÜBERWACHUNG

DIE GRUNDLAGEN DER FERNÜBERWACHUNG DIE GRUNDLAGEN DER FERNÜBERWACHUNG Verbraucherleitfaden Version 1.0 Deutsch Einleitung Derzeit sind am Markt zahlreiche Videoüberwachungssysteme erhältlich, die einen digitalen Zugriff über Netzwerkverbindungen

Mehr

Verteilte Systeme - 3. Übung

Verteilte Systeme - 3. Übung Verteilte Systeme - 3. Übung Dr. Jens Brandt Sommersemester 2011 1. Zeit in verteilten Systemen a) Nennen Sie mindestens drei verschiedene Ursachen zeitlicher Verzögerungen, die bei einem Entwurf eines

Mehr

Empfehlung für die technische Kommunikation von Produktänderungen im GDSN

Empfehlung für die technische Kommunikation von Produktänderungen im GDSN 1 Germany Empfehlung für die technische Kommunikation von Produktänderungen im GDSN Version 1.0 Stand Mai 2014 I I I Global Standards. Make Business Efficient. Zielsetzung des Dokuments Ziel der vorliegenden

Mehr

Alle Video-Arbeitsplätze zentral überwachen

Alle Video-Arbeitsplätze zentral überwachen EBÜS Supervisor Alle Video-Arbeitsplätze zentral überwachen Status: Freigegeben Dieses Dokument ist geistiges Eigentum der Accellence Technologies GmbH und darf nur mit unserer ausdrücklichen Zustimmung

Mehr

Synology MailStation Anleitung

Synology MailStation Anleitung Nach dem englischen Original von Synology Inc. Synology MailStation Anleitung Übersetzt von Matthieu (synology-forum.de) Matthieu von synology-forum.de 04.08.2009 Inhaltsverzeichnis Einleitung... 3 1.

Mehr

Tabelle: Maßnahmen und Datenschutz-Kontrollziele zu Baustein 1.5 Datenschutz

Tabelle: Maßnahmen und Datenschutz-Kontrollziele zu Baustein 1.5 Datenschutz Tabelle: Maßn und Datenschutz-Kontrollziele zu Baustein 1.5 Datenschutz (Verweis aus Maß M 7.5) Basierend auf den IT-Grundschutz-Katalogen Version 2006 Stand: November 2006, Stand der Tabelle: 22.08.07

Mehr

peer-to-peer Dateisystem Synchronisation

peer-to-peer Dateisystem Synchronisation Ziel Realisierungen Coda Ideen Fazit Literatur peer-to-peer Dateisystem Synchronisation Studiendepartment Informatik Hochschule für Angewandte Wissenschaften Hamburg 30. November 2007 Ziel Realisierungen

Mehr

SWE KEx-Datex II. System-Architektur

SWE KEx-Datex II. System-Architektur Seite: 1 von 10 SWE Version 3.0 Stand 16.02.2015 Produktzustand Datei Vorgelegt SysArc_KExDatex_FREI_V3.0_D2015-02-16.docx Projektleiter Projektträger Herr Stock Strassen.nrw Verantwortlich Ansprechpartner

Mehr

A506 Backup Software. IKT-Standard. Ausgabedatum: 2015-02-03. Version: 1.13. Ersetzt: 1.12

A506 Backup Software. IKT-Standard. Ausgabedatum: 2015-02-03. Version: 1.13. Ersetzt: 1.12 Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB A506 Backup Software Klassifizierung: Typ: Nicht klassifiziert IKT-Standard Ausgabedatum: 2015-02-03 Version: 1.13 Status:

Mehr

Band M, Kapitel 7: IT-Dienste

Band M, Kapitel 7: IT-Dienste Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: Hochverfuegbarkeit@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit

Mehr

Elektronische Signaturen. LANDRATSAMT BAUTZEN Innerer Service EDV

Elektronische Signaturen. LANDRATSAMT BAUTZEN Innerer Service EDV Elektronische Signaturen Rechtsrahmen Signaturgesetz (SigG) Signaturverordnung (SigV) Bürgerliches Gesetzbuch (BGB), 125 ff. über die Formen von Rechtsgeschäften Verwaltungsverfahrensgesetz (VwVfG), 3a

Mehr

OPNET s Application Response Expert (ARX)

OPNET s Application Response Expert (ARX) OPNET s Application Response Expert (ARX) Root Cause Analyse und End2End Monitoring für Web Anwendungen Summary Werden im IT Betrieb Probleme durch die Anwender gemeldet, müssen schnell Informationen aus

Mehr

GPRS-Modem: ComFTP. Voraussetzungen für eine erfolgreiche Inbetriebnahme. Sehr geehrter Kunde,

GPRS-Modem: ComFTP. Voraussetzungen für eine erfolgreiche Inbetriebnahme. Sehr geehrter Kunde, Sehr geehrter Kunde, die Applikation ComFTP ist dazu gedacht, automatisiert online Messwerte (Prozessdaten) oder Archive aus einem EK260 / EK280 oder DL2x0 auf einen FTP-Server im PUSH-Betrieb zu übertragen.

Mehr

NTP Eine Zusammenfassung. ProSeminar: Kommunikationsprotokolle SS 2003

NTP Eine Zusammenfassung. ProSeminar: Kommunikationsprotokolle SS 2003 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol NTP Eine Zusammenfassung ProSeminar: Kommunikationsprotokolle SS 2003 Marek Jawurek Matrikelnummer:

Mehr

optipoint 150 S Konfigurationshinweise für den VoIP-Anbieter T-Online

optipoint 150 S Konfigurationshinweise für den VoIP-Anbieter T-Online optipoint 150 S Konfigurationshinweise für den VoIP-Anbieter T-Online bktoc.fm Inhalt Inhalt 0 1 Einführung............................................................ 3 1.1 Voraussetzungen für die Konfiguration......................................

Mehr

CN.as COM - SIP Spezifikationen Notruf

CN.as COM - SIP Spezifikationen Notruf Dokument-Nr. Version Gültig ab Dokumenten- Status Verteilerstatus Arbeitsgruppe Anzahl Seiten 1.00 01.01.2016 öffentlich 000 10 PLaPB Technisches Planungshandbuch der ASFiNAG AUTOBAHNEN- UND SCHNELLSTRASSEN-FINANZIERUNGS-AKTIENGESELLSCHAFT

Mehr

bnsyncservice Installation und Konfiguration bnnetserverdienst Voraussetzungen: KWP Informationssysteme GmbH Technische Dokumentation

bnsyncservice Installation und Konfiguration bnnetserverdienst Voraussetzungen: KWP Informationssysteme GmbH Technische Dokumentation bnsyncservice Voraussetzungen: Tobit DAVID Version 12, DVWIN32: 12.00a.4147, DVAPI: 12.00a.0363 Exchange Server (Microsoft Online Services) Grundsätzlich wird von Seiten KWP ausschließlich die CLOUD-Lösung

Mehr

Fachtagung der TUI-Koordinatoren am 11. und 12.11.2009

Fachtagung der TUI-Koordinatoren am 11. und 12.11.2009 Wahlergebnispräsentation - Probleme Bewältigung - Vermeidung Zusammenfassung der Ergebnisse Fachtagung der TUI-Koordinatoren am 11. und 12.11.2009 Frank Albrecht Citkomm Version 1.0 Status: freigegeben

Mehr

Die Beurteilung normativer Managementsysteme

Die Beurteilung normativer Managementsysteme Die Beurteilung normativer Managementsysteme Hanspeter Ischi, Leiter SAS 1. Ziel und Zweck Um die Vertrauenswürdigkeit von Zertifikaten, welche durch akkreditierte Zertifizierungsstellen ausgestellt werden,

Mehr

Anwendungshinweis. Portweiterleitung mit Linux basierenden Steuerungen. A500840, Deutsch Version 1.0.0

Anwendungshinweis. Portweiterleitung mit Linux basierenden Steuerungen. A500840, Deutsch Version 1.0.0 Portweiterleitung mit Linux basierenden Steuerungen, Deutsch Version 1.0.0 ii Wichtige Erläuterungen Impressum Copyright 2011 by WAGO Kontakttechnik GmbH & Co. KG Alle Rechte vorbehalten. WAGO Kontakttechnik

Mehr

IP-Adressen und Ports

IP-Adressen und Ports IP-Adressen und Ports Eine Einführung Tina Umlandt Universität Hamburg 2. August 2011 Überblick Präsentationsablauf 1 IP = Internetwork protocol Schematische Darstellung über die Layer IP-Datenpaket (IPv4)

Mehr

Das Network Time Protocol - NTP. Das Network Time Protocol - NTP. Das Network Time Protocol - NTP. Das Network Time Protocol - NTP

Das Network Time Protocol - NTP. Das Network Time Protocol - NTP. Das Network Time Protocol - NTP. Das Network Time Protocol - NTP Ausführliche Informationen zu NTP im WWW: Eigenschaften von NTP http://www.ntp.org ("Offizielle" NTP-Homepage) http://www.eecis.udel.edu/~mills (Homepage David Mills) Geschichte Entwickelt seit 198 (NTP

Mehr

Multicast Security Group Key Management Architecture (MSEC GKMArch)

Multicast Security Group Key Management Architecture (MSEC GKMArch) Multicast Security Group Key Management Architecture (MSEC GKMArch) draft-ietf-msec-gkmarch-07.txt Internet Security Tobias Engelbrecht Einführung Bei diversen Internetanwendungen, wie zum Beispiel Telefonkonferenzen

Mehr

Anleitung fu r die Vorlage restpunkte.xlsx

Anleitung fu r die Vorlage restpunkte.xlsx Anleitung fu r die Vorlage restpunkte.xlsx Inhalt 1 Einleitung... 1 2 Grundsätzliche Bedienungshinweise... 1 3 Wichtige Regeln für das Ausfüllen... 2 4 Erfassen der Information... 2 4.1 Das Blatt Inspektionen...

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr