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

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

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

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

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

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

... 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

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

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

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

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

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

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

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

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

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

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

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

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION Prof. Dr.-Ing. Dagmar Meyer 5 SYNCHRONISATION Warum braucht man Synchronisation? Ausgangssituation Prozesse müssen sich koordinieren / synchronisieren, z. B. beim Zugriff auf gemeinsame Ressourcen. Alle

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

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

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

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Wolfgang Ginolas Fachhochschule Wedel 21. September 2009 Wolfgang Ginolas (Fachhochschule Wedel) 21. September 2009 1 / 14 Einleitung

Mehr

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

Mehr

7 Transportprotokolle

7 Transportprotokolle 7 Transportprotokolle 7.1 Transmission Control Protocol (TCP) 7.2 User Datagram Protocol (UDP) 7.3 Ports 7.1 TCP (1) IP-Pakete (Datagramme) von A nach B transportieren reicht nicht interaktive Verbindungen

Mehr

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com Use Cases REQEDIT CLIENT Mai 2014 Übersicht 1. Einführung Anforderungsmanagement 2. Einführung Anforderungsmanagementtools und Austauschformate 3. Warum ReqEdit? 4. Use Cases - kleinere und mittlere Unternehmen

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

Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr.

Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr. Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr. Herbert Weber Von Dezember 2004 bis Februar 2005 haben die Fraunhofer-Institute

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

Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von

Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Rick Graziani Cabrillo College Vorbemerkung Die englische Originalversion

Mehr

S1 Zeit in verteilten Systemen

S1 Zeit in verteilten Systemen S1 Zeit in verteilten Systemen Süddeutsche Zeitung vom 1.1.1 FK4 Prof. Dr. Rainer Seck 1 Eigenschaften verteilter Systeme Szenarien: konkurrierender Zugriff auf einmal vorhandene Betriebsmittel verteilter

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft Lösungen zu ---- Informations- und Telekommunikationstechnik - Arbeitsheft Handlungsschritt Aufgabe a) Die TCP/IP-Protokollfamilie verwendet logischen Adressen für die Rechner (IP- Adressen), die eine

Mehr

IPsec. Vortrag im Rahmen des Seminars Neue Internet Technologien

IPsec. Vortrag im Rahmen des Seminars Neue Internet Technologien IPsec Vortrag im Rahmen des Seminars Neue Internet Technologien Friedrich Schiller Universität Jena Wintersemester 2003/2004 Thomas Heinze, Matrikel xxxxx Gliederung IPsec? - Motivation, Grundbegriffe,

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

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

Lösung Verteilte Systeme WS 2011/12 Teil 1

Lösung Verteilte Systeme WS 2011/12 Teil 1 Seite 1 von 5 Lösung Verteilte Systeme WS 2011/12 Teil 1 2.02.2012 1. Aufgabe (5) Sie fahren in Ihrem Privatfahrzeug auf einer Autobahn und hinter Ihnen fährt ein Polizeifahrzeug. 1.1 Nennen Sie ein Szenario,

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

Recordersoftware Version 7.3.5

Recordersoftware Version 7.3.5 Technische Mitteilung Recordersoftware Version 7.3.5 DMX Recorder Deutsch Version 1.0 / 2011-09-07 1 Zusammenfassung Dieses Dokument beinhaltet Informationen über Neuerungen und Änderungen, die mit der

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

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet SEC Für ein sicheres Internet Was ist SEC? SEC ist eine Erweiterung des Domain Namen Systems (), die dazu dient, die Echtheit (Authentizität) und die Voll ständig keit (Integrität) der Daten von - Antworten

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

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

Mehr

PKI für CV-Zertifikate

PKI für CV-Zertifikate Einführung der Gesundheitskarte PKI für CV-Zertifikate Registrierung einer CVC-CA der zweiten Ebene Version: 1.5.0 Stand: 18.03.2008 Status: freigegeben gematik_pki_cvc_registrierung_subca_v1_5_0.doc Seite

Mehr

DECUS Symposium Bonn 29.3.2000. File: decus_tim Peter Schuerholt. Casium-Uhr. DECUS Symposium Bonn 29.3.2000. Peter Schuerholt

DECUS Symposium Bonn 29.3.2000. File: decus_tim Peter Schuerholt. Casium-Uhr. DECUS Symposium Bonn 29.3.2000. Peter Schuerholt Network Time Service Agenda Vortragsnummer: 2O04 "Time has been invented in the universe so that everything would not happen at once." Einführung in die Zeit-Geschichte UTC NTP Protokoll NTP Hierarchie

Mehr

Buzzword Bingo Game Documentation (Java based Game)

Buzzword Bingo Game Documentation (Java based Game) Buzzword Bingo Game Documentation (Java based Game) Meppe Patrick Djeufack Stella Beltran Daniel April 15, 2011 1 Inhaltsverzeichnis 1 Einleitung 3 2 Aufgabenstellung 3 3 Allgemeines zu Buzzword Bingo

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

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

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

Robert Schischka GovCERT.at / CERT.at

Robert Schischka GovCERT.at / CERT.at CERT-Strukturen in Österreich und Maßnahmen zur DNS-SicherheitSicherheit Robert Schischka GovCERT.at / CERT.at Teams in Österreich CERT.at nationales CERT GovCERT öffentliche Verwaltung Weitere Teams

Mehr

Artikelüberschrift (Vorlage Überschrift 1 )

Artikelüberschrift (Vorlage Überschrift 1 ) Artikelüberschrift (Vorlage Überschrift 1 ) Paul Beitragsautor (Vorlage Autoren ) 1 Einleitung Bitte verwenden Sie diese Word-Dokumentvorlage zum Erstellen von einzelnen Sammelband-Beiträgen. Sie enthält

Mehr

Kurs 70-291 Notizen Rene Dreher www.renedreher.de -DNS (Domain Name System)

Kurs 70-291 Notizen Rene Dreher www.renedreher.de -DNS (Domain Name System) -DNS (Domain Name System) Das DNS ist ein weltweit auf tausende von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in so genannte

Mehr

NetScaler Integration bei Hellmann Worldwide Logistics. Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011

NetScaler Integration bei Hellmann Worldwide Logistics. Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011 NetScaler Integration bei Hellmann Worldwide Logistics Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011 Agenda Firmenporträt Das Projekt Details zur Umsetzung Fazit Fakten & Zahlen Mitarbeiter

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

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

Mindeststandard des BSI nach 8 Abs. 1 Satz 1 BSIG für den Einsatz des SSL/TLS-Protokolls in der Bundesverwaltung

Mindeststandard des BSI nach 8 Abs. 1 Satz 1 BSIG für den Einsatz des SSL/TLS-Protokolls in der Bundesverwaltung Mindeststandard des BSI nach 8 Abs. 1 Satz 1 BSIG für den Einsatz des SSL/TLS-Protokolls in der Bundesverwaltung Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49

Mehr

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen 9. Februar 2008 Vortrag für den PC-Treff Böblingen Agenda 1 Einleitung Netzwerkeinstellungen 2 Feste Zuordnung Lease 3 4 Einleitung Einleitung Netzwerkeinstellungen DHCP, das Dynamic Host Configuration

Mehr

Red Hat Cluster Suite

Red Hat Cluster Suite Red Hat Cluster Suite Building high-available Applications Thomas Grazer Linuxtage 2008 Outline 1 Clusterarten 2 3 Architektur Konfiguration 4 Clusterarten Was ist eigentlich ein Cluster? Wozu braucht

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Bedienerhandbuch. TCO-Inventar. Netzwerk Scanner

Bedienerhandbuch. TCO-Inventar. Netzwerk Scanner Bedienerhandbuch TCO-Inventar Netzwerk Scanner Zimmer IT-Solution Am Hart 9f 85375 Neufahrn Tel.: 08165 / 6476443 Fax.: 08165 / 6476445 www.zimmer-it-solution.de Inhaltsverzeichnis 1 Der Inventar-Scanner...4

Mehr

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Peter Hillmann Institut für Technische Informatik Fakultät für Informatik Peter.Hillmann@unibw.de Peter Hillmann 1 Gliederung 1. Motivation

Mehr

Grundlagen TCP/IP. C3D2 Chaostreff Dresden. Sven Klemm sven@elektro-klemm.de

Grundlagen TCP/IP. C3D2 Chaostreff Dresden. Sven Klemm sven@elektro-klemm.de Grundlagen TCP/IP C3D2 Chaostreff Dresden Sven Klemm sven@elektro-klemm.de Gliederung TCP/IP Schichtenmodell / Kapselung ARP Spoofing Relaying IP ICMP Redirection UDP TCP Schichtenmodell Protokolle der

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

Konfigurationsanleitung SIP Trunking und ISDN Anlagenanschluss Graphical User Interface (GUI) Seite - 1 -

Konfigurationsanleitung SIP Trunking und ISDN Anlagenanschluss Graphical User Interface (GUI) Seite - 1 - Konfigurationsanleitung SIP Trunking und ISDN Anlagenanschluss Graphical User Interface (GUI) Copyright Stefan Dahler 22. Oktober 2013 Version 1.0 www.neo-one.de Seite - 1 - 3. SIP Trunking und ISDN Anlagenanschluss

Mehr

RSS Push Verfahren. Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI. 18. November 2009

RSS Push Verfahren. Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI. 18. November 2009 RSS Push Verfahren Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI 18. November 2009 1 Übersicht RSSFeeds Polling Push RSSCloud PubSubHubBub Vergleich Quellen 2 Feeds FU-Berlin Institut

Mehr

VIEWER EVOLUTION VOM APPLET ZUM JADICE WEB TOOLKIT: KUNDENBEISPIEL LEVIGO SOLUTIONS DAY 24.10.2013, 11:15 11:45 F. STEHLING CENIT ECM

VIEWER EVOLUTION VOM APPLET ZUM JADICE WEB TOOLKIT: KUNDENBEISPIEL LEVIGO SOLUTIONS DAY 24.10.2013, 11:15 11:45 F. STEHLING CENIT ECM VIEWER EVOLUTION VOM APPLET ZUM JADICE WEB TOOLKIT: KUNDENBEISPIEL LEVIGO SOLUTIONS DAY 24.10.2013, 11:15 11:45 F. STEHLING CENIT ECM VIEWER EVOLUTION 2 PROJEKTABLAUF Technische Evaluierung Gründe für

Mehr

EBÜS Manager. Alle Video-Arbeitsplätze zentral überwachen. Hardo Naumann EBÜS Manager 12.10.2007. Status: Freigegeben, 12.10.2007

EBÜS Manager. Alle Video-Arbeitsplätze zentral überwachen. Hardo Naumann EBÜS Manager 12.10.2007. Status: Freigegeben, 12.10.2007 EBÜS Manager Alle Video-Arbeitsplätze zentral überwachen Status: Freigegeben, 12.10.2007 Dieses Dokument ist geistiges Eigentum der Accellence Technologies GmbH und darf nur mit unserer ausdrücklichen

Mehr

.TEL Eine innovative Nutzung des DNS

.TEL Eine innovative Nutzung des DNS .TEL Eineinnovative NutzungdesDNS 1 von 5 DAS KONZEPT Die.tel-Registry nutzt das Domain Name System (DNS) auf eine Weise, die Inhabern einer.tel-domain Unternehmen oder Einzelpersonen die Kontrolle in

Mehr

nachfolgende Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte

nachfolgende Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte Stand: 1. Januar 2015 Zwischen dem GKV-Spitzenverband (Spitzenverband Bund der Krankenkassen) K.d.ö.R, Berlin und der Kassenärztlichen

Mehr

Kurzanleitung So geht s. Fernzugriff mit der ETS. MDT IP-Interface und IP-Router

Kurzanleitung So geht s. Fernzugriff mit der ETS. MDT IP-Interface und IP-Router Kurzanleitung So geht s Fernzugriff mit der ETS Anwendungsbeispiel: Fernzugriffs auf das ETS-Netzwerk über das Internet. Verwendete Geräte: MDT IP-Interface und IP-Router SCN-IP000.01 & SCN-IP100.01 1

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

Kurzanleitung. Arbeiten mit Word 2003 bei der Erstellung Wissenschaftlicher Arbeiten. Renate Vochezer rv@vochezer-trilogo.de

Kurzanleitung. Arbeiten mit Word 2003 bei der Erstellung Wissenschaftlicher Arbeiten. Renate Vochezer rv@vochezer-trilogo.de Kurzanleitung Arbeiten mit Word 2003 bei der Erstellung Wissenschaftlicher Arbeiten Renate Vochezer rv@vochezer-trilogo.de Inhaltsverzeichnis, Abbildungs- und Tabellenverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis...

Mehr

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/ Einführung Was ist Unison? Unison ist ein Dateisynchronisationsprogramm für Windows und Unix. Es teilt sich viele Funktionen mit anderen Programmen, wie z.b. CVS und rsync. Folgend einige Vorteile des

Mehr

Managed Cloud Services

Managed Cloud Services Managed Cloud Services Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Cloud Services

Mehr

LAN Schutzkonzepte - Firewalls

LAN Schutzkonzepte - Firewalls LAN Schutzkonzepte - Firewalls - Allgemein Generelle Abschirmung des LAN der Universität Bayreuth - Lehrstuhlnetz transparente Firewall - Prinzip a) kommerzielle Produkte b) Eigenbau auf Linuxbasis - lokaler

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network. 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung

Mehr

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel VS7 Slide 1 Verteilte Systeme Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

Mehr

Time synchronisation with NTP

Time synchronisation with NTP Time synchronisation with NTP Matthias Kastner Betreuer: Dirk Haage Seminar Innovative Internet Technologien und Mobilkommunikation WS09/10 Lehrstuhl Netzarchitekturen und Netzdienste Fakultät für Informatik,

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

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

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

D5 GmbH AnycastDNS SCHNELL, STABIL UND AUSFALLSICHER

D5 GmbH AnycastDNS SCHNELL, STABIL UND AUSFALLSICHER D5 GmbH AnycastDNS SCHNELL, STABIL UND AUSFALLSICHER Hochverfügbare Nameserver-Infrastruktur zum Schutz vor DoS-Attacken und für optimale Erreichbarkeit weltweit und jederzeit 1 AnycastDNS von D5 Höchste

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

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

SHD Rechenzentrum. Leistungsbeschreibung

SHD Rechenzentrum. Leistungsbeschreibung SHD Rechenzentrum Leistungsbeschreibung Gegenstand des Leistungsbildes Gegenstand dieser Leistungsbeschreibung ist das Leistungsbild der SHD Rechenzentrumslösung. Dieses Leistungsbild beschreibt Umfang

Mehr

Zugangsschutz: Packet Filter und Firewalls

Zugangsschutz: Packet Filter und Firewalls Zugangsschutz: Packet Filter und Firewalls (1) Motivation Das Internet hat sich von einem rein akademischen Netzverbund zu einer Informationsquelle entwickelt, die auch für kommerzielle Zwecke von Interesse

Mehr

Internet Routing am 14. 11. 2006 mit Lösungen

Internet Routing am 14. 11. 2006 mit Lösungen Wissenstandsprüfung zur Vorlesung Internet Routing am 14. 11. 2006 mit Lösungen Beachten Sie bitte folgende Hinweise! Dieser Test ist freiwillig und geht in keiner Weise in die Prüfungsnote ein!!! Dieser

Mehr

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät NAT und Firewalls Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April 2005

Mehr

Netz16 GmbH Managed Service / Cloud Solutions. www.netz16.de Netz16 GmbH Firmenpräsentation / Stand 2014 S. 1

Netz16 GmbH Managed Service / Cloud Solutions. www.netz16.de Netz16 GmbH Firmenpräsentation / Stand 2014 S. 1 Netz16 GmbH Managed Service / Cloud Solutions www.netz16.de Netz16 GmbH Firmenpräsentation / Stand 2014 S. 1 Vorstellung Netz16 Eckdaten unseres Unternehmens Personal 80 60 40 20 0 2010 2011 2012 2013

Mehr

Diplomanden- und Doktorandenseminar. Implementierung eines Gnutella-Clients für IPv6

Diplomanden- und Doktorandenseminar. Implementierung eines Gnutella-Clients für IPv6 Diplomanden- und Doktorandenseminar Implementierung eines Gnutella-Clients für IPv6 1. Motivation 2. IPv6 3. Gnutella 4. Portierung Frank Sowinski 17.12.2002 Motivation Gute Gründe für IPv6 Das Anwachsen

Mehr

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor.

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor. Cloud Computing im Gesundheitswesen Cloud Computing ist derzeit das beherrschende Thema in der Informationstechnologie. Die Möglichkeit IT Ressourcen oder Applikationen aus einem Netz von Computern zu

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Bestimmungen zur Kontrolle externer Lieferanten

Bestimmungen zur Kontrolle externer Lieferanten Bestimmungen zur Kontrolle externer Lieferanten Internet-Sicherheit Für Lieferanten der Kategorie Geringes Internetrisiko Internet- 1. Ressourcenschutz und Systemkonfiguration Die Daten von Barclays sowie

Mehr

How-to: Webserver NAT. Securepoint Security System Version 2007nx

How-to: Webserver NAT. Securepoint Security System Version 2007nx Securepoint Security System Inhaltsverzeichnis Webserver NAT... 3 1 Konfiguration einer Webserver NAT... 4 1.1 Einrichten von Netzwerkobjekten... 4 1.2 Erstellen von Firewall-Regeln... 6 Seite 2 Webserver

Mehr

Tips, Tricks und HOWTOs Virtualisierung für Profis und Einsteiger Serverkonsolidierung, Testumgebung, mobile Demo

Tips, Tricks und HOWTOs Virtualisierung für Profis und Einsteiger Serverkonsolidierung, Testumgebung, mobile Demo virtuelle Maschinen mit VMware und Virtual PC Tips, Tricks und HOWTOs Virtualisierung für Profis und Einsteiger Serverkonsolidierung, Testumgebung, mobile Demo virtuelle DMZ mit IPCop und Webserver unter

Mehr

Scaling IP Addresses. CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg

Scaling IP Addresses. CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg Scaling IP Addresses CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Rick Graziani, Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr